Базы данных.

 

1.1. Общие положения

 

Определение. Реляционная логическая модель представляет собой совокупность нормализованных отношений, в которых реализованы связи между объектами предметной области и выполнены все преобразования, необходимые для ее эффективной реализации в среде конкретной СУБД.

Для получения такой модели необходимо:

1) выполнить анализ исходной концептуальной инфологической модели для установления дополнительных логических связей;

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

3) выполнить анализ полученных отношений с точки зрения соответствия их требованиям четвертой нормальной формы(IVНФ);

4) преобразовать полученные отношения с учетом требований конкретной системы управления базой данных (СУБД).

В результате будет получена СУБД-ориентированная эффективная логическая модель базы данных.

 

1.2. Установление дополнительных логических связей

 

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

Правило. Между сущностями исходной инфологической модели устанавливается дополнительная логическая связь, если, во-первых, частота совместного использования этих сущностей высока; во-вторых, непосредственной связи эти сущности не имеют, а выборка данных согласно имеющимся связям требует "лишнего" чтения.

Несколько слов о "лишнем" чтении. Обратимся к рис. А. Предположим, что необходимо выполнить следующий запрос пользователя: "Дать сведения об изделиях, в состав которых входит двигатель ДВ12". Какова бы ни была логическая модель базы и ее физическая реализация, заранее можно утверждать, что запрос будет выполнен, поскольку между записями "Паспорт" и "Изделие" в исходной модели есть непосредственная связь.

Теперь предположим, что существует следующий запрос: "Дать сведения о доводке изделий, в состав которых входит двигатель ДВ12".

Для выполнения запроса необходима информация, содержащаяся в записях "Паспорт двигателя" и "Доводка изделия". Но в модели (рис. А) между ними нет непосредственной связи. Поэтому для выполнения запроса потребуется: во-первых, поиск всех изделий, в состав которых входит конкретный двигатель (чтение записей "Изделие"); во-вторых, поиск сведений о доводке изделий (чтение записей "Доводка изделия").

Чтение записей "Изделие" и будет являться "лишним", так его можно избежать, установив , а в дальнейшем и реализовав, непосредственную связь между сущностями "Паспорт двигателя" и "Доводка изделия".

Если предположить, рассмотренный запрос выполняется часто, например ежедневно, то объем "лишнего" чтения станет значительным и будет ухудшать эксплуатационные характеристики действующей базы данных. Поэтому очевидна цель рассматриваемого приема логического проектирования: исключить "лишнее" чтение и, следовательно, минимизировать время выполнения запросов пользователей.

Введем обозначения: R=R(I,J) - матрица суммарной частоты совместного использования сущностей модели при решении всех задач пользователей; К - количество сущностей в модели; i,j - индексы сущностей; i,j=1,k.

Последовательность действий:

1. Расчет матрицы R суммарной частоты использования сущностей модели.

2. Расчет среднего значения матрицы R.

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

4. Анализ по модели наличия непосредственной связи между сущностями.

5. Если связь есть, переход к анализу модели для следующей пары сущностей, частота совместного использования которых выше среднего. Если связи нет, определение объема "лишнего" чтения, принятие решения об установлении связи.

 

 

Таблица 3 – Частота совместного использования сущностей модели БД

«Эксперимент»

 

сущность	индекс сущности
1. Справочник испытаний
2. План испытаний
3. Паспорт двигателя
4. Состав двигателя
5. Параметры двигателя
6. Справочник параметров
7. Изделие
8. Доводка изделия

 

Алгоритм завершает работу, когда все пары сущностей с высокой частотой использования просмотрены.

Значения матрицы R для нашего примера приведены в таб. 3. Исходные данные для расчетов содержатся в таб. 1.

Таблица 3. Частота совместного использования сущностей модели базы данных "Эксперимент"

Средняя частота :

 

В нашем примере средняя частота равна 150. Сущности "Справочник испытаний" и "План испытаний" используются с частотой выше среднего. То же характерно и для сущностей "Справочник параметров" и "Параметры двигателя", а также "Изделие" и "Доводка изделия". Здесь нет необходимости в установлении дополнительных логических связей, т.к. связи уже имеются.

Сущности "Справочник испытаний" и "Состав двигателя" используются совместно с высокой частотой, но непосредственной связи в модели не имеют (см. рис. А).

Оцениваем объем "лишнего" чтения. Доступ к сущности "Состав двигателя" возможен только через сущность "Паспорт двигателя". Объем этого массива(паспорт двигателя), умноженный на частоту решения первой задачи и будет составлять объем "лишнего" чтения. Данные о размерности массивов приведены в таб. 4. Поскольку объем "лишнего" чтения велик, принимаем решение об установлении дополнительной логической связи между сущностями "Справочник испытаний" и "Состав двигателя". На модели она должна быть проведена пунктиром.

 

