Косарев_Экомическая информатика

Рис. 5.25. Сетевая модель данных

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

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

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

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

Перечислим свойства, присущие набору:

•набор - это поименованная совокупность связанных за­ писей;

•в каждом экземпляре набора имеется только один экземпляр владельца;

•экземпляр набора может содержать нуль, один или несколь­ ко записей-членов;

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

•экземпляр набора существует после запоминания записи-вла­ дельца;

•тип набора представляет логическую взаимосвязь «Один ко многим» между владельцем и членом набора. При этом не пред­ полагается, что экземпляры членов набора должны располагать­ ся вблизи экземпляра набора в физической памяти;

•каждому типу набора присваивается имя, что позволяет од­ ной и той же паре типов объектов участвовать в нескольких взаи­ мосвязях.

Необходимо различать тип и экземпляр набора. Но предвари­ тельно поясним различия между понятиями типа и экземпляра записи. «Студент» - это тип записи, а строка символов «Иванов Иван Иванович, комн.23» - экземпляр типа записи «Студент». Таким образом, в базе данных могут храниться один экземпляр или несколько экземпляров записи некоторого типа. Аналогич­ ное отношение существует и между типом набора и экземпляра.

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

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

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

Реляционная модель данных. В настоящее время наибольшее распространение при разработке БД получила реляционная мо­ дель данных, которая позволяет определять:

•структуры данных;

•операции по запоминанию и поиску данных;

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

Основное ее положительное отличие от иерархической и сете­ вой моделей - отсутствие связей. Взаимосвязи в реляционной мо­ дели рассматриваются как объекты и представляются следующим образом: имена (ключи) записей используются в качестве значе­ ний атрибутов других записей (на рис. 5.26 и 5.27 выделены жир­ ным шрифтом). Для того чтобы можно было установить связь между двумя БД Фирма-поставщик и Склад, пользователи этих

Рис. 5.26. Реляционная концептуальная схема информационной модели фирмы-поставщика

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

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

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

Дата поставки Количество товара

Рис. 5.27. Реляционная модель склада

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

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

Основными достоинствами реляционной модели данных яв­ ляются:

•простота и доступность;

•независимость данных;

•гибкость;

•возможность непроцедурных запросов.

При описании реляционных БД часто используется своя тер­ минология. Например, множество допустимых значений (область определения) атрибута называют доменом, запись - кортежем, а множество однотипных записей - отношением. Список имен ат­ рибутов одного отношения называется схемой отношения; каж­ дое отношение, как правило, имеет свое название (имя). От тер­ мина «отношение» (от англ. relation) происходит название реля­ ционная модель данных.

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

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

В математическом понимании отношение представляет собой подмножество декартова произведения доменов. Декартовым про­ изведением А>доменов (DvD2,Db,...,Dk), которое обозначается {D*D*D*...*Dk), называется множество всех кортежей вида

(VvV2,Vi,...,Vk) длины к, таких, что V{ принадлежит Dv V2ID2, V3 \Dv...,Vk\Dk.

Фундаментальные свойства отношений.

1.Отсутствие кортежей-дубликатов.

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

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

2. Отсутствие упорядоченности кортежей.

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

3. Отсутствие упорядоченности атрибутов.

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

4. Атомарность значений атрибутов.

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

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

Отношение R находится в нормальной форме Бойса-Кодда

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

Замечание. Легко заметить, что если в отношении имеется только один возможный ключ (являющийся первичным ключом), то это оп­ ределение становится эквивалентным определению третьей нормаль­ ной формы.

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

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

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

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

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

5.5.3. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

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