Абстракции в проектировании БД

Среди разработчиков баз данных и связанных с ними информационных систем нередко практикуется "технологически-конструктивистский" подход к своей деятельности. Например, часто (но не исключительно) это происходит, когда разработчик перешел от использования настольных систем типа Paradox или Clipper к более развитым системам типа Oracle. Люди увлекаются техническими решениями и находками типа "как получить такой-то эффект в новой версии", "как стыковать одно с другим" и т.п., и часто находят в этих поисках свое основное занятие. Создание информационной системы при таком подходе часто видится как подбор комбинации и организация взаимодействия технологических решений, вкупе предоставляющих возможность выполнения требуемой задачи. Не оспаривая такой деятельности тотально, мне бы хотелось здесь поговорить о ровным счетом противоположных вещах, а именно не о технической конкретике, а об абстракциях в проектировании БД. И вот доводы в пользу такого разговора.

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

Но вот как раз состояние с моделированием в базах данных в последние годы способно вызывать у разработчиков определенное беспокойство. Оно несколько напоминает уже существовавшее 20 лет назад: равно как тогда шли споры о взаимных преимуществах и перспективах трех технологий организации БД, иерархической, сетевой и реляционной, так и сегодня, и, по крайней мере на слуху, имеется (но пока еще не обсуждается в столь же активном сравнении) новая технологическая тройка: реляционная, объектная и многомерная. Реляционная, по сути дела, монополия в СУБД, не вызывавшая сомнения еще 10 лет назад, поколебалась, а некоторые даже говорят о тупике реляционного подхода в качестве перспективы. Это несколько нервирует пользователей СУБД, поскольку перед ними снова начинает маячить вопрос "куда бежать ?". А действительно, куда ? Где "будут все" через 10 лет ?

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

Здесь будут рассмотрены только некоторые виды абстракций, которые в той или иной степени, явно или неявно, но обязательно (возможны лишь комбинационные различия) присутствуют в разработке конкретной БД. Во-первых, это "концептуальная тройка", три уровня моделей БД: концептуальный, логический и физический. Во-вторых, это группа конкретных моделей, часть их которых реализована в ЭВМ инструментально, а часть - нет, например реляционная, подразумеваемая SQL, объектная схема БД и некоторые другие. Однако начать перечисление правильно было бы с "самой общей" абстракции, с которой только можно иметь дело, а именно с математической модели.

Математическая модель

Мне неизвестно ни одной прикладной системы, разработанной с явным использованием математической модели. Тогда зачем говорить о ней в техническом журнале ? Дело в том, что хотя бы общее представление о том, что она есть такое, уже дает определенное понимание целей, техники и содержания процессов проектирования БД.

Модель вообще теснейшим образом связана с абстракцией. "Абстракция" - это, буквально, "отвлечение", то есть исключение из рассмотрения чего-то. (Уже здесь можно заметить, что исключаться "что-то" может либо как несущественное, либо же по незнанию, забывчивости и т.д., и последствия в разных случаях разные.) Всякая модель - это абстракция, то есть отвлечение от тех явлений реального или идеального мира, которые нас не интересуют. Еще одно замечание: вопреки интуитивным при проектировании информационной системы (ИС) ожиданиям, отвлечение не равнозначно выделению явлений, представляющих интерес (так сказать "модель всегда "меньше" и "проще" реальности"). Например, отвлечение от имеющихся ограничений может привести к появлению у модели свойств, не соотносимых с действительностью.

Модели в информатике предназначены для совместного использования разными людьми, и, кроме того, их должна "понимать" ЭВМ, а поэтому они должны быть по меньшей мере четко сформулированы. Наиболее общее и строгое ("однозначное") понятие модели придумано в математике. Там модель, говоря упрощенно, есть (а) основное множество объектов и (б) множество отношений на нем: M = , и модели составляют предмет самостоятельного изучения. Однако базам данных ближе по духу несколько иное математическое понятие, а именно алгебраические системы, развитие теории которых тесно связано с работами академика Мальцева в 50-х годах. Алгебраические системы объединяют в себе помимо (а) и (б), как и в модели, сверх того еще и (в) множество операций (функций), задаваемых на основном множестве: A = . Математическая модель и алгебраическая система - это настолько близкие понятия, что для степени нестрогости настоящего этого текста они неразличимы, и в дальнейшем будет употребляться только один термин: "модель", подразумевающий тройку . Общность математического понятия модели означает, что с его помощью можно описать любую математическую, т.е. формальную, структуру.

Уже на общем уровне сказанного можно сделать некоторые интересные для разработчика наблюдения:

1. Всякая формальная система формальна постольку поскольку для нее существует модель. Например, база данных - это модель, и значит, проектирование базы данных есть построение модели.

2. Не правда ли, тройка напоминает триаду <Базовые таблицы, Декларативные ограничения целостности, Процедуры БД > ?

3. Множества отношений R и функций F в математической модели "взаимозаменяемы", т.е. можно подобрать такие отношения R1, что надобность в F1 отпадет, и наоборот. Распределение правил, задающих множества объектов модели, между R-определениями (например, путем перечисления) и F-определениями есть вопрос удобства работы с ними, и принципиально ничего не убавляет и не добавляет к этому множеству (будучи, конечно, сделано корректно). Не то же ли можно сказать о декларативных и процедурных ограничениях целостности в базах данных ?

В математике модели хорошо изучены на уровне строгости и тщательности, недостижимом в других областях знаний, а в качестве описательного средства они универсальны. Более того, они всегда "незримо присутствуют" во всяком процессе проектирования ИС. Так почему же их не используются при разработках БД явным образом? Есть ряд причин, и одна их них в том, что математическая модель - слишком уж абстрактное понятие, лишенное семантической окраски, сплошь пронизывающей прикладную область. Иначе говоря, ей неизвестен прикладной смысл объектов из S, R и F, то есть как раз то, что все время на уме у разработчика БД, и это затрудняло бы работу последнего с ней. Кроме того, модели, в том виде, в каком они существуют в математике, "не понимает" ни одна компьютерная программа. Реально в проектировании между математической моделью (умозрительной) и базой данных (тоже моделью, но "выполненой в компьютере") присутствует несколько моделей разных уровней абстракции, связанных между собою. Математическая модель и база данных образуют как бы два полюса, между которыми находятся другие модели, тяготеющие к одному или другому "полюсу"; при этом "полюс" математической модели принципиально недостижим, и ценен, скорее, как "точка отсчета", своего рода "реперная точка", а "полюс" БД, напротив, всегда реализуем. Можно привести три уровня моделей, заполняющих "промежуток": концептуальной модели прикладной области и два других, о которых, как и о концептуальном, известно было давно, но которые практически стали популярны среди разработчиков сравнительно недавно, а именно уровни логической и физической модели БД.

Уровни моделирования в процессах проектирования

Концептуальная модель данных

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

Таким образом, в концептуальном моделировании проектируется схема понятий прикладной области в их взаимосвязи. Предлагались и предлагаются разные пути такого моделирования. Вот например, какие (мета-)понятия рассматривали для концептуального моделирования в конце 70-х годов Смит и Смит.

Исходными базовыми понятиями в трактовке этих двух специалистов являются объекты и связи между объектами. Связи могут быть двух видов: обобщение и агрегация. Обобщение интуитивно ясно, и связывает одни объекты с другими, по смыслу более общими. Например, объект "животное" есть обобщение для объектов "собака" и "лошадь". Агрегация связывает разнородные объекты по признаку компонентного вхождения в другие объекты, как например, "колеса" и "кузов" связаны с "автомобилем" тем, что последний состоит из первых. Независимо, оба вида связей образуют каждый свою иерархию среди объектов модели (см. Рисунок 1).

Рисунок 1. Два вида связей в концептуальном моделировании.

Кроме этих базовых имеются и другие понятия концептуальной модели, как-то атрибут, отношение, экземпляр, индивид. Самое замечательное в "модели Смитов" - зто относительность перечисленных понятий. Одно и то же явление может быть и объектом, и отношением, и атрибутом, и экземпляром, и индивидом, и все определяется точкой зрения на явление. Зависимость интерпретации от точки зрения на явление (а точнее - возможность выбора точек зрения с разной интерпретацией) - это очень мощное свойство, придающее концептуальной модели большую гибкость и приспособляемость в описании проектируемой ИС. Это свойство, например, будь оно реализовано, позволило бы в информационной системе смотреть на "адрес" то как на объект реестра адресов, то как на атрибут "лица", то как на отношение, связывающее владельца с остальными жильцами - когда, где и кому как нужно. Наиболее близко к концептуальной в этом отношении подошла (теоретическая) реляционная модель данных (см. ниже), а вот объектный подход с его фиксированной интерпретацией структуры отстоит от реляционного на шаг назад.

