Шпора

Естественное хранение в виде типа xml

Данные при этом хранятся во внутреннем представлении, которое обеспечивает неизменность XML-содержимого данных. Это внутреннее представление включает в себя сведения об иерархии контейнеров, порядке документов и значений элементов и атрибутов. Точнее говоря, при этом обеспечивается неизменность InfoSet-содержимого XML-данных. Сведения о спецификации InfoSet можно найти по адресу: http://www.w3.org/TR/xml-infoset. InfoSet-содержимое не всегда идентично текстовым XML-данным, потому что следующая информация при этом не сохраняется: несущественные пробелы, порядок атрибутов, префиксы пространств имен и XML-декларация.

Для типизированного (то есть связанного с XML-схемой) типа данных xml модуль проверки после обработки схемы (PSVI) добавляет в информационный набор данные о типах и кодирует их во внутреннее представление. Это значительно ускоряет синтаксический анализ. Дополнительные сведения см. в спецификациях XML-схем, разработанных консорциумом W3C XML. Найти их можно по адресам http://www.w3.org/TR/xmlschema-

1 иhttp://www.w3.org/TR/xmlschema-2.

Сопоставление XML-данных и данных, хранящихся в реляционном формате

Используя аннотированную схему (AXSD), можно разбить XML на столбцы одной или нескольких таблиц. Это обеспечивает правильность данных на реляционном уровне. В результате гарантируется сохранность иерархической структуры данных, хотя порядок элементов не учитывается. Схема не может быть рекурсивной.

Хранение больших объектов, [n]varchar(max) и varbinary(max)

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

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

Выбор XML-технологии

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

Параметры хранения

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

Обработка запросов

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

Назначение ключевого слова BROWSE не относится к теме нашей статьи.

FOR XML RAW – Каждая строка представляется в виде элемента <row/>.

Индексирование XML-данных

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

Возможности модификации данных Некоторые виды рабочей нагрузки сопряжены с

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

Поддержка схем

XML-данные можно описать при помощи схемы, которая может быть, а может и не быть документом XML-схемы. Поддержка связанных со схемой XML-

данных зависит от XML-технологии.

Кроме того, технологии хранения XML-данных различаются по быстродействию.

Хранение XML-данных в собственном формате

XML-данные можно хранить на сервере в столбце типа xml. Этот вариант уместен, если выполняются следующие условия:

необходим простой способ хранения XML-данных на сервере, при этом нужно сохранить порядок и структуру документа;

существует вероятность отсутствия схемы XMLданных;

требуется запрашивать и изменять XML-данные;

требуется проиндексировать XML-данные для ускорения обработки запросов;

требуется использовать в приложении представления системного каталога для управления

XML-данными и XML-схемами.

Механизм хранения XML-данных в естественном формате полезен, если есть XML-документы, имеющие разную структуру, или XML-документы, соответствующие разным или сложным схемам, которые слишком трудно сопоставить с реляционными структурами.

XML-столбец может быть столбцом, вычисляемым на основе столбца [n]varchar(max). Однако для вычисляемого XMLстолбца, а также для столбцов типов[n]varchar(max) или varbinary(max) нельзя создать XML-

индекс.

Технология XML-представлений

Определив соответствие между XML-схемами и таблицами базы данных, можно создать «XML-представление» хранимых данных. Чтобы заполнить базовые таблицы при помощи XMLпредставления, можно использовать операцию массовой загрузки XML-данных. Запрашивать XML-данные можно при помощи технологии XPath версии 1.0, при этом запрос преобразуется в SQL-запросы таблиц. Обновления также распространяются на эти таблицы.

Название поля формирует название атрибута, а значение поля – значение атрибута.

Пример

Этот запрос возвращает имена	буквы M. Вот результаты в
всех авторов, начинающиеся с	формате	XML:

<row au_fname="Marjorie" au_lname="Green" address="309 63rd St. #411" />

<row au_fname="Michael" au_lname="O'Leary" address="22 Cleveland Av. #14" />

