Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Рус.вар.-Метод.указания.к.р.3.doc
Скачиваний:
2
Добавлен:
01.04.2025
Размер:
1 Мб
Скачать
☆

Проектирование реализации базы данных

Точно размежевать инфологический и физический этапы проектирования БД достаточно трудно из-за отсутствия установленной терминологии. Поэтому принято считать, что на этапе инфологического проектирования данные рассматривают без учета специфики используемой СУБД, а особенности ее структуры на этапе физического проектирования, на котором получают СУБД — ориентированную схему БД, принято называть проектированием реализации.

Рис. 8. Второй вариант ER-диаграммы фрагмента БД ИС товарно-сырьевой биржи.

Рис 9. ER – диаграмма фрагмента БД ИС учета лизинговых контрактов.

Проектирование реализации БД — переход к даталогической концептуальной модели данных (СУБД – ориентированной модели).

Инфологическая концептуальная модель является более общей, сравнительно с даталогической концептуальной моделью, отображением состояния информационной системы. Даталогическая модель нуждается в более детальном описании состояния объектов и связей между ними через необходимость отображения модели данных в памяти вычислительной системы. Здесь могут появиться дополнительные объекты хранения в БД. Например, ER-дмаграмму фрагмента БД ИС учета перемещения материалов на складе, который отображает поставку материалов посторонними организациями и реализацию избытков материалов посторонним организациям, можно изобразить двумя вариантами. Первый из них показан на рис. 10. Действия “Получение” и “Реализация” представлены разными связями.

Рис. 10. Первый вариант ER-диаграммы фрагмента БД ИС учета перемещения материалов

Второй вариант этого фрагмента изображен на рис. 11. Контакты с посторонними организациями здесь представлены в виде одной связи “Внешняя операция” с дополнительным атрибутом “Код операции”, не зафиксированным в словаре данных. Атрибут может приобретать два значения: 1 – “Получение” и 0 – “Реализация”. Второй вариант фрагмента имеет преимущества над первым. Они предопределены тем, что вместо двух массивов, — связь между типами сущностей “Материал” и “Внешняя организация”, использован лишь один – “Внешняя операция”. Новый атрибут “Код операции” не влечет существенную избыточность.

Рис. 11. Второй вариант ER-диаграммы фрагмента БД ИС учета перемещения материалов

На концептуальном инфологическом уровне возможными являются использование как первого, так и второго вариантов ER-диаграммы. Переход к более рациональной модели можно выполнить на даталогическом уровне, на котором происходит уточнение и оптимизация структуры БД.

На этапе проектирования реализации БД также возможным является дополнение полученной информационной модели информационными структурами (в виде ER-диаграмм), что предопределено дополнительно обнаруженными запросами к БД.

В дальнейшем этот этап проектирования является переходом от полученной концептуальной инфологической модели к даталогической или СУБД- ориентированной модели данных.

Графически даталогическая модель является отображением инфологической. В ней тип сущности изображают в виде поименованного прямоугольника, каждая клетка которого отвечает атрибуту сущности. Ключ подчеркивается. Связи между записями отображают в виде направленных линий с указанием типов связи 1:1, 1:М, М:М. Данные пересечения при связи типа М:М указываются рядом с линией связи.

Переходя к даталогической модели данных, стоит руководствоваться такими эвристическими правилами.

Правило 1. Сложная сетевая модель является самой распространенной моделью данных, поскольку она отображает сложность связей между объектами информационной системы. Поэтому, как правило, даталогическая концептуальная модель данных отображается в виде сложной сетевой модели.

Даталогическая модель относительно задачи учета перемещения материалов, которая отвечает второму варианту фрагмента ER-диаграммы (см. Рис. 11), показана на рис. 12. Это неоднородная сложная сетевая модель.

Правило 2. От сложной сетевой модели осуществляется переход к простой сетевой модели. При этом избавляются связей типа М:м, вводя дополнительную запись, которая обязательно должна содержать ключи записей, которые соединяются.

На рис. 13 изображена неоднородная простая сетевая модель, которая отвечает сложной модели на рис. 12.

