Правила целостности

Реляционная модель определяет два общих правила целостности базы данных: целостность объектов и ссылочная целостность.

Правило целостности объектов очень простое. Оно требует, чтобы первичные ключи таблиц не содержали неопределенных (пустых) значений.

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

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

Индексация

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

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

5.3. Описание данных

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

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

СУБД не имеет права нарушать принципы реляционной модели, но может как конкретизировать технические параметры (например, определять диапазоны представления чисел и т.п.), так и предоставлять разработчикам и пользователям свои собственные уникальные средства, отсутствующие в других системах. Эти средства бывают очень удобными (собственно, на этом поле в основном и конкурируют СУБД различных производителей). Но, используя специфические для данной СУБД особенности, всегда надо иметь в виду возможность миграции БД в другую систему. Приведем короткий пример для иллюстрации сказанного. СУБД Microsoft Access разрешает именовать поля в таблицах с использованием букв русского алфавита. Большинство других СУБД такую возможность не поддерживает. Следовательно, здесь кроется источник потенциальных проблем.