Дефекты, обнаруживаемые AllFusion Data Model Validator, подразделяются на четыре категории.
1. Ошибки проектирования столбцов.
В эту категорию включаются ошибки, связанные с неверным именованием столбцов, с наличием неуникальных имен столбцов и таблиц, с заданием неверных определений столбцов (типов, доменов и т. п.).
2. Ошибки проектирования индексов и ограничений.
Ошибки данной категории весьма критичны: их наличие отрицательно сказывается на эффективности выполнения запросов и в целом на производительности серверной части информационной системы. Неправильная реализация ограничений целостности может привести к аномалиям вставки, обновления и удаления данных. Перечислим наиболее серьезные ошибки проектирования.
2.1. Некорректное определение внешнего ключа, не обеспечивающее ссылочной целостности.
Ошибка данного типа может быть выявлена как в модели БД, так и в реализованной БД, готовой к эксплуатации. Некоторые внешние ключи, несмотря на формально правильное определение, могут быть некорректными в том плане, что их наличие в БД не гарантирует ссылочной целостности данных. Сказанное можно пояснить на следующем примере. Пусть имеется БД, хранящая сведения о банках, отделениях банков и клиентских счетах. Схема данных включает три таблицы (рис. 8.1, а): banks, bank_branches и accounts. В таблице bank_branches имеется внешний ключ bank_id для привязки отделения к банку. В таблице accounts определен аналогичный внешний ключ id_bank.
Рисунок 8.1 – Пример некорректного определения внешних ключей:
а) схема БД;
б) заполнение таблиц
Обратим внимание на то, что в таблице accounts, помимо внешнего ключа bank_id, имеется столбец branch_id. Однако для него, по условию примера, не создано ограничение целостности FOREIGN KEY, поэтому внешним ключом он не является.
На рис. 8.1, б показано заполнение таблиц БД. При таком заполнении ссылочная целостность не нарушена. Добавим в таблицу accounts новую строку:
insert into accounts values(433, 002, 006, ‘Якунов И. В.’)
СУБД разрешит выполнение данного оператора. Почему? Потому что банк с идентификатором 433 существует, и, следовательно, ограничение целостности не нарушено. Тем не менее, нарушение согласованности данных очевидно: Балтийский банк (идентификатор 433) не имеет отделения с номером 002, следовательно, Якунов И.В. обслуживается несуществующим отделением Балтийского банка!
Причина нарушения согласованности – в некорректной реализации ограничений целостности. Более грамотный вариант реализации следующий. Столбец branch_id в таблице accounts должен быть внешним ключом – ссылкой на одноименный столбец таблицы bank_branches. В этом случае счет клиента транзитивно связывается с банком через отделение, поэтому внешний ключ bank_id в таблице accounts не нужен вообще (рис. 8.2). При такой реализации невозможно привязать счет клиента к несуществующему отделению банка.
Рисунок 8.2 – Скорректированная схема БД банковской системы
2.2. Все столбцы, входящие в составной потенциальный ключ таблицы, могут хранить неопределенные значения.
Потенциальный ключ – это столбец или группа столбцов, к которой предъявляется требование уникальности значений. Если потенциальный ключ является составным, то уникальной должна быть комбинация значений на пересечении любой строки и всех столбцов, входящих в состав ключа.
Согласно концепции Computer Associates, если каждый столбец в составе потенциального ключа, может хранить неопределенное значение, т. е. нет ни одного столбца, связанного ограничением NOT NULL, это может затруднить поиск и привести к появлению повторяющихся значений в результатах поисковых запросов: в этом случае нельзя будет отличить различные экземпляры сущности друг от друга, что не согласуется с классической концепцией реляционных баз данных.
2.3. Лишние индексы.
Индексы считаются лишними, если они функционально эквивалентны первичным ключам, уже определенным в таблице, или индексируемые столбцы включают первичный ключ.
2.4. В таблице отсутствуют альтернативные ключи.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.