РУКОВОДСТВО ПО РЕЛЯЦИОННОЙ СУБД DB2

         

ВРАЗЛИЧНЫЕ СОВЕТЫ И РЕКОМЕНДАЦИИ


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

Составные ключи

Использование составных (состоящих из нескольких полей) первичных ключей может оказаться весьма неудобным. Если выясняется, что в Вашем проекте имеется таблица с составным первичным ключом, примите во внимание те преимущества, которые обеспечиваются введением нового, несоставного поля, которое могло бы служить первичным ключом вместо первоначально выбранного. Например, можно ввести в таблицу 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

.

Январь

Февраль

.

декабрь

январь

февраль

.

декабрь

.

100

50

.

360

75

144

.

35

.

а не так, как показано ниже:

ПРОДАЖИ

ТОВАР

КОЛИЧ_

ЯНВАРЬ

КОЛИЧ_

ФЕВРАЛЬ

. . .

КОЛИЧ_

ДЕКАБРЬ

x

y

.

100

75

.

50

144

.

 . . .

 . . .

 . . .

360

35

.

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

в месяце m со сведениями для товара j в месяце n, где i, j, m и n — параметры.



Смысловая перегрузка полей

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

Снова нормализация

В заключение еще несколько слов о нормализации.

— Во-первых, принципы нормализации являются только принципами. Нет никаких обязательных требований, чтобы все таблицы были, например, в третьей нормальной форме. Единственное требование состоит в том, чтобы они были по крайней мере в первой нормальной форме. Дисциплина нормализации в некотором смысле оптимизирует производительность обновления за счет производительности выборки — избыточность, которую пытается исключить нормализация, плоха для обновления, но она может быть хороша для выборки данных. Можно высказать это другим образом: «Принципы нормализации рекомендуют руководствоваться критерием «один факт в одном месте»; но иногда есть существенные причины для того, чтобы иметь два факта в одном месте или один факт в двух местах». Поэтому Вы можете иногда сделать выбор в пользу нарушения этих принципов. Но, поступая так, документируйте причины, которыми Вы руководствовались.

— Во-вторых, все наши обсуждения были связаны с базовыми таблицами. Даже если базовые таблицы находятся в 3НФ, нет никакой необходимости, чтобы этому условию удовлетворяли представления, и в действительности они чаще всего и не находятся в 3НФ. Процедура проектирования, которая была настойчиво рекомендована в этом приложении, в большой степени независима от приложений. Мы просто говорили: «Решите, в каких сущностях Вы заинтересованы; решите, какие существуют между ними связи, и т. д.», и при этом полностью игнорировали вопрос, каким образом планируется использовать эту информацию. Впоследствии можно будет в некоторой мере приспособить, реструктуризовать, скорректировать этот независимый от приложений проект с тем, чтобы удовлетворять потребности конкретных приложений с помощью механизма представлений. Однако такая деятельность по приспособлению носит в большой степени вторичный характер. Главная задача состоит прежде всего в том, чтобы получить как раз независимый проект.





Содержание раздела