4. Варианты для самостоятельной работы.
Задание№1.
Опишите атрибуты нижеперечисленных сущностей. Укажите тип данных, размер, ограничения значений, допустимость значения Null.
|
Табельный_номер Имя(Фамилия, Имя,Отчество) Адрес Телефон Пол Дата_Рождения Должность |
|
То же, что и у работника |
|
То же, что и у работника Скорость_Печати |
|
Номер_объекта Адрес(Улица,Город, Почтовый_индекс) Тип Количество_комнат Арендная_плата |
|
Номер_владельца Имя Адрес Телефон |
|
Номер_объявления Дата_публикации Название_газеты Стоимость |
|
Название_газеты Адрес Телефон Факс |
|
Дата_Собеседования Комментарии |
|
Номер_клиента Имя Адрес Телефон Предпочтительный_тип Максимальный_размер_платы |
|
Номер_договора Номер_объекта Арендная_плата Способ_платежа Сумма_задатка Задаток_выплачен Дата_начала_аренды Дата_завершения_аренды Продолжительность_аренды |
|
Дата_инспектирования Комментарии |
Задание№2.
Определить область значения атрибутов из задания №1. Опишите домены атрибутов.
Обсуждение локальной концептуальной модели данных с пользователями.
Прежде чем завершить выполнение первого этапа разработки базы данных, необходимо обсудить созданные локальные концептуальные модели с пользователями. При обнаружении ошибок следует внести в проект соответствующие изменения, для чего необходимо вернуться к начальному этапу. Этот цикл должен повторяться до тех пор, пока пользователь не согласится с тем, что предложенный ему проект верно отражает представление каждого типа пользователя о работе предприятия.
Условимся, что наш учебный пример соответствует потребностям пользователя.
Практическая работа №3. Преобразование локальной концептуальной модели данных в логическую модель .
Цель занятия: Проверить логическую модель данных, построенную на занятии №2 . Определить первичные и внешние ключи для отношений, присутствующих в модели.
На этом этапе необходимо удалить из концептуальной модели все структуры, реализация которых в СУБД была бы затруднительна.
Удаление связей типа М:N
Связь
имеет мощность «многие ко многим». Поэтому необходимо преобразовать связь Осматривает в две связи типа 1:М (назовем их Выполняет и ПредоставляетсяДля). Для этого потребуется ввести новую слабую сущность Осмотр. Поскольку вновь созданная сущность – слабая, первичный ключ ее будет полностью или частично определяться сущностями – владельцами, т.е. сущностями Клиент и Объект_для_аренды.
Удаление сложных связей
В связи может участвовать два и более объектов. Связи, в которых участвуют два объекта, называются бинарными. Связи, в которых участвуют три объекта - тернарные, и т.д. На нашей учебной диаграмме связи такого типа отсутствуют, все имеющиеся связи – бинарные.
Удаление связей, имеющих атрибуты.
Присутствие связей с атрибутами может указывать на наличие в модели еще не выделенных сущностей. В нашем случае есть такая связь Клиент Осматривает Объект_для_аренды. Она имеет атрибуты Дата_осмотра и Комментарии. Однако на этапе 1.1 мы эту связь удалили.
Перепроверка связей типа 1:1.
В некоторых случаях сущности, участвующие в связи 1:1, могут фактически представлять различные аспекты одного и того же объекта. По этой причине рекомендуется еще один раз проанализировать смысл всех связей типа 1:1, присутствующих в модели.
В нашей модели такая связь Собеседование с Клиент. Очевидно, участвующие в связи сущности представляют различные объекты реального мира. Поэтому на диаграмме она должна быть сохранена.
Удаление избыточных связей.
Типичным примером избыточной связи является связь Клиент Арендует Объект_для_аренды. Фактически эта связь уже представлена в модели в виде пути, образованного связями Клиент Заключает Договор_аренды и Договор_аренды СвязанС Объект_для_аренды. Поэтому связь Арендует является избыточной и не вносит какой-либо дополнительной информации. Более того клиент вообще не может взять объект в аренду, не заключив договор.
Связь Клиент Арендует Объект_для_аренды просто удаляем из диаграммы.
ER-диаграмма.
Все наши изменения необходимо внести в первоначальный вариант диаграммы. Полученную модель принято называть локальной логической моделью данных представления Инспектор приложения Дом_Мечты(рис.2).
Важно также внести все необходимые изменения в прилагаемую к логической модели данных документацию.
Рис.1. Локальная логическая модель данных представления Инспектор в нотации Чена.