Модели, базы данных и СУБД в информационных системах

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

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

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

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

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

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

Использование модели данных при работе с БД (в "компьютерном" смысле, в смысле хранения структур данных) неизбежно по нескольким причинам. Во-первых, модель дает общий язык пользователям, работающим с данными. Во-вторых, модель может обеспечить предсказуемость результатов работы с данными. Становится возможным объяснить пользователю, почему он получил конкретный результат при просмотре или изменении данных, и наоборот, работающий с базой может предвидеть, какого сорта он получит результат. За время существования разработок программных систем предложено много различных моделей разной степени распространенности. На некоторых можно остановиться.

Реляционная модель и СУБД

Не будучи хронологически первой, наиболее популярной с начала 80-х гг. была и до сих пор остается реляционная модель данных. Она первая получила математическое описание, и она экономна по части базовых понятий. Первое повлекло возможность тщательного и интенсивного исследования свойств этой модели (немедленно реализованного в обширной литературе), а второе сделало ее привлекательной для программистов и пользователей.

В реляционной модели считается, что все данные ИС представлены в виде таблиц [2]. Строки в каждой таблице - это кортеж неструктурированных единиц данных, "атрибутов". Набор кортежей, составляющий таблицу, образует математическое отношение; таким образом, модель данных представляется множеством таблиц-отношений (называемых также R-таблицами); отсюда название "реляционная", т.е. модель, представленная отношениями.

Атрибуты строк-кортежей (и таблиц-отношений) - это значения из заданных наравне с таблицами областей определения ("доменов"). Разные столбцы в одной и той же или в разных таблицах могут иметь одну и ту же область определения, а могут - разные.

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

Реляционная база данных - это набор R-таблиц и только R-таблиц, т.е. считается, что никаким иным образом (переменные, массивы и т.п.) данные в базе не представлены.

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

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

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

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

Вскоре после появления идея (и теория) реляционных баз данных стала популярна среди разработчиков СУБД. Однако сделать реляционную СУБД оказалось непросто. Сложилась неоднозначная ситуация, когда после некоторых усовершенствований одни фирмы стали называть свои разработки реляционными (иногда просто добавляя '/R' к имени своей СУБД), а другие - отказываться от создания реляционных СУБД в силу сложности задачи. Для того чтобы внести ясность в оценку разработок одних фирм и более определенно сформулировать цель, к которой разработчикам нужно стремиться, для других (или тех же самых) фирм, Е. Кодд, автор реляционного подхода, в конце 70-х гг. опубликовал свои 12 правил соответствия произвольной СУБД реляционной модели (2) [3], дополнив основные понятия реляционных баз данных определениями, важными для практики. Ниже приводятся эти правила вместе с дополняющим их подразумеваемым общим положением.

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

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

2. Правило гарантированного логического доступа. К каждому имеющемуся в реляционной базе атомарному значению должен быть гарантирован доступ с помощью указания имени R-таблицы, значения первичного ключа и имени столбца.

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

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

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

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

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

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

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

10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

11. Правило независимости от распределенности. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределенными данными) или перераспределения (если СУБД действительно распределенная).

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

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

Другие модели

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

Моделью данных, привлекающей нарастающее внимание с конца 80-х гг., является объектная, или "объектно-ориентированная"(3) модель (см., например, одну из первых работ [5]). Основными понятиями, с которыми оперирует эта модель, являются следующие: объекты, обладающие внутренней структурой и однозначно идентифицируемые уникальным внутрисистемным ключом; классы, являющиеся по сути типами объектов; операции над объектами одного или разных типов, называемые "методами"; инкапсуляция структурного и функционального описания объектов, позволяющая разделять внутреннее и внешнее описания (в терминологии предшествовавшего объектному модульного программирования - "модульность" объектов); наследуемость внешних свойств объектов на основе соотношения "класс-подкласс".

К достоинствам объектно-ориентированной модели обычно относят: возможность для пользователя системы определять свои сколь угодно сложные типы данных (используя имеющийся синтаксис и свойства наследуемости и инкапсуляции); наличие наследуемости свойств объектов; повторное использование программного описания типов объектов при обращении к другим типам, на них ссылающимся.