Несмотря на очевидную привлекательность концептуального проектирования, оно существует лишь в статьях и не реализовано напрямую ни в одной компьютерной системе. Исключение составляет лишь (не так давно появившаяся) заслужившая высокую оценку среди специалистов система InfoModeler фирмы Visio, которая использует концептуальную модель "объект-роль", несколько отличную от "модели Смитов". Еще одним известным примером "умозрительного" подхода может служить широко известная система RM/T описанная Коддом в 1979 году, и обладающая высокой насыщенностью семантических конструкций, но вместе с тем и сложностью. Пик работ по концептуальному моделированию пришелся на конец 70-х годов. К сожалению, с того времени эта тема активно не обсуждается в литературе, но к счастью работы тех лет по этой теме не потеряли своей значимости.

Логическая модель данных

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

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

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

Наиболее популярными видами моделей БД логического уровня являются ER-модель, реляционная модель, а в последнее время и объектная "модель" (в неформальном смысле).

Физическая модель данных

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

Инструментарий

Трем приведенным уровням моделирования при разработке базирующейся на использовании СУБД прикладной системы соответствует достаточно обширный языковый инструментарий (см. Рисунок 2), позволяющий организовать работу с соответствующими моделями на ЭВМ. Из рисунка очевидна неравномерность распределения подобного инструментария по категориям "подход/уровень": например, при реляционном подходе компьютерный инструментарий для концептуального проектирования отсутствует, а для логического проектирования он достаточно богат (на рисунке не указана еще многочисленность конкретных CASE-систем, реализующих ER- и IDEF-подходы).

Рисунок 2. Примеры инструментальных языков проектирования для разных подходов.
	Реляционный подход	Объектный подход	Многомерный подход
Концептуальное проектирование объектов прикладной области	нет	только схемы "объект-роль" (InfoModeler)	нет
Логическое проектирование БД	варианты ER-, IDEF1X-схем	диаграммы UML, OMT, Booch, ...	нет
Физическое проектирование БД	схема БД	схема объектной БД	Средства определения данных в Oracle Express

Конкретные модели данных

Итак, в своей практике разработчик ИС может сталкиваться с множеством разных конкретных моделей прикладной области или БД. Взаимоотношение между некоторыми наиболее известными из них показано на рисунках (см. Рисунок 3 и Рисунок 4). Ниже приводятся пояснения к использованным в рисунках названиям моделей.

Рисунок 3. Насыщенность семантикой абстракций моделирования разных уровней.

Рисунок 4. Теоретическая обоснованность моделей разных уровней.

Математическая модель - абстракция понятия модели, принятая в математической логике. О ней говорилось выше.

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

RM/T - расширенная реляционная модель, предложенная в 1979 году Коддом для "лучшего учета семантики" прикладной области. В отличие от реляционной модели, RM/T вообще не получила никакого воплощения в компьютере, но она также имеет большое методологическое значение.

Модель данных SQL - имеется в виду модель данных, существующая в рамках SQL-диалекта той или иной СУБД, то есть, например, для Oracle это модель данных, задаваемая описанием, составленным на реализации SQL, принятой в Oracle.

"Модель Смитов" - методика концептуального моделирования, предложенная в статьях Смит и Смита в 1977 году.

ER-модель - здесь имеется в виду не классическая модель, введенная Ченем (она в таком виде нигде не используется), а тот ее упрощенный вариант, который употребим в большинстве сегодняшних CASE-систем.

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

Объектная схема - схема БД конкретной объектной СУБД

Многомерная схема - схема данных в одной из многомерных систем представления данных, например, в Oracle Express. Многомерные модели используются не для описания данных, а для их представления, так как "универсализация" отношений приводит к "потере точности" описания, но зато и к удобству восприятия информации конечным пользователем. Таким образом, значение многомерных схем - преимущественно "интерфейсное" (они удобны конечным пользователям), а не описательное.

"Объект-роль" - модель концептуального описания, принятая в системе InfoModeler фирмы Visio. В этой системе для модели "объект-роль" используется два языка: графический и [условно-] естественный.

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

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

Говоря о "реляционном кризисе" (если об этом уместно говорить), не следует забывать, что он был изначально запрограммирован самим подходом. Действительно, реляционная модель принципиально построена нереализуемым образом. Она требует полной нормализации данных, а это недостижимо. Всякая используемая на ЭВМ модель необходимо имеет некоторый определенный уровень абстракции по отношению к моделируемой области, а это противоречит нормализации.

