«В.И. Кокова БАЗЫ ДАННЫХ Рекомендовано Сибирским региональным учебно-методическим центром высшего профессионального образования для межвузовского использования в качестве учебного пособия для студентов, обучающихся по ...»

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

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

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

Такой подход обеспечивает решение трех важных задач:

• уменьшение нагрузки на сеть;

• уменьшение требований к компьютерам-клиентам;

• повышение надежности и сохранение логической целостности базы данных.

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

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

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

Распределенные БД не получили большого распространения.

2.2. Классификация баз данных по модели данных По модели данных БД классифицируются следующим образом:

• файловая модель;

• иерархическая модель;

• сетевая модель;

• реляционная модель.

Файловая модель представляет собой совокупность не связанных между собой файлов (независимых) из однотипных записей с линейной (одноуровневой) структурой.

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

В иерархической модели отношения между данными бывают типа «родители – потомки». У каждого объекта может быть только один родитель, хотя потомков может быть несколько. У корневого объекта нет родителя. Такие отношения принято изображать в виде дерева, где ребро между объектами отображает наличие некоторого отношения, причем название отношения пишется на ребре.

Например, между объектами «клиенты» и «заказы» может быть отношение, которое называют «делает».

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

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

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

и называется реляционной моделью. Он предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение).

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

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

Реляционная модель — это модель, основанная на следующих принципах:

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

Английский термин relation (отношение), по сути, представляет собой принятое математическое название для таблицы. Поэтому на практике термины отношение и таблица в большинстве случаев можно считать синонимами.

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

В настоящее время наиболее популярны именно реляционные модели, поэтому реляционным моделям посвящена отдельная глава

ГЛАВА 3. ОСНОВНЫЕ ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ

ДАННЫХ

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

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

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

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

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

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

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

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

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

На стадии физического проектирования строятся компьютеро-ориентированные модели: даталогическая модель данных и физическая модель данных. Эти модели должны быть описаны на языке описания данных конкретной СУБД, поэтому необходимо выбрать СУБД. На этом этапе конструируются таблицы базы данных, создаются связи между таблицами, то есть разработка продолжается средствами СУБД.

Описание, создаваемое по инфологической модели данных, называют даталогической моделью данных.

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

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

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

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

Критерии выбора технических средств определяются требованиями к информационной системе в целом. Разработчики информационных систем (ИС) дают как минимальный, так и оптимальный вариант, а также вариант, ориентированный на развитие.

ГЛАВА 4. ИНФОРМАЦИОННО – ЛОГИЧЕСКОЕ И

ДАТАЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ

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

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

Сущность – любой различимый объект (объект, который можно отличить от другого), информацию о котором необходимо хранить в базе данных. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Абакан, Саяногорск и т.д.

Атрибут – поименованная характеристика сущности.

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

Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: АВТОМОБИЛЬ, ИЗДЕЛИЕ, ТКАНЬ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: красный, синий, белый и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

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

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

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

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

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

4.2. Характеристика связей и язык ER-диаграмм информационно-логических или инфологических моделей (ИЛМ).

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, содержащими имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа.

Ассоциации изображаются помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово «много») и необходимое пояснение. Другими словами, в ERдиаграммах связь - это линия, соединяющая геометрические фигуры, изображающие сущности, атрибуты, ассоциации и другие информационные объекты. В тексте же этот термин используется для указания на взаимозависимость сущностей. Если эта взаимозависимость имеет атрибуты, то она называется ассоциацией.

Возможно и другое изображение связей. В месте «стыковки»

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

Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.

В ER-диаграммах характеристики изображаются в виде трапеции, а обозначение – в виде параллелограмма.

На рис. 4.1 изображены элементы расширенного языка ERдиаграмм.

Рис. 4.1. Элементы расширенного языка ER-диаграмм Между двумя сущностями, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В. Студент может не получать стипендию, получать обычную или одну из повышенных стипендий. На рис. 4.2 изображены фрагменты ERдиаграмм, иллюстрирующие связь ОДИН-К-ОДНОМУ.

