Базы данных. Учебное пособие

ГЛАВА 2. МОДЕЛИ ДАННЫХ

Основная цель создания баз данных заключается в том,

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

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

архитектура большинства современных СУБД в той или иной степени строится на базе так называемой архитектуры ANSI/SPARC. Рассмотрим ее подробно.

2.1.Трехуровневая архитектура ANSI/SPARC

В1975 году была признана необходимость использова- ния трехуровневого подхода при построении модели данных, предложенного комитетом ANSI/SPARC. Хотя модель ANSI/SPARC не стала стандартом, тем не менее она пред- ставляет собой основу для понимания некоторых функцио- нальных особенностей СУБД.

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

1)внешний;

2)логический;

3)внутренний.

Цель трехуровневой архитектуры заключается в отде-

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

Уровень, на котором воспринимают данные пользова- тели, называется внешним уровнем, тогда как СУБД и опера- ционная система воспринимают данные на внутреннем уров-

21

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

Внешний уровень. Формируется инфологическая модель

Логический уровень

Формируется даталогическая модель

Диск Внутренний (физический) уровень

Рис. 2.1. Трехуровневая архитектура ANSI-SPARC

Внешний уровень.

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

22

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

Логический уровень.

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

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

Внутренний уровень.

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

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

23

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

2.2. Инфологическая модель данных "Сущностьсвязь"

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

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

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

žграфовые модели;

žсемантические сети;

žмодель "сущность-связь" и т. д.

24

Наиболее популярной из них оказалась модель "сущ- ность-связь".

Модель "сущность-связь" (Entity-Relationship model, ER model) является высокоуровневой моделью, в которой данные представлены в виде сущностей, атрибутов и свя- зей. Она ограничивает представление данных, но не специ- фицирует его. Особое внимание в ней уделяется связям, так

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

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

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

Сущность – любой различимый объект (объект, кото- рый мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т. д. Необходимо различать такие понятия, как тип сущности и экземпляр сущ- ности. Понятие тип сущности относится к набору однород- ных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Барселона и т. д.

Атрибут – поименованная характеристика сущности.

Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: КОШКА, АВТОМОБИЛЬ, ОБОИ и т. д.). Атрибуты используются для определения того, какая инфор- мация должна быть собрана о сущности. Примерами атрибу- тов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т. д. Здесь также существует

25

различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Ба- нановый, Белая ночь и т. д., однако каждому экземпляру сущ- ности присваивается только одно значение атрибута.

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

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

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

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

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

2.3. ER-диаграммы

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

26

полужирным шрифтом. Связи между ними – ненаправленны- ми ребрами, над которыми может проставляться степень свя- зи (1 или символ, заменяющий слово "много") и необходимое пояснение.

Одиночная ортогональная к основной линия справа оз- начает "один", "птичья лапка" слева - "многие", а отношение читается вдоль линии, например "многие к одному "(рис. 2.2, 2.3). Вертикальная черта означает "обязательно", кружок - "не обязательно", например, для каждого издания в TITLE обяза- тельно должен быть указан издатель в PUBLISHERS, а один издатель в PUBLISHERS может выпускать несколько наиме- нований изданий в TITLES

Рис. 2.2. Элемент ER-диаграммы

Владелец

Арендатор Недвижимость

.

Рис 2.3. Пример ER- диаграммы

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

27

2.3.2.Подтипы

Вэтом случае атрибут ВЛАДЕЛЕЦ сущности СЧЕТ имеет особое значение для данной сущности - сущность де- лится на типы по категориям: "для физического лица" и "для юридического лица". Полученные в результате сущности на- зывают подтипами, а исходная сущность становится суперти- пом. Чтобы понять, нужен супертип или нет, надо установить, сколько одинаковых свойств имеют различные подтипы. Изо- бражают их так, как показано на рис. 2.6.

Подтип 1

Супертип

Подтип 2

Рис. 2.6. Подтипы (слева) и супертип (справа)

Следует отметить, что злоупотребление подтипами и супер- типами является довольно распространенной ошибкой.

2.3.3. Ассоциации

К. Дейт определяет три основные класса сущностей:

стержневые, ассоциативные и характеристические.

Стержневая сущность (стержень) – это независимая сущность на диаграммах определяется как прямоугольник. Это, например, ДОГОВОР, АРЕНДАТОР и т.д., названия ко- торых в рассмотренных выше примерах помещены в прямо- угольники.

Ассоциация (ассоциативная сущность) – это связь вида

"многие-ко-многим" между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности:

üони могут участвовать в других ассоциациях и обозна- чениях точно так же, как стержневые сущности;

29

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

Обозначение ассоциаций на схеме – ромб или шести- угольник. Характер связей между сущностями не ограничива-

Консультант Рис. 2.7. Несколько связей между двумя сущностями

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

Итак, инфологическая модель, построенная на этапе предпроектных исследований, полностью независима от па- раметров среды хранения данных.

Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "по- нятную" СУБД.

2.4.Даталогические модели данных

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

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

30