Таблица 4 - Размерность массивов базы данных "Эксперимент"

 

Наименование массива	Размерность массива (в байтах)
число	степень 10
Справочник испытаний	1,5
План испытаний
Паспорт двигателя
Состав двигателя
Справочник параметров
Параметры двигателя
Изделие
Доводка изделия

 

Сущности "План испытаний" и "Состав двигателя" используются совместно с частотой выше среднего. Непосредственной связи в модели не имеют. Оцениваем объем "лишнего" чтения. Сущности используются совместно при решении первой задачи вместе с сущностью "Справочник испытаний". От нее ("Справочник испытаний") идет непосредственная связь к сущности "План испытаний" и дополнительная логическая связь к сущности "Состав двигателя". Следовательно, доступ к этим сущностям при решении первой задачи не затруднен, "лишнего" чтения нет. А так как больше ни в одной задаче эти сущности совместно не используются, принимаем решение о том, что необходимость в дополнительной логической связи между ними отсутствует.

Выполняя анализ по тому же алгоритму, принимаем решение об установлении дополнительной логической связи между сущностями "Справочник параметров" и "Состав двигателя" и об отсутствии необходимости такой связи между сущностями "Состав двигателя" и "Параметры двигателя".

Модель с установленными дополнительными логическими связями показана на рис. 2. Связи пронумерованы для удобства дальнейшей работы.

 

Рис. 2. Установление дополнительных логических связей в схеме базы

данных "Эксперимент"

 

 

 

3 4 5 6 1 7 8 2

	ПЛАН ИСПЫТАНИЙ

 

 

 

	ДОВОДКА ИЗДЕЛИЯ

 

 

1.3. Отображение концептуальной инфологической модели на реляционную модель

1.3.1. Совместное представление ключевых элементов взаимосвязанных сущностей инфологической модели

 

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

Общее правило в связи с этим заключается в следующем: ключ порожденной сущности добавляется в исходную.

Следующая задача - правильно определить для двух взаимосвязанных сущностей исходную и порожденную.

Правило 1. Если между сущностями модели существует однонаправленная простая или сложная связь, то порожденной считается сущность, к которой эта связь направлена. В качестве примера рассмотрим связь между сущностями "Справочник параметров" и "Состав двигателя" общей модели (рис. 2).

Фрагмент модели и результат его отображения на реляционную модель показаны на рис. 3.

 

Рис. 3. Реализация сложной однонаправленной связи :

а - фрагмент исходной схемы;

б - результат отображения фрагмента схемы на

отношения реляционной модели

а)

Справочник параметров

 

Наименование параметра

Размерность параметра

 

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

 

б)

 

Отношение 1

Наименование параметра

Номер двигателя

Номер узла

Размерность параметра

 

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

 

Как видим, сцепленный ключ порожденной сущности НОМЕР ДВИГАТЕЛЯ + НОМЕР УЗЛА добавляется в исходную сущность "Справочник параметров", результате чего образуется отношение 1. Порожденная сущность "Состав двигателя" остается без изменений и образует отношение 2.

Замечание 1. Отношение 1 не соответствует требованиям четвертой нормальной формы. Этому вопросу посвящен п.1.4. данной главы.

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

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

Правило 2. Если между сущностями исходной модели существует двунаправленная простая или двунаправленная сложная связь, то для определения исходной сущности необходимо знать частоту использования связей. Исходной будет считаться та сущность, которая имеет исходную связь с большей частотой. Если частота использования связей одинакова или неизвестна, то выбор исходной сущности произволен. После определения исходной и порожденной сущностей реализация связей осуществляется так, как это описано в общем правиле.

В качестве примера рассмотрим сущности "План испытаний" и "Состав двигателя", предположив, что между ними была установлена двунаправленная сложная связь (рис. 4).

 

Рис. 4 - Фрагмент модели базы данных.

 

План испытаний

Номер двигателя

Номер испытания

Шифр методики испытания

 

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла В составе двигателя

 

Если частота использования связи при предпроектном обследовании не определена, то выбор порожденной и исходной сущности произволен. Результат отображения в двух равнозначных вариантах представлен на рис. 5:

а) исходной была определена сущность "План испытаний";

б) исходной была определена сущность "Состав двигателя";

 

Рис. 5. Реализация сложной двунаправленной сложной связи:

 

а) Отношение 1

Номер двигателя

Номер узла

Номер испытания

Шифр методики испытания

 

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла В составе двигателя

 

