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

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

Существуют несколько типов даталогических моделей данных:

• сетевая модель;

• иерархическая модель;

• объектно-ориентированная модель;

• реляционная модель;

Необходимо выбрать один из приведённых выше типов и построить на основе инфологической модели, разработанной ранее, датологическую модель данной ИС. Также необходимо выбрать СУБД, в которой, впоследствии, будет реализована данная БД, т.к. даталогическая модель строится в терминах выбранной СУБД.

Рассмотрим подробнее каждый тип даталогической модели.

Сетевая модель

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

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

Особенности сетевой модели:

• База данных может состоять из произвольного количества записей и наборов различных типов.

• Связь между двумя записями может выражаться произвольным количеством наборов.

• В любом наборе может быть только один владелец.

• Тип записи может быть владельцем в одних типах наборов и членом в других типах наборов.

• Тип записи может не входить ни в какой тип наборов.

• Допускается добавление новой записи в качестве экземпляра владельца, если экземпляр-член отсутствует.

• При удалении записи-владельца удаляются соответствующие указатели на экземпляры-члены, но сами записи-члены не уничтожаются [11].

Иерархическая модель

Иерархическая модель – это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

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

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

Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента — это поименованная совокупность входящих в него типов полей данных.

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

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

Для информационной системы автошкола «АРГО» на основе проведенного системного анализа предметной области выделены следующие сущности:

1. Сотрудники: сущность содержит информацию о сотрудниках, работающих в организации;

2. Клиенты: сущность содержит информацию о клиентах, проходящих обучение;

3. Автомобили: сущность содержит информацию об автомобилях, используемых для занятий;

4. Курс: сущность содержит информацию о курсе, количестве занятий, стоимости и выбранном автомобиле;

5. Продажи: сущность содержит информацию о ID продаже, дате покупки, количестве купленных курсов, клиенте, сотруднике и дополнительных услугах;

6. Группа: сущность содержит информацию о курсе, дополнительных услугах и сотруднике, который ведет группу;

7. Дополнительные услуги: сущность содержит информацию об услугах, которые могут быть оказаны клиенту.

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

Рис. 5. Инфологическая модель базы данных

К основным недостаткам иерархических моделей следует отнести:

• неэффективность, медленный доступ к сегментам данных нижних уровней иерархии;

• четкая ориентация на определенные типы запросов и др;

• громоздкость для обработки информации с достаточно сложными логическими связями;

• сложность понимания для обычного пользователя.

Иерархические модели быстро прошли пик популярности, которая обусловливалась их ранним появлением на рынке. Затем их недостатки сделали их неконкурентоспособными, и в настоящее время иерархическая модель представляет исключительно исторический интерес [12].

Объектно-ориентированная модель

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

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

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

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

Реляционная модель

Реляционная модель данных – логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка. В ней достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation - "отношение").

В реляционной модели данных применяются разделы реляционной алгебры, откуда и была заимствована соответствующая терминология. В реляционной алгебре поименованный столбец отношения называется атрибутом, а множество всех возможных значений конкретного атрибута – доменом. Строки таблицы со значениями разных атрибутов называют кортежами. Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). Так ключевое поле – это такое поле, значения которого в данной таблице не повторяется. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Сложный ключ выбирается в тех случаях, когда ни одно поле таблицы однозначно не определяет запись.

Достоинства реляционной модели заключаются в:

• Изложение информации в простой и понятной для пользователя форме (таблица).

• Реляционная модель данных основана на строгом математическом аппарате, что позволяет лаконично описывать необходимые операции над данными.

• Независимость данных от изменения в прикладной программе при изменении.

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

• Для работы с моделью данных нет необходимости полностью знать организацию БД.

К недостаткам относятся:

• Относительно медленный доступ к данным.

• Трудность в создании БД основанной на реляционной модели.

• Трудность в переводе в таблицу сложных отношений.

• Требуется относительно большой объем памяти.

2.3. Даталогическое проектирование бд

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

• отсутствие дублируемой информации;

• поддержание целостности данных при вставке, удалении или изменении записей;

• возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.

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

В реляционных базах данных (РБД) даталогическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, адекватно моделирующих объекты ПО и семантических связей между ними.

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

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

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• Декомпозиция (разбиение);

• Синтез;

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

1. каждой сущности ставится в соответствие отношение;

2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;

3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);

4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);

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

6. для отражения категоризации сущностей возможны несколько вариантов;

7. все связи М:М должны быть раскрыты;

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

Автомобили:

• Код автомобиля – int NOT NULL PK

• Марка – varchar(20) NOT NULL

• Модель – varchar(20) NOT NULL

• Цвет – varchar(20) NOT NULL

• Номер – int NOT NULL

• Год выпуска – int NOT NULL

Курс:

• Код курса – int NOT NULL PK

• Количество занятий – int NOT NULL

• Цена – int NOT NULL

• Код автомобиля – int NOT NULL FK

Сотрудники:

• Код сотрудника – int NOT NULL PK

• ФИО – varchar(50) NOT NULL

• Должность – varchar(30) NOT NULL

• Дата рождения – date NOT NULL

• Паспортные данные – varchar(10) NOT NULL

• Телефон – int NOT NULL

• Адрес – varchar(50) NOT NULL

• Дата приёма на рабату – date NOT NULL