ОтветыБД
.pdf<ИмяУзла ИмяАтр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.