2.3. Логическое проектирование бд.

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

• отсутствие дублируемой информации;

• поддержание целостности данных при вставке, удалении или изменении записей;

• возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.

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

В реляционных базах данных (РБД) даталогическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, адекватно моделирующих объекты ПО и семантических связей между ними.

Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными.

В конце этого этапа должно быть получено описание схемы БД в терминах выбранной СУБД. Целью даталогического проектирования является построение корректной схемы БД, ориентированную на реляционную модель. Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• Декомпозиция (разбиение).

• Синтез.

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

1. каждой сущности ставится в соответствие отношение;

2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;

3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOTNULL);

4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);

5. по умолчанию, все атрибуты, не входящие в PK, необязательны;

6. для отражения категоризации сущностей возможны несколько вариантов;

7. все связи М:М должны быть раскрыты;

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

Таблица 1. Схема отношения Клиенты (Clients)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	id	N(4)	Первичный ключ
Фамилия, имя, отчество	fio	C(50)	Обязательное поле
Стаж вождения	dyears	N(2)	Обязательное поле
Рейтинг (кол-во заказов)	rating	N(4)	Вычисляемое поле
№ Паспорта	passport	N(12)	Обязательное уникальное поле
Кол-во штрафов	taxes	N(3)	Вычисляемое поле
Номер телефона	phone	N(12)	Обязательное поле

Таблица 2. Схема отношения Автомобили (Cars)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	id	N(3)	Первичный ключ
Год выпуска	year_of_issue	N(4)	Обязательное поле
Цвет	color	N(4)	Обязательное поле
Состояние	quality	N(3)	Обязательное поле
В прокате	rented	N(1)	вычисляемое поле
ID модели	modelid	N(4)	Обязательное поле (внеш. ключ к models)

Таблица 3. Схема отношения Контракты (Contracts)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	id	N(4)	Первичный ключ
ID Клиента	clientid	N(4)	Обязательное поле (внеш. ключ к clients)
ID Автомобиля	carid	N(3)	Обязательное поле (внеш. ключ к cars)
Дата заключения	date	D	Обязательное поле
Длительность	days	N(3)	Обязательное поле
Ценность	value	N(10)	Обязательное поле
ID сотрудника	Staff_id	N(4)	Обязательное поле (внеш. ключ к Staff)

Таблица 4. Схема отношения Марки (Brands)

Содержание поля	Имя поля	Тип, длина	Примечания
ID Фирмы	id	N(2)	Первичный ключ
Название	brand	C(25)	Обязательное поле

Таблица 5. Схема отношения Штрафы (Taxes)

Содержание поля	Имя поля	Тип, длина	Примечания
Табельный номер	id	N(4)	Первичный ключ
Дата	date	D	Обязательное поле
Описание	descriptoin	С(50)	Обязательное поле
Сумма	result	N(5)	Обязательное поле
ID Контракта	id_contract	N(4)	Обязательное поле (внеш. ключ к contracts)

Таблица 6. Схема отношения Модели (Models)

Содержание поля	Имя поля	Тип, длина	Примечания
ID модели (табельный номер)	id	N(6)	Первичный ключ
Название модели	nae	C(20)	Обязательное поле
ID Марки	brand_id	N(2)	Обязательное поле (внеш. ключ к brands)
Вместимость	capacity	N(1)	Обязательное поле
Id Тип кузова	typeid	N(6)	Обязательное поле (внеш. ключ к bodytype)
Id цвета	colorid	N(6)	Обязательное поле (внеш. ключ к Colors)

Таблица 7. Схема отношения Типы Кузова (Bodytype)

Содержание поля	Имя поля	Тип, длина	Примечания
ID типа	id	N(2)	Первичный ключ
Название	type	C(25)	Обязательное поле

Таблица 8. Схема отношения Цвет (Colors)

Содержание поля	Имя поля	Тип, длина	Примечания
ID Цвета	id	N(2)	Первичный ключ
Название	color	C(25)	Обязательное поле

Таблица 9. Схема отношения Должности (Positions)

Содержание поля	Имя поля	Тип, длина	Примечания
ID Должности	id	N(2)	Первичный ключ
Название	color	C(25)	Обязательное поле
Зарплата	sallary	N(10)	Обязательное поле

Таблица 10. Схема отношения Сотрудники (Staff)

Содержание поля	Имя поля	Тип, длина	Примечания
ID cотрудника	id	N(2)	Первичный ключ
ФИО	Full_name	C(25)	Обязательное поле
ID должности	Position_id	N(2)	Обязательное поле
№ Паспорта	passport	N(12)	Обязательное уникальное поле
Номер телефона	phone	N(12)	Обязательное поле