Понятие хранилища данных. Отличия хд от БД.

Сегодня наиболее очевидными недостатками реляционных баз данных являются:

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

Чтобы избежать этих недостатков, специалисты стали использовать методику конструирования базы, при которой данные, предназначенные для аналитической обработки, хранятся в отдельных базах. Так возникло понятие хранилища данных (Data warehouses), а соответствующий метод конструирования стал называться многомерной моделью. Процесс работы с хранилищами данных – это сбор, отсеивание и обработка данных для предоставления результирующей информации пользователям при анализе и создании ими аналитических отчетов.

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

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

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

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

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

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

Хранилище данных отличается от обычной реляционной базы данных по ряду характеристик.

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

Во-вторых, реляционные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилища данных относительно стабильны: данные в них обычно обновляются согласно расписанию: либо ежедневно либо ежемесячно, либо ежегодно – в зависимости от назначения хранилища. Процесс пополнения обычно представляет собой добавление новых данных за определенный период времени без изменения прежней информации, находящейся в хранилище.

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

Сущность технологии OLAP.

Ключевой компонентой организации хранилищ данных является т ехнология OLAP (On Line Analytical Processing) – технология комплексного многомерного анализа данных. OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах.

Концепция OLAP-технологии была описана в 1993 году Эдгаром Коддом, автором реляционной модели данных. В 1995 году на основе требований, изложенных Э. Коддом, был сформулирован тест FASMI (Fast Analysis of Shared Multidimensional Information) – быстрый анализ разделяемой многомерной информации. Этот тест включает следующие требования к приложениям для многомерного анализа:

• многомерное концептуальное представление данных, включая полную поддержку иерархий и множественных иерархий (это – ключевое требование OLAP);
• возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
• многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
• возможность обращаться к любой нужной информации независимо от ее объема и места хранения;
• предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 секунд), пусть даже ценой менее детального анализа.

Подводя итоги, можно сказать следующее.

1. Назначение хранилищ данных – это предоставление пользователям информации для статистического анализа и принятия управленческих решений.

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

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

Основные понятия объектно-ориентированных СУБД.

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

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

Объект – это отражение сущности реального мира средствами СУБД. Каждый объект имеет уникальное имя (идентификатор) и два аспекта: состояние и поведение объекта. Состояние объекта – это набор значений его атрибутов. Так, например, объект файл может находиться в состоянии «открыт» и «закрыт». Поведение объекта – это набор методов, т.е. программ, оперирующих над состоянием объекта. Например, изменить поведение – это выполнить операции «открыть» и «закрыть» файл. Другими словами, термин «объект» означает комбинацию данных и программы, представляющую некоторую сущность реального мира. Данные состоят из компонентов произвольного типа, которые принято называть атрибутами. А каждая программа называется методом.

Объект называется сложным, если он содержит вложенные в него объекты. Например, объект «адрес» может характеризоваться набором атрибутов: улица, город, область, почтовый индекс, – а объект «сотрудник» атрибутами: ФИО, адрес, должность, размер зарплаты. В реляционных базах данных любой объект – простой, а в объектных – может быть сложным. Главной характерной чертой объектно-ориентированных баз данных является способность хранить информацию о сложных объектах с исчерпывающим описанием взаимосвязи между ними и их динамического поведения.

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

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

Каждому объекту присущи следующие основные свойства:

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

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

3. Инкапсуляция– объекты наделяются некоторой структурой и обладают некоторым набором операций, т.е. поведением. Внутренняя структура объекта скрыта от пользователя. Манипуляция объектом, изменение его состояния возможно лишь посредством его методов. Таким образом, благодаря инкапсуляции объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира. Другими словами, инкапсуляция – это способ доступа к данным только через свойства и методы.

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

5. Расширяемость, то есть возможность добавлять в базу данных новые объекты и связанные с ними правила поведения данных, не вступая в конфликт с имеющимися объектами и приложениями.

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

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

В 90-ых годах ХХ века создавали экспериментальные образцы объектных СУБД. Сегодня такие системы уже более распространены: это Poet (Poet Software), Jasmin (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (научно-производственный центр "Интеллект Плюс"), Iris, Orion, Postgres и др.

Сегодня поддерживается два направления развития объектных СУБД: объектно-ориентированные и объектно-реляционные.

Можно отметить следующие отличия реляционных СУБД от объектных.

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

2. Язык описания объектов унифицирован с базовым языком программирования, например: C++, Smalltalk, Java, – в отличие от реляционных, где прикладные программы пишутся на универсальном языке программирования, а встроенные в приложения функции управления базой данных – на языке базы данных.

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

4. Объектная база не требует модификаций ядра при добавлении нового типа данных.