б)

Отношение 1

Номер двигателя

Номер испытания

Шифр методики испытания

 

Отношение 2

Номер двигателя

Номер узла

Номер испытания

Номер разреша- ющего документа

Наработка узла в составе двигателя

 

 

а) исходная сущность "План испытаний";

б) исходная сущность "Состав двигателя";

 

Если частота использования связи определена, то результат отображения будет определен однозначно (либо "а", либо "б" рис. 5) в зависимости от направления связи с большей частотой.

Замечание 4. Если между сущностями модели существует двунаправленная простая связь, то порядок отображения на отношения реляционной модели точно такой же, как рассмотрено выше. Отличие заключается в следующем. Если порожденной определена сущность с простым ключом, то добавляемый ключ в новом отношении не подчеркивается, отношение не требует дальнейшей нормализации.

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

Замечание 5. В рассмотренном примере в случае "а" отношение 1, в случае "б" отношение 2 требуют дальнейшей нормализации.

Замечание 6. Если во взаимосвязанных сущностях есть одноименные ключи, то при совместном представлении дублирование исключается. В нашем случае обе сущности содержали в качестве составляющего сцепленного ключа "Номер двигателя". При отображении в отношении 1 (случай "а") и в отношении 2 (случай "б") этот ключ представлен один раз.

Правило 3. Если между сущностями исходной модели существует двунаправленная связь разного типа (простая и сложная), то независимо от частоты их использования исходной будет являться та сущность, от которой исходит простая связь.

В качестве примера рассмотрим связь между сущностями "Паспорт двигателя" и "Изделие" (см. рис. 2). Фрагмент модели и результат его отображения на реляционную модель показаны на рис. 6.

 

а) Паспорт двигателя

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

 

 

Изделие

Номер изделия

Наименование изделия

Обозначение изделия

 

б)

 

Отношение 3

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

 

Отношение 4

Номер изделия

Номер двигателя

Наименование изделия

Обозначение изделия

 

Рис. 6. Реализация двунаправленной связи разного типа:

а) фрагмент исходной модели;

б) результат отображения фрагмента модели на отношения

реляционной модели.

 

Почему за основу отображения берется простая связь? Для ответа на этот вопрос рассмотрим фрагмент модели с изображением экземпляров сущностей (рис. 7).

Предположим, что в предметной области экземпляры объектов двигатель и изделие связаны так, как это отражает экземпляр модели на рис. 8.

Используя правило 3, выполним отображение фрагмента модели (рис. 7) на совокупность отношений реляционной модели. В результате будем иметь фрагмент реляционной модели, показанной на рис. 9. Ключ порожденной сущности "Паспорт двигателя" размещен в экземплярах исходных сущностей "Изделие" строго в соответствие с экземпляром модели (рис. 8). В результате получено отношение "Изделие с двигателем". Отношение "Паспорт двигателя" не изменилось. Изображенные на рис. 9 отношения могут быть физически реализованы.

 

Паспорт двигателя

 

Номер двигателя	Дата изготовления	Место Изготовления	Наработка двигателя
ДВ1	01.12.83	Харьков
ДВ2	06.10.87	Новосибирск
ДВ3	12.08.85	Харьков
ДВ4	04.11.86	Ленинград
. . .	. . .	. . .	. . .

 

 

Изделие

 

Номер изделия	Наименование изделия	Обозначение изделия
НИ1	ИЗДЕЛИЕ 1
НИ2	ИЗДЕЛИЕ 2
НИ3	ИЗДЕЛИЕ 3
НИ4	ИЗДЕЛИЕ 4
НИ5	ИЗДЕЛИЕ 5
НИ6	ИЗДЕЛИЕ 6
НИ7	ИЗДЕЛИЕ 7
НИ8	ИЗДЕЛИЕ 8
. . .	. . .	. . .

 

Рис. 7. Фрагмент модели БД «Эксперимент»

 

 

Рис. 8. Экземпляр модели взаимосвязи объектов Двигатель и Изделие

 

Паспорт двигателя

 

Номер двигателя	Дата изготовления	Место Изготовления	Наработка двигателя
ДВ1	01.12.83	Харьков
ДВ2	06.10.87	Новосибирск
ДВ3	12.08.85	Харьков
ДВ4	04.11.86	Ленинград
. . .	. . .	. . .	. . .

 

Изделие с двигателем

 

