5. Модели и этапы проектирования баз данных

5.1. Модели многоуровневой архитектуры систем баз данных

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

Опубликованный в 1975 году отчет ANSI/X3/SPARC зафикси­ровал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделе­ния специального концептуального уровня представления базы дан­ных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уро­вень, который должен обеспечивать поддержку представления хра­нимой базы данных, и внешний, поддерживающий представления базы данных «с точки зрения» приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем (прикладном, пользовательском) уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются соответственно внешней, концептуальной и внутренней.

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

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

Проектирование базы данных — это упорядоченный формали­зованный процесс создания системы взаимосвязанных описаний³², т. е. таких моделей предметной области, которые связывают (фик­сируют) хранимые в базе данные с объектами предметной области, описываемыми этими данными. Прикладное назначение таких опи­саний состоит в том, чтобы пользователь, практически не имеющий представления об организации данных в БД (физическом размеще­нии в памяти данных и механизмах их поиска), обращая запрос к базе, имел бы практическую возможность получить адекватную ин­формацию о состоянии объекта предметной области. Проектирование начинается c анализа предметной области и выявления функциональных и других требований к проектируемой системе. Подробнее этот процесс мы рассмотрим ниже, а здесь отметим, что проектирование обычно выполняется человеком (группой людей) — системным аналитиком (а на практике чаще администратором базы данных), которым может быть как специально выделенным сотрудником, так и будущим пользователем базы данных, достаточно хорошо знакомым с машинной обработкой данных.

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

Такая человеко-ориентированная модель практически полно­стью независима от физических параметров среды хранения данных, которой может быть как память человека, так и ЭВМ. Поэтому инфологическая модель не изменяется до тех пор, пока какие-то из­менения в реальном мире (той его части, которая отнесена к пред­метной области) не потребуют изменения в модели соответствую­щего фрагмента описания, чтобы эта модель продолжала адекватно отражать предметную область.

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

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

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

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

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

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

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

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

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

О развитии и конкурировании моделей. По аналогии с ситуацией 70-х гг., когда велись споры о преимуществах сетевой, иерархической и реляционной модели данных (как известно, завершившиеся «ничейным» исходом открытой дис­куссии Ч. Бахмана и Э. Кодда на Конференции ACM SIGMOD в 1975 г.), в на­стоящее время сформировались новая тройка конкурентов — реляционная, объектная и многомерная модели.

Хотя, строго говоря, здесь речь идет лишь о двух моделях. Действительно, многомерные модели, коммерческие реализации которых появились в начале 90-х гг. для поддержки технологий OLAP не основаны на каких-либо радикаль­но новых идеях. Они представляют собой некоторое расширение активно иссле­довавшейся в 70—80-х п. модели универсальных отношений новыми операци­онными возможностями, обеспечивающими, в частности, необходимые для OLAP функции агрегирования данных. Таким образом, многомерные модели представляют собой особую разновидность реляционной модели.

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

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

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

Именно на достижение этой цели направлены интенсивные разработки WWW-консорциумом языка XML и его инфраструктуры (фактически новой мо­дели данных для этой среды), объектной модели документов и других средств, которые, как можно ожидать, скоро станут основой технологий управления ин­формационными ресурсами. Это направление связано с другой глобальной про­блемой — организацией распределенных неоднородных информационных сис­тем на основе построения репозитариев метаданных, обеспечивающих возмож­ность семантического отождествления ресурсов и, таким образом, возможность их целенаправленного повторною использования.