ВРАЗЛИЧНЫЕ СОВЕТЫ И РЕКОМЕНДАЦИИ
Завершим это довольно длинное приложение кратким перечнем различных советов и рекомендаций. Недостаток места исключает возможность слишком подробного обсуждения этих вопросов.
Составные ключи
Использование составных (состоящих из нескольких полей) первичных ключей может оказаться весьма неудобным. Если выясняется, что в Вашем проекте имеется таблица с составным первичным ключом, примите во внимание те преимущества, которые обеспечиваются введением нового, несоставного поля, которое могло бы служить первичным ключом вместо первоначально выбранного. Например, можно ввести в таблицу 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.
Векторы
Представляйте векторы по столбцам, а не по строкам. Например, диаграмму продаж товаров х,у,... за последние годы лучше представить в виде:
| ПРОДАЖИ | ТОВАР | МЕСЯЦ | КОЛИЧЕСТВО |
| х | Январь | 100 |
| ПРОДАЖИ | ТОВАР | КОЛИЧ_ | КОЛИЧ_ | . . . | КОЛИЧ_ |
| x | 100 | 50 | . . . | 360 |
