Описание предметной области

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

Такую информацию целесообразно хранить в базе данных. Реляционная база данных состоит из именованных таблиц. Таблица состоит из строк (записей) и столбцов (полей). Первая таблица cars содержит сведения об автомобилях:

· модель;

· год выпуска;

· государственный регистрационный номер;

· цвет;

· учетный номер автомобиля в автопарке.

Вторая таблица, назовем ее drivers, предназначена для информации о водителях:

· имя;

· отчество;

· фамилия;

· дата рождения;

· домашний адрес;

· дата приема на работу;

· учетный номер водителя.

Таблица timetable содержит данные о расписании использования того или иного автомобиля:

· дата;

· учетный номер автомобиля в автопарке;

· учетный номер водителя.

Таблица cars связана с таблицей timetable. Схема базы данных такой фирмы представлена на рис. 3.

Рис. 3. Схема базы данных таксопарка

Одна и та же машина, описанная в таблице cars, может несколько раз упоминаться в таблице timetable. Такая связь называется отношением "один-ко-многим" (1:N). Аналогично каждый водитель из таблицы drivers может несколько раз упоминаться в таблице timetable. Отношения 1:N являются основными отношениями, поддерживаемыми серверами баз данных. Кроме этого, может встречаться отношение "один-к-одному" (1 : 1). При поступлении на работу водитель представил реко­мендации. Их тоже можно занести в базу, заведя для этой цели новый столбец. Но рекомендации – это длинный текст, и есть они не у всех, значит, несколько полей останутся пустыми, это будет необоснованной тратой памяти. Можно завести отдельную таблицу driver_ref, содержащую два столбца – учетный номер водителя и сам столбец с текстом рекомендации. Отношение между таблицами drivers и driver_ref будет отношением "один-к-одному", ведь у каждого водителя есть только один текст рекомендаций.

Обычно, если вы проектируете базу и обнаруживаете, что между таблицами существует связь "один-к-одному", это означает, что таблицы можно объединить. Проверяйте, не напрасно ли вы создаете дополнительные таблицы, но в данном примере создание таблицы оправдано.

В реляционной базе данных нельзя напрямую создать отношение "многие-ко-многим" (М:N). Его необходимо преобразовать в два отношения 1:N, устанавливаемых с промежуточной таблицей.

Если значения одного поля таблицы представлены в поле другой таблицы, то говорят, что первое поле ссылается на второе. Когда один столбец в таблице ссылается на другой, он называется внешним ключом; а столбец, на который он ссылается, называется родительским ключом. Ключи служат связующим звеном между таблицами. Внешний ключ (foreign key) – это столбец, который соответствует первичному ключу другой таблицы.

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

Значения в поле первичного ключа должны быть уникальными.

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