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

Определив требования к системе, вы готовы к разработке логической модели данных. В

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

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

Изучив материал этог №тия, вы сможете:

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

Продолжительность занятия - около 35 минут.

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

Один из этапов формулирования требований к структуре базы данных - определение

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

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

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

гостиничной системы бронирования номеров. Выясняя требования к системе, вы выявили

несколько категорий данных: номера, постояльцы и предварительные заказы В ре-

зультате в базе данных будут созданы таблицы, соответствующие каждой из этих категорий,

как показано на рис. 3-9.

Рие. 3-9. Главнге объекте! в етруктуре базы данных; таблиц wms. Reservations и Guests

При определении -правил для этой системы установлено, что в су-

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

на рис. 3-10.

Рис 10. База данных системе! бронирования гостиничных номеров с таблицей RoomType

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

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

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

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

Guests

GuestsID FirstName

LastName

Addressi

Address2

City

State

RoomTypelD

Рис. 3-11 лица Guests и ее атрибуты

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

После определения таблиц и их столбцов следует выявить связи между таблицами. Не

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

В примере с гостиничной базой данных начнем с одной из основных таблиц и выберем

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

RoomType и Guests тоже связаны.

Установив, что между таблицами существует связь, следует определить ее тип. На рис. 3-12

концы линии связи помечены цифрой 1 или символом бесконечности ( ). Так обозначены стороны связи: 1 означает один а символ бесконечности - много .

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

Рие. 3-12. Связи межд иами в базе данных гоетиничной (

еиетемы номеров

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