Ошибки и недостатки моделирования колонок

Противоречивое определение типа. Название колонки встречается
в различных таблицах, но при этом колонки (или их синонимы) имеют раз-
ные определения. Это может привести к сохранению неверных данных. Рас-
смотрим пример на рис. 4. 1. 2.

Здесь колонки СОТРУДНИК. Номер_города и ГОРОД. Номер_города имеют одинаковое наименование, но разное определение типов - var-
char2(20) и number; следовательно, колонки СОТРУДНИК. Номер_города
и ГОРОД. Номер_города могут иметь разные наборы данных. Если не пред-
принимать специальных мер, это может привести к потере ссылочной цело-
стности, например внесение сотрудника из несуществующего города.

Противоречивое определение групп колонок. Группа колонок, нару-
шающих первую нормальную форму, имеет противоречивое взаимное оп-
ределение (рис. 4. 1. 3).

Если уж в модели имеются группы колонок, нарушающие первую нор-
мальную форму, то по крайней мере все колонки группы должны иметь
одинаковое определение типа. Так, в примере на рис. 4. 1. 3 имеется груп-
па колонок Оплата1, Оплата2, ОплатаЗ, причем тип колонки Оплата2
(varchar2(20) отличается от типа колонок Оплата1, ОплатаЗ (number). Для
исправления этой ошибки следует привести тип колонки Оплата2 в соот-
ветствие с типом других колонок группы.

Таблицы с неуникальнными именами. Имя таблицы должно быть
уникально в модели. Для исправления ошибки необходимо удалить или пе-
реименовать одну из таблиц.

Таблица не имеет колонок. Таблица должна иметь хотя бы одну колонку.

Для колонки типа VARCHAR не определена длина (для СУБД Ora-
cle). При генерации схемы СУБД Oracle не позволит создать такую колонку.

Длина имени поля больше, чем допускает СУБД.

Противоречивое значение по умолчанию. Значение колонки по умол-
чанию конфликтует с типом данных колонки или со значением, определен-
ном в ограничении CHECK. Возможна также ситуация, когда значение ко-
лонки по умолчанию конфликтует с ограничением CHECK или с определе-
нием данных.

Колонки, которые представляют одни и те же данные, должны
иметь те же самые типы данных.

В примере на рис. 4. 1. 4 колонки КЛИЕНТ. Номер_клиента и ЗА-
КАЗ. Номер_клиента имеют разные типы (CHAR и VARCHAR). Хотя такое
несоответствие не приведет к потере ссылочной целостности, как в примере
на рис. 4. 1. 2, колонки должны быть приведены к одинаковому типу.

Имена колонок совпадают с резервированными словами ANSI SQL.

Это может привести к конфликтам при генерации схемы СУБД. Такие ко-
лонки должны быть переименованы.

4. 1. 3. Ошибки и недостатки моделирования индексов
и ограничений

Колонки потенциальных ключей допускают значение NULL. По-
скольку каждый экземпляр сущности должен однозначно идентифициро-
ваться, не допускается значение NULL для первичных и альтернативных
ключей.

Аномалии в определении индексов. Исправление этого типа ошибки
приводит к увеличению производительности ИС. Этот тип ошибок может
включать следующие 3 разновидности:

1. Индекс функционально эквивалентен первичному ключу. Неуни-
кальный индекс эквивалентен первичному ключу (содержит те же самые
колонки, но в другом порядке). В этом случае либо первичный ключ не га-
рантирует уникальности строки, либо индекс объявлен как уникальный, что,
возможно, не нужно.

Поскольку первичный ключ уникален, любая перестановка колонок
ключа должна быть уникальна, поэтому индекс, функционально эквива-
лентный первичному ключу, должен быть уникален и, вероятно, не нужен,
либо первичный ключ определен на колонках, которые не обеспечивают
уникальности строки. Рассмотрим пример.

create table РЕЙС
(

Аэропорт Вылета varchar2 (3) not null,
Аэропорт_Прибытия varchar2 (3) not null,
Номер_Рейса number not null,
Время_Прибытия number (6, 2)
);

alter table РЕЙС
add constraint PK_ РЕЙС

primary key (Аэропорт_Вылета, Аэропорт_Прибытия, Номер_Рейса);

create index NDX_ РЕЙС

on РЕЙС (Аэропорт_Прибытия, Аэропорт_Вылета, Номер_Рейса);

Если сочетание колонок, входящих в первичный ключ (Аэро-
порт_Вылета, Аэропорт_Прибытия, Номер_Рейса) уникально, то и со-
четание Аэропорт_Прибытия, Аэропорт_Вылета, Номер_Рейса должно
быть уникально.

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

Если индекс создан для того, чтобы извлекать строки в определенном
порядке, возможно, он содержит больше колонок, чем нужно. Если в при-
мере нужно извлекать строки, отсортированные по колонке Аэро-
порт_Прибытия, колонки Аэропорт_Вылета и Номер_Рейса в индексе
NDX_РЕЙС лишние.

Если первичный ключ не обеспечивает уникальности сроки таблицы, не-
обходимо пересмотреть колонки-кандидаты на первичный ключ и допол-
нить первичный ключ так, чтобы он обеспечивал уникальность.

2. Индекс содержит супернабор первичного ключа (т. е. имеет все ко-
лонки первичного ключа и по крайней мере еще одну колонку), но при этом

не является уникальным. Так как первичный ключ уникален, любой супер-
набор должен быть также уникален. Либо индекс должен быть сделан уни-
кальным, либо в действительности первичный ключ не обеспечивает уни-
кальности и должен быть пересмотрен.
Рассмотрим пример.

create table ЗАКАЗ

(

Номер_Заказа number not null,

Дата_3аказа date not null

);

alter table ЗАКАЗ

add constraint PK_3AKA3

primary key (Номер_Заказа);

create index NDX_3AKA3

on ЗАКАЗ (Дата_3аказа, Номер_Заказа);

Если Номер_Заказа уникален, то сочетание колонок Дата_3аказа, Но-
мер_Заказа тоже должно быть уникально. Для того чтобы обнаружить та-
кую ошибку, нужно убедиться, что колонки, входящие в первичный ключ,
действительно обеспечивают уникальность строки. Если это так, то индекс
должен быть сделан уникальным. Возможно, такой индекс создан для сор-
тировки строк по колонке Дата_Заказа. В этом случае колонка Но-
мер Заказа должна быть удалена из индекса. Если же индекс создан для
сортировки по дате заказа, а затем по номеру, то он построен правильно.
Если индекс создан для обеспечения уникальности, то он должен быть уда-
лен, поскольку первичный ключ уже обеспечивает уникальность.

Если первичный ключ не обеспечивает уникальности, необходимо пере-
смотреть состав первичного ключа.

3. Индекс содержит супернабор другого уникального индекса (т. е. имеет все колонки уникального индекса и по крайней мере еще одну колон-

ку) или ограничения. Этот индекс должен быть уникальным и должен быть
переопределен как уникальный.
Рассмотрим пример.

create table КЛИЕНТ
(

Номер_Клиента number not null primary key,
Имя_Клиента varchar2 (80),

Город_Клиента varchar2 (80));

create unique index NDХ_КЛИЕНТ_01

on клиент (Имя_Клиента);

create index NDХ_КЛИЕНТ_02

on КЛИЕНТ (Город_Клиента, Имя_Клиента);

Если Имя_Клиента уникально, то сочетание Город_Клиента,
Имя_Клиента тоже должно быть уникально. Индекс NDX_KJIHEHT_02

должен быть переопределен как уникальный.

Неверно определенный альтернативный ключ. Таблица имеет сурро-
гатный ключ (т. е. ключ, который не имеет соответствия в предметной об-
ласти, например порядковый номер последовательности). В этом случае це-
лесообразно создать альтернативный ключ (см. гл. 2).

В примере на рис. 4. 1. 5 левая таблица СОТРУДНИК имеет суррогатный
ключ Номер_Сотрудиика, но не имеет альтернативного ключа. Это может
привести к внесению имени одного и того же человека с разными номерами.
Для исключения такой ситуации целесообразно создать альтернативный
ключ на колонках Фамилия, Имя, Отчество, Дата_рождения (рис. 4. 1. 5,
справа). ERwin сгенерирует на основе альтернативного ключа уникальных
индекс, см. гл. 2.

Различные определения ограничения CHECK. Одни и те же колонки,
описанные в двух или более таблицах, имеют различные ограничения
CHECK. Это может привести к неверному выполнению запросов, особенно
при выполнении операции объединения (join). Если колонка имеет ограни-
чения CHECK в одной таблице, аналогичные колонки в других таблицах
должны иметь те же самые ограничения.

Таблицы не имеют потенциальные ключей (первичный ключ, уни-
кальное ограничение или уникальный индекс), гарантирующих уникаль-
ность строки. Это может привести к неправильному выполнению запросов.
Каждая таблица должна иметь либо первичный ключ, либо уникальный ин-
декс, либо уникальное ограничение. Если потенциального ключа нет, СУБД
не в состоянии проверить в момент вставки записи, была ли внесена такая
же строка с теми же значениями колонок ранее.

Если таблица не используется для специальных целей, например для тес-
тирования или временного хранения отчетов, для нее должен быть создан
первичный ключ.

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