Понятие и назначение базы данных. примеры и классификация баз данных

Состав частей реляционной модели данных

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

Структурная часть

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

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

Манипуляционная часть

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

Целостная часть

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

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

Обобщенное описание структуры

Термин «древовидная» для описания структуры упоминается в этой статье уже далеко не единожды. Пора рассказать, откуда он произошел. Все потому что иерархическая база данных — это такая БД, которая использует тип данных «дерево». Рассмотрим подробнее, что он из себя представляет.

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

Элементарные типы могут быть простыми и составными, но по существу это всегда записи. Но в простом записи присутствует один тип данных, а в составном — целая их совокупность.

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

Иерархия и реляционность

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

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

Другие модели баз данных (ООСУБД)

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

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

На данный момент не существует общепринятого стандарта ООСУБД. Считается, что подобные модели данных находится на ранней стадии развития.

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

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

Данная публикация является переводом статьи «Types of Database Models | Database Management System» , подготовленная редакцией проекта.

Операторы поиска данных с возможностью модификации

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

Синтаксис:

GET HOLD UNIQUE
<имя сегмента> WHERE <список поиска>

1. Найти и удержать следующий
   с теми же условиями поиска. Аналогично операции 4 эта операция дублирует вторую
   операции поиска GET NEXT с возможностью выполнения последующей модификации
   данных.

Синтаксис:

GET HOLD NEXT

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

Синтаксис:

GET HOLD NEXT
WITHIN PARENT

Операторы
модификации данных

1. Удалить : Это первая
   из трех операций модификации.

Синтаксис:

DELETE

Эта команда
не имеет параметров. Почему? Потому что операции модификации действуют на экземпляр
сегмента, найденный командами поиска с удержанием. А он всегда единственный
текущий найденный и удерживаемый для модификации экземпляр конкретного сегмента.
Поэтому при выполнении команды удаления будет удален именно этот экземпляр сегмента.

1. Обновить

Синтаксис:

UPDATE

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

Ввести новый
экземпляр сегмента.

INSERT <имя
сегмента>

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

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

Ограничения типа данных hierarchyidLimitations of hierarchyid

Тип данных hierarchyid имеет следующие ограничения.The hierarchyid data type has the following limitations:

• Столбец типа hierarchyid не принимает древовидную структуру автоматически.A column of type hierarchyid does not automatically represent a tree. Приложение должно создать и назначить значения hierarchyid таким образом, чтобы они отражали требуемые связи между строками.It is up to the application to generate and assign hierarchyid values in such a way that the desired relationship between rows is reflected in the values. Некоторые приложения могут содержать столбец типа hierarchyid , указывающий местоположение в иерархии, определенной в другой таблице.Some applications might have a column of type hierarchyid that indicates the location in a hierarchy defined in another table.

• Параллельными процессами создания и присвоения значений hierarchyid управляет само приложение.It is up to the application to manage concurrency in generating and assigning hierarchyid values. Нет никакой гарантии, что значения hierarchyid уникальны, если приложение не использует ограничение уникального ключа или не обеспечивает уникальность своей логикой.There is no guarantee that hierarchyid values in a column are unique unless the application uses a unique key constraint or enforces uniqueness itself through its own logic.

• Иерархические связи, представленные значениями типа hierarchyid , не обеспечиваются и не проверяются, как связи по внешнему ключу.Hierarchical relationships represented by hierarchyid values are not enforced like a foreign key relationship. Можно, а иногда и удобно иметь иерархическую связь, в которой у A есть потомок B и когда A удаляется, у B остается связь с несуществующей записью.It is possible and sometimes appropriate to have a hierarchical relationship where A has a child B, and then A is deleted leaving B with a relationship to a nonexistent record. Если это неприемлемо, приложение должно запросить потомков, прежде чем удалять родителей.If this behavior is unacceptable, the application must query for descendants before deleting parents.

Язык манипулирования данными в сетевой модели

Все операции
манипулирования данными в сетевой модели делятся на навигационные операции
и операции модификации.

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

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

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

	Операция	Назначение
	READY	Обеспечение доступа данного процесса или пользователя к БД (сходна по смыслу с операцией открытия файла)
	FINISH	Окончание работы с БД
	FIND	Группа операций, устанавливающих указатель найденного объекта на текущий объект
	GET	Передача найденного объекта в рабочую область. Допустима только после FIND
	STORE	Помещение в БД записи, .сформированной в рабочей области
	CONNECT	Включение текущей записи в текущий экземпляр набора
	DISCONNECT	Исключение текущей записи из текущего экземпляра набора
	MODIFY	Обновление текущей записи данными из рабочей области пользователя
	ERASE	Удаление экземпляра текущей записи

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

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

На рис. 3.7
представлена концептуальная модель торгово-посреднической организации.

Рис.
3.7. Схема БД «Торговая фирма»

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

RECORD Цены

02 Цена TYPE
REAL

02 Товар VIRTUAL

SOURCE IS Товары.НаименованиеТовара

OF OWNER OF
Товар-Цены SET

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

1. По ключу (запись должна
   быть описана через CALC USING …):

   FIND <Имя записи>
   RECORD BY CALC KEY <Имя параметра>

