Лекция 14 Даталогиечекское проектирование Общие сведения о даталогическом проектировании

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

Классификация СУБД:

• по числу уровней в архитектуре: одноуровневые, двух– и трехуровневые системы. Подразумевается некоторый уровень абстракции данных. Логические и физические уровни поддерживаются СУБД всегда, а внешний уровень может отсутствовать;

• по выполняемым функциям: информационные и операционные СУБД. Первые позволяют организовать хранение информации и доступ к ней. Для выполнения более сложной обработки необходимо написание специальных программ. Операционные СУБД выполняют достаточно сложную обработку без специальных программ;

• по сфере возможного применения: универсальные, специализированные (проблемно-ориентированные). СУБД поддерживают разные типы данных. Некоторые СУБД позволяют разработчику добавлять новые типы данных и операции над ними. Такие СУБД называются расширяемыми. Новым направлением являются генераторы баз данных, когда разработчик может строить свою СУБД нового типа из программных кодов.

• Конечной целью даталогического проектирования является описание логической структуры базы данных. Спроектировать логическую структуру базы данных – это значит:

1. определить все информационные единицы: тип, длина поля и др.;

2. определить связи между ними;

3. задать их имена.

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

• для любой инфологической области можно построить множество различных моделей, т.е. для любой предметной области и соответствующей ей инфологической модели существует множество проектных вариантов ее отображения в даталогическую модель. Например, связи между сущностями в инфологической модели могут отображаться в даталогической модели либо путем совместного расположения, либо путем объявления связи между ними;

• не все виды связей, существующие в предметной области могут быть непосредственно отображены в конкретной даталогической модели. Например, многие СУБД не поддерживают непосредственно связь многие ко многим (М : М), обычно в этом случая связь разбивается на 2 отношения один ко многим (1 : М);

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

• характер обработки информации оказывает влияние на проектное решение по структуре базы данных. Так, рекомендуется хранить вместе информацию, часто обрабатываемую совместно. Информацию, которая обрабатывается часто и которая используется редко следует помещать в разные файлы;

• существуют разные подходы к определению состава показателей, которые должны храниться в базе данных:

1. должны храниться только исходные данные (простота и однозначность принятия решения, отсутствие дублирования информации и меньший объем занимаемой памяти);

2. должны храниться и расчетные показатели.

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

Все шаги проектирования даталогической модели выполняются итеративно.