Операции над базой данных

Стандартным способом доступа к данным базы является вход по ассоци­ативному адресу {образцу), осуществляемый операцией "поиск по образ­цу". Аргумент операции "поиск по образцу" представляет собой структу­ру, характер которой может меняться в достаточно широком диапазоне в зависимости от функций, выполняемых базой данных. Результатом этой операции является множество (возможно, пустое - негативный резуль­тат) всех референтов образца-аргумента, т.е. фрагментов базы данных, каждый из которых представляет собой ответ на запрос, специфициро­ванный в форме этого образца.

Можно выделить несколько типов образцов.

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

Точное совпадение - референты изоморфны образцу с точностью до отсутствующих элементов в образце;

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

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

< положительный образец, отрицательный образец >,

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

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

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

Будем делить операцию "поиск по образцу" на два основных вида: одновариантный и многовариантный поиск.

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

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

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

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

Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.

Реляционная база данных

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

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

Таблица PRODUCTS

ID NAME COMPANY PRICE
123 Печеньки ООО ”Темная сторона” 190
156 Чай ООО ”Темная сторона” 60
235 Ананасы ОАО ”Фрукты” 100
623 Томаты ООО ”Овощи” 130

Таблица состоит из 4х строк, строка в таблице является кортежем в реляционной теории. Множество упорядоченных кортежей называется отношением.
Перед тем как дать определение отношения, введем еще один термин - домен. Домены применительно к таблице это столбцы.

Для ясности, теперь введем строгое определение отношения.

Пусть даны N множеств D1,D2, …. Dn (домены), отношением R над этими множествами называется множество упорядоченных N-кортежей вида , где d1 принадлежит D1 и тд. Множества D1,D2,..Dn называются доменами отношения R.
Каждый элемент кортежа представляет собой значение одного из атрибутов, соответствующего одному из доменов.

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

Таблица DRIVERS

Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.

В реляционной БД таблицы взаимосвязаны и соотносятся друг с другом как главные и подчиненные. Связь главной и подчиненнной таблицы осуществляется через первичный ключ (primary key) главной таблицы и внешний ключ (foreign key) подчиненной таблицы.
Внешний ключ это атрибут или набор атрибутов, который в главной таблице является первичным ключем.

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

Операции реляционной алгебры

Основные восемь операций реляционной алгебры были предложены Э.Коддом .
  • Объединение
  • Пересечение
  • Вычитание
  • Декартово произведение
  • Выборка
  • Проекция
  • Соединение
  • Деление
Первая половина операций аналогична таким же операциям над множествами. Часть операций можно выразить через другие операции. Рассмотрим большую часть операций с примерами.

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

Таблица SELLERS

ID SELLER
123 OOO “Дарт”
156 ОАО ”Ведро”
235 ЗАО “Овоще База”
623 ОАО ”Фирма”

Условимся, что в этой таблице ID это внешний ключ, связанный с первичным ключом таблицы PRODUCTS.

Для начала рассмотрим самую простую операцию - имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.

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

Синтаксис операции:
π (ID, PRICE) PRODUCTS

В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:

σ (PRICE>90 ^ ID<300) PRODUCTS

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

Получим декартово произведения таблиц PRODUCTS и SELLERS.
Синтаксис операции:

PRODUCTS × SELLERS
Можно заметить, что у двух этих таблиц есть одинаковый домен ID. В подобной ситуации домены с одинаковыми названиями получают префикс в виде названия соответствующего отношения, как показано ниже.
Для краткости перемножим не полные отношения, а выборки с условием ID<235

(цветом выделены одни и те же кортежи)

PRODUCTS.ID NAME COMPANY PRICE SELLERS.ID SELLER
123 Печеньки ООО ”Темная сторона” 190 123 OOO “Дарт”
156 Чай ООО ”Темная сторона” 60 156 ОАО ”Ведро”
123 Печеньки ООО ”Темная сторона” 190 156 ОАО ”Ведро”
156 Чай ООО ”Темная сторона” 60 123 OOO “Дарт”

Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:

π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS

В результате этой операции получим отношение:

SELLER
ОАО ”Ведро”
Соединение и естественное соединение
Операция соединения обратна операции проекции и создает новое отношение из двух уже существующих. Новое отношение получается конкатенацией кортежей первого и второго отношений, при этом конкатенации подвергаются отношения, в которых совпадают значения заданных атрибутов. В частности, если соединить отношения PRODUCTS и SELLERS, этими атрибутами будут атрибуты доменов ID.

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

