Структура таблиц и целостность данных

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

• ? Какие данные будут храниться в каждой из таблиц?
• ? Какие колонки будут созданы для хранения данных и какие у них будут имена?
• ? Какие будут требования к диапазону данных, хранящихся в колонках (какие данные разрешено в них хранить), и какие типы данных должны применяться для каждой из колонок?
• ? Будут ли иметься колонки, которые могут содержать null-значения, или же вместо этого могут применяться значения по умолчанию?
• ? Какие колонки станут первичными ключами, а какие — внешними ключами?
• ? Какие типы ограничений должны использоваться?
• ? Для какой колонки или колонок должны быть определены индексы?
• ? Какие пользователи должны иметь доступ к тем или иным таблицам?

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

Декларативные ограничения. Ограничения автоматически обеспечивают целостность данных. Ограничения задают правила, которые определяют значения данных, допустимые для какой-либо колонки. Они позволяют ограничивать значения данных, которые вводятся в колонку, чтобы в этой колонке не оказались неверные значения. Например, с помощью ограничения можно ограничить значения колонки для экзаменационной оценки диапазоном значений целого типа от 1 до 10, а для выбора пола — принадлежностью набору символьных значений М или Ж. В результате любые значения вне этого диапазона нельзя будет ввести в данную колонку.

Ограничение NOT NULL задается в описании колонки, чтобы воспрепятствовать вставке null-значений в эту колонку (в противоположность ограничению NULL, которое разрешает присваивать null-значения).

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

Ограничение FOREIGN KEY определяет внешний ключ, который задает связь между двумя таблицами. Колонка или колонки внешнего ключа одной таблицы ссылаются на потенциальный ключ (одна или несколько колонок) в другой таблице. При вставке строки в таблицу с ограничением FOREIGN KEY значения, которые должны быть внесены в колонку или колонки, определенные как внешний ключ, сравниваются со значениями в потенциальном ключе ссылочной таблицы.

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

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

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

Средствами документирования разработки физической модели будем считать описания таблиц и их атрибутов. В таблице 3 приведено описание двух связанных отношений (объектов БД), представленных во фрагменте ER-диаграммы на рисунке 4, определены таблицы и названия полей, заданы ограничения. В колонке «Признак ключа» определяется декларативное определение первичного ключа и внешнего ключа — поля связи.

Рисунок 4 — Фрагмент ER-диаграммы.

Таблица 3 — Описание таблиц и их атрибутов.

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