Главы 2, 3 - Кафедра анализа данных и исследования операций

Ульман Дж. Базы
(главы 2, 3)
ББК
УДК
У51
данных на
32.973.2-01
У51
[[681.3.016: 519.682] +681.3-181.4])-
Паскале
03 == 20
Ульман Дж.
Базы данных на Паскале/Пер, с англ. М. В. Сергиевского, А. В. Шалашова; Под ред. Ю. И. Топчеева.-М.:
Машиностроение, 1990.-368.: ил.
ISBN 5-217-00628-5
В книге английского автора процесс создания баз данных впервые описывается с
позиций инженера-программиста. Многочисленные примеры структур данных и запросов
дают возможность читателю быстро овладеть мощными языковыми средствами и могут
быть легко обобщены на ситуациях, возникающих в технических областях. Основное
внимание автор уделяет широко распространенным реляционным базам данных,
реализуемых на мини- и микроЭВМ, в частности на персональных компьютерах.
Для инженеров-разработчиков и пользователей баз данных во всех областях
техники.
Оригинал книги опубликован на английском языке
издательством Оксфорд Юниверсити Пресс, г. Оксфорд, Англия
ПРОИЗВОДСТВЕННОЕ ИЗДАНИЕ
ДЖУЛИАН УЛЬМАН
БАЗЫ ДАННЫХ
НА ПАСКАЛЕ
Ордена Трудового Красного Знамени издательство <Машиностроение>
107076, Москва, Стромынский пер., 4
Типография № 6 ордена Трудового Красного Знамени
издательства <Машиностроение> при Государственном комитете СССР по печати.
193144, Ленинград, ул. Моисеенко, 10.
ISBN 5-217-00628-5 (СССР)
@ Julian Ullmann, 1985
ISBN 0-19-859642-1 (Велико- @ Перевод на русский язык и
британия)
ответы к упражнениям,
М. В. Сергиевский, А. В. Шалашов, 1990
ОГЛАВЛЕНИЕ
Введение .....................
Глава 2. РЕЛЯЦИОННАЯ АЛГЕБРА
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Введение
Музыкальные файлы
Операции и операнды
Проектирование
Выбор
Простейшие запросы
Соединение
2.7.1 Соединение по одному полю
2.7.2. Использование соединения при ответах на запросы
2.7.3. Соединение по нескольким полям
2.8. Упражнения
2.9. Объединение
2.10. Пересечение
2.11. Вычитание
2.12. Деление
2.13. Умножение
2.14. Упражнения.
2.15. Оптимизация запросов
Глава
3. ПРИНЦИПЫ
НОРМАЛИЗАЦИИ
3.1. Распределение полей по файлам
3.2. Полная декомпозиция
3.3. Дублирование информации
3.3.1. Примеры дублирования
3.3.2. Ключи-кандидаты
3.4. Присоединенные записи
3.5. Нормализация
3.5.1. Пятая нормальная форма
3.5.2. Упражнения
3.6. функциональная зависимость
3.6.1. 0пpеделениe функциональной зависимости
3.6.2. Теорема Хита
3.7. Нормализация на основе функциональной зависимости.
3.7.1. Первая нормальная форма
3.7.2. Вторая нормальная форма
3.7.3. Третья нормальная форма
3.7.4. Нормальная форма Бойса-Кодда
3.8. Упражнения
3.9. Четвертая нормальная форма
3.10. Объекты и атрибуты
3.10.1. Функциональная зависимость атрибутов от объектов
3.10.2. Построение набора файлов по эмпирическим данным
З.10.З. Преобразование набора файлов
3.11. Упражнения
ВВЕДЕНИЕ
Обширный
предмет исследований и разработок, объединяемых под общим
названием «Технология проектирования баз данных», принадлежит к числу важнейших
разделов современной информатики. Этим определяется и место данного предмета в
профессиональной подготовке будущих специалистов по вычислительной технике.
Настоящая книга адресована в первую очередь студентам университетов и
технических вузов, изучающим Паскаль в качестве базового языка программирования.
Автор считал одной из своих главных задач продемонстрировать связь технологии
проектирования баз данных и методологии Паскаля. По его мнению, такой подход
расширяет кругозор студентов, стимулирует формирование у них представления о
вычислительной технике как единой области знаний. Гораздо менее этому
способствует традиционное изложение предмета в виде набора изолированных
дисциплин.
Автор стремился построить книгу таким образом, чтобы изучение технологии
проектирования баз данных могло вестись на более раннем этапе цикла,
посвященного вычислительной технике, чем это принято в настоящее время. Опыт
преподавания показывает, что такие понятия, как пятая нормальная форма или
структуры данных КОДАСИЛ,
вполне доступны хорошо успевающему первокурснику.
Между тем, раннее знакомство с технологией проектирования баз данных
представляется желательным по многим соображениям.
а. Очень важно, чтобы уже в самом начале обучения основам вычислительной
техники студент приобщался к ее практическому применению, и базы данных
предоставляют для этого самый разнообразный материал.
б. Технология баз данных включает ряд весьма изящных математических
построений, особенно в теории нормализации. Знакомство с ним может послужить
стимулом для углубленного изучения проблем вычислительной техники.
в. Внутренние механизмы функционирования
современных систем управления
базами данных отличаются значительной сложностью, и разобраться в них бывает
непросто даже старшекурснику. Переход к более ранней форме обучения позволяет
сосредоточить внимание студента прежде всего на общих принципах построения таких
систем, а не на деталях, представляющих интерес с точки зрения профессионала.
г. Курс по базам данных, прочитанный на одном из первых семестров, может
послужить хорошей основой для практикума по программированию, ориентированного
на применение файлов, записей, указателей, методов косвенной адресации. Подобный
курс будет также способствовать более осознанному усвоению общих понятий
вычислительной техники, таких, например, как иерархия уровней программирования.
д. Следует, наконец, упомянуть и о тех трудностях, с которыми сталкивается
преподаватель, читающий на одном из последних семестров курс по архитектуре баз
данных, если технология проектирования баз данных изучается в параллель с этим
курсом или даже позже.
Важной особенностью книги является то, что в ней соседствуют, дополняя друг
друга, материалы по технологии проектирования баз данных и элементы обработки
информации. Так, например, гл. 9 в основном посвящена проблемам целостности
баз данных, однако в ней упоминаются и некоторые методы контроля информации. В
гл. 6 обсуждение вопросов групповой обработки сочетается с описанием В-деревьев,
используемых впоследствии для организации доступа к данным.
Здравый смысл подсказывает, что изучению основ технологии баз данных должно
предшествовать хотя бы минимальное знакомство с практическими приложениями
файлов. По этой причине гл. 1 начинается с описания типичного предприятия,
использующего в своей деятельности различные виды данных. В этой же главе
приводятся наглядные примеры файлов, записей, полей и ключей.
Операции с данными первоначально исследуются в книге с позиций
реляционной теории. Такая методика дает возможность получить более абстрактные и
вместе с тем более простые описания по сравнению с описаниями на уровне анализа
путей доступа к данным. Знакомство с элементами указанной теории значительно
облегчает студенту последующее усвоение таких понятий, как пути доступа,
уяснение их роли в реализации действий на более высоком уровне реляционных
соотношений. Между тем по-прежнему бытует традиционная и, по мнению автора,
совершенно ошибочная практика изучения методов организации файлов до реляционной
теории. Подобный подход является лишь отражением того, как исторически
складывается развитие этой области знаний, и не может рассматриваться как
результат поиска наиболее эффективных методов преподавания данного предмета.
Для иллюстрации излагаемых принципов и книге было введено всего два языка один язык запросов реляционной алгебры и один язык более низкого уровня,
являющийся, по существу, дополнением Паскаля. Из всего многообразия реляционных
языков запросов был выбран язык реляционной алгебры, поскольку его операции
весьма удобны при выводе нормальных форм, описываемых в гл. 3. Кроме того, эти
операции широко используются в гл. 7 и 8. Реляционная алгебра представлена как
самостоятельный язык, не погруженный в среду языка более высокого уровня.
На примере языка нижнего уровня предполагалось продемонстрировать студентам
соотношение между средствами программирования путей доступа к базе данных и
стандартными средствами Паскаля. С этой целью в гл. 5 и 6 Паскаль был дополнен
небольшим набором процедур, в том числе INSERT, FIND и REMOVE. Подобное
расширение в какой-то мере приближает
Паскаль к фирменным
языкам
манипулирования данными. Разумеется, это расширение является минимальным и не
идет ни в какое сравнение с другими дополнительными средствами, за счет которых
Паскаль приобретает некоторые возможности, свойственные лишь реляционным языкам
запросов.
Опыт показывает, что целесообразно размещать материал в том порядке, в
котором он лучше усваивается студентом, даже если при этом приходится нарушать
традиционную логику, идя от частного к общему. Именно поэтому книга начинается с
почти элементарных практических примеров, а завершается в гл. 9 анализом
достаточно абстрактных для начинающего проблем организационного характера. Вряд
ли гл. 9 пришлась бы по вкусу читателю, будь она в самом начале книги, хотя во
многих учебных пособиях с этого примерно я начинается изложение предмета.
В завершение автору хотелось бы поблагодарить Спобана Норта, Хью Лэфферти,
Джима Мак-Грегора и Лоренса Эткинсона за их конструктивные замечания по
содержанию некоторых разделов рукописи. Дополнительные средства Паскаля,
описанные в книге, были полностью реализованы Нортом на ЭВМ PRIMOS
750, оснащенной системой PRIMOS (см. A Pascal database management system.
Journal of Pascal, Ada and Modula 2, Vol. 3, No. 6, 1984, pp 15--22).
Шеффилд,
декабрь 1984
Дж. УЛЬМАН
ГЛАВА 2
РЕЛЯЦИОННАЯ
АЛГЕБРА
2.1. ВВЕДЕНИЕ
Если файлы хранятся в памяти компьютера, пользователь не может сам
взять и прочитать или исправить их содержимое, как в добрые старые времена,
когда они хранились в папках с бумагами. Вместо этого он должен скомандовать
машине, чтобы та проделала за него требуемые операции. Но иногда пользователю
бывает нужно выполнить такие действия, которые крайне сложно, а зачастую и
невозможно запрограммировать на обычном языке, в том числе на Паскале. В таких
случаях приходится переходить на специальный язык обработки данных,
представляющий расширение стандартного языка программирования. Альтернативой
может служить высокоуровневый язык запросов - специализированный язык для
работы с файлами. Между языками запросов и обработки данных трудно провести
четкую границу, и некоторые специалисты предпочитают не различать их вовсе.
Примером языков подобного типа является простейший язык запросов на основе
реляционной алгебры. Существуют и другие, порой весьма изощренные и обладающие
широкими возможностями языки, по форме напоминающие примитивный английский,
и благодаря этому значительно более удобные в обращении. Начнем, однако, именно
с реляционной алгебры. Этот сравнительно новый раздел математики послужил
теоретической основой для описания действий, выполняемых над группами файлов.
Определенные в ней элементарные операции реализуются в любом языке запросов
независимо от его внешнего оформления.
2.2. МУЗЫКАЛЬНЫЕ
ФАЙЛЫ
Воспользуемся набором намеренно упрощенных
будут именоваться музыкальными.
файлов, которые в дальнейшем
Музыкальные файлы содержат информацию
о музыкантах, музыкальных
произведениях и обстоятельствах их исполнения. Нескольких музыкантов, образующих
единый коллектив, назовем ансамблем - это может быть классический оркестр,
джазовая группа, квартет, квинтет и т. д. К музыкантам причислим исполнителей
(играющих на одном или нескольких инструментах), композиторов, дирижеров и
руководителей ансамблей.
Все даты в файлах будут представлены восьмизначными числами, в которых
первая слева четверка цифр указывает год, следующая пара - номер месяца, а две
последние цифры - число месяца. В частности, 19910507 обозначает <7 мая 1991 г.>
Достоинство такой непривычной записи дат в том, что их можно использовать
непосредственно как операнды в операциях сравнения. Если, например, d =
19891102, можно утверждать, что справедливо неравенство 19910506 > d.
Дадим теперь краткую характеристику музыкальных файлов и входящих в них
полей.
МУЗЫКАНТЫ
(MUSICIANS)
НОММУЗ
(MNO)
ИМЯ МУЗ
(MNAME)
ДАТАРОЖ
(BDATE)
СТРАНАРОЖ
(BCOUN TRY)
СОЧИНЕНИЯ
(COMPOSITIONS)
НОМСОЧ
(CNO)
НАЗВАНИЕ
(TITLE)
НОММУЗ
(MNO)
ДАТАСОЧ
(CDATE)
АНСАМБЛИ
(ENSEMBLES)
НОМАНС
(ENO)
НАЗВАНС
(ENAME)
СТРАНАНС
(ECOUNTRY)
НОММУЗ
(MNO)
{Имя файла, содержащего персональную
информацию о музыкантах. Ниже
перечислены поля этого файла}
{Номер музыканта. Поле служит первичным
ключом файла, а также используется как
перекрестная ссылка)
{Имя музыканта. Для простоты
записывается только фамилия)
{Дата рождения}
(Страна происхождения)
{Имя файла, содержащего краткую
информацию о сочинениях. Ниже
перечислены поля файла)
{Номер сочинения. Поле служит первичным
ключом файла, а также используется как
перекрестная ссылка}
{Название произведения)
{Номер музыканта, присвоенный
композитору)
{Дата создания произведения)
{Имя файла, содержащего информацию об
ансамблях. Ниже перечислены
поля файла}
{Номер ансамбля. Поле служит первичным
ключом файла, а также используется как
перекрестная ссылка}
{Название ансамбля}
(Страна, где был организован
ансамбль)
{Номер музыканта, присвоенный
руководителю ансамбля)
ИСПОЛНЕНИЯ
(PERFORMANCES)
НОМСОЧ
(CNO)
{Имя файла, содержащего информацию об
исполнениях сочинений. Ниже
перечислены поля файла)
{Номер исполненного сочинения}
ДАТАИСП
(PDATE)
{Дата исполнения)
ГОРОД
(TOWN)
СТРАНА
(COUNTRY)
НОММУЗ
(MNO)
{Место, где было исполнено
сочинение)
{Страна, где было исполнено сочинение)
{Номер музыканта, присвоенный дирижеру
ансамбля, исполнявшего сочинение)
НОМАНС
(ENO)
{Номер ансамбля, исполнявшего
сочинение)
ИСПОЛНИТЕЛИ
(PERFORMERS)
{Имя файла, содержащего информацию о
специальностях и квалификации
исполнителей (некоторые из них могут
играть на нескольких инструментах, а
другие не умеют ни на одном).
Ниже перечислены поля файла)
{Номер исполнителя. Поле служит
первичным ключом файла, а также
используется как перекрестная ссылка)
{Номер музыканта, присвоенный
исполнителю}
{Инструмент, на котором играет
исполнитель}
{Оценка качества исполнения)
НОМИСП
(PNO)
НОММУЗ
(MNO)
ИНСТРУМЕНТ
(INSTRUMENT)
ОЦЕНКА
(GRADE)
УЧАСТНИКИ АНСАМБЛЕЙ
(ENSEMBLES МЕМВЕRS)
{Имя файла, содержащего информацию о
том, в каких ансамблях играют
исполнители. Ниже перечислены поля
файла}
{Номер ансамбля)
{Номер исполнителя}
НОМАНС
(ENO)
НОМИСП
(PNO)
Приведем пример содержимого музыкальных файлов, заполнив каждый из них
всего несколькими записями. С его помощью будут наглядно проиллюстрированы
описываемые далее операции реляционной алгебры. Вообще достоинства реляционной
алгебры проявляются более наглядно, когда приходится манипулировать десятками
тысяч записей, однако обилие данных затрудняет восприятие. Кроме того,
соотношения реляционной алгебры одинаково справедливы для файлов, содержащих и
многие тысячи, и единицы записей, как в представленном примере.
МУЗЫКАНТЫ
НОММУЗ
М1
М2
МЗ
М4
М5
М6
М7
М8
М9
ИМЯМУЗ
ЭЙБИЙСКИЙ
БИСИЙСКИЙ
СИДИЙСКИЙ
ЭЙБИЙСКИЙ
ЭЙЭФСКИЙ
БИДИЙСКИЙ
ЭЙСИЙСКИЙ
СИДИЙСКИЙ
ДИБИЙСКИЙ
ДАТАРОЖ
19410609
18181211
18980404
19360621
19510919
19021025
19471104
18980404
19540130
СТРАНАРОЖ
УДЙЛАНДИЯ
ЗЕДЛАНДИЯ
ЭКСЛАНДИЯ
УАЙЛАНДИЯ
ЗЕДЛАНДИЯ
ТИЛАНДИЯ
УАЙЛАНДИЯ
ТИЛАНДИЯ
УАЙЛАНДИЯ
СОЧИНЕНИЯ
номсоч
С1
С2
СЗ
С4
С5
НАЗВАНИЕ
ЭЛПИС
ЭМТЬЮН
КЕЙСОНГ
ЭЙЧТЬЮН
ЭЛПИС
НОММУЗ
М5
М9
МЗ
М5
МЗ
ДАТАСОЧ
19830605
19851108
19340120
19840929
19290530
С6
КЕЙСОНГ
АНСАМБЛИ
HOMAHC
Е1
E2
E3
E4
E5
E6
E7
ИСПОЛНЕНИЯ
НОМСОЧ
С5
С1
С5
СЗ
С5
С6
Cl
С4
НАЗВАНС
ЭЙЗ
ВИЗ
сиз
АЙЗ
ДИЗ
ЭФС
ВИЗ
ДАТАИСП
19860530
19860615
19860622
19860622
19860703
19860705
19860711
19860719
ИСПОЛНИТЕЛИ
НОМИСП
Р1
Р2
РЗ
Р4
Р5
Р6
Р7
Р8
Р9
НОММУЗ
М1
М1
М1
М4
М5
М5
М9
М9
М7
УЧАСТНИКИ АНСАМБЛЯ
НОМАНС
Е1
Е1
Е1
E2
E2
Е3
E4
E4
E4
E5
Е5
Е6
E6
E7
Е7
2.3. ОПЕРАЦИИ И
ОПЕРАНДЫ
ГОРОД
ТИТОН
АРБИ
ЭСТОН
ЭСФИЛД
ЭСТОН
АРБИ
ТИБИ
АРБИ
М5
19821204
СТРАНАНС
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
ТИЛАНДИЯ
ЗЕДЛАНДИЯ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
ЗЕДЛАНДИЯ
СТРАНА
ТИЛАНДИЯ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
ТИЛАНДИЯ
ЗЕДЛАНДИЯ
ЭКСЛАНДИЯ
УАЙЛАНДИЯ
ИНСТРУМЕНТ
САКСОФОН
ФЛЕЙТА
ФОРТЕПИАНО
ТРУБА
СКРИПКА
АЛЬТ
КЛАРНЕТ
САКСОФОН
ФОРТЕПИАНО
НОМИСП
Р5
Р8
Р9
Р5
РЗ
Р9
Р4
Р1
Р7
Р5
Р9
P1
Р7
РЗ
Р5
НОММУЗ
М7
М5
М7
М4
М5
М5
М4
НОММУЗ
М9
М1
М9
М1
М9
М7
М1
М4
НОМАНС
ЕЗ
E6
E5
Е1
E5
E4
Е1
E2
ОЦЕНКА
ОТЛИЧНО
СРЕДНЕ
СКВЕРНО
ОТЛИЧНО
ОТЛИЧНО
ПЛОХО
ОТЛИЧНО
СКВЕРНО
СРЕДНЕ
Имена и значения полей, образующих запись, определяют ее тип.
Неупорядоченную совокупность однотипных записей называют отношением (Термин
<отношение> в оригинале – <реляция>. Отсюда и произошло название раздела
математики <реляционная алгебра>. - Прим. пер.). Понятие файла по сравнению с
отношением является более общим - действительно, в файле могут содержаться
записи разных типов (хотя в книге всегда подразумевается противоположное). Кроме
того, существуют способы организации файлов, делающие возможной упорядоченность
входящих в них записей и ее использующие. Предваряя обсуждение операндов
реляционной алгебры, рассмотрим простейший оператор Паскаля:
F: = (А + В)* С - D.
Здесь А, В, С и D -операнды, а знаки +, * и обозначают выполняемые
над ними операции. Итоговый результат присваивается переменной F.
В реляционной алгебре и операнды и результата всех действий являются
отношениями. Несколько упрощая, будем в дальнейшем отождествлять отношения
реляционной алгебры с файлами. Порядок размещения записей в файлах-операндах
никак не учитывается при выполнении операций, а в файлах-результатах
их распределение считается произвольным.
В работах по теории отношений и реляционной алгебре аналоги записей
иногда именуются кортежами, полей - доменами, однако в книге эта специальная
терминология не употребляется.
Познакомимся теперь с операциями, используемыми в реляционной алгебре.
2.4. ПРОЕКТИРОВАНИЕ
В операции проектирования участвует единственный операнд, который
обозначим как ИМЯФАЙЛА
(FNAME). Это может быть и файл с исходными данными, и
файл, созданный в результате преобразований реляционной алгебры. Дадим следующее
определение операции проектирования
proj список имен полей (ИМЯ ФАЙЛА)
В списке имен, следующем за оператором proj, должны упоминаться только те
поля, что входят в состав записей ИМЯФАЙЛА. Результат операции проектирования
формируется следующим образом:
а) Из файла ИМЯФАЙЛА
удаляются все поля, имена которых не фигурируют в
списке;
б) Из полученной в п. а) совокупности записей удаляются повторяющиеся, так
что итог операции не содержит одинаковых записей.
Первый пример - proj ИНСТРУМЕНТЫ (ИСПОЛНИТЕЛИ)
САКСОФОН
ФЛЕЙТА
ФОРТЕПИАНО
ТРУБА
СКРИПКА
АЛЬТ
КЛАРНЕТ
Как можно видеть, каждый инструмент назван лишь однажды.
Второй пример - proj ИМЯМУЗ, СТРАНАРОЖ (МУЗЫКАНТЫ)
ЭЙБИЙСКИЙ
БИСИЙСКИЙ
СИДИЙСКИЙ
ЭЙЭФСКИЙ
БИДИЙСКИЙ
ЭЙСИЙСКИЙ
СИДИЙСКИЙ
ЛИВИЙСКИЙ
УАЙЛАНДИЯ
ЗЕДЛАНДИЯ
ЭКСЛАНДИЯ
ЗЕДЛАНДИЯ
ТИЛАНДИЯ
УАЙЛАНДИЯ
ТИЛАНДИЯ
УАЙЛАНДИЯ
2.5. ВЫБОР
Подобно проектированию, операция выбора имеет единственный операнд,
который может быть файлом с исходными данными или файлом, полученным в
результате преобразований реляционной алгебры. Синтаксис операции выбора таков:
sel условие (ИМЯФАЙЛА)
Итогом операции является совокупность записей ИМЯФАЙЛА, объединяющая лишь
те из них, которые удовлетворяют заданному условию. Например, в результате
операции
sel СТРАНАРОЖ='УАЙЛАНДИЯ' (МУЗЫКАНТЫ)
формируется следующий
М1
М4
М7
М9
ЭЙБИЙСКИЙ
ЭЙБИЙСКИЙ
ЭЙСИЙСКИЙ
ЛИВИЙСКИЙ
набор записей:
19410609
19360621
19471104
19540130
УАЙЛАНДИЯ
УАЙЛАНДИЯ
УАЙЛАНДИЯ
УАЙЛАНДИЯ
Обратим внимание на то, что в приведенном примере название страны
заключено в апострофы. Они указывают, что эта строка символов, называемая также
литералом, является значением поля СТРАНАРОЖ. В то же время СТРАНАРОЖ
записано без апострофов, поскольку это имя поля, а не его значение. Данное
правило относится к любым одиночным символам и строкам, представляющим
литералы. Их всегда помещают в апострофы, чтобы отличать от имен полей,
переменных и др., которые, напротив, нельзя записывать в апострофах. Числовые
константы также записываются без апострофов, за исключением тех случаев, когда
они выступают как символьные строки. В частности, из файла МУЗЫКАНТЫ
можно
выбрать записи о музыкантах, родившихся ранее 1946 г., с помощью следующей
операции:
sel ДАТАРОЖ > 19451231 (МУЗЫКАНТЫ)
Здесь 19451231 понимается как целая константа, а не как строка символов, и
поэтому не заключается в апострофы.
Условие, определяющее результат выбора, представляет собой выражение,
которое может включать операции сравнения <, =, >, <=, => и <>, а также
логические операции and (<И>), ог (<ИЛИ>) и not (<НЕ>). В то же время запрещено
использовать арифметические операции +,-,
*,/. Любой операнд, входящий в
условие, сам не может быть результатом преобразований реляционной алгебры. В
остальном условия записываются согласно правилам стандартного Паскаля.
Предположим, например, что из файла МУЗЫКАНТЫ требуется выбрать данные
обо всех музыкантах, родившихся в Уайландии не позже 1946 г. Это можно сделать,
воспользовавшись операцией
sel (СТРАНАРОЖ='УАЙЛАНДИЯ') and (ДАТАРОЖ>19451231) (МУЗЫКАНТЫ)
которая дает следующие две записи:
М7
М9
ЭЙСИЙСКИЙ
ЛИВИЙСКИЙ
19471104
19540130
УАЙЛАНДИЯ
УАЙЛАНДИЯ
2.6. ПРОСТЕЙШИЕ ЗАПРОСЫ
Применив операцию проектирования к результату ранее выполненного
выбора, из файла можно извлечь информацию, содержащую ответ на вполне
практический, хотя и очень простой вопрос. Рассмотрим следующий пример.
Запрос: перечислить фамилии всех музыкантов, родившихся
не ранее 1946 г.
Задача решается с помощью операций
proj ИМЯМУЗ
(sel ДАТАРОЖ>19451231
(МУЗЫКАНТЫ)).
Приведем еще один пример.
Запрос: перечислить номера всех музыкантов, играющих на фортепиано, кроме
тех, игра которых оценивается как <скверно>.
Ответ дает следующая пара операций:
proj НОММУЗ
(sel (ИНСТРУМЕНТ-ФОРТЕПИАНО')
and
(ОЦЕНКА <> 'СКВЕРНО')
(ИСПОЛНИТЕЛИ)).
Результат включает единственный номер М7. Ответ, однако, может быть и
<отрицательным>, т. е. не содержать никакой информации. Это демонстрирует
следующий пример.
Запрос: указать все страны и города, в которых любые произведения
исполнялись 22 июня 1986 г.
Этот запрос следует записать таким образом:
proj ГОРОД, СТРАНА (sel ДАТАИСП=19860622 (ИСПОЛНЕНИЯ)).
Ни одной записи, отвечающей заданному условию, не найдено.
2.7. СОЕДИНЕНИЕ
2.7.1. СОЕДИНЕНИЕ ПО
ОДНОМУ
ПОЛЮ
В реляционной алгебре определен целый ряд операций соединения. Ниже будет
рассматриваться лишь одна разновидность соединения, именуемого естественным.
Поэтому далее термином соединение будет обозначаться, если не оговорено иное,
именно этот вид операции.
Очевидно, любое поле записи, подобно переменной Паскаля, является объектом
определенного типа - например, целым числом (INTEGER), вещественным числом
(REAL) или строкой символов (STRING). В операции соединения участвуют два
операнда, которые запишем как ИМЯФАЙЛА1 и ИМЯФАЙЛА2. Здесь и далее считается,
что файлы могут содержать как исходные данные, так и полученные в результате
преобразований реляционной алгебры. Для простоты предположим сначала, что в
состав ИМЯФАЙЛА1 и ИМЯФАЙЛА2 входит ровно одно общее для них поле, имеющее в
обоих файлах одинаковые имя и тип. Например, у файлов МУЗЫКАНТЫ и СОЧИНЕНИЯ
таким общим полем является НОММУЗ.
Что же касается полей, содержащих даты,
то у них разные имена: в первом файле ДАТАРОЖ, во втором - ДАТАСОЧ.
Рассмотрим еще один простой пример. Допустим, в ИМЯФАЙЛА1
присутствуют
поля G1 и F1, содержащие следующую информацию:
G1
d
h
У
F1
3
7
4
В ИМЯФАЙЛА2 имеются поля F1 и G2, содержимое которых таково:
F1
3
3
7
4
4
G2
A
В
А
С
В
Результатом операции соединения
ИМЯФАЙЛА1 join ИМЯФАЙЛА2
является конкатенация каждой записи ИМЯФАЙЛА1 с каждой записью ИМЯФАЙЛА2, у
которых совпадают данные в общем поле, причем само это поле в образующейся
записи помещается лишь однажды. (Конкатенацией называется слияние двух или
нескольких строк в одну).
В
обсуждаемом примере сливаются записи
G2
А
В
F1
3
3
из ИМЯФАЙЛА2 с записью
G1
D
F1
3
из ИМЯФАЙЛА1. Действительно, у них одинаковые значения (равные 3) общего поля
F1. После выполнения операции
ИМЯФАЙЛА1 join ИМЯФАЙЛА2
из этих записей формируются две
G1
d
d
новые:
F1
3
3
G2
А
В
Однако это лишь часть результата. В ИМЯФАЙЛА1 есть запись
G1
h
F1
7
которую можно
cлить c запиcью
F1
7
G2
A
из ИМЯФАЙЛА2, поскольку у них совпадают значения (равные 7) общего поля F1.
Наконец, результат операции должен содержать конкатенацию пары записей
F1
4
4
G2
C
B
из ИМЯФАЙЛА2
G1
y
в запиcью
F1
4
из ИМЯФАЙЛА1. У них в общем поле F1 помещается одно и то же
операции
ИМЯФАЙЛА1 join ИМЯФАЙЛА2
даст cледующую совокупность записей:
G1
F1
d
3
d
3
h
7
У
4
У
4
G2
A
В
A
С
В
2.7.2. ИСПОЛЬЗОВАНИЕ СОЕДИНЕНИЯ ПРИ ОТВЕТАХ
С помощью операции
proj НОММУЗ
(СОЧИНЕНИЯ)
НА
ЗАПРОСЫ
число 4. В итоге
можно получить перечень номеров, присвоенных всем композиторам, т. е.
музыкантам, создавшим хотя бы по одному произведению. Но чтобы узнать имена
всех композиторов, c полями НОММУЗ
в записях файла СОЧИНЕНИЯ
нужно связать
соответcтвующие поля ИМЯМУЗ.
Для этого достаточно произвести соединение
файлов СОЧИНЕНИЯ и МУЗЫКАНТЫ, в результате которого произойдет слияние каждой
записи файла СОЧИНЕНИЯ
с записью файла МУЗЫКАНТЫ, содержащей имя автора.
Таким образом, список имен композиторов сформирует пара операций
proj ИМЯМУЗ
(СОЧИНЕНИЯ join МУЗЫКАНТЫ).
Рассмотрим еще один пример.
Запрос: указать имя и дату рождения каждого композитора, написавшего вещь под
названием <Кейсонг>.
Ответ дает следующая последовательность операций:
proj ИМЯМУЗ, ДАТАРОЖ (sel НАЗВАНИЕ='КЕЙСОНГ' (СОЧИНЕНИЯ) join МУЗЫКАНТЫ).
С помощью операции выбора из файла СОЧИНЕНИЯ выделяются записи всех
сочинений, названных <Кейсонг>. Эти записи соединяются затем с теми записями
файла МУЗЫКАНТЫ, у которых совпадают значения поля НОММУЗ.
Это означает, что
каждая отобранная запись файла СОЧИНЕНИЯ дополняется информацией об авторе
данного произведения. Окончательным итогом описанной последовательности
операций реляционной алгебры являются следующие данные:
СИДИЙСКИЙ
ЭЙЭФСКИЙ
18980404
19510919
Нетрудно убедиться, что это правильный ответ на запрос, могут быть и более
сложные запросы, требующие выполнения двух и более операций соединения.
Приведем пример.
Запрос: перечислить все инструменты, на которых играют в ансамбле <Эйз> из
Зедландии.
Вот выражение реляционной алгебры, которое позволит получить ответ на этот
запрос:
proj ИНСТРУМЕНТ
(proj НОМАНС
(sel (НАЗВАНИЕ='ЭЙЗ') and (СТРАНАНС='ЗЕДЛАНДИЯ') (АНСАМБЛИ))
join УЧАСТНИКИ_АНСАМБЛЕЙ join ИСПОЛНИТЕЛИ).
В результате первого (считая слева) соединения формируется набор номеров
НОМИСП всех участников названного ансамбля. Второе соединение образует
совокупность записей, содержащих названия инструментов, на которых играют
исполнители.
Операции выбора в преобразованиях реляционной алгебры могут выполняться
более чем над одним файлом. Проиллюстрируем это следующим примером.
Запрос: указать, когда в Эксландии исполнялось произведение под названием
<Эмтьюн>.
Ответ на запрос получим с помощью такого выражения:
proj ДАТАИСП
(sel СТРАНАИСП='ЭКСЛАНДИЯ' (ИСПОЛНЕНИЯ)
join proj НОМСОЧ (sel НАЗВАНИЕ='ЭМТЬЮН' (СОЧИНЕНИЯ))).
Еще один пример развивает предыдущий. В нем потребуется вторая операция
соединения.
Запрос: указать автора любого произведения, названного Эмтьюн, которое хотя
бы однажды исполнялось в Эксландии.
На запрос отвечает следующее выражение:
proj
ИМЯМУЗ
(proj НОМСОЧ
(sel СТРАНА='ЭКСЛАНДИЯ' (ИСПОЛНЕНИЯ))
join
sel НАЗВАНИЕ='ЭМТЬЮН' (СОЧИНЕНИЯ) join МУЗЫКАНТЫ).
В таком множестве операций нетрудно и запутаться. Недаром многие предпочитают
конструировать преобразования реляционной алгебры, а не разбираться в них.
2.7.3. СОЕДИНЕНИЕ ПО
ПОЛЯМ
НЕСКОЛЬКИМ
Соединением двух файлов, не имеющих ни одного общего поля, является
пустое множество. Если же у файлов ИМЯФАЙЛА1 и ИМЯФАЙЛА2, наоборот, не одно, а
несколько общих полей, то соединение включает конкатенацию каждой записи
ИМЯФАЙЛА1 с каждой записью ИМЯФАЙЛА2, у которой совпадают с первой значения
всех общих полей.
Предположим, например, что файл ИМЯФАЙЛА1 содержит три записи:
G1
d
h
У
а файл ИМЯФАЙЛА2
-
F1
3
7
4
F2
H
N
H
F2
H
H
N
H
H
G2
A
B
A
C
B
пять:
F1
3
3
7
4
4
Операция соединения
ИМЯФАЙЛА1 join ИМЯФАЙЛА2
формирует следующий набор данных:
G1
d
d
h
У
Y
FI
3
3
7
4
4
F2
H
H
N
H
H
G2
A
В
A
С
В
Как и прежде, в полученных записях имеется лишь по одному общему полю.
Запрос: указать страну и название каждого ансамбля, руководитель которого
выступает одновременно и как исполнитель.
Ответ дает последовательность операций
proj НАЗВАНС, СТРАНАНС
(АНСАМБЛИ join ИСПОЛНИТЕЛИ
join УЧАСТНИКИ
АНСАМБЛЕЙ).
Поясним написанное. В результате первого соединения номер исполнителя
НОМИСП
связывается с номером НОМАНС, если этот исполнитель руководит
ансамблем. Таким образом, все руководители, не являющиеся исполнителями, после
этого соединения удаляются из списка. Второе соединение осуществляется
на основе двух общих полей, НОМИСП и НОМАНС.
После него из результата
предшествующего соединения исключаются записи, содержащие пары НОМИСП
и
НОМАНС,
отсутствующие в записях файла УЧАСТНИКИ_АНСАМБЛЕЙ.
Тем самым
отсеиваются ансамбли, в которых не играют их руководители.
2.8. УПРАЖНЕНИЯ
1. Составьте последовательность операций реляционной алгебры, с помощью
которых можно получить ответы на следующие запросы:
а) назвать города Эксландии, в которых давались концерты любых ансамблей;
б) указать дату создания каждого произведения под названием <Кейсонг>;
в) перечислить имена исполнителей, играющих на саксофоне;
г) перечислить названия сочинений, написанных Эйэфским;
д) указать даты исполнения произведений, созданных композиторами уроженцами Зедландии;
е) перечислить руководителей всех ансамблей, в составе которых есть
саксофонисты.
3. Сконструируйте выражения, дающие ответы на запросы относительно
содержимого музыкальных файлов:
а) перечислить названия всех эксландских ансамблей, среди участников которых
есть саксофонисты;
б) назвать все города Эксландии, в которых исполнялись любые вещи, созданные
не ранее 1947 г.;
в) перечислить страны, города и даты проведения концертов, на которых
композиторы дирижировали исполнением собственных сочинений.
2.9. ОБЪЕДИНЕНИЕ
Наряду с выбором, проектированием и соединением в реляционной алгебре
определены операции объединения, пересечения, вычитания, деления и умножения.
Объединение, пересечение и вычитание применяются только к файлам с одинаковыми
именами и типами полей. Иными словами, у файлов-операндов должны совпадать
типы записей.
Результатом операции объединения
ИМЯФАЙЛА1 union ИМЯФАЙЛА2
является совокупность записей, входящих хотя бы в один, а возможно, и в оба
операнда. Пусть, например, ИМЯФАЙЛА1 включает записи
F1
a
b
c
G1
4
5
6
а ИМЯФАЙЛА2
F1
d
b
e
c
G1
2
5
4
6
В этом случае операция
ИМЯФАЙЛА1 union ИМЯФАЙЛА2
дает следующий набор записей:
F1
а
b
с
d
e
G1
4
5
6
2
4
При ответах на некоторые запросы вместо объединения предпочтительнее
пользоваться выборов, включая в его условие операцию <ИЛИ>. Приведем пример
подобной ситуации.
Запрос: назвать имена всех музыкантов, родившихся в Уайландии или
Зедландии.
Ответ на этот запрос получим с помощью выражения:
proj ИМЯМУЗ
(sel (СТРАНАРОЖ
(СТРАНАРОЖ
=
=
'УАЙЛАНДИЯ') оr
'ЗЕДЛАНДИЯ') (МУЗЫКАНТЫ)).
Операция объединения применяется в тех случаях, когда информацию нельзя
извлечь из одного файла с помощью выбора.
Еще один пример.
Запрос: перечислить имена всех музыкантов, родившихся в Уайландии либо
сочинивших вещь под названием <Кейсонг>.
Ответ на
proj ИМЯМУЗ
union
proj ИМЯМУЗ
запрос даст следующая
последовательность операций:
(sel СТРАНАРОЖ ='УАЙЛАНДИЯ' (МУЗЫКАНТЫ))
(МУЗЫКАНТЫ join sel НАЗВАНИЕ = 'КЕЙСОНГ' (СОЧИНЕНИЯ)).
Первым операндом в операции объединения служит набор имен музыкантов,
родившихся в Уайландии, вторым - набор, объединяющий имена композиторов,
которые написали произведения, названные <Кейсонг>.
2.10. ПЕРЕСЕЧЕНИЕ
В результате выполнения операции пересечения
ИМЯФАЙЛА1
intersection ИМЯФАЙЛА2
получается набор записей, входящих
файле ИМЯФАЙЛА1 содержатся записи
F1
a
b
c
в состав обоих
файлов. Если, например, в
G1
4
5
6
а в ИМЯФАЙЛА2
F1
d
b
e
c
G1
2
5
4
6
то их пересечением является следующая
F1
b
с
Пример
пересечения.
совокупность записей.
G1
5
6
запроса, для ответа на который
необходимо применить операцию
Запрос: назвать имена всех композиторов, являющихся
мере двух произведений - Кейсонг и Элпис.
Ответ можно получить с помощью такого выражения:
авторами по меньшей
proj ИМЯМУЗ
(МУЗЫКАНТЫ join (proj НОММУЗ (sel НАЗВАНИЕ = 'КЕЙСОНГ' (СОЧИНЕНИЯ))
intersection
proj НОММУЗ (sel НАЗВАНИЕ = 'ЭЛПИС'(СОЧИНЕНИЯ)))).
А вот для ответа на следующий запрос операция пересечения не потребуется.
Запрос: перечислить всех композиторов, родившихся в Уайландии не позднее
1945 г.
Вместо пересечения здесь проще, воспользоваться логическим <И> в условии
операции выбора (этого не удалось бы сделать в предыдущем случае).
proj ИМЯМУЗ
(sel (СТРАНАРОЖ='УАЙЛАНДИЯ') and (ДАТАРОЖ<19460101) (МУЗЫКАНТЫ)).
2.11. ВЫЧИТАНИЕ
Результатом операции вычитания
ИМЯФАЙЛА1 difference ИМЯФАЙЛА2
является совокупность записей, имеющихся в ИМЯФАЙЛА1, но отсутствующих
ИМЯФАЙЛА2. Если, например, ИМЯФАЙЛА1
содержит записи
F1
a
b
c
f
в
G1
4
5
6
5
а в ИМЯФАЙЛА2
F1
d
b
e
c
G1
1
5
4
6
то операция
ИМЯФАЙЛА1 difference ИМЯФАЙЛА2
формирует набор записей
F1
a
f
G1
4
5
Приведем пример запроса, для ответа на который приходится использовать
вычитание.
Запрос: назвать имена всех музыкантов, не сочиняющих произведений.
Ответ даст последовательность операций
proj ИМЯМУЗ
(proj НОММУЗ (МУЗЫКАНТЫ)
difference
proj НОММУЗ (СОЧИНЕНИЯ) join МУЗЫКАНТЫ).
Интерес здесь представляет внутреннее выражение
proj НОММУЗ (МУЗЫКАНТЫ) difference proj НОММУЗ (СОЧИНЕНИЯ),
с помощью которого образуется совокупность НОММУЗ
всех музыкантов,
упомянутых в файле МУЗЫКАНТЫ, но не фигурирующих в файле СОЧИНЕНИЯ.
2.12. ДЕЛЕНИЕ
При выполнении
ИМЯФАЙЛА1
операции деления
division ИМЯФАЙЛА2
требуется, чтобы каждое поле ИМЯФАЙЛА2 имело те же имя и тип, что и одно из
полей ИМЯФАЙЛА1.
В результате деления получается файл, поля которого
содержатся в ИМЯФАЙЛА1, но отсутствуют в ИМЯФАЙЛА2. Запись включается в
результат только при том условии, что в ИМЯФАЙЛА1 она сцеплена с каждой
записью из ИМЯФАЙЛА2.
Если, например, ИМЯФАЙЛА1 содержит записи
G2
A
С
В
В
А
A
В
С
Gl
d
h
h
У
У
h
d
У
Fl
3
7
7
4
4
7
3
4
а ИМЯФАЙЛА2
Gl
d
h
У
F1
3
7
4
то результат деления
ИМЯФАЙЛА1
division ИМЯФАЙЛА2
представляет собой файл
G2
А
В
В этом файле лишь одно поле - G2, которое входит в ИМЯФАЙЛА1 и не входит
в ИМЯФАЙЛА2.
Значение А поля G2 включено в результат деления по той причине,
что в ИМЯФАЙЛА1 оно сцеплено с каждой записью ИМЯФАЙЛА2. Действительно,
в составе ИМЯФАЙЛА1
имеются все записи
G2
А
А
А
G1
d
h
У
Значение С
запись
поля
F1
з
7
4
G2 не вошло в результат, поскольку в ИМЯФАЙЛА1 отсутствует
С d 3.
Рассмотрим
пример, в котором используется
операция деления.
Запрос: перечислить номера ансамблей, в каждом из которых играют все
исполнители, составляющие ансамбль Е6.
Ответ сформируем о помощью соотношения
УЧАСТНИКИ_АНСАМБЛЕЙ division
proj НОМИСП (sel НОМАНС
= 'Е6' (УЧАСТНИКИ
АНСАМБЛЕЙ)).
Второй операнд операции деления дает здесь список номеров всех
исполнителей из ансамбля Е6.
2.13. УМНОЖЕНИЕ
Результатом операции умножения (В некоторых работах эту операцию называют
декартовым произведением.- Прим. ред.)
ИМЯФАЙЛА1
product ИМЯФАЙЛА2
является совокупность записей, представляющих конкатенацию каждой записи
ИМЯФАЙЛА1 с каждой записью ИМЯФАЙЛА2.
Пусть, например, даны файлы-операнды ИМЯФАЙЛА1
F1
b
d
F2
4
7
и ИМЯФАЙЛА2
F3
A
C
F4
4
R
В этом
случае результат содержит
ИМЯФАЙЛА1.Fl
b
b
d
d
ИМЯФАЙЛА1.F2
4
4
7
7
записи
ИМЯФАЙЛА2.F3
A
C
A
C
ИМЯФАЙЛА2.F4
4
R
4
R
В образованном файле каждое поле сохраняет прежнее имя, но оно
дополняется именем файла, из которого взято. Дополнительно имя предшествует
имени поля и отделено от него точкой. Получающиеся при умножении составные
имена, подобные ИМЯФАЙЛА1.F1,
употребляются точно так же, как и простые.
Имя полю присваивается для того, чтобы однозначно идентифицировать
определенный фрагмент записи, и поэтому в ней не должно быть двух полей с
одинаковыми именами. Введение дополнительных имен обеспечивает однозначность
идентификации полей в таких случаях, например, как при выполнении умножения
МУЗЫКАНТЫ
product СОЧИНЕНИЯ.
Если бы не использовались дополнительные имена файлов, результат операции
содержал бы два поля с одинаковым именем НОММУЗ.
Операция умножения находит практическое применение при составлении
ответов на запросы, в которых требуется сравнивать значения полей различных
файлов. Проиллюстрируем это следующим примером.
Запрос: перечислить названия всех произведений, созданных после того, как
родился Эйэфский.
Ответ получим с помощью выражения
proj СОЧИНЕНИЯ.НАЗВАНИЕ
(sel СОЧИНЕНИЯ.ДАТАСОЧ > МУЗЫКАНТЫ.ДАТАРОЖ
(СОЧИНЕНИЯ prodact sel ИМЯМУЗ = 'ЭЙЭФСКИЙ' (МУЗЫКАНТЫ))).
Еще один вариант использования операции умножения - формирование пар
значений полей одного и того же файла, как это делается в приведенном ниже
примере.
Запрос: назвать всевозможные пары имен музыкантов, родившихся в одной
стране.
Если просто умножить файл МУЗЫКАНТЫ на самое себя, в результат войдут пары
полей с одинаковыми составными именами. Это запрещено, поскольку имена полей
файла должны быть уникальными. Разрешить проблему поможет введение
альтернативного имени для файла МУЗЫКАНТЫ,
которое принято называть
псевдонимом или али асом. Чтобы задать это имя, перед последовательностью
операций реляционной алгебры, формирующих ответ на запрос, необходимо
поместить оператор aliases:
НОВЗЫКАНТЫ aliases МУЗЫКАНТЫ;
proj МУЗЫКАНТЫ.ИМЯМУЗ, НОВЗЫКАНТЫ.ИМЯМУЗ
(sel МУЗЫКАНТЫ.СТРАНАРОЖ = НОВЗЫКАНТЫ.СТРАНАРОЖ
(МУЗЫКАНТЫ
product НОВЗЫКАНТЫ)).
Можно сделать и так, чтобы среди полученной совокупности пар имен не было
повторяющихся, однако для этого выражение придется несколько усложнить:
НОВЗЫКАНТЫ aliases МУЗЫКАНТЫ;
proj МУЗЫКАНТЫ.ИМЯМУЗ, НОВЗЫКАНТЫ.ИМЯМУЗ
(sel (МУЗЫКАНТЫ.СТРАНАРОЖ = НОВЗЫКАНТЫ.СТРАНАРОЖ)
(МУЗЫКАНТЫ.НОММУЗ
< > НОВЗЫКАНТЫ.НОММУЗ)
(МУЗЫКАНТЫ product НОВЗЫКАНТЫ)).
and
2.14. УПРАЖНЕНИЯ
1. Составьте выражения реляционной алгебры, с помощью которых можно
получить ответы на следующие запросы
относительно содержимого музыкальных файлов:
а) дать перечень номеров всех ансамблей, среди участников которых есть
кларнетист или саксофонист (либо тот и другой);
б) дать перечень номеров всех ансамблей, среди участников которых есть и
кларнетист, и саксофонист;
в) дать перечень номеров всех ансамблей, среди участников которых есть
саксофонист, но пет кларнетистов;
г) перечислить имена всех музыкантов, не являющихся уроженцами Уайландии и
родившихся не ранее 1946 г.;
д) перечислить имена всех музыкантов - уроженцев Уайландии, не играющих на
саксофоне;
е) перечислить имена всех музыкантов, не являющихся уроженцами Уайландии и
не играющих на саксофоне;
ж) перечислить имена всех музыкантов - уроженцев Уайландии, играющих на
саксофоне;
з) назвать каждую страну, в которой исполнялись все сочинения Эйэфского;
и) назвать каждую страну, в которой не было исполнено ни одного сочинения
Эйэфского;
к) перечислить названия ансамблей, дававших концерты во всех странах, в
каждой из которых выступал любой из них;
л) перечислить названия ансамблей, среди участников которых есть кларнетист
или саксофонист, но не оба одновременно.
2.15. ОПТИМИЗАЦИЯ ЗАПРОСОВ
Вопрос о вычислительных затратах, связанных с выдачей ответов на
конкретный вопрос, пока не затрагивался, и при составлении выражений на языке
реляционной алгебры никак не учитывалось, насколько они эффективны с этой точки
зрения.
Между тем запросы необходимо оптимизировать, выбирая такую
последовательность операций, которая сводила бы к минимальному объем
вычислительной работы. Предположим, например, что V представляет одно из
возможных значений поля F файла ИМЯФАЙЛА1. Если ответ на запрос формируется
согласно соотношению
(sel F = V (ИМЯФАЙЛА1))
join ИМЯФАЙЛА2,
записи из ИМЯФАЙЛА1
выбираются до того, как будет выполнена операция
соединения. Выражение
sel F = V
(ИМЯФАЙЛА1
join ИМЯФАЙЛА2)
в принципе даст тот же самый ответ, но эффективность его может оказаться ниже,
если результат соединения будет содержать больше записей, чем имеется в файле
ИМЯФАЙЛА1.
Выборка в этом случае будет идти дольше, поскольку придется
просматривать большее число записей.
Если запрос формализуется на специализированном языке типа языка
реляционной алгебры, нетрудно сделать так, чтобы компьютер оптимизировал
последовательность операций автоматически. Однако при использовании расширенной
версии Паскаля, обсуждаемой в гл. 4 и 5, автоматизировать процедуру оптимизации
ответов на запросы гораздо сложнее, и это еще один довод в пользу применения
специализированных языков.
ГЛАВА 3
ПРИНЦИПЫ
НОРМАЛИЗАЦИИ
3.1. РАСПРЕДЕЛЕНИЕ ПОЛЕЙ ПО ФАЙЛАМ
В обсуждавшихся примерах все файлы выступали до сих пор лишь как
объекты, содержащие некоторые данные. Взглянем теперь на проблему с иной точки
зрения и попытаемся найти способ, позволяющий объективно судить о том, какие
нужны файлы и какие поля должны в них помещаться. Но сначала познакомимся с
понятием полной декомпозиции.
3.2. ПОЛНАЯ ДЕКОМПОЗИЦИЯ
Начнем с простейшего примера. Рассмотрим зоологический файл, который
назовем ЗВЕРИ_В_НЕВОЛЕ (ANIMALS). В нем три поля: ЗООПАРК, ЖИВОТНОЕ и ЗОНА_ОБИТАНИЯ. Предположим, что файл содержит ровно четыре записи:
ЗООПАРК
эйтон
эйтон
БИТОН
БИТОН
ЖИВОТНОЕ
КЕНГУРУ
ВЕРБЛЮД
ЭМУ
ВЕРБЛЮД
ЗОНА_ОБИТАНИЯ
АВСТРАЛИЯ
АРАВИЯ
АВСТРАЛИЯ
АРАВИЯ
Нетрудно убедиться, что результат операций
(proj ЗООПАРК, ЖИВОТНОЕ (ЗВЕРИ_В_НЕВОЛЕ))
join
(proj ЖИВОТНОЕ, ЗОНА_ОБИТАНИЯ (ЗВЕРИ_В_НЕВОЛЕ))
полностью совпадает с исходным файлом ЗВЕРИ_В_НЕВОЛЕ. В общем случае полную
декомпозицию файла определяют как совокупность произвольного числа его проекций,
соединение которых идентично этому файлу. В частности, приведенный пример
демонстрирует, как две проекции:
proj ЗООПАРК, ЖИВОТНОЕ (ЗВЕРИ_В_НЕВОЛЕ)
и
proj ЖИВОТНОЕ, ЗОНА_ОБИТАНИЯ
(ЗВЕРИ_В_НЕВОЛЕ), соединяясь, образуют полную
декомпозицию файла ЗВЕРИ_В_НЕВОЛЕ.
С другой стороны, соединение проекций
proj ЗООПАРК, ЗОНА_ОБИТАНИЯ
(ЗВЕРИ_В_НЕВОЛЕ) и
proj ЖИВОТНОЕ, ЗОНА_ОБИТАНИЯ (ЗВЕРИ_В_НЕВОЛЕ)
дает следующий набор записей:
ЗООПАРК
эйтон
эйтон
ЭЙТОН
БИТОН
БИТОН
БИТОН
В нем
ЭЙТОН
БИТОН
ЖИВОТНОЕ
КЕНГУРУ
ЭМУ
ВЕРБЛЮД
КЕНГУРУ
ЭМУ
ВЕРБЛЮД
ЗОНА_ОБИТАНИЯ
АВСТРАЛИЯ
АВСТРАЛИЯ
АРАВИЯ
АВСТРАЛИЯ
АВСТРАЛИЯ АРАВИЯ
ЭМУ
КЕНГУРУ
АВСТРАЛИЯ АВСТРАЛИЯ
есть две записи
которые отсутствуют в самом файле ЗВЕРИ_В_НЕВОЛЕ. Таким образом, этот набор не
идентичен исходному файлу и, следовательно, соединением проекций
proj ЗООПАРК,
ЗОНА_ОБИТАНИЯ (ЗВЕРИ_В_НЕВОЛЕ) и
proj ЖИВОТНОЕ, ЗОНА_ОБИТАНИЯ (ЗВЕРИ_В_ НЕВОЛЕ) нельзя получить полную
декомпозицию файла ЗВЕРИ_В_НЕВОЛЕ.
Материал последующих разделов в значительной мере посвящен проблемам
реляционной теории нормализации. Уместно поэтому сформулировать здесь ее
основные задачи.
1. Создание методов анализа, позволяющих определить, образует ли данная
совокупность проекции файла полную декомпозицию этого файла.
2. Определение правил выбора одной из двух альтернативных
возможностей:
а) хранить файл в его непосредственном виде или
б) хранить вместо самого файла набор проекций, составляющих его полную
декомпозицию (при необходимости файл всегда можно восстановить по его
проекциям).
Обратимся сначала к задаче 2), т. е. решим вопрос о том, что хранить - файл
или его полную декомпозицию, а задачей 1)
займемся чуть позже.
3.3. ДУБЛИРОВАНИЕ
ИНФОРМАЦИИ
3.3.1. ПРИМЕРЫ ДУБЛИРОВАНИЯ
В некоторых случаях, заменив файл его полной декомпозицией, можно избежать
ненужного дублирования данных.
Проиллюстрируем это на примере файла ПОСТАВЩИКИ_ТОВАРОВ, включающего
три
поля:
ШИФР_ТОВАРА
НАЗВАНИЕ
НОМЕР_ТЕЛЕФОНА
{Уникальный номер, идентифицирующий товар}
{Название фирмы-поставщика}
{Телефон фирмы-поставщика}
Для простоты будем считать, что любой товар поставляется не более чем
одной фирмой, и все эти фирмы имеют разные названия. Предположим, содержимое
файла таково:
ШИФР_ТОВАРА
АА39
АС22
АН84
АР83
AZ27
DD68
FS44
HS41
ММ72
НАЗВАНИЕ
ДЖЕКСОН
ДЖЕКСОН
УИЛСОН
РОБСОН
УИЛСОН
УИЛСОН
РОБСОН
РОБСОН
УИЛСОН
НОМЕР_ТЕЛЕФОНА
3692
3692
5948
2514
5948
5948
2514
2514
5948
Можно показать (это будет сделано несколько позднее), что две проекции:
proj ШИФР_ТОВАРА, НАЗВАНИЕ (ПОСТАВЩИКИ-ТОВАРОВ)
и
proj НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА (ПОСТАВЩИКИ_ТОВАРОВ)
совместно образует полную декомпозицию файла ПОСТАВЩИКИ_ТОВАРОВ. Иными словами,
соединение этих проекций дает файл, идентичный исходному. Проекция
proj НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА (ПОСТАВЩИКИ_ТОВАРОВ) содержит следующий набор
записей:
НАЗВАНИЕ
ДЖЕКСОН
УИЛСОН
РОБСОН
НОМЕР_ТЕЛЕФОНА
3692
5948
2514
Каждый из телефонных номеров упоминается в этой проекции лишь по одному
разу, хотя, скажем, в файле ПОСТАВЩИКИ_ТОВАРОВ
телефон фирмы <УИЛСОН>
фигурирует в четырех записях. Многократное повторение телефонных номеров - один
из примеров дублирования данных. Чтобы обойтись без него, предлагается в данном
случае вместо файла ПОСТАВЩИКИ_ТОВАРОВ
хранить его полную декомпозицию, в
которой каждый номер (как и остальные данные) указан ровно один раз. Точно
так же можно избежать дублирования информации, храня полную декомпозицию, а не
сам исходный файл ЗВЕРИ_В_НЕВОЛЕ.
Устранить дублирование важно по двум причинам. Во-первых, можно добиться
существенной экономии памяти. Во-вторых, если какой-то элемент дублируется N раз
(например, телефон фирмы <Робсон> - трижды), то при корректировании данных
необходимо менять содержимое всех N копий. В частности, если у фирмы <Робсок>
сменится телефон, новый номер придется занести во все три записи файла
ПОСТАВЩИКИ_ТОВАРОВ, где был указан старый. Очевидно, что N-кратное повторение
одной и той же операции - излишняя трата времени. С другой стороны, не вносить
изменения во все N копий нельзя, иначе будут возникать ошибки из-за несовпадения
данных. Если же дублирование отсутствует, то нет и причин для возникновения
подобных ошибок. Например, в проекции
proj НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА
(ПОСТАВЩИКИ_ТОВАРОВ)
каждый
номер упомянут лишь однократно, в силу чего несовпадение принципиально
невозможно.
3.3.2. КЛЮЧИ-КАНДИДАТЫ
Итак, в некоторых случаях дублирование устраняется за счет перехода от
самого файла к его полной декомпозиции. Однако возможны и такие ситуации, когда
подобная замена не дает эффекта. Очевидно, необходимо найти критерий, который
позволил бы объективно судить о целесообразности использования полной
декомпозиции вместо файла.
Воспользуемся
понятием
ключа-кандидата,
введенным в разд. 1.2.3.
Ключ-кандидат определялся как минимальный набор полей (одного или нескольких),
значения которых однозначно идентифицируют
запись файла. Минимальность набора
понимается в том смысле, что при изъятии из него любого поля он перестает быть
ключом-кандидатом. У файла может иметься несколько таких ключей.
В приведенном ниже примере ключом-кандидатом файла АДРЕСА_КЛИЕНТОВ служит
поле НОМЕР_КЛИЕНТА.
НОМЕР_КЛИЕНТА
0391
0403
0569
0615
НАЗВАНИЕ
уилкинсон
сэмсон
уилкинсон
сэмсон
АДРЕС
19 КОБЛ-СТРИТ
31 ХАЙ-СТРИТ
31 ХАЙ-СТРИТ
19 КОБЛ-СТРИТ
Еще один ключ-кандидат образует пара полей НОМЕР_КЛИЕНТА и АДРЕС.
Соединение проекций
proj НОМЕР_КЛИЕНТА, НАЗВАНИЕ
(АДРЕСА_КЛИЕНТОВ)
и
proj НОМЕР_КЛИЕНТА, АДРЕС
(АДРЕСА_КЛИЕНТОВ)
представляет собой
полную декомпозицию, однако она не позволяет избавиться от дублирования. Дело в
том, что обе проекции содержат ключ-кандидат НОМЕР-КЛИЕНТА. Именно его
присутствием и там и там объясняется нежелательный эффект. Заметим, что в
обсуждавшемся
выше примере полная
декомпозиция файла ПОСТАВЩИКИ_ТОВАРОВ,
с помощью которой устранялось дублирование данных, была сформирована как
соединение двух проекций, общие поля которых не могли образовать ключ-кандидат.
Можно доказать, что дублирование неизбежно, если проекции, порождающие
полную декомпозицию, содержат общий для обеих ключ-кандидат исходного файла.
Доказательство построим таким образом: покажем, что отсутствие дублирования
противоречит предположению о наличии у проекций общего ключа-кандидата.
Рассмотрим файл ИМЯФАЙЛА
с полями FX, FY и FZ. Пусть выполняется
равенство
ИМЯ ФАЙЛА = proj FX, FY (ИМЯФАЙЛА) join proj FY, FZ (ИМЯФАЙЛА),
причем FY, являясь ключом-кандидатом, входит в состав обеих проекций, образующих
полную декомпозицию файла ИМЯФАЙЛА.
В данном случае дублирование не
исключено, поскольку файл ИМЯФАЙЛА может содержать такие записи, как
FX
FY
FZ
Х
X'
Y
Y
Z
Z
В этих записях пара значений Y и Z повторяется дважды. Налицо
противоречие, поскольку предполагалось, что FY служит ключом-кандидатом, ввиду
чего Y может встретиться максимум в одной записи. Этим и завершается
доказательство. Оно практически не изменилось бы, если FX, FY и FZ обозначали не
одиночные поля, а совокупность полей.
В общем случае у файла может быть несколько полных декомпозиций. Так, файл
ПОСТАВЩИКИ_ТОВАРОВ имеет полную декомпозицию, составленную из проекций
proj ШИФР_ТОВАРА,
НОМЕР_ТЕЛЕФОНА
(ПОСТАВЩИКИ-ТОВАРОВ) и
proj ШИФР-ТОВАРА,
НАЗВАНИЕ
(ПОСТАВЩИКИ-ТОВАРОВ).
Обе они содержат ключ-кандидат файла ПОСТАВЩИКИ_ТОВАРОВ,
ввиду чего замена его
приведенной декомпозицией не гарантирует отсутствия дублирования. Однако ранее
для этого файла была составлена другая декомпозиция, в которой не было
дублирования данных. В конечном итоге можно сделать следующий вывод: если
существует такая полная декомпозиция файла, которая образована проекциями, не
имеющими общего ключа-кандидата, то замена исходного файла этой декомпозицией
исключает возможность дублирования информации.
3.4. ПРИСОЕДИНЕННЫЕ ЗАПИСИ
Решая вопрос о том, что целесообразнее хранить - файл как таковой или его
полную декомпозицию, следует принимать в расчет и проблему записей, получивших
название <присоединенных>. Сначала рассмотрим пример подобной записи, а затем
дадим точное определение.
Вновь вернемся к файлу ПОСТАВЩИКИ_ТОВАРОВ, который обсуждался в разд.
3.3.1. Предположим, что в этот файл понадобилось занести телефонный номер 6632
новой фирмы-поставщика, именуемой <Симсон>, от которой не поступало еще никаких
товаров. Но поле ШИФР_ТОВАРА
служит ключом, и его нельзя оставить пустым,
иначе новую запись впоследствии невозможно будет идентифицировать. По этой
причине номер телефона в файл ПОСТАВЩИКИ_ТОВАРОВ
ввести не удастся. В то же
время его можно записать в проекцию
proj НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА
(ПОСТАВЩИКИ, ТОВАРОВ):
НАЗВАНИЕ
ДЖЕКСОН
УИЛСОН
РОБСОН
СИМСОН
НОМЕР-ТЕЛЕФОНА
3692
5948
2514
6632
Записи, подобные последней, и называют присоединениями.
Сформулируем теперь общее определение присоединенной записи. Пусть R и S наборы полей файла ИМЯФАЙЛА, и выполняется условие
ИМЯФАЙЛА = proj R (ИМЯФАЙЛА) join proj S (ИМЯФАЙЛА).
В качестве примера можно вновь взять файл ПОСТАВЩИКИ_ТОВАРОВ, отождествив
с R пару полей (ШИФР_ТОВАРА, НАЗВАНИЕ),
а с S -- пару полей (НАЗВАНИЕ,
НОМЕР_ТЕЛЕФОНА). Запись является присоединенной, если она занесена в проекцию
proj S (ИМЯФАЙЛА),
но не входит в состав какой-либо записи
proj R (ИМЯФАЙЛА)
join proj S (ИМЯФАЙЛА),
поскольку с ней невозможно образовать конкатенацию ни одной из записей проекции
proj R (ИМЯФАЙЛА). В частности, proj ШИФР_ТОВАРА, НАЗВАНИЕ (ПОСТАВЩИКИ_ТОВАРОВ)
не содержит записей, где фигурировало бы название <Симсон>. По этой причине
<Симсон> и номер телефона фирмы будут исключены из результата соединения
proj ШИФР
ТОВАРА, НАЗВАНИЕ
(ПОСТАВЩИКИ_ТОВАРОВ) join
proj НАЗВАНИЕ,
НОМЕР_ТЕЛЕФОНА (ПОСТАВЩИКИ_ТОВАРОВ).
Если присоединенная запись занесена в proj S (ИМЯФАЙЛА),
последняя перестает быть точной проекцией ИМЯФАЙЛА. Тем не менее основное ее
содержание не меняется, и поэтому будем обозначать ее по-прежнему proj S
(ИМЯФАЙЛА).
Вернемся к проблеме запоминания телефона фирмы <Симсон>, которая еще не
успела приступить к поставке товаров. В подобных обстоятельствах проблема
решается с помощью присоединенных записей, которые можно хранить не в исходном
файле, а в его полной декомпозиции. Возможны, однако, такие ситуации, когда
использование полной декомпозиции для запоминания присоединенных записей
лишено смысла.
Как и ранее, все решает наличие или отсутствие общего ключа-кандидата.
Если в состав обеих проекций, образующих полную декомпозицию
ИМЯФАЙЛА,
входит ключ-кандидат, проблемы присоединенных записей практически не существует.
Предположим, например, что в файл АДРЕСА_КЛИЕНТОВ (см. разд. 3.3.2)
потребовалось поместить название новой фирмы - <Хобсон>, а также ее телефон 0643, не указывая в то же время ее адреса. Эту информацию в виде записи
0643 ХОБСОН
можно занести в проекцию proj НОМЕР_КЛИЕНТА, НАЗВАНИЕ (АДРЕСА_КЛИЕНТОВ). Можно
поступить и по-иному, поместив в файл АДРЕСА_КЛИЕНТОВ
запись
0643 ХОБСОН
пусто.
Словом <пусто> здесь обозначено поле, не содержащее никакого значения.
Учитывая, что это поле не используется как ключ, в данном случае правила не
нарушены. Таким образом, запись
0643 ХОБСОН
по существу не является присоединенной, поскольку ее можно поместить, объединив
с пустым нолем, непосредственно в исходный файл.
Чтобы обосновать правильность последней операции, достаточно занести в
проекцию proj НОМЕР_КЛИЕНТА, АДРЕС (АДРЕСА_КЛИЕНТОВ) вспомогательную запись
0643 пусто.
Ее конкатенация с записью
0643 ХОБСОН
из proj НОМЕР_КЛИЕНТА,
0643 ХОБСОН
НАЗВАНИЕ (АДРЕСА_КЛИЕНТОВ)
дает запись
пусто
в файле АДРЕСА_КЛИЕНТОВ, который восстанавливается в результате соединения двух
указанных проекций. Итак, можно считать, что в рассмотренном примере
присоединенные записи отсутствуют.
Встанем теперь на формальную позицию и покажем более строго, что
проблема присоединенных записей не существует, если в проекциях, образующих
полную декомпозицию некоторого файла, присутствуют поля, составляющие его ключкандидат.
Пусть этими свойствами по отношению к файлу ИМЯФАЙЛА обладают две
проекции, proj R (ИМЯФАЙЛА)
и proj S (ИМЯФАЙЛА). Дополним proj S (ИМЯФАЙЛА)
еще одной записью, которую обозначим s, и предположим, что ни одно из полей s,
входящих в ключ-кандидат, не является пустым.
Проекцию proj R (ИМЯФАЙЛА)
также дополним специально сформированной
записью r. Все поля этой вспомогательной записи, присутствующие одновременно в
наборах R и S, по своему содержанию идентичны полям записи s, в то время как
остальные пусты. Введение r в проекцию proj R (ИМЯФАЙЛА) не противоречит
правилам, поскольку в силу своей структуры г включает ключ-кандидат, причем ни
одно из его полей в этой записи не пусто. Очень важно также, что новая запись,
не привнося никакой информации, помимо уже имеющейся в proj R (ИМЯФАЙЛА),
фактически не меняет содержимого последней.
Завершим доказательство, осуществив соединение
proj R (ИМЯ ФАЙЛА)
join proj S (ИМЯ ФАЙЛА).
Результат этой операции включает конкатенацию r и s. Следовательно, s
нельзя считать присоединенной записью, поскольку, согласно определению, при
соединении проекций такая запись не может войти в результирующий файл. Таким
образом, показано, что присоединенные записи отсутствуют, если проекции,
порождающие полную декомпозицию, содержат общий ключ-кандидат исходного
файла.
Ранее уже отмечалось, что файл может иметь не одну полную декомпозицию.
Если во всех проекциях, из которых формируется каждая из таких декомпозиций,
присутствует ключ-кандидат, бессмысленно хранить вместо исходного файла какую-то
из его полных декомпозиций (речь, разумеется, идет лишь о проблеме
присоединенных записей). Но если существует хотя бы одна полная декомпозиция,
которую образуют проекции, не содержащие общего ключа-кандидата, то при
переходе от нее к исходному файлу возможна (хотя и не обязательна) потеря
присоединенных записей.
3.5. НОРМАЛИЗАЦИЯ
3.5.1. ПЯТАЯ НОРМАЛЬНАЯ ФОРМА
Говорят, что файл находится в пятой нормальной форме, если не существует
ни одной его полной декомпозиции, в которую входили бы проекции, не имеющие
общего ключа-кандидата. Можно сформулировать это условие и более строго: файл
представлен в пятой нормальной форме тогда и только тогда, когда в каждой его
полной декомпозиции все проекции содержат ключ-кандидат. Считается, что файл, не
обладающий ни одной полной декомпозицией, также имеет пятую нормальную форму.
Предшествующий анализ позволяет сделать вывод, что замена файла в пятой
нормальной форме любой его полной декомпозицией не дает никаких преимуществ в
смысле устранения дублирования информации и сохранения присоединенных записей.
С другой стороны, если файл не находится в пятой нормальной форме, то
имеется возможность избежать дублирования и потери присоединенных записей,
перейдя от файла к такой его полной декомпозиции, которая образована проекциями,
не содержащими общего ключа-кандидата. Если составляющие такую декомпозицию
проекции, в свою очередь, не являются файлами в пятой нормальной форме, то
каждую из них также можно заменить полной декомпозицией, сформированной из
проекций в пятой нормальной форме. Подобный процесс последовательного перехода
к полным декомпозициям называют нормализацией. Основная цель нормализации добиться того, чтобы не дублировались данные и не исчезали присоединенные
записи.
3.5.2. УПРАЖНЕНИЯ
В каждом из упражнений 1-6 совместно с исходным файлом дается одна или
несколько его полных декомпозиций.
а. Во всех упражнениях необходимо нормализовать файл. Возможно, для
этого потребуется заменить его подходящей полной декомпозицией из числа
приведенных. Достаточно указать, которую из декомпозиций следует выбрать для
этой цели. Если же файл предположительно уже находится в пятой нормальной
форме, следует доказать, что это действительно так. Можно считать, что, помимо
представленных, других декомпозиций, способных заместить файл, не существует.
б. Предлагается во всех случаях, когда исходный файл не приведен еще к
пятой нормальной форме, дать пример нормализации, сокращающей дублирование, а
также найти нормализацию, которая позволила бы сохранить присоединенную запись,
выпадающую из ненормализованного файла.
1. Представим себе подробный план парка, на котором отдельно указано каждое
растущее дерево. Все деревья снабжены индивидуальными номерами. Исходный файл в
этом упражнении именуется ДЕРЕВЬЯ.
В нем хранятся краткие сведения
относительно каждого дерева. Ниже приведены имена полей этого файла и четыре его
записи.
НОМЕР_ДЕРЕВА
1
2
3
4
ПОРОДА
БУК
ПАДУБ
БУК
ЯСЕНЬ
ВЫСОТА
21
9
23
18
ВЕЧНОЗЕЛЕНОЕ
НЕТ
ДА
НЕТ
НЕТ
Первая полная декомпозиция
proj НОМЕР_ДЕРЕВА, ПОРОДА, ВЫСОТА (ДЕРЕВЬЯ),
proj НОМЕР_ДЕРЕВА, ВЕЧНОЗЕЛЕНОЕ
(ДЕРЕВЬЯ).
Вторая полная декомпозиция
proj НОМЕР_ДЕРЕВА, ПОРОДА
(ДЕРЕВЬЯ),
proj НОМЕР_ДЕРЕВА, ВЫСОТА
(ДЕРЕВЬЯ),
proj НОМЕР_ДЕРЕВА, ВЕЧНОЗЕЛЕНОЕ
(ДЕРЕВЬЯ).
Третья полная декомпозиция
proj НОМЕР_ДЕРЕВА, ПОРОДА, ВЫСОТА (ДЕРЕВЬЯ),
proj ПОРОДА, ВЕЧНОЗЕЛЕНОЕ
(ДЕРЕВЬЯ).
2. Имя исходного файла - КОНФЕТЫ.
и часть помещенных в нем записей:
РЕЦЕПТ
ИРИС
ИРИС
ИРИС
ИРИС
ТЯНУЧКА
ТЯНУЧКА
ТЯНУЧКА
ИНГРЕДИЕНТ
САХАР
МАСЛО
МУКА
ПАТОКА
САХАР
МАСЛО
СГУЩЕННОЕ МОЛОКО
Вот имена его полей
ГРАММЫ
450
225
5
20
450
225
400
КАЛОРИИ_НА_ГРАММ
3,7
7,8
3,5
3,2
3,7
7,8
4,5
proj
proj
Первая полная декомпозиция
РЕЦЕПТ, ИНГРЕДИЕНТ,
ГРАММЫ
(КОНФЕТЫ),
ИНГРЕДИЕНТ, КАЛОРИИ_НА_ГРАММ (КОНФЕТЫ).
proj
proj
Вторая полная декомпозиция
РЕЦЕПТ, ИНГРЕДИЕНТ,
ГРАММЫ
(КОНФЕТЫ),
РЕЦЕПТ, ИНГРЕДИЕНТ,
КАЛОРИИ_НА_ ГРАММ (КОНФЕТЫ).
3. В исходном файле, названном ВИЗИТЫ (VISITS), фиксируются приезды людей в
различные города и страны. Для простоты предполагается, что у всех визитеров
разные фамилии и нет городов с одинаковыми названиями. Ниже указаны имена полей
файла и приведено несколько его записей.
ДАТА
(DATE)
19920615
19920615
19920617
19920620
19920620
19920620
ФАМИ ЛИЯ
(NAME)
ДЖОНС
СМИТ
СМИТ
СМИТ
НАЙТ
ЯНГ
ПРОФЕССИЯ
(PROFESSION)
БУХГАЛТЕР
ПРОГРАММИСТ
ПРОГРАММИСТ
ПРОГРАММИСТ
ИНЖЕНЕР
ИНЖЕНЕР
ГОРОД
(TOWN)
ЭФТОН
СИТОН
ЭЙТОН
ЭФТОН
дитон
СИТОН
СТРАНА
(COUNTRY)
УАЙЛАНДИЯ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
УАЙЛАНДИЯ
ЭЕДЛАНДИЯ
ЭКСЛАНДИЯ
Первая полная декомпозиция
proj ДАТА, ФАМИЛИЯ, ПРОФЕССИЯ, ГОРОД (ВИЗИТЫ),
proj ГОРОД, СТРАНА (ВИЗИТЫ).
Вторая полная декомпозиция
proj ДАТА, ФАМИЛИЯ,
ГОРОД, СТРАНА (ВИЗИТЫ),
proj ФАМИЛИЯ,
ПРОФЕССИЯ (ВИЗИТЫ).
Третья полная декомпозиция
proj ДАТА, ФАМИЛИЯ,
ГОРОД (ВИЗИТЫ),
proj ГОРОД, СТРАНА (ВИЗИТЫ),
proj ФАМИЛИЯ,
ПРОФЕССИЯ (ВИЗИТЫ).
4. Исходный файл, названный ПОЕЗДКИ, содержит записи о междугородных
автобусных перевозках. Переезд из одного города в другой всегда совершается по
неизменному маршруту, причем в день этим путем проезжает не более одного
автобуса. В шестом поле файла отмечается продолжительность поездки.
Имена полей и образцы записей приведены ниже.
ОТКУДА
УИНКЛБИ
УИНКЛБИ
КОКЛТОН
КУДА
КОКЛТОН
КОКЛТОН
МАСЛГРОВ
ДАТА
19930305
19930306
19930306
ВОДИТЕЛЬ
МАРШАЛЛ
АРНОЛЬД
МАРШАЛЛ
ВРЕМЯ
3.4
2.8
4.1
РАССТОЯНИЕ
62
62
62
Первая полная декомпозиция
КУДА, ДАТА, ВОДИТЕЛЬ, ВРЕМЯ (ПОЕЗДКИ),
КУДА, РАССТОЯНИЕ (ПОЕЗДКИ).
Вторая полная декомпозиция
proj ОТКУДА, КУДА, ДАТА, ВОДИТЕЛЬ
(ПОЕЗДКИ),
proj ОТКУДА, КУДА, ДАТА, ВРЕМЯ (ПОЕЗДКИ),
proj ОТКУДА, КУДА, РАССТОЯНИЕ (ПОЕЗДКИ).
proj ОТКУДА,
proj ОТКУДА,
5. Исходный файл ШАХМАТЫ содержит записи, в которых указаны дата встречи,
фамилии участников и победитель, а также продолжительность игры. Два конкретных
шахматиста могут сыграть не более одной партии в день. Имена полей и часть
записей приведены ниже.
ДАТА
19920502
19929592
19920503
19920503
proj
proj
УЧАСТНИК_1
ГРАМБИГ
ГРАМБИГ
ГРАМБИГ
СМИТ
УЧАСТНИК 2
ПИВИЧ
СМИТ
ПИВИЧ
ПИВИЧ
ПОБЕДИТЕЛЬ
ПИВИЧ
СМИТ
ПИВИЧ
СМИТ
ВРЕМЯ
3,6
2,5
1,4
5,2
Полная декомпозиция
ДАТА, УЧАСТНИК_1, УЧАСТНИК_2, ПОБЕДИТЕЛЬ (ШАХМАТЫ),
ДАТА, УЧАСТНИК_1, УЧАСТНИК_2, ВРЕМЯ
(ШАХМАТЫ).
В данном случае имеется всего одна полная декомпозиция, которую и
предстоит проанализировать.
6. В исходном файле ИСКИ содержится подробная информация об исках,
представленных страховым компаниям. Названия этих компаний не повторяются. По
данному страховому полису может быть возбуждено несколько исков, но не более
одного в день. Любой клиент может иметь несколько полисов. Ниже приведен
перечень полей файла ИСКИ.
ФИРМА
АДРЕС_ФИРМЫ
НОМЕР_ПОЛИСА
ДАТАСТРАХ
КЛАСС
СУММАСТРАХ
ДАТА_ИСКА
СУММА_ИСКА
НОМЕР_КЛИЕНТА
ИМЯ_КЛИЕНТА
АДРЕС_КЛИЕНТА
proj
proj
proj
proj
Первая полная декомпозиция
ФИРМА, АДРЕС_ФИРМЫ,
HOMEР_ПОЛКСА. ДАТАСТРАХ,
НОМЕР_КЛИЕНТА, КЛАСС, СУММАСТРАХ (ИСКИ),
НОМЕР_ПОЛИСА, ИМЯ_КЛИЕНТА, АДРЕС_КЛИЕНТА, ДАТА.
ИСКА, СУММА_ИСКА (ИСКИ).
Вторая полная декомпозиция
ФИРМА, АДРЕС_ФИРМЫ (ИСКИ),
НОМЕР_КЛИЕНТА, ИМЯ_КЛИЕНТА.
АДРЕС_КЛИЕНТА
(ИСКИ),
proj
proj
НОМЕР_ПОЛИСА, ФИРМА, НОМЕР_КЛИЕНТАб ДАТАСТРАХ,
КЛАСС, СУММАСТРАХ (ИСКИ),
НОМЕР_ПОЛИСА, ДАТА_ИСКА, СУММА_ИСКА (ИСКИ).
3.6. ФУНКДИОНАЛЬНАЯ ЗАВИСИМОСТЬ
3.6.1. ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНОЙ ЗАВИСИМОСТИ
До сих пор молчаливо предполагалось, что существует некоторый критерий,
позволяющий определить, образует данный набор проекций полную декомпозицию или
не образует. Теперь настала пора разобраться, как практически можно выявить
подобную декомпозицию. Весьма полезно в связи с этим познакомиться с понятием
функциональной зависимости.
Пусть Х и Y -наборы, каждый из которых объединяет одно или несколько
полей файла ИМЯФАЙЛА. Y находится в функциональной зависимости от Х тогда и
только тогда, когда с каждым данным значением Х связано не более одного
значения Y. По отношению к ИМЯФАЙЛА
функциональная зависимость Y от Х
создает ограничение, выражающееся в том, что любые две записи этого файла,
содержащие одинаковые значения X, должны обязательно включать и совпадающие
значения Y. Ограничение это действует не только на записи, уже имеющиеся в
ИМЯФАЙЛА, ной на те, что потенциально могут попасть в него в будущем.
В качестве примера возьмем файл АДРЕСА_КЛИЕНТОВ из разд. 3.3.2. Положив
Х – НОМЕР_КЛИЕНТА,
а Y - АДРЕС, сразу же можно убедиться, что Y функционально
зависит от X. Действительно, АДРЕСА_КЛИЕНТОВ
удовлетворяют данному выше
определению уже потому, что ни в одной из записей значения НОМНР_КЛИЕНТА
не
повторяются.
Рассмотрим еще один, намеренно упрощенный, пример. Пусть файл содержит
следующие четыре записи:
F1
A
B
C
B
F2
h
i
j
k
Очевидно, F2 не связано функциональной зависимостью с F1, поскольку
значению B поля ЕЗ соответствуют два различных значения поля F2. В то же
время нельзя утверждать, что F1 функционально зависит от F2, исходя лишь из
имеющихся записей. Это допустимо только при том условии, что на файл
дополнительно наложено ограничение, запрещающее, вводить в него такие новые
записи, как, например,
F1
C
F2
k
которая нарушает условие однозначного соответствия значений F2 значениям FL
Если Х состоит из нескольких полей, то говорят, что Y находится в полной
функциональной зависимости от Х тогда и только тогда, когда:
а) Y функционально зависит от X.:
б) Y функционально не зависит от любого X', где X' – такое подмножество X,
что по меньшей мере одно поле из Х не принадлежит X'.
Иными словами, утверждать, что Y связан G Х полной функциональной
зависимостью, можно в том и только в том случае, если Y функционально зависит от
Х и не зависит от любого его подмножества, не совпадающего с X.
Примером может служить файл ЗВЕРИ_В_НЕВОЛЕ из разд. 3.2. В нем поле
ЗОНА_ОБИТАНИЯ функционально зависит от пары ЗООПАРК, ЖИВОТНОЕ.
Действительно,
любой паре значений, например,
9ЙТОН
ЗЙТОН
КЕНГУРУ
ВЕРБЛЮД
соответствует ровно по одному значению поля ЗОНА_ОБИТАНИЯ. Легко, однако,
убедиться и в том, что ЗОНА_ОБИТАНИЯ функционально зависит также от поля
ЖИВОТНОЕ. Совместно это означает, что ЗОНА_ОБИТАНИЯ не обладает полной
функциональной зависимостью от пары ЗООПАРК, ЖИВОТНОЕ.
Завершим раздел еще одним простым примером. Предположим, что дан файл
ЗАКАЗЫ со следующими полями:
НОМЕР_ЗАКАЗА
ШИФР_ТОВАРА
ОПИСАНИЕ
КОЛИЧЕСТВО
{Шифр, присвоенный заказанному товару}
{Описание товара}
{Заказанное количество единиц товара}
Первичный ключ (и единственный ключ-кандидат) этого файла состоит из двух
полей – НОМЕР_ЗАКАЗА и ШИФР_ТОВАРА.
В одиночку каждое из указанных полей не способно играть роль ключакандидата, поскольку файл может содержать по несколько записей с одинаковыми
значениями НОМЕР_ЗАКАЗА и с одинаковыми значениями ШИФР_ТОВАРА. В то же время
пара значений НОМЕР_ЗАКАЗА и ШИФР_ТОВАРА однозначно идентифицирует конкретную
запись. Следовательно, этой паре соответствует единственное значение поля
КОЛИЧЕСТВО, из чего можно заключить, что КОЛИЧЕСТВО связано полной
функциональной зависимостью с полем НОМЕР_ЗАКАЗА и ШИФР_ТОВАРА. Действительно,
условие б) выполняется: не исключено появление записей с повторяющимися
значениями полей НОМЕР_ЗАКАЗА и ШИФР_ТОВАРА, вследствие чего поле КОЛИЧECTВO
не зависит функционально ни от того, ни от другого в отдельности.
С другой стороны, поле ОПИСАНИЕ функционально зависит от поля
ШИФР_ТОВАРА.
Из этого следует, что ОПИСАНИЕ не находится в полной
функциональной зависимости от ключа-кандидата НОМЕР_ЗАКАЗА, ШИФР_ТОВАРА.
3.6.2. ТЕОРЕМА ХИТА
Посвятим этот раздел доказательству теоремы Хита, устанавливающей связь
между
функциональной зависимостью и полной декомпозицией файла. Рассмотрим
файл ИМЯФАИЛА, в котором выделим три набора полей: Н, J и К таких, что каждое
поле ИМЯ ФАЙЛА принадлежит лишь какому-то одному из этих трех наборов.
Теорема Хита. Если К функционально
ИМЯФАЙЛА
= proj Н,
J
зависит от J, то справедливо тождество
(ИМЯФАЙЛА) join proj J, К (ИМЯ ФАЙЛА).
Это означает, что при наличии функциональной зависимости К от J проекции
proj Н, J (ИМЯФАЙЛА)
и proj J, К, (ИМЯФАЙЛА)
образуют полную декомпозицию
исходного файла.
Доказательство теоремы. Возможные значения Н, J и К будем обозначать
соответственно h и h’ j и j', k и k'. Каждая из указанных величин фактически
может представлять собой совокупность значений нескольких полей.
Начнем доказательство с того, что введем вспомогательный файл ИМЯФАЙЛА1:
ИМЯ ФАЙЛА1 = proj Н, J (ИМЯФАЙЛА) join proJ J, К (ИМЯФАЙЛА).
Возьмем произвольную запись hjk, входящую в ИМЯФАЙЛА. Очевидно, hj
принадлежит проекции proj Н, J (ИМЯФАЙЛА), a jk - проекции proj J. К (ИМЯФАЙЛА).
Исходя из определения ИМЯФАЙЛА1
и свойств операции соединения, можно
заключить, что запись hjk входит в файл ИМЯФАЙЛА1. Следовательно,
каждая
запись ИМЯФАЙЛА
является одновременно и записью ИМЯФАЙЛА1Далее
рассмотрим произвольную запись h'j'k’ из файла ИМЯФАЙЛА1.
Согласно определению файла ИМЯФАЙЛА1 выполняется равенство
proj Н, J (ИМЯФАЙЛА1) = proj Н, J (ИМЯФАЙЛА).
Отсюда можно сделать вывод, что в ИМЯФАЙЛА присутствует запись h’j’k’.
Аналогичным образом равенство
proj J, К (ИМЯФАЙЛА1) = proj J, К (ИМЯФАЙЛА)
позволяет утверждать, что ИМЯФАЙЛА содержит запись hj’k'. Поскольку К
функционально зависит от J, в записи h'j'k' и hj'k' входит одно и то же значение
]'. Следовательно, k = k' и h'j’k = h'j'k'. Последнее означает, что каждая
запись ИМЯФАЙЛА1 присутствует в ИМЯФАЙЛА. Учитывая, что выполняется и
обратное, можно сделать вывод, что эти два файла тождественны, т. е. ИМЯФАЙЛА =
ИМЯФАЙЛА1). Этим и завершается доказательство теоремы Хита.
3.7. НОРМАЛИЗАЦИЯ НА
ОСНОВЕ ФУНКЦИОНАЛЬНОЙ
ЗАВИСИМОСТИ
3.7.1. ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА
Теорема Хита создает основу для построения различных полных
декомпозиций, которые образуются из проекций, не содержащих общего для всех них
ключа-кандидата. Начнем с того, что проанализируем условия, определяющие
принадлежность файла к определенной нормальной форме, последовательно переходя
от первой формы ко второй, затем к третьей и т.д.
Наиболее' общими свойствами среди нормальных форм обладает первая, с
которой и начнем обсуждение. Файл находится в первой нормальной форме тогда и
только тогда, когда ни одна из его записей не содержит в любом своем поле более
одного значения и ни одно из ее ключевых полей не пусто. В качестве примера
возьмем файл СОСТАВ_АНСАМБЛЯ
НОМАНС
{Номер ансамбля}
УЧАСТНИКИ
{Номера присвоенные музыкантам, играющим в ансамбле}
Предположим, что
НОМАНС
Е1
Е2
ЕЗ
Е4
Е5
Е6
Е7
СОСТАВ_АНСАМБЛЯ включает следующие данные:
УЧАСТНИКИ
Р1, Р8, Р9
РЗ, Р5
Р9
P1, Р4, Р7
Р5, Р9
Р1, Р7
РЗ, Р5
Большинство записей файла содержат по несколько номеров в поле УЧАСТНИКИ
- следовательно, это не первая нормальная форма. В то же время все музыкальные
файлы из разд. 2.2 имеют первую нормальную форму, поскольку в каждом поле любой
их записи помещается ровно по одному знaчению. Заметим, что строки символов,
подобные записанным в поле АДРЕС файла АДРЕСА_КЛИЕНТОВ, рассматриваются как
отдельные значения.
3.7.2. ВТОРАЯ НОРМАЛЬНАЯ
ФОРМА
Как пояснялось в разд. 1.2.3, первичным ключом принято называть наиболее
удобный для доступа в записям файла ключ-кандидат. Например, фирма <Типико> в
качестве первичного ключа файла КЛИЕНТЫ использует поле НОМЕР_КЛИЕНТА.
Файл считается представленным во второй нормальной форме в том и только в
том случае, если все его поля, не входящие в первичный ключ, связаны полной
функциональной зависимостью с первичным ключом.
В частности, файл ЗВЕРИ_В_НЕВОЛЕ из разд. 3.2 не может быть отнесен ко
второй нормальной форме, поскольку поле ЗОНА_ОБИТАНИЯ
функционально зависит
от поля ЖИВОТНОЕ и тем самым не находится в полной функциональной зависимости
от первичного ключа, образуемого парой ЗООПАРК, ЖИВОТНОЕ.
Описанный в разд. 3.3.1 файл ПОСТАВЩИКИ_ТОВАРОВ, напротив, удовлетворяет
определению второй нормальной формы, так как его поля НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА
функционально полностью зависят от первичного ключа, которым служит ШИФР_ТОВАРА.
Первичный ключ файла ЗАКАЗЫ
из разд. 3.6.1 состоит из двух полей:
НОМЕР_ЗАКАЗА
и ШИФР_ТОВАРА. В то время как поле КОЛИЧЕСТВО
находится в
полной функциональной зависимости от первичного ключа, поле ОПИСАНИЕ
просто
зависит от него, и поэтому файл ЗАКАЗЫ не представлен во второй нормальной
форме.
Легко показать, что любой файл, не отвечающий определению второй
нормальной формы, не может находиться и в пятой нормальной форме. Предположим,
что таким файлом является ИМЯФАЙЛА. Набор из одного или нескольких неключевых
полей ИМЯФАЙЛА, функционально зависящих от первичного ключа, обозначим К, а
подмножество полей первичного ключа, от которых К функционально зависит
полностью, - J. Совокупность остальных полей ИМЯФАЙЛА,
не входящих в К или J,
назовем Н. Согласно теореме Хита, указанная функциональная зависимость влечет
тождество: ИМЯФАЙЛА = proj Н, J (ИМЯФАЙЛА join proj J, К (ИМЯФАЙЛА).
Проекции в правой части тождества не имеют общего ключа-кандидата.
Следовательно, ИМЯФАЙЛА не находится в пятой нормальной форме и подлежит
поэтому нормализации. Имеется в виду, что его следует заменить полной
декомпозицией, объединяющей проекции в пятой нормальной форме. Для файла
ЗВЕРИ_В_НЕВОЛЕ такую декомпозицию можно составить, в частности, из проекций
proj ЗООПАРК, ЖИВОТНОЕ (ЗВЕРИ_В_НЕВОЛЕ) и
proj ЖИВОТНОЕ, ЗОНА_ОБИТАНИЯ (ЗВЕРИ_В_ НЕВОЛЕ).
Нормализация файла ЗАКАЗЫ
осуществляется путем разложения на проекции
proj НОМЕР_ЗАКАЗА, ШИФР_ТОВАРА, КОЛИЧЕСТВО (ЗАКАЗЫ) и
proj ШИФР_ТОВАРА, ОПИСАНИЕ (ЗАКАЗЫ).
3.7.3. ТРЕТЬЯ НОРМАЛЬНАЯ
ФОРМА
Файл представлен в третьей нормальной форме, если и только если он
удовлетворяет определению второй нормальной формы и ни одно из его неключевых
полей не зависит функционально от любого другого неключевого поля.
Если ввести ограничение, запрещающее записывать в файл ПОСТАВЩИКИ_ТОВАРОВ
из разд. 3.3.1 фирмы-поставщики с одинаковыми названиями, он потеряет третью
нормальную форму, поскольку его поле НОМЕР_ТЕЛЕФОНА станет связано
Функциональной зависимостью с полем НАЗВАНИЕ, не являющимся ключом. В то же
время, благодаря тому, что поле АДРЕС файла АДРЕСА_КЛИЕНТОВ функционально не
зависит от поля НАЗВАНИЕ, этот файл имеет третью нормальную форму.
Можно доказать, что любой файл ИМЯФАЙЛА,
который не представлен в
третьей нормальной форме, не может находиться в пятой нормальной форме. Для
этого определим К как набор неключевых полей, обладающих функциональной
зависимостью от другого набора неключевых полей, которое обозначим J. Введем
также совокупность полей Н файла ИМЯФАЙЛА, не принадлежащих J или К. Наличие
указанной функциональной зависимости согласно теореме Хита приводит к тождеству
ИМЯФАЙЛА = proj Н, J (ИМЯФАЙЛА)
join proj J, К (ИМЯФАЙЛА).
Проекции в правой части тождества не имеют общего ключа- кандидата.
Следовательно, ИМЯФАЙЛА не находится в пятой нормальной форме и его следует
нормализовать, заменив этими проекциями. Так, например, файл
ПОСТАВЩИКИ_ТОВАРОВ {разд 3.3.1) можно нормализовать, замещая его проекциями
proj ШИФР_ТОВАРА,
НАЗВАНИЕ
(ПОСТАВЩИКИ_ТОВАРОВ) и
proj НАЗВАНИЕ, НОМЕР_ТЕЛЕФОНА
(ПОСТАВЩИКИ_TOBAРОB).
3.7.4. НОРМАЛЬНАЯ ФОРМА БОЙСА-КОДДА
Следующим шагом по сравнению с третьей нормальной формой является
нормальная форма Бойса-Кодда (НФБК). По определению, файл находится в НФБК, если
и только если любая функциональная зависимость между его полями сводится
к полной функциональной зависимости от ключа-кандидата.
Примером файла, который представлен в третьей нормальной форме
но не
имеет НФБК, может служить файл СТОРОЖА_ЗООПАРКОВ:
ЗООПАРК
эйтон
эйтон
БИТОН
БИТОН
ЖИВОТНОЕ
КЕНГУРУ
ВПГБЛЮД
ЭМУ
ВЕРБЛЮД
СТОРОЖ
ПОНСОНБИ
ПОНСОПБИ
КАРУЗЕРС
ГЕРДЛСТОН
Пара ЗООПАРК,
ЖИВОТНОЕ
составляет ключ-кандидат, от которого поле
СТОРОЖ находится в полной функциональной зависимости. Однако из-за того, что
поле ЗООПАРК, входящее в ключ-кандидат, функционально зависит от поля СТОРОЖ,
данный файл не находится в НФЬК.
Для того чтобы доказать, что любой файл, не имеющий НФБК, не может
находиться в пятой нормальной форме, рассмотрим произвольный файл ИМЯФАЙЛА.
Пусть К - набор полей этого файла, связанный полной функциональной зависимостью
с другим набором полей J, который не является ключом-кандидатом. Как и в
предыдущих случаях, введем совокупность полей Н, не принадлежащих J или К. В
силу наличия функциональной зависимости из теоремы Хита следует, что
ИМЯФАЙЛА = proj Н, J (ИМЯФАЙЛА) join proj J, К (ИМЯ ФАЙЛА).
Две проекции в правой части тождества не содержат общего ключа-кандидата,
ввиду чего можно утверждать, что ИМЯФАЙЛА не представлен в пятой нормальной
форме и может быть нормализован путем разложения на свои проекции. Файл
СТОРОЖА_ЗООПАРКОВ, например, можно нормализовать, заменив его проекциями
proj ЖИВОТНОЕ, СТОРОЖ (СТОРОЖА_ЗООПАРКОВ) и
proj СТОРОЖ, ЗООПАРК (СТОРОЖА_ЗООПАРКОВ).
3.8. УПРАЖНЕНИЯ
Анализируя файлы, заданные в каждом из упражнений 1-5, необходимо решить
следующие задачи:
а) перечислить все имеющиеся функциональные зависимости между полями. (Чтобы
составить такой перечень, следует сначала выяснить, не связано ли каждое поле
функциональными зависимостями со всеми из оставшихся полей по отдельности, затем
со всевозможными парами из числа оставшихся полей и т. д.);
б) полагая, что множество функциональных зависимостей исчерпывается
найденными, нормализовать файл, т. е. заменить его проекциями в НФБК;
в) привести один пример, в котором за счет нормализации сокращается
дублирование, и еще один пример, показывающий, как благодаря нормализации
удается сохранить присоединенную запись, которая была бы исключена из
ненормализованного файла.
1. Дано содержимое файла, имеющего
ПОМЕСТЬЕ
ГЕЙБЛЗ
ГЕЙБЛЗ
КОЗИКОТ
КОЗИКОТ
поля со следующими именами:
САДОВЫЕ_ЦВЕТЫ
НАРЦИССЫ
РОЗЫ
КОЛОКОЛЬЧИКИ
РОЗЫ
СЕЗОН_ЦВЕТЕНИЯ
ВЕСНА
ЛЕТО
ВЕСНА
ЛЕТО
2. Дано содержимое файла, имеющего поля со следующими именами:
ВИД_СПОРТА
ПРЫЖКИ в ДЛИНУ
БЕГ НА 100 М
100 М С БАРЬЕРАМИ
ПРЫЖКИ С ШЕСТОМ
ПОБЕДИТЕЛЬ
АРМСТРОНГ
МАРШАЛЛ
МАРШАЛЛ
УИЛЬЯМС
ГОД_РОЖДЕНИЯ_ПОБЕДИТЕЛЯ
1972
1969
1969
1969
3. Дано содержимое файла, имеющего поля со следующими именами:
ФАМИЛИЯ
АРМСТРОНГ
АРМСТРОНГ
ВЕК
НАЙТ
НАПИТОК
ВИСКИ
ХЕРЕС
ВИСКИ
ХЕРЕС
КОЛИЧЕСТВО_ПОРЦИЙ
3
1
1
2
ЦЕНА_ЗА_ПОРЦИЮ
40
30
40
30
4. Дано содержимое файла, имеющего поля со следующими именами:
ВЛАДЕЛЕЦ_АВТОМОБИЛЯ
АРМСТРОНГ
ДАТА_РОЖДЕНИЯ
июнь 1960
N_РЕГИСТРАЦИИ
АНС134Т
ДАТА_РЕГИСТРАЦИИ
июнь 1979
АРМСТРОНГ
ВЕК
НАЙТ
июнь 1960
май 1959
июль 1961
BCY529
AHD339H
ОУУ796Р
5. Дано содержимое файла, имеющего
именами:
НОМЕР_ДОРОГИ
ПРОТЯЖЕННОСТЬ
A3
352
A3
352
А4
219
А4
219
май 1980
октябрь 1972
январь 1976
поля со следующими
ГОРОД
АРБИ
ТИТОН
АРБИ
ЭСФИЛД
НАСЕЛЕНИЕ
25632
62310
25632
25632
Для простоты можно считать, что в файле нет двух городов
G одинаковыми названиями.
3.9. ЧЕТВЕРТАЯ НОРМАЛЬНАЯ
ФОРМА
Для того чтобы перейти от НФБК к следующей нормальной форме, необходимо
несколько расширить условия теоремы Хита. Конструктивное определение четвертой
нормальной формы, занимающей промежуточное положение между НФБК и пятой,
основывается на понятии обобщенной функциональной зависимости. Здесь это понятие
не вводится, поскольку требует привлечения достаточно объемистого материала.
Сформулированный ниже вариант определения нельзя считать полноценным,
так как в нем не содержится ответа на вопрос, образует ли данная пара проекций
полную декомпозицию файла.
Будем говорить, что файл представлен в четвертой нормальной форме, если и
только если каждая его полная декомпозиция из двух проекций такова, что обе
проекции не содержат общего ключа-кандидата.
Сконструируем пример файла, который, будучи в НФБК, не находится в
четвертой нормальной форме. Для этого несколько преобразуем структуру
музыкального файла ИСПОЛНЕНИЯ так, чтобы в него можно было записывать номера
всех сочинений (НОМСОЧ),
исполнявшихся на каждом концерте. Кроме того,
заменим поле НОМАНС, в которое будут заноситься номера всех исполнителей,
выступавших на каждом концерте. Сразу же можно отметить, что модернизированный
файл не отвечает требованиям, предъявляемым к первой нормальной форме,
поскольку его поля НОМСОЧ
и НОМИСП
могут содержать по нескольку значений.
ДАТА
19860530
19860615
и т.п.
ГОРОД
ТИТОН
АРБИ
СТРАНА
ТИЛАНДИЯ
ЭКСЛАНДИЯ
НОММУЗ
М9
М1
НОМСОЧ
С 1, СЗ, С5
СЗ, С4, С6
НОМИСП
Р8, Р9
Р1, Р4, Р7
Можно получить эквивалентную нормальную форму (по крайней мере, первую),
соединив два файла, которые назовем НАБОР_СОЧ НАБОР_ИСП. Первый из них должен
содержать следующую информацию:
ДАТА
19860530
19860530
19860530
19860615
19860615
19860615
ГОРОД
ТИТОН
ТИТОН
ТИТОН
АРБИ
АРБИ
АРБИ
СТРАНА
ТИЛАНДИЯ
ТИЛАНДНЯ
ТИЛАНДИЯ
ЗКСЛАНДИЯ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
НОМСОЧ
С1
СЗ
С5
СЗ
С4
С6
В этом файле (он имеет первую нормальную форму) указаны номера всех
произведений, исполненных на каждом концерте. Файл НАБОР_ИСП, также
представленный в первой нормальной форме, позволяет выяснить, что за исполнители
участвовали в каждом концерте. Его содержимое таково:
ДАТА
19860530
ГОРОД
ТИТОН
СТРАНА
ТИЛАНДИЯ
НОММУЗ
М9
НОМИСП
Р8
19860530
19860615
19860615
19860615
и т. д.
ТИТОН
АРБИ
АРБИ
АРБИ
ТИЛАНДИЯ
ЭКСЛАНДИЧ
ЭКСЛАНДИЯ
ЭКСЛАНДИЯ
М9
М
М1
MI
Р9
Р1
Р4
Р7
Соединению файлов НАБОР_СОЧ и НАБОР_ИСП присвоим имя НОВИСПОЛНЕНИЯ.
Операция соединения осуществляется по трем полям - ДАТА, ГОРОД и СТРАНА.
Ключевыми полями файла НОВИСПОЛНЕНИЯ
являются ДАТА, ГОРОД, СТРАНА,
НОМИСП и НОМСОЧ,
так что он, очевидно, представлен в НФБК. Однако
НОВИСПОЛНЕНИЯ не находится в четвертой нормальной форме, хотя его проекции
НАБОР_СОЧ и НАБОР_ИСП образуют полную декомпозицию. Эти проекции имеют общие
поля ДАТА,
ГОРОД
и СЫГРАНА, которые составляют лишь часть ключа-кандидата,
и поэтому любое сочетание значений этих трех полей может присутствовать в файле
НОВИСПОЛНЕНИЯ произвольное число раз.
Файл, не представленный в четвертой нормальной форме, не имеет и пятой
нормальной формы, ввиду чего может быть нормализован. По отношению к файлу
НОВИСПОЛНЕНИЯ,
например, это означает, что его следует заменить проекциями
НАБОР_СОЧ и НАБОР_ИСП.
Для того чтобы можно было выявить принадлежность конкретного слайда к
четвертой нормальной, форме, необходимо иметь способ определения полных
декомпозиций. В тех случаях, когда файл, как в примере с НОВИСПОЛНЕНИЯ, либо уже
записан, либо наверное может быть записан в виде соединения двух проекций,
распознавание полной декомпозиции не составляет труда.
В определении пятой нормальной формы, данном в разд. 3.5.1. число
проекций, образующих полную декомпозицию файла и содержащих общий ключкандидат, не лимитируется. Очевидно, четвертая нормальная форма представляет
специальный случай пятой, когда полная декомпозиция должна быть соединением
ровно двух проекций.
Весьма не просто подобрать реальный файл, который находился бы в
четвертой, но не был бы в пятой нормальной форме. Как уже говорилось,
нормализация, в сущности, сводится к получению файлов в пятой нормальной форме.
На практике, приведя все файлы к НФБК, с большой гарантией можно утверждать,
что они имеют и пятую нормальную форму. Разумеется, этот факт нуждается и
проверке, и при возможности ее всегда следует выполнять.
Наиболее просто проводить нормализацию поэтапно. Сначала все неприведенные
файлы заменяются соответствующими проекциями в третьей нормальной форме. Затем
полученные файлы подвергаются проверке на предмет выполнения требований,
предъявляемых к НФБК. Те файлы, что не находятся в этой форме, приводятся к
ней. После этого осуществляется проверка на наличие четвертой нормальной формы.
Как правило, обнаружить, что условия существования четвертой формы не
выполняются, бывает очень нетрудно. Далее следовало бы удостовериться, не
оказались ли уже все файлы в пятой нормальной скорме. К сожалению,
эффективного алгоритма проверки для этого этапа нормализации пока не
предложено.
3.10. ОБЪЕКТЫ И
АТРИБУТЫ
3.10.1. ФУНКЦИОНАЛЬНАЯ
ЗАВИСИМОСТЬ АТРИБУТОВ
ОТ ОБЪЕКТОВ
Вполне естественно возникает вопрос - как определить, какие файлы
необходимы и какие поля должны в них помещаться? Пытаясь ответить на него, можно
начать с перечисления имен полей в том порядке, в котором они располагаются
внутри каждого отдельного файла. Далее можно проверить, не связано ли каждое
поле функциональной зависимостью с наборами других полей и, последовательно
применяя теорему Хита, сформировать в конечном итоге совокупность проекций в
НФБК. Отправным пунктом может, например, служить такой перечень полей:
НОМЕР_СЧЕТА
ДАТА_ПРЕДЪЯВЛЕНИЯ_СЧЕТА
НОМЕР_НАРЯДА
ШИФР_ТОВАРА
КОЛИЧЕСТВО_ЕДИНИЦ
ПЛАТА_ЗА_ДОСТАВКУ
ОБЩАЯ_СУММА
НОМЕР_КЛИЕНТА
ИМЯ_ПОКУПАТЕЛЯ
АДРЕС_ДЛЯ_РАСЧЕТОВ
ПРЕДЕЛЬНЫЙ_РАЗМЕР_КРЕДИТА
ТОРГОВАЯ_ЗОНА
Выявление всех функциональных зависимостей даже в этом, сравнительно
небольшом, списке представляет весьма трудоемкую задачу, не говоря уж о более
протяженных.
Предпочтительнее иной подход, в основе которого лежит следующее свойство
первичного ключа файла: либо он идентифицирует объект, либо определяет
соотношение между объектами. Под объектом понимается нечто материальное,
например товар, хранящийся на складе, или некоторый признак, например цвет
предмета. Чаще всего файлы используются как носители информации об объектах и
их атрибутах. В таких файлах неключевые поля являются атрибутами объектов,
идентифицируемых первичными ключами. Примером могут служить поля файла
АДРЕСА_КЛИЕНТОВ,
обсуждавшегося в разд. 3.3.2: НАЗВАНИЕ и АДРЕС
являются
атрибутами клиентов, которые однозначно определяются значениями первичного
ключа НОМЕР-КЛИЕНТА.
Файлы могут применяться и как описания соотношений между объектами в тех
случаях, когда необходимо хранить атрибут подобных соотношений и/или когда эти
файлы служат связками при выполнении операций соединения файлов, содержащих
информацию об объектах.
Проиллюстрируем эти положения на примере музыкальных файлов.
Файл АНСАМБЛИ
содержит такие атрибуты каждого ансамбля, как его
название, страна, где он был организован, его руководитель. Сами ансамбли
представляют объекты, идентифицируемые первичным ключом НОМАНС.
В файле
МУЗЫКАНТЫ имя музыканта, дата его рождения и страна, где он родился,
представляют атрибуты музыканта, однозначно определяемого по первичному ключу
НОММУЗ.
Файл ИСПОЛНИТЕЛИ описывает соотношения между двумя объектами, которые
идентифицируются
полями НОММУЗ и ИНСТРУМЕНТ.
Поле ОЦЕНКА
- это атрибут
соотношения между музыкантом и его инструментом, принимающий значения
от СКВЕРНО до ОТЛИЧНО.
Совместно поля НОММУЗ
и ИНСТРУМЕНТ
образуют ключкандидат файла ИСПОЛНИТЕЛИ. Желательно иметь еще один ключ-кандидат для
перекрестных ссылок, в связи с чем файл ИСПОЛНИТЕЛИ
дополнен полем
НОММУЗ,
которое используется как первичный ключ.
Файл УЧАСТНИКИ_АНСАМБЛЕЙ также описывает соотношение между двумя типами
объектов - исполнителями и ансамблями. Как можно выяснить из гл. 2, без этого
файла трудно обойтись, хотя в нем и не содержится никаких атрибутов указанного
соотношения. Их отсутствие означает, что оба поля файла УЧАСТНИКИ.
АНСАМБЛЕЙ
являются ключевыми.
Инструмент в музыкальных файлах выступает как объект, однако никаких
атрибутов этого объекта хранить не предполагалось, в связи с чем специальный
файл ИНСТРУМЕНТЫ не заводился.
Воспользуемся всеми этими сведениями при анализе списка полей, помещенного
в начале раздела. Попытаемся выяснить, какие понадобятся файлы и как
распределятся поля по этим файлам. Начнем с того, что определим объекты,
атрибуты которых должны храниться в файлах. Не вызывает сомнений, что такими
объектами являются счета и клиенты.
Очевидно, поле НОМЕР_СЧЕТА
может служить первичным ключом и
использоваться для идентификации счетов. Поля ДАТА_ПРЕДЪЯВЛЕНИЯ_СЧЕТА,
ПЛАТА_ЗА_ДОСТАВКУ, НОМЕР_КЛИЕНТА и ОБЩАЯ_СУММА следует рассматривать
как атрибуты счетов. В приведенном выше списке других атрибутов, связанных со
счетами, не имеется. Отсюда можно сделать вывод, что первый из планируемых
файлов должен обладать следующей структурой:
ЗАГОЛОВКИ_СЧЕТОВ
{Имя файла)
HOMEР_СЧЕТА
ДАТА_ПРЕДЪЯВЛЕНИЯ_СЧЕТА
HOMEР_КЛИЕНТА
ПЛАТА_ЗА_ПОСТАВКУ
ОБЩАЯ_СУММА
{Первичный ключ файла}
{Суммарная плата за доставку всехтоваров}
{Общая сумма выплат по счету}
Второй тип объектов представляют клиенты, идентифицируемые первичным
ключом НОМЕР_КЛИЕНТА. Данным объектам в списке соответствуют атрибуты
ИМЯ_ПОКУПАТЕЛЯ, АДРЕС_ДЛЯ_РАСЧЕТОВ, ПРЕДЕЛЬНЫЙ_РАЗМЕР_КРЕДИТА и ТОРГОВАЯ_ЗОНА.
Учитывая это, логично предложить следующую структуру для второго файла:
КЛИЕНТЫ
{Имя файла)
НОМЕР_КЛИЕНТА
ИМЯ_ПОКУПАТЕЛЯ
АДРЕС_ДЛЯ_РАСЧЕТОВ
ПРЕДЕЛЬНЫЙ_РАЗМЕР_КРЕДИТА
ТОРГОВАЯ_ЗОНА
Можно заметить, что ни в один из файлов не вошло поле КОЛИЧЕСТВО_ЕДИНИЦ,
которое должно играть роль атрибута. Не исключено, что любой из товаров
фигурирует в нескольких счетах, причем всякий раз КОЛИЧЕСТВО_ЕДИНИЦ
может
принимать различные значения. Следовательно, это поле функционально не зависит
от поля ШИФР. ТОВАРА и вообще оно не может рассматриваться как атрибут какоголибо из объектов. Однако оно все же является атрибутом, но не объекта, а
соотношения между двумя объектами - счетом и товаром. Еще одним атрибутом того
же соотношения служит НОМЕР_НАРЯДА. Это поле идентифицирует наряд на продажу, в
котором записан данный товар, вследствие чего последний и был включен в счет.
Принимая во внимание эти атрибуты, необходимо сформировать еще один файл
следующей структуры:
СОДЕРЖАНИЕ_СЧЕТОВ {Имя файла}
НОМЕР_СЧЕТА
ШИФР_ТОВАРА
КОЛИЧЕСТВО_ЕДИНИЦ
НОМЕР_НАРЯДА
Поскольку в рассматриваемом примере нет ни одного атрибута,
характеризующего продаваемые товары, нет нужды заводить такой файл, как
ТОВАРНЫЕ_ЗАПАСЫ. Вообще, помимо трех сформированных файлов, включивших все поля
из приведенного в начале раздела списка, очевидно, никаких других не требуется.
Отметим, что эти три файла находятся в НФБК и, более того, в пятой нормальной
форме.
Если бы поля НОМЕР_СЧЕТА и НОМЕР_КЛИЕНТА отсутствовали в первоначальном
списке, их в любом случае пришлось бы ввести, чтобы обеспечить с помощью
перекрестных ссылок связь между файлами. (Напомним, что с той же целью
музыкальный файл ИСПОЛНИТЕЛИ был дополнен полем НОМИСП. Приобретя опыт работы с
файлами, можно оценить выигрыш, получаемый от введения дополнительных ссылок
типа номера НОМИСП).
Итак, в результате анализа объектов, атрибутов и соотношений между ними
определены структуры файлов. Далее необходимо проверить, соблюдаются ли
следующие требования:
а) все файлы имеют НФБК (разумеется, предпочтительнее - пятую нормальную
форму);
б) соединение сформированных файлов включает все поля, подлежащие хранению.
Если обнаружится, что указанные требования не выполняются, файлы нуждаются
в перекомпоновке. Например, могло случиться так, что поле НОМЕР_КЛИЕНТА не было
включено в файл ЗАГОЛОВКИ_СЧЕТОВ. В этом случае из соединения трех файлов
выпало бы поле ИМЯ_ПОКУПАТЕЛЯ. В подобных ситуациях весь анализ необходимо
проводить заново.
3.10.2. ПОСТРОЕНИЕ НАБОРА ФАЙЛОВ ПО ЭМПИРИЧЕСКИМ
ДАННЫМ
В этом разделе обсуждаются несколько достаточно простых примеров,
иллюстрирующих, каким образом производится формирование файлов и закрепление за
ними полей в тех случаях, когда постановка задачи носит эмпирический характер.
Футбольные состязания. Требуется подобрать выразительные имена файлов и
полей этих файлов, которые предполагается использовать для хранения данных,
касающихся графика проведения игр, запланированных для клубной футбольной
команды г. Бигчестер. Нужно запоминать следующую информацию: дату встречи,
название стадиона, где она должна произойти, вместимость стадиона, ожидаемое
количество зрителей, а также расстояние от Бигчестера до места, где расположен
стадион.
Начнем с определения объектов, которым будут приписаны запоминаемые в
файлах атрибуты. Назовем их МАТЧИ
(MATCHES) и СТАДИОНЫ
(GROUNDS). Для
каждого из этих двух объектов заведем отдельный файл со следующими полями:
МАТЧИ
{Имя файла)
ДАТА_ВСТРЕЧИ (MATCH DATE)
НАЗВАНИЕ_СТАДИОНА (NAME OF GROUND)
ЗРИТЕЛИ (EXPECTED GROUND ATTENDANCE)
СТАДИОНЫ
{Имя файла)
НАЗВАНИЕ_СТАДИОНА (NAME OF GROUND)
РАССТОЯНИЕ_ОТ_БИГЧЕСТЕРА (DISTANCE FROM BIGCHESTER TO THIS GROUND)
ВМЕСТИМОСТЬ (GROUND CAPACITY)
Заметим,
функциональной
если бы вместо
представляющий
форму.
что ни одно из неключевых полей файла СТАДИОНЫ не связано
зависимостью с полем НАЗВАНИЕ_СТАДИОНА. И еще одно замечание:
двух файлов, МАТЧИ
и СТАДИОНЫ,
был сформирован лишь один,
соединение МАТЧИ join СТАДИОНЫ, он имел бы третью нормальную
Библиотечное дело. Этот пример несколько сложнее. Вновь предстоит найти
имена для файлов и полей, которые войдут в базу данных городской библиотеки
Бигчестера. Кроме центрального отделения, эта библиотека имеет также ряд
филиалов в отдаленных районах города. Каждому абоненту при регистрации
вручается читательский билет с уникальным номером. Читателю разрешается брать
книги и в центральной библиотеке и в любом из ее филиалов, причем все они
пользуются единым каталогом. Каждая книга идентифицируется стандартным
международным библиотечным шифром ISBN (естественно, у всех экземпляров
книги одинаковый ISBN; переиздания той же книги имеют другие шифры ISBN). Одно
или большее число отделений библиотеки может располагать несколькими
экземплярами книги, а также разными ее переизданиями. Когда книга поступает в
библиотеку Бигчестера, ей присваивается отдельный инвентарный номер, посредством
которого идентифицируется конкретный экземпляр данного издания. Ни у одной из
книг (даже если они находятся в разных хранилищах) инвентарные номера не
совпадают - все экземпляры с одинаковыми шифрами ISBN имеют разные инвентарные
номера. Каждый экземпляр книги должен иметь своего рода паспорт, включающий
такие данные, как название, имена авторов, издание (например, второе), страна и
город опубликования, название издательства, дата выхода книги, число страниц,
инвентарный номер, номер отделения и номер стеллажа. Номер отделения указывает,
в каком филиале (или в центральной библиотеке) постоянно находится книга, а по
номеру стеллажа можно определить, где именно она стоит. В файлах необходимо
также хранить адреса и названия отделений библиотеки и регистрационные данные
каждого абонента. Наконец, должны фиксироваться даты получения и возврата книг.
Как и в предыдущем случае, начнем с того, что выделим из множества
перечисленных данных объекты и относящиеся к ним атрибуты. Кроме того, определим
те соотношения, с которыми связаны некоторые из запоминаемых атрибутов, а также
те, что будут использоваться при соединении файлов. Анализ показывает, что к
числу объектов и соотношений, для которых потребуются отдельные файлы, должны
быть отнесены следующие:
АБОНЕНТЫ
КНИГИ
ВЫДАЧА_КНИГ
{Объект}
{Объект}
{Соотношение}
ПУБЛИКАЦИИ
ОТДЕЛЕНИЯ
{Объект (файл каталога)}
{Объект}
Сформировав такой перечень, довольно нетрудно выяснить, какие атрибуты
следует приписать каждому объекту или соотношению.
АБОНЕНТЫ
НОМЕР_ЧИТАТЕЛЬСКОГО_БИЛЕТА
ИМЯ_АБОНЕНТА
АДРЕС_АБОНЕНТА
КНИГИ
ИНВЕНТАРНЫЙ_НОМЕР
ISBN
НОМЕР_ОТДЕЛЕНИЯ
НОМЕР_СТЕЛЛАЖА
{Имя файла. Ниже приведены имена
его полей}
{Первичный ключ, идентифицирующий
абонента библиотеки}
{Имя файла. Ниже перечислены имена
его полей}
(Первичный ключ, идентифицирующий
конкретный экземпляр книги}
{Используется для доступа к информации
из каталога}
Структура последнего файла несколько упрощена за счет того, что вместо
двух полей, НАЗВАНИЕ_ОТДЕЛЕНИЯ и АДРЕС_ОТДЕЛЕНИЯ, в него включено лишь одно –
НОМЕР_ОТДЕЛЕНИЯ. Связь между полем НОМЕР_ОТДЕЛЕНИЯ и парой НАЗВАНИЕ-ОТДЕЛЕНИЯ,
АДРЕС_ОТДЕЛЕНИЯ устанавливается c помощью дополнительного файла ОТДЕЛЕНИЯ.
ОТДЕЛЕНИЯ
НОМЕР_ОТДЕЛЕНИЯ
НАЗВАНИЕ_ОТДЕЛЕНИЯ
АДРЕС_ОТДЕЛЕНИЯ
{Имя файла. Ниже перечислены имена
его полей}
(Первичный ключ}
Получение книги можно рассматривать как соотношение, связывающее
конкретного читателя с конкретной книгой. Атрибутом этого соотношения является
ДАТА_ВОЗВРАТА.
ВЫДАЧА_КНИГ
НОМЕР_ЧИТАТЕЛЬСКОГО_БИЛЕТА
ИНВЕНТАРНЫЙ_НОМЕР
ДАТА_ВОЗВРАТА
{Имя файла. Ниже перечислены имена
его полей}
{Поле, идентифицирующее абонента
библиотеки}
{Поле, идентифицирующее данный экземпляр книги}
Первичный ключ этого файла образуют два первых поля. Учитывая, что в
библиотеке могут храниться несколько экземпляров книги с одним и тем же шифром
ISBN, последний не может служить ключом файла КНИГИ. Такие атрибуты, как
ИМЕНА_АВТОРОВ и НАЗВАНИЕ, функционально зависят от ISBN, и поэтому вместо файла
КНИГИ они должны быть включены в файл каталога.
КАТАЛОГ
ISBN
НАЗВАНИЕ
ИЗДАНИЕ
ИМЕНА_АВТОРОВ
НАЗВАНИЕ_ИЗДАТЕЛЬСТВА
ГОРОД
СТРАНА
(Имя файла. Ниже перечислены его
поля}
{Первичный ключ}
{Заголовок книги}
{Например, второе}
Этим необходимый набор файлов исчерпывается. Может показаться, что этот
набор следовало бы дополнить файлом авторов. Однако для них не имеет смысла
заводить отдельный файл, поскольку авторам в данном случае не приписано ни
одного атрибута. Еще раз подчеркнем, что файлы нужны только для тех объектов, с
которыми связаны подлежащие
хранению атрибуты. Примером может служить
объект <издательства>. Если бы такие атрибуты, как город и страна опубликования
книги, функционально зависели от него (что выполняется далеко не всегда),
можно было бы создать специальный файл издательств.
3.10.3. ПРЕОБРАЗОВАНИЕ НАБОРА ФАЙЛОВ
Не всегда требуется формировать файлы заново, опираясь лишь на данные
эмпирического анализа. В некоторых случаях задача состоит в нормализации уже
имеющейся совокупности файлов, не все из которых представлены в первой
нормальной форме.
Скачки (пример 1). В этом примере речь идет о скаковых лошадях и их
владельцах. Предстоит нормализовать два файла, названия которых соответствуют их
содержанию. Первый файл находится по меньшей мере в первой нормальной форме:
ЛОШАДИ (HORSES) {Имя файла. Ниже приведены имена
его полей и часть записей}
НОМЕР_ЛОШАДИ
(HORSE NUMBER)
КЛИЧКА_ЛОШАДИ
(HORSE NAME)
ЦВЕТ
(COLOUR)
ВЫСОТА
(HEIGHT)
ДАТА_ОЖДЕНИЯ
(DATE OF BIRTH)
НЗ
Н5
Н6
ТРАНКОЛ
ХОТПОТЕЙТО
СТРОГОУЛД
ГНЕДАЯ
ВОРОНАЯ
ГНЕДАЯ
165
170
164
19890630
19890212
19880105
ВЛАДЕЛЬЦЫ (OWNERS) {Имя файла. Ниже приведены имена
его полей и часть записей}
ИМЯ_ВЛАДЕЛЬЦА
(OWNER NAME)
АДРЕС
(ADDRESS)
ПРИНАДЛЕЖАЩИЕ_ЛОШАДИ
(HORSES OWNED)
ЭЙСОН
БИЙСОН
ДЖИЙСОН
КЛАМБЕРУИК
УИГХЭМСТЕД
ПЛАМХЕЙВН
Н7, Н10, Н18
НЗ, Н8
Н5, Н6, Н9, Н14
Этот файл не имеет первой нормальной формы, поскольку в каждой его
записи поле ПРИНАДЛЕЖАЩИЕ_ЛОШАДИ содержится по несколько значений. В
рассматриваемом примере только лошади и владельцы являются объектами,
атрибуты которых нуждаются в хранении. Следовательно, других файлов, кроме
приведенных, не требуется, и для их нормализации нужно лишь несколько изменить
состав полей. Если лошадь не может принадлежать более чем одному владельцу (в
данный момент), достаточно ввести в оба файла новое поле НОМЕР_ВЛАДЕЛЬЦА
(OWNER NUMBER)
и удалить из файла ВЛАДЕЛЬЦЫ поле ПРИНАДЛЕЖАЩИЕ_ЛОШАДИ.
Структура модифицированных файлов такова:
ВЛАДЕЛЬЦЫ
НОМЕР_ВЛАДЕЛЬЦА
ИМЯ_ВЛАДЕЛЬЦА
АДРЕС
ЛОШАДИ
НОМЕР_ЛОШАДИ
КЛИЧКА_ЛОШАДИ
ЦВЕТ
ВЫСОТА
ДАТА_РОЖДЕНИЯ
НОМЕР_ВЛАДЕЛЬЦА
Нормализацию
удалось осуществить благодаря тому, что каждая лошадь
имеет единственного хозяина, и поэтому в поле НОМЕР,
ВЛАДЕЛЬЦА
всегда
заносится ровно одно значение. В первоначальном варианте соответствие между
лошадьми и их владельцами устанавливалось посредством поля
ПРИНАДЛЕЖАЩИЕ_ЛОШАДИ. Поскольку любому владельцу может принадлежать несколько
лошадей, в это поле приходилось заносить все их номера.
Скачки (пример 2). Дополним предыдущий пример сведениями о жокеях и о тех
лошадях, на которых они выступали как минимум в одном состязании. Эта
информация помещается в ненормализованном файле ЖОКЕИ (JOCKEYS).
ЖОКЕИ {Имя файла. Ниже приведены имена его полей и
некоторые записи}
НОМЕР_ЖОКЕЯ
(JOCKEY NUMBER)
ИМЯ_ЖОКЕЯ
(JOCKEY NAME)
АДРЕС
(ADDRESS)
ЛОШАДЬ_ЖОКЕЯ
(HORSES RIDDEN)
J2
J4
J5
УИЛСОН
ЭНДРЮС
ХОБСОН
УИГЛСВИК
ЭЛФР^СТОН
ЭКЛСФИЛД
Н4, Н9, Н18
НЗ, Н4
НЗ, Н4, Н9, Н10
В поле ЛОШАДЬ_ЖОКЕЯ
может помещаться несколько различных значений,
поэтому файл не имеет первой нормальной формы. Два других файла, ЛОШАДИ и
ВЛАДЕЛЬЦЫ,
нормализованы описанным выше способом.
Если бы на каждой лошади выезжал единственный жокей, для приведения файла
ЖОКЕИ к нормальной форме достаточно было бы исключить из него поле ЛОШАДЬ_ЖОКЕЯ
и одновременно ввести в файл ЛОШАДИ поле НОМЕР_ЖОКЕЯ. К сожалению, так сделать
не удастся, поскольку лошадь может участвовать в скачках с разными жокеями. В
данном случае предлагается удалить из файла ЖОКЕИ поле ЛОШАДЬ_ЖОКЕЯ и создать
дополнительный файл, назвав его, скажем, ЛОШАДИ_НА_ СКАЧКАХ (HORSE RIDDEN).
ЛОШАДИ_НА_СКАЧКАХ{Имя файла. Ниже приводятся имена
его полей и часть записей}
НОМЕР_ЖОКЕЯ
J2
J2
J2
J4
J4
J5
J5
J5
J5
НОМЕР_ЛОШАДИ
Н4
Н9
Н18
НЗ
Н4
НЗ
Н4
Н9
Н10
Файлы ЛОШАДИ
и ВЛАДЕЛЬЦЫ
уже приведены к нормальной форме, так что
никаких изменений вносить в них не требуется. В итоге получен набор из четырех
файлов, причем все они нормализованы.
Остается выяснить, обязательно ли было заводить новый файл
ЛОШАДИ_НА_СКАЧКАХ. Дело в том, что поле ЛОШАДЬ. ЖОКЕЯ исходного файла ЖОКЕИ
представляет соотношение между жокеями и лошадьми. Учитывая, что жокеи могут
менять лошадей, а лошади - наездников, нельзя обеспечить однозначность этого
соотношения в любом из файлов, будь то ЛОШАДИ или ЖОКЕИ.
Единственный выход создать новый файл ЛОШАДИ_НА_СКАЧКАХ, описывающий данное соотношение в
нормализованной форме. Подчеркнем объективность полученного результата - четыре
файла, ВЛАДЕЛЬЦЫ, ЛОШАДИ, ЖОКЕИ и ЛОШАДИ_НА_СКАЧКАХ - это минимально
необходимый набор, позволяющий хранить атрибуты объектов <владельцы>,
<лошади> и <жокеи>, а также соотношения <лошади-жокеи>.
3.11. УПРАЖНЕНИЯ
1. Усложним пример с лошадьми, владельцами и жокеями, разобранный в разд.
3.10.3. Предлагается удалить файл ЛОШАДИ_НА_СКАЧКАХ и вместо него завести другие
файлы, в которых хранилась бы следующая информация относительно каждого
состязания: дата, время и место проведения скачек, их название (если таковое
имеется), кличка лошади, пришедшей первой, имя ее жокея, список лошадей и
жокеев, занявших второе и последующие места. Подберите имена, отражающие
содержание сформированной системы файлов и их полей.
2. В альпинистском клубе ведется хроника восхождений. Записываются даты
начала и завершения каждого восхождения, имена и адреса участвовавших в нем
альпинистов, название и высота горы, страна и район, где она расположена. Дайте
выразительные имена файлам и полям, в которые могла бы заноситься
указанная информация. Попытайтесь продемонстрировать на примере этих файлов, как
благодаря их нормализации удается решить проблемы дублирования данных и
сохранения присоединенных записей.
3. Четыре практикующих
врача-терапевта решили организовать своего рода
кооператив. Они завели файлы, в которых занесены имя, пол, дата рождения и
домашний адрес каждого их пациента. Всякий раз, когда врач осматривает
больного, явившегося к нему на прием, или сам приходит к нему на дом, он
записывает дату и место, где проводится осмотр, симптомы, диагноз и предписания
больному, проставляет имя пациента, а также свое. Если врач прописывает больному
какое-либо лекарство, в файл заносится его название, способ приема, словесное
описание предполагаемого действия и возможных побочных эффектов. Подыщите
выразительные имена для файлов и полей, содержащих всю перечисленную
информацию.
4. В базе данных бигчестерского муниципалитета хранятся имена, адреса,
домашние и служебные телефоны всех членов городского совета. Он объединяет
порядка сорока комиссий, все участники которых состоят в совете. Каждая
комиссия имеет свой профиль - одна, например, занимается вопросами образования,
другая решает проблемы, связанные с жильем и т. д. В муниципальной базе
данных записаны данные по каждой из комиссий: ее нынешний состав и
председатель, прежние председатели и члены этой комиссии, участвовавшие в ее
работе за прошедшие 10 лет, даты включения и выхода из состава комиссии,
избрания ее председателей. Многие члены совета заседают в нескольких комиссиях.
В файлы заносятся время и место проведения каждого заседания комиссии с
указанием служащих муниципалитета, которые будут участвовать в его организации.
Протокол заседания и список присутствующих на нем членов комиссии пишутся на
бумаге и в файлах не хранятся. Предлагается подобрать выразительные имена полей
и файлов для базы данных городского совета Бигчестера.
5. Даны три файла. Первый содержит информацию
судов:
НОМЕР-РЕЙСА
(CRUISE NUMBER)
1
2
3
4
5
6
7
8
ДАТА_ОТПЛЫТИЯ
(DEPARTURE DATE)
840407
840412
840529
840529
840603
840630
840630
840719
о рейсах пассажирских
ЧИСЛО_ПАССАЖИРОВ
(NUMBER OF PASSENGERS)
380
560
830
790
600
780
400
810
Суда, совершающие эти рейсы, перечислены во втором файле, не имеющем
нормальной формы.
НАЗВАНИЕ-СУДНА
КАСЛ КУИН
СИ ПРИНСЕС
МЭРИ РОУЗ
ВМЕСТИМОСТЬ-СУДНА
820
460
850
НОМЕРА_РЕЙСОВ
5, 6
l, 7
3, 8
первой
БРИСТОЛ БЕЛЛ
630
2, 4
Третий файл также не нормализован. В нем указаны все порты, в которые
заходит судно, выполняющее конкретный рейс.
ПОРТ (PORT)
ГИБРАЛТАР
МАРСЕЛЬ
АЛЖИР
АЛЕКСАНДРИЯ
ПАЛЕРМО
АФИНЫ
СТАМБУЛ
ПЛАТА_ЗА_СТОЯНКУ
(HARBOUR CHARGE PER DAY)
100
250
150
150
200
250
150
НОМЕРА_РЕЙСОВ
(CRUISE NUMBERS)
2,3,5,7,8
2, 3, 6
2, 3, 7
1,2,3,5,6
4,6,7,8
1,3,5,8
1, 4, 8
Приведите эти файлы к пятой нормальной форме и выберите подходящие имена
для новых файлов и их полей.
6. Фирме <Слиппери фишерз> принадлежит небольшая флотилия рыболовных
катеров. Каждый катер имеет <паспорт>, куда занесены его название, тип,
водоизмещение и дата постройки. Фирма регистрирует каждый выход на лов,
записывая название катера, имена и адреса членов команды с указанием их
должностей (капитан, боцман и т.д.), даты выхода и возвращения, а также
вес пойманной рыбы отдельно по сортам (например, трески). За время одного
рейса катер может посетить несколько банок. Фиксируется дата прихода на каждую
банку и дата отплытия, качество выловленной рыбы (отличное, хорошее, плохое).
На борту улов не взвешивается. Подыщите имена полей и файлов, в которых можно
было бы хранить всю эту информацию.
7. Фирма <Уиллоби> занимается продажей с аукциона антикварных изделий и
произведений искусства. Владельцы вещей, выставляемых на аукционах <Уиллоби>,
юридически являются продавцами. Лица, приобретающие эти вещи, именуются
покупателями. Получив от продавцов партию предметов, фирма решает, на котором из
аукционов выгоднее представить конкретный предмет. Перед проведением очередного
аукциона каждой из выставляемых на нем вещей присваивается отдельный номер лота,
играющий ту же роль, что и введенный ранее шифр товара. Две вещи, продаваемые
на различных аукционах, могут иметь одинаковые номера лотов.
В книгах <Уиллоби> делается запись о каждом аукционе. Там отмечаются дата,
место и время его проведения, а также специфика (например, выставляются картины,
написанные маслом и не ранее 1900 г.). Заносятся также сведения о каждом
продаваемом предмете: аукцион, на который он заявлен, номер лота, продавец,
отправная цена и краткое словесное описание. Продавцу разрешается выставлять
любое количество вещей, а покупатель имеет право приобретать сколько ему угодно.
Одно и то же лицо или фирма может выступать и как продавец, и как покупатель.
После аукциона служащие <Уиллоби> записывают фактическую цену, уплаченную за
проданный предмет и фиксируют данные покупателя.
Придумайте имена полей и файлов для базы данных <Уиллоби>, которая
позволит фирме усовершенствовать ее дело производство.
8. Владелец магазина граммофонных пластинок пользуется набором файлов,
содержащих те же данные, что и музыкальные файлы, описанные в разд. 2.2. Кроме
того, у него хранится информация о пластинках, которыми он торгует. Каждая
пластинка, а точнее, ее наклейка, идентифицируется отдельным номером, так что
всем копиям, отпечатанным с матрицы в разное время, присвоены одинаковые номера.
На пластинке может быть записано несколько исполнений одной и той же вещи - для
каждого из них в магазине заведена отдельная запись типа содержащихся в
музыкальном файле ИСПОЛНЕНИЯ. Когда выходит новая пластинка, регистрируется
название выпустившей ее компании (например, ЕМ1), а также адрес оптовой фирмы, у
которой магазин может приобрести эту пластинку. Не исключено, что компанияпроизводитель занимается и оптовой продажей своих пластинок. Магазин фиксирует
текущие оптовые и розничные цены на каждую пластинку, дату ее выпуска,
количество экземпляров, проданных за прошлый год и в нынешнем году, а также
число еще не распроданных пластинок.
Попробуйте подобрать имена для полей и файлов, которые могут понадобиться
владельцу магазина граммофонных пластинок для хранения нужной ему информации в
дополнение к музыкальным файлам из разд. 2.2. Не стоит особенно
сосредоточиваться на том, как Модернизировать эти исходные носители данных хотелось бы, чтобы изменения в них вносились лишь в случае явной необходимости.
9. Примерно посередине воображаемого великого океана лежит воображаемый
остров Санта Белинда. Вот уже триста лет ведется подробная летопись острова. В
летопись заносятся и данные обо всех людях, которые хоть какое-то время жили на
Санта Белинде. Записываются их имена, пол, даты рождения и смерти. Хранятся там
и имена их родителей, если известно, кто они. У некоторых отсутствуют сведения
об отце, у некоторых - о матери, а часть людей, судя по записям, - круглые
сироты. Из летописи можно узнать, когда был построен каждый дом, стоящий на
острове, а если сейчас его уже нет, то когда он был снесен, точный адрес и
подробный план этого дома, кто и когда в нем жил.
Точно так же, как и столетия назад, на Санта Белинде действуют
предприниматели, занимающиеся, в частности, ловлей рыбы, заготовкой сахарного
тростника и табака. Большинство из них делают все сами, а некоторые нанимают
работников, заключая с ними контракты разной продолжительности. Имеются
записи и о том, кто кого нанимал, на какую работу, когда начался и закончился
контракт. Собственно, круг занятий жителей Санта Белинды крайне невелик и не
меняется веками. Неудивительно поэтому, что в летописи подробно описывается
каждое дело, будь то рыбная ловля или выпечка хлеба. Все предприниматели уроженцы острова. Некоторые объединяются в кооперативы, и по записям можно
установить, кто участвовал в деле, когда вступил я когда вышел из него, каким
паем владел. Имеются краткие описания деятельности каждого частного
предпринимателя или кооператива, сообщающие, в том числе, когда было
начато дело, когда и почему прекращено.
Предлагается сформировать систему нормализованных файлов, в которых можно
было бы хранить всю эту многообразную информацию. Подыщите выразительные имена
для файлов и полей, снабдив их при необходимости соответствующими
пояснениями.
10. Фирма <Типико> отказалась от приобретения некоторых товаров у своих
поставщиков, решив самостоятельно наладить их производство. С этой целью она
организовала сеть специализированных цехов, каждый
из которых принимает
определенное участие в технологическом процессе. Каждому виду продукции,
выпускаемой <Типико>, присваивается, как обычно, свой шифр товара, под которым
он значится в файле товарных запасов. Этот же номер служит и шифром продукта. В
записи с этим шифром указывается когда была изготовлена последняя партия этого
продукта какова ее стоимость, сколько операций потребовалось.
Операцией считается законченная часть процесса производства которая
целиком выполняется силами одного цеха в соответствии с техническими
требованиями, перечисленными на отдельном чертеже. Для каждого продукта и для
каждой
операции в <Типико> заведена запись, содержащая описание операции,
ее среднюю продолжительность и номер чертежа, по которому можно отыскать
требуемый чертеж. Кроме того, указывается номер цеха, обычно производящего
данную операцию.
В запись связанную с конкретной операцией, заносятся потребные количества
расходуемых материалов, а также присвоенные им шифры товара. Расходуемыми
называют такие материалы, как например, электрический кабель, который нельзя
использовать повторно. Когда, готовясь к выполнению операции, расходуемый
материал забирают со склада, регистрируется фактически выданное количество,
соответствующий шифр товара, номер служащего, ответственного за выдачу, дата и
время выдачи, номер операции и номер наряда на проведение работ, который будет
обсуждаться ниже. Реально затраченное количество материала может не совпадать с
потребным, из-за того, например, что часть изготовленной продукции бракуется.
Каждый из цехов располагает многочисленными инструментами и
приспособлениями. При выполнении некоторых операций их все же не хватает, и цех
вынужден обращаться в центральную инструментальную за недостающими. В
<Типико> каждый тип инструмента снабжен отдельным номером и на него заведена
запись со словесным описанием. Кроме того, там отмечено, какое количество
инструментов этого типа выделено цехам и какое осталось в инструментальной.
Экземпляры инструмента конкретного типа, например гаечные ключи одного размера,
различаются по своим индивидуальным номерам. На фирме для каждого типа
инструмента имеется запись, содержащая перечень всех индивидуальных номеров.
Кроме того, указаны даты их поступления на склад.
По каждой операции в <Типико> отмечают типы и количества инструментов этих
типов, которые должны использоваться при ее выполнении. Когда инструменты
действительно берутся со склада, фиксируется индивидуальный номер каждого
экземпляра, указываются номер заказавшего их цеха и номер наряда на проведение
работ. И в этом случае потребное количество не всегда совпадает с заказанным.
Наряд на проведение работ по форме напоминает заказ на приобретение
товаров, но, в отличие от последнего, он направляется не поставщику, а в один из
цехов. Оформляется этот наряд после того, как руководство <Типико> сочтет
необходимым выпустить партию некоторого продукта. В наряд заносятся шифр
продукта, дата оформления наряда, срок, к которому должен быть выполнен заказ, а
также требуемое количество продукта.
Подберите имена полей и файлов, в которых могла бы разместиться вся эта
информация. Разработанная система файлов должна обеспечивать возможность
получения разнообразных справок в ответ на запросы, например, следующего
характера.
а. Каковы количества и шифры всех расходуемых материалов, фактически
потраченных при выполнении работ по наряду номер 6531?
б. Располагает ли фирма всеми инструментами, необходимыми для выпуска партии
продукта номер 421729?
в. Где находится (на складе или в цехе с таким-то номером) каждый инструмент
типа 321? В каких операциях и при изготовлении какой продукции он применяется?