<row au_fname="Meander" au_lname="Smith" address="10 Mississippi Dr." />

<row	au_fname="Morningstar"	au_lname="Greene"
address="22 Graybar House Rd." />
<row	au_fname="Michel" au_lname="DeFrance" address="3
Balding Pl." />

Эта технология полезна в следующих ситуациях:

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

есть XSD-схема или XDR-схема XML-данных, которую, возможно, предоставила внешняя

партнерская организация;порядок данных не важен, данные таблиц

select au_fname, au_lname, address from authors

where au_fname like 'M%' for xml raw

нерекурсивны или максимальная глубина рекурсии не известна заранее;

требуется запрашивать и изменять данные посредством XML-представления с использованием технологии XPath версии 1.0;

требуется выполнять массовую загрузку XMLданных и распределять их между базовыми

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

Комбинированная модель Довольно часто для моделирования данных лучше всего

подходит комбинация реляционных столбцов и столбцов типа xml . Некоторые значения XML-данных можно хранить в реляционных столбцах, а остальные или все значения XML — в XML-столбце. Это может привести к повышению производительности за счет более полного контроля над индексами, созданными для реляционных столбцов, и параметрами блокировки.

Значения, которые следует хранить в реляционных столбцах, зависят от рабочей нагрузки. Например, если извлекаются все XML-значения при использовании выражения пути /Customer/@CustId, то, выполнив продвижение значения атрибута CustId до реляционного столбца и осуществив его индексацию, можно ускорить обработку запросов. С другой стороны, если XML-данные чрезмерно распределить по реляционным столбцам без дублирования, составление данных в единое целое может оказаться слишком дорогим.

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

Примеры формирования выборок данных с использованием XML-элементов с помощью SQL-запросов.

FOR XML

Этот оператор предназначен для представления результирующего набора строк в виде XML-документа.

Рассмотрим		его	синтаксис:
	[ FOR { BROWSE | XML { RAW | AUTO
		| EXPLICIT }
		[ , XMLDATA ]
		[ , ELEMENTS ]
		[ , BINARY BASE64 ]
		}
	]

Язык запросов на основе Xquery.

XQuery — язык запросов, разработанный для обработки данных в формате XML. XQuery использует XML как свою модель данных. XML-документ может содержать ОЧЕНЬ много данных, поэтому нужно уметь как-то искать те или иные данные в нем.

С этой целью консорциумом W3C был создан язык запросов

XQuery.

Составной частью XQuery является XPath - язык адресации в XML-документе.

Некоторые основные правила синтаксиса:XQuery чувствителен к регистру

XQuery элементы, атрибуты и переменные должны быть действительными именами XML

Значение Строка должно заключаться в одинарные или двойные кавычки

Переменная XQuery определяется с $, за которым следует имяКомментарии оформляются в (: а :)

Условные выражения XQuery

"If-Then-Else"

Посмотрите на следующий пример:

for $x in /bookstore/book

return if ($x/@category="CHILDREN")

then <child>{data($x/title)}</child>

else <adult>{data($x/title)}</adult>

Заметки о «если-то-иначе" синтаксис: скобки, если выражение не требуется. еще не требуется, но это может быть просто другом (). В результате:

<adult>Everyday Italian</adult>

<child>Harry Potter</child>

<adult>Learning XML</adult>

<adult>XQuery Kick Start</adult>

XQuery сравнения

В XQuery существует два способа сравнения значений.

1.Основной: =, =, <, <=,>,> =

eq, ne, lt, le, gt, ge

Разница между этими двумя методами сравнения приведены ниже.

Следующее выражение возвращает истину, если д атрибуты имеют значение больше 10:

$bookstore//book/@q > 10

Следующее выражение возвращает истину, если есть только один атрибут q возвращает выражение, и его значение больше 10. Если более чем один q возвращается сообщение об ошибке:

$bookstore//book/@q gt 10

FLWOR - аббревиатура из первых букв операторов - выражение, которое является основной частью XQuery

