Абстракции и модели в системах баз данных

В недавнем выпуске журнала СУБД была опубликована статья В.В. Пржиялковского «Абстракции в проектировании баз данных» [12]. Намерение ее автора обратить внимание читателей журнала на связанный с этой темой круг вопросов заслуживает всяческого одобрения по той причине, что методы абстракции лежат в основе моделирования данных, которое, в свою очередь, является фундаментом технологий баз данных.

Важность моделирования данных в технологиях баз данных подтверждается тем фактом, что за работы в этой области одной из самых престижных наград в информатике - Тьюринговской премии - были удостоены в разное время идеолог сетевой модели данных CODASYL Чарльз Бахман (1973) и создатель реляционной модели Эдгар Кодд (1981).

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

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

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

Дополнительные трудности связаны с формированием русскоязычной терминологии. Уже давно не является секретом, что за рубежом научные исследования и разработки инструментария в области баз данных и информационных систем ведутся значительно более интенсивно, чем в нашей стране, особенно в последние годы. Вместе с тем оперативным источником информации для широкого круга специалистов в рассматриваемой области информатики являются, главным образом, публикации в ведущих научно-технических журналах и в материалах крупных международных конференций, издаваемых в большинстве своем на английском языке. По этим причинам в новых областях, естественно, доминирует англоязычная терминология. Образный язык и раскованность в выборе новых терминов их авторами доставляет много проблем отечественным специалистам. Достаточно упомянуть в этой связи такие причудливые термины, как «data mart», «data mining» или «data warehouse», для которых найти адекватный русскоязычный термин довольно трудно, а обойтись калькой невозможно. В результате в отечественных публикациях появляются «витрины данных», «киоски данных», «добыча данных» или «склады данных».

В этой статье нам хотелось бы кратко высказать свое мнение по ключевым вопросам терминологии, связанным с моделированием в системах баз данных, и прокомментировать некоторые положения работы [12]. Мы стараемся здесь по возможности избегать ссылок на конкретные фрагменты этой работы для того, чтобы не обременять читателя необходимостью заниматься утомительными текстологическими изысканиями и, вместе с тем, обеспечить возможность автономного чтения предлагаемой статьи.

Более детальное обсуждение затрагиваемых здесь вопросов можно найти в наших работах [7,24]. Кроме того настоятельно советуем читателю познакомиться с замечательной монографией [14], посвященной фундаментальному рассмотрению концепций моделирования данных и почему-то не включенной автором [12] в список рекомендуемой литературы.

1. Разновидности используемых моделей

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

1.1. Инструменты и результаты моделирования

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

По указанной причине неестественно проводить сопоставление моделей данных (инструментов) и схем баз данных (результатов) по каким-либо критериям такого рода, например, как «насыщенность семантикой» или «теоретическая обоснованность» [12]. Точно так же неуместно даже условно трактовать объектную модель данных как схему объектной базы данных, заключая слово модель в кавычки.

1.2. Модели и архитектура систем

Функции моделей в системах баз данных (как инструментов, так и результатов моделирования) существенно различаются, в зависимости от архитектурных уровней системы, с которыми они ассоциируются.

Уже на ранней стадии разработок систем баз данных в качестве одного из основополагающих принципов построения таких систем был принят принцип независимости данных. В соответствии с этим принципом, в системе должны поддерживаться раздельные представления данных для пользователя («логическое представление») и для системных механизмов среды хранения базы данных («физическое представление»). Такое разделение избавляет пользователя от необходимости знания принятого способа хранения базы данных и, вместе с тем, при условии поддержки управляемого отображения между этими представлениями, позволяет динамически в процессе эксплуатации системы оптимизировать способ хранения базы данных для обеспечения более высокой производительности системы и/или более рационального использования ресурсов памяти. В соответствии с таким подходом, стали различать логический и физический архитектурные уровни системы (системные механизмы, поддерживающие такие представления данных). Связанные с ними модели данных и схемы базы данных также стали называть логическими и физическими.

