Физическая организация данных
 Скачать 487.44 Kb.
|
|
Для реляционной БД на этом этапе определяются параметры распределения памяти для объектов БД, строятся индексы, определяется целесообразность использования хеширования и кластеризации. Фактически проектирование БД имеет итерационный характер. В процессе функционирования системы становится возможным измерение её реальных характеристик, выявление "узких" мест. И если система не отвечает предъявляемым к ней требованиям, то обычно она подвергается реорганизации, т.е. модификации первоначально созданного проекта.
Функциональное ядро систем автоматизированного проектирования (САПР) БД строится как совокупность взаимосвязанных модулей инфологического моделирования, проектирования схем и физической организации БД. Существующие в настоящее время САПР БД строятся как человеко машинные экспертные системы. В первую очередь это определяется слабо поддающимся формализации процессом синтеза инфологического описания ПО, т.е. преобразования неформальных представлений реального мира в формальные категории. Этот процесс выполняется экспертом - специалистом в той или иной ПО. Поэтому все проблемы, которые характерны для формирования базы знаний экспертной системы, возникают и в случае САПР БД. Характерной особенностью САПР БД является её ориентация на коллективное творчество и продолжительность самого процесса проектирования, предполагающего множество итераций. Это находит свое отражение в наличии журнала проектирования и других средств, обеспечивающих ведение и коллективное использование исходных данных, промежуточных и окончательных результатов проектирования. Общая структура САПР БД приведена на рис. 8.3.
I
Рис.8.3. Общая структура САПР БД В настоящее время создан ряд САПР БД, которые называются CASE- средствами. В качестве примеров таких систем можно привести ERWin, BPWin, Designer (Oracle) и др. Подробный обзор современных можно найти в [9].
Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности, которые в первую очередь касаются этапа логического проектирования. На этапе логического проектирования реляционной базы данных также необходимо решить следующие задачи:
Правила преобразование ER-диаграммы в схему БД следующие:
Рис. 8.4. Преобразование бинарной связи 1:n между сущностями разных типовх TEACHERS ПРЕПОДАВАТЕЛИ (Пре по дамгош) IDP экзамен овать СТУДЕНТЫ Е ХА MS (Экзамены) IDD «ракш .Its STUDENTS (Студенты) Каждая связь со степенью больше двух и связь, имеющая атрибуты, преобразуется в таблицу БД (рис. 8.5). Рис. 8.5. Преобразование связи с атрибутами
таблице СОТРУДНИКИ связи руководить, нужно добавить в неё поле Руководитель. Это поле будет внешним ключом, ссылающимся на первичный ключ этой же таблицы (рис. 2.9). Такой ключ позволяет отразить иерархию сотрудников, когда у каждого сотрудника может быть только один непосредственный руководитель, а у директора поле Руководитель будет неопределённым (null). Рис. 8.6. Преобразование бинарной связи 1:n между сущностями разных типов Бинарная связь типа n:m реализуется с помощью промежуточной таблицы. Например, для сущностей КНИГИ и АВТОРЫ и связи написать промежуточная таблица будет содержать два внешних ключа: идентификатор книги и идентификатор автора, написавшего эту книгу (рис. 8.6). В эту промежуточную таблицу также вносятся те атрибуты, которые характеризуют эту связь (например, номер автора в списке авторов этой книги). КЛЮЧЕВЫЕ СЛОВА K.EYW ORDS (Ключевые слова) ASSOS1ATIONS (Ассоциации) Унарная связь n:m реализуется с помощью промежуточной таблицы. Например, для отражения связи ассоциируется между терминами таблицы КЛЮЧЕВЫЕ СЛОВА, нужно добавить таблицу АССОЦИАЦИИ, в которой будут два внешних ключа на таблицу.КЛЮЧЕВЫЕ СЛОВА (рис. 8.6). Рис. 8.7. Преобразование унарной связи кардинальности n:m
К нереализуемым относятся связи кардинальностью 1:n или n:m, обяза тельные в обе стороны. Например, связь заказы-строки заказов: заказ не может быть пустым, и заказанный товар должен входить в определённый заказ. Т.е. нельзя добавить заказ, пока в нём нет ни одной строки, и нельзя добавить строку в несуществующий заказ. Эта проблема обычно решается так: связь делается необязательной со стороны первичного ключа, а внешний ключ остаётся обязательным. При этом в приложениинеобходимо предусмотреть правило обработки пустых заказов (например, их удаление). К необычным конструкциям данных можно отнести так называемые взаимоисключающие связи, когда подчинённая сущность связана с одной из двух родительских сущностей. Например, счёт в банке может принадлежать либо физическому лицу, либо юридическому, и не может принадлежать и тому, и другому либо не принадлежать никому. Такую связь можно реализовать по-разному, например, введением в таблицу счетов двух внешних ключей (номер_физ_лица и номер_юр_лица) и следующего ограничения целостности: (номер_физ_лица IS NULL AND номер_юр_лица IS NOT NULL) OR (номер_физ_лица IS NOT NULL AND номер_юр_лица IS NULL)
В принципе, можно создать таблицу и без первичного ключа. Но наличие у каждой таблицы первичного ключа - хороший стиль проектирования БД. Кроме того, если эта таблица является родительской для какой-либо другой таблицы, то определить первичный или уникальный ключ необходимо, чтобы можно было определить внешний ключ в подчинённой таблице. В качестве ПК следует брать тот уникальный атрибут сущности, по которому чаще всего происходит обращение к данным. Например, для БД налоговой инспекции это ИНН - индивидуальный номер налогоплательщика, а для БД ФОМС (фонда обязательного медицинского страхования) - номер медицинского полиса. Если у сущности нет уникальных атрибутов, можно рассмотреть уни кальные комбинации атрибутов. Но первичный ключ не должен быть длинным, т.к. ссылающийся на него внешний ключ будет занимать много памяти. Поэтому при отсутствии подходящих атрибутов нужно вводить суррогатный первичный ключ, который не несёт смысловой нагрузки и служит только для идентификации записей. (Некоторые СУБД позволяют определять значения такого ключа как AUTOINCREMENT, т.е. числовое поле, значение которого начинается с 1 автоматически увеличивается на 1 при добавлении новой записи).
Определение типов данных для полей таблиц зависит от требований ПО. Но можно дать следующие общие рекомендации по выбору типов данных: |