Отображение на иерархическую модель данных

Отображение на реляционную модель данных

Проектирование логической модели данных. Отображение на иерархическую модель данных. Отображение на сетевую модель данных. Отображение на реляционную модель данных.

Реляционная модель данных состоит из ряда отношений (таблиц). При отображении концептуальной модели, на логическую модель необходимо определить отношения и их атрибуты. Отдельные атрибуты этих отношений являются их первичными ключами.

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

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

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

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

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

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

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

1.1Устранение транзитивности.

В концептуальной модели имеется транзитивная зависимость, если удаление взаимосвязи между А и С не приводит к потере информации.

1.2Выявление взаимосвязей типа «исходный-порожденный».

1.3Устранение множественного родительства.

1.4Оба исходных узла являются отношениями в третьей нормальной форме и не были созданы искусственно.

Узлы Х и Y - исходные, а Z —порожденный. Здесь возможны два варианта выбора исходного узла. Либо Х принимается за исходный узел, а Y и Z объединяются и становятся порожденным узлом, либо Y принимается за исходный, а X и Z объединяются. И в том, и в другом случаях возникает избыточность данных. Поэтому, следует решить, всегда ли необходимо наличие двух исходных узлов или же ценой введения избыточности можно объединить один из предполагаемых исходных узлов с порожденным. Существует и третий вариант - объединить исходные и порожденный в один узел, например X, Y и Z.

Один из исходных узлов — истинное отношение в третьей нормальной форме, а другой образован искусственно

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

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

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

5. Имена ключей порожденных сегментов можно упростить, удалив те части имени, которые встречаются в имени исходного сегмента. В иерархии ключ физически порожденного сегмента косвенно подразумевает ключ исходного.

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

Дата добавления: 2015-05-09