К недостаткам объектно-ориентированной модели можно отнести: отсутствие строгих определений; разное понимание терминов и различия в терминологии (в [7], например, изъявляется готовность изложить восемь различных толкований такого базового понятия, как "наследуемость"); как следствие - эта модель не исследована столь тщательно математически, как реляционная; отсутствие общеупотребимых стандартов, позволяющих связывать конкретные объектно-ориентированные системы с другими системами работы с данными.

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

Еще одной моделью данных, имеющей конкретную реализацию (система InfoModeller), является модель "объектов-ролей", предложенная еще в начале 70-х годов, однако выведенная за рамки академических исследований совсем недавно коллективом фирмы Asymetrix [5]. В отличие от реляционной модели в ней нет атрибутов, а основные понятия - это объекты и роли, описывающие их. Роли могут быть как "изолированные", присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель, по словам авторов, служит для понятийного моделирования, что отличает ее от реляционной модели. Имеются и другие отличия и интересные особенности: например, для нее помимо графического языка разработано подмножество естественного языка, не допускающее неоднозначностей, и, таким образом, пользователь (заказчик) не только общается с аналитиком на естественном языке, но и видит представленный на том же языке результат его работы по формализации задачи. (Можно заметить, что многие пользователи, в отличие от аналитиков, с трудом разбираются в описывающих их деятельность рисунках и схемах.) Модель "объектов-ролей" сейчас привлекает большое внимание специалистов, однако до промышленных масштабов ее использования, сравнимых с двумя предыдущими, ей пока далеко.

Взаимосвязь моделей данных

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

Много дебатов, к примеру, ведется по вопросу, совместимы ли и если да, то каким образом, реляционная и объектная модели. Существуют мнения, что они взаимоисключают друг друга и что они взаимодополняют друг друга. Последнего придерживается, например, такой авторитет в области теории баз данных, как К.Дейт [7]. Согласно Дейту синергия двух моделей могла бы ("должна" - по утверждению автора) базироваться на формуле "область определения атрибута = класс объектов". Иными словами, атрибутами в реляционных таблицах могут быть объекты произвольно заданной сложности. С точки зрения реляционной модели они остаются атомарными, а все возможности работы с ними, проистекающие из наличия внутренней структуры, реализуются объектно-ориентированными методами. Существует выбор, какие свойства предметной области моделировать реляционными методами (т.е. моделировать таблицами, связанными друг с другом ключами), а какие - объектными, но это уже составляет проблему разработчика базы данных: теория здесь лишь предоставляет возможности такого выбора. Предложение Дейта не противоречит ни реляционному, ни объектному подходу и выглядит теоретически обоснованным. В то же время оно противоречит другому подходу, основывающемуся на формуле "класс объектов = таблица", когда с объектом связывается строка таблицы. Этот подход получил распространение в практике производителей объектно-ориентированных СУБД.

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

Переход от модели "объекты-роли" к реляционной заложен создателями в основу реализации первой. Модель "объекты-роли" согласно такой позиции рассматривается как понятийная, а реляционная модель - как реализационная. Трансформация определений "объектов-ролей" в реляционные определения не просто возможна, а и изначально предположена в InfoModeller, причем гарантируется высокое качество результата такого преобразования: получаемые таблицы имеют так называемую "5-ую нормальную форму", считающуюся более качественной в реляционном плане, чем обычно требуемая в реляционных СУБД "3-я нормальная форма".

Программная реализация моделей данных, т.е. построение СУБД или программных систем, наталкивается на большие сложности. Наиболее отчетливо это видно на примере реляционной модели, для которой ни одной СУБД, если следовать строго определениям, не создано. Вместо этого имеется целое семейство систем, в той или иной степени поддерживающих язык работы с данными SQL. SQL изначально появился как язык для реляционных СУБД, однако по мере своего практического развития он все больше и больше отклонялся от реляционности. Причиной тому являются как принципиальные проблемы реализации, так и организационно-рыночные факторы, не позволяющие разным производителям СУБД договориться о "правильном" стандарте. Реально сейчас известно три основных стандарта [6]: SQL89, SQL92, SQL95 (в процессе разработки).

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

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

Реализованные SQL-системы

