 |
Структура таблиц и целостность данных
|
|
|
|
Когда приступают к проектированию таблиц базы данных, требуется принять некоторые решения, относящиеся к их структуре. К этим решениям относится определение того, какие элементы данных должны храниться в этихтаблицах и как таблицы будут связаны друг с другом. Эта работа поможет представить общую картину базы данных, прежде чем вы углубитесь в создание таблиц. Ниже дан перечень вопросов для принятия решений:
− Какие данные будут храниться в каждой из таблиц?
− Какие колонки будут созданы для хранения данных и какие у них будут имена?
− Какие будут требования к диапазону данных, хранящихся в колонках (какие данные разрешено в них хранить), и какие типы данных должны применяться для каждой из колонок?
− Будут ли иметься колонки, которые могут содержать null-значения, или же вместо этого могут применяться значения по умолчанию?
− Какие колонки станут первичными ключами, а какие – внешними ключами?
− Какие типы ограничений должны использоваться?
− Для какой колонки или колонок должны быть определены индексы?
− Какие пользователи должны иметь доступ к тем или иным таблицам?
Необходимо найти ответы на как можно большее количество этих вопросов о проектировании системы и записать их на листок бумаги или в компьютерной программе для рисования схем, чтобы осознать общую конструкцию таблиц вашей базы данных, прежде чем начать создавать их. Нужно определить, каким образом пользователи будут осуществлять доступ к данным. Например, можно определить, что некоторая таблица будет предназначена только для чтения или же в нее будут производиться вставки, удаления или обновления данных. Необходимо предусмотреть, какие запросы будут выполняться чаще всего и из каких колонок будут извлекаться данные. Надо определить, какая информация действительно необходима для базы данных, а какую хранить не надо: она будет получена в результате вычислений.
|
|
|
При задании типа данных у колонки задаются следующие атрибуты:
− тип данных, которые могут содержаться в колонке (например, символьные данные, целые числа или изображения);
− размер (длина) данных, хранимых в колонке;
− точность чисел (этот атрибут применяется только для числовых типов данных), т.е. количество цифр, содержащихся в числах;
− масштаб чисел (этот атрибут применяется только для числовых типов данных), т. е. количество цифр, способных помещаться справа от десятичной точки;
− null-значение (nullvalue) – это неизвестное значение, для которого применяется обозначение NULL. Колонки, способные хранить null-значения, могут оказаться полезными в случаях, когда необходимая информация пока что недоступна для вас. Как правило, не следует применять null-значения. Из-за них запросы и обновления становятся более сложными, кроме того, к колонкам, способным хранить null-значения, нельзя применять некоторые настройки, такие, как первичные ключи и свойство IDENTITY. Вместо применения null-значений в колонке можно задавать значения по умолчанию (defaultvalue).
Декларативные ограничения. Ограничения автоматически обеспечивают целостность данных. Ограничения задают правила, которые определяют значения данных, допустимые для какой-либо колонки. Они позволяют ограничивать значения данных, которые вводятся в колонку, чтобы в этой колонке не оказались неверные значения. Например, с помощью ограничения можно ограничить значения колонки для экзаменационной оценки диапазоном значений целого типа от 1 до 10, а для выбора пола – принадлежностью набору символьных значений М или Ж. В результате любые значения вне этого диапазона нельзя будет ввести в данную колонку.
|
|
|
Ограничение NOT NULL задается в описании колонки, чтобы воспрепятствовать вставке null-значений в эту колонку (в противоположность ограничению NULL, которое разрешает присваивать null-значения).
Ограничение UNIQUE устанавливает, что в колонке или наборе колонок не будут допускаться дублированные значения; иными словами, обеспечивается уникальность значений в этой колонке или наборе колонок.
Ограничение PRIMARY KEY используется, чтобы задать первичный ключ таблицы, представляемый колонкой или набором колонок, уникальным образом идентифицирующих строку таблицы. Поскольку первичный ключ идентифицирует строку, соответствующая колонка никогда не содержит значения NULL.
В этом состоит отличие ограничения PRIMARY KEY от ограничения UNIQUE, которое допускает null-значения. Таблица может иметь только одно ограничение PRIMARY KEY.
Ограничение FOREIGN KEY определяет внешний ключ, который задает связь между двумя таблицами. Колонка или колонки внешнего ключа одной таблицы ссылаются на потенциальный ключ (одна или несколько колонок) в другой таблице. При вставке строки в таблицу с ограничением FOREIGN KEY значения, которые должны быть внесены в колонку или колонки, определенные как внешний ключ, сравниваются со значениями в потенциальном ключе ссылочной таблицы.
Декларативная поддержка ограничений целостности заключается в определении ограничений средствами языка определения данных (DDL – DataDefinitionLanguage).
Например, следующий оператор создает таблицу Куратор и определяет длянекоторые ограничения целостности:
Ссылочная целостность. При работе БД должна обеспечиваться целостность данных. Под целостностью данных понимают обеспечения целостности связей между записями в таблицах при удалении записей из первичных таблиц.
То есть при удалении записей из первичных таблиц, автоматически должны удаляться связанные с ними записи из вторичных таблиц.
В случае несоблюдения целостности данных со временем в БД накопится большое количество записей во вторичных таблицах, связанных с несуществующими записями в первичных таблицах, что приведет к сбоям в работе БД и ее засорению неиспользуемыми данными.
Для обеспечения целостности данных используют диаграммы и триггеры.
|
|
|
Диаграммы – это компоненты БД, которые блокируют удаление записей из первичных таблиц, если существуют связанные с ними записи во вторичных таблицах. Следовательно, диаграммы предотвращают нарушение целостности данных. Для поддержания ссылочной целостности используется каскадирование: разрешить выполнение требуемой операции, но внести каскадные изменения в другие отношения так, чтобы не допустить нарушения ссылочной целостности.
Триггеры – это аналог процедур обработчиков событий в VisualBasic. То есть они выполняют команды SQL, если происходят какие-либо действия с таблицей (например, добавление, изменение или удаление записей). При помощи триггеров можно организовать автоматическое удаление записей из вторичной таблицы при удалении связанной с ними записи из первичной таблицы. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Очень важным является то, что пользователь не может обойти триггер.
Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров – автоматическая (процедурная) поддержка целостности базы данных.
Структуры таблиц определяют физическую модель данных: отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Средствами документирования разработки физической модели будем считать описания таблиц и их атрибутов. В таблице 3 приведено описание двух связанных отношений (объектов БД), представленных во фрагменте ER-диаграммы на рисунке 4, определены таблицы и названия полей, заданы ограничения. В колонке «Признак ключа» определяется декларативное определение первичного ключа и внешнего ключа – поля связи.
Таблица 3. Описание таблиц и их атрибутов.
В соответствии с приведенным выше описанием необходимо представить каждую таблицу проектируемой базы данных.
Если база данных реализуется в MS Access, а затем преобразовывается в MS SQL Server, возможно определение процедурной поддержки целостности базы данных, т.е. разрабатываются триггеры.
|
|
|
