книги / Структурный подход к организации баз данных

рованы» и являются исходными. Порожденный узел — 2. Можно объе­ динить X, V и 2 в один новый тип узла. Поскольку и X, и V удаляются, можно переместить объединенный узел, X, V и 2, на более высокий уро­ вень иерархии, как это показано на рис. 6.106.

ется, что обязательно наличие двух исходных узлов, следует использовать СУБД, поддерживающую несколько исходных узлов. Узел СЕМЕСТР + КУРС имеет два исходных узла. Допустим, что мы принимаем решение остановиться на логической модели, показанной на рис. 6.10.

Этапы преобразования в п. А.3.1—А.3.3 можно последовательно при­ менять к узлам, расположенным на нижних уровнях: рассматриваются исходные узлы второго уровня и порожденные третьего и т. д.

Теперь можно учесть ограничения, которые накладывает используе­ мая СУБД.

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

Иерархическую модель данных поддерживает целый ряд СУБД. Одна из них — система 1М5, поставляемая фирмой 1ВМ. Эта система поддерживает и некбторые сетевые структуры. Использование системы 1М5 накладывает следующие ограничения на модель данных:

1.Возможно существование не более 255 типов узлов, которые в си­ стеме 1М5 называются «типами сегментов».

2.Допускается не более 15 уровней иерархии.

3.Порожденный сегмент может иметь максимум два исходных сег­ мента (Система 1М5 более подробно рассматривается в гл. 8). Один из исходных сегментов, в иерархии которого находится порожденный, назы­ вается «физически исходным». Другой исходный называется «логически исходным». На рис. 6.10в X — физически исходный сегмент, У — логиче­ ски исходный, а 2 — логически порожденный. На логически порожденные сегменты накладывается следующее ограничение.

4.Логически порожденный не может иметь логически порожденного. На рис. 6.10в, г узел 2, являясь логически порожденным, не может иметь физически порожденного М, логически исходный которого — Ы, как это показано на рис. 6.10в. 2 не может иметь логически порожденного М, физически исходным которого является N (рис. 6.Юг).

Рис. 6.10в. Первое иерархическое деревб образовано узлами X, 2 и М. Второе — узлами V Ы Р. Для узла 2 X является физически исходным, т. е. 2 логически порожденный. Узел М не может быть ло­ гически порожденным и, следовательно, не может иметь два исходных 2 и N. Узел 2 — логически порожденный и не может иметь физически порожденным М, у ко­ торого исходный N

Рис. 6.10г. Первое иерархическое дерево образовано узлами X и 2, второе — уз­ лами У N. К и М. Для узла 2 X — физи­ чески исходный, а У — логически исход­ ный, т. е. 2 является логически порож­ денным. Узел М не может быть логиче­ ски порожденным и, следовательно, иметь два исходных узла N и 2. Узел 2, будучи логически порожденным, не может иметь логически порожденным узел М

Ни одно из перечисленных ограничений на рис. 6,10 не нарушено. Поэтому никаких трансформаций логической модели не требуется. Эта модель может быть реализована в системе 1М5. Единственный вопрос, который остается решить, касается расположения логически порож­ денного сегмента СЕМЕСТР + КУРС + СТУДЕНТ. Последний может быть физически порожденным либо сегмента СЕМЕСТР, либо сегмента СЕМЕСТР + КУРС.

В. Модификация трансформированной модели данных с учетом «оче­ видных» соображений, влияющих на эффективность обработки.

До сих пор мы имели дело с представлением, показанным на рис. 6.11, которое аналогично приведенному на рис. 6.10. Это пред­ ставление гарантирует выполнение всех необходимых требований обра­

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

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

Рис. 6.11. Логическая модель, состоящая из двух иерархических деревьев, которая является отобра­ жением концептуальной модели, представленной на рис. 6.1

рования можно принять в этой части ряд решений, основанных на «очевидных» соображениях.

В.1. Исходный сегмент, обладающий только одним порожденным типом сегмента, может с ним объединяться.