Рис. 4.2. Фрагменты ER-диаграмм, иллюстрирующие связь ОДИНК-ОДНОМУ Другими словами, связь ОДИН-К-ОДНОМУ означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице. В качестве примера можно рассмотреть связь между списком служащих предприятия и таблицей, содержащей их служебные характеристики.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В. Квартира может пустовать, в ней может жить один или несколько жильцов. На рис. 4.3 изображены фрагменты ER-диаграмм, иллюстрирующие связь ОДИН-КОМНОГИМ.

Рис. 4.3. Фрагменты ER-диаграмм, иллюстрирующие связь ОДИНКО-МНОГИМ Это наиболее часто встречающийся тип связи. В качестве примеров могут быть рассмотрены связи между покупателем и купленными им товарами, между предприятием и работающими на нем сотрудниками.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи: МНОГО-КОДНОМУ (М:1) и МНОГО-КО-МНОГИМ (М:N).

Третий тип - связь МНОГО-К-ОДНОМУ можно сравнить со связью ОДИН-КО-МНОГИМ, рассматриваемое с другой точки зрения. Например, между клиентами и сделанными ими заказами существует связь ОДИН-КО-МНОГИМ. С другой стороны, если в качестве исходной точки рассматривать заказы, то между сделанными заказами и клиентами получается связь МНОГО-КОДНОМУ.

Четвертый тип - связь МНОГО-КО-МНОГИМ (M:N): в качестве примера можно рассмотреть магазин оптовой торговли.

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

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

На рис. 4.4 изображен фрагмент ER-диаграммы, иллюстрирующий связь МНОГО-КО-МНОГИМ.

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

Рис. 4.5. Инфологическая модель базы данных «Питание»

На рис. 4.6 изображен пример связи между сущностями БИЛЕТ и ПАССАЖИР с использованием трехточечного входа.

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

БИЛЕТ ПАССАЖИР

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

На рис. 4.7 изображен пример инфологической модели, построенной вышеописанным способом.

Рис. 4.7. Инфологическая модель базы данных «Питание»

4.3. Язык инфологического моделирования Язык ER-диаграмм обычно используется для построения небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2,..., атрибут n) АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2,...], где S1, S2 – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.

Например, отдел записей актов гражданского состояния (ЗАГС) имеет дело с теми людьми, которые обратились с просьбой о регистрации брака. Данный пример может быть описан на ЯИМ следующим образом:

Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа, Отчество_мужа, Дата_рождения_мужа, Фамилия_жены, Дата_регистрации, Место_регистрации,...) Рассмотрим случай, когда какой-либо организации потребовались данные о наличии в ней семейных пар, а для хранения сведений о сотрудниках уже имеется сущность Сотрудники (Табельный_номер, Фамилия, Имя,...).

Использование в рассмотренном примере сущности «Брак»

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

Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2,...)

ХАРАКТЕРИЗУЕМЫХ

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

...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

К. Дж. Дейт определяет три основные класса сущностей:

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

Стержневая сущность (стержень) – это независимая сущность.

В рассмотренных ранее примерах стержни – это «Студент», «Квартира», «Врач» и другие, названия которых помещены в прямоугольники.

Ассоциативная сущность (ассоциация) – это связь вида МНОГО-КО-МНОГИМ между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности: они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности, могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

Характеристическая сущность (характеристика) – это связь вида МНОГО-К-ОДНОМУ или ОДИН-К-ОДНОМУ между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности.

Обозначающая сущность или обозначение – это связь вида МНОГО-К-ОДНОМУ или ОДИН-К-ОДНОМУ между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

Рассмотрим пример, связанный с зачислением сотрудников в различные отделы предприятия.

При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией «Зачисление»:

Отделы (Номер отдела, Название отдела,...) Служащие (Табельный номер, Фамилия,...) Зачисление [Отделы M, Служащие N] Дата зачисления).

Однако, при условии, что каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением «Служащие»:

Отделы (Номер отдела, Название отдела,...) Служащие (Табельный номер, Фамилия,..., Номер отдела, Дата зачисления)[Отделы] В данном примере служащие имеют независимое существование (если удаляется отдел, то из этого не следует, что также должны быть удалены служащие этого отдела). Поэтому они не могут быть характеристиками отделов и названы обозначениями.

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

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

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

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