2. Последовательный просмотр
   записей данного типа:

   FIND DUPLICATE <Имя
   записи> RECORD BY CALC KEY

3. Найти владельца текущего
   экземпляра набора:

   FIND OWNER OF CURRENT
   <Имя набора> SET

4. Последовательный просмотр
   записей—членов текущего экземпляра набора:

   FIND (FIRST | NEXT) <Имя
   записи> RECORD IN CURRENT <Имя набора> SET

5. Просмотр записей—членов
   экземпляра набора, специфицированных рядом нолей:

   FIND <Имя
   записи> RECORD IN CURRENT <Имя набора> SET USING <Список полей>

6. Сделать текущей записью
   процесса текущий экземпляр набора:

   FIND CURRENT OF <Имя
   набора> SET

7. Установить текущую
   запись процесса:

   FIND CURRENT OF <Имя
   записи> RECORD

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

ФИО = "Петров"
FIND Люди RECORD BY CALC KEY
FIND FIRST Заказы RECORD IN
CURRENT Люди-Заказы SET WHILE NOT FAIL DO
FIND OWNER OF CURRENT
Товары-Заказы SET GET Товары 
PRINT НаимТовара FIND NEXT Заказы RECORD IN
CURRENT Люди-Заказы SET
END

к алгоритмизации  
алгоритмы, струкутуры данных и программирование  
СУБД  
ЯиМП  
3GL  
4GL  
5GL  
технологии прогр.

Знаете ли Вы, что любой разумный человек скажет, что не может быть улыбки без кота и дыма без огня, что-то там, в космосе, должно быть, теплое, излучающее ЭМ-волны, соответствующее температуре 2.7ºК. Действительно, наблюдаемое космическое микроволновое излучение (CMB) есть тепловое излучение частиц эфира, имеющих температуру 2.7ºK. Еще в начале ХХ века великие химики и физики Д. И. Менделеев и Вальтер Нернст предсказали, что такое излучение (температура) должно обнаруживаться в космосе. В 1933 году проф. Эрих Регенер из Штуттгарта с помощью стратосферных зондов измерил эту температуру. Его измерения дали 2.8ºK — практически точное современное значение. Подробнее читайте в FAQ по эфирной физике.

НОВОСТИ ФОРУМАРыцари теории эфира

Объектно-ориентированные субд

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

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

Структура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример модели

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

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. (а) (Для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры : заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК(НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (рис. (b)).

Из этого примера видны недостатки иерархических БД:

• Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.
• Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних. Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ — дочерней (рис. (c)). Таким образом, мы опять вынуждены дублировать информацию.

Операторы поиска данных

Синтаксис:

GET UNIQUE <имя
сегмента> WHERE <список поиска>;

список поиска
состоит из последовательности условий вида:

<имя сегмента>.<имя
поля>ОС <constant или имя другого поля данного сегмента или имя переменной>:

ОС — операция
сравнения;

условия могут
быть соединены логическими операциями И и ИЛИ {& , V}.

Назначение:

Получить
единственное значение.

Пример:

Найти типовую
модель стоимостью не более $600, которая существует не менее чем в 10 экземплярах.

GET UNIQUE ТИПОВЫЕ
МОДЕЛИ

WHERE Типовые
модели.Стоимость <= $600

AND Типовые модели,Количество
на складе >= 10

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

Синтаксис:

GET NEXT <имя
сегмента> WHERE <список аргументов поиска>

Назначение:

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

Пример:

Напечатать
полный список заказов стоимостью не менее $500.

GET UNIQUE ИНДИВИДУАЛЬНЫЕ
МОДЕЛИ

WHERE Индивидуальные
модели.Стоимость >- $500

WHILE NOT EAIL
(пока не конец поиска) DO

PRINT № заказа.
Стоимость, Количество

GET NEXT ИНДИВИДУАЛЬНЫЕ
МОДЕЛИ

END

Синтаксис:

GET NEXT <имя
сегмента> WITHIN PARENT

Назначение:

Получить
следующий для того же исходного.

Пример:

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

GET UNIQUE СКЛАД
WHERE Склад.Номер = 1

GET NEXT ИЗДЕЛИЕ
WITHIN PARENT

WHERE Изделие.Наименование
= «Винчестер»

GET NEXT ХАРАКТЕРИСТИКИ
WITHIN PARENT

WHERE ХАРАКТЕРИСТИКИ.Параметр
= 10 AND

ХАРАКТЕРИСТИКИ.Единицы
Измерения = Гб AND

ХАРАКТЕРИСТИКИ.Величина
> 10

While Not Fail
(пока поиск не завершен) DO

Get Next Within
Parent

end

Сетевые

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

Если мы возь­мём базу дан­ных с сай­та Кино­по­ис­ка, то она может выгля­деть так:

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

Напри­мер, вы посмот­ре­ли «Нача­ло» Кри­сто­фе­ра Нола­на и вам понра­вил­ся этот фильм. Когда вы перей­дё­те к спис­ку филь­мов, кото­рые он ещё снял, база на сай­те сде­ла­ет так:

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

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