Объектные, объектно-ориентированные и объектно-реляционные субд.
Сравнивая объектно-ориентированный и реляционный подходы к БД, можно отметить следующие особенности. В реляционных БД (РБД) реальные объекты представляются как структуры, состоящие из набора элементарных типов данных. Такое представление имеет понятную интерпретацию – строка в плоской таблице. В том случае, когда специфика предметной области позволяет работать с такого рода приближением реальных объектов, РБД отлично справляются со своей задачей. Довольно часто реляционная модель и ее способ описания предметной области в виде набора плоских таблиц не отражают внутренней структуры для многих предметных областей, являются искусственными и становятся совершенно непонятными при увеличении количества таблиц. Основная причина несостоятельности реляционного подхода заключается в слишком сильной абстракции реального объекта, что ведет к потере семантики.
В отличие от реляционных баз данных объектно-ориентированные базы данных обладают простой и естественной связью с предметной областью, представляя ее структуру и состав, что облегчает проектирование и положительно сказывается на понимании принципов функционирования программ. Так, в сложных неоднородных предметных областях использование ООБД (в частности, там, где разные объекты имеют разные методы) должно действительно упростить процесс проектирования и разработки.
К сожалению, в ООБД существуют свои проблемы. В ООБД отсутствует универсальная модель данных, и соответственно, отсутствует мощная математическая база, как, например, в реляционной модели. В связи с этим у ООБД нет языка запросов высокого уровня, аналогичного SQL, и при доступе к данным используется мало эффективный навигационный подход. ООСУБД отличаются от реляционных СУБД тем, что программный интерфейс создания приложения либо очень слаб, либо вообще отсутствует. Это означает, для написании приложения, работающего с ООБД не существует мастеров и конструкторов (не считая, например, конструктора создания списка полей в объекте, который поставляется вместе с ООСУБД ObjectStore). Поэтому разработчик создает приложения на одном из алгоритмических языков.
По нашему мнению, существенным ограничением развития объектно-ориентированного подхода к созданию баз данных является то, что методы объекта содержатся внутри объекта и неразрывно связаны с ним. Это делает, по сути, невозможным создание для объектно-ориентированной базы данных соответствующей системы управления базой данных в традиционном понимании СУБД, функциями которой, в частности, является реализация операций обработки данных. Поэтому ООСУБД часто является не системой управления базами данных, а библиотекой программ, с помощью которой можно построить объектно-ориентированную базу данных. Примером такой библиотеки является ООСУБД ObjectStore. В связи с этим, возникает проблема реализации непредвиденных запросов.
Для перехода к объектно-ориентированным БД стандарт объектного программирования был дополнен стандартизованными средствами доступа к базам данных (стандарт ODMG 93; Object Database Management Group – группа управления объектно-ориентированными базами данных). К настоящему времени этот стандарт не реализован. Состояние проблемы подробно описано также в работах [[26], [4], [2], [18], [3] и др.]. Отметим только, что ООБД используются, но пока не стали реальной альтернативой реляционным базам данных.
Объектно-ориентированные возможности появляются в ведущих современных СУБД, таких, как, например, Oracle. Предпринимаются попытки внесения изменений в стандарты языка SQL с целью его частичной адаптации к ООБД. Так, новый стандарт SQL-3 включает большой раздел, посвященный этому вопросу.
Объектно-реляционные СУБД
В настоящее время реляционные СУБД доминируют среди систем управления данными. Преимущества объектно-ориентированного подхода для создания сложных специализированных приложений с одной стороны, и стремление разработчиков систем управления базами данных с другой стороны расширить границы применения соответствующих СУБД обусловили включение объектно-ориентированных компонент (расширяемая пользователем система типов, инкапсуляция, наследование, полиморфизм и т. п.) в модель данных реляционной СУБД. Соответствующие СУБД, называемые объектно-реляционными, соединяют в себе лучшие качества реляционных и объектно-ориентированных баз данных. Отметим, что в разных СУБД реализован разный набор из перечисленных объектно-ориентированных компонент. Таким образом, не существует общепринятой объектно-реляционной модели, а скорее имеется несколько таких моделей, поддерживающих определенный набор объектно-ориентированных компонент. Однако, основой всех таких моделей являются реляционные таблицы, используется язык запросов, включено понятие объекта, а в некоторых дополнительно реализована возможность сохранения методов в базе данных.
Соответствующие изменения реляционной модели обусловили необходимость расширения стандарта языка запросов SQL. Первый вариант такого стандарта получил название SQL3. Работа над стандартом продолжается и в настоящее время.
В качестве примера в максимальной степени объектно-ориентированной СУБД можно указать исследовательскую СУБД Postgres [[4]].
Отметим считающиеся объектными расширениями элементы СУБД Microsoft Server 2008.
Пользовательские расширения. Пользователи имеют возможность вмешиваться в изначально предоставляемый СУБД инструментарий, создавая, в частности, новые пользовательские типы данных.
Хранение больших объемов данных. Наряду с теми данными, которые хранились в БД традиционно, Microsoft SQL Server 2008 позволяет хранить в столбцах таблицы данные больших размеров (поддерживаются соответствующие типы данных).
Новые, ориентированные на определенные классы объектов, типы данных. В системе определены новые типы данных (geometry, geography), характерные для тех направлений, в которых объектно-ориентированный подход весьма эффективен и часто используется (картография и соответствующие приложения, геометрическое представление объектов самойразнойприроды)Web-технологии и СУБД.
Хранилища данных.
Хранилище данных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы.
Принципы организации хранилища
Проблемно-предметная ориентация. Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.
Интегрированность. Данные объединены так, чтобы они удовлетворяли всем требованиям предприятия в целом, а не единственной функции бизнеса.
Некорректируемость. Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются.
Зависимость от времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени
Дизайн хранилищ данных
Существуют два архитектурных направления – нормализованные хранилища данных и хранилища с измерениями.
В нормализованных хранилищах, данные находятся в предметно ориентированных таблицах третьей нормальной формы. Нормализованные хранилища характеризуются как простые в создании и управлении, недостатки нормализованных хранилищ – большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы.
Хранилища с измерениями используют схему «звезда» или схему «снежинка». При этом в центре «звезды» находятся данные (Таблица фактов), а измерения образуют лучи звезды. Различные таблицы фактов совместно используют таблицы измерений, что значительно облегчает операции объединения данных из нескольких предметных таблиц фактов (Пример – факты продаж и поставок товара). Таблицы данных и соответствующие измерениями образуют архитектуру «шина». Измерения часто создаются в третьей нормальной форме, в том числе, для протоколирования изменения в измерениях. Основным достоинством хранилищ с измерениями является простота и понятность для разработчиков и пользователей, также, благодаря более эффективному хранению данных и формализованным измерениям, облегчается и ускоряется доступ к данным, особенно при сложных анализах. Основным недостатком является более сложные процедуры подготовки и загрузки данных, а также управление и изменение измерений данных.
Процессы работы с данными
Источниками данных могут быть:
Традиционные системы регистрации операций
Отдельные документы
Наборы данных
Операции с данными:
Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.
Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.
Загрузка – помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих.
Анализ – OLAP, Data Mining, сводные отчёты.
Представление результатов анализа.
Вся эта информация используется в словаре метаданных. В словарь метаданных автоматически включаются словари источников данных. Здесь же форматы данных для их последующего согласования, периодичность пополнения данных, согласованность во времени.
Задача словаря метаданных состоит в том, чтобы освободить разработчика от необходимости стандартизировать источники данных.
Создание хранилищ данных не должно противоречить действующим системам сбора и обработки информации.
Специальные компоненты словарей должны обеспечивать своевременное извлечение из словарей и обеспечить преобразование к единому формату на основе словаря метаданных.
Логическая структура данных хранилища данных отличается от структуры данных источников данных.
Для разработки эффективного процесса преобразования необходима хорошо проработанная модель корпоративных данных и модель технологии принятия решений.
Данные для пользователя удобно представлять в многоразмерных БД, где в качестве измерения могут выступать время, цена или географический регион.
Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.
С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные → информация → знания → полученные решения.
Web-технологии и СУБД.
Сегодня большинство информационных систем в той или иной степени используют базы данных. Не составляют исключение и системы, основанные на веб-технологиях. Поэтому организация взаимодействия веб-приложений с СУБД является неотъемлемой составной частью веб-технологий.
До начал 90-х годов существовало несколько разных поставщиков баз данных, каждый из которых имел собственный интерфейс. Если приложению было необходимо обмениваться данными с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать отдельный код. С целью решения этой проблемы Майкрософт и ряд других компаний создали стандартный интерфейс для получения и отправки данных источникам данных различных типов. Этот интерфейс получил название open database connectivity ( ODBC ).
C помощью ODBC прикладные программисты смогли разрабатывать приложения с использованием единого интерфейса доступа к данным, не учитывая тонкости взаимодействия с различными источниками данных. Это достигается благодаря тому, что поставщики различных баз данных разрабатывают драйверы, учитывающие специфику конкретных источников данных при реализации стандартных функций из ODBC API. При этом приложения используют функции такого API, реализованные в соответствующем конкретному источнику данных драйвере.
По-сути, интерфейс ODBC является обычным процедурным API. ODBC поддерживается большим количеством операционных систем.
Имеются также ODBC-драйверы и для нереляционных данных, таких как электронные таблицы, текст и XML файлы.
Типичный сценарий работы веб-приложения с источником данных выглядит следующим образом:
Установление соединение и подключение к источнику данных.
Выполнение запросов, необходимых для выборки, вставки или изменения наборов данных источника.
Отключение от источника данных.
Компанией Майкрософт был предложен интерфейс программирования приложений для доступа к данным, разработанный и основанный на технологии компонентов ActiveX - ADO (ActiveX Data Objects), который позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде. Компоненты ADO нашли применятся при разработке приложений на таких языках как VBScript в ASP и Visual Basic.
В рамках Microsoft .NET основной моделью доступа приложений к источникам данных является ADO.NET. Она не является развитием ADO и представляет собой совершенно самостоятельную технологию.Компоненты ADO .NET входят в поставку .NET Framework .
ADO.NET включает в себя две основные части:
Dataprovider - набор классов для доступа к источникам данных. Каждый из источников данных имеет свой собственный набор объектов, однако все они имеют общее множество классов: Connection, Command, Parameter, DataAdapter, DataReader.
DataSets объекты - группа классов, описывающих простые реляционные базы данных, размещаемы в памяти. Содержит иерархию таких классов как: DataTable, DataView, DataColumn, DataRow, DataRowView, DataRelation, Constraint.
Объект DataSet заполняется данными из БД с помощью объекта DataAdapter, у которого заданы свойства Connection и Command. DataSet может сохранять свое содержимое также в XML (опционально вместе с XSD схемой) или получать данные из XML.
ADO.NET поддерживает работу с отсоединенными наборами данных, что крайне важно при использовании масштабируемых веб-приложений. Такая возможность реализуется с помощью класса DataSet совместно с классом DataAdapter.
Одной из важнейших составляющих технологии ADO.NET является поставщик данных. По-сути, это набор классов, предназначенных для взаимодействия с источником данных определенного типа. Использование разных поставщиков данных делает ADO.NET очень гибкой и расширяемой.