Сетевые модели также создавались для малоресурсных ЭВМ.

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

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

Сегодня наиболее распространены реляционные модели.

Инфологическая модель адекватно преобразуется в даталогическую модель.

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

1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы.

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

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

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

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

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

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

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

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

ГЛАВА 5. РЕЛЯЦИОННАЯ АЛГЕБРА И РЕЛЯЦИОННЫЕ

БАЗЫ ДАННЫХ

структурной части, манипуляционной части и целостной части.

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

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

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

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

В состав теоретико-множественных операций входят операции:

• объединения отношений;

• пересечения отношений;

• взятия разности отношений;

• прямого произведения отношений.

Специальные реляционные операции включают:

• ограничение отношения;

• проекцию отношения;

• соединение отношений;

• деление отношений.

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

представляют собой два альтернативных подхода. Принципиальное различие между ними следующее. Реляционная алгебра в явном виде предоставляет набор операций (соединение, объединение, проекция и т.д.), которые можно использовать, чтобы сообщить системе, как в базе данных из определенных отношений построить некоторое требуемое отношение, а реляционное исчисление просто представляет систему обозначений для определения требуемого отношения в терминах данных отношений. В реляционном исчислении просто описывается, в чем заключается проблема, тогда как в реляционной алгебре задается процедура решения этой проблемы[1].

5.2. Общая интерпретация реляционных операций Почти все операции предложенного выше набора обладают очевидной и простой интерпретацией:

1. При выполнении операции объединения двух отношений производится отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов.

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

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

4. При выполнении прямого произведения двух отношений производится отношение, кортежи которого являются конкатенацией (сцеплением) кортежей первого и второго операндов.

5. Результатом ограничения отношения по некоторому условию является отношение, включающее кортежи отношенияоперанда, удовлетворяющее этому условию.

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

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

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

9. Операция переименования производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены.

10. Операция присваивания позволяет сохранить результат вычисления реляционного выражения в существующем отношении БД.

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

5.3. Базовые понятия реляционных баз данных Как уже говорилось, реляционные модели данных отличаются от сетевых и иерархических моделей простотой структур данных, удобным для пользователя табличным представлением и доступом к данным. Реляционная модель данных является совокупностью простейших двумерных таблиц. Эти таблицы получили название реляций или отношений.

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

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

На рис. 5.1 показан пример отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторого предприятия.

Рис. 5.1. Пример отношения СОТРУДНИКИ Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных, а также данных типа дата.

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропусков» и «Номера отделов» относятся к типу целых чисел, но не являются сравнимыми.

Заметим, что в большинстве реляционных СУБД понятие домена не используется.

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.

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

Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4х-арным. Если все атрибуты одного отношения определены на разных доменах, лучше использовать для именования атрибутов имена соответствующих доменов. Это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута.

Схема БД (в структурном смысле) - это набор именованных схем отношений.

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Иначе говоря, кортеж - это набор именованных значений заданного типа.

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

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

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

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Имя схемы отношения в реляционных базах данных всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.

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

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

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

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

То есть для массового пользователя реляционных БД можно использовать неформальные эквиваленты этих понятий:

• отношение – таблица;

• кортеж – строка (или запись);

атрибут – столбец (или поле).

При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

Этой терминологии придерживаются в большинстве реляционных СУБД, в том числе и в Visual FoxPro, который будет рассмотрен в главе 11.

Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.

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

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

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

Например, предположим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника).

При правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ - ОТД_НОМЕР) и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ - СОТР_НОМЕР).

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМЕР в некотором кортеже отношения ОТДЕЛЫ.

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

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

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

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

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

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

ГЛАВА 6. НОРМАЛИЗАЦИЯ

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

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

Цели нормализации:

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

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

В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:

• первая нормальная форма (1NF);

• вторая нормальная форма (2NF);

• третья нормальная форма (3NF);

• нормальная форма Бойса-Кодда (BCNF) (правильнее было бы считать эту нормальную форму третьей, однако по историческим причинам третья ступень оказалась занятой к моменту изобретения BCNF, из-за чего она и получила нестандартное название);

• четвертая нормальная форма (4NF);

