Сотрудники Телефоны

Транзитивные зависимости полей создают проблемы при добавлении, обновлении и удалении записей из таблицы. Например, если в какой-то комнате поменялся номер телефона, то для отношения (таблицы) ДанныеСотрудниковнеобходимо изменить столько записей, сколько сотрудников работает в этой комнате. В случае связанных отношений Сотрудники и Телефоны, удовлетворяющих 3НФ, нужно будет изменить только одну запись в таблице Телефоны.

Таблица Заказы3 также находится в 3НФ, т.к. неключевые поля КодПокупателя и Количество взаимно независимы, т.е. в этой таблице нет транзитивных зависимостей полей.

Таким образом, «плата» за нормализацию таблиц – добавление в таблицы новых полей, возможное увеличение количества таблиц в процессе нормализации. «Выгода» от нормализации – более простая и быстрая обработка данных; экономия памяти и машинного времени для хранения и обработки данных.

ПРИМЕРЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

В СУБД MS ACCESS

Рассмотрим примеры проектирования реляционных БД с учетом требований нормализации средствами СУБД MS Access (ниже приведены окна создания схемы данных, вызываемые из основного меню MS Access командами Сервис / Схема данных).

Пример 1.Спроектировать БД «Каталог продукции производителей Республики Беларусь». БД должна содержать следующую информацию: сведения о продукции, сведения о предприятии-производителе, стоимость продукции на определенную дату.

Требуемая схема данных может иметь вид:

Между таблицами используются связи типа «один ко многим» (1:¥). Поля на стороне отношения «один» (на схеме данных выделяются полужирным шрифтом) являются первичными ключами таблиц. Первичные ключи КодПредприятия, КодПродукции в таблицах Предприятия, Продукция имеют тип данных Счетчик, а соответствующие поля на стороне отношения «многие» (внешние ключи) в таблице Стоимость имеют тип данных Числовой (при этом свойство Размер поля имеет значение Длинное целое). Остальные поля имеют типы данных Текстовый, Числовой, Дата/время в зависимости от заносимых данных. При этом задается минимально необходимое значение свойства Размер поля (например, нет необходимости для текстового поля НазваниеПредприятия задавать размер, больший 20-30 символов).

Отметим, что структуру реляционной БД, соответствующей требованиям нормализации, можно быстро создать, используя подход «справочных» и «оперативных» таблиц. В данном примере к справочным таблицам (справочникам) относятся таблицы Предприятия, Продукция (содержат по одной строке для каждого предприятия или вида продукции соответственно; данные в этих таблицах слабо зависят от времени и изменяются относительно редко). Оперативная таблица Стоимость содержит много строк для каждого предприятия и вида продукции, ее данные сильно зависят от времени и быстро изменяются, так как стоимость продукции постоянно обновляется. Как правило, с течением времени объем данных оперативных таблиц становится существенно больше объема данных справочников. Между таблицами-справочниками и оперативными таблицами устанавливается связь 1:¥ (чаще всего используется в реляционных БД), для этого в таблицы нужно добавить соответствующие первичные и внешние ключи. В результате, разместив поля БД по справочным и оперативным таблицам (после анализа предметной области и выделения интересующих атрибутов отношений) и задав связи, получаем нормализованную БД, как правило, соответствующую 3НФ.

Пример 2.Разработать БД «Энергетик», в которой хранится и обрабатывается информация об энергетическом оборудовании предприятия (объединения предприятий). Для каждой единицы оборудования в БД должна храниться следующая информация:

1) инвентарный и серийный номера, марка, наименование;

2) данные о подразделении, где установлено оборудование: адрес (город, улица, дом, корпус); реквизиты главного энергетика;

3) организация - производитель оборудования (наименование, основные реквизиты, контактное лицо);

4) год выпуска, дата (год, месяц) ввода в эксплуатацию;

5) даты испытаний (год, месяц);

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

7) лицо, ответственное за эксплуатацию оборудования (ФИО, подразделение, должность, телефон);

8) энергосберегающие мероприятия, связанные с оборудованием: наименование мероприятия, дата выполнения (год, квартал), затраты на внедрение (млн. руб.); экономический эффект от внедрения мероприятия за квартал (млн. руб.); для одной единицы оборудования могут периодически выполняться энергосберегающие мероприятия.

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

Первичные ключи КодОборудования, КодОтветственного, КодПодразделения имеют тип данных Счетчик, а соответствующие поля на стороне отношения «многие» имеют тип данных Числовой (при этом свойство Размер поля имеет значение Длинное целое). Для таблиц Оборудование, МаркиОборудования поле МаркаОборудования имеет тип данных Текстовый. Остальные поля имеют типы данных Текстовый, Числовой в зависимости от заносимых данных. При этом задается минимально необходимое значение свойства Размер поля (например, 10-15 символов для текстового поля МаркаОборудования).

Отметим, что в приведенных БД некоторые поля могут содержать много текстовых данных: поле ХарактеристикиПродукции в таблице Продукция - Пример 1; поле ПроизводительРеквизиты в таблице МаркиОборудования - Пример 2). С учетом анализа предметных областей, эти данные атомарны – нас интересуют полные значения этих полей. Если бы требовалось хранить и обрабатывать по отдельности, например, каждую их характеристик вида продукции (масса, размеры, цвет и т. д.) или каждый из реквизитов производителя определенной марки оборудования (адрес, расчетный счет и т. д.), то указанные поля пришлось бы разбить на несколько полей согласно требованиям нормализации.

На приведенной схеме данных таблица Оборудование выступает в качестве оперативной таблицы по отношению к справочным таблицам МаркиОборудования, Подразделения, Ответственные. Таблица Ответственные, в свою очередь, является оперативной по отношению к таблице Подразделения. Кроме этого, таблица Оборудование является справочной таблицей по отношению к таблицам ЭнергоСберМероприятия и Испытания. Соответствующие первичные и внешние ключи обеспечивают связи 1:¥ между таблицами БД.