Физическая структура ядра системы

Чтобы разработать базу данных «Администратор отеля» необходимо создать таблицы, в которые будут вноситься данные. Любой объект можно создать либо вручную, либо с помощью Мастера. Форма создается на базе одной таблицы, а запрос – одной или нескольких таблиц. Создав таблицу, необходимые изменения

можно внести с помощью режима Конструктор.

Рисунок 5 – Схема данных «Администратор отеля»

Описание таблиц базы данных

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

Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами: все столбцы в таблиц – однородные (имеют одинаковый тип); каждый столбец имеет уникальное имя; одинаковые строки в таблице отсутствуют; порядок следования строк и столбцов может быть произвольным. Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы – атрибутам отношений, доменам, полям.

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

В АИС «Администратор отеля» таблица сотрудники состоит из следующих атрибутов: код сотрудника, фамилия сотрудника, имя сотрудника, отчество сотрудника, дата рождения сотрудника, должность, зарплата. Также в таблице сотрудники создан индексы код сотрудника, должность для связи с таблицами должность, состояние номеров. Код сотрудника является первичным ключом, тип связи один-ко-многим. Код сотрудника имеет тип данных primery и расширение 4 - возможно ввести 4 цифры.

.

Рисунок 6 – Таблица сотрудники в режиме конструктора, поля и индексы

Нормализация

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

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

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

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

Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.

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

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