Рис. 12. Даталогическая модель фрагмента БД ИС учета перемещения материалов в виде сложной сети

Рис. 13. Даталогическая модель фрагмента БД ИС учета перемещения материалов в виде простой сети

Правило 3. При устранении “зависимости от пути” в иерархических фрагментах модели данных в порожденные записи включают ключи порождающих записей. Если экземпляры порожденных записей учитывают в пределах порождающих записей, то первичным ключом порожденной записи становится сложный ключ. Он состоит из первичного ключа порождающей записи и первичного атрибута порожденной записи.

Рис. 14. Иерархическая даталогическая модель фрагмента БД ИС учета изделий на складе с зависимой записью “Изделие”

На рис. 14 показана иерархическая 17 даталогічну модель фрагмента БД ИС учету изделий на составе, который отвечает ER-діаграмі (рис. 3). В данном случае атрибут порожденной записи “Код изделия” означает нумерацию изделий в пределах каждого состава.

После устранения “зависимости от пути”, как это показано на рис. 15, ключ порожденной записи “Изделие” становится сложным. Он состоит из ключа порождающей записи “Склад” и кода изделия на складе.

Рис. 15. Иерархическая даталогическая модель фрагмента БД ИС учета изделий на складе с независимой записью “Изделие”

Первичный ключ порождающей записи поступает к порожденной записи и становится внешним ключом, необходимым для соединения записей по запросам к БД. Результатом устранения “зависимости от пути” является то, что все записи в модели данных становятся автономными, независимыми от порождающих записей.

Правило 4. В сетевой модели понятия “порождающая” и “порожденная” записи условны, потому что точкой входа в ней может быть любая запись. Считать записи порождающими и порожденными можно только после выбора точки входа. Тогда “зависимость от пути” устраняют так же, как и в иерархической структуре данных.

В примере с фрагментом БД, изображенном на рис. 13, запись “Внешняя операция” содержит ключи порождающих записей, потому в этой модели зависимости от пути нет.

Пример, который показан на рис. 16, иллюстрирует простую сетевую модель с зависимой записью. Это фрагмент БД ИС учета материалов на складе свидетельствует, что каждый материал зависит определенным образом от поставщика и склада.

Рис. 16. Даталогическая модель БД ИС учета материалов на складе с зависимой записью “Материал”

Запись “Материал” станет автономной, если будет содержать ключи записей “Склад” и Фирма-поставщик” или как внешние ключи, или как компоненты сложного первичного ключа “Код поставщика” + “Код склада” + “Код материала”. Рис 17 иллюстрирует последний вариант ключа записи “Материал”.

Рис. 17. Даталогическая модель фрагмента БД ИС учета материалов на складе с независимой записью “Материал”

Правило 5. Фрагменты структуры, которые содержат циклы и петли, упрощают по-разному в зависимости от типа связи между типами сущностей. При наличии связей типа М:М в цикле или в петле вводят дополнительную запись с ключами записей, которые соединяются.

Относительно фрагмента БД ИС товарно-сырьевой биржи (см. Рис 8) даталогическая модель данных является сложной сетью (рис. 18).

На рис. 19 показано даталогическую простую сетевую модель данных, в которой устранена связь типа М:М и зависимость от пути. Эта модель отвечает сложной сетевой модели данных, которая изображена на рис 18. Атрибуты “Код конторы 1” и “Код конторы 2” принадлежат домену “Код конторы” и определяют коды контор брокера-продавца и брокера-покупателя товара. Атрибуты “Код брокера 1” и “Код брокера 2” принадлежат домену “Код брокера” и определяют коды брокера-продавца и брокера-покупателя, в своих конторах. Запись “заключения соглашения” имеет сложный ключ. Первые два атрибута записи определяют брокера-продавца, два следующих — брокера-покупателя, пятый — код товара.

Относительно фрагмента БД ИС учета лизинговых контрактов (см. Рис. 9) даталогическая модель является неоднородной сложной сетевой (рис. 20).

На рис. 21 изображена простая сетевая модель данных, в которой устранена связь типа М:М и зависимость от пути. Эта модель отвечает сложной сетевой модели данных, которая показана на рис. 20.

