Процедура проектирования даталогической модели БД

Под даталогической понимается модель, отражающая логические взаимосвязи м/у элементами дан-х безотносительно их содержания и физ-ой организации. При этом даталог-ая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфол-ой модели. Датал-ая модель явл-тся моделью логического уровня и представляет собой отображение логических связей м/у элементами дан-х безотносительно к их содержанию и среде хранения. Конечным результатом даталогического проектирования является описание структуры БД на языке описания данных конкретных СУБД. Процесс проектирования БД начинается с исследования предметной области и построения инфол-ой модели дан-х, (- это неформальное описание создаваемой БД, выполненное с использованием естественного языка, матем-ких формул, таблиц, графиков и др. средств, понятных всем людям, работающих над проектированием БД; отражает предметную область в виде совок-ти инф-ых объектов и их стр-рных связей.). Затем необходимо выполнить след. шаги процедуры проектирования даталог-ой модели: (1) Представить каждый стержень (независимую сущность) таблицей БД (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы. (2) Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей. (3) Представить каждую хар-ку как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой хар-кой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого внешнего ключа и св-ва, к-ое гарантирует "уникальность в рамках описываемой сущности". (4) Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения. (5) Представить каждое свойство как поле в базовой таблице, представляющей сущность, к-ая непосредственно описывается этим св-вом. (6) Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить процедуру нормализации. (7) Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфол-ую модель БД и повторить перечисленные шаги. (8) Указать ограничения целостности проектируемой БД и дать (если это необходимо) краткое описание полученных таблиц и их полей.

На рис. показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений.

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