Данные понятия соответствуют описанию графического представления иерархической модели в виде ориентированного графа (перевернутое дерево).

Каждый элемент иерархической структуры соответствует некоторому атрибуту базы данных. Каждой записи в базе данных соответствует единственный путь, ведущий от корневой вершины к оконечным атрибутам (листьям). Например путь А;В3;С4 – это запись в базе данных. Если под А; понимать атрибут – институт № (например МИРЭА), а под В3; - атрибут группа № (например ВУС – 6.99), а под С4; - атрибут студент № (например Иванов), то данная структура является описанием логической структуры базы данных студентов МИРЭА.

В базе данных может быть несколько корневых вершин.

Сетевая модель данных.


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

Реляционная модель данных.

Понятие реляционная база данных (от англ. relation – отношение) связанно, прежде всего, с именем американского специалиста по базам данных Е. Кодда.

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

каждый столбец (атрибут или домен) имеют уникальное имя;

одинаковые строки в таблице отсутствуют;

все элементы в столбце имеют одинаковый тип и формат;

порядок следования строк и столбцов – произвольный.

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


На следующем рисунке представлен пример реляционной модели, построенной на основе отношений: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ.

Поле т.е. один или несколько доменов, значение которого однозначно определяет соответствующую запись называется ключевым, или ключом. В табл. 1 и 2 ключом является поле “номер зачетной книжки”. Для того что бы связать две таблицы, надо ключ одной таблицы ввести в состав ключа другой таблицы. Например чтобы связать таблицы 2 и 3 надо в табл. 3 и 2 использовать атрибут “результат”. Если бы его не было в одной из таблиц, то его необходимо было бы ввести.

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

Инфологическая модель.

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

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

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


Пример представления информационного объекта в виде графа представлен на следующем рисунке:

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

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

Е. Коддом выделены 3 нормальные формы отношений и предложен механизм их получения.

Первая нормальная форма. Отношение находится в первой нормальной форме (1 НФ), если все его атрибуты являются неделимыми. Например, атрибут “Ф.И.О.” не находится в 1 НФ, т.к. может быть разбит на “Фамилия”, “Имя”, “Отчество”, т.е. приведен к 1 НФ.

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


Пример функциональной зависимости представлен на рисунке:

Помимо функциональной существует также понятие функционально – полной зависимости.

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

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

Пример т-осного отношения (во 2 НФ) – это отношение студент = ( , фамилия, имя, отчество, дата, группа) – которое также находится и в 1 НФ.

Отношение успеваемость = (номер , фамилия, имя, отчество, дисциплина , оценка) находится в 1 НФ и имеет составной ключ номер + дисциплина . Но это отношение не находится во 2 НФ, т.к. атрибуты фамилия, имя, отчество, не находятся в полной функциональной зависимости от составного ключа отношения (иными словами фамилия, имя, отчество функционально зависят от части составного ключа – атрибута номер и это функционально полную зависимость).

Понятие третьей нормальной формы основывается на понятии транзитивной и не транзитивной зависимости.

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

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

Примером транзитивной зависимости для отношения “Студент” может служить атрибут “Староста”, который определяется номером “группы”.

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

Для устранения транзитивной зависимости необходимо произвести “расщепление” исходного информационного объекта. В результате расщепления часть атрибутов удаляется из исходного информационного объекта – см. рис.


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

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

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

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

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


©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-02

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

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

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

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

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии – подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.

Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т.д. (пример – каталоги ЭВМ).

Сетевая модель

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

Реляционная модель

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

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

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

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

3.5 Построение реляционной субд

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

    позволяют обрабатывать очень большие объемы данных;

    информационные массивы можно без труда трансформировать, связывать, представляя их в виде еди­ной таблицы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядром любой базы данных является модель данных. Модель данных - это совокупность структур данных и операций их обработки.

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

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

Иерархическая древовидная структура модели БД

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

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

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



Реляционная модель была разработана в начале 70-х годов ХХ в. Коддом. Простота и гибкость этой модели привлекли к ней внимание разработчиков, и уже 80-х годах ХХ в. она получила широкое распространение. Таким образом, реляционные СУБд оказались промышленным стандартом.

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

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

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

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

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

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

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

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

