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

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

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

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

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

Недостатки:

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

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

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

 

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

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

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. Представление результатов анализа.

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

Задача словаря метаданных состоит в том, чтобы освободить разработчика от необходимости стандартизировать источники данных.

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

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

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

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

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

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

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

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.