Эволюция баз данных

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

15Данные взяты с сайта сети магазинов М-Видео. Автор данного пособия не является клиентом этого магазина, а его упоминание абсолютно случайно и не является рекламой.

41

Рис. 19. Схема данных в виде снежинки16

Необходимо отметить, что многомерный куб – это понятие концептуального уровня, которое ничего не говорит о способе физической организации данных. Его хранение в виде реляционной базы данных, т.е. в виде совокупности файлов, каждый из которых содержит одну таблицу, не всегда удобно. Попробуем проследить логику работы СУБД при попытке сформировать полное информационное описание продажи №3 из приведенного выше примера:

1)открыть файл ПРОДАЖА ТОВАРА и найти запись с ID_Прода-

жи = 3;

2)открыть файл ДАТА и найти запись с ID_Дата = D002; прочитать эту запись и подставить полученную информацию в итоговое описание продажи;

3)открыть файл ТОВАР, найти и прочитать запись с Код товара

=20022746;

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

42

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

2.9. Объектно-ориентированные базы данных

Другим направлением структурирования сложной многомерной информации является применение объектно-ориентированного подхода к хранению данных. Хотя работы в этом направлении велись с середины 1970-х гг., его формирование и сам термин «объектноориентированная база данных» (ООБД) связываются с манифестом [18], обнародованным в 1989 г. В нем были сформулированы основные характеристики, но не модель ООБД, строгого определения которой не существует до сих пор. В 1991 г. была сформирована группа по управлению данными, представленными в виде объектов

– ODMG (Object Data Management Group, англ.), преобразованная в 1998 г. в группу по управлению ООБД (Object Database Management Group, англ.). Эта группа просуществовала до 2001 г. и опубликовала несколько редакций требований к объектной модели данных, языку определения объектов, объектному языку запросов и к интерфейсам с языками программирования. Последняя версия этих требований – ODMG 3.0 стала, по существу, стандартом ООБД.

Данный подход основан на традиционной объектно-ориентиро- ванной парадигме, где любая конкретная сущность предметной области (например, работник Петров С.В. или пылесос ZSC6930) представляется в виде объекта, имеющего свой уникальный идентификатор. Каждый объект имеет состояние и поведение. Состояние – это набор значений его атрибутов. Значение атрибута – это тоже объект или множество объектов. Поведение – это изменение значений, производимое с помощью ассоциированных с объектов методов. Взаимодействие между объектами осуществляется посредством передаваемых друг другу сообщений. Например, сообщение «примени к себе данный метод» вызовет запуск соответствующей процедуры и, возможно, последующее изменение состояния объекта. Множество подобных объектов с одинаковыми атрибутами и методами образует класс. Классы в свою очередь могут образовывать иерархию.

На рисунке 21 приведен пример реализации базы данных, показанной на рис. 13, 14 и в табл. 7–9, с помощью объектно-ориенти-

44

рованной парадигмы17. Сравнив рис. 21 и 14, можно увидеть, что структурно ООБД очень напоминает иерархическую модель. Это вызвано тем, что основным видом связи между объектами и классами является обобщение, обеспечивающее наследование свойств.

Рис. 21. Объекты, атрибуты и методы

Общими для всех классов ООБД являются методы «Создать объект», «Удалить объект». Метод ПЕРЕВЕСТИ класса ОТДЕЛ (рис. 21) позволяет перевести работника из одного отдела в другой, а

17Данный пример лишь иллюстрирует введенные понятия и не является строгой объектно-ориентированной схемой.

45

метод НАЗНАЧИТЬ класса РАБОТНИК – изменить должность работника.

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

вто время как их обработка и изменение ложатся на прикладную программу. В объектно-ориентированном подходе изменение данных – это изменение состояния объекта, осуществляемое методами, ассоциированными с объектом [7]. Иначе говоря, в ООБД процедуры обработки являются частью данных, т.е. данные и процедуры объединены – инкапсулированы вместе.

Из-за привлекательности объектно-ориентированного подхода

впоследние двадцать лет наблюдается высокая активность в создании СУБД18. Согласно [16], сегодня их насчитывается около 300. Однако большинство из них являются экспериментальными прототипами, в то время как коммерческих продуктов сравнительно немного – наиболее испытанные временем представлены в табл. 16.

