Разработка мй модея. данных

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

Dooms

RoomType

Guests

RoomReserv

ReservatlonB

Рис. 3-13 Reserv - таблица шяющая таблицы Rooms и Reservations

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

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

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

столбцы, разделяя их так, чтобы каждое имело отношение к одной инструкции:

не обязательно вводить значения в столбец уреID таблицы Guests;

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

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

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

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

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

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

карандаша будет вполне достаточно. Кроме того, бумага и карандаш понадобятся,

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

► Ка лить, каки следует добавить к базе данных

Обратитесь к требованиям к разработанным для сценария с книжным мага-

зином, и запишите категории данных.

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

2. Нарисуйте таблицу для каждой категории данных. Она должна быть достаточно большой, чтобы и ней поместились имена столбцов. Расположите таблицы так. чтобы нарисовать связи между ними. Далее вы добавите имена столбцов и определите связи. Всего на рисунке должно быть пять таблиц,

3. Обозначьте каждую таблицу названием одной из категорий. Для согласованности назовите таблицы Books, Authors, Employees, Customers и Orders.

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

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

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

Назовите новые таблиц ormOfPayment, Positions и BookCondition.

6. из системных требований, в заказе может быть несколько книг.

1. Добавьте одну таблицу Orders) для учета заказанных книг и реальных заказов, принятых от покупателей.

Теперь в общей сложности должно быть 10 таблиц.

> Определение столбцов таблиц

1. Обратитесь к требованиям к системе, разработанным для сценария с книжным

зином.

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

2. Добавьте к таблице столбцы. Помните, что необходима возможность

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

требуется столбец с идентификатором из связанной таблицы. Например, в таблице Orders будет столбец StatusID, который ссылается на таблицу OrderStalus. Для согласованности дайте столбцам названия, указанные ниже.

Таблица Слбц1

Books Titlil ulhorlD, Publisher Date, Edition, Cost, SRP,

ConditionID, Sold

BookCondiiion ConditionID nName, Description

Authors AuthorlD, Fin;lN:mie, LastName. YcarBorn, Ye:irDii;il. Description

Employees EmployeelD. FirstName, LastName, Addressl, Address2, City, State, Zip,

Phone, DOB, HireDate, PositionID

Positions PositionID, Title, JobDescrip

Customers Customer! D, FirstName. LastName, Phone. Addressl, Address2, City, State.

Orders OrderlD, CustomerlD. EmployeelD. Amount, OrderDate, DeliveryDate,

Payment] D. StatusID

OrderStatus StatusL StatusDescrip

FormOfPayment FaymentlD. PaymentUescrip ,:

BookOrders OrderlD, Book ID

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

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

1. Определите, какие связи имеются между таблицей Books и другими таблицами в базе

данныхри необходимости обратитесь за помощью к сценарию с книжным магазином и требованиям к системе.

Сначала отышите прямые связи. Например, как между таблицами Books и ВоокСоп-dition. Данные из таблицы BookCondition связаны непосредственно с данными из ia6-

лицы Books. Кроме того, данные таблицы Authors напрямую связаны с данными таблицы Books [авторы (authors) пишут книги (books)). Между данными таблиц Books и