Иванов Д.Н. Введение в реляционные базы данных / Иванов Д.Н. Введение в реляционные базы данных

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

4. Нормализация - процесс, позволяющий гарантировать эффективность структуры реляционной базы данных.

2.2. Модель «сущность-связь»

Модель «сущность-связь» впервые была предложена Ченом (Chen P.) в 1976 году и в дальнейшем претерпела значительные изменения. ERмоделирование состоит из трех компонентов.

1. Сущности (Entities) - это элементы реального мира, которые могут существовать независимо. Чен определял сущность как «предмет, который можно четко идентифицировать». Все экземпляры одной сущности обладают одинаковыми признаками и правилами поведения, что и позволяет выделить данный элемент реального мира как сущность. Все сотрудники фирмы, на­ пример, обладают одинаковым набором признаков, значит можно определить сущность «Сотрудник», а все подразделения фирмы могут быть описаны сущностью «Отдел».

2. Атрибуты (Attributes) - свойство, которым обладают все экземпляры сущности. Важным понятием является ключевой атрибут - такой атрибут или несколько атрибутов, которые уникальным образом идентифицирует каждый экземпляр сущности. Для сущности «Сотрудник», например, можно определить атрибуты «Фамилия», «Имя», «Дата рождения». Но ни один из них в отдельности, ни все вместе не образуют ключевой атрибут, так как можно допустить, что в фирме могут работать однофамильцы (или полные тезки), родившиеся в один день. В таких случаях принято идентифицировать каждый экземпляр сущности уникальными значениями нового атрибута «Номер сотрудника», который будет являться ключевым.

3. Связи (Relationships) представляют взаимодействие между сущностя­ ми. Так как сотрудники работают в отделах, то между сущностями «Сотруд­ ник» и «Отдел» существует определенная связь.

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

- «Один-к-одному». Между сущностями А и В определен вид связи «один-к-одному», если конкретный экземпляр сущности А может быть связан только с одним экземпляром сущности В, а конкретный экземпляр сущности В может быть связан только с одним экземпляром сущности А. Примером может служить связь между сущностями «Отдел» и «Руководитель отдела». У одного конкретного отдела может быть только один руководитель, а с дру­ гой стороны, один сотрудник может руководить только одним отделом.

- «Многие-к-одному». Для сущностей «Отдел» и «Сотрудник» опреде­ лен вид связи «многие-к-одному» - в каждом отделе могут работать много сотрудников, а каждый сотрудник может работать только в одном отделе. Тип связи «один-ко-многим» эквивалентен связи «многие-к-одному» в зави-

20

симости от того, как рассматривать сущности - «Отдел-Сотрудник» юга «Со­ трудник-Отдел» соответственно. Схема ER-модели связи сущностей «Отдел» и «Сотрудник» может выглядеть так

Сотрудник °° -> 1 Отдел

Связь между сущностями организуются по значениям атрибутов. В сущности «Отдел» должен быть определен ключевой атрибут «Номер отде­ ла» (хотя, если название отдела фирмы должно быть уникальным, то атрибут «Названием» тоже будет ключевым). Тогда сущность «Сотрудник» обладает свойством «Номер отдела», значения которого должны быть подмножеством множества значений атрибута «Номер отдела» сущности «Отдел», что отра­ жается в схеме направлением стрелки.

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

Связи сами могут становиться сущностями. Если требуется знать, на ка­ кой должности работает сотрудник в отделе, то, оказывается, связь «Сотруд­ ник-Отдел» получает дополнительный атрибут «Должность» и сама стано­ вится сущностью, которой можно дать полное название «Назначение сотруд­ ника в отдел на должность» или короткое - «Назначение». Причем, нужно заметить, что определенная новая сущность является отражением процесса - процедуры назначения сотрудника в отдел. Таким образом, для создания свя­ зи «многие-ко-многим» требуется третья сущность-посредник, которую еще принято называть слабой сущностью. Слабая сущность не может существо­ вать независимо, а только при обязательном наличии других сущностей, с которыми связана слабая сущность. Атрибутами слабой сущности становятся ключевые атрибуты сильных сущностей, от которых зависит существование слабой сущности, причем, все эти атрибуты (либо их определенный набор) образуют составной уникальный ключ. Уникальная идентификация каждой должности сотрудника в отделе будет состоять из всех трех атрибутов - со­ трудника, отдела и должности.

Связь «Сотрудник-Отдел» можно схематично описать как:

Отдел 00 <-> 00 Сотрудник

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

Отдел 1 <- 00 Назначение °° —> 1 Сотрудник

1

1

Должность

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

Отдел 1 <- 00» Сотрудник °° -» 1 Должность