В приведенном примере отношение СОТРУДНИК ссылается на отношение ОТДЕЛ через название отдела.

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

НАЗВАНИЕ ТАБЛИЦЫ (Поле 1, Поле 2, ..., Поле п).

Например, для таблиц, показанных на рисунке, имеем следующие схемы (курсивом выделены первичные ключи):

СОТРУДНИК (Номер пропуска, ФИО, Должность, Название отдела, Телефон);

ОТДЕЛ (Название отдела, Расположение отдела, Назначение отдела).

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

Доминирование реляционной модели в современных СУБД определяется:

наличием развитой теории (реляционной алгебры);

наличием аппарата сведения других моделей данных к реляционной модели;

наличием специальных средств ускоренного доступа к информации;

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

ТИПЫ ВЗАИМОСВЯЗЕЙ В МОДЕЛИ

На практике часто используются связи, устанавливающие различные виды соответствия между объектами «связанных» типов, - это один к одному (1:1), один ко многим (1:М), многие ко многим (М: М).

Связь один к одному означает, что каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В) и, наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А).

Связь один ко многим означает, что каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может соответствовать только один экземпляр первого объекта (А).

Связь многие ко многим означает, что каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и, наоборот, каждому экземпляру второго объекта (В) могут соответствовать тоже несколько экземпляров первого объекта (А).

Пример. Рассмотрим совокупность следующих информационных объектов:

СТУДЕНТ (Номер студента, ФИО, Дата рождения, Номер группы);

СТИПЕНДИЯ (Номер студента, Размер стипендии);

ГРУППА (Номер группы, Специальность);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Должность).

Здесь информационные объекты СТУДЕНТ и СТИПЕНДИЯ связаны отношением один к одному, так как каждый студент может иметь только одну стипендию и каждая стипендия может быть назначена только одному студенту.

Информационные объекты ГРУППА и СТУДЕНТ связаны отношением один ко многим, так как одна группа может включать в себя много студентов, в то время как каждый студент может обучаться только в одной группе.

Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ связаны отношением многие ко многим, так как один студент может обучаться у многих преподавателей и один преподаватель может обучать многих студентов.

Лекция №2.

«Информационная модель данных, её состав и три типа логических моделей».

План.
1. Информационная модель данных, ее состав:
- концептуальная,
- логическая
- физическая модели

- иерархическая,
- сетевая,
- реляционная.
3. Типы взаимосвязей в модели: «один к одному», «один ко многим», «многие ко мно-гим»

1. Информационная модель данных, ее состав.

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

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

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

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

В против¬ном случае связь является факультативной (необязательной).
Обязательная связь «ЗАМЕЩАЕТ» существует, например, меж¬ду двумя объектами СО-ТРУДНИК и ДОЛЖНОСТЬ в предметной области кадровой информационной системы.

Каждый принимае¬мый в организацию сотрудник зачисляется на какую-либо долж¬ность и не может быть сотрудника, не замещающего какой-либо должности.
В то же время связь «ЗАМЕЩАЕТСЯ» между типами объектов СОТРУДНИК и ДОЛЖ-НОСТЬ является факультативной, поскольку могут существовать вакантные должности.

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

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

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

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

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

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

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

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

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

Указанный недостаток снят в сетевой модели, где, по крайней мере, теоретически возмож-ны связи «всех информационных объек¬тов со всеми».

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

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

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

Реляционная модель (от англ, relation - отношение) была разра¬ботана в начале 70-х го-дов Коддом. Простота и гибкость модели привлекли к ней внимание разработчиков.
В 80-х годах она получи¬ла широкое распространение, и реляционные СУБД оказались про¬мышленным стандартом.

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

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

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

Логически среди строк не существует «первой» и «последней».

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

Этот столбец или их совокуп¬ность и называется первичным ключом таблицы (рис. 1.4).
Таблица 1. СОТРУДНИК
Название таблицы
№ пропуска
Фамилия
Должность
Название отдела Y
Телефон

\
Первичный ключ таблицы 1
Внешний ключ таблицы 1
Таблица 2. ОТДЕЛ
Название таблицы
Название отдела
Расположение отдела
Назначение отдела