Первой системой, реализовавшей поддержку придуманного для этой же системы и самого первого варианта SQL, была Система R, разработанная в фирме IBM в конце 70-х гг. Система R не была коммерческим продуктом, каковым стало ее развитие - семейство СУБД DB2, существующих сейчас на большинстве машин этой фирмы. Первой же коммерческой SQL-системой стала СУБД Oracle, выпущенная во второй половине 80-х гг. фирмой, носящей теперь то же название. К середине 90-хгг. промышленно поставляемых SQL-систем стало довольно много, но если говорить о наиболее распространенных, то к ним относятся DB2, Oracle, Sybase и Informix. С рыночной точки зрения между этими (и "догоняющими" их) системами существует жесткая конкуренция, что имеет положительные для пользователя стороны: фирмы-разработчики систем постоянно следят за достижениями конкурентов и подхватывают друг у друга новые технологические идеи, не допуская крупных отставаний. С другой стороны, как указывалось, привнесение рыночных факторов в выработку стандартного общеупотребимого SQL сказывается отрицательно как на сроках разработки стандарта, так и на его качестве.

Другие системы

Хотя в количественном отношении объектно-ориентированные системы явно и значительно уступают реляционно-ориентированным, все же их разнообразие также велико. Можно указать на такие непохожие друг на друга системы, как Smalltalk, C++, Delphi и даже объектно-ориентированную версию языка Cobol. В отличие от SQL-ориентированных систем промышленные объектно-ориентированные не расчитаны на большую производительность и интенсивную переработку данных; они чаще служат для быстрой разработки небольших приложений или клиентской части больших систем. Другую группу образуют объектно-ориентированные СУБД, предназначенные для того, чтобы дать возможность пользователю создавать в рамках объектного подхода объекты предметной области и работать с ними. К таким СУБД относятся ONTOS, GemStore, UniSQL и др. (см. в [8]).

Нельзя не заметить схожести объектного подхода с сетевой моделью проектирования баз данных, распространенной в 70-х гг. (модель данных CODASYL [9]) и практически не встречающейся в новых системах сейчас. Многие из идей, тщательно разработанных в свое время в подходе CODASYL, появляются в более поздних системах вторично, как это, например, стало с процедурами баз данных, относительно недавно появившихся в SQL-системах.

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

(1) К сожалению, это общее суждение не всегда применимо в некоторых "деталях".

(2) Лиха беда начало: позже появились 12 правил К. Дейта оценки соответствия системы распределенной СУБД, а в начале 90-х – 12 правил E. F. Codd & Associates соответствия системы системам оперативной аналитической обработки данных, "OLAP-системам".

(3) Правильнее было бы говорить об "объектной модели" и "объектно-ориентированных реализациях" этой модели на ЭВМ. Оправданием термина "объектно-ориентированная модель" может служить, во-первых, традиция и, во-вторых, отсутствие общепринятого определения объектной модели.

(4) В. И. Филиппов, частное сообщение.

1. Webster's Tenth New Collegiate Dictionary, 1967.

2. Pascal F. Understanding Relational Databases with Examples in SQL-92. John Wiley & Sons, 1993.

3. Codd E. F. An Evaluation Scheme for Database Management Systems that are Claimed to be Relational. Proc. IEEE CS International Conference, no. 2 on Data Engineering, Los Angeles, February, 1986.

4. The Xerox Learning Research Group.// The Smalltalk-80 System, Byte, 1981. V. 6. No.8. August. PP. 36-48.

5. Halpin T. Using Object Role Modelling to Design Relational Databases: Interview.// DBMS, 1995. V. 8. No. 9 (September). P. 38.

6. Дадли К. Соответствие стандарту SQL.// Мир Oracle, 1996. № 1 (39). Январь - март. (Перевод на русский язык) С. 7-16.

7. Date C. J. Moving Forward with Relational: Interview.//DBMS, 1994. V. 7. No. 10 (October). P. 62.

8. Вон К. Технология объектно-ориентированных баз данных.// Открытые системы, 1994. Вып. 4 (8). Осень.P. 14.

9. Олле Т. В. Предложения КОДАСИЛ по управлению базами данных. М.: Финансы и статистика, 1981.