Разработка логической модели данных

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

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

Определение сущностей и их атрибутов

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

Например, одним из основных объектов базы данных Publishers является таблица Titles. Одним из объектов, связанных с таблицей Titles, является таблица RoyaltySchedule, которая предоставляет информацию о планах по выплате гонораров по каждой книге. Другим таким объектом является таблица TitleAuthor, которая сопоставляет имена авторов с названием книги.

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

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

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

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

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

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

Определение связей между сущностями

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

В примере с гостиничной базой данных начнем с одной из основных таблиц и выберем объекты, связанные с этой таблицей. Допустим, заказчик хочет, чтобы в каждый предварительный заказ номера были включены сведения о номере и постояльце. Номера, постояльцы и предварительные заказы — это категории данных. Ясно, что между номерами и предварительными заказами (как и между постояльцами и предварительными заказами) существует связь. На диаграммах это обычно изображается линией, соединяющая две таблицы. При этом таблицы Rooms и RoomType, а также RoomType и Guests тоже связаны.

Установив, что между таблицами существует связь, следует определить ее тип. На диаграмме такие связи могут быть помечены цифрой 1 или символом бесконечности. Так обозначены стороны связи: 1 означает «один» а символ бесконечности — «много».

В различных источниках для обозначения типов связей между таблицами используются различные типы нотации. Например, в Database Designer из SQL Server сторона «один» обозначена символом ключа, а сторона «много» — символом бесконечности.

Чтобы определить типы связей между таблицами, следует проанализировать типы данных в каждой таблице и выяснить, как таблицы связаны между собой. Например, таблицы Guests и Reservations связаны, поскольку в предварительном заказе необходимо указать сведения о постояльцах. Согласно бизнес-правилам, постоялец может забронировать один или несколько номеров. Но в записи о предварительном заказе номера разрешено указывать только одного постояльца, обычно того, который бронирует номер. В результате можно сделать вывод, что между таблицами существует связь «один ко многим»: одному постояльцу соответствует несколько забронированных номеров.

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

Определение ограничений, налагаемых на данные

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

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

• не обязательно вводить значения в столбец RoomType_ID таблицы Guests;

• любое значение кроме NULL, введенное в столбце RoomType_ID таблицы Guests, должно быть значением из столбца RoomType_ID таблицы RoomType;

• в строке таблицы Guests может быть только одно значение из столбца RoomType_ID.

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

Дата добавления: 2014-01-11