Эволюция СУБД

Эволюция  СУБД

     Управление  информацией всегда было основной сферой применения компьютеров и, надо думать, будет играть еще большую роль в будущем. Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами.  
            История развития компьютерной техники – это история непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. Если первые машины требовали от пользователя оформления того, что ему нужно (то есть написания программ), в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяли конечным пользователям, не являющимся профессиональными программистами, получать доступ к информации без детального описания каждого шага, но только с встроенными предопределенными типами данных – например, таблицами. 
Последним шагом в этом направлении стала объектно-ориентированная  
технология,радикально изменившая сферу разработки программного обеспечения уже в 1990-х годах.

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

     Обьектно-ориентированные  СУБД (ООСУБД) стали разрабатываться  в основном для поддержки приложений САПР. Сложные структуры данных систем автоматизированного проектирования оказалось очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки”результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР.

     Между тем рынок САПР был быстро насыщен, и в начале 90-х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator – DBA), средствами резервногокопирования/восстановления и т. д.

     Эпоха объектно-реляционных баз данных началась в декабре 1996 года в компании Informix, которая выпустила объектно-реляционную систему управления базами данных (ОРСУБД) Informix Universal Server. Вслед за ней в 1997 г. на рынке появились ОРСУБД компаний Oracle (Oracle8) и IBM (DB2 Universal Database). В течение примерно трех лет новая технология интенсивно обсуждалась. Многим в то время казалось, что ОРСУБД в корне изменят способы проектирования и разработки приложений баз данных. Однако постепенно шум вокруг ОРСУБД затих. До конца 1990-х гг. Informix, Oracle и IBM совершенствовали свои ОРСУБД. В 1999 г. появился стандарт SQL:1999, в котором были зафиксированы объектные расширения языка SQL. И, наконец, после выхода в 2003 г. стандарта SQL:2003, уточнившего и дополнившего SQL:1999, в сообществе баз данных окончательно перестали обсуждать объектно-реляционную технологию баз данных.

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

Объектно-ориентированная  БД (преимущества)

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

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

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

ООСУБД  подходят для организации распределенных вычислений Традиционные базы данных (в том числе и реляционные  и некоторые объектные) построены  вокруг центрального сервера, выполняющего все операции над базой. По существу, эта модель мало отличается от мэйнфреймовой организации 60 х годов с центральной ЭВМ – мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных терминалов. Такая архитектура имеет ряд недостатков, главным из которых является вопрос масштабируемости. В настоящее время рабочие станции (клиенты) имеют вычислительную мощность порядка 30 50 % мощности сервера базы данных, то есть большая часть вычислительных ресурсов распределена среди клиентов. Поэтому все больше приложений, и в первую очередь базы данных и средства принятия решений, работают в распределенных средах, в которых объекты (объектные программные компоненты) распределены по многим рабочим станциям и серверам и где любой пользователь может получить доступ к любому объекту. Благодаря стандартам межкомпонентного взаимодействия (об этом позже) все эти фрагменты кода комбинируются друг с другом независимо от аппаратного, программного обеспечения, операционных систем, сетей, компиляторов, языков программирования, различных средств организации запросов и формирования отчетов и динамически изменяются при манипулировании объектами без потери работоспособности.

Объектно-ориентированная  СУБД (недостатки) 

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

1. Отсутствие всеобъемлющей унифицированной теории. Преимущество реляционных баз данных заключается в наличии достаточно четкого определения понятия реляционный. Объектно-ориентированные базы данных, которые, по сути, являются адаптацией соответствующей парадигмы программирования, не имеют четкого определения, что позволяет разработчикам трактовать их по-своему. Это приводит к путанице в сфере терминологии. Пользователи объектно-ориентированных баз данных часто вынуждены вникать в совершенно новые понятия при переходе к новой системе. Взаимодействие баз данных представляет для объектно-ориентированных систем большую проблему.
2. Отсутствие такой формально определенной методологии проектирования баз данных, как нормализация. Недостаток рекомендаций проектировщикам относительно оптимизации разработки объектно-ориентированной системы может привести к тому, что полученные системы будут совершенно неэффективны.
3. Отсутствие специальных средств создания запросов. Доступ к объектам возможен только посредством предварительно определенных методов. Если не существует метода, позволяющего построить нужное множество данных, "рядовой" пользователь не может получить доступ к множеству данных, даже если соответствующие данные существуют внутри объектов базы данных;
4. Отсутствие общих правил обеспечения целостности;

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

Объектно-реляционная  БД (преимущества)

     Так что же такое ОРСУБД? Что такое  объектно-реляционная база данных? Если не зафиксировать какое-либо конкретное понимание этих терминов, то, очевидно, рассуждения на их тему становятся бессмысленными. Заметим, что банальное житейское толкование термина ОРСУБД как традиционной реляционной СУБД, расширенной основными объектными возможностями, является опасно упрощенным и искажающим действительность. Во-первых, имеющиеся сегодня на рынке ОРСУБД не являются «традиционными реляционными», поскольку в них не поддерживается реляционная модель данных. Они основаны на другой модели данных, представленной в стандарте языка SQL. Во-вторых, объектный мир определен в целом настолько расплывчато и нечетко, что невозможно однозначно говорить об основных объектных возможностях.

     Поэтому в данной статье я не буду пытаться приводить сжатые дефиниции ОРСУБД. С моей точки зрения, сегодня под ОРСУБД следует понимать системы, которые следуют духу Манифеста систем баз данных третьего поколения и букве стандартов SQL:1999 и SQL:2003. 

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

     Объектно-реляционная  система управления базами данных обладает следующими достоинствами: 

1. Типы, операторы  и методы доступа, определяемые пользователем.
2. Поддержка сложных объектов, представляющих собой наборы других объектов.
3. Перегрузка операторов манипулирования данными.
4. Создание функций, определяемых пользователем.
5. Динамическое (т.е. без прерывания работы СУБД) добавление новых типов данных, операторов, функций и методов доступа. Описание всех этих возможностей создается на языке C и компилируется в объектный файл, который может динамически загружаться сервером СУБД.
6. Наследование данных и функций.
7. Использование массивов как значений полей кортежей.

Объектно-реляционная  СУБД (недостатки)

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

1. Диапазон семантики. Реляционная теория поддерживает лишь весьма ограниченный набор семантических понятий. Поддержка многих важных семантических понятий в реляционных моделях вовсе отсутствует. Это означает, что широкий диапазон типов информации невозможно осмысленным образом представить в реляционной базе данных.
2. Структуры данных. Реляционные системы очень ограничены в том, что касается структур данных. Все данные в них хранятся в отношениях, состоящих из простых атрибутов. Существует много разнообразной информации, которую невозможно удовлетворительно представить таким способом.
3. Пассивность данных. Данные в реляционной системе в основном пассивны. Чтобы описать поведение данных, необходимы прикладные программы. В объектно-ориентированной базе данных можно хранить как структуру, так и поведенческие аспекты данных.
4. Отсутствие семантической целостности. Ее можно определить как сохранение и согласованность семантики базы данных в различных приложениях. В реляционной системе поведение данных определяется способом их использования в прикладных программах.