В качестве первичных ключей на практике часто выбираются «бессодержательные» столбцы – например, уникальные идентификаторы строк. При всех преимуществах этого приема, он имеет один недостаток с точки зрения теории реляционных БД: если в таблице нет альтернативных ключей, то не всегда возможно отличить один экземпляр сущности от другого по неключевым столбцам. Поэтому, если в таблице определен «бессодержательный» первичный ключ, Computer Associates настоятельно рекомендуется задавать альтернативные ключи с помощью ограничения целостности UNIQUE.
2.5. Несогласованность ограничений целостности CHECK у идентичных столбцов разных таблиц.
2.6. Отсутствие потенциальных ключей в таблице.
Данная особенность модели БД считается недостатком с точки зрения теории реляционных БД: в таблице без ключевых атрибутов не гарантируется отличимость одной строки от другой.
2.7. Ограничения целостности отключены.
СУБД дают возможность отключать имеющиеся в ней ограничения целостности и триггеры. Отключенные ограничения игнорируются СУБД при любой обработке данных. Чем больше ограничений отключено, тем менее защищена БД от появления некорректных значений.
2.8. Повторяющиеся внешние ключи.
Эта ошибка может встречаться в моделях, создаваемых при помощи AllFusion ERWin Data Modeler. Суть ошибки в том, что таблица содержит два и более дублирующихся внешних ключей, ссылающихся на один и тот же потенциальный ключ. На уровне СУБД это не допускается.
2.9. Первичный ключ содержит столбцы вещественного типа.
Использование вещественных значений в ключевых столбцах нетипично для реляционных БД, хотя и не является ошибкой и даже необходимо в особых случаях. Компания Computer Associates рекомендует разработчикам баз данных в подобных ситуациях дополнительно проверять корректность определений столбцов.
2.10. Ненужное ограничение целостности CHECK.
Этот тип ошибки охватывает множество случаев. Один из наиболее типичных –когда ограничивающему условию удовлетворяет только одно значение. Очевидно, что нет никакой нужды в использовании таких столбцов. Скорее всего, речь должна идти не столько о «лишнем», сколько об ошибочно реализованном ограничении CHECK. Кроме того, ограничения, «лишним» ограничение может оказаться потому, что оно создано не для той таблицы. Не стоит накладывать ограничение CHECK на столбец, являющийся внешним ключом; гораздо правильнее – наложить его на соответствующий первичный (потенциальный) ключ независимой таблицы.
2.11. Ненужные внешние ключи.
Типичный случай использования ненужного внешнего ключа показан на рис. 8.3. Таблица table1 транзитивно связана с table3 через table2. Поэтому одна из ссылок является лишней – скорее всего, это прямая ссылка из table1 на table3.
Рисунок 8.3 – Пример использования ненужного внешнего ключа
2.12. Слишком много индексов для одной таблицы.
Таблицу, индексируемую множеством индексов, сложно обрабатывать: снижается скорость выполнения запросов (тогда как основная цель использования индексов – повысить скорость их выполнения).
Оценивание избыточности индексирования производится относительно порогового значения, задаваемого экспертом. Если количество индексов на таблицу превышает пороговое значение, система выдает сообщение об ошибке.
2.13. Индекс или первичный ключ содержит слишком много столбцов таблицы.
Как и в предыдущем пункте, оценивание производится с указанием порогового значения. Некорректными считаются индексы (ключи), у которых количество индексируемых столбцов превышает заданное пороговое значение.
2.14. Индекс содержит столбцы VARCHAR или любые другие типы данных нефиксированной длины.
Такая ситуация является недопустимой в СУБД DB2 для мэйнфреймов, поэтому AllFusion Data Model Validator предупреждает эксперта о возможной ошибке в модели.
2.15. Размер поля индексирования или первичного ключа слишком велик.
Данная ошибка возникает, если поле индексирования по размеру превышает заданное пользователем пороговое значение.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.