Выражение FLWOR является одним из самых мощных и в то же время обычных выражений в XQery. Однако выражения FLWOR не определены в терминах таблиц, строк и столбцов; вместо этого они связывают с переменными значения в операторах for и let и используют эту связь для создания новых результатов. Комбинация связей переменных, созданных операторами for и let в выражении FLWOR, называется кортежем.

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

let - это оператор присваивания. Связывает переменные с полным результатом вычисления выражения, добавляя эти связи к кортежам, полученным оператором for, или создавая единственный кортеж (при отсутствии оператора for).

order by - сортирует поток кортежей

where - оставляет в потоке только те кортежи, которые удовлетворяют условию, являющемуся параметром данного оператора

return - создает результат выражения

FLWOR аббревиатура "For, Let, Where, Order by, Return".

"Действительно, Пусть, Где, Сортировка, Вернуть".

Ниже приведен пример, с которым вы уже знакомы:

/bookstore/book[price>30]/title

При помощи данного выражения будут выбраны все названия книг, которые по прайсу больше 30. Следующее выражение XQuery FLWOR равносильно предыдущей записи.

for $x in /bookstore/book

where $x/price>30

return $x/title

XML (EXtensible Markup Language) – расширяемый язык разметки, с

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

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

HTML.

Язык XML представляет собой подмножество языка SGML (стандартный обобщенный язык разметки); он предназначен специально для оформления документов Web.

Язык XML уже фактически стал стандартным средством обмена данными в индустрии программного.

Преимущества XML

1.Простота — относительно простой язык, его стандарт не превышает по объему 50 стр.

2.Открытый стандарт; независимость от платформы и программного обеспечения. Язык XML также основан на стандарте (ISO 10646), в нем предусмотрена поддержка набора символов Unicode, и поэтому он может служить для представления текста на всех алфавитах.

3.Способность к расширению. В отличие от HTML он позволяет пользователям опр. собственные дескрипторов соответствии с требованиями к конкретному приложению.

4.Возможность повторного использования. Расширяемость языка XML позволяет также создавать библиотеки дескрипторов XML и повторно использ. их во многих приложениях.

5.Разделение информационного наполнения и средств представления. Язык XML позволяет хранить содержимое документа и независимо от этого описывать способ его представления (в браузере).

6.Улучшенное распределение нагрузки. Язык XML позволяет доставлять данные в браузер (на клиентский компьютер) для проведения некоторых вычислений на месте; при этом сервер частично освобождается от вычислительной нагрузки и обеспечивается более равномерное распределение нагрузки.

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

9.Усовершенствованные механизмы поиска. При использовании XML поисковые машины могут применяться просто для интерпретации дескрипторов с описаниями.

Недостатки

1.Синтаксис избыточен – большой размер XML-документа; влияние на эффективность приложения (возрастает стоимость хранения, обработки и передачи данных).

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

3.XML не содержит встроенной в язык поддержки типов данных – нет строгой типизации.

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

<ИмяУзла ИмяАтр1=”значение” ИмяАтр2=”значение” ...> <!--вложенные теги и тексты--> </ИмяУзла> Пример:

<?xml version=”1.0”?>

<books>

<book isbn=”1558604669">

<title>Principles of Multimedia Database Systems</title> <authors><author>Subrahmanian</author></authors>

</book>

<book isbn=”1558603123”>

<title>Multimedia and Imaging Databases</title> <authors>

<author>Khoshafian</author>

<author>Baker</author>

</authors>

</book>

</books>

SQL Server и XML: Способы хранить XML-данных в БД: 1.Преобразование схемы (схем) XML-документов в схему базы данных. 2. Использование опр. набора структур, позволяющего хранить любой XML-документ.

Поддержка XML начиная с версии 2000

–FOR XML - извлечение результатов запросов к базам данных в виде XML-потока;

–OPENXML - сохранение XML-документов в базе данных (предназначена для обратных действий – создания записи, на основе переданного ей XML-документа)

