Переход к реляционной модели данных (определение отношений, атрибутов, потенциальных и первичных ключей)

Инфологическая модель

Инфологическая модель применяется на втором этапе проектирования базы данных, то есть словесного описания предметной области. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта базы данных (БД), и конечно, оно не должно быть привязано к конкретной системе управления базами данных (СУБД).

Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД.

Существует несколько моделей данных. Для проектируемой базы данных применена модель "сущность-связь", которая стала фактическим стандартом при инфологическом моделировании баз данных. Инфологическая модель предметной области «Интернет-провайдер» представлена на рисунке 2.1.

Рис. 2.1 – Инфологическая модель «Интернет-провайдер»

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

Согласно правилам преобразования ER-модели в реляционную, определяем отношения (базовые таблицы), их атрибуты, первичные и внешние ключи.

Сущности Тариф будет соответствовать отношение Tarif, свойства атрибутов указаны в таблице 2.1.

Таблица 2.1 – Свойства атрибутов отношения Tarif
Наименование колонки	Тип	Ключ
id_tarif	INT (AUTOINC)	NOT NULL	PRIMARY KEY
tname	CHR(15)	NOT NULL	CANDIDATE KEY
tkind	CHR(10)	NOT NULL
timecost	NUM(6, 2)	NOT NULL
trafcost	NUM(6, 2)	NOT NULL
maxspeed	INT(4)	NOT NULL
oplata	INT (4)	NOT NULL

Синтаксис для создания таблицы Tarif на языке структурированных запросов (SQL) будет выглядеть, как показано в листинге на рисунке 2.2.

Рис. 2.2 – Создание с помощью SQL таблицы Tarif

Сущности Улица соответствует отношение Street; свойства атрибутов указаны в таблице 2.2.

Таблица 2.2 – Свойства атрибутов отношения Street
Наименование колонки	Тип	Ключ
id_street	INT (AUTOINC)	NOT NULL	PRIMARY KEY
strname	CHR(30)	UNIQUE

Синтаксис для создания таблицы Tarif на языке структурированных запросов (SQL) будет выглядеть, как показано в листинге на рисунке 2.3.

Рис. 2.3 – Создание с помощью SQL таблицы Street

Сущности Пользователь соответствует отношение Users; свойства атрибутов указаны в таблице 2.3.

Таблица 2.3 – Свойства атрибутов отношения Users
Наименование колонки	Тип	Ключ
id_user	INT (AUTOINC)	NOT NULL	PRIMARY KEY
fio	CHR(30)	NOT NULL
id_street	INT(4)	NOT NULL	FOREIGN KEY
n_house	CHR(7)	NOT NULL
n_flat	CHR(4)	NULL

Синтаксис для создания таблицы Users на языке структурированных запросов (SQL) будет выглядеть, как показано в листинге на рисунке 2.4.

Рис. 2.4 – Создание с помощью SQL таблицы Users

Сущности Логин соответствует отношение Login; свойства атрибутов указаны в таблице 2.4.

Таблица 2.4 – Свойства атрибутов отношения Login
Наименование колонки	Тип	Ключ
id_login	INT (AUTOINC)	NOT NULL	PRIMARY KEY
login	CHR(10)	NOT NULL
parol	CHR(8)	NOT NULL
id_tarif	INT(4)	NOT NULL	FOREIGN KEY
id_user	INT(4)	NOT NULL	FOREIGN KEY
account	NUM(8, 2)	NOT NULL

Синтаксис для создания таблицы Login на языке структурированных запросов (SQL) будет выглядеть, как показано в листинге на рисунке 2.5.

Рис. 2.5 – Создание с помощью SQL таблицы Login

Сущности Статистика соответствует отношение Statistics; свойства атрибутов указаны в таблице 2.5.

Таблица 2.5 – Свойства атрибутов отношения Statistics
Наименование колонки	Тип	Ключ
id_stat	INT (AUTOINC)	NOT NULL	PRIMARY KEY
id_login	CHR(10)	NOT NULL	FOREIGN KEY
contin	NUM(6, 2)	NOT NULL
trafic	NUM(10, 3)	NOT NULL
oplata	NUM(8, 2)	NOT NULL
paid	LOGICAL	NOT NULL

Синтаксис для создания таблицы Statistics на языке структурированных запросов (SQL) будет выглядеть, как показано в листинге на рисунке 2.6.

Рис. 2.6 – Создание с помощью SQL таблицы Statistics

Параметр DEFAULT служит для задания значения по умолчанию при добавлении новой записи в таблице.

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

– Что должно случиться при попытке удалить объект ссылки внешнего ключа?

– Что должно случиться при попытке обновить потенциальные ключ, на который ссылается внешний ключ?

– Что должно произойти при попытке добавления значение, которого нет в родительской таблице?

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

– «ограничить» операцию удаления, т.е. удаление «запрещается» пока есть хоть одна ссылка на этот объект;

– «ограничить» операцию вставки, т.е. вставка новой строки «запрещается», если значению внешнего ключа не соответствует ни одно значение из родительской таблицы;

– «каскадировать» операцию обновления, обновляя также внешний ключ в дочерней таблице.

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

Дата добавления: 2015-07-13