6.3. Отображение на сетевую модель данных
Отображение концептуальной модели на сетевую модель данных представляет собой сложный процесс. Здесь также имеется ряд альтернатив, нет очевидного наилучшего решения и требуется выполнение следующих основных этапов:
Формирование обобщенной сетевой модели данных, в которой не учитываются ограничения, накладываемые используемой СУБД.
Трансформация обобщенной сетевой модели с учетом ограничений, накладываемых конкретной СУБД.
Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.
Упрощение имен ключей.
Реализация взаимосвязей, не отраженных в логической модели, но на самом деле существующих.
1. Формирование обобщенной сетевой модели данных, в которой не учитываются ограничения, накладываемые используемой СУБД.
1.1. Определение взаимосвязей «владелец— член».
В концептуальной модели прямоугольники представляют типы записей, а стрелки – связи между ними. При обсуждении сетевой модели воспользуемся так называемыми стрелками Бахмана. На рис. 6.9 приведена концептуальная модель, изображенная с использованием стрелок Бахмана. Это видоизмененный вариант концептуальной модели, показанной на рис. 5.9.
Рис. 6.9
Концептуальная модель, представленная на рис. 5.9, изображена с помощью стрелок Бахмана. Эту модель мы примем за исходную при разработке логической модели. Здесь сделаны следующие предположения:
1. НАЗВ-КУРСА зависит от СЕМЕСТРА и НОМ-КУРСА. Возможно, что от семестра к семестру НАЗВ-КУРСА с данным НОМ-КУРСА будет изменяться.
2. ЗАЧЕТЫ зависят от СЕМЕСТРА, НОМ-КУРСА и НОМ-СТУДЕНТА. Студент сам определяет, сколько зачетов он сдает по данному курсу в данном семестре.
Присвоим наборам имена:
Набор I– ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ, член – СЕМЕСТР + КУРС + СТУДЕНТ.
Набор II–ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС, член – СЕМЕСТР+КУРС+СТУДЕНТ.
Связь между наборами Iи II осуществляет запись-член СЕМЕСТР+КУРС+СТУДЕНТ.
Набор III – КУРСЫ-СЕМЕСТРА: владелец – СЕМЕСТР, член— СЕМЕСТР + КУРС.
Набор IV – СЕМЕСТРЫ-КУРСА: владелец – КУРС, член – СЕ-МЕСТР+КУРС.
Запись-член СЕМЕСТР+КУРС связывает наборы III и IV. Она одновременно состоит членом наборов III и IV и владельцем набора II.
Преобразование концептуальной модели, приведенной на рис. 5.9, в логическую модель, основанную на сетевой модели данных, осуществляется достаточно просто. Полученная в результате сетевая модель (рис. 6.9) не предполагает использования какой-либо конкретной СУБД.
1.2. Устранение множественного владения.
Из рассмотренного выше мы знаем, что член набора не может иметь более одного владельца в одном и том же наборе. В модели на рис. 6.9 это правило не нарушено, поэтому никаких преобразований здесь не требуется.
2. Трансформация обобщенной сетевой модели с учетом ограничений, накладываемых конкретной СУБД.
Целый ряд СУБД базируется на использовании спецификаций КОДАСИЛ, например системы IDS/11, IDMS, DBMS-10 и DBMS-20. Все четыре конструкции наборов на рис. 6.9 не противоречат спецификациям КОДАСИЛ. Однако, если используемая СУБД не поддерживает все спецификации КОДАСИЛ, могут потребоваться некоторые модификации этой сетевой модели данных.
3. Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.
Логическая модель на рис. 6.9 удовлетворяет всем функциональным требованиям. Выясним теперь, можно ли улучшить эксплуатационные характеристики создаваемой базы данных, например объединить некоторые записи и за счет этого сократить число наборов, или, наоборот, из соображений обеспечения безопасности данных разнести их в большее число записей, одновременно увеличив число наборов, или внести другие структурные изменения.
В сетевой модели данных в отличие от большинства других моделей АБД должен указывать способы размещения записей. Выбор способа размещения существенно влияет на эксплуатационные характеристики базы данных. Например, экземпляры типа записи СЕМЕСТР + КУРС + СТУДЕНТ могут размещаться либо через набор ЗАЧЕТЫ-СТУДЕНТА, либо через набор ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ. Выбор может определяться тем, по какому пути доступ осуществляется быстрее. (Вне зависимости от того, через какой набор размещаются записи, доступ к ним может производиться через любой из двух наборов.)
Указанные проблемы эффективнее решаются на основе анализа количественных характеристик, например частот использования удельных наборов, средних чисел экземпляров каждого типа записей, длин записей. Поэтому окончательный выбор производится на стадии физического проектирования базы данных. Но уже на этапе логического проектирования можно принять некоторые решения, основываясь на перечисленных ниже «очевидных» соображениях, влияющих на эксплуатационные характеристики базы данных.
3.1. Не следует усложнять структуру.
Шаг 1.Можно удалить владельцев или членов набора, которые не содержат собственных данных. Вероятнее всего будут удалены «сгенерированные» записи. На рис. 6.9 запись-владелец в типе набора IV не содержит никаких данных кроме НОМ-КУРСА. Те же данные можно обнаружить в записи-члене СЕМЕСТР + КУРС. Оставлены следующие типы наборов:
Тип набора I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ,. член – СЕМЕСТР+КУРС+СТУДЕНТ.
Тип набора II –ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец–СЕМЕСТР+КУРС, член–СЕМЕСТР+КУРС+СТУДЕНТ.
Тип записи-члена СЕМЕСТР+КУРС+СТУДЕНТ осуществляет связь между типами наборов Iи II.
Тип набора III –КУРСЫ-СЕМЕСТРА: владелец–СЕМЕСТР, член –СЕМЕСТР+КУРС.
Шаг 2.Записи-владельцы, участвующие в этом качестве в небольшом числе типов наборов и содержащие только тривиальные данные, могут быть объединены с записями-членами, если их содержимое не слишком часто обновляется. СЕМЕСТР, владелец типа набора III (рис. 6.10), содержит только ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата окончания семестра) и участвует только в одном типе набора (рис. 6.10). Он вполне может быть объединен с членом данного набора СЕМЕСТР+ -1- КУРС. Полученная в результате модель показана на рис. 6.11. (В действительности даты начала и окончания семестра используются очень редко, и в базе данных их можно не хранить. Эти даты могут храниться в отдельных таблицах.) В типе набора 1 владельца СТУДЕНТ не следует объединять с членом СЕМЕСТР+КУРС+СТУДЕНТ. Тип записи СТУДЕНТ содержит важные сведения о студентах. Комбинированный тип записи из записей СЕМЕСТР и СЕМЕСТР+КУРС (рис. 6.11) также не следует объединять с членом типа набораIIСЕМЕСТР+КУРС+СТУДЕНТ.
Рис. 6.10
Модель, приведенная на рис. 6.11, содержит два типа набора:
Тип набора I – ЗАЧЕТЫ-СТУДЕНТА: владелец – СТУДЕНТ, член – СЕМЕСТР+КУРС+СТУДЕНТ.
Тип набора II– ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС, член – СЕМЕСТР+КУРС+СТУДЕНТ. Тип записи СЕМЕСТР+КУРС+СТУДЕНТ связывает типы наборовI и II.
Рис. 6.11
4. Упрощение имен ключей.
В конструкции набора могут иметь следующие имена ключей (см. левый рис. 6.12):
Рис. 6.12
Изъяв из имени ключа каждой записи-члена часть, входящую в состав ключа записи-владельца, .можно упростить ключи так, как показано на правом рис. 6.12.
После упрощения имен ключей логическая модель (рис. 6.11) приобретает вид, показанный на рис. 6.13. Здесь представлены два типа наборов:
Тип набора I–ЗАЧЕТЫ-СТУДЕНТА: владелец–СТУДЕНТ, член–СЕМЕСТР+ КУРС + СТУДЕНТ.
Тип набора II – ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ: владелец – СЕМЕСТР+КУРС, член – СЕМЕСТР+КУРС+СТУДЕНТ. Тип записи СЕМЕСТР+КУРС+СТУДЕНТ связывает типы наборовIи II.
5. Реализация взаимосвязей, которые не отражены в логической модели, но на самом деле существуют.
Вводить какие-либо новые взаимосвязи в представленную на рис. 6.11модель нет никакой необходимости.
Рис. 6.13
Таким образом, на рис. 6.13 получена улучшенная логическая модель, в которой из записи СЕМЕСТР+КУРС+СТУДЕНТ исключены элементы СЕМЕСТР, НОМ-КУРСА и НОМ-СТУДЕНТА (см. рис. 6.11).