Номер изделия	Номер двигателя	Наименование изделия	Обозначение изделия
НИ1	ДВ1	ИЗДЕЛИЕ 1
НИ2	ДВ2	ИЗДЕЛИЕ 2
НИ3	ДВ1	ИЗДЕЛИЕ 3
НИ4	ДВ2	ИЗДЕЛИЕ 4
НИ5	ДВ2	ИЗДЕЛИЕ 5
НИ6	ДВ2	ИЗДЕЛИЕ 6
НИ7	ДВ4	ИЗДЕЛИЕ 7
НИ8	ДВ3	ИЗДЕЛИЕ 8
. . .	. . .	. . .	. . .

 

Рис. 9. Фрагмент реляционной модели БД "Эксперимент". Отображение

простой связи объектов изделие-двигатель.

 

Рассмотрим альтернативный вариант отображения, когда за основу для реализации берется не простая, а сложная связь между сущностями (см. рис. 7). Экземпляр модели остается тем же (см. рис. 8). Результат отображения представлен на рис. 10.

 

 

Номер двигателя	Дата изготовления	Место изготовления	Наработка двигателя	Номер изделия
ДВ1	01.12.83	Харьков		НИ1 НИ3
ДВ2	06.10.87	Новосибирск		НИ4 НИ5 НИ6 НИ2
ДВ3	12.08.85	Харьков		НИ8
ДВ4	04.11.86	Ленинград		НИ7

 

Изделие

 

Номер изделия	Наименование изделия	Обозначение изделия
НИ1	ИЗДЕЛИЕ 1
НИ2	ИЗДЕЛИЕ 2
НИ3	ИЗДЕЛИЕ 3
НИ4	ИЗДЕЛИЕ 4
НИ5	ИЗДЕЛИЕ 5
НИ6	ИЗДЕЛИЕ 6
НИ7	ИЗДЕЛИЕ 7
НИ8	ИЗДЕЛИЕ 8

 

Рис. 10. Фрагмент реляционной модели БД "Эксперимент". Отображение

сложной связи объектов изделие-двигатель.

 

В этом случае (рис. 10) физические записи отношения "Паспорт двигателя с изделием" будут иметь переменную длину. Избавиться от этого можно только введением избыточности, т.е. повторяя для каждого изделия номер соответствующего двигателя и все его характеристики.

Как видим, аномалии возникли, когда исходной была определена сущность с исходящей сложной связью. Поэтому данный вариант отображения отбрасывается как заведомо худший.

Правило 3 исчерпывает все множество правил отображения исходной модели на реляционную логическую модель.

Применив правила отображения ко всем взаимосвязанным сущностям (см. рис. 2), получим совокупность отношений реляционной модели, показанную на рис. 11.

 

Отношение 1

Наименование параметра

Номер двигателя

Номер узла

Размерность параметра

(Связь 1)

 

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

 

Отношение 3

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

 

 

Отношение 4

Номер изделия

Номер двигателя

Наименование изделия

Обозначение изделия

(Связь 2)

 

Отношение 5

Номер двигателя

Номер испытания

Шифр методики испытания

(Связь 3,4)

 

Отношение 6

Номер испытания

Номер двигателя

Номер узла

Наименование испытания

Статус испытания

(Связь 5)

 

Отношение 7

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

(Связь 6)

 

Отношение 8

Номер двигателя

Наименование параметра

Действующая величина параметра

(Связь 7,8)

 

Отношение 9

Номер изделия

Наименование дефекта

Шифр счета по дефекту

 

Рис. 11. Результат отображения исходной модели на отношения реляционной модели

 

Полученную модель необходимо проверить на полноту представления информации.

 

1.3.2. Анализ полноты представления информации

 

С точки зрения полноты представления информации анализируется результат отображения (рис. 11) в сравнении с исходной схемой (рис. 2 и рис. 1).

Анализу подлежат:

- полнота представления связей;

- полнота представления характеристик объектов и процессов.

 

 

1.4. Нормализация отношений

 

Этот метод был разработан Коддом. Введены новые понятия:

Домен – набор значений элементов данных одного типа, т.е. один столбец таблицы.

Простой атрибут – атрибут, значения которого атомарны, т.е. неделимы.

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

Составной ключ – это ключ, который содержит несколько атрибутов.

Ключ должен обладать двумя свойствами:

1) однозначная идентификация записей: записи должны однозначно определяться значением ключа;

2) отсутствие избыточности: никакой атрибут нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации.

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

Коддом выделены 3 нормальных формы отношений.

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

1.4.1. П е р в а я н о р м а л ь н а я ф о р м а

Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты – простые.

Пример 1.

Ненормализованное отношение R1:

Табельный номер	ФИО	Оклад	Комната	Телефон	Дети
Имя	возраст
	Иванов Л.А.				Саша Женя Вася
	Темкин М.Т.				Вова
	Кошкин В.К.				Женя Вова

 

 