Версия 2005

–Тип данных xml

–Поддержка проверки данных на уровне XSD-схемы

–Поддержка Xquery

Версия 2008

FOR XML - это атрибут команды SELECT, указывающий на то, что результаты выполнения запроса должны быть представлены в виде XML-потока:

– Запрос:

SELECT ProductID, ProductName FROM Products Product

FOR XML AUTO

– Результат - XML-документ:

<Product ProductID="1" ProductName="Widget"/>

<Product ProductID="2" ProductName="Sprocket"/>

XQuery

Язык запросов XML, разработан в W3C; первая версия - XQuery 1.0 в

2003г.

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

Совместим с другими XML-стандартами

Изначально был предназначен для извлечения информации и не включал средств для модификации существующих документов XML, XQuery аналог SQL для баз данных

XQuery поддерживается тремя главными производителями БД (IBM,

Oracle, Microsoft).

Пример: <html><head/><body>

{ for $act in doc("hamlet.xml")//ACT

let $speakers := distinct-values($act//SPEAKER) return

<span>

<h1>{ $act/TITLE/text() }</h1> <ul>

{ for $speaker in $speakers return <li>{ $speaker }</li> } </ul>

</span> } </body> </html>

5.1. Недостатки и ограничения реляционной модели. Постреляционные БД, примеры. Введение объектной модели в язык SQL3. Примеры SQL-запросов, содержащих объекты.

Недостатки и ограничения реляционной модели данных:

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

2.По определению в реляционной модели поля кортежа могут содержать только атомарные значения. Однако, в приложениях САПР, ГИС и системах ИИ должны проводиться операции со сложноструктурированными объектами.

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

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

Постреляционная модель, т.е. модель систем, относящихся к следующему поколению.

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

1.Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам

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

2.Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется, вплоть до самых базисных слоев системы.

3.Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами.

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

Введение объектной модели в язык SQL3:

Попытки совместить средства манипулирования данными реляционной модели и способы описания внешнего мира объектно-ориентированной модели получили развитие в языке SQL -3.

1.Характеристики объекта определяется описанием строки таблицы. Поэтому вводится специальная возможность описания нового типа данных:

Create type Address ( number char (6), street char (30), aptno integer,

city char (30), state char (2), zip integer );

2.На основе нового типа могут быть определены таблицы, например:

Create table Addresses of Address;

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

Сreate table People of new type Person ( name char (30),

address Address, birthdate date, );

4.Наследование определяется с помощью фразы under .

Create type Employee under Person ( empno char(10),

dept ref(Department) );

Здесь атрибут dept является ссылкой на объект, хранящийся в таблице Department . т.е. в понятиях реляционной модели в этом столбце должен быть записан внешний ключ, указывающий на одну из строк таблицы Department . В SQL-3 предполагается, что каждый объект имеет уникальный идентификатор - OID , именно он используется при создании ссылок на объекты.

Также в операторе CREATE TABLE можно определить и методы доступа к вновь созданным типам данных:

Create table People of new type Person ( name char(30),

address Address, birthdate date

function age(:р ref(Person)) return date; begin current_age:=:р.birthdate-current_date; return current _ age ;

end ; );

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

5.2. Идея ООБД. Преимущества и недостатки объектноориентированных баз данных. Стандарт ODMG: общие сведения.

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

Пример ОО СУБД ObjectStore которая обеспечивает долговременное хранение в базе данных объектов, созданных программами на языках

C++ и Java.

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

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

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

инкапсуляция, наследование, полиморфизм

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

(3)Средства манипулирования данными: отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из ОО-языков программирования общего назначения, обычно это

SmallTalk, C++ или Java.

Преимущества:

В ООБД, в отличие хранятся не записи, а объекты. ОО подход представляет более совершенные средства для отображения реального мира, чем реляционная модель:

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

-имеется возможность определения новых типов данных и операций с ними.

Недостатки:

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

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

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами:

1.Расширение ОО языков в сторону управления данными (стандарт

ODMG)

2.Добавление объектных свойств в реляционные СУБД (SQL 3, а также объектно реляционных СУБД).

Стандарт ODMG (Object Data Management Group) ODMG добавляет возможности взаимодействия с базами данных в ОО-языки программирования: определяются средства долговременного хранения объектов и расширяется семантика языка, вносятся операторы управления данными. Стандарт состоит из нескольких частей: Ключевые концепции объектной модели ODMG:

1.наделение объектов такими свойствами как атрибуты и связи

2.методы объектов (поведение)

3.множественное наследование

4.идентификаторы объектов (ключи)

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

6.блокировка объектов и изоляция доступа

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

Язык описания объектов (ODL - Object Defifnition Language) – средство определения схемы базы данных. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД.

Язык объектных запросов (OQL - Object Query Language) – SQL-

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

Язык манипулирования объектами (OML - Object Manipulation Language) расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программирования и доступа к данным.

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

Недостатки и ограничения реляционной модели.

A)Высокая приспособленность к реализации в СУБД, вследствие простоты структур.

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

