 |
Объектные, объектно-ориентированные и объектно-реляционные СУБД.
|
|
|
|
Сравнивая объектно-ориентированный и реляционный подходы к БД, можно отметить следующие особенности. В реляционных БД (РБД) реальные объекты представляются как структуры, состоящие из набора элементарных типов данных. Такое представление имеет понятную интерпретацию – строка в плоской таблице. В том случае, когда специфика предметной области позволяет работать с такого рода приближением реальных объектов, РБД отлично справляются со своей задачей. Довольно часто реляционная модель и ее способ описания предметной области в виде набора плоских таблиц не отражают внутренней структуры для многих предметных областей, являются искусственными и становятся совершенно непонятными при увеличении количества таблиц. Основная причина несостоятельности реляционного подхода заключается в слишком сильной абстракции реального объекта, что ведет к потере семантики.
В отличие от реляционных баз данных объектно-ориентированные базы данных обладают простой и естественной связью с предметной областью, представляя ее структуру и состав, что облегчает проектирование и положительно сказывается на понимании принципов функционирования программ. Так, в сложных неоднородных предметных областях использование ООБД (в частности, там, где разные объекты имеют разные методы) должно действительно упростить процесс проектирования и разработки.
К сожалению, в ООБД существуют свои проблемы. В ООБД отсутствует универсальная модель данных, и соответственно, отсутствует мощная математическая база, как, например, в реляционной модели. В связи с этим у ООБД нет языка запросов высокого уровня, аналогичного 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-технологии и СУБД.
Сегодня большинство информационных систем в той или иной степени используют базы данных. Не составляют исключение и системы, основанные на веб-технологиях. Поэтому организация взаимодействия веб-приложений с СУБД является неотъемлемой составной частью веб-технологий.
До начал 90-х годов существовало несколько разных поставщиков баз данных, каждый из которых имел собственный интерфейс. Если приложению было необходимо обмениваться данными с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать отдельный код. С целью решения этой проблемы Майкрософт и ряд других компаний создали стандартный интерфейс для получения и отправки данных источникам данных различных типов. Этот интерфейс получил название open database connectivity (ODBC).
C помощью ODBC прикладные программисты смогли разрабатывать приложения с использованием единого интерфейса доступа к данным, не учитывая тонкости взаимодействия с различными источниками данных. Это достигается благодаря тому, что поставщики различных баз данных разрабатывают драйверы, учитывающие специфику конкретных источников данных при реализации стандартных функций из ODBC API. При этом приложения используют функции такого API, реализованные в соответствующем конкретному источнику данных драйвере.
По-сути, интерфейс ODBC является обычным процедурным API. ODBC поддерживается большим количеством операционных систем.
Имеются также ODBC-драйверы и для нереляционных данных, таких как электронные таблицы, текст и XML файлы.
Типичный сценарий работы веб-приложения с источником данных выглядит следующим образом:
1. Установление соединение и подключение к источнику данных.
2. Выполнение запросов, необходимых для выборки, вставки или изменения наборов данных источника.
|
|
|
3. Отключение от источника данных.
Компанией Майкрософт был предложен интерфейс программирования приложений для доступа к данным, разработанный и основанный на технологии компонентов 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 очень гибкой и расширяемой.
Хранилища данных.
Хранилища данных – это процесс сбора, отсеивания и предварительной обработки данных с целью представления результирующей информации пользователям для статистического анализа и аналитических отчетов. Ральф Кинболл (автор концепции хранилищ данных) описывал хранилища данных как «место, где люди могут получить доступ к своим данным». Он же сформулировал основные требования к хранилищам данных:
– поддержка высокой скорости данных из хранилища;
– поддержка внутренней непротиворечивости данных;
– возможность получения и сравнения данных;
– наличие удобных утилит просмотра данных хранилища;
– полнота и достоверность хранимых данных;
– поддержка качественного процесса пополнения данных.
|
|
|
Всем перечисленным требованиям удовлетворять зачастую не удается, поэтому для реализации хранилищ данных используют несколько продуктов. Одни из которых представляют средства хранения данных, другие – средства их извлечения и просмотра, в-третьих – средства пополнения хранилищ данных. Типичное хранилище данных как правило отличается от реляционной базы данных: 1) Обычная база данных предназначена для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений; 2) Обычная база данных подвержена постоянным изменениям в процессе работы пользователей, а хранилища данных относительно стабильно; данные в нем обновляются согласно расписанию (например, ежечасно, ежедневно, ежемесячно), в идеале, процесс пополнения данными за определенный период времени без изменения прежней информации находящейся уже в хранилище. 3) Обычная база данных чаще всего является источником данных попадающих в хранилище, кроме того хранилище может пополняться за счет внешних источников (например, сжатия данных).
Принципы построения
Информация, которая загружается в хранилище, должна интегрироваться в целостную структуру, отвечающую целям анализа данных. При этом минимизируются несоответствия между данными из различных оперативных систем, в хранилище именуются и выражаются единым образом. Данные интегрированы на множестве уровней: на уровне ключа, атрибута, на описательном, структурном уровне и так далее. Общие данные и общая обработка данных консолидированы и являются единообразным для всех данных, которые подобны или схожи в хранилище данных. При этом информация структурируется по разным уровням детализации:
– высокая степень суммаризации;
– низкая степень суммаризации;
– текущая детальная информация.
Хранилища можно рассматривать как набор моментальных снимков состояния данных: можно восстановить картинку на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища.
Попав однажды в хранилище, данные уже никогда не изменяются, а только пополняются новыми данными из оперативных систем, где данные постоянно меняются. Новые данные по мере поступления обобщаются с уже накопленной информацией в хранилище данных.
|
|
|