рис. 6.11 у сегмента СЕМЕСТР только один порожденный СЕ­ МЕСТР + КУРС. Необходимо сделать выбор между требованиями повы­ шения производительности и уменьшения избыточности данных. В сегмен­ те СЕМЕСТР всего два поля: ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата окончания семестра). Если принять сегмент СЕМЕСТР в качестве исходного для сегмента СЕМЕСТР + КУРС, то для каждого семестра останется лишь один экземпляр сегмента СЕМЕСТР, т. е. даты его начала и окончания будут запоминаться в течение семестра всего один раз. Но при этом должен храниться по крайней мере один указатель на первый принадлежащий данному семестру экземпляр курса. Кроме того, хранятся указатели, связывающие экземпляры семестров. Следует рассмотреть время, затрачиваемое на обновление указателей и на доступ к отдельным сегментам СЕМЕСТР и СЕМЕСТР + КУРС.

Одно из решений состоит в объединении сегментов СЕМЕСТР и СЕМЕСТР + КУРС, как это показано на рис. 6.12, что порождает избыточ­ ность по значениям ДНАЧСЕМ (дата начала семестра) и ДКОНСЕМ (дата окончания семестра). Если в данном семестре читается 50 различных курсов, им соответствует 50 экземпляров сегмента СЕМЕСТР + КУРС,

СЕМЕСТР+ \ 1КУРС+

________ <' СТУДЕНТ СЕМЕСТР НОМ-КУРСА НОМ-СТУДЕНТА

ЗАЧЕТЫ (Отношение 7 )

Рис. 6.12. Логическая модель, состоящая из двух иерар­ хических деревьев. Модификация модели, представлен­ ной на рис. 6.11

в каждом из которых для каждого курса хранятся поля ДНАЧСЕМ и ДКОНСЕМ. Избыточность данных, приводит к увеличению требуемых объемов памяти. Более серьезную проблему может представлять обеспе­ чение целостности избыточно хранимых данных. Основным вопросом, ко­ торый следует рассматривать при введении избыточности, является часто­ та обновления данных. Часто обновляемые данные должны храниться

сминимальной избыточностью. В нашем примере дата начала семестра

идата его окончания в течение семестра не изменяются. Обновление этих значений происходит достаточно редко. Поэтому интуитивно пред­ ставляется вполне оправданным объединить сегмент СЕМЕСТР и его порожденный сегмент СЕМЕСТР + КУРС.

Мы решили, что сегмент СЕМЕСТР + КУРС + СТУДЕНТ будет для сегмента СТУДЕНТ физически порожденным, а для сегмента СЕМЕСТР +

+КУРС — логически порожденным.

В.2. Следует ли сохранить логическую взаимосвязь или объединить логически исходный и логически порожденный сегменты?

На рис. 6.12 логически исходный сегмент СЕМЕСТР + КУРС имеет ло­ гически порожденный СЕМЕСТР + КУРС + СТУДЕНТ. В системе 1М5 с каждого корневого сегмента начинается новая база данных. Мы имеем два иерархических дерева и соответственно две базы данных. Всякий раз, когда прикладной программе потребуются сведения о курсах, которые изучает какой-либо студент, система 1М5 должна осуществить доступ к двум различным базам данных: базе данных СТУДЕНТ и базе данных СЕМЕСТР и КУРС. Если объединить логически порожденный сегмент СЕМЕСТР + КУРС + СТУДЕНТ с логически исходным — СЕМЕСТР +

На рис. 6.12 единственный сегмент, в котором можно упростить ключ, — это СЕМЕСТР + КУРС + СТУДЕНТ — логически порожденный цегмент. Он связывает исходные сегменты, принадлежащие различным Иерархическим путям. Нам приходится использовать составной ключ с ат­ рибутами СЕМЕСТР, НОМ-КУРСА и НОМ-СТУДЕНТА.

Д. Реализация взаимосвязей, не отраженных в логической модели, но, на самом деле, существующих.

Усовершенствованная логическая модели, представленная на рис: 6.12, удовлетворяет функциональным требованиям и обеспечивает, очевидно, более высокую производительность, чем первоначальная концеп­ туальная модель, показанная на рис. 6.1. На этом можно было бы считать логическое конструирование, включающее отображение в иерархическую модель данных, завершенным. Однако проектировщик может пожелать его продолжить и добавить ряд внутренних (скрытых) взаимосвязей, существующих между данными. Речь идет о реально существующих взаимосвязях, определяемых организационными или физическими харак­ теристиками моделируемой предметной области, но явно не сформулиро­ ванных в концептуальных требованиях. Основная причина реализации упомянутой взаимосвязи состоит в том, что база данных должна обеспе­ чивать получение ответов на произвольные запросы и легко адаптировать­ ся для будущих применений.