C)Наличие универсального языка SQL, сочетающего функции ЯОД, ЯМД и ЯООД.

D)Возможность поддержки распределенных БД.

Недостатки модели связаны с отсутствием хранения явной информации о связях:

Отсюда следует:

A)Не всегда адекватное представление предметной области.

B)Невозможность явного определения ограничений на существование.

C)Неприспособленность модели для инфологического моделирования

D)Определенные трудности при создании запросов. Постреляционные базы данных, примеры.

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

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

Идея ООБД.

Общие понятия объектно-ориентированного подхода и их преломление в ООБД

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

Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения [6]. Это определяется потребностями долговременного хранения объектов во внешней памяти, ассоциативного доступа к объектам, обеспечения согласованного состояния ООБД в условиях мультидоступа и тому

подобных	возможностей,	свойственных	базам	данных [8].
В [6] выделяются три аспекта, отсутствующие в				традиционной

парадигме, но требующиеся в ООБД.

Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.) Второй аспект - потребность в механизме определения разного рода семантических связей между объектами вообще говоря разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использовании ООБД в сфере автоматизированного проектирования и инженерии [66]. Наконец, третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа и класса объектов.

Как мы отмечали во введении, в сообществе исследователей ООБД и разработчиков систем отсутствует полное согласие, но в большинстве

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

Преимущества, недостатки и особенности использования объектноориентированных баз данных.

Преимущества:

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

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

3.Для доступа к данным из СУООБД не обязателен отдельный язык запросов, поскольку доступ происходит непосредственно к объектам. Тем не менее, возможность использовать запросы существует.

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

Недостатки:

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

2.СУООБД обычно привязана к отдельному языку с помощью отдельного АПИ и данные доступны только через этот АПИ. СУРБД в этом плане имеет большие возможности, благодаря общему языку запросов.

3.В СУРБД, реляционная природа данных позволяет конструировать ad-hoc запросы, где можно объединять различные таблицы. В СУООБД невозможно дублировать семантику соединения двух таблиц соединением двух классов, поэтому в данном случае СУООБД уступает СУРБД в гибкости. Запросы, которые могут исполняться над данными в СУООБД, в большей мере зависят от дизайна системы.

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

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

.

6.2 Концепция и терминология анализа данных, суть OLAP. Алгоритмы и идеи Data Mining. Многомерное представление данных: куб данных, измерения, меры, срезы. Принципы разработки и использования информационных хранилищ данных.

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

–данные могут быть неточными, неполными (содержать пропуски), противоречивыми, разнородными, косвенными, и при этом иметь гигантские объёмы;

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

общие выводы на основе частных наблюдений;

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

Термин ИАД обозначает не столько конкретную технологию, сколько сам процесс поиска корреляций, тенденций, взаимосвязей и закономерностей

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

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

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

OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами

программных	решений	класса Business		Intelligence. Причина
использования	OLAP	для	обработки	запросов —	это

скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для

операционных	БД	(системы OLTP),	но сложные многотабличные
запросы в ней выполняются относительно медленно.
OLAP-структура, созданная из рабочих данных, называется OLAP-куб.
Куб создаётся	из	соединения	таблиц с применением схемы

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

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

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

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 20 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему количество возможных вариантов быстро достигает десятков миллионов и более.

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

Существуют три типа OLAP:[2]

-многомерная OLAP (Multidimensional OLAP —

MOLAP);

-реляционная OLAP (Relational OLAP — ROLAP);

-гибридная OLAP (Hybrid OLAP — HOLAP).

Алгоритмы и идеи Data Mining. Многомерное представление данных: куб данных, измерения, меры, срезы.

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

Преимущества использования кубов

Куб представляет собой единое место, где хранятся все связанные данные для анализа.

Компоненты кубов

Элемент — конкретное значение измерения.

Ячейка — результат расчёта фактов в разрезе измерений.

Измерение, или размерность — ось куба.

Срез (сечение) — результат преобразований куба данных путём манипулирования измерениями

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

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

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

Хранилище данных (англ. Data Warehouse) — предметно-

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

Принципы организации хранилища

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

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

Некорректируемость. Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются.

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

Источниками данных могут быть:

1.Традиционные системы регистрации операций

2.Отдельные документы

3.Наборы данных Операции с данными:

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

2.Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений. 3.Загрузка – помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих. 4.Анализ – OLAP, Data Mining, сводные отчёты.

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

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

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

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

Логическая структура данных хранилища данных отличается от структуры данных источников данных.

Для разработки эффективного процесса преобразования необходима хорошо проработанная модель корпоративных данных и модель технологии принятия решений.

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

Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные → информация → знания → полученные решения.

6.3Назначение Microsoft Analysis Services. Примеры организации запросов к многомерным данным на языке MDX. Создание приложения для анализа данных с использованием

возможностей SQL Server Data Tools.

Analysis Services включают в себя набор средств для работы с OLAP и интеллектуальным анализом данных. Microsoft Analysis Services (Службы анализа от Microsoft) - часть Microsoft SQL Server,

системы управлениябазами данных (СУБД). Microsoft включила набор служб в SQL Server, связанных с бизнес-анализом ихранением данных. Эти службы включают в себя службы интеграции (Integration Services) и

службы анализа (Analysis Services). Analysis Services в свою очередь включают в себя набор средств для работы с OLAP иинтеллектуальным анализом данных.

Примеры организации запросов к многомерным данным на языке

MDX.

Пусть наш куб содержит данные клиентов: ФИО, дату рождения, место рождения, пол, место жительства, а также календарь и список населенных пунктов. В случае реляционной базы данных можно было организовать 3 таблицы: [Населенные пункты], [Календарь] и [Паспортные данные]; причем в [Паспортных данных] присутствовали бы поля, связанные с соответствующими полями из [Календаря] и [Населенных пунктов]. В многомерном случае можно задать, например, такие измерения: [Клиенты], [Дата], [Место], [Тип места] (рождения или жительства), [Пол].

На пересечении этих измерений зададим некоторые агрегированные величины - меры. Например: [Количество клиентов], [Максимальный возраст].

Пример (*): Сколько клиентов мужского пола проживает в Твери? Ответ можно получить, задав следующий MDX-запрос:

SELECT { [Место].[РФ].[Тверь] } ON COLUMNS, { [Пол].[М] } ON ROWS

FROM [Наш куб данных]

WHERE ([Measures].[Количество клиентов] , [Тип места].[Место жительства])

В данном запросе присутствуют лишь 3 измерения: [Место], [Тип места] и [Пол]; все измерения, не указанные в запросе ([Клиенты] и [Дата]), присутствуют в нем неявно.

Следует отметить, что совокупность мер является, по сути, еще одним измерением.

Как видим, синтаксис MDХ очень похож на синтаксис SQL.