Попробуем соединить отношения PRODUCTS и SELLERS и получим отношение.

PRODUCTS.ID NAME COMPANY PRICE SELLERS.ID SELLER
123 Печеньки ООО ”Темная сторона” 190 123 OOO “Дарт”
156 Чай ООО ”Темная сторона” 60 156 ОАО ”Ведро”
235 Ананасы ОАО ”Фрукты” 100 235 ЗАО “Овоще База”
623 Томаты ООО ”Овощи” 130 623 ОАО ”Фирма”

Натуральное соединение получает схожее отношение, но в случае, если у нас корректно настроена схема в базе (в данном случае первичный ключ таблицы PRODUCTS ID связан с внешним ключем таблицы SELLERS ID), то в результирующем отношении остается один домен ID.

Синтаксис операции:
PRODUCTS ⋈ SELLERS;

Получится такое отношение:

PRODUCTS.ID NAME COMPANY PRICE SELLER
123 Печеньки ООО ”Темная сторона” 190 OOO “Дарт”
156 Чай ООО ”Темная сторона” 60 ОАО ”Ведро”
235 Ананасы ОАО ”Фрукты” 100 ЗАО “Овоще База”
623 Томаты ООО ”Овощи” 130 ОАО ”Фирма”
Пересечение и вычитание.
Результатом операции пересечения будет отношение, состоящее из кортежей, полностью входящих в состав обоих отношений.
Результатом вычитания будет отношение, состоящее из кортежей, которые являются кортежами первого отношения и не являются кортежами второго отношения.
Данные операции аналогичны таким же операциям над множествам, так что, я думаю, нет необходимости подробно их расписывать.
Источники информации
  • Основы использования и проектирования баз данных - В. М. Илюшечкин
  • курс лекций Introduction to Databases - Jennifer Widom, Stanford University

Буду благодарен за аргументированные замечания

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

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

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

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

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

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

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

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

Объектно-реляционные СУБД

Разница между объектно-реляционными и объектными СУБД : первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных (как и объектных) СУБД от реляционных заключается в том, что ОРСУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java .

Объектно-реляционными СУБД являются, например, широко известные Oracle Database , Microsoft SQL Server , PostgreSQL, Microsoft Access.

Реляционный подход к построению модели предметной области.

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

· между таблицами существуют связи;

· каждый элемент таблицы - один элемент данных;

· все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

· каждый столбец описывает один атрибут сущности;

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

· строка содержит значения атрибутов для одного экземпляра сущности;

· одинаковые строки в таблице отсутствуют (наличие первичного ключа);

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

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

Первая нормальная форма

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

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

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

· таблица должна содержать данные об одном типе объектов;

· каждая таблица должна содержать одно поле или несколько полей, образующих уникальный идентификатор (или первичный ключ) для каждой строки;

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

Третья нормальная форма

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

Типы связей. Свойства отношений

· Отношение "один-к-одному" (1:1) означает, что каждая запись в одной таблице соответствует не более чем одной записи в другой таблице.

· Отношение "один-ко-многим" (1:М) означает, что каждой записи в одной таблице соответствует 0 или 1 или несколько записей в другой таблице.

· Отношение "многие-к-одному" (М:1) аналогично рассмотренному ранее типу "один-ко-многим". Тип отношения между объектами зависит от точки зрения.

· Отношение "многие-ко-многим" (М:М). возникает между двумя таблицами тогда, когда каждой записи в одной таблице соответствует 0 или более записей в другой таблице и наоборот.

Простые и составные ключи

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

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

Такой первичный ключ называют составным ключом

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

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

Связь "многие-ко-многим " реализуется через дополнительную таблицу, с помощью которой эта связь будет сведена к двум связям типа "один-ко-многим ".


Введение. 4

1. Базы данных и СУБД 6

2. Реляционные базы данных 20

3. Операции над таблицами реляционных баз данных 29

4. Разработка инфологических моделей 49

5. Организация доступа к данным 64

6. Принципы построения систем, ориентированных на анализ данных 96

Заключение. 106

Список наиболее часто встречающихся сокращений. 107

Введение.