1НФ:

Табельный номер родителя	Имя ребенка	Возраст ребенка	ФИО	Оклад	Комната	Телефон
	Саша		Иванов Л.А.
	Женя		Иванов Л.А.
	Вася		Иванов Л.А.
	Вова		Темкин М.Т.
	Женя		Кошкин В.К.
	Вова		Кошкин В.К.

 

Ненормализованное отношение легко сделать нормализованным. Такое представление может привести к изменению ключа.

1.4.2. В т о р а я н о р м а л ь н а я ф о р м а

Ф у н к ц и о н а л ь н а я з а в и с и м о с т ь

Задавая отношения над элементами данных, разработчик должен интересоваться тем, какие из атрибутов объекта являются зависимыми. Термин функциональная зависимость означает следующее: атрибут В отношения R функционально зависит от атрибута А того же отношения, если в каждый момент времени каждому значению атрибута А соответствует не более чем одно значение атрибута В, связанного с А в отношении R.

Утверждения что В функционально зависит от А, означает то же самое, что А определяет В, т.е. если в какой-то момент времени известно значение А, то можно получить и значение В.

Рассмотрим функциональные зависимости примера А:

1) Таб. Номер функционально зависит от ФИО, и одновременно ФИО функционально зависит от таб. номера:

Табельный номер < - > ФИО

Действительно, каждому сотруднику ставится в соответствие только один таб. номер, а конкретный таб. номер в определенный момент времени соответствует только одному сотруднику.

2) номер комнаты функционально зависит от ФИО, если сотрудник имеет рабочее место в одной комнате:

ФИО < - > номер комнаты

3) если в каждой комнате установлен один телефон, то номер телефона функционально зависит от номера комнаты:

номер комнаты < - > номер телефона

Пример 2.

 

Номер * служащего

Имя * Служащего

Зарплата

Номер Проекта

Дата окончания

 

* - отмечены основные атрибуты (элементы возможных ключей)

 

Функциональные зависимости этого отношения:

1) номер служащего < - > имя служащего;

2) зарплата - > имя служащего

или

зарплата - > номер служащего;

3) номер проекта - > имя служащего

или

номер проекта - > имя служащего

или

номер проекта - > номер служащего

4) дата окончания - > имя служащего

или

дата окончания - > номер служащего

или

дата окончания - > номер проекта

Атрибут НОМЕР-СЛУЖАЩЕГО не является функционально зависимым от атрибута ЗАРПЛАТА, т.к. несколько служащих могут иметь одинаковую зарплату. Аналогично НОМЕР СЛУЖАЩЕГО не является функционально зависимым от атрибута НОМЕР ПРОЕКТА; атрибут ДАТА ОКОНЧАНИЯ наоборот обладает такой зависимостью. Никакие другие атрибуты не являются зависимыми от атрибута НОМЕР ПРОЕКТА. Эти функциональные зависимости более ясно можно представить с помощью диаграммы:

 

НОМЕР СЛУЖАЩЕГО *

 

ИМЯ СЛУЖАЩЕГО *

 

ЗАРПЛАТА

 

НОМЕР ПРОЕКТА

 

ДАТА ОКОНЧАНИЯ

 

Если В функционально зависит от А, то из вершины А проводится стрелка в вершину В.

 

Пример 3:

Атрибут может функционально зависеть не от какого-то одного атрибута, а от целой группы атрибутов. Рассмотрим, например, следующее отношение, содержащее информацию о расходе рабочего времени программистов:

 

Деятельность программиста

Номер * программиста

Номер * программы

Имя * программиста

Имя * программы

Количество рабочих часов

 

Атрибут КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ функционально зависит от составного ключа (НОМЕРПРОГРАММИСТА,НОМЕРПРОГРАМЫ) или от одного из следующих возможных ключей: (НОМЕР ПРОГРАММИСТА, ИМЯ ПРОГРАММЫ), (ИМЯ ПРОГРАММИСТА, НОМЕР ПРОГРАММЫ) или (ИМЯ ПРОГРАММИСТА, ИМЯ ПРОГРАММЫ). Предполагается, что среди программистов нет однофамильцев и что две программы не могут иметь одинаковых имен. Функциональные зависимости этого отношения:

 

НОМЕР ПРОГРАММИСТА *

 

НОМЕР ПРОГРАММЫ *

 

ИМЯ ПРОГРАММИСТА *

 

ИМЯ ПРОГРАММЫ *

 

КОЛИЧЕСТВО РАБОЧИХ ЧАСОВ

 

Нетрудно убедится, что в нормализованном отношении все не ключевые атрибуты функционально зависят от ключа отношения.