Классика баз данных - статьи
Как видно из примера, таблица
Как видно из примера, таблица содержит два вида отсутствующей информации - “неизвестно” в случае с должностью Семенова и размером жалования Борисова, и “не применимо” в случае должности и жалования Давиденко (по условиям задачи, он - безработный).
Предикат отношения PERSONAL_INFO
мог бы выглядеть так: “человек, идентифицируемый как 1034, имеет фамилию Анин, занимает должность юриста и имеет жалование 100000 руб.”. В то же время предикат “человек, идентифицируемый как 1036, имеет фамилию
Семенов, занимает должность ? и имеет жалование 50 000
руб.” не имеет явного смысла. Кроме того, неизвестно даже точно, какому типу данных принадлежит этот “?”, поскольку, как отмечают Дейт и Дарвен, NULL не принадлежит никакому домену (типу данных), и не является значением
в общепринятом контексте этого понятия.
Первая стадия включает вертикальную декомпозицию этого отношения, как показано на рис. 2.
| CALLED | DOES_JOB | EARNS | |||
| ID | NAME | ID | JOB | ID | SAL |
| 1034 | Анин | 1034 | Юрист | 1034 | 100 000 |
| 1035 | Борисов | 1035 | Почетный президент | 1035 | NULL |
| 1036 | Семенов | 1036 | NULL | 1036 | 50 000 |
| 1037 | Давиденко | 1037 | NULL | 1037 | NULL |
Теперь отношение PERSONAL_INFO
декомпозировано на три отношения: CALLED, DOES_JOB, EARNS. Каждое из полученных в результате отношений характеризуется определенным предикатом. Предикат отношения CALLED выглядит так: “человек, идентифицируемый как ID, имеет фамилию NAME ”. Предикат отношения DOES_JOB
: “человек, идентифицируемый как ID, занимает должность JOB ”. Предикат отношения EARNS: “человек, идентифицируемый как ID, имеет жалование SAL”. Но предикаты отношений DOES_JOB и EARNS все еще не до конца приемлемы.
Вторая стадия – горизонтальная декомпозиция (рис. 3, 4).
| DOES_JOB | JOB_UNK | UNEMPLOYED | ||
| ID | JOB | ID | ID | |
| 1234 | Юрист | 1236 | 1237 | |
| 1235 | Почетный президент |