Опубликованный в 1975 году широко известный отчет ANSI/X3/SPARC [16], к сожалению, так и не изданный в русском переводе, зафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения в архитектуре таких систем специального уровня представления полной базы данных, единого для всех ее приложений и независимого от них (концептуальный уровень). Эта идея уже высказывалась ранее во многих работах, начиная еще с [18].

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

Архитектурная терминология ANSI/X3/ SPARC получила широкое распространение. Пытаясь связать раннюю терминологию с терминологией ANSI/X3/SPARC, некоторые авторы, например [22,33], отождествляют понятия «логической» и «концептуальной» схемы базы данных, «физической» и «внутренней».

1.3. Объекты моделирования

Другим аспектом различия модельных средств в системах баз данных являются объекты моделирования, с которыми они связаны. С этой точки зрения, различаются модели предметной области системы и модели базы данных. Эти модели взаимосвязаны и их взаимосвязь проявляется в процессе проектирования системы базы данных. Рассмотрим кратко основные стадии этого процесса.

Начальной стадией проектирования системы базы данных является разработка модели предметной области, которая базируется на анализе информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью предметной области. (Подчеркнем, что объектом моделирования здесь является предметная область будущей системы!) Такая модель, по существу, представляет интегрированным образом информационные потребности пользователей создаваемой системы. Отечественные специалисты использовали в 70-80-е годы для обозначения этой стадии термины «инфологическое проектирование», «инфологическая модель» (см. например, [1,13]), отдавая дань шведской школе проектирования информационных систем [25,26,31,32].

Инструментальные средства для спецификации концептуальной модели предметной области вопреки логике также принято называть моделями данных. (Обратим внимание на то, что при этом происходит подмена обмена моделирования!) Однако такие модели, в отличие от моделей данных, используемых в качестве инструмента моделирования баз данных, не обязательно поддерживаются механизмами используемой СУБД, хотя это и может иметь место. Одной из наиболее популярных моделей данных подобного рода является модель сущностей-связей (Entity-Relationship) П. Чена [17].

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

Концептуальная схема базы данных, как и модели базы данных, ассоциированные с другими архитектурными уровнями системы базы данных (внутренняя и внешние схемы), позволяет механизмам СУБД правильно интерпретировать содержимое базы данных и осуществлять необходимые операции.

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

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

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

1.4. Модели и парадигмы моделирования

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

2. О понятии модели данных

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

Одной из ранних публикаций, где упоминается понятие модели данных, впрочем, без какого-либо явного определения, является широко известная работа Э. Кодда [19]. Впоследствии оно значительно трансформировалось с развитием технологий баз данных.

Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. Структурная трактовка полностью согласовывалась с математическим определением понятия модели как множества с заданными на нем отношениями [15] и до сих пор встречается в литературе. Вероятно, именно в связи с этим обстоятельством предполагалось, что нет необходимости давать определение этого термина. Очевидно, что в данном контексте имелся в виду результат процесса моделирования. Существенно отметить, что объектом моделирования в данном случае являются не данные вообще, а конкретная база данных. Таким образом, мы имеем здесь дело с подменой объекта моделирования, в результате которой возник ложно ориентирующий термин [6]. Более уместно было бы вести здесь речь не о модели данных, а о модели базы данных.

В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Этому, безусловно, способствовали новые потребности теории. Разработка новых архитектурных подходов (см. п.1.2), основанных на получивших широкое признание идеях многоуровневой архитектуры СУБД, высказанных еще в раннем отчете CODASYL DBTG [18], в отчете ANSI/X3/SPARC [16] и во многих других работах начала – середины 70-х годов, а также активные исследования в области распределенных баз данных, в свою очередь, породили проблемы отображения данных [8]. При этом оказалось уже недостаточно рассматривать отображение представлений конкретной базы данных. Требовалось решение на метауровне, позволяющее оперировать множествами всевозможных допустимых представлений баз данных в рамках заданной СУБД или, что эквивалентно, инструментальными средствами, используемыми для их спецификации. В этой связи возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса.

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

