О Иерархическая модель данных. Иерархически организованные данные встречаются в повседневной жизни очень часто. Например, структура высшего учебного заведения — это многоуровневая иерархическая структура. Иерархическая (древовидная) БД состоит из упорядоченного набора элементов. В этой модели исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы. Каждый порожденный элемент имеет только один порождающий элемент/
Организационные структуры, списки материалов, оглавление в книгах, планы проектов и многие другие совокупности данных могут быть представлены в иерархическом виде. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.
Основным недостатком данной модели является необходимость использования той иерархии, которая была заложена в основу БД при проектировании. Потребность в постоянной реорганизации данных (а часто невозможность этой реорганизации) привели к созданию более общей модели — сетевой.
О Сетевая модель данных. Сетевой подход к организации данных является расширением иерархического подхода. Данная модель отличается от иерархической тем, что каждый порожденный элемент может иметь более одного порождающего элемента.
Рассмотрим предметную область для базы данных, в которой хранится информация о заказах магазина. Заказчики берут напрокат фильмы, используя два носителя: видеоленту и компакт-диски. Обслуживание заказчиков выполняют продавцы. Каждый продавец обслуживает многих заказчиков. Каждый продавец может пользоваться услугами нескольких магазинов и наоборот. Существует много копий одного и того же фильма и т. д.
Поскольку сетевая БД может представлять непосредственно все виды связей, присущих данным соответствующей организации, по этим данным можно перемещаться, исследовать и запрашивать их всевозможными способами, то есть сетевая модель не связана всего лишь одной иерархией. Однако для того чтобы составить запрос к сетевой БД, необходимо достаточно глубоко вникнуть в ее структуру (иметь под рукой схему этой БД) и выработать механизм навигации по базе данных, что является существенным недостатком этой модели БД.
О Реляционная модель данных. Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерной таблицы. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но чаще всего эта модель описывает структуру и взаимоотношения между несколькими различными таблицами.
Итак, целью информационной системы является обработка данных об объектах реального мира, с учетом связей между объектами. В теории БД данные часто называют атрибутами, а объекты — сущностями. Объект, атрибут и связь — фундаментальные понятия ИС.
Объект (или сущность) — это нечто существующее и различимое, то есть объектом можно назвать то «нечто», для которого существуют название и способ отличать один подобный объект от другого. Например, каждая школа — это объект. Объектами являются также человек, класс в школе, фирма, сплав, химическое соединение и т. д. Объектами могут быть не только материальные предметы, но и более абстрактные понятия, отражающие реальный мир. Например, события, регионы, произведения искусства; книги (не как полиграфическая продукция, а как произведения), театральные постановки, кинофильмы; правовые нормы, философские теории и проч.
Атрибут (или данное) — это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах. Например, возьмем в качестве набора объектов классы в школе. Число учеников в классе — это данное, которое принимает числовое значение (у одного класса 28, у другого — 32). Название класса — это данное, принимающее текстовое значение (у одного — 10А, у другого — 9Б и т. д.).
Атрибут некоторого набора объектов сам может быть набором объектов, имеющих собственные атрибуты. Например, атрибутом лица (как экземпляра набора объектов «Лица») является вуз, который это лицо окончило (МГУ, МИФИ и т. п.). С другой стороны, конкретный вуз — это экземпляр набора объектов «Вузы» и характеризуется множеством данных: фамилией ректора, адресом, специализацией, числом студентов и т. д. Наконец, ректор в свою очередь является экземпляром набора объектов «Лица». Таким образом, возникает возможность установления связи между экземплярами объектов из разных наборов.
Развитие реляционных баз данных началось в конце 60-х годов, когда появились первые работы, в которых обсуждались возможности использования при проектировании баз данных привычных и естественных способов представления данных — так называемых табличных даталогических моделей.
Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 июня 1970 г. статью A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных», что и положило начало реляционным базам данных.
Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую Основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.
Э. Кодд, будучи математиком по образованию, предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида, известных в математике как «отношения».
Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами.
Таблица состоит из столбцов (полей) и строк (записей); имеет имя, уникаль
ное внутри базы данных. Таблица отражает тип объекта реального мира (сущ
ность), а каждая ее строка— конкретный объект. Так, таблица Спортивная
секция содержит сведения обо всех детях, занимающихся в данной спортивной
секции, а ее строки представляют собой набор значений атрибутов каждого кон
кретного ребенка. Каждый столбец таблицы — это совокупность значений конк
ретного атрибута объекта. Столбец Вес, например, представляет собой
совокупность всех весовых категорий детей, занимающихся в секции. В столбце
Пол могут содержаться только два различных значения: «муж.» и «жен.». Эти значения выбираются из множества всех возможных значений атрибута объекта, которое называется доменом (domain). Так, значения в столбце выбираются из множества всех возможных весов детей.
В самом общем виде домен определяется заданием некоторого базового' типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементам данных. Если при вычислении логического условия относительно элемента данных в результате получено значение «истина», то этот элемент принадлежит домену. В простейшем случае домен определяется как допустимое потенциальное множество значений одного типа. Например, совокупность дат рождения всех сотрудников составляет «домен дат рождения», а имена всех сотрудников составляют «домен имен сотрудников». Домен дат рождения имеет тип данных, позволяющий хранить информацию о моментах времени, а домен имен сотрудников должен иметь символьный тип данных.
В один домен могут входить значения из нескольких столбцов, объединенных, помимо одинакового типа данных, еще и логически. Например, домен может состоять из столбца с датой пйступления на работу и столбца с датой увольнения. Но в этот домен нельзя включить столбец с датой рождения, так как дата поступления или увольнения с работы не связана с датой рождения.
Если два значения берутся из одного и того же домена, т,о можно выполнять сравнение этих двух значений. Например, если два значения взяты из .домена дат рождения, то можно сравнить их и определить, кто из сотрудников старше. Если же значения берутся из разных доменов, то их сравнение не допускается,
так как, по всей вероятности, оно не имеет смысла. Например, из сравнения имени и даты рождения сотрудника ничего определенного не выйдет.
В большинстве систем управления реляционными базами данных понятие домена не реализовано.Каждый элемент данных в отношении может быть определен с указанием его адреса в формате A[i , j], где А — элемент данных, i — строка отношений, j — номер атрибута отношения.
Количество атрибутов в отношении определяет его порядок (или степень). Порядок отношения, приведенного в табл., равен 4.
| ID сотрудника | Имя сотрудника | № паспорта | Дата рождения |
| 12576893 | Мамаев Евгений | 357934 ХИ-БА | 13.08.78 |
| 56387934 | Шкарина Лилия | 463865 XIV-БА | 07.10.72 |
| 85973002 | Салихов Тимур | 653473 Х1И-БА | 17.12.80 |
| 24856892 | Волков Иван | 395789 XVII-БА | 05.05.79 |
| 76578243 | Мамаев Сергей | 312642 XVII-БА | 21.09.80 |
Множество значений А [ i , j ] при постоянном i и всех возможных j образуют кортеж (или попросту строку таблицы). Количество всех кортежей в отношении определяет его мощность, или кардинальное число. Мощность отношения в табл. 2.2 равна 5. Мощность отношения, в отличие от порядка отношения, может со временем меняться. Совокупность всех кортежей образует тело отношения (или собственно таблицу).