Модель данных

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

Сущность - это то, о чем нужно хранить информацию в базе данных.

При проектировании баз данных достаточно описать происходящую ситуацию - и большинство существительных и часть глаголов будут кандидатами на сущности. Например: "Покупатели покупают товары. Сотрудники продают товары покупателям. Поставщики поставляют товары" - покупатели, товары, сотрудники и поставщики - это сущности. Глаголы "покупать" и "продавать" - тоже сущности (хотя могут быть и одной сущностью, разной с точки зрения покупателя и продавца). При проектировании БД главный источник информации о сущностях - это беседа с заказчиком в целях уяснения его бизнес-процессов. Кроме того, анализируются стандартные документы, используемые в бизнес-процессах: бланки, отчеты, инструкции и т.п. После получения такого списка необходимо проверить его на полноту и связность, а также выявить дубли - одинаковые сущности, которые называются разными словами, и сущности, которые на самом деле отличаются, но описываются один и ем же термином. Сущности могут моделировать конкретные понятия (клиенты, товары, звонки) и абстрактные (агент отвечает за клиента, студент записан на курс).

Записи об определенных параметрах каждой из сущностей называются атрибутами. Например, для сущности "заказчик", видимо, будет храниться информация об его наименовании, представителях, адресе и т.п. Выбор нужного комплекта атрибутов - одна из самых больших проблем при проектировании баз данных. Очень часто в реальной базе данных нужный комплект атрибутов в итоге не хранится - просто по той причине, что пользователи не смогли сообщить в процессе сбора информации, что он действительно нужен. Иногда в базе, наоборот, попадают лишние атрибуты, заполнение которых требует дополнительного времени. Очень часто возникает проблема с форматом вводимых данных, например, на какие части делить адрес и что делать с нестандартными случаями. Общее правило при выборе набора атрибутов: нужно начинать с результата и стараться упрощать модель, а не усложнять ее. Первое, на что нужно ответить - на какие вопросы пользователей должны отвечать ваша база данных? Далее - обеспечиваем системе гибкость. Потребности пользователей могут изменяться, им потребуется дополнительная функциональность, возникнут исключения и т.п. Обычно достижение большей гибкости производится за счет усложнения базы данных (и системы ввода информации), но чем более сложна система, тем тяжелее с ней работать пользователям.

Домен - это "вид" данных, которые может содержать данный атрибут. Более четкое определение - это набор всех допустимых значений, которые может содержать данный атрибут. Понятие "домен" не следует путать с понятием "тип данных". Тип данных - это физическое понятие (которое реализовано средствами СУБД), а домен - логическое понятие. Например, для пола обычно используется текстовое поле длиной 1 символ или 3 символа (на уровне типа данных), в то же время на уровне домена - это только два возможных значения. Непосредственно в СУБД механизмов, которые бы представляли домен, нет. Обычно понятие домена используется для обеспечения так называемой доменной целостности данных, например, когда введенное пользователем значений проверяется на соответствий указанному набору значений.

В реальных СУБД модель данных, кроме атрибутов каждой сущности определяет также связи между сущностями. Связи формально определяются как ассоциации между участниками. Например, утверждение "покупатели покупают продукты" указывает, что существует связь между сущностью "покупатели" и сущностью "продукты". Число участников определяет размерность связи. У большей части отношений - два участника, хотя на практике их может быть и больше, например, в утверждении: "сотрудники продают товары покупателям" видна тройная связь. Иногда сущность оказывается связана сама с собой. Обычно подобные связи характерны для иерархических структур, когда сотрудник может подчиняться менеджеру и одновременно являться менеджером для других сотрудников. Существует несколько типов связей между сущностями: "один к одному", "один ко многим" и "многие ко многим".

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

Связь "один ко многим" - наиболее распространенный тип связей. Например, один торговый агент может выписывать много счетов и т.п.

Очень часто используется и связь "многие ко многим". Например, один покупатель может покупать товары нескольких видов, и при этом товар одного вида может "покупаться" разными покупателями. Обычно в СУБД возможности явно определить отношение "многие-ко-многим" нельзя, но это часто делается обходным способом.

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

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

Один из самых удобных способов представления сущностей и связей - использование так называемых ER диаграмм (entity relationship diagrams). В таких диаграммах сущности отображаются в виде прямоугольников, атрибуты - эллипсов, отношения – ромбов. Такие диаграммы удобно рисовать в Access, Visio, специализированных продуктах типа ERWin, VisioModeler.