2.10. Темпоральные базы данных

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

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

46

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

Базовым понятием в темпоральной базе данных является линия времени – представление моментов и интервалов времени, характеризующих истинность хранимой информации19. Как правило, обычная база данных хранит лишь текущую информацию, т.е. информацию, которая истинна в данный момент времени. Если информация меняется, например, происходит повышение зарплаты сотрудника, то размер новой зарплаты записывается на место старой (табл. 17). И уж тем более, эта информация исчезнет после увольнения сотрудника и удаления соответствующей записи. В отличие от обычной, в темпоральной базе данных сохраняется вся история данных. Известны два основных способа формирования линии времени:

1)указание интервалов времени, в течение которых определенный факт являлся истинным (табл. 18);

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

Таблица 17

Данные без темпоральных расширений

Таблица 18 Интервальное представление темпорального расширения данных

19Строго говоря, существуют две линии времени – действительная (valid time) и транзакционная (transaction time). В тексте речь идет о первом типе.

47

Таблица 19 Точечное представление темпорального расширения данных

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

Для работы с темпоральными базами данных в 1994 г. был разработан язык TSQL2 (SQL/Temporal), являющийся расширением традиционного SQL, и созданы немногочисленные СУБД (табл. 20).

48

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

2.11. Нереляционные базы данных

В 2000-е гг. с появлением web-ресурсов с огромными хранилищами разнородной информации разработчики стали все больше экспериментировать с новыми идеями. Реляционный подход основан на четком структурировании данных и строго формализованном доступе к ним, что делает базы данных негибкими и замедляет скорость работы. Новый подход базировался на отказе от фиксированной схемы данных и языка SQL. В 1998 г. этот подход получил название NoSQL, которое разными авторами трактуется как «нереляционная» или «не только SQL» (not only SQL, англ.). «Нереляционная» не означает антиреляционная – адепты этого направления, не отрицая достоинств реляционного подхода, лишь подчеркивают новые возможности нереляционного.

Рассмотрим основные понятия и нереляционные технологии хранения на примере данных, показанных в отношении РАБОТНИК, введенном в разд. 2.6 (табл. 21) 20.

Таблица 21

Отношение РАБОТНИК

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

49

Первое важное «нереляционное» понятие – ассоциативный массив (другие названия – ассоциативный контейнер, отображение, конечное отображение, словарь21 ), который представляет собой пару «ключ-значение». Подобно математической функции, связывающей независимую переменную x с зависимой y, ассоциативный массив отображает ключ на значение, т.е. ассоциирует значение с ключом. Например, с ключом Петров С.В. ассоциировано значение

Начальник; иначе говоря, имеем пару <Петров С.В., Начальник>. В

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

Ассоциативные массивы легли в основу так называемых key-va- lue-баз данных (другие названия – кортежные хранилища или хранилища «ключ-значение»), образцами которых, согласно данным англоязычной Wikipedia, являются Cassandra (Apache Software Foundation, 2008), GT.M (Fidelity National Information Services, Inc., 2000), Redis (VMware, 2009), Riak (Basho Technologies) и др.

Расширением ассоциативного массива стал трипл (triple – тройка, англ.) – три элемента, связанные в выражение «субъект – предикат – объект» [25]. Если на первое место в этой тройке поставить некоторый конкретный материальный объект, на второе – его свойство, а на третье – значение этого свойства, то получаем классический элемент информации «объект-атрибут-значение», например, <Петров С.В., Должность, Начальник>. По существу трипл – это одна ячейка классического отношения. Благодаря указанию свойства, для которого приведено значение, триплы являются более информативными, чем пары «ключ-значение». В случае пар каждый объект может быть представлен в базе данных лишь единожды, иначе нарушится свойство уникальности ключа. В случае триплов каждому объекту может соответствовать столько триплов, сколько свойств имеет данный объект. Например, отношение, показанное в табл. 21, можно представить следующими триплами<Петров: С.В., Дата рождения, 21.09.1978>;

<Петров С.В., Пол, М>; <Петров С.В., Должность, Начальник>;

<Иванова И.В., Дата рождения, 8.07.1963 > …

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

50