Полезное:
Как сделать разговор полезным и приятным
Как сделать объемную звезду своими руками
Как сделать то, что делать не хочется?
Как сделать погремушку
Как сделать так чтобы женщины сами знакомились с вами
Как сделать идею коммерческой
Как сделать хорошую растяжку ног?
Как сделать наш разум здоровым?
Как сделать, чтобы люди обманывали меньше
Вопрос 4. Как сделать так, чтобы вас уважали и ценили?
Как сделать лучше себе и другим людям
Как сделать свидание интересным?
Категории:
АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника
Пример проектирования реляционной базы данных
|
|
Пример 4
Задание: преобразовать модель «сущность-связь» из примера 1 в реляционную модель данных. Провести нормализацию таблиц.
Проектирование реляционной базы данных заключается в определении структуры таблиц, связей между ними, доменов и ограничений целостности. На рис.11 показана схема связи реляционных таблиц. Она получена из модели «сущность-связь» (рис.8) по правилам, изложенным выше. Каждой сущности соответствует отдельная таблица:
сущности АВТОМОБИЛЬ – таблица AUTO,
сущности ВОДИТЕЛЬ – таблица DRIVER,
сущности РАСПИСАНИЕ – таблица SHEDULE,
сущности ЗАЯВКА – таблица REQUEST.
Моделирование взаимоисключающих подтипов ОРГАНИЗАЦИЯ и ЧАСТНОЕ_ЛИЦО выполнено по третьему варианту правила (см. п.4.3, правило 8): таблица CUSTOMER (ЗАКАЗЧИК) содержит атрибуты, общие для обоих подтипов (название Name и телефон Phone). Первичный ключ таблицы CUSTOMER суррогатный – столбец ID_Cust. Значения этого столбца являются внешним и первичным ключом одновременно в таблицах PERSON и ORGANIZATION, моделирующих подтипы сущностей ЧАСТНОЕ_ЛИЦО и ОРГАНИЗАЦИЯ. Например, для регистрации заказчика Сидорова П.И. в таблице CUSTOMER добавляется строка (315; Сидоров П.И.; NULL). 315 – его регистрационный номер, NULL – телефона нет. В таблице PERSON добавляется строка (315; 19.02.1964; 38 00; 169805). Число 315 является ссылкой на строку таблицы CUTOMER, и первичным ключом таблицы PERSON.
Моделирование связей М:1 (в том числе связи 2:1 между водителем и автомобилем) происходит путем добавления внешних ключей в таблицу, со стороны которой кардинальное число связи “М”. Если связь обязательная, внешний ключ NOT NULL, иначе – NULL.
| Связь | Таблица.Столбец | Обязательность |
| ЗАКРЕПЛЕННЫЙ_ АВТОМОБИЛЬ | DRIVER. RegNumAuto | Not null |
| РАБОТАЕТ | SHEDULE. Driver _ID | Not null |
| ОБСЛУЖИВАНИЕ_ ЗАЯВКИ | REQUEST. RegNumAuto | null |
| ЗАКАЗ | REQUEST. Cust _ID | Not null |
Рис.11. Схема связи таблиц реляционной модели. Первичные ключи таблиц обозначены PK, внешние FK. Связи по внешним ключам имеют тип M:1 (¥:1).
Обязательность связи со стороны сущности, где кардинальное число равно «1», никак не моделируется в реляционной модели (как, например, связь ЗАКАЗ со стороны сущности ЗАКАЗЧИК).
Проектирование доменов (про домены прочтите п.6.2 на с.41) В каждый домен для нашего примера входит один первичный ключ и все внешние ключи, ссылающиеся на него.
| Имя домена | Назначение домена | Столбцы, принадлежащие домену | Базовый тип | Ограничения целостности домена |
| TRegNum | Регистрационные номера автомобилей | AUTO. RegNum DRIVER. RegNumAuto REQUEST. RegNumAuto | CHAR(14) | NOT NULL, Маска «бб чч-чч ччRUS» бб – буквы, чч- числа |
| TModelAuto | Модели автомобилей | AUTO. Model REQUEST. ModelAuto | См. примечание | |
| TDriver_ID | Код водителя | DRIVER. ID _ Driver SHEDULE. Driver _ ID | SMALLINT | NOT NULL, >0 |
| TDate | Дата | SHEDULE. WDate REQUEST. Rdate | DATE | Нет |
| TTime | Время | SHEDULE. TimeStart SHEDULE. TimeFinal REQUEST. TimeStart REQUEST. TimeFinal | TIME | Нет |
| TCust_ID | Номера заказчиков | CUSTOMER. ID_Cust PERSON. Cust _ID ORGANIZATION. Cust _ ID | SMALLINT | NOT NULL, >0 |
Примечание: модели автомобилей можно записывать в виде строки символов («Газ», «Камаз»). Недостатки этого способа проявляются в следующем: 1) если при оформлении заявки записать название модели, допустим, заглавными буквами («ГАЗ»), то поиск свободных автомобилей данной марки не даст результатов, так как строки «Газ» и «ГАЗ» не равны; 2) строка занимает больше байтов памяти, чем число. Рациональнее будет создать дополнительную таблицу МОДЕЛИ_АВТОМОБИЛЕЙ (Models) со столбцами (КодМодели, НазваниеМодели), и везде вместо названия модели записывать ее код. Таким образом, домен TModelAuto будет числовым.
Таблица [Models]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| ID_Model | TModel Auto | См. домен | Авто-инкрем. | Primary key | См. домен | Код модели | |
| ModelType | VARCHAR(20) | NOT NULL | Название модели |
Таблица [Auto]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| RegNum | TRegNum | См. домен | Авто-инкрем. | Primary key | См. домен | Рег.номер автомобиля | |
| Model | TModelAuto | См. домен | См. домен | FK Models.ID_Model DELETE NO ACTION) | Ссылка на модель |
Таблица [Driver]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| ID_Drver | TDriver_ID | См. домен | Авто-инкрем. | Primary key | См. домен | Код водителя | |
| Surname | NVARCHAR(30) | NOT NULL | Фамилия | ||||
| Name | NVARCHAR(20) | NOT NULL | Имя | ||||
| Patronymic | NVARCHAR(30) | NOT NULL | Отчество | ||||
| RegNumAuto | TModelAuto | См. домен | См. домен | *FK Auto.RegNum DELETE NO ACTION | Ссылка на авто |
*: не более двух строк таблицы могут иметь равные значения столбца RegNumAuto.
Таблица [Shedule]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| Driver_ID | TDriver_ID | См. домен | Primary key | См. домен | FK Driver. .ID_Driver | Код водителя DELETE CASCADE UPDATE CASCADE | |
| WDate | TDate | NOT NULL | См. домен | Дата | |||
| TimeStart | TTime | NOT NULL | >TimeFinal | Время начала смены | |||
| TimeFinal | TTime | NOT NULL | Время конца смены |
Таблица [Customer]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| ID_Cust | TCust_ID | См. домен | Авто-инкрем | Primary key | См. домен | Код заказчика | |
| Name | NVARCHAR(70) | NOT NULL | Имя заказчика | ||||
| Phone | VARCHAR(12) | NULL | Телефон |
В ER-модели подтипы сущностей ОРГАНИЗАЦИЯ и ЧАСТНОЕ_ЛИЦО идентифицировались по-разному. Идентификатором организации был атрибут ИНН, идентификатором человека (СерияПаспорта, НомерПаспорта) (рис.8). При переходе к реляционной модели в таблицы PERSON и ORGANIZATION был добавлен новый первичный ключ Cust_ID, идентифицирующие атрибуты сущности превратились в обычные столбцы с ограничением Unique.
Таблица [Person]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| Cust_ID | TCust_ID | См. домен | Primary key | См. домен | FK Customer. .ID_Cust | Код заказчика | |
| DateOfBirth | DATE | NOT NULL | Дата рождения | ||||
| PassportSeria | CHAR(5) | NOT NULL | Unique | Серия паспорта | |||
| PassportNumber | NUMERIC (6,0) | NOT NULL | >0 | Номер паспорта |
Таблица [Person]
| Имя столбца | Тип | NULL/ NOT NULL | Default | PRIMARY KEY/ Unique | Check | FOREIGN KEY и другие огран. целостности | Примечание |
| Cust_ID | TCust_ID | См. домен | Primary key | См. домен | FK Customer. .ID_Cust | Код заказчика | |
| INN | NUMERIC(15,0) | NOT NULL | Unique | >0 | ИНН | ||
| Province | NVARCHAR(31) | NULL | Область | ||||
| Region | NVARCHAR(31) | NULL | Район | ||||
| Town | NVARCHAR(31) | NOT NULL | Город, село | ||||
| Street | NVARCHAR(47) | NULL | Улица | ||||
| House | VARCHAR(12) | NULL | Дом, корпус |
Date: 2016-07-25; view: 1037; Нарушение авторских прав