Логическая модель, представленная на рис. 6.12, не нуждается в ка­ ких-либо изменениях.

Логическая модель данных для системы 1М5 может выглядеть так, как это показано на рис. 6.12. Внешняя модель, позволяющая подготав­ ливать расписания занятий, которые вручаются каждому студенту в нача­ ле семестра, представлена на рис. 6.14.

6.3. ОТОБРАЖЕНИЕ НА СЕТЕВУЮ МОДЕЛЬ ДАННЫХ

Отображение концептуальной модели на сетевую модель данных пред­ ставляет собой сложный процесс. Здесь также имеется ряд альтернатив, нет очевидного наилучшего решения и требуется выполнение следующих основных этапов:

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

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

B. Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.

Г. Упрощение имен ключей.

Д. Реализация взаимосвязей, не отраженных в логической модели, но на самом деле существующих.

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

А.1. Определение взаимосвязей «владелец— член»

В концептуальной модели прямоугольники представляют типы запи­ сей, а стрелки (ч->) — связи между ними. При обсуждении сетевой модели

ется достаточно просто. Полученная в результате сетевая модель (рис. 6.15) не предполагает использования какой-либо конкретной СУБД.

A. 2. Устранение множественного владения

Из § 4.5 мы знаем, что член набора не может иметь более одного вла­

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

Целый ряд СУБД базируется на использовании спецификаций РГБД КОДАСИЛ, например системы Ш 5/П корпорации НопеумгеИ, ШМ5 корпорации СиШпапе, ОВМ5-Ю и ОВМ5-20 корпорации ОЕС и ОМ5 1100 корпорации Цп^уас. Все четыре конструкции наборов на рис. 6.15 не противоречат спецификациям РГБД КОДАСИЛ. Однако, если используемая СУБД не поддерживает все спецификации РГБД КОДАСИЛ, могут потребоваться некоторые модификации этой сетевой модели данных.

B. Модификация трансформированной модели с учетом «очевидных» соображений, влияющих на производительность.

Логическая модель на рис. 6.15 удовлетворяет всем функциональным требованиям. Выясним теперь, можно ли улучшить эксплуатационные ха­ рактеристики создаваемой базы данных, например объединить некоторые записи и за счет этого сократить число наборов, или, наоборот, из сообра­ жений обеспечения безопасности данных разнести их в большее число записей, одновременно увеличив число наборов, или внести другие структурные изменения.

В сетевой модели данных в отличие от большинства других моделей АБД должен указывать способы размещения записей. Выбор способа размещения существенно влияет на эксплуатационные характеристики ба­ зы данных. Например, экземпляры типа записи СЕМЕСТР + КУРС + СТУ­ ДЕНТ могут размещаться либо через набор ЗАЧЕТЫ-СТУДЕНТА, либо через набор ЗАЧЕТЫ-ПО-КУРСУ-В-СЕМЕСТРЕ. Выбор может опреде­ ляться тем, по какому пути доступ осуществляется быстрее. (Вне зависи­ мости от того, через какой набор размещаются записи, доступ к ним может производиться через любой из двух наборов.) В гл. 8 эти вопросы рассмат­ риваются подробнее.

Указанные проблемы эффективнее решаются на основе анализа коли­ чественных характеристик, например частот использования удельных на­ боров, средних чисел экземпляров каждого типа записей, длин записей. Поэтому окончательный выбор производится на стадии физического проек­ тирования базы данных. Но уже на этапе логического проектирования можно принять некоторые решения, основываясь на перечисленных ниже

«очевидных» соображениях, влияющих на эксплуатационные характери­ стики базы данных.

В.1. Не следует усложнять структуру

Ш аг 1. Можно удалить владельцев или членов набора, которые не содержат собственных данных. Вероятнее всего будут удалены «сгене­ рированные» записи. На рис. 6.15 запись-владелец в типе набора IV не