Модели баз данных

Содержание Введение 1. Иерархическая модель данных 1. Структура данных 2. Операции над данными, определенные в иерархической модели 3. Ограничения целостности 2. Сетевая модель данных 1. Структура данных 2. Операции над данными 3. Ограничения целостности 3. Реляционная модель данных 11 3. 1.

Структура данных 2. Свойства отношений 15 Заключение 16 Список использованной литературы 17 Введение Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. Модель данных — совокупность структур данных и операций их обработки.

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

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

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

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

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

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

две дочерние записи). Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры : заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК(НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. (b)). Рис. 1

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

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

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

корневых записей извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева) В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 1 тысячи руб.) Как видим, все операции изменения применяются только к одной "текущей" записи (которая предварительно извлечена из базы данных). Такой подход к манипулированию данных получил название "навигационного".

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

Ч.Бахман. Основные принципы сетевой модели данных были разработны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.). Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между между записью-владельцем и записью-членом также имеет вид 1:N.

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

При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного. Иерархическая структура преобразовывается в сетевую следующим образом (рис. 2): • древья (a) и (b), показанные на рис. 3.1, заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения; • для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей

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

них может быть назначен свой способ упорядочивания. - режим включения подчиненных записей: • автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем; • ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем). - режим исключения Принято выделять три класса членства подчиненных записей в групповых отношениях:

Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи-владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.

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

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

выполнением каких-либо договорных обязательств перед заказчиками. 2. 2. Операции над данными. ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение. ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельцем.

ПЕРЕКЛЮЧИТЬ - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении. ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи. ИЗВЛЕЧЬ - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора. УДАЛИТЬ - убрать из БД запись. Если эта запись является владельцем группового отношения, то анализируется

класс членства подчиненных записей. Обязательные члены должны быть предварительно исключены из группового отношения, фиксированные удалены вместе с владельцем, необязательные останутся в БД. ИСКЛЮЧИТЬ ИЗ ГРУППОВОГО ОТНОШЕНИЯ - разорвать связь между записью-владельцем и записью-членом. 2. 3. Ограничения целостности. Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения). 3.

Реляционная модель данных Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД. 3. 1. Структура данных. В реляционной модели достигается гораздо более высокий уровень абстракции

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

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

Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2) Отношение: Отношением R, определенным на множествах называется подмножество декартова произведения . При этом: o множества называются доменами отношения o элементы декартова произведения называются кортежами o число n определяет степень отношения ( n=1 - унарное, n=2 - бинарное, n-арное) o количество кортежей

называется мощностью отношения Пример: на множестве С из предыдущего примера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2) Отношения удобно представлять в виде таблиц. На рис. 3 представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам.

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

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

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

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

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

Рассмотренный в параграфах 1 и 2 пример базы данных, содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид: Рис.4 База данных о подразделениях и сотрудниках предприятия. Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер отдела" из первого отношения во второе.

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

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

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

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

и вырезать из нее требуемые строки и столбцы (селекция и проекция). Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели,

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

в базе данных; • высокая трудоемкость манипулирования информацией и изменения связей. Список использованной литературы. 1. Бойко В.В Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика,1999. 2. Конноллн, Томас, Бегг, Карелии. Базы данных. Проектирование, реализация и сопровождение.

Теория и практика. 3-е издание.: Пер. с англ. – М.: Издательский дом "Вильяме", 2003. – 1440 с. 3. Котеров Д. В. Самоучитель РНР 4. – СПб.: БХВ-Петербург, 2003. – 576 с. 4. Кренке Д. Теория и практика построения баз данных. 9-е изд. – СПб.: Питер, 2005 – 859c. 5. Макаров А.

С Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник – М.: Финансы и статистика, 2004 – 512 с.