Обоснование выбора моделей данных

 

Различают сетевую, иерархическую и реляционную модели данных. Каждая из них имеет свои преимущества и свои недостатки. Ниже мы рассмотрим подробно эти модели данных.

1. Иерархическая модель данных

В иерархической модели связи между данными описывают с помощью упорядоченного графа (или дерева). Тип является составным. Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево». Каждый из элементарных типов, включенных в тип «дерево», является простым или составным типом «запись».

Таким образом, иерархическая модель данных представляет собой упорядоченную совокупность экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).

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

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

2. Сетевая модель данных

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

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

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

3. Реляционная модель данных

Предпочтение было отдано реляционной модели по следующим причинам:

- реляционная модель является более простой моделью, чем сетевая;

- схема данных позволяет представить структуру в виде таблиц (после некоторых преобразований);

- в настоящее время реляционные базы данных являются более распространенными, чем сетевые;

- использование реляционных баз данных удобнее, чем сетевых;

- сетевая модель данных сложна для изучения пользователем, проще разобраться с реляционной моделью данных;

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

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

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию систем баз данных: «нисходящий» и «восходящий».

В основу проектирования структуры БД был положен нисходящий метод проектирования. Данный метод предоставляет конструктивно более правильный подход к решению задачи проектирования базы данных. Непосредственная связь классов объектов с предметной областью позволяет построить более логичную структуру классов объектов и связей между ними. Нисходящий метод формализован и поддерживается множеством CASE-средств.

По сравнению с восходящим методом нисходящий обладает рядом неоспоримых преимуществ, что позволяет говорить о приоритетности его использования.

На первом этапе на основе анализа предметной области получают описание внешнего уровня БД, являющееся исходными данными для второго этапа.

Следующий этап – разработка инфологической модели предметной области. На этом этапе по полученному на предыдущем этапе описанию строится модель данных использующая модель «сущность-связь» («объект-отношение»).

Далее следует формирование даталогической модели БД. Результатом этого этапа является даталогическая модель, построенная на основе реляционной модели данных.

Следующий этап является опциональным и представляет собой нормализацию полученной модели.

На заключительном этапе проектирования строится физическая модель данных с учетом особенностей используемой СУБД. Результатом является физическая модель.

Разработанная инфологическая модель представлена в пункте 2.2.1 в виде ER-диаграммы, построенной по методологии Ричарда Баркера.