Первичный ключ таблицы 2
Рис. 1.4. Организация ссылки от одной таблицы к другой

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

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

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

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

В приведенном примере на рис. 1.4 отношение «СОТРУДНИК» ссылается на отношение «ОТДЕЛ» через название отдела.

Схема реляционной таблицы (отношения)
представляет собой со¬вокупность имен полей, образующих запись таблицы:
НАЗВАНИЕ ТАБЛИЦЫ (Поле 1, Поле 2, ..., Поле N).

Например, для таблиц на рис. 1.4 имеем следующие схемы таблиц:

СОТРУДНИК (№ пропуска, Фамилия. Должность, Название отдела, Телефон);
ОТДЕЛ (Название отдела, Расположение отдела, Назначение отдела).

Курсивом в схемах таблиц показаны первичные ключи.

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

Доминирование реляционной модели в современных СУБД оп¬ределяется:
1) наличием развитой теории (реляционной алгебры);
2) наличием аппарата сведения других моделей данных к реля¬ционной модели;
3) наличием специальных средств ускоренного доступа к ин¬формации;
4) наличием стандартизированного высокоуровневого языка за¬просов к БД, позволяющего манипулировать ими без знания кон¬кретной физической организации БД во внешней па-мяти.

3. Типы взаимосвязей в модели:
«один к одному», «один ко многим», «многие ко многим»

На практике часто используются связи, устанавливающие раз¬личные виды соответствия между объектами «связанных» типов, - «один к одному» (1:1), «один ко многим» (1:М), «многие ко мно¬гим» (М:М).

Связь «один к одному» означает, что каждому экземпляру пер¬вого объекта (А) соответст-вует только один экземпляр второго объ¬екта (В) и наоборот, каждому экземпляру второго объекта (В) соот¬ветствует только один экземпляр первого объекта (А).

Связь «один ко многим» характеризуется тем, что каждому эк¬земпляру одного объекта (А) может соответствовать несколько эк¬земпляров другого объекта (В), а каждому экземпляру второго объ¬екта (В) может соответствовать только один экземпляр первого объ¬екта (А).
Связь «многие ко многим» означает, что каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземп-ляру второго объек¬та (В) могут соответствовать тоже несколько экземпляров первого объ-екта (А).
Пример 1.1. Рассмотрим совокупность следующих информаци¬онных объектов:

СТУДЕНТ (Номер студента, Фамилия И.О., Дата рождения. Номер группы);
СТИПЕНДИЯ (Номер студента. Размер стипендии);
ГРУППА (Номер группы, Специальность);
ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И.О., Должность).

Информационные объекты СТУДЕНТ и СТИПЕНДИЯ связаны отношением «один к од-ному», так как каждый студент может иметь только одну стипендию, и каждая стипендия может быть назначена только одному студенту.
Информационные объекты ГРУППА и СТУДЕНТ связаны от¬ношением «один ко многим», так как одна группа может включать много студентов, и в то же время каждый студент может обучаться только в одной группе.
Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ связаны отношением «многие ко многим», так как один студент мо¬жет обучаться у многих преподавателей, и один пре-подаватель мо¬жет обучать многих студентов.

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

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

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


Рис. 1.8.

Общие принципы классификации СУБД

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

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

Так, СУБД CDS / ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE - для БД смешанного типа. Во избежание несуразностей с использованием определенной модели данных, БД, за редким исключением, целесообразно классифицировать по типу используемой модели в СУБД. Отметим, что классификация БД далеко не завершенная область исследований: попытки ввести новые типы БД продолжаются (активные, дедуктивные, нечеткие реляционные, графические БД и т.д.).

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

Существуют различные концептуальные подходы к обработке транзакций при распределенной обработке. Принципиальным здесь является не только вопрос как, но и где локализуется обработка транзакции : на файлах компьютера конечного пользователя или на выделенном в сети компьютере. От выбора той или иной концепции будет зависеть время отклика системы на запрос пользователя. Параметр "время отклика системы на запрос пользователя" очень часто выступает в качестве определяющего или желательного параметра разрабатываемой системы. Например, для распределенной системы бронирования авиабилетов для крупнейших мировых авиакомпаний этот параметр является существенным и закладывается в проектное решение как не превышающий 30-45 секунд.