Одна из проблем ER-моделирования заключается в том, что не всегда очевидно, как следует представить в модели определенный элемент - сущно­ стью или атрибутом. «Руководитель отдела» - это независимая сущность или атрибут сущности «Отдел», так как у отдела может быть только один руково­ дитель? Руководитель отдела - это такой же сотрудник фирмы, обладающий такими же признаками, что и любой другой сотрудник. Следовательно, среди всех сотрудников можно выделить единственного руководителя для конкрет­ ного отдела, а это значит «Руководитель отдела» - это сущность с теми же атрибутами, что и у сущности «Сотрудник». Экземпляры сущности «Руково­ дитель отдела» будут подмножеством множества экземпляров сущности «Сотрудник». Для того чтобы не дублировать все значения схожих атрибу­ тов, можно у сущности «Руководитель отдела» определить атрибуты «Номер отдела» и «Номер сотрудника».

Отдел 1<-1 Руководитель отдела 1 -> 1 Сотрудник (1)

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

Отдел 1 <- 1 Руководитель отдела °° -» 1 Сотрудник (2)

Каким способом достичь построения схем (1) и (2), ведь атрибуты всех сущностей, участвующих в связи, не изменились? Все решается путем уста­ новления ключевых атрибутов, которые уникальным образом идентифици­ руют значения. В схеме (1) сущность «Руководитель отдела» содержит два независимых простых ключа для каждого атрибута «Номер отдела» и «Номер

22

сотрудника» соответственно, а в схеме (2) только один - «Номер отдела». В той и другой схемах атрибуты «Номер отдела» и «Номер сотрудника» в сущ­ ностях «Отдел» и «Сотрудник» соответственно будут являться ключевыми.

Очень важно помнить простое правило проектирования базы данных. Элементы семантического моделирования, которые были «забыты» в процес­ се проектирования, могут привести к непредсказуемым последствиям.

Оказывается, в рассматриваемом примере возможна логическая ошибка, если в семантике базы данных было сделано одно единственное упущение. Дело в том, что сотрудник не просто может являться руководителем одного или нескольких отделов, но еще и должен работать в этих отделах, т.е. быть назначенным в эти отделы на какие-либо должности. Это замечание приво­ дит к тому, что прямых связей между сущностями «Руководитель отдела» и «Сотрудник», «Руководитель отдела» и «Отдел» вообще не существует, так как это дает возможность назначить сотрудника руководителем такого отде­ ла, в котором он не работает. Корректная ER-схема (2), разрешающая со­ труднику руководить многими отделами будет выглядеть так:

Руководитель отдела

\/

1 Отдел 1 <- 00 Назначение 00— 1 Сотрудник

00

\/

1

Должность

В сущности «Руководитель отдела» определен ключевой атрибут «Но­ мер отдела». Сущность «Назначение» состоит из атрибутов «Номер сотруд­ ника», «Номер отдела» и «Номер должности», причем первые два атрибута являются составным уникальным ключом.

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

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

2,3. Нормализация

При преобразовании спроектированной концептуальной модели в кон­ цептуальную схему какой-либо реляционной СУБД нет возможности полно-

23

стью отразить все аспекты семантической модели средствами выбранной реляционной системы. Сущности преобразовываются в таблицы, атрибуты - в столбцы таблицы, ключевые атрибуты - в первичные и потенциальные ключи, а связи - в систему внешних ключей. Преобразовывается все, кроме смыслового значения данных. Вместо доменов реляционные СУБД, в основ­ ном, предлагают устанавливать необходимые ограничения на значения полей определенным набором базовых типов на некотором диапазоне. Исчезают слабые сущности - все таблицы в концептуальной схеме равноправны. Ре­ альный смысл таблиц, столбцов и связей остается только в документирован­ ном виде «на бумаге» или в обычном словесном описании в комментариях к каждому объекту концептуальной схемы реляционной системы.

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

таблицами, а атрибуты - столбцами (либо полями).

Реляционная база данных считается эффективной, если она обладает следующими свойствами:

1.Отсутствие избыточности. Избыточность возникает в случае дуб­ лирования одной и той же информации. Неэффективная реляционная база данных может содержать информацию о сотрудниках и отделах, в которых они работают, в одной таблице «Сотрудники» со столбцами «Сотрудник» и «Название отдела». Это может привести к аномалии обновления. В случае принятия решения о переименовании отдела возникает необходимость изме­ нения всех остальных соответствующих значений «Название отдела» в таб­ лице «Сотрудники». Аномалия вставки возникает в случае назначения нового сотрудника в отдел, для которого значение «Название отдела» должно быть представлено так же, как и для других сотрудников этого отдела.