Пусть в таблице SQL-СУБД мы храним такие атрибуты лица, как телефон и адрес. В 99% случаев реальной практики номер телефона будет описан строкой, иначе говоря, будет неструктурирован (в 90% случаев и адрес будет описан строкой, а в остальных 10% случаев адрес будет структурирован, но только частично, и никогда полностью !). Но ведь в такой ситуации мы получим денормализованную таблицу. Все номера телефонов выдаются АТС, а они обслуживают вполне определенные районы, то есть между номером телефона и адресом в жизни существует зависимость, неучтенная схемой БД. Человек знает об этой связи, а машина - нет, и когда-нибудь человек задаст машине вопрос, подразумевающий наличие связи и получит неправильный ответ. Другая ситуация не менее коварна: неправильный ответ может возникнуть не в результате прямого запроса пользователя, а как следствие заложенной в систему на стадии разработки "человеческой" логики. Когда подобная накладка может стать осязаемо вероятной ? Когда данных станет много, а система сложной.

Последнее время предлагают семантически более продвинутую объектную технологию организации данных в БД. Но ведь и она принципиально нереализуема в ее "ортодоксальном" виде, потому что механизмы "регулирования" уровня абстракции в ней невозможны для выполнения. Объектный подход требует уникального системного ключа для каждого экземпляра объекта в БД. Это не особая проблема, если объектная база данных работает на одной установке для конкретной задачи. Но как обстоят дела с reusability ? Мы соединяем две установки, и хотим взаимно пользоваться объектами. Как сделать так, чтобы не возникло конфликтов с OID ? В перспективе большинство машин мира соединяться друг с другом посредством Интернета. Возможно, при этом понадобится некая единая служба выдачи OID, наподобие существующей для адреса IP. Но верхняя оценка числа адресов IP сопоставима с числом компьютеров на Земле, а сколько может быть на них заведено объектов? Сообразно с разнообразием моделируемых явлений и с уровнем их моделирования число идентификаторов объектов заведомо бесконечно. Когда эта бесконечность проявит себя реально лимитирующим фактором для ИС ? Когда объектов в разных БД станет много, и они начнут использоваться совместно.

Указывая на сотни тысяч работающих БД в мире, и при том, что среди них многие -большого объема, можно задать вопрос: как же "нереализуемо", ведь "работает" ? Мы-то с вами знаем как, и что дело здесь в абстракциях, а точнее в их уровне. Не знаю, как в остальном мире, но в Российской Федерации отсутствует исчерпывающая система (хотя бы только) почтовых адресов, и разработка ее... как бы это сказать... по меньшей мере, отнимет много времени. А информационные системы нужно делать "уже вчера". Противоречие разрешается известным всем способом: принимается решение считать адрес [фактически] атомарным символьным значением, и, это значит, что волевым решением фиксируется конкретный уровень абстракции. Он вполне достаточен для маленьких баз (где список адресов можно просмотреть глазами), и терпим для средних (можно поставить более мощный сервер, и делать выборки в реальном времени) - и первый уровень компьютеризации предприятия оказывается закрыт на год, на несколько лет, быть может, намного. Но ведь не навсегда !

Слово "навсегда" в предыдущем абзаце и представления об "общемировом универсуме" объектов и "запредельной сложности" "больших" ИС в паре абзацев выше могут показаться здесь неуместными, однако возражающему "прагматику"-"конструктивисту" (см. начало статьи), можно предложить всего один пример: так называемую "проблему 2000-го года". Выбранный десятки лет назад в тысячах систем уровень абстракции для понятия "год" вдруг неожиданно стал неадекватен и привел сейчас к одной их наиболее дорогостоящих проблем за всю историю создания ИС, давая заработок разнообразным авторам технических решений и не оставляя чувства гарантированной уверенности у заказчика. Понятно, что 30 лет назад проблема 2000-го года мало кого из разработчиков беспокоила, но если бы вдруг тогдашние системы проектировались с возможностью регулирования уровня абстракции понятия "год", нынешних чудовищных расходов удалось бы избежать.

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

В общей перспективе очевидна желательность компьютерной поддержки концептуального проектирования, дающего действительно семантически насыщенный, теоретически проверенный и адаптирующийся по форме и по уровню абстрагирования инструмент моделирования (обозначенная эллипсами верхняя часть зоны "концептуальный уровень", см. Рисунок 3 и Рисунок 4). Пример с "проблемой 2000-го года" свидетельствует, что желательность этой перспективы совсем не маниловски-умозрительна. Но для нее понадобится вернуться к направлению, обозначенному трудно дававшимися работами по концептуальному проектированию, в значительной мере оставленным исследователями с начала 80-х годов. Подобные возвраты не новы для такой интенсивно динамичной области деятельности, как компьютерная. Они время от времени наблюдаются и в базах данных, и в других разделах информатики, и в них как таковых нет необычного. Возврат к концептуальному моделированию в ИС представляется очевидным. Когда же он произойдет именно, и в какой именно форме, загадывать трудно: это зависит от всех, работающих в этой области ИС, то есть в том числе и от читавших этот текст.