ВРАЗЛИЧНЫЕ СОВЕТЫ И РЕКОМЕНДАЦИИ
Завершим это довольно длинное приложение кратким перечнем различных советов и рекомендаций. Недостаток места исключает возможность слишком подробного обсуждения этих вопросов.
Составные ключи
Использование составных (состоящих из нескольких полей) первичных ключей может оказаться весьма неудобным. Если выясняется, что в Вашем проекте имеется таблица с составным первичным ключом, примите во внимание те преимущества, которые обеспечиваются введением нового, несоставного поля, которое могло бы служить первичным ключом вместо первоначально выбранного. Например, можно ввести в таблицу SP поле номера поставки НОМЕР_ПОСТАВКИ.
Подтипы сущностей
Иногда заданная сущность может быть одновременно нескольких типов. Один и тот же человек, например, может быть одновременно служащим, акционером и покупателем. Кроме того, некоторые типы сущностей являются подтипами других типов. Так, все директора являются служащими. Тип сущностей Y называется подтипом типа сущностей X, если каждый экземпляр Y обязательно является экземпляром X. Все свойства, обозначения и т. д., относящиеся к X, относятся также и к Y, но не наоборот. Например, директора имеют зарплату, поскольку зарплату имеют все служащие, но они имеют также и бюджет, которого не имеют служащие, не являющиеся директорами. Такая ситуация может быть удобно представлена следующим образом (снова с помощью псевдоЯОД):
CREATE TABLE СЛУЖАЩИЕ /* служащие (стержневые сущности)*/
PRIMARY KEY (НОМЕР_СЛУЖАЩЕГО)
FIELDS (НОМЕР_СЛУЖАЩЕГО . . ., ЗАРПЛАТА . . .);
CREATE TABLE ДИРЕКТОРА /* директора — подтип типа сущностей
СЛУЖАЩИЕ*/
PRIMARY KEY (НОМЕР_СЛУЖАЩЕГО)
FOREIGN KEY (НОМЕР_СЛУЖАЩЕГО
IDENTIFIES СЛУЖАЩИЕ и т. д.)
FIELDS (НОМЕР_СЛУЖАЩЕГО . .., БЮДЖЕТ . . .);
Одно из достоинств этого проекта по сравнению с вариантом, когда эти две таблицы скомбинированы в одну, состоит в том, что он исключает необходимость в неопределенных значениях, которые потребовались бы в противном случае для представления значений БЮДЖЕТ для служащих, которые не являются директорами.
Домены
Хотя система DB2 не поддерживает понятие домена, оно может быть все же полезно в процессе проектирования и может быть, однако, представлено средствами псевдоЯОД. Например;
CREATE DOMAIN НОМЕР_СЛУЖАЩЕГО CHAR (5); /*номера
поставщиков */
CREATE TABLE S
FIELDS (НОМЕР_СЛУЖАЩЕГО DOMAIN
(НОМЕР_СЛУЖАЩЕГО), . . .);
CREATE TABLE SP
FIELDS (НОМЕР_СЛУЖАЩЕГО DOMAIN
(НОМЕР_СЛУЖАЩЕГО), . . .);
Рекомендация.
Всегда, когда это возможно, следует давать каждому полю то же самое имя, что и у определяющего домена. Если же такой возможности нет, давайте полю имя этого домена с использованием некоторого уточнителя в качестве префикса, который обеспечивает уникальность полного имени в содержащей его таблице Так, например, можно использовать НОМЕР_ПОСТАВЩИКА, S.HOMEP_ПОСТАВЩИКА или SP.HOMEP_ПOСТАВЩИКА и т. д. в качестве имен полей, содержащих номера поставщиков. Не используйте, например, НОМЕР_ПОСТАВЩИКА в одной таблице, НОМ_ПОСТ — в другой, а НОМЕР_ПОСТ — в третьей и т. д. Одна из причин использования этого правила состоит в том, что оно облегчает жизнь пользователю— нужно запоминать меньше различных имен, допускается меньше произвола. Другая, возможно, более важная причина—это правило позволяет с помощью запроса к каталогу узнать все случаи использования данного домена. Например:
SELECT NAME, TBNAME
FROM SYSIBM. SYSCOLUMNS
WHERE NAME LIKE ' % НОМЕР_ПОСТАВЩИКА';
Неопределенные значения
Будьте очень внимательны с неопределенными значениями. В поведении неопределенных значений проявляется много произвола и противоречивости, и они могут быть в этой связи источником многих трудностей.
Например:
— два неопределенных значения считаются дубликатами друг друга в связи со спецификациями DISTINCT, UNIQUE и ORDER BY; это не относится, однако, к WHERE или GROUP BY;
— при наличии неопределенных значений для стандартных функций COUNT, SUM и AVG не гарантируется удовлетворение требования, чтобы среднее было равно сумме, деленной на количество;
— при наличии неопределенных значений не гарантируется, что выражение SUM(Fl) +SUM(F2) будет иметь то же самое значение, что и выражение SUM(F1+F2), где F1 и F2—некоторые поля.
В результате следует очень внимательно подумать, хотите ли Вы вообще допускать неопределенные значения для каких-либо полей. Вполне возможно, что Вашим намерениям будет лучше служить использование некоторого «недопустимого» значения, которое, однако, не является неопределенным, такого, как -1 для поля ОТРАБОТАННЫЕ_ЧАСЫ. Если Вы действительно выберете этот путь, то данные ранее рецепты относительно первичных и внешних ключей потребуют, конечно, некоторого пересмотра. Заметим, однако, что имеются три места, в которых понятие неопределенного значения встраивается в саму структуру языка SQL. А именно, SQL:
— предусматривает
присваивание неопределенного значения для любого поля, добавляемого к таблице с помощью предложения ALTER TABLE
— генерирует
неопределенное значение как результат применения какой-либо функции, например
AVQ, к пустому множеству
— генерирует
неопределенное значение для любого неспецифицированного поля при выполнении предложения INSERT.
Векторы
Представляйте векторы по столбцам, а не по строкам. Например, диаграмму продаж товаров х,у,... за последние годы лучше представить в виде:
х
.
х
y
y
.
y
.
Февраль
.
декабрь
январь
февраль
.
декабрь
.
50
.
360
75
144
.
35
.
а не так, как показано ниже:
ЯНВАРЬ
ФЕВРАЛЬ
ДЕКАБРЬ
y
.
75
.
144
.
. . .
. . .
35
.
Одна из причин такой рекомендации заключается в том, что при этом значительно проще записываются обобщенные (параметризованные) запросы. Рассмотрите, например, как выглядит сравнение сведений из диаграммы продаж для товара i
в месяце m со сведениями для товара j в месяце n, где i, j, m и n — параметры.
Смысловая перегрузка полей
Не перегружайте полей более чем одним смысловым значением. Например, ясно, что поле «размер заказа на закупку» относится только к закупаемым деталям. Но оно могло бы также использоваться для представления «количества-находящихся-в-работе» деталей, производимых на своем предприятии. Однако такой проект порождает сложности в программировании, трудности в понимании системной документации, приводит также к возникновению серьезных проблем, если когда-либо будет решено и производить на своем предприятии и закупать одну и ту же деталь.
Снова нормализация
В заключение еще несколько слов о нормализации.
— Во-первых, принципы нормализации являются только принципами. Нет никаких обязательных требований, чтобы все таблицы были, например, в третьей нормальной форме. Единственное требование состоит в том, чтобы они были по крайней мере в первой нормальной форме. Дисциплина нормализации в некотором смысле оптимизирует производительность обновления за счет производительности выборки — избыточность, которую пытается исключить нормализация, плоха для обновления, но она может быть хороша для выборки данных. Можно высказать это другим образом: «Принципы нормализации рекомендуют руководствоваться критерием «один факт в одном месте»; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах». Поэтому Вы можете иногда сделать выбор в пользу нарушения этих принципов. Но, поступая так, документируйте причины, которыми Вы руководствовались.
— Во-вторых, все наши обсуждения были связаны с базовыми таблицами. Даже если базовые таблицы находятся в 3НФ, нет никакой необходимости, чтобы этому условию удовлетворяли представления, и в действительности они чаще всего и не находятся в 3НФ. Процедура проектирования, которая была настойчиво рекомендована в этом приложении, в большой степени независима от приложений. Мы просто говорили: «Решите, в каких сущностях Вы заинтересованы; решите, какие существуют между ними связи, и т. д.», и при этом полностью игнорировали вопрос, каким образом планируется использовать эту информацию. Впоследствии можно будет в некоторой мере приспособить, реструктуризовать, скорректировать этот независимый от приложений проект с тем, чтобы удовлетворять потребности конкретных приложений с помощью механизма представлений. Однако такая деятельность по приспособлению носит в большой степени вторичный характер. Главная задача состоит прежде всего в том, чтобы получить как раз независимый проект.