2.Минимальное использование Null-значений. Использование неопреде­ ленного значения атрибута следует минимизировать и применять только в случае возможного отсутствия информации, как в примере с картинами и художниками. Наряду с избыточностью, неопределенные значения - источ­ ник проблем в реляционных базах данных, поскольку невозможно точно оп­ ределить, что они означают. Если позволить в таблице «Назначения» Nullзначения в столбце «Номер должности», то сложно будет интерпретировать смысл таких значений - сотрудник назначен в отдел, но его должность пока не определена, либо этот сотрудник не является работником этого отдела, но имеет какое-то другое отношение к отделу.

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

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

Теория нормализации построена на методе декомпозиции исходных от­ ношений с целью нормализации схем отношений. При этом каждая после­ дующая схема соответствует нормальной форме более высокого уровня и обладает лучшими свойствами, по сравнению с предыдущей схемой. Каждой нормальной форме соответствует некоторый набор ограничений. Так, напри­ мер, отношение соответствует первой нормальной форме {1НФ), если оно отвечает условию атомарности.

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

Третья нормальная форма (3НФ) отношения требует, чтобы отношение находилось в 2НФ, и не имела транзитивных зависимостей, т.е. значение любого атрибута должны не зависеть от значений другого атрибута, который не входит в состав любого потенциального ключа. Если транзитивная зави­ симость обнаружена, то следующий шаг декомпозиции предполагает удале­ ние атрибутов, образующих эту зависимость. Создается новое отношение, в которое входят удаленные атрибуты, а также атрибут, от которого они зави­ сят. Этот атрибут становится первичным ключом нового отношения и оста­ ется в исходном отношении в качестве внешнего ключа для потенциального ключа нового отношения.

Иногда возможны ситуации, когда отношение находится в 3НФ, но имеет два или более потенциальных ключа, которые являются составными и имеют общий атрибут. Тогда необходима дальнейшая нормализация путем представления отношения в нормальной форме Бойса-Кодда (НФБК). Отно­ шение находится в НФБК, если оно находится в 3НФ, и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

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

25

2.4. Этапы проектирования системы баз данных

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

1.Проектирование базы данных. Сложный процесс, который состоит из следующих стадий:

-Концептуальное моделирование, которое начинается с точной фикса­ ции требований пользователя и точного описания постановки задачи. Затем проводится семантическое моделирование, которое начинается с системного анализа и словесного описания объектов предметной области и заканчивается созданием ER-модели.

-Создание концептуальной схемы для выбранной СУБД. Для спроекти­ рованной ER-модели производится выбор программного обеспечения систе­ мы баз данных. После того как СУБД выбрана, происходит преобразование концептуальной модели в концептуальную схему СУБД. Если выбрана реля­ ционная СУБД, то необходимо провести нормализацию схемы.

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

кданным, а также разработка специальных средств администрирования сис­ темы баз данных.

3.Эксплуатация системы баз данных. Последним этапом становится ввод системы в практическую эксплуатацию.

2.5.Особенности концептуального

моделирования и нормализации

2.5.1. Намеренная денормализация данных

Предположим, в базе данных поставок фирмы необходимо отразить ин­ формацию о домашних адресах клиентов фирмы. Очевидно, самое простое решение, какое возникает сразу - выделить сущность «Клиент» с атрибутами «Фамилия» и «Адрес». Однако если внимательно изучить значения, которые может принимать атрибут «Адрес», то можно выяснить, что оно может при­ нимать набор независимых значений - «Город», «улица», «номер дома», «номер квартиры». Следовательно, значение атрибута «Адрес» не атомарно и отношение «Клиент» не соответствует даже 1НФ. Значит, чтобы добиться соответствия реляционной модели, необходимо создать отдельные столбцы в таблице «Клиент» для каждой значимой части адреса клиента. Однако нельзя отвергать и тот факт, что «Адрес» сам по себе является атрибутом сущности «Клиент», значение которого - обычная строковая информация, характери­ зующая местожительство клиента, существует домен «Адрес». Следователь­ но, можно рассматривать атрибут «Адрес» как атомарный. Возникает проти­ воречие. Какое же решение принимать в таких случаях? Все зависит от того, какова семантическая модель разрабатываемой базы данных для данной

предметной области. Если смысл значения «Адрес» не важен в рамках этой модели, либо не несет никакой особой смысловой нагрузки в процессе экс­ плуатации базы данных, то можно остановиться на варианте единственного атрибута «Адрес». Если же значение адреса становится значимым, то атрибут «Адрес» должен быть подвергнут нормализации хотя бы до 2НФ. Когда ад­ рес становится значимым? Если, например, возникнет необходимость найти клиента из Омска, то где гарантия того, что поиск подстроки «Омск» по стро­ кам атрибута «Адрес» вернет именно такого клиента, а не какого-либо другого, проживающего в другом городе на улице Омская?