• пятая нормальная форма, или нормальная форма проекциисоединения (5NF).

Основные свойства нормальных форм:

• каждая следующая нормальная форма в некотором смысле лучше предыдущей;

• при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

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

Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е.

таблицы, содержащие повторяющиеся группы, не допускаются в реляционной БД.

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

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

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

6.2. Функциональные зависимости Пусть R является отношением, а X и Y – произвольными подмножествами множества атрибутов отношения R. Тогда Y функционально зависимо от X, что в символическом виде записывается как X Y.

Функциональная зависимость. В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными атрибутами) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y, что в символическом виде можно записать как {R.X} {R.Y}. Читается это как «X функционально определяет Y» или как «X стрелка Y».

Левую и правую части символической записи иногда называют детерминантом и зависимой частью соответственно. Если детерминант или зависимая часть содержит только один атрибут, они называются одноэлементными и фигурные скобки в символической записи можно опустить. Иначе говоря, если два кортежа совпадают по значению X, они также совпадают и по значению Y.

Проще говоря, поле Y таблицы функционально зависит от поля X той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля X обязательно существует только одно из различных значений поля Полная функциональная зависимость. Функциональная зависимость {R.X} {R.Y} называется полной, если атрибут Y не зависит функционально от любого точного подмножества X (точным подмножеством множества X называется любое его подмножество, не совпадающее с X).

Иначе говоря, поле Y находится в полной функциональной зависимости от составного поля X, если оно функционально зависит от X и не зависит функционально от любого подмножества поля X.

Транзитивная (производная) функциональная зависимость.

Функциональная зависимость R.X R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X R.Z и R.Z R.Y Иными словами, транзитивная зависимость определяется следующим образом: если атрибут Z зависит от атрибута X и атрибут Y зависит от атрибута Z, то, следовательно, атрибут Y зависит от атрибута X.

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

Взаимно независимые атрибуты. Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

Детерминант. Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.

Многозначная зависимость. В отношении R (X, Y, Z) существует многозначная зависимость R.X R.Y (читается как «X многозначно определяет Y» или «X двойная стрелка Y») в том и только в том случае, если множество значений Y, соответствующее паре значений X и Z, зависит только от X, но не зависит от Z.

Другими словами, в отношении R (X, Y, Z) существует многозначная зависимость R.X R.Y в том и только в том случае, когда существует многозначная зависимость R.X R.Z.

Таким образом, многозначные зависимости всегда образуют связанные пары, поэтому обычно их представляют вместе в символическом виде: X Y Z.

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

Для иллюстрации многозначных зависимостей рассмотрим табл. 6.1.

Базы данных Иванова И.А. К. Дж. Дейт. Введение в Базы данных Иванова И.А. В.В.Евдокимов.

Базы данных Петров В.П. К. Дж. Дейт. Введение в Базы данных Петров В.П. В.В.Евдокимов.

В ней есть многозначная зависимость «ДисциплинаПреподаватель»: дисциплина может читаться несколькими преподавателями. Есть и другая многозначная зависимость «Дисциплина-Учебник»: при изучении дисциплины Базы данных используются учебники «Введение в системы баз данных» и «Экономическая информатика». При этом Преподаватель и Учебник не связаны функциональной зависимостью, что приводит к появлению избыточности (для добавления еще одного учебника придется ввести в таблицу две новых строки). Дело улучшается при замене этой таблицы двумя: («Дисциплина-Преподаватель» и «Дисциплина-Учебник»).

Теорема Фейгина. Отношение R (X, Y, Z) можно спроецировать без потерь в отношения R1 (X, Y) и R2 (X, Z) в том и только в том случае, когда существует многозначная зависимость R.X R.Y (это равнозначно существованию двух многозначных зависимостей R.X R.Y и R.X R.Z ).

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

Зависимость соединения. Отношение R (X, Y,..., Z) удовлетворяет зависимости соединения * (X, Y,..., Z) (читается «звездочка X, Y,..., Z») в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y,..., Z.

Зависимость соединения является обобщением как многозначной зависимости, так и функциональной зависимости.

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

В теории реляционных баз данных обычно выделяют шесть нормальных форм.

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

Отношение не должно содержать повторяющиеся группы данных.

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

Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.

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

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится во 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

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

