Методическое пособие 522

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

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

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

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

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

МОДЕЛЬ ДАННЫХ – это интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации.

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

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

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

31

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

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

Цель построения модели данных заключается в представлении данных в понятном виде.

Для отображения трехуровневой архитектуры можно идентифицировать следующие три связанные модели данных:

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

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

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

Существует много моделей данных. Они подразделяются на три категории:

Объектные,

Модели данных на основе записей,

Физические модели данных.

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

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

Ниже перечислены некоторые наиболее общие типы объектных моделей данных:

Модель типа «сущность-связь», или ER –модель

Семантическая модель

Функциональная модель

Объектно-ориентированная модель.

32

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

Пример типа дерева (схемы иерархической БД): «Отдел»

Здесь запись «Отдел» является предком для записей «Начальник» и «Сотрудники», а записи «Начальник» и «Сотрудники» - потомки записи «Отдел». Между типами записи поддерживаются связи.

База данных с такой схемой могла бы выглядеть следующим образом (один экземпляр дерева):

34

Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода – сверху - вниз, слева - направо.

Манипулирование данными в иерархической модели

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

Найти указанное дерево БД (например, отдел 310);

Перейти от одного дерева к другому;

Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);

Перейти от одной записи к другой в порядке обхода иерархии;

Вставить новую запись в указанную позицию;

Удалить текущую запись.

Ограничения целостности иерархической модели

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

Заметим, что аналогичное поддержание целостности по

35

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

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

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

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

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc.,

предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.

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

Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора

36

типов записи и набора экземпляров каждого типа из заданного набора типов связи.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

Каждый экземпляр типа P является предком только в одном экземпляре L;

Каждый экземпляр C является потомком не более, чем в одном экземпляре L.

На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:

а) Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

б) Данный тип записи P может быть типом записи предка

влюбом числе типов связи.

в) Данный тип записи P может быть типом записи потомка в любом числе типов связи.

д) Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

ж) Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

з) Предок и потомок могут быть одного типа записи.

Простой пример сетевой схемы БД:

37

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

Подробно реляционная модель рассматривается далее (риздел 3.1).

39

3. МАТЕМАТИЧЕСКИЕ ОСНОВЫ ПОСТРОЕНИЯ РЕЛЯЦИОННЫХ СУБД. РЕЛЯЦИОННАЯ АЛГЕБРА И БЕЗОПАСНЫЕ ВЫРАЖЕНИЯ. РЕЛЯЦИОННЫЕ ИСЧИСЛЕНИЯ, ПОСТРОЕННЫЕ НА ДОМЕНАХ

ИКОРТЕЖАХ

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

Остановимся более подробно на реляционной модели данных.

Реляционная модель впервые была предложена Э.Ф.Коддом в 1970 году. Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД. Примерами реляционных СУБД являются СУБД Access и FoxPro фирмы

Microsoft, Paradox и Visul dBase фирмы Borland, а также R:Base фирмы Microrim.

Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица.

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

ОТНОШЕНИЕ – это плоская таблица, состоящая из столбцов и строк.

АТРИБУТ – это поименованный столбец отношения

ДОМЕН – это набор допустимых значений для одного или нескольких атрибутов.

КОРТЕЖ – это строка отношения.

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

заголовком (содержанием). Кортежи называются

40