Первичный ключ, имеющий колонку типа действительного числа

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

Ненужные ограничения CHECK. Ограничения CHECK считаются не-
нужными, если они либо проверяют только одно условие в логическом
"или" либо проверяют внешний ключ в дочерней таблице вместо того, что-
бы проверять первичный ключ в родительской.

Рассмотрим пример проверки только одного условия в логическом
"или".

CHECK (Статус IN ('РАЗРЕШИТЬ'))

Если во всех строках таблицы колонка Статус принимает только одно
значение - 'РАЗРЕШИТЬ', то либо такая колонка не нужна и ее следует уда-
лить вместе с ограничением CHECK, либо в действительности колонка
Статус может принимать и другие значения и ограничение CHECK нужно
переопределить.

Другой пример:

create table КАТЕГОРИЯ

(Категория varchar2 (12) not null primary key);

create table КЛИЕНТ (
Номер_Клиента number not null primary key,

Имя_Клиента varchar2 (80),
Категория varchar2 (12) not null
constraint VALID_Категория check
(Категория in ('Обычный', 'Постоянный', 'VIP'))
);

Предположим, из таблицы КАТЕГОРИЯ удаляется строка, например
значение 'Обычный'. При этом в таблице КЛИЕНТ строки с таким значени-
ем остаются. Для обеспечения целостности данных при каждом редактиро-
вании таблицы КАТЕГОРИЯ придется редактировать множество строк таб-
лицы КЛИЕНТ и менять ограничение VALID_Категория. Поэтому ограни-
чение VALID_Категория в дочерней таблице на колонку КЛИЕНТ. Кате-
гория должно быть удалено и аналогичное ограничение должно быть
создано в родительской таблице КАТЕГОРИЯ. Категория.

Ненужные индексы. Ненужные индексы приводят к падению произво-
дительности ИС и должны быть удалены.

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

Индекс, колонки которого целиком включены в другой индекс. Рас-
смотрим пример.

create table ЗАКАЗ
(

Номер_Заказа number not null primary key,
Номер_Клиента number not null,

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

create unique index NDX_3AKA3_01

on ЗАКАЗ (Номер__Клиента, Дата_3аказа);

create index NDX_3AKA3_02

on ЗАКАЗ (Номер_Клиента);

Если строка идентифицируется по индексу NDX_3AKA3_01, то она
идентифицируется и по индексу NDX_3AKA3_02; следовательно, индекс
NDX_ЗАКАЗ_02 должен быть удален (если только он не используется для
специальных целей).

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

Ненужный внешний ключ. В примере на рис. 4. 1. 6 ссылочная целост-
ность поддерживается связями R1 и R2, связь R3 должна быть удалена.

Отсутствие индексов. Рассмотрим пример на рис. 4. 1. 7. Таблицы ЗА-
КАЗ и КЛИЕНТ денормализованы (см. гл. 2). Таблица КЛИЕНТ связана
с таблицей ЗАКАЗ по колонке Номер_Клиента. Если в таблице ЗАКАЗ
на колонке Номер_Клиента не будет создан индекс, то при удалении стро-
ки в таблице КЛИЕНТ для обеспечения ссылочной целостности СУБД бу-
дет проверять наличие строк в таблице ЗАКАЗ с соответствующим значени-
ем поля ЗАКАЗ. Номер_Клиента. Если по этому полю не построен индекс,
производительность системы может резко упасть.

С другой стороны, если данные в родительской таблице меняются редко
(например, в таблице ГОРОД), отсутствие индекса на внешнем ключе
(КЛИЕНТ. Номер_Города) допустимо.

Таблицы со слишком большим количеством индексов. Большое ко-
личество индексов замедляет операции вставки и обновления (insert и upda-
te). Конкретное число индексов, которое допустимо для данной таблицы,
зависит от многих параметров и должно определяться автором модели.

Индексы со слишком большим количеством колонок. Такие индексы
замедляют операции вставки (update). Допустимое число колонок в индексе
также должно определяться автором модели.

Длина индекса слишком большая. Максимальная общая длина коло-
нок, входящих в индекс, превосходит значение, заранее заданное пользова-
телем ERwin Examiner. Слишком большая длина индекса может привести
к его недопустимому размеру.

Длина первичного ключа слишком большая. Максимальная общая
длина колонок, входящих в первичный ключ, превосходит значение, заранее
заданное пользователем ERwin Examiner.

Первичные ключи со слишком большим количеством колонок. Та-
кие ключи замедляют операции вставки (update) и выборки (select) с объ-
единением таблиц. В этом случае целесообразно заменить естественный
первичный ключ на суррогатный как показано на рис. 4. 1. 8 и 4. 1. 9.

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

Таблица не имеет связей. Иногда таблица без связей создается умыш-
ленно, например служебные таблицы или специальные справочники. Но ес-
ли такие таблицы отражают предметную область, они должны быть тща-
тельно проанализированы. В примере на рис. 4. 1. 10 таблицы КЛИЕНТ
и ЗАКАЗ не связаны, но такая связь предполагается по полям КЛИЕНТ. Но-
мер_клиента и ЗАКАЗ. Клиент. Это ошибка, и она должна быть исправле-
на - должна быть установлена связь между КЛИЕНТ и ЗАКАЗ.