Объектно-ориентированная модель данных является расширением положений объектно-ориентированного программирования (в то время как реляционная модель возникла на основе теории множеств, именно как модель данных). Группой управления Объектно-ориентированных БД разработан стандарт ODMG-93 (Object DataBase Management Group). Этот стандарт полностью еще не реализован.
Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Видимая структура объекта определяется свойствами его класса. Класс включает в себя объекты, при этом структура и поведение объектов одного класса одинаковы. Каждый объект, а именно экземпляр класса считается потомком объекта, в котором он определен как свойство. Свойства объектов - или стандартный тип, например, string, или конструируемый пользователем тип class. Поведение объектов задается с помощью методов. Метод – это некая операция, которую можно применить к объекту.
В качестве примера рассмотрим БД «БИБЛИОТЕКА» (рис.4.4). Для каждого объекта определены свойства, их типы и значения. В БД:
«БИБЛИОТЕКА» – родитель (предок) для «АБОНЕМЕНТ», «КАТАЛОГ», «ВЫДАЧА»;
«КАТАЛОГ» – родитель для «КНИГА».
«КНИГА» – различные объекты могут иметь одного или разных родителей. Если один и тот же родитель (один автор), то инвентарные номера разные, но isbn, УДК, название и автор – одинаковы.
Логическая структура объектно-ориентированной БД похожа на иерархическую, основное отличие – в методах манипулирования данными. Над БД можно производить такие действия как логические операции, усиленные объектно-ориентированными методами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором определено. Так, если в «КАТАЛОГ» добавлено свойство телефон автора книги, то получаются аналогично в «АБОНЕМЕНТ» и «КАТАЛОГ». Смысл свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование ,наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа «КНИГА», являющимся потомками «КАТАЛОГ», можно приписать свойства родителя isbn, УДК, название и автор.
Полиформизм означает способность одного и того же программного кода работать с разнотипными данными. Иными словами, он означает допустимость в объектах разных типов иметь методы – процедуры и функции – с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Для БД «БИБЛИОТЕКА» это означает, что объекты класса «КНИГА», имеющие разных родителей из класса «КАТАЛОГ» может иметь разный набор свойств, т.е. программы работы с объектом класса «КНИГА» может содержать полиморфный код. В классе у метода нет тела, т. е. не определено, какие конкретно действия он должен выполнить. Каждый подкласс выполняет нужные операции. Инкапсуляция скрывает детали реализации от всех объектов вне данной иерархии.
Достоинствамиобъектно-ориентированноймодели в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов, отсутствие ограниченности в структурах хранения данных. В объектно-ориентированной БД может храниться не только структура, но и поведенческие аспекты данных. С использованием объектно-ориентированного подхода могут создаваться и БД с большими объемами семантической информации, такие как мультимедийные и специализированные для конкретных предметных областей (географические, проектные и др.).
К недостаткам данного подходаможно отнести высокую понятийную сложность, неудобство обработки данных и низкую скорость выполнения запросов.
В 90-е годы были созданы прототипы действующих объектно-ориентированных БД. Это POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.
Тема 5
Реляционный подход при построении информационно-логической модели: основные понятия
Реляционная модель данных. Основные понятия
Как было отмечено в разделе предыдущей лекции, реляционная модель в настоящее время является одной из наиболее распространенных моделей на рынке БД. Основу этой модели составляет набор взаимосвязанных таблиц (отношений).
Основные теоретические идеи реляционной модели были изложены в работах по теории отношений американского логика Чарльза Содерса Пирса (1839-1914) и немецкого логика Эрнста Шредера (1841-1902), а также американского математика Эдгара Кодда.
В работах Пирса и Шредера было доказано, что множество отношений замкнуто относительно некоторых специальных операций, совместно образующих абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными.
В 1970 г. появилась статья Э.Кодда о представлении данных, организованных в виде двумерных таблиц, называемых отношениями. Коддом впервые были введены основные понятия и ограничения реляционной модели как основы хранения данных, и показана возможность обработки данных с помощью традиционных операций над множествами и специальных введенных реляционных операций.
Основные понятия реляционной модели даны в табл. 3.1.
Объектами реляционной модели в основном являются таблицы (отношения). Целостность данных обеспечивается внешними и первичными ключами (см. п. «Реляционная целостность данных»).
Операторы в реляционной модели – это набор инструкций, которые обеспечивают выборку и манипуляцию над данными.
Таблица 5.1. Элементы реляционной модели
| Термин реляционной модели | Описание |
| База данных (БД) | Набор таблиц и других объектов, необходимых для абстрактного представления выбранной предметной области |
| Схема БД | Набор заголовков таблиц, взаимосвязанных друг с другом |
| Отношение | Таблица – совокупность объектов реального мира, которые характеризуются общими свойствами и характеристиками (поля таблицы) |
| Заголовок отношения | Заголовок таблицы – названия полей (столбцов) таблицы |
| Тело отношения | Тело таблицы – совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таблицы) |
| Схема отношения | Строка заголовков столбцов таблицы («шапка» таблицы) |
| Атрибут отношения | Наименование столбца таблицы (поле таблицы) |
| Кортеж отношения | Строка таблицы (запись) – однозначное представление объекта реального мира, созданное с использованием значений полей таблицы |
| Домен | Множество допустимых значений атрибута |
| Значение атрибута | Значение поля в записи (кортеже) |
| Первичный ключ | Один или несколько (в случае составного ключа) атрибутов, которые единственным образом определяют значение кортежа (значение строки таблицы) |
| Внешний ключ | Атрибут таблицы, значения которого соответствуют значениям первичного ключа в другой связанной (родительской, первичной) таблице. Внешний ключ может состоять как из одного, так и из нескольких атрибутов (составной внешний ключ). Если число атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего первичного ключа, то он называется усеченным (частичным) внешним ключом |
| Степень (арность) отношения | Количество столбцов таблицы |
| Мощность отношения | Количество строк (кортежей) таблицы |
| Экземпляр отношения | Множество записей (кортежей) для данной таблицы (отношения). С течением времени экземпляр может изменяться. Поскольку обычная БД в текущий момент времени работает только с одной версией отношения, то такой экземпляр отношения называется текущим |
| Тип данных | Тип значений элементов таблицы |
| Базовое отношение | Отношение, содержащие один или несколько столбцов, характеризующих свойства объекта, а также первичный ключ |
| Производное отношение | Не является базовым отношением, т.е. не характеризует свойства объекта и используется для обеспечения связей между другими таблицами, может не содержать первичного ключа. Если первичный ключ задан, то он состоит из внешних ключей, связанных с первичными ключами базового отношения |
| Связь | Устанавливает взаимосвязь между совпадающими значениями в ключевых полях – первичным ключом одной таблицы и внешним ключом другой |
| Связь «один-к-одному» (1:1) | При использовании этого вида связи запись в одной таблице может иметь не более одной связанной с нею записи в другой таблице. В обеих таблицах ключевые поля должны быть первичными. Используется для разделения таблиц с многочисленными полями или по требованию защиты данных |
| Связь «один-ко-многим» (1:M) | При использовании этого вида связи каждой записи одной таблицы может соответствовать несколько записей второй, но каждой записи второй таблицы соответствует лишь одна запись первой таблицы. В первой таблицы обязательно должен быть задан первичный ключ, во второй – внешний |
| Связь «многие-ко-многим» (N:M) | При данном типе связи одной записи в первой таблице может соответствовать несколько записей второй таблицы, но и одной записи второй таблицы может соответствовать несколько записей первой. Уникальность ключей для таких таблиц не требуется. В процессе проектирования схемы БД такие связи преобразуют. Для этого необходимо ввести вспомогательное отношение, позволяющее заменить связь «многие-ко-многим» на две связи типа «один-ко-многим» |
Структура данных реляционной модели предполагает представление предметной области рассматриваемой задачи в виде набора взаимосвязанных отношений.
В каждой связи одно отношение может выступать как основное (базовое, родительское), а другое – в роли подчиненного (производного, дочернего). Для поддержания этих связей оба отношения должны содержать набор атрибутов, по которым они связаны: в основном отношении это – первичный ключ отношения (однозначно определяет кортеж основного отношения); в подчиненном отношении должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Здесь этот набор атрибутов уже является вторичным ключом или внешним ключом, т.е. определяет множество кортежей производного отношения., связанных с единственным кортежем основного отношения.
Множество взаимосвязанных друг с другом таблиц образуют схему БД .
Итак, отношение R представляет собой двумерную таблицу, содержащую некоторые данные.
Математически N -арное отношение R – это множество декартова произведения D 1 ×D 2 ×…×D n множеств (доменов) D 1 , D 2 ,…,D n (n ≥1), необязательно различных:
R D 1 ×D 2 ×…×D n ,
где D 1 ×D 2 ×…×D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.
Домен представляет собой семантическое понятие, которое можно рассматривать как подмножество значений некоторого типа данных, имеющих определенный смысл.
Свойства домена :
Домен имеет уникальное имя (в пределах БД),
Определен на некотором простом типе данных или на другом домене,
Может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для этого домена,
Несет определенную смысловую нагрузку.
Основное значение доменов состоит в том, что они ограничивают сравнения: нельзя сравнивать значения из различных доменов, даже если они имею одинаковый тип данных.
Атрибут отношения представляет собой пару вида
<Имя_атрибута: Имя_домена> (либо <A:D >).
Имена атрибутов в пределах отношения уникальны. Часто имена атрибутов совпадают с именами соответствующих доменов.
Отношение R, определенное на множестве доменов, содержит две части: заголовок и тело.
Заголовок отношения – фиксированное кол-во атрибутов отношения, описывающее декартово произведение доменов, на котором задано отношение:
(<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >).
Заголовок статичен: не меняется во время работы с БД, Если в отношении изменены, добавлены, удалены атрибуты, то получается уже другое отношение. Даже при сохраненном имени.
Тело отношения содержит множество кортежей отношения.
Каждый кортеж представляет собой множество пар вида:
<Имя_атрибута: Значение атрибута>:
R (<A 1:Val 1 >, <A 2:Val 2 >, …, <A n: Val n >).
Таких, что значение Val i атрибута A i принадлежит домену D i .
Тело отношения представляет собой набор кортежей, т. Е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных, т. К. кортежи с течением времени могут изменяться, добавляться и удаляться.
Отношение обычно записывается в виде:
R (<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >),
либо сокращенно: R (A 1 , A 2 , …, A n ) или R .
Схема отношения представляет собой набор заголовков отношения, входящих в базу данных, т. Е. перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:
S R = (A 1 , A 2 , …, A n ), A i D i , i = 1,..., n .
Если атрибуты принимают значения из одного и того же домена, то они называются θ-сравнимыми, где θ - множество допустимых операций сравнений, заданных для данного домена.
Например, если домен содержит числовые данные, то для него допустимы все операции сравнения: θ == {=, <>,>=,<=,<,>}. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он также имеет полное множество операций сравнения.
Схемы двух отношений называются эквивалентными , если они имеют одинаковую степень, и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, т. Е. атрибуты, принимающие значения из одного домена.
Таким образом, для эквивалентных отношений выполняются следующие условия:
Наличие одинакового количества атрибутов;
Наличие атрибутов с одинаковыми наименованиями;
Наличие в отношениях одинаковых строк с учетом того, что порядок атрибутов может различаться;
Отношения такого рода есть различные изображения одного и того же отношения.
Свойства отношений непосредственно следуют из приведенного ранее определения отношения. В этих свойствах в основном и состоят различия между отношениями реляционной модели данных и простыми таблицами:
Уникальность имени отношения. Имя одного отношения должно отличаться от имен других отношений.
Уникальность кортежей. В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Каждая ячейка отношения содержит только атомарное (неделимое) значение.
Неупорядоченность кортежей. Кортежи не упорядочены (сверху вниз), т. К. тело отношения есть множество, а множество не упорядочено (для сравнения - строки в таблицах упорядочены). Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
Неупорядоченность атрибутов. Атрибуты не упорядочены (слева направо).
Уникальность имени атрибута в пределах отношения. Каждый атрибут имеет уникальное имя в пределах отношения, значит, порядок атрибутов не имеет значения (для сравнения - столбцы в таблице упорядочены). Это свойство несколько отличает отношение от математического определения отношения. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.
Атомарность значений атрибутов. Все значения атрибутов атомарны. Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения, т. Е. с каждым триибутом связана какая-то область значений (отдельный элементарный тип), значения атрибутов берутся из одного и того же домена. Схема и кортежи отношения - множества, а не списки, поэтому порядок их представления не имеет значения. Для сравнения - в ячейки таблицы можно поместить различную информацию: массивы, структуры, другие таблицы и т. Д.
Замечание:
Из свойств отношения следует, что не каждая таблица может быть отношением. Для того чтобы некоторая таблица задавала отношение, необходимо, чтобы таблица имела простую структуру (содержала только строки и столбцы, причем в каждой строке должно быть одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми.
Следует отметить, что реляционная модель представляет собой базу данных в виде множества взаимосвязанных отношений, которые называются схемой реляционной базы данных .
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Стандартизованная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group – Группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрошенную модель объектно-ориентированной БД.
Структура объектно-ориентированной БД (например, Versant Object Database, Object Store и др.) графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым – string) или типом, конструируемым пользователем (определяется как class).
Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект – экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект – экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.
Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными.
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Ограниченно могут применяться операции, подобные командам языка SQL (например, для создания БД).
Создание и модификация БД сопровождаются автоматическим формированием и последующей корректировкой индексов (индексных таблиц), содержащих информацию для быстрого поиска данных.
Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.
Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Поиск в объектно-ориентированной БД состоит в выяснении сходств между объектом, задаваемым пользователем, и объектами, хранящимися в БД. Определяемый пользователем объект, называемый объектом-целью (свойство объекта имеет тип goal), в общем случае может представлять собой подмножество всей хранимой в БД иерархии объектов. Объект-цель, а также результат выполнения запроса могут храниться в самой БД.
Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
Первоначально СУБД применялись преимущественно для решения финансово-экономических задач. При этом независимо от модели представления в базах данных использовались следующие основные типы данных:
В разных СУБД эти типы могли несущественно отличаться друг от друга по названию, диапазону значений и виду представления. Впоследствии is новых областях применения стали появляться специализированные системы обработки данных, например геоинформациониые, обработки видеоизображений и т.д. В связи с этим разработчики стали вводить в традиционные СУБД новые типы данных. К числу сравнительно новых типов данных можно отнести следующие:
В современных СУБД с различными моделями данных могут использоваться все перечисленные типы данных.
Объектно-ориентированная модель данных
Объектно-реляционная модель данных
Другие модели данных
Всё возрастающая сложность приложений баз данных и ограниченность реляционной модели привели к развитию модели Кодда, ĸᴏᴛᴏᴩᴏᴇ сначала получило название расширенной реляционной модели , а позже получило свое развитие в объектно-реляционной модели данных . Базы данных, основанные на этих моделях, принято относить к III-у поколению.
Объектно-реляционная модель данных (ОРМД) реализована с помощью реляционных таблиц, но включает объекты, аналогичного понятию объекта в объектно-ориентированном программировании. В ОРМД используются такие объектно-ориентированные компоненты, как пользовательские типы данных, инкапсуляция, полиморфизм, наследование, переопределение методов и т.п.
К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 ᴦ. был принят стандарт SQL-99, а в 2003 ᴦ. вышел второй релиз этого стандарта͵ получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).
В большинстве реализаций ОРМД объектами признаются агрегат и таблица (отношение), которая может входить в состав другой таблицы. Методы обработки данных представлены в виде хранимых процедур и триггеров, которые являются процедурными объектами базы данных, и связаны с таблицами. На концептуальном уровне все данные объектно-реляционной БД представлены в виде отношений, и ОРСУБД поддерживают язык SQL.
Ещё один подход к построению БД – использование объектно-ориентированной модели данных (ООМД) . Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (к примеру, для систем автоматизации проектирования (САПР), издательских систем и т.п.).
При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:
К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.
Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.
В 2000 ᴦ. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации состоит по сути в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.
Теперь рассмотрим, как поддержка моделей данных реализована в реальных системах управления базами данных.
Объектно-ориентированная модель данных - понятие и виды. Классификация и особенности категории "Объектно-ориентированная модель данных" 2017, 2018.
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы данных. Между записями и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книг а могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isb n , удк, названи е и автор.
Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Наследование , наоборот, распространяет область видимости свойства на всех потомков объекта.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.
Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
К объектно-ориентированным СУБД относятся POET , Jasmine , Versant , O 2, ODB — Jupiter , Iris , Orion , Postgres .
Постреляционная модель
Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц. Постреляционная модель представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных. Модель допускает многозначные поля – поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу.
На рис. 2.6 на примере информации о накладных и товарах для сравнения приведено представление одних и тех же данных с помощью реляционной (а) и постреляционной (б) моделей. Из рисунка видно, что по сравнению с реляционной моделью в постреляционной модели данные хранятся более эффективно, а при обработке не потребуется выполнять операцию соединения данных из двух таблиц.
Накладные Накладные-товары
|
N накладной |
Покупатель |
N накладной |
Количество |
||
Накладные
|
N накладной |
Покупатель |
Количество |
|
Рис. 2.6. Структуры данных реляционной и постреляционной моделей
Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД соответствующих механизмов.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.
Рассмотренная постреляционная модель данных поддерживается СУБД uniVers . К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb .
Многомерная модель
Многомерный подход к представлению данных появился практически одновременно с реляционным, но интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов. Толчком послужила в 1993 году статья Э. Кодда. В ней были сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing – оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных.
В развитии концепций информационных систем можно выделить следующие два направления:
Системы оперативной (транзакционной) обработки;
Системы аналитической обработки (системы поддержки принятия решений).
Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД.
Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации. Основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость.
Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь, управляющий, руководитель.
Историчность данных предполагает обеспечение высокого уровня статичности собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени.
Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными.
По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 2.7 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей.
Основные понятия многомерных моделей данных: измерение и ячейка.
Измерение – это множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.
Ячейка – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).
Рис. 2.7. Реляционное и многомерное представление данных
В примере на рис. 2.7 б каждое значение ячейки Объем продаж однозначно определяется комбинацией временного измерения Месяц продаж и модели автомобиля. На практике зачастую требуется большее количество измерений. Пример трехмерной модели данных приведен на рис. 2.8.
Рис. 2.8. Пример трехмерной модели
В существующих многомерных СУБД используются две основных схемы организации данных: гиперкубическая и поликубическая.
В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server .
В случае гиперкубической схемы предполагается, что все ячейки определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов в БД, все они имеют одинаковую размерность и совпадающие измерения.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем.
Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации.
Примерами систем, поддерживающими многомерные модели данных, является Essbase , Media Multi - matrix , Oracle Express Server , Cache . Существуют программные продукты, например Media / MR , позволяющие одновременно работать с многомерными и с реляционными БД.
Объектно-ориентированная модель
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы данных. Между записями и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG -93 (Object Database Management Group – группа управления объектно-ориентированными базами данных).
Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связн ую ие рархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент , Каталог и Выдача . Различные объекты типа Книг а могут иметь одного или разных родителей. Объекты типа Книга , имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isb n , удк , названи е и автор .
Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон , то мы получим одноименные свойства у объектов Абонент и Каталог . Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование , наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга , являющимся потомками объекта типа Каталог , можно приписать свойства объекта-родителя: isbn , удк , название и автор . Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs . Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свой ств вс еми дочерними объектами Абонент , Книга и Выдач а. Не случайно, поэтому значения свойства билет классов Абонент и Выдача , показанных на рис. 2.9, являются одинаковыми – 00015.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к рассматриваемому примеру полиморфизм означает, что объекты класса Книга , имеющие разных родителей из класса Каталог , могут иметь разный набор свойств. Следовательно, программы работы с объектами класса Книга могут содержать полиморфный код.
Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.
Рис. 2.9. Логическая структура БД библиотечного дела
Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
К объектно-ориентированным СУБД относятся POET , Jasmine , Versant , O 2, ODB - Jupiter , Iris , Orion , Postgres .