Понятно, что инструмент моделирования баз данных должен по необходимости включать не только средства структурирования данных, но и операционные возможности для манипулирования данными. Поэтому модель данных в инструментальном смысле стала пониматься как алгебраическая система [10] – множество всевозможных допустимых типов данных, а также определенных на них отношений и операций (см., например, Тьюринговскую лекцию Э. Кодда [20]). Позднее в это понятие стали включать еще и ограничения целостности, которые могут налагаться на данные. В результате проблема отображения данных в многоуровневых СУБД и системах распределенных баз данных стала рассматриваться как проблема отображения моделей данных.

Важно подчеркнуть, что для разработчиков и пользователей СУБД точным определением реализованной в ней модели данных являются фактически языковые средства определения данных и манипулирования данными, воплощающие функциональность этой модели. Действительно, базовая реляционная модель Кодда (материализованная в языке ALPHA) – совсем иная модель данных, чем реляционная модель, воплощенная в языке SQL, или RM/T. По этой причине существует целое семейство возможных реляционных моделей данных и имеются различные конкретные его представители. Сопоставление семантических и других свойств абстрактного представителя этого семейства с конкретной принадлежащей ему моделью, например SQL-моделью (как это делается в [12], рис. 3,4), представляется нам некорректным.

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

Уместно здесь заметить, что необходимость самостоятельно существующего, отделенного от приложений и независимого от них описания организации базы данных была впервые предложена в рамках концепции сетевых баз данных CODASYL (еще в отчете [18]). Отсюда, естественно, следовала необходимость использования языков определения (описания) данных. В указанном отчете была представлена первая версия языка определения данных CODASYL, подвергшаяся в дальнейшем значительной доработке.

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

Завершая эту тему, заметим, что начиная с середины 70-х годов под влиянием предложенной в этот период концепции абстрактного типа данных и ряда основанных на ней экспериментальных языков программирования (CLU, Alphard и др.) понятие типа данных в языках программирования, стало трансформироваться таким образом, что в него стали вкладывать не только структурные свойства, но и элементы поведения. Такая интерпретация понятия типа послужила в дальнейшем основой для формирования концепции объекта, на которой базируются современные объектные модели.

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

3. Об использовании математических моделей

Важный вопрос, поднятый в [12], заключается в том, можно ли разрабатывать приложения систем баз данных с явным использованием математических моделей.

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

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

В отчете занимающейся этой проблемой рабочей группы WG3 [21] язык логики предикатов рассматривался как один из претендентов на роль языка спецификации концептуальной схемы базы данных.

Еще одним более свежим примером может служить исследовательский проект СИНТЕЗ, реализуемый в Институте проблем информатики РАН [23], в котором используется весьма математизированный язык спецификации информационных ресурсов, опирающийся на аппарат математической логики и на сети Петри.

Наконец, сошлемся на наш личный опыт. В начале 90-х годов автором данной статьи вместе с коллегами было разработано для нужд одного из подразделений ГВЦ Госплана СССР приложение, позволяющее явным образом оперировать нотацией оптимизационных моделей линейного программирования и поддерживающее широко принятый де-факто стандарт представления исходных данных и результатов решения таких задач (MPS-формат).

Что касается уровня семантики, поддерживаемого математическими моделями, то по нашему мнению (в отличие от высказанного в [12]), он может изменяться в очень широком диапазоне. Все зависит от конкретного характера модели. Возможность же их явного использования в системах баз данных связана лишь с тем, реализованы ли такие модели средствами программного обеспечения CASE, архитектуры СУБД или, может быть, приложения.

4. О реализации концептуального проектирования

Как уже было описано выше, важной стадией разработки системы базы данных является концептуальное проектирование. Это обстоятельство особенно четко было осознано после выхода уже упоминавшегося отчета ANSI/X3/SPARC [16]. Начались активные исследования, а также разработки подходов и инструментальных средств для этих целей, дискуссии о том, какова должна быть модель данных для концептуального моделирования предметной области. В этот период, в частности, были опубликованы привлекшие большое внимание работы Чена [17] (модель сущностей-связей), Джона и Дианы Смит [28-30] и многих других авторов, посвященные методологии концептуального моделирования. Одна из работ Смитов [30] упоминается в качестве примера в [12]. Однако вызывает удивление высказанное в [12] суждение о том, что концептуальное проектирование «существует лишь в статьях и не реализовано напрямую ни в одной компьютерной системе». Обратимся к истории.

