Выбор модели данных

Большое количество разработанных к настоящему времени раз­нообразных СУБД связано с существованием различных моделей данных. Проектировщик банка данных, выбирая для своей системы конкретную СУБД общего назначения, прежде всего сталкивается с задачей выбора наиболее подходящей модели данных для своей прикладной области. Проектировщик оценивает возможности рас­сматриваемой модели данных с точки зрения «прямого» модели­рования понятий, сформулированных в инфологической модели ПО только такими структурами данных, которые составляют по­нятийный базис данной модели.

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

1) «атрибут сущности» (моделируется полем, значение атрибу­та -значением поля);

2) «тип сущности» (моделируется типом записи). Например, тип сущности СЛУЖАЩИЙ, описываемый атрибутами ТАБЕЛЬ­НЫЙ-НОМЕР, ФАМИЛИЯ, ГОД-РОЖДЕНИЯ и ОБРАЗО­ВАНИЕ, можно смоделировать типом записи СЛУЖАЩИЙ со следующей схемой записи: СЛУЖАЩИЙ (ТАБЕЛЬНЫЙ-НО­МЕР, ФАМИЛИЯ, ГОД-РОЖДЕНИЯ, ОБРАЗОВАНИЕ).

3) «экземпляр сущности» (моделируется экземпляром за­писи);

4) «набор экземпляров сущностей одного типа» (моделируется одним файлом). Например, файл СЛУЖАЩИЕ, представляет собой совокупность экземпляров записей типа СЛУЖАЩИЙ.

В рассмотренном примере нельзя выполнить прямое модели­рование связей между сущностями. Однако это не означает, что связи вообще нельзя смоделировать с помощью структур, допу­скаемых используемой моделью данных. Отсутствие в МД пря­мого двойника для рассматриваемого понятия означает, что придется моделировать косвенным образом, используя допускаемые моделью типы структур данных.

В развитых моделях данных число косвенных путей моделирования существенно возрастает.

Чем большее количество конструкции инфологической модели ПО можно представить прямым моделированием при датологическом проектировании БД, тем более удачной считается рассмат­риваемая МД для данного приложения.

Кроме анализа возможностей прямого моделирования проекти­ровщик оценивает следующие свойства модели данных СУБД:

1) сложность и трудоемкость написания определений данных и программ для манипулирования структурами данных;

2) сложность модели для изучения пользователями;

3) простоту и элегантность, т. е. модель должна иметь мини­мальное число типов базисных структур и правил композиции;

4. наглядность представления структуры данных и др.

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