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

 

 

 

3.Сущность и характеристика  моделей данных (иерархическая, сетевая и реляционная)

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

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

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

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

 

Это одна из наиболее ранних моделей данных. Типовая сетевая модель данных была предложена рабочей группой по базам данных (Data Base Task Group – DBTG) системного комитета CODASYL (Conference of Data System Languages), основными функциями которого были анализ известных фирменных систем обработки управленческих данных с единых позиций и в единой терминологии, обобщение опыта организации таких систем и разработка рекомендаций по созданию соответствующих систем.

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

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

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

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

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

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

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

1. Групповые отношения  являются отношениями соподчиненности.

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

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

− имеется единственная особая вершина (соответствующая группе), называемая корнем, в которую не заходит ни одно ребро (группа не имеет предков);

− во все остальные вершины входит только одно ребро (все остальные группы имеют одного предка), а исходит произвольное количество ребер (группы имеют произвольное количество потомков);

− отсутствуют циклы.

3. Иерархическая модель  данных может представлять совокупность

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

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

Рисунок 2. Иерархическая модель данных

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

СУБД, поддерживающие иерархическую модель, достаточно широко использовались на вычислительных системах IBM 360/370 (ЕС ЭВМ). В качестве примеров таких систем можно указать IMS, OKA и широко тиражируемую в СССР отечественную разработку ИНЕС.

Примером иерархической СУБД для персональных ЭВМ является отечественная система НИКА (адаптация системы ИНЕС к IBM PC).

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

Учитывая недостатки сетевых и иерархических моделей, можно сформулировать желательные требования к модели данных:

 модель должна быть  понятна пользователю, не имеющему  особых

навыков в программировании;

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

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

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

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

Групповое отношение может представляться двумя способами.

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

При втором способе групповое отношение определяется как дополнительная группа (дополнительная таблица). Столбцами этой дополнительной таблицы являются ключи групп – членов отношения. Таким

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

Для формального описания таблицы используется теоретико-множественное понятие отношения. Список названий столбцов таблицы (имен полей записи, соответствующих атрибутам) именуют схемой отношения и обозначают R (A1, A2, …, An).

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

 

Рисунок 3. Реляционная модель данных

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

Необходимо отметить, что большинство СУБД для персональных ЭВМ поддерживают именно реляционную модель данных. В качестве примеров таких наиболее распространенных СУБД можно указать все dBase-подобные системы, DB2, Paradox, Access, FoxPro, Oracle, MS SQL Server.

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы 

Кузнецов, С.Д. Базы данных. Модели и языки / С.Д. Кузнецов М.: ООО «Бином-Пресс», 2008. – 720 с.

 Голицына  О.Л., Основы проектирования баз  данных. – М.: Форум, 2012. – 416 с.

3///Илюшечкин В.М.. Основы использования и проектирования баз данных. – М.: Юрайт, Юрайт, 2011. – 224 с.

Кириллов, В.В. Г.Ю. Громов  Г.Ю.. Введение в реляционные базы данных (+ CD-ROM). – СПб.: БХВ-Петербург, 2009. – 464 с.

Дунаев В.. Базы данных. Язык SQL для студента. – СПб.: БХВ-Петербург, 2012. – 320 с.

 Кузовкин, А.В. Цыганов, А.А. Щукин. Б.А. Управление  данными. – М.: Академия, 2010. – 256 с.

Лацис. А.О. Параллельная обработка данных. – М.: Академия, 2010. – 336 с.