Хорошо известно, что в результате отмеченной выше активности в исследовательском сообществе еще в 70-х-80-х годах начали предприниматься попытки разработки программных инструментальных средств для автоматизации процессов проектирования баз данных, включая стадию концептуального проектирования (разработки концептуальной модели предметной области). Исследовательские работы проводились в этой области и в нашей стране (см., например, [3,9,11,13]). Уже в указанный период были получены практически полезные результаты и стало появляться программное обеспечение.

В настоящее время существует значительное количество коммерческих CASE-продуктов, ориентированных на различные программно-аппаратные платформы и решающих эту задачу [2]. В конце 80-х – начале 90-х годов активно проводились работы по созданию таких средств и для платформы ПК [9]. Имеющиеся CASE-продукты поддерживают полный цикл разработки систем или отдельные его стадии, ориентированы на СУБД определенного поставщика или на некоторый спектр поставщиков. Ряд из них основан на методах объектного анализа и проектирования. В последние годы быстро получил распространение в этой области недавно стандартизованный OMG язык UML (1997), созданный компанией Rational, и уже имеются его реализации. Многие CASE-продукты не только поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, но и позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы базы данных для выбранной СУБД, например, схемы базы данных для какого-либо SQL-сервера (на языке SQL-92) или объектной СУБД (на языке определения объектов ODMG ODL).

5. О «новой технологической тройке»

В [12] проводится аналогия ситуации первой половины 70-х годов, когда велись споры о преимуществах сетевой (CODASYL), иерархической и реляционной модели данных (как известно, завершившиеся «ничейным» исходом в открытой дискуссии Ч.Бахмана и Э.Кодда на Конференции ACM SIGMOD в 1975 году), с сегодняшней ситуацией. По мнению автора, в настоящее время сформировалась новая тройка конкурентов – реляционная, объектная и многомерная модели. При этом утверждается, что многомерная модель, якобы, «используется не для описания данных, а для их представления».

Не вдаваясь в обсуждение сравнительных достоинств и преимуществ этих моделей, рискнем заметить, что, строго говоря, здесь речь идет лишь о двух моделях. Действительно, многомерные модели (существует целый ряд их воплощений, см. в п.2 о семействах моделей и об их конкретных представителях) , коммерческие реализации которых появились в начале 90-х годов для поддержки технологий OLAP, не основаны на каких-либо радикально новых идеях. Они представляют собой некоторое расширение активно исследовавшейся в 70-х-80-х годах модели универсальных отношений [33] новыми операционными возможностями, обеспечивающими, в частности, необходимые для OLAP функции агрегирования данных. Таким образом, многомерные модели представляют собой особую разновидность реляционной модели.

Интересно заметить, что структура данных многомерных моделей – так называемый куб данных – уже давно привлекает внимание специалистов, работающих в области статистических баз данных. Для примера можно сослаться на работу одного из авторов инфологического подхода к базам данных Бо Сундгрена [31], где была введена аналогичная структура данных «box structure» и построена алгебра таких структур, предусматривающая, в частности, и возможности агрегирования данных.

Многомерные модели – это «полноправные» модели данных. Так же как и другие модели данных, они используются для описания базы данных, определяя тем самым соответствующее ее природе представление данных, и предоставляют средства манипулирования данными. И в этом смысле они ничем не отличаются по своей функциональности от других моделей данных. В сегодняшних массовых реляционных технологиях многомерные модели ассоциируются с внешним уровнем архитектуры систем баз данных. Именно этим определяется их направленность на конечного пользователя, справедливо отмечаемая в [12]. Нужно заметить, что обеспечение комфортных условий для работы конечного пользователя было также основной целью разработки модели универсального отношения.

6. По поводу перспектив моделирования

Рассмотрим теперь кратко перспективы моделирования, обсуждаемые в [12].