Нормальная форма Бойса-Кодда. Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.

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

Четвертая нормальная форма. Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A B все остальные атрибуты R также функционально зависят от атрибута A.

Пятая нормальная форма. Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

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

Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF встречается чрезвычайно редко.

Нормализация – это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5NF. На практике же достаточно привести таблицы к нормальной форме Бойса-Кодда.

Эта процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K F, где K – первичный ключ, а F – некоторое другое поле. Заметим, что это следует из определения первичного ключа таблицы, в соответствии с которым K F всегда имеет место для всех полей данной таблицы. «Один факт в одном месте»

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

Цель нормализации состоит именно в том, чтобы избавиться от всех функциональных зависимостей, которые имеют иной вид, чем K F.

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

Допустим, таблица имеет первичный (возможный) ключ К, не являющееся возможным ключом поле F1, которое функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. В этом случае рекомендуется сформировать другую таблицу, содержащую F1 и F2, с первичным ключом F1, а F удалить из первоначальной таблицы:

Заменить T(K,F1,F2), первичный ключ К Для любой заданной таблицы, повторяя применение двух рассмотренных правил, почти во всех практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в «окончательной» нормальной форме и, таким образом, не содержат каких-либо функциональных зависимостей вида, отличного от K F.

ГЛАВА 7. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ

ДАННЫХ

Имеется отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ с информацией о номере сотрудника, его зарплате, номере отдела, номере проекта и о заданиях, выполняемых сотрудниками.

Допустим, что заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).

СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР,

СОТР_НОМЕР, ПРО_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР СОТР_ЗАРП

СОТР_НОМЕР ОТД_НОМЕР

ОТД_НОМЕР СОТР_ЗАРП

СОТР_НОМЕР, ПРО_НОМЕР СОТР_ЗАДАН

Можно произвести следующую декомпозицию отношения

СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ-ОТДЕЛЫ СОТР_ЗАРП,

СОТР_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР СОТР_ЗАРП

СОТР_НОМЕР ОТД_НОМЕР

ОТД_НОМЕР СОТР_ЗАРП

СОТР_НОМЕР, ПРО_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР CОТР_ЗАДАН

Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР СОТР_ЗАРП является транзитивной; она является следствием функциональных зависимостей СОТР_НОМЕР ОТД_НОМЕР и ОТД_НОМЕР СОТР_ЗАРП.

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

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

Чтобы согласованным образом изменить заработную плату отдела, требуется предварительно найти все кортежи, описывающие сотрудников этого отдела. Другими словами, в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.

Произведем декомпозицию отношения СОТРУДНИКИОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР) Определим первичный ключ:

СОТР_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР ОТД_НОМЕР

ОТД_НОМЕР Выявим все функциональные зависимости:

ОТД_НОМЕР СОТР_ЗАРП

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

Рассмотрим следующий пример: имеется отношение СОТРУДНИКИ-ПРОЕКТЫ с информацией о номере сотрудника, его фамилии, номере проекта и о заданиях, выполняемых сотрудниками. Предположим, что личность сотрудника полностью определяется как его номером, так и фамилией (это не очень жизненное предположение, так как возможны однофамильцы, но достаточное для примера).

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР,

СОТР_НОМЕР, ПРО_НОМЕР СОТР_ ФАМИЛИЯ, ПРО_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР CОТР_ ФАМИЛИЯ

СОТР_НОМЕР ПРО_НОМЕР

СОТР_ ФАМИЛИЯ CОТР_НОМЕР

СОТР_ ФАМИЛИЯ ПРО_НОМЕР

СОТР_НОМЕР, ПРО_НОМЕР CОТР_ЗАДАН

СОТР_ ФАМИЛИЯ, ПРО_НОМЕР CОТР_ЗАДАН

Можно произвести декомпозицию СОТРУДНИКИПРОЕКТЫ в два отношения СОТРУДНИКИ и СОТРУДНИКИПРОЕКТЫ:

СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ ФАМИЛИЯ) Определим возможные ключи:

СОТР_НОМЕР

СОТР_ ФАМИЛИЯ

СОТР_НОМЕР CОТР_ ФАМИЛИЯ

