УДК 004.2
Рословцев В.В.
БУДУЩЕЕ СИСТЕМ БАЗ ДАННЫХ: РЕТРОСПЕКТИВА И ПЕРСПЕКТИВА
Национальный исследовательский ядерный университет
«Московский инженерно-физический институт»
Предпринимается попытка анализа актуальных проблем в области систем баз данных. Предлагается ретроспективный анализ некоторых проблем и тенденций, кратко обрисовываются основные этапы развития баз данных и их связь с разработкой прикладных программных систем. Результаты анализа перспектив развития систем баз данных предлагаются в сжатом виде, в форме перечня некоторых из числа наиболее общих характеристик.
Ключевые слова: базы данных, системы управления базами данных
Some pressing problems and tendencies in the field of database research are subject to a retrospective analysis in the present work. Some basic stages in database management system evolution are outlined, their connection with applied program systems development being in consideration. Database systems development perspectives analysis is provided, and its results are outlined briefly in form of a list of some most important characteristics.
Key words: data bases, database management systems
В нашем мире многое, если не все, развивается спирали. Процессы или явления периодически приобретают формы, сходные с теми, которые они имели когда-то в прошлом, но внутреннее наполнение качественно иное. Системы баз данных начинались с сетевых и иерархических моделей, которые, как считалось, отражали структуру связей между элементами предметной области, а также допускали эффективную, с точки зрения использования памяти, реализацию на основе указателей.
Иерархическая модель данных. В основе иерархической модели лежит представление объектов данных и метаданных в виде древовидной структуры, в которой типы объектов данных представляются узлами, а дуги отражают имеющиеся между ними связи дочерне-родительского типа. Узлы можно рассматривать как формы [1], снабженные заголовками: именами подформ (иерархических групп) и именами полей. Записями в форме являются значения данных, расположенные под соответствующими заголовками. Связи между формами (стрелки) можно представить одним из двух способов: поместив связывающие данные либо одну или обе связанные формы, либо в отдельную, третью, специально создаваемую форму.
Основные операции над формами следующие: занесение результатов (некоторой указанной) операции в форму; выделение, выборка части формы, отвечающей заданному логическому условию; получение выборки вдоль одного иерархического пути; соединение нескольких форм в одну, и др.
Сетевая модель данных. Основная конструкция сетевой модели (см. [1]) – набор (множество). Отдельные записи (одного типа) могут группироваться в наборы. Наборы представляются в сетевой модели (помеченными) узлами, соединенными друг с другом (направленными) стрелками, представляющими различные связи. Сетевую модель можно рассматривать как расширение иерархической, при котором у записи-потомка может быть более одной записи-предка (в иерархической модели допускается только один предок).
Сетевая модель позволяет естественным образом выражать не только (многоуровневые) иерархии объектов, но и более сложные структуры, в частности циклические (систему из нескольких циклов). Техника построения сетей требует введения типа связующей записи («соотношение») для образования связей между типами записей, представляющими сущности, которые становятся «владельцами» «соотношения». Характерной задачей, для которых очень хорошо подходят сетевые модели, является задача представления информации о деталях и узлах, причем узлы могут полностью входить в состав некоторых деталей.
К началу 1970-х гг. основная часть СУБД основывалась на иерархической или сетевой модели данных. Однако эти системы обладали качественными недостатками: низкоуровневый процедурный способ взаимодействия, зависимость пользовательских программ от используемых физических структур данных (в частности, это относится к сортировке, индексированию и «пути доступа» – access path), избыточность данных, трудности, связанные с внесением изменений в модель объектов данных и метаданных и др.
Реляционная модель данных. Для преодоления этих проблем Э. Кодд предложил реляционную модель [2]. Ее преимущество, по сравнению с иерархической и сетевой моделями, виделось в независимости данных (точнее, независимости их логической модели от их физического представления), а также в том, что реляционная модель предоставляет хороший базис для определения выводимости, избыточности и непротиворечивости отношений.
Основным понятием реляционной модели является отношение – подмножество декартова произведения доменов, на которых это отношение определено, причем: а) элементами отношения являются (однотипные) кортежи; б) порядок следования кортежей при их перечислении несущественен; в) все кортежи различны; г) порядок перечисления элементов в каждом кортеже, а также порядок перечисления доменов, на которых отношение определено, является существенным, но это отчасти преодолимо посредством оснащения отношений именной структурой.
Существенно, что в качестве элементов кортежей допускаются только атомарные сущности (т.н. первая нормальная форма [2]). Смысл, вкладываемый Э. Коддом в термин «база данных», заключается в идее выявления некоторого (предпочтительно, минимального) «базиса» хранимых отношений, из которого, при заранее фиксированном наборе средств «комбинирования» [3] отношений, можно выразить всю необходимую информацию. Э. Кодд приводит [4] следующие доводы в пользу дальнейшей нормализации: 1) снижение числа зависимостей при операциях вставки, изменения и удаления; 2) снижение необходимости внесения изменений в структуру хранимых отношений при внесении новых типов данных, тем самым, снижая затраты на поддержку прикладного ПО; 3) повышение информативности реляционной модели для пользователя; и 4) придание независимости набору хранимых отношений от частоты выполнения тех или иных конкретных запросов, в условиях, когда эта частота меняется со временем. Это включает избавление от определенных типов избыточности и упрощение применения ограничений целостности в ряде ситуаций.
Предложенная теория, однако, не охватывала семантику этих связей между объектами предметной области. И сущности предметной области, и связи между ними (во всяком случае, связи некоторых типов) представляются в виде отношений, и нет формальных средств, позволяющих их различать. Позднейшие работы, например, работа [5], в которых предпринималась попытка преодолеть эту и другие проблемы, были восприняты лишь отчасти.
Существование реляционных СУБД начиналось с таких прототипов, как System R [6]. Это была система, реализующая основную часть реляционной модели, хотя и с отклонениями, и предлагавшая пользователю "Реляционный интерфейс данных" (Relational Data Interface, RDI) – высокоуровневые, независимые от данных (data-independent) средства для извлечения (retieval), определения (definition), манипулирования (manipulation) и контроля (control) данных. Предоставляемый системой язык взаимодействия с ней (покрывающий все четыре перечисленных аспекта) во многом напоминает современный SQL. Как часть средств контроля данных, система предоставляла возможность управления транзакциями (в виде, несколько отличном от принятого ныне), а также триггеры, позволявшие исполнять произвольные Sequel-выражения при возникновении определенных событий – например, таких как вставка, удаление или изменение записей в определенной таблице. Это было одной из первых реализаций концепции, которая впоследствии получила название «активные системы баз данных». Существенным следует считать то, что СУБД предоставляла средства взаимодействия с ней из других программ.
Следующий виток развития: вычислительные возможности. СУБД позволяли хранить данные и управлять ими, но все алгоритмы их обработки выносились на пределы СУБД во внешнее программное обеспечение. Перспективным путем решения этих проблем виделась концепция активных баз данных. Период наиболее интенсивных исследований в этом направлении относится к концу 1980-х и 1990-м гг. (см., например, [7,8,9], а также библиографию [7]). Объектом исследования были правила, обычно называемые триггерами, которые представляли собой некоторое действие, которое должно было выполняться СУБД при возникновении определенного события (например, вставка записи в таблицу) и при выполнении определенного заданного условия. В различных работах предлагались средства различной выразительной силы для описания событий, условий и собственно действий. Кроме того, предлагаемые решения имели более или менее значительные различия в семантическом аспекте. Некоторый анализ этих различий приводится в работах [7,9].
До некоторой степени, справедливым будет рассматривать появление хранимых процедур и функций как развитие идеи активных баз данных и применение принципа инкапсуляции к базам данных, когда данные и алгоритмы их обработки в виде хранимых процедур и функций стали хранится вместе. Однако, в реляционных системах хранимые процедуры и функции не стали полноправными объектами, чаще – некоторым расширением соответствующего языка. Кроме того, триггеры, как правило, тоже являются не объектами данных, а объектами метаданных, частью «схемы» базы данных.
До некоторой степени этот разрыв между программами и данными преодолевается за счет возможности передачи на исполнение произвольной строки, так что элементы программного кода можно хранить в виде строковых значений в таблицах.
Необходимо отметить, что в настоящее время на практике применения триггеров стараются избегать, их применяют лишь в исключительных случаях. Мотивация, стоящая за таким подходом, заключается в а) сложности семантики вызова и исполнения триггеров (в частности, исполнение одного триггера может привести к срабатыванию другого) и б) неявности триггеров. Последнее соображение заключается в том, что триггеры представляют собой побочный эффект операций над таблицей и ее записями. Если же с операциями над записями какой-либо таблицы должна быть связана какая-либо дополнительная логика, ее реализуют в виде хранимых процедур, и принимают соглашения, что все действия с записями данной таблицы должны выполняться только через вызов этих хранимых процедур (принцип инкапсуляции, в применении к реляционным базам данных, реализуемый за счет соглашения).
Объектно-ориентированные базы данных. Идея применить принципы объектно-ориентированного программирования, в частности, инкапсуляцию, к базам данных выглядит исключительно привлекательно, и предпринимались неоднократные попытки ее реализации; хороший анализ работ в этом направлении можно найти в гл. 1 и 2 в книге [10]. В [10] приводится детальное обсуждение причин, по которым основную часть проектов по реализации объектно/реляционных СУБД нельзя признать (удачным) решением указанной проблемы: они содержат концептуальные изъяны. Суммируя вкратце, таких основных изъянов два: а) отсутствие четкого понимания разницы между моделью и ее реализацией и б) неверное понимание концепции типа. Понятие тип является фундаментальным для всех компьютерных наук; неверное понимание этого понятия ведет не только к ошибкам в проектировании и реализации объектно/реляционных СУБД, но и, как мы думаем, объектно-ориентированных языков программирования общего назначения. В работе [10] утверждается, что верным (во всяком случае, применительно к СУБД) оказывается понимание типа как домена. В работе [10] защищается позиция, что реляционная модель является фундаментальным решением, независимым и независящим от поддержки других парадигм – объектно-ориентированной, императивной, функциональной (хотя авторы указывают, что некоторые сформулированные ими утверждения точны в случае применения императивного подхода и требуют некоторого уточнения при использовании функционального). Вопрос выбора между декларативным (в частности, функциональным) подходом и императивным был предметом острых дискуссий уже в конце 1980-х – начале 1990-х гг. В частности, в работе [11] приводится анализ доводов в пользу каждой из точек зрения и предлагается вариант интеграции обоих подходов. Отметим, что в настоящее время данная дискуссия не кажется актуальной, т.к. известны средства, позволяющие охватывать императивные аспекты языка, не выходя за рамки чисто функционального подхода [12].
Отдельно необходимо упомянуть о документно-ориентированных СУБД, в которых основными структурными единицами являются не отношения (и не объекты), а документы. В такой базе данных документы могут храниться в одном или нескольких поддерживаемых форматах (например, XML, JSON, PDF), и, таким образом, речь идет о хранении полуструктурированной информации. СУБД поддерживает поиск документов на основе их содержания (например, на основе значений тех или иных тегов). К числу промышленно используемых прототипов таких СУБД относятся, например, MongoDB, CouchDB и др.
Очередной виток эволюции начался сравнительно недавно, когда в практике программирования стали говорить о разделении объектов, хранящих состояние (statefull objects), и объектов, его не хранящих (stateless objects). До некоторой степени, будет корректной аналогия, что в предметной области выделяются сущности (хранящие состояние объекты с характеристическим набором атрибутов) и процессы (объекты, не хранящие состояния). Это не означает, что в statefull объектах нет методов, а в stateless – свойств; речь идет о концептуальном различии. В области баз данных эта тенденция отразилась в том, что в самих базах данных стали хранить лишь достаточно низкоуровневые алгоритмы, связанные с извлечением или модификацией данных. Алгоритмы уровня предметной области почти всегда выносятся на уровень прикладного программного обеспечения.
Интересная тенденция, которая наблюдается в настоящее время, заключается в том, что вновь приобрели актуальность сетевые и иерархические модели – однако не на уровне СУБД, а на уровне клиентских приложений. Действительно, анализируя структуры данных уровня предметной области, можно заметить, что зачастую возникает сеть, в которой есть как ISA-дуги, так и различные ассоциации. В программном коде сущностям предметной области соответствуют классы, а ассоциации выражаются в виде свойств, имеющих в качестве своего типа класс (возможно, тот же самый), также представляющий сущность предметной области.
Реализация многих алгоритмов основана на навигации по этой сети. В программном коде навигация по ассоциациям выражается в обращении (чтении значения) свойств-ассоциаций, причем серии таких обращений выстраиваются в цепочку. Навигация по ISA-связам лучше всего проявляется, когда выполняется динамическое приведение объектов к (лежащему ниже по ISA-иерархии) типу. Существенно то, что число компонент связности такой сети, даже в крупных системах, оказывается зачастую в пределах нескольких единиц, или даже равно строго единице. Поскольку редкий пользователь работает с сетью, состоящей из многих десятков и сотен узлов-сущностей, сеть подвергается расчленению (на уровне клиентского приложения, но не ее реляционная модель в базе данных). Это расчленение соответствует выделению фрагментов предметной области, с которыми работают пользователи определенных категорий. Такое расчленение достигается, например, тем, что некоторые ассоциации, имеющие место в предметной области, не отражаются в соответствующих классах.
Интенсивное проникновение отдельных концепций функционального программирования (например, в той или иной форме, концепция «функция-как-объект») в наиболее популярные языки позволяет предполагать, что 1) функциональные языки в скором времени станут использоваться так же широко, как и императивные, особенно, как только возникнут более развитые поддерживающие средства; 2) принципы функциональных языков если и не лягут в основу будущих систем баз данных, то, несомненно, будут использоваться в соответствующих RDI. В частности, известны работы, выполненные в 80-е гг., в которых исследуется повышение эффективности систем баз данных при использовании функциональных языков запросов за счет развитых возможностей оптимизации (в т.ч. применения «ленивых» вычислений) и распараллеливания.
Интенсивность исследований в направлении предметно-ориентированных средств и систем говорит о потребности в развитых средствах типизации объектов данных. В частности, возникает потребность оперировать со сложными объектами так, как если бы они были простыми (например, хранить в качестве значений полей записей массивы). Это требует переосмысления подходов к определению того, что считается доменом.
Необходимо также отметить развитие средств интероперабельности между СУБД и клиентскими приложениями. Пять-шесть лет назад программисты были вынуждены писать, а главное, – поддерживать, – алгоритмы получения данных из базы, преобразования этих данных в объектно-ориентированную форму, и записи сделанных изменений обратно в базу данных. Причем эти алгоритмы, как правило, были зависимы от модели объектов данных и метаданных, и изменение этих моделей требовало внесения изменений, нередко, нетривиальных, в код, реализующий указанные алгоритмы, причем этот код носил заметно рутинный характер, но повторному использованию не поддавался. Создание и поддержка такого кода представляло собой задачу высокой трудоемкости. Решением этой проблемы оказалось применение т.н. систем объектно-реляционных преобразований (object-relational mapping, ORM). Как правило, такие системы реализуются в виде подключаемой библиотеки, предоставляющей программисту каркас для разработки классов, реализующих модель объектов данных и метаданных. Если ранее такие системы в основном создавались отдельными программирующими коллективами для их собственных нужд и, по разным причинам, редко применялись другими коллективами, то в настоящее время существует целый ряд широко применяемых разработок, например, одна из наиболее развитых – Hibernate.
В информационных системах, наряду с запросами к базе данных, возникает потребность в сравнительно сложных выборках из уже загруженных в память данных. В императивном языке выражение вычислительного процесса для получения таких выборок требует вложенных циклов и приводит к трудно воспринимаемому программному коду. Один способов (предоставляемый, например, LINQ) решения этой проблемы заключается в том, что все данные – исходные, из которых требуется сделать выборку, промежуточные результаты и конечная выборка – хранятся в коллекциях, поддерживающих высокоуровневые методы поиска и агрегирования. Дополнительным средством может служить погружение в язык программирования подъязыка запросов (как, например, имеет место в случае C# 3.0 и LINQ). В результате наблюдается некоторая интероперабельность прикладных приложений и СУБД на уровне объектов данных и метаданных. Отметим, что встраиваемые СУБД, т.е. такие, которые могут быть легко интегрированы в прикладные приложения, существуют уже на протяжении некоторого времени, например, SQL Lite, но интероперабельность между ними низкая и осуществляется на уровне SQL-запросов, передаваемых в виде строки.
Мы также считаем необходимым отметить следующее обстоятельство. Вышеупомянутые высокоуровневые методы для манипулирования коллекциями выполнены в функциональном стиле и предполагают, по сути, функциональный стиль программирования; в частности, интенсивно используются делегаты. Эта техника была высоко оценена практикующими программистами и используется некоторыми из них как один из основных методов программирования, заменяющий применение циклов, особенно вложенных.
В работе [13] отмечается, что в области систем баз данных в настоящее время наблюдается поворотный момент и исключительно широкие возможности научного и технического продвижения. Некоторые направления исследований нами уже упоминались: пересмотр архитектурных и алгоритмических решений, и даже принципов, моделей данных, лежащих в основе современного ядра базы данных; новые языки запросов; предметно-ориентированные расширения. К числу других относятся масштабирование, поддержка работы в средах с большим количеством вычислительных единиц, в средах с виртуализацией, поддержка облачных вычислений, поддержка работы с неструктурированной и слабоструктурированной информацией, защита информации на всех уровнях и др.
Основные направления развития систем баз данных. Анализ тенденций и актуальных направлений развития в области баз данных позволяет сформулировать некоторые общие черты будущих систем баз данных:
1. Они будут основаны на продвинутых моделях данных, поддерживающих оперирование объектами данных и метаданных на уровне концептуальной модели предметной области. Такие системы будут существенно использовать наследование и полифморфизм, но, по всей вероятности, будут существенные отличия от объектно-ориентированного подхода, такого, каким мы его знаем сегодня.
2. Существенное значение приобретут встраиваемые решения – компактные, пригодные для распространения вместе с прикладными приложениями в виде подключаемой библиотеки. Вероятнее всего, такие системы будут определяться своими спецификациями, на основе которых соответствующие группы разработчиков будут выполнять реализацию для каждой платформы – Java, Microsoft .NET, и др. – аналогично тому, что объектная модель документов (Document Object Model, DOM) XML существует в первую очередь как спецификация, имеющая множество независимых реализаций.
3. Весьма вероятно, что будущие системы баз данных будут обладать открытой архитектурой – будут состоять из относительно независимых компонент, взаимодействующих на основе опубликованных интерфейсов. Это позволит как облегчить реализацию масштабируемости, так и расширяемость и адаптивность (к конкретной вычислительной среде).
4. Возможность «повторного использования» информации в будущем станет еще более актуальной проблемой. И хотя применение онтологий позволит существенно упростить достижение этой цели, потребность в средствах «стыковки» между (различными) моделями (различных) предметных областей будет почти повсеместной.
Поворотный момент назревает не только в области баз данных, но и в целом в компьютинге. Назревающая революция в области принципов осуществления компьютинга предоставит качественно новые модели вычислений. Хотя сейчас трудно сказать, какими именно они будут и когда именно получат широкое распространение, анализ текущих тенденций позволяет предположить, что в ближайшей перспективе возникнут системы, существенно основанные на принципах аппликативного компьютинга и высокой степени распараллеливания вычислений. Последующие научные и технические достижения, по-видимому, настолько преобразят компьютинг, что многие текущие проблемы потеряют актуальность, и будут заменены другими.
Литература:
1. Вольфенгаген В.Э., Кузин Л.Т., Саркисян В.И. Реляционные методы проектирования банков данных. // Киев: Вица школа. Головное изд-во, 1979г. – 192 С.
2. Codd E.F. A Relational Model of Data for Large Shared Data Banks. // Communications of ACM, Vol. 13, No. 6, 1970. – pp. 377-387.
3. Codd E.F. Relational Completeness of Data Base Sublanguages. // In: R. Rustin (ed.): Database Systems, Prentice Hall and IBM Research Report RJ 987, San Jose, California, 1972. – pp. 65-98.
4. Codd E.F. Further Normalization of the Data Base Relational Model. // IBM Research Report, San Jose, California RJ909, 1971. – 35 p.
5. Codd E.F. Extending the Database Relational Model to Capture More Meaning. // ACM Transactions on Database Systems, Vol. 4, No. 4, 1979. – pp. 397-434.
6. Astrahan M.M. et al. System R: Relational Approach to Database Management. // ACM Transactions on Database Systems, Vol.1, No. 2, 1976. – pp. 97-137.
7. Dayal U., Hanson E.N., Widom J. Active Dayabase Systems. // In: Kim W., ed. Modern Database Systems: The Object Model, Interoperability, and Beyond. / Addison-Wesley, 1994.
8. Griefahn U. First Specification of Phoenix, an Active Database Programming Language. // Technical report, University of Bonn, 1995. –
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.44.6002&rep=rep1&type=pdf
9. Simon E., Kieman J., De Maindreville C. Maindreville. Implementing high level active rules on top of a relational DBMS. // Proceedings of the Eighteenth International Conference on Very Large Data Bases, 1992. – pp. 315-326.
10. Дейт К.Дж., Дарвен Х. Основы будущих систем баз данных. Изд. 2-е. / Перев. с англ. С.Д. Кузнецова и Т.А. Кузнецовой / Под ред. С.Д. Кузнецова // М.: Янус-К, 2004. – 656 С.
11. Manthey R. Declarative Languages – Paradigm of the Past or Challenge of the Future? // Proceedings of the 1st International East-West Database Workshop, Kiev, USSR, No. 504 in Lecture Notes in Computer Science, Springer-Verlang, 1990. – pp. 1-16.
12. Moggi E. Notions of computation and monads. // Information And Computation, No. 93, 1991. – pp. 55-92.
13. Agrawal R., Ailamaki A., Bernstein P.A., Brewer E.A., Carey M.J., Chaudhuri S., Doan A., Florescu D., Franklin M.J., Garcia-Molina H., Gehrke J., Gruenwald L., Haas L.M., Halevy A.Y., Hellerstein J.M., Ioannidis Y.E., Korth H.F., Kossmann D., Madden S., Magoulas R., Ooi B.C., O'Reilly T., Ramakrishnan R., Sarawagi S., Stonebraker M., Szalay A.S., Weikum G. The Claremont report on database research. // SIGMOD Rec., Vol. 37, No. 3, 2008. – pp. 9-19.