Литературы на русском языке, посвященной тематике СУБД, очень мало. Невозможно порекомендовать одну или несколько книг, содержание которых покрывало бы материал курса «Базы данных». К числу лучших относятся книги К. Дейта "Введение в системы баз данных" (Наука, 1980) и "Руководство по реляционной СУБД DB2" (Финансы и статистика, 1988), а также книга Дж. Ульмана "Основы систем баз данных" (Финансы и статистика, 1983). Хотя эти книги несколько устарели (на английском языке вышло уже несколько дополненных изданий), их стоит читать.

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


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

    2. реляционные базы данных (основные понятия реляционных баз данных, тип данных, домен, схема отношения, схема базы данных, кортеж, отношение, целостность реляционных баз данных, основные свойства отношений реляционных баз данных);

    3. операции над таблицами реляционных баз данных (операции теории множеств, нормализация отношений реляционных баз данных);

    4. использование языка ER-диаграмм для построения инфологических моделей (диаграммы "сущность-связь", информационное моделирование, методология IDEF1X, этапы разработки инфологической модели данных);

    5. организация доступа к данным (средства ускоренного доступа к данным, язык запросов, обработка транзакций, средства восстановления после сбоев);

    6. принципы построения систем, ориентированных на анализ данных (хранилища данных; модели данных, используемые при построении хранилищ данных).
Учебное пособие предназначено для студентов всех специальностей и форм обучения.

1. Базы данных и СУБД

1.1. Данные и ЭВМ

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

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

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


Интерпретация

Номер рейса

Дни недели

Пункт отправления

Время вылета

Пункт назначения

Время прибытия

Тип самолета

Стоимость билета

Данные

138
2_4_7
Баку
21.12
Москва
0.52
ИЛ-86
115.00

57
3_6
Ереван
7.20
Киев
9.25
ТУ-154
92.00

1234
2_6
Казань
22.40
Баку
23.50
ТУ-134
73.50

242
1 по 7
Киев
14.10
Москва
16.15
ТУ-154
57.00

86
2_3_5
Минск
10.50
Сочи
13.06
ИЛ-86
78.50

137
1_3_6
Москва
15.17
Баку
18.44
ИЛ-86
115.00

241
1 по 7
Москва
9.05
Киев
11.05
ТУ-154
57.00

577
1_3_5
Рига
21.53
Таллин
22.57
АН-24
21.50

78
3_6
Сочи
18.25

Баку
20.12
ТУ-134
44.00

578
2_4_6
Таллин
6.30
Рига
7.37
АН-24
21.50

Рис. 1.1.1. Данные и их интерпретация.

Применение ЭВМ для ведения (сопровождения, поддержки) и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло?

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

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных " (СУБД). СУБД – программное обеспечение, осуществляющее создание баз данных, поддержание ее в рабочем состоянии и обеспечение эффективного доступа к данным базы для пользователей и для приложений. Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных " (БД). Таким образом, База данных (БД)– отражение предметной области в форме структурированной совокупности данных. Хранящиеся в ней данные характеризуют состав объектов предметной области, их свойства и взаимосвязи.

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:


  • физическом размещении в памяти данных и их описаний;

  • механизмах поиска запрашиваемых данных;

  • проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

  • способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

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

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

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

Рис. 1.2.1. Уровни моделей данных

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

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

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

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

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

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

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

  • ограничения на длину имен объектов базы данных (таблиц, столбцов, индексов),

  • использование специальных символов в именах,

  • допустимые типы данных и их внутреннее представление на устройствах хранения данных в ЭВМ.
Одной и той же инфологической модели данных могут соответствовать несколько разных физических моделей.

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

Связь между записью-владельцем и записью-членом также имеет вид 1:N.

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

  • деревья (a) и (b), показанные на рис. 4.2 , заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;
  • для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, (см. рис. 4.3). Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту.


Рис. 4.3.

Каждый экземпляр группового отношения характеризуется следующими признаками:

Способ упорядочения подчиненных записей:

  • произвольный,
  • хронологический /очередь/,
  • обратный хронологический /стек/,
  • сортированный.

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

Режим включения подчиненных записей:

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

Режим исключения.

Принято выделять три класса членства подчиненных записей в групповых отношениях:

  • Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи -владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.
  • Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.
  • Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи -владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Операции над данными в сетевой модели БД

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

Ограничения целостности

Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Достоинства и недостатки ранних СУБД

Достоинства ранних СУБД:

  • развитые средства управления данными во внешней памяти на низком уровне;
  • возможность построения вручную эффективных прикладных систем;
  • возможность экономии памяти за счет разделения подобъектов (в сетевых системах)

Недостатки ранних СУБД:

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

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

Объектно-ориентированные СУБД

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

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

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

Структура

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

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

Целостность данных

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

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

Средства манипулирования данными

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

Подведем теперь некоторые итоги

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

В то же время, ОО - модели присущ и ряд недостатков :

  • отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;
  • вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES ) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).