Р ис. 18. Даталогическая сложная сетевая модель данных фрагмента БД ИС товарно-сырьевой биржи

Первичный ключ записи “Лизинговый контракт” является сложным: “Код предприятия 1” + “Код предприятия 2” + Код оборудования” + “Дата контракта”. Атрибуты “Код предприятия 1” и “Код предприятия 2” принадлежат домену “Код предприятия” и определяют код лиссора и код рентера соответственно.

Р ис. 19. Даталогическая простая сетевая модель дынных фрагмента БД ИС товарно-сырьевой биржи

Рис. 20. Даталогическая модель фрагмента БД ИС учета лизинговых контрактов в виде сложной сети

Р ис. 21. Даталогическая модель фрагмента БД ИС учета лизинговых контрактов в виде простой сети

Правило 6. После того как все записи даталогической модели данных стали автономными, то есть независимыми от попрождающих записей, они могут быть представлены в виде схем отдельных отношений. Даталогическая реляционная модель данных содержит набор схем отношений или записей, которые графически не связаны между собой. Схему отношения изображают в виде вектора. Название вектора отвечает названию записи. В скобках через запятую идет перечень имен атрибутов. Первичный ключ подчеркивают.

Правило 7. Даталогическая реляционная модель данных должна состоять из набора схем отношений. Отношения этой модели должны быть возведены как минимум к третьей нормальной форме.

Правило 8. Первичные ключи отношений используются при проектировании уникальных первичных ключевых или индексных файлов, с помощью которых осуществляется поиск данных в памяти вычислительной системы.

Правило 9. В отношении порядок атрибутов в сложном ключе не суть важно, а при проектировании индексного или ключевого файла порядок полей, которые отвечают этим атрибутам, имеет принципиальное значение. Сортировка данных ключа выполняется сначала по первому атрибуту, а в пределах одинаковых экземпляров первого атрибута ключа — по следующим атрибутам и так далее.

Правило 10. Полученную даталогическую модель анализируют с целью оптимизации (в частности, оценивается эффективность схемы БД по объему обработки).

Каждая прикладная задача характеризуется частотой выполнения и количеством обращений LRA (Logical records access) к логическим записям БД. Количество LRA может быть оценено по данным таблицы “Задача — данные” и данными о частоте выполнения каждой прикладной задачи.

Общее количество LRA во всех прикладных задачах является одним из основных критериев эффективности схемы БД. LRA характеризует общее количество обращений к физическим записям БД, которая содержится во внешней памяти. Чем более высок этот показатель в системе, тем ниже скорость обработки. Поэтому прикладная задача с наибольшим значением LRA должна быть исследована с целью совершенствования структуры данных, уменьшения частоты выполнения, решения вопроса о целесообразности оптимизации хранения записей в процессе эксплуатации БД. Последнее обстоятельство особенно важно учитывать тогда, когда файл данных из-за большого размера полностью не вмещается в оперативной памяти. Выборка записей такого файла, отсортированного по ключу, может занимать много времени. Это предопределено тем, что близкие по ключу записи могут физически находиться на диске на значительном расстоянии одна от другой. Такие файлы нужно время от времени перезаписывать, предварительно проиндексировав их по первичному ключу. Это минимизирует время обработки записей. По результатам анализа разрабатывают предложения относительно совершенствования схемы БД и режимов обработки данных.

Пример проектирования базы данные информационной системы “Формирование заказов на товары на фирме”

Постановка задачи

Торгово-посредническая фирма намеревается автоматизировать процесс формирования заказов на товары. БД, которая проектируется, вместе с вычисляемой системой, СУБД, словарем данных и администратором БД играют роль обеспечительной подсистемы ИС процесса сбора и обработки информации о поставщиках и товарах на фирме, а также формирование заказов на товары.

Традиционно товары выбирают служащие фирмы вручную по каталогам и рекламным проспектам фирм-поставщиков. В течение первых трех дней недели служащий фирмы выбирает из каталогов и рекламных проспектов информацию о товарах и фирмах, которые могут заинтересовать администрацию, и вносит ее в созданную таблицу товаров 7, которые предлагаются для продажи.

Таблица 5