Если говорить о преодолении «реляционного кризиса», то главная проблема в области массовых технологий заключается, на наш взгляд, не столько в том, чтобы найти достойного преемника реляционной модели. Дело прежде всего в том, что огромный «баласт» унаследованных систем (в данном контексте – уже реляционных) не дает возможности для резких технологических сдвигов и радикального обновления существующих технологий. Стремление избежать огромных кратковременных капиталовложений в случае перехода к принципиально новым технологиям приводит к необходимости лишь эволюционного пути развития. Отсюда рождение таких гибридов, как объектно-реляционные серверы баз данных «нового поколения».

Что касается проблемы уникальной идентификации объектов (OID) в объектных системах баз данных, то как справедливо замечено в [12], она более злободневна в распределенных системах. Однако в стандартизованных объектных средах обеспечиваются некоторые пути решения этой проблемы. Например, в архитектуре CORBA, как известно, предусматривается использование Сервисов именования. Каждый объект должен быть зарегистрирован в соответствующем Сервисе. При назначение OID данному объекту и его регистрации Сервисом, приложение имеет возможность отследить уникальность данного OID в области действия этого Сервиса. Конечно, «проклятие размерности» и здесь может создать дополнительные проблемы.

Следующий важный вопрос, поднятый в [12], – об обеспечения многообразия уровней абстракции. Нужно заметить, что теоретически этот вопрос был решен еще в 60-х – 70-х годах. Основой для его решения является рассмотренная выше концепция многоуровневой архитектуры системы базы данных. Действительно, уже в цитировавшемся здесь раннем отчете CODASYL [18] предусматривался архитектурный уровень подсхемы, который позволял для каждого конкретного приложения строить свое собственное «видение» используемого подмножества базы данных путем определения его «персональной» подсхемы базы данных. Хотя, по существу, оба этих архитектурных уровня поддерживали одну и ту же модель данных, в определенных рамках допускалось различие свойств данных в их схемном и подсхемном представлении.

В более общем виде этот вопрос решен в архитектурной модели ANSI/X3/SPARC [16]. Здесь на внешнем уровне может поддерживаться совсем иная модель данных (или даже несколько моделей, см. например [27]), чем на концептуальном уровне. Поддержка разнообразных возможностей абстрагирования в такой системе достигается благодаря средствам определения и поддержки междууровневого отображения моделей данных.

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

Наконец, о концептуальном проектировании. Как было показано в п.4, оно вовсе не было «оставлено исследователями с начала 80-х годов». Поддержка концептуального проектирования – не желательная перспектива (см. [12]), а сегодняшняя реальность, хотя оно, несомненно, требует дальнейшего развития модельных возможностей.

Вопрос о перспективах моделирования в системах баз данных, конечно, отнюдь не исчерпывается затронутыми в [12] проблемами. Серьезное обсуждение этой темы требует специального обсуждения, которое выходит за рамки данной статьи. Ограничимся здесь лишь несколькими примерами злободневных проблем.

Одной из них является обеспечение интеграции неоднородных информационных ресурсов, в частности, структурированных и слабоструктурированных данных. Необходимость ее решения связана, в частности, со стремлением к полноценной интеграции систем баз данных в среду Web-технологий. При этом уже недостаточно простого обеспечения доступа к базе данных традиционным теперь способом «из-под» HTML-форм. Нужна интеграция на модельном уровне. И не просто синтаксическая интеграция. Например, разработки цифровых библиотек (Digital Library) требуют обеспечения семантической интероперабельности информационных ресурсов.

Другая модельная проблема, которая на самом деле является подпроблемой предыдущей, состоит в разработке средств и технологий, предусматривающих явную спецификацию метаданных для ресурсов слабоструктурированных данных, которыми столь богата среда WWW, в поисках путей перенесения традиционных технологий моделирования из области баз данных в эту среду. (Напомним, что в области систем баз данных аналогичная ситуация была преодолена благодаря предложениям CODASYL о необходимости явной спецификации схемы базы данных, независимой от приложений, см. выше п.2). Именно на достижение этой цели направлены интенсивные разработки консорциумом W3C нового языка XML и его инфраструктуры (фактически, новой модели данных для этой среды), объектной модели документов и других компонентов нового комплекса средств, который, как можно ожидать, в близкое время станет основой новых технологий управления информационными ресурсами в Internet.

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

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

Заключение

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

Литература