Проектирование базы данных на концептуальном уровне

Основные понятия

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

Сущности – личности, факты, объекты реального мира, имеющие отношение к некоторой проблемной области.

Атрибуты – данные, описывающие сущности.

Связи – взаимодействия между несколькими сущностями; связь может иметь атрибуты.

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

Концептуальная схема – графическое представление концептуальной модели.

Задачи моделирования данных

Цель построения модели: документирование требований к данным со стороны бизнес – процессов.

Назначение модели: основа для создания физической базы данных.

Преимущества правильно спроектированной базы:

1) минимальная избыточность данных;

2) максимальная целостность данных;

3) стабильность структуры БД;

4) эффективное совместное использование данных;

5) своевременность доступа к данным;

6) удобство и простота использования данных;

7) возможность разработки новых приложений без изменения структуры данных и др.

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

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

Сущности

Сущность – это человек, место, предмет, понятие или событие, то есть то, что существует и что можно описать. Например: Студент, Преподаватель, Дисциплина, Заказчик, Товар и т.д.

Как выявить сущности?

Информация о сущностях используется в описании бизнес – процессов организации и представлена, как правило, именами существительными. Например: "обучение студентов", "продажа товаров" и т.п.

С чего начать?

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

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

Требования к имени сущности: имена должны быть стандартными, хорошо определенными и постоянными.

Правило задания имени сущности: имя сущности должно быть существительным в единственном числе, допускается сочетание с прилагательным. Желательно записывать имя заглавными буквами, например, СТУДЕНТ.

Проблема выбора имени: наличие синонимов, используемых разными категориями пользователей, например, СТУДЕНТ, УЧАЩИЙСЯ, ОБУЧАЕМЫЙ.

Решение проблемы: выбрать наиболее популярное название или принять волевое решение по этому поводу. Выбранное название должно быть единственным в базе данных.

При проектировании базы данных необходимо различать понятия "Сущность" и "Экземпляр сущности". Так, сущность СТУДЕНТ – это абстрактное понятие, а Иванов – это экземпляр сущности СТУДЕНТ.

Атрибуты

Атрибут – это характеристика или свойство сущности.

Можно выделить следующие разновидности атрибутов:

1) идентифицирующие, то есть те, которые позволяют отличить один экземпляр сущности от другого, например, № студенческого билета; такие атрибуты являются потенциальными ключами сущности и должны быть неизменными;

2) связывающие, то есть те, которые позволяют создать связи между сущностями;

3) описывающие, то есть те, которые не относятся к первым двум разновидностям, например, Дата рождения.

 

Не существует точного правила, позволяющего отличить атрибут от сущности и наоборот.

Можно использовать следующие рекомендации:

1) на основании знания бизнес – процессов выявить роли атрибутов (идентификация, связывание, описание);

2) экземпляры атрибутов, как правило, элементарны по своей природе, то есть атрибут представляет собой единичный факт, который в бизнес – процессах не раскладывается на составные части; например, ФИО как атрибут сущности СТУДЕНТ является не лучшим решением, т.к. раскладывается на составные части, которые в бизнес – процессах могут рассматриваются отдельно, например, поздравление всех Татьян с Татьяниным днем.

Соглашения для имен атрибутов могут быть разными в разных организациях, например, ИмяСтудента или имя_студента и т.п.

Существуют общепринятые сокращения для имен атрибутов, например, ID - идентификатор или ADDR – адрес и т.д.

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

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

- указание типа данных;

- тип данных и диапазон;

- использование классификаторов и кодификаторов;

- список допустимых значений и т.д.

Для каждого атрибутанеобходимо оценить возможность принимать неизвестное значение (NULL - значение). Например, сущность СТУДЕНТ, атрибут ЦветВолос. Как задать значение этого атрибута для студентки с неизвестным цветом волос или для лысого студента?

Ключи

Ключ состоит из одного или более атрибутов, значения которых однозначно идентифицируют экземпляр сущности, например, №Паспорта – ключ личности, по нему один экземпляр сущности ЛИЧНОСТЬ отличается от другого экземпляра.

Каждая сущность может иметь несколько ключей, но должна иметь по крайней мере один ключ. Такие ключи называются потенциальными ключами.

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

Критерии выбора первичного ключа:

- ключ должен гарантировать уникальность каждого экземпляра сущности;

- атрибуты, входящие в первичный ключ, не могут принимать NULL – значения;

- ключ должен быть неизменным, то есть неспособным и невосприимчивым к изменениям;

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

Например, сущность СЛУЖАЩИЙ. Атрибут №Паспорта является плохим кандидатом на роль первичного ключа, так как его значение зависит от внешних организаций и может быть изменено ими. Его значения находятся вне зоны внутреннего контроля. Лучшим решением является ТабельныйНомер, т.к. его значение присваивается внутри организации.

Связи

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

Типы связей:

1) унарные или рекурсивные – это связи между экземплярами одной и той же сущности, например, связь "подчиняться" моделирующая отношение "руководитель - подчиненный" на экземплярах сущности РАБОТАЮЩИЙ;

2) бинарные – это связи между двумя сущностями, например, связь "изучает" между сущностями СТУДЕНТ и ДИСЦИПЛИНА;

3) n – арные – это связи между более, чем двумя, сущностями, например, связь "обучает" между сущностями СТУДЕНТ, ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА.

 

Унарные и бинарные связи характеризуются мощностью и обязательностью. Характеристики задаются на каждом конце связи.

Мощность – это количество экземпляров сущности участвующих в каждом конкретном экземпляре связи.

В зависимости от мощности различают следующие виды связей:

1) " один – к - одному ", например, связь "имеет" между сущностями СТУДЕНТ и МЕДИЦИНСКАЯ_КАРТА при условии, что учитываются только карты в конкретной поликлинике;

2) " один – ко многим ", например, связь "состоит из" между сущностями СТУДЕНТ и ГРУППА при условии, что в базе будет храниться информация только об одной группе, в которой обучается студент;

3) "многие – ко многим", например, связь "изучает" между сущностями СТУДЕНТ и ДИСЦИПЛИНА.

Обязательность – определяет обязательность наличия связи для каждого экземпляра сущности. Если существуют экземпляры сущности, для которых связь не задается, то для данной сущности связь является частичной. В противном случае, связь называется обязательной или всюду определенной. Например, связь "состоит из" для сущности ГРУППА является обязательной, т.к. группа состоит хотя бы из одного студента и для каждой конкретной группы такая связь существует. Для сущности СТУДЕНТ данная связь является частичной, т.к. существуют студенты, которые находятся в академическом отпуске и не могут быть приписаны к какой – либо группе.

Для связей также существуют соглашения по присваиванию имен.

Имя связи обычно задается глаголом. Для связи "многие – ко - многим" рекомендуется указывать два имени, например, СТУДЕНТ "изучает" ДИСЦИПЛИНУ и ДИСЦИПЛИНА "изучается" СТУДЕНТОМ, то есть связь именуется "изучает / изучается".

Классы и подклассы

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