2.2. Основные термины и определения теории бд, виды бд и их отличия

2.2.1. Классификация бд

По модели представления данных БД классифицируются как:

• картотеки;

• сетевые БД;

• иерархические БД;

• реляционные БД;

• многомерные БД;

• объектно-ориентированные БД;

• дедуктивные БД.

На уровне физической модели БД представляет собой файл или их набор в форматах TXT, CSV, Excel, DBF, XML либо в специализированном формате конкретной СУБД.

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

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

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

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

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

Упорядочение осуществляется обязательно по логическим критериям, по алфавиту, дате и т.д.

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

К основным понятиям сетевой модели БД относятся: уровень, элемент (узел), связь.

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

На схеме иерархического дерева узлы представляются вершинами графа.

В сетевой структуре каждый элемент может быть связан с любым другим элементом.

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

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

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

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

Примеры сетевых СУБД: Cerebrum, CronosPlus.

Иерархическая модель БД состоит из объектов с указателями от родительских объектов к потомкам, соединяющих вместе связанную информацию.

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

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

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

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

Объект «покупатель» будет иметь указатели от каждого заказчика к физическому расположению заказов покупателя в объект «заказ».

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

Также, трудно представить не-иерархические данные при использовании этой модели.

Известные иерархические СУБД:

• Иерархической базой данных является файловая система.

• Типичным представителем (наиболее известным и распространённым) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.

• Time-Shared Date Management System (TDMS) компании Development Corporation.

• Mark IV Multi - Access Retrieval System компании Control Data Corporation.

• System - 2000 разработки SAS-Institute.

• Серверы каталогов, такие, как LDAP и Active Directory (допускают чёткое представление в виде дерева).

• По принципу иерархической БД построен и реестр Windows.

Реляционная БД – БД, основанная на реляционной модели. Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 году.

В реляционных БД все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные.

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

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

• Данные хранятся в таблицах, состоящих из столбцов («атрибутов») и строк («записей», «кортежей»).

• На пересечении каждого столбца и строчки стоит в точности одно значение.

• У каждого столбца есть своё имя, которое служит его названием, и все значения в одном столбце имеют один тип.

• Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов.

• Строки в реляционной базе данных неупорядочены – упорядочивание производится в момент формирования ответа на запрос.

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

Многомерные БД – один из наиболее распространённых переводов термина OLAP (On-line Analytical Processing).

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

Это ПО позволяет реализовать множество различных представлений данных и характеризуются тремя основными чертами:

• многомерное представление данных;

• сложные операции над данными;

• операции, связанные с изменением данных во времени.

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

Характеристики ООБД:

1. Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счёт применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, т.е. любой конструктор можно было применять к любому объекту.

2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.

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

4. Поддержка типов и классов. Требуется, что бы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами.

5. Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.

6. Перегрузка в сочетание с полным связыванием. Методы должны применятся к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имён методов в системе не должно выполняться до времени выполнения программы.

7. Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.

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

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

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

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

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