Первая нормальная форма. (вопрос 55). Установление ограничений целостности по полям таблиц и связям

Нормализация таблиц. (вопрос 54)

Установление ограничений целостности по полям таблиц и связям. (вопрос 53)

Создание списков (словарей) для полей с перечислительным характером значений данных. (вопрос 51)

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

Например, поле “Образование” является не просто текстовым, а текстово-списочным, ибо набор его значений составляет унифицированный список: “Начальное”, “Среднее”, “Среднеспециальное”, “Среднетехническое”, “Высшее”. Другой пример – перечень специальностей в организации.

Некоторые СУБД обеспечивают возможность построения и привязки этих списков-словарей к соответствующим полям.

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

Списки (словари) значений могут быть фиксированными и не меняться в процессе эксплуатации банка данных, или динамическими. Фиксированные списки “привязываются” к соответствующим полям через специальные механизмы конкретной СУБД, а динамические размещаются в системных таблицах в соответствующей части базы данных, которые называются системным каталогом. Многие СУБД хранят списки пользователей и ролей (наборы привилегий), списки таблиц, индексов, триггеров, процедур и др., а также сведения кто ими владеет – это все примеры системных таблиц, располагающихся в системном каталоге. Пользователи-абоненты не имеют доступа к системному каталогу.

Динамические словари в большинстве случаев реализуются через создание дополнительных одностолбцовых таблиц, строки которых являются источником списка значений для полей других таблиц. Привязка подобных словарных таблиц в качестве источника значений для полей других таблиц также осуществляются через специальные механизмы конкретной СУБД. Такие таблицы в дальнейшем доступны пользователям банка данных. Обновление, добавление или удаление записей в таблицах-словарях позволяет изменять словарный базис для полей соответствующих таблиц.

Важным, с утилитарной точки зрения, этапом проектирования таблиц является установление ограничений целостности по полям и связям.

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

Дополнительно могут устанавливаться требования уникальности значений и по другим (не ключевым) полям посредством создания для них индексов в режиме без повторов (UNIQUE), а также установления режима обязательного заполнения в строках-кортежах определенных полей (режим NOT NULL).

Вместе с тем СУБД могут предоставлять и более развитые возможности установления ограничений целостности данных. Так можно установить допустимые диапазоны значений полей. Такие ограничения целостности отражают часть правил и особенностей предметной области АИС, которая не формализуется в рамках реляционной модели. Иногда такие ограничения целостности называют “правилами бизнеса”.

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

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

Во втором подходе при удалении записи, значения внешних ключей всех связанных записей таблицы становятся неопределенными. В этом случае СУБД различает “пустые” (NULL) и “неопределенные” значения полей.

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

В заключение отметим, что процесс предварительного проектирования (создания) таблиц реализуется специальными инструкциями языка SQL

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

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

Первая нормальная форма-это основа реляционной системы. Сущность первой нормальной формы определяется требованием атомарности (неделимости) полей и единственности значений по полям в реляционной модели данных. На рис. 5.13. приведен пример ненормализованной и нормализованной таблицы рис. 5.14.

Рис. 5.13. Ненормализованная структура документа «Приказ накладная на отпуск готовых изделий».

Рис. 5.14. Нормализованная структура документа.

S – составная единица информации (документ).

C11 – общая часть, C12 – предметная часть, C13 – оформительская часть.

S.(C11,C12,C13) – S- идентификатор, точка – знак иерархии, C11,C12,C13 – составляющие.

Общая часть документа – C11.(C21,C22,C23); C21 (P1 – номер накладной, P2 – дата, P3 – вид операции, P4 – код склада). C21.(P1,P2,P3,P4); Pi – реквизиты-признаки.

Данные о получателе C22.(P5,P6,P7); Pi – наименование, код, адрес получателя.

Совокупность C23 общей части документа – C23.(C31.(P8,P9),P10,P11,P12). C31 – данные о платежном требовании, P10 – вид упаковки, P11 – станция назначения, P12 – основание сделки; P8 – номер платежного требования; P9 – дата выписки платежного требования.

Предметная часть документа C12.

C12.(P13,P14,Q1,C32.(Q2,Q3),Q4)

P13 – наименование, сорт, размер;

P14 – номенклатурный номер;

Q1 – цена;

C32 – количество, Q4 – сумма;

Q2 – количество по наряду, Q3 – количество отпущенное.

Оформительная часть документа C13.

C13.(P15,P16,P17,P18);

P15 – отпуск разрешил, P16 – виза гл. буха, P17 – отпустил, P18 – получил.