СОТР_ ФАМИЛИЯ СОТР_НОМЕР

СОТР_НОМЕР, ПРО_НОМЕР Выявим все функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР CОТР_ЗАДАН

Рассмотрим следующий пример: отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусмотренных проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.

ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН) Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта (предположим, что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). Получается, что единственным возможным ключом отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает следующим недостатком: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено, так как любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом.

В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:

ПРО_НОМЕР ПРО_СОТР

ПРО_НОМЕР ПРО_ЗАДАН

В данном примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:

ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР) ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН) Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.

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

Рассмотрим, например, отношение

СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР,

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

Введем следующие имена составных атрибутов:

СО = {СОТР_НОМЕР, ОТД_НОМЕР} СП = {СОТР_НОМЕР, ПРО_НОМЕР} ОП = {ОТД_НОМЕР, ПРО_НОМЕР} Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫПРОЕКТЫ существует зависимость соединения:

* (СО, СП, ОП) Произведем декомпозицию исходного отношения в три новых отношения:

СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР) СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР) ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР) Данные отношения находятся в 5NF, так как в каждой ее полной декомпозиции все проекции содержат возможный ключ.

Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции.

7.2. Проектирование реляционной базы данных без построения информационно-логической модели Рассмотрим пример проектирования реляционной базы данных без построения ИЛМ, основанный на здравом смысле.

Руководство корпорации определило требования, которым должна отвечать БД, чтобы успешно удовлетворять нуждам компании.

БД должна содержать как минимум следующую информацию:

• фамилию и. о., должность, специальность, номер в расчетной ведомости служащего;

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

Условие нахождения базы данных в первой нормальной форме:

• таблица не должна иметь повторяющихся записей;

• в таблице должны отсутствовать повторяющиеся группы Полученное отношение показано в табл. 7.1.

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

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

Например, поле Номер в расчетной ведомости однозначно определяет поля: Фамилия И.О., Код специальности, Должность.

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

Еще два зависимых поля: Номер проекта и Дата окончания.

Поле Номер проекта однозначно определяет поле Дата окончания.

Следовательно, поле Дата окончания функционально зависит от ключевого поля Номер проекта, которое должно иметь уникальные значения. Полученное отношение показано в табл. 7.3.

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

Полученное отношение показано в табл. 7.4.

Третья нормальная форма требует удаления транзитивных (производных) зависимостей.

Транзитивная зависимость определяется следующим образом: если атрибут Z зависит от атрибута X и атрибут Y зависит от атрибута Z, то, следовательно, атрибут Y зависит от атрибута X.

О таблице говорят, что она находится в третьей нормальной форме, если:

• она удовлетворяет условиям второй нормальной формы;

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

Предположим, что каждый Код специальности имеет только одну связанную с ним Должность (это предположение не совсем жизненное, но достаточное для примера). Поле Должность условно зависит от поля Номер в расчетной ведомости. Если поле Должность зависит от поля Номер в расчетной ведомости и поле Код специальности зависит от поля Должность, то, следовательно, поле Код специальности зависит от поля Номер в расчетной ведомости.

Удалим поле Должность из табл. 7.2 и создадим новую табл.

7.5, содержащую два поля: Код специальности и Должность, и табл. 7.6, содержащую поля: Номер в расчетной ведомости, Фамилия И.О. и Код специальности.

Спроектирована реляционная база данных, состоящая из четырех таблиц: табл. 7.3, 7.4, 7.5, 7.6.

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

Например, на рис. 7.1 показана схема данных, созданная в Visual FoxPro.

Рис. 7.1. Окно конструктора базы данных в Visual FoxPro

ГЛАВА 8. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Системы управления базами данных – это прикладные информационные системы для управления и обработки структурированной информации.

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

Между собственно физической базой данных (т.е. данными, которые реально хранятся) и пользователями системы располагается уровень программного обеспечения, который можно называть СУБД. Все запросы пользователей на доступ к базе данных обрабатываются СУБД.

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

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

Термин СУБД также часто используется в отношении конкретных программных продуктов конкретных изготовителей, например, СУБД Visual FoxPro или СУБД Microsoft Access[1].