Предположим, что постановка задачи требует значимости атрибута «Адрес» для определения мест проживания клиентов. Очевидно, что в одном городе могут проживать много клиентов. Больше того, в одном городе на одной улице вполне вероятно могут проживать несколько клиентов. Следо­ вательно, для формального обеспечения целостности следует привести таб­ лицу «Клиенты» хотя бы к 3НФ, а лучше к НФБК, создав дополнительные таблицы «Город», «Улица» и организовать соответствующие связи. Но боль­ шинство разработчиков намеренно оставят таблицу «Клиенты» в 2НФ, так как необходимо задумываться и о производительности системы. Ведь для того, чтобы получить обычное строковое значение адреса для простого отче­ та о клиентах необходимо будет выполнить как минимум две операции JOIN:

Клиенты JOIN Город JOIN Улица

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

Решение по денормализации данных должно соответствовать постанов­ ке задачи. Для баз данных, например, «Телефонный справочник», «Адресная книга» целостность данных атрибута «Адрес» будет первостепенной, а зна­ чит, нормализация базы данных до 3НФ необходима.

2.5.2. Проблемы и ошибки идентификации

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

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

Ошибки нормализации часто допускаются в процессе проектирования базы данных начинающими разработчиками. Самые распространенные ошибки можно обозначить на следующих примерах. Иногда нормализация отношения, например, «Сотрудник» приводит к уникальной идентификации домашнего адреса сотрудника, для чего создается отдельная таблица «Адрес» и каждый адрес получает уникальный числовой идентификатор. С точки зре­ ния теории нормализации никаких ошибок нет, таблицы «Сотрудник» и «Ад­ рес» приведены как минимум в 3НФ. Семантически такое решение можно растолковать как возможность проживания в одном городе, на одной улице, в одном доме и в одной квартире нескольких клиентов. Почему бы и нет - это может значить, что члены одной семьи являются клиентами одной и той же фирмы. Если провести оценку значений, которые будут храниться в таб­ лице «Адрес», то получим, что в действительности преобладать будет одно­ значное соответствие «клиент-адрес». Тем более, если разработчиком уста­ новлена связь «один-к-одному» между таблицами «Клиент» и «Адрес», то это значит, что в этой квартире может проживать только один клиент. Следо­ вательно, декомпозиция адреса клиента в любом случае не оправдана, кроме тех случаев, когда постановка задачи оговаривает возможность большого числа проживающих по одному адресу.

Оценка значений на стадии проектирования помогает определиться с уровнем нормализации базы данных. Так, если в произвольной таблице ис­ пользуется атрибут «День недели», то нет смысла создавать отдельную таб­ лицу, в которой придется описывать названия дней недели и давать каждому дню идентификатор. Вряд ли количество записей такой таблицы будет боль­ ше семи, а обеспечить ввод нужных значений можно средствами ограниче­ ний базового типа, например, числового. Если таблица «Студент» содержит атрибут «Год поступления», то нет необходимости идентифицировать каж­ дый год в отдельной таблице, другими словами обозначать число года дру­ гим числом - на первый взгляд очевидная нелепость, однако в проектах на­ чинающих разработчиков такая ошибка возникает постоянно.

Глава 3. Практический пример проектирования реляционной базы данных

3.1. Постановка задачи

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

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

Бюро состоит из нескольких отделов, среди которых распределяются все задачи всех этапов реализации проекта, причем одну конкретную задачу может решать только один отдел.

В каждом отделе могут работать несколько сотрудников, один из кото­ рых назначается руководителем отдела. Каждый сотрудник может работать только в одном отделе и выполнять только такие задачи, которые назначены на этот отдел. Над одной задачей могут работать несколько сотрудников од­ ного отдела.

3.2. Концептуальное моделирование

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

Выделим все предполагаемые сильные сущности, участвующие в дан­ ной предметной области.

(1)Проект

(2)Этап

(3)Задача

(4)Отдел

{5} Сотрудник

(6)Руководитель

Определим связи между сущностями.

(2)Отдел 1 <- °° Сотрудник

(3)Отдел 1 «- 1 Руководитель 1 -> 1 Сотрудник

(4)Сотрудник 00 «- 00 Задача

Проведем анализ обнаруженных связей.

A) Цепочка связей (1) намеренно не объединена со связью (2). Связи (1) отражают процесс распределения проекта на этапы, этапы на задачи, а задачи по отделам. Связь (2) говорит о том, что независимо от задач, сотрудники работают в определенных отделах.

Б) Связь (3) явно указывает на то, что только один сотрудник может яв­ ляться руководителем отдела, и один из сотрудников может выбираться как руководитель. Очевидно, что в связи «Руководитель-Сотрудник» есть ошиб­ ка, так как руководитель должен выбираться не среди всех сотрудников, только среди сотрудников отдела, т.е. среди вариантов связи (2). А это зна­ чит, что связь (2) по сути, является отражением процесса назначения сотруд­ ника в отдел, а, следовательно, сама является сущностью. Но так как между сотрудником и отделом определен вид связи «многие-к-одному», то сущ­ ность «Сотрудник» обладает свойствами слабой сущности и требует более точного обозначения как «Сотрудник_Отдела». Поэтому сущность (5) «Со­ трудник» теперь определена как «Сотрудник_Отдела», а связи (2), (3) и (4) принимают следующий вид:

(2)Отдел 1 <-00» Сотрудник_Отдела

(3)Отдел 1 <- 1 Руководитель 1 -> 1 Сотрудник__Отдела

(4)Сотрудник_Отдела 00<-00 Задача

Заметим еще, что сущность «Руководитель» (правильнее было бы обо­ значить эту сущность как «Руководитель_Отдела») также обладает свойства­ ми слабой сущности, и нет необходимости в связи между сущностями «От­ дел» и «Руководитель», как избыточной. И действительно, руководитель - это такой же сотрудник отдела, а связь между сотрудниками отдела и отде­ лами уже определена связью (2). Следовательно, связь (3) будет иметь вид:

(3)Руководитель 1 -» 1 Сотрудник_Отдела

B)Очевидно, что связь (4) так же не свободна от нарушения логической целостности. Сотруднику отдела могут быть назначены только задачи того же отдела, а не любая задача. Действуя аналогично предыдущим рассужде­ ниям можно прийти к выводу, что сущность «Задача» должна трансформиро­ ваться в сущность «Задача_Отдела» для предотвращения назначения сотруд­ нику задачи другого отдела, а связь (4) - это процесс назначения задачи со­ труднику, который можно определить как сущность «Задача_Сотрудника_Отдела». Следовательно, в связи (1) следует провести замену:

Если сотрудника, принимая на работу, сразу назначают в определенный отдел, то вряд ли при планировании этапов разработки проекта конкретную задачу сразу назначат в отдел до утверждения всех этапов проектов. Поэтому сущность «Задача» должна остаться в своем прежнем виде, как сильная сущ­ ность, т.е. независимой от другой сущности, в данном случае, от сущности «Отдел». Следовательно, связь (1) должна иметь следующий вид:

(1) Проект 1 <- 00 Этап 1 <- 00 Задача

Также нужно четко представлять, что, назначив определенную задачу в отдел, руководитель отдела вряд ли сразу же назначит эту задачу определен­ ным сотрудникам своего отдела, поэтому должны существовать сущности «Задача_Отдела» и «Задача_Сотрудника_Отдела». Причем, задачи могут на­ значаться в отдел без распределения по сотрудникам. Заметим, что сущность «Задача_Отдела» является тем самым звеном связи между проектами и отде­ лами, ранее указанным в связи (1). Итак, модификация связи (4) будет выгля­ деть как

(4)Сотрудник_Отдела 00 <-> 00 Задача_Отдела

(5)Отдел 1 - °° Задача_Отдела 1 -> 1 Задача

Сущность «Задача_Сотрудника__Отдела» является слабой сущностью, полученной в результате декомпозиции связи «многие-ко-многим» между сущностями «Сотрудник_Отдела» и «Задача_Отдеда»:

(4 5 Сотрудник_Отдела 1 <- °° Задача_Сотрудника_Отдела °° -> 1 3адача_0тдела

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

(1)Проект

(2)Этап

(3)Задача

(4)Отдел

(5)Сотрудник_Отдела

(6)Руководитедь_Отдела

(7)3адача_0тдела

{8) Задача_Сотрудника_0тдела

Между сущностями определены связи.

(1)Проект 1 «- °° Этап 1 <- 00 Задача

(2)Отдел 1 «- 00 Сотрудник_Отдела

(3)Руководитель__Отдела 1 -» 1 Сотрудник Отдела

Следующим шагом определим атрибуты всех сущностей и выделим ключевые атрибуты.

(1) Проект [ЮПроект, Название, ПланНачало,

ПланОкончание, НачалоРабот, ОкончаниеРабот)

(2)Этап [ЮЭтап, ЮПроект, Название, ПланНачало, ПланОкончание, НачалоРабот, ОкончаниеРабот)

(3)Задача [ЮЗадача, ЮЭтап, Название, НачалоРабот,

ОкончаниеРабот)

(4) Отдел [ЮОтдел, Название)

(5) Сотрудник_Отдела [ЮСотрудник, ЮОтдел, Фамилия, Имя,

Да таРождения)

(6)Руководитель__Отдела [ЮОтдел, ЮСотрудник)

(7)3адача_0тдела [ЮЗадача, ЮОтдел)

(8)Задача_Сотрудника_Отдела [ЮЗадача, ЮСотрудник

ЮОтдел)

Для организации связей между сущностями «Руководитель_Отдела» и «Сотрудник_Отдела», «Задача__Сотрудника_Отдела» и «Сотрудник__Отдела»

32

потребуется создать дополнительный составной ключ (ЮСотрудник, ЮОтдел) для сущности «Сотрудник_Отдела».

Для связи между сущностями «Задача_Сотрудника_Отдела» и «Задача^Отдела» необходим составной ключ (ЮОтдел, ЮЗадача) для сущности «Задача_Отдела».

Заметим, что вид связи меняется, если изменить ключевой атрибут. Так, например, можно разрешить сотруднику работать только над одной задачей, если изменить ключевой атрибут сущности «Задача_Сотрудника Отдела» на простой ключ (ГОСотрудника).

3.3. Преобразование ER-модели в реляционную базу данных

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

1.Для каждой сильной сущности ER-модели создается отдельная таб­ лица, а для каждого атрибута сущности создается столбец таблицы. Ключе­ вой атрибут становится первичным ключом, а дополнительные ключевые атрибуты - потенциальными ключами.

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

Взависимости от вида связи устанавливаются ключевые атрибуты таблицы.

3.Далее необходимо создать внешние ключи, обеспечивающие ссылоч­ ную целостность, по указанному типу связи в ER-модели.

В рассматриваемом примере ER-моделирование было проведено доста­ точно подробно, поэтому указанные действия очевидны. Однако при созда­ нии столбцов в таблице необходимо указывать точный тип данных и ограни­ чения на значения каждого столбца, которые есть в арсенале выбранной СУБД. Кроме того, в процессе семантического моделирования в ERдиаграмму вкладывается основная концепция проектируемой базы данных, и опускаются некоторые подробности формализации несущественных атрибу­ тов. Так, например, при детальном рассмотрении некоторых атрибутов может оказаться, что значения атрибутов могут быть многозначными. Поэтому вполне возможно возникнут новые столбцы в таблице или даже новые табли­ цы, которые в ER-модели не существует. Примером может послужить уже рассмотренная ранее детализация атрибута «Адрес» сущности «Сотрудник», если предположить, что в ER-диаграмме для домашнего адреса сотрудника был отведен один атрибут.

Вполне возможно, что в ER-схеме будет присутствовать избыточность данных, поэтому необходимо нормализировать базу данных, как минимум, до нормальной формы Бойса-Кодда.

33

ДЛЯ демонстрации работоспособности примера базы данных проектноконструкторского бюро достаточно остановиться на СУБД Access 2000 из состава пакета Microsoft Office. Преобразовав концептуальную модель в кон­ цептуальную схему СУБД Access, получим следующую схему данных.

На схеме выделены первичные ключи таблиц, кроме которых база дан­ ных содержит дополнительные потенциальные ключи:

СК1. СотрудникиОтдела (ЮСотрудника, ЮОтдела) СК2 . ЗадачиОтдела (ЮОтдела, ЮЗадачи)

Каждый ключ в базе данных должен уникально определяться по имени, поэтому обозначим каждый ключ СК1 и СК2 соответственно. Определим все внешние ключи базы данных:

FK1. Этапы (IDПроекта) -> Проекты (ЮПроекта) FK2. Задачи (IDЭтапа) -. Этапы (ЮЭтапа)

FK3 .СотрудникиОтдела (ЮОтдела) -> Отделы (ЮОтдела)

FK4 . РуководителиОтдела (ЮЮСотрудника, ЮОтдела) -> СотрудникиОтдела (ЮСотрудника, ЮОтдела)

FK5. ЗадачиОтдела (ЮОтдела) -> Отделы (ЮОтдела)

FK6.ЗадачиОтдела (ЮЗадачи) -» Задачи (ЮЗадачи)

34

FK7.ЗадачиСотрудникаОтдела(IDОтдела, IDЗадачи) -» ЗадачиОтдела (IDОтдела, IDЗадачи)

FK8 . ЗадачиСотрудникаОтдела (IDСотрудника, IDОтдела) -> СотрудникиОтдела (IDСотрудника, IDОтдела)

Отметим, что полученная схема данных отвечает нормальной форме Бойса-Кодда теории нормализации, минимизировано использование Nullзначений. Сокращение таблиц может привести к вынужденному использова­ нию Null-значений. Так, например, если сократить таблицу «Руководители­ Отдела», то в таблицу «Отделы» необходимо добавить атрибут «ЮСотрудни­ ка», который указывал бы на руководителя отдела из таблицы «Сотрудники­ Отдела». Но такой атрибут должен содержать Null-значения, так как при соз­ дании нового отдела нельзя выбрать сразу руководителя отдела, потому что в отдел еще не назначен ни один сотрудник.

Недостатки предложенной концептуальной схемы заключаются в не­ продуманном отражении планирования проектов, этапов и задач, а также сроках их выполнения. Все атрибуты «НачалоРабот» и «ОкончаниеРабот» подразумевают использование Null-значений, так как эти атрибуты опреде­ ляют даты фактического начала и завершения работы, которые могут быть не определены. Кроме того, может нарушиться целостность данных при опреде­ лении дат окончания работ над этапом проекта по плану. Реляционными ме­ тодами невозможно установить ограничение, например, на планируемую да­ ту окончанию этапа не позже планируемой даты завершения всего проекта. Такое ограничение можно установить только путем написания триггера. Дру­ гой вариант решения этой проблемы - исключить атрибуты дат планирова­ ния из таблицы «Проекты» и создать вычисляемое представление проектов, где эти даты выбираются из этапов проекта.

3.4. Примеры построения запросов

Пример 1. Найти такие отделы, которым в настоящее время не назначе­ но ни одной плановой задачи любого проекта.

Решение задачи методами реляционного исчисления:

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

На языке SQL решение задачи можно выразить следующим образом:

SELECT Название FROM Отделы AS О WHERE NOT IDOTдела IN (

SELECT IDOTдела

FROM ЗадачиОтдела AS ЗдО, Задачи AS Зд,

Этапы AS Эт

WHERE ЗдО. IDЗадачи = Зд. IDЗадачи AND Зд.IDЭтапа = Эт.IDЭтапа AND СЕГОДНЯ() > Эт.ПланНачало AND СЕГОДНЯ() < Эт.ПланОкончание

)

Пример 2. Для каждого сотрудника подсчитать количество выполнен­ ных им задач в прошлом году.

R1 := Задачи WHERE ГОД(ОкончаниеРабот) = ГОД(СЕГОДНЯ())-1

R2 := Rl JOIN ЗадачиСотрудниковОтдела

R3 := SUMMARIZE R2 BY (IDСотрудника)

ADD COUNT() AS КоличествоЗадачЗаГод

R4 := (R3 JOIN СотрудникиОтдела JOIN Отделы)

RENAME Название AS НазваниеОтдела

R5 := R4[Фамилия, Имя, НазваниеОтдела, КоличествоЗадачЗаГод]

Запрос на языке SQL:

SELECT Фамилия, Имя,

Название AS НазваниеОтдела, COUNT(*) AS КоличествоЗадачЗаГод

FROM Задачи, ЗадачиСотрудниковОтдела AS 3CO, Отделы WHERE Задачи.IDЗадачи = ЗСО. IDЗадачи AND

ЗСО. IDОтдела = Отделы. IDОтдела AND ГОД(Задачи.ОкончаниеРабот) = ГОД(СЕГОДНЯ())-1

GROUP BY Фамилия, Имя, Отделы.Название

Пример 3. Найти такие отделы, которым назначены задачи, но эти зада­ чи не выполняются, в связи с тем, что все сотрудники отдела уже загружены хотя бы одной другой задачей.

Начало решения до представления 113(IDОтдела, IDЗадачи) соответст­ вует примеру 1 для поиска всех текущих плановых задач отделов.

Если в представлении R7 взять операцию пересечения, то получим от­ делы, где есть нераспределенные задачи и свободные сотрудники, а если вы­ полнить обратное вычитание, то получим отделы без назначенных задач и со свободными сотрудниками.

Замечание. Задача решена обычными методами работы с множествами с помощью традиционных реляционных операторов, поэтому данное решение можно легко переложить на язык SQL. Эту же задачу можно решить другими способом, например, используя агрегатную функцию COUNT().

Упражнения

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

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

Вторая часть упражнений содержит темы задач, на основе которых можно построить достаточно сложные системы, оперирующие большим чис­ лом сущностей и связей. Некоторые темы упражнений для упрощения наме­ ренно разбиты на разные упражнения (например, задача «Продажа билетов» тесно связана и не может действовать отдельно от задачи «Расписание дви­ жение поездов»).

Раздел 1. Проектирование простых баз данных

1.1.Ежедневник. Расписание, планирование, группировка и классифи­ кация мероприятий, встреч.

1.2.Справочник покупателя. Торговые точки города. Адреса, специа­ лизации, время работы, выходные дни. Филиальные сети.

1.3.Телепрограмма. Программа телепередач нескольких телекомпаний на неделю по дням и часам. Жанры телепередач, анонсы программ.

1.4.Справочник филателиста. Почтовые марки. Филателисты. Кол­ лекции филателистов. Собственная коллекция. Предложения по обмену.

1.5.Справочник нумизмата. Монеты. Коллекционеры. Коллекции мо­ нет. Собственная коллекция. Предложения по обмену.

1.6.Ломбард. Заложенные товары и недвижимость. Клиенты. Продажа заложенного имущества.

1.7.Справочник селекционера. Сорт какой-либо культуры, автор, роди­ тельские сорта, урожайность, характеристики плодов, морозоустойчивость, устойчивость к вредителям и болезням. Селекционные фонды.

1.8.Справочник работника ГИБДД. Транспортные средства. Класси­ фикация средств. Владельцы. Розыск угнанных транспортных средств. Про­ хождение техосмотра.

1.9.Бюро знакомств. Потенциальные женихи и невесты. Характери­ стики. Знаки зодиака. Требования к партнеру. Состоявшиеся пары. Архив.

1.10.Справочник потребителя (служба быта). Предприятия бытового обслуживания города. Разряды, специализации, услуги. Время работы.

1.11.Магазин с одним продавцом. Товары. Классификация товаров. За­ воз товаров. Склад. Продажа товара.

1.12.Справочник начальника тюрьмы. Камеры. Заключенные. Характе­ ристики заключенных. Сроки заключения.

1.13.Справочник командира. Подчиненные военнослужащие. Форма службы, гражданские профессии. Подразделения. Командиры подразделе­ ний.

1.14.Автосалон. Выставка и продажа автомобилей. Поставщики. Кли­ енты. Заявки клиентов. Заказы поставщикам.

1.15.Справочник географа. Города (географические координаты, чис­ ленность населения). Регионы (области, провинции, штаты и т.д.). Страны (площадь, численность населения, форма государственного правления, сто­ лица), материки.

1.16.Сбербанк. Вкладчики. Вклады. Виды вкладов. Операции по вкла­ ду. Закрытие вклада. Архив.

1.17.Купи-продай. Продавцы. Товары продавцов. Объемы, партии, виды продаж, формы оплаты. Покупатели. Спрос покупателей на товары.

I.I8.Гостиница. Номера гостиницы. Класс номеров. Комфортабель­ ность. Бытовые приборы. Постояльцы.

2Е

1.19.Шеф-повар. Блюда. Рецепт приготовления. Состав продуктов блюда. Склад продуктов.

1.20.Генеалогическое дерево. Родовые кланы. Потомки (на примере ге­ неалогического дерева дома Романовых).

1.21.Терминология. Определения и термины. Ссылки на используемые

термины.

1.22.Объявления. Объявления по рубрикам. Купля, продажа, обмен, ра­ бота, услуги.

1.23.Крылатые фразы. Пословицы, поговорки, афоризмы, каламбуры. Классификация по авторам и источникам.

1.24.Справочник туриста. Туристические агентства. Туры. Предлагае­ мые услуги. Путевки.

Раздел 2. Проектирование сложных баз данных

2.1.Аэрофлот. Самолеты. Расписание. Посадочная ведомость. Клас­ сификация мест. Предварительная продажа билетов. Возврат билетов.

2.2.Автовокзал. Автобусы. Маршруты. Расписание. Посадочная ведо­ мость. Предварительная продажа билетов. Возврат билетов.

2.3.Железная дорога (расписание). Станции. Железнодорожные ветки. Поезда. Типы поездов. Расписание движения поездов по станциям. Пример: www.timetable.tsi.ru.

2.4.Железная дорога (продажа билетов). Развитие предыдущей зада­ чи «Расписание». Станции. Поезда. Состав поезда по вагонам. Классифика­ ция вагонов. Расписание. Тарифная сетка стоимости билетов. Продажа биле­ тов до пункта назначения с возможными пересадками. Предварительная про­ дажа билетов. Возврат билетов. Пример: www.express-2.ra.

2.5.База данных мирового кино. Художественные, телевизионные, мультипликационные, документальные фильмы. Название, год выпуска на экраны, цветность кинопленки. Бюджет фильмов. Жанры, студии, режиссе­ ры, съемочная группа, отзывы и оценки кинокритиков. Актеры и их роли, главные роли фильма. Премии. Пример: www.imdb.com.

2.6.Кинопрокат. Кинотеатры. Техническое обеспечение кинотеатров. Фильмы. Бюджет фильмов. Прокат фильмов. Сеансы. Посещаемость и сбор с каждого сеанса.

2.7.База данных меломана. Композиторы, группы и исполнители, ав­ торы слов. Песни, слова песен. Студии звукозаписи. Диски. Носители. Тира­ жи дисков.

2.8.База данных любителя живописи. Художники, стили. Картины ху­ дожников, жанры. Оригиналы и копии. Оценочная стоимость. Коллекции, коллекционеры и музеи. Аукционы и комиссионки. Собственная коллекция.

2.9.ВУЗ, расписание. Учебное расписание вуза. Предметы, преподава­ тели, студенческие группы. Учебный план. Аудитории, типы аудиторий. Учет пожеланий преподавателей.

39