Системы управления базами данных в ГИС. Как правило, ГИС создаются на основе уже существующих систем управления базами данных (СУБД), приобретение или аренда СУБД составляет основную часть затрат на программное обеспечение системы. СУБД выполняет множество функций, которые в противном случае следовало бы программировать в ГИС. Различают два пути использования СУБД в ГИС:
1) выполнение ГИС-процедур полностью через СУБД, тогда доступ ко всем данным осуществляется только через СУБД и все данные должны удовлетворять требованиям, заложенным при ее разработке;
2) некоторые данные (обычно таблицы атрибутов и их отношений) доступны через СУБД, поскольку они вполне соответствуют модели, а к некоторым данным (обычно пространственно локализованным) доступ прямой, так как они не удовлетворяют требованиям модели СУБД.
ГИС добавляет географический аспект к уже существующим методам поиска и запроса. Сложность и разнообразие представления данных в ГИС, различимость в представлении позиционной и атрибутивной составляющей информации, необходимость ее обработки в контексте пространственной близости предъявляют своеобразные и повышенные требования к СУБД по сравнению с традиционной формой их использования.
Функции СУБД. Каждую СУБД принято характеризовать способностью выполнять следующие основные функции
• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• операции над БД;
• обеспечение надежности хранения данных в БД;
• поддержка языка управления БД.
Управление данными во внешней памяти. Эта функция обеспечивает организацию структуры внешней памяти как для хранения данных, входящих в БД, так и для служебных целей, например, для ускорения доступа к данным. В некоторых СУБД используются возможности файловых систем, в других работа производится на уровне функционирования устройств внешней памяти. В любом случае пользователи СУБД не обязаны знать, какая структура используется или как организованы файлы. Обычно в СУБД создает- ся собственная система наименования объектов БД.
Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера, существенно большего доступного объема оперативной памяти. Для того чтобы СУБД не зависела от скорости работы устройств внешней памяти, используется организация собственных наборов буферов оперативной памяти с определенными правилами замены и обновления буферов.
Операции над БД. Последовательность операций над БД, рассматриваемых СУБД как единое целое, называется транзакцией.При выполнении транзакции СУБД либо фиксирует во внешней памяти изменения в БД, произведенные этой транзакцией, либо не производит никаких изменений. Понятие транзакции важно для сохранения логической целостности БД, особенно в многопользовательских СУБД. Каждая транзакция начинается при целост- ном состоянии БД и оставляет это состояние целостным после своего завершения. При эффективном управлении параллельно выполняюшимися транзакциями со стороны СУБД каждый из пользователей может ощущать себя единственным ее пользователем.
Управление транзакциями в многопользовательской СУБД осуществляется с помощью специальных операций, которые объединяют транзакции одного пользователя в серии (сериализация транзакций), при этом суммарный эффект смеси транзакций эквива- лентен эффекту их последовательного выполнения. Существует несколько базовых алгоритмов сериализации транзакций, средикоторых наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД.
Обеспечение надежности хранения данных в БД. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти, т.е. СУБД должна обладать способностью восстановления последнего согласованного состояния БД после любого аппаратного или программного сбоя. Возможны два вида аппаратных сбоев: «мягкие» сбои, которые приводят к внезапной остановке работы компьютера (например, аварийное выключение питания), и «жесткие» сбои, характеризуемые потерей информации на носителях внешней памяти. Программные сбои — это аварийное завершение работы СУБД или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Для восстановления БД нужно располагать некоторой дополнительной информацией, что требует избыточности хранения данных. Наиболее распространенным методом поддержания такой избыточной информации является ве- дение журнала изменений БД.
Журнал — это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физи- ческих лисках), в которую поступают записи обо всех изменениях основной части БД. Самая простая процедура обеспечения надежности восстановления БД — откат транзакции, выполненной пользователем, для чего все записи от одной транзакции связывают обратным списком от конца к началу (аналог Undo).
При «мягком» сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты,модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при «мягком» сбое пропадает). В таком случае во внешней памяти журнала должны обязательно находиться записи, относящиеся к операциям модификации обоих видов объектов. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД.
Поддержка языков управления БД. Для работы с базами данных используются специальные языки, называемые языками баз данных. Первоначально в СУБД поддерживалось несколько специализированных по функциям языков. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в на- стоящее время реляционных СУБД является язык SQL (Structured Query Language). Язык SQL позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД, которые тоже хранятся в специальных таблицах-каталогах. Обеспечение контроля целостности БД произ- водится на языковом уровне. Компилятор SQL для операторов модификации БД на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляцион- ной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить «видимость» БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными правами доступа к БД.Пользователь, создавший таблицу БД, обладает полным набором прав для работы с этой таблицей, в том числе правом разрешения доступа другим пользователям. Контроль прав доступа поддержи- вается на уровне языка.
Типовая организация СУБД. Организация типичной СУБД и состав ее компонентов соответствуют рассмотренному набору функций. СУБД представляет собой три взаимосвязанные компоненты: командный язык для выполнения требуемых операций с дан- ными (ввод, вывод, модификация), интерпретирующую систему(или компилятор) для обработки команд и перевода их на язык машины, интерфейс пользователя для формирования запросов к БД (выборки нужных данных).
Логически в реляционной СУБД можно выделить:
• внутреннюю часть — ядро СУБД (часто его называют Data Base Engine);
• компилятор языка БД (обычно SQL);
• подсистему поддержки времени выполнения;
• набор утилит.
В некоторых системах эти части выделяются явно, в других нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление: данными во внешней памяти, буферами оперативной памяти, транзакциями, а также за ведение журнала. Компоненты ядра — это соответственно менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно организованным протоколам. Ядро СУБД является основной резидентной частью СУБД, а в архитектуре «клиент-сервер» — основной составляющей серверной части системы.
Основной функцией компилятора языка БД является перевод операторов языка БД в некоторую выполняемую программу. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто во внутреннем машинно-независимом коде.
В отдельные утилиты БД обычно выделяют такие процедуры,которые слишком накладно выполнять с использованием языка БД, например загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД.
К числу достоинств реляционного подхода можно отнести:
• наличие небольшого набора приемов для простого абстрактного представления объектов большинства распространенных областей применения БД с интуитивно понятными и достаточно точными формальными определениями;
• наличие простого математического аппарата, опирающегося на теорию множеств и математическую логику, обеспечивающего основу реляционного подхода к организации баз данных;
• возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
Отмеченные преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что в середине 80-х годов XX в. реля- ционные системы практически вытеснили с мирового рынка ранние СУБД.
К недостаткам реляционных СУБД относятся некоторая ограниченность (как следствие простоты) их использования при сложных структурах данных, в том числе пространственно-определенных данных разных моделей, а также невозможность адекватного отражения семантики предметной области.
Базовые понятия реляционных баз данных. В преобладающем большинстве ГИС используются реляционные базы данных, поддерживаемые такими СУБД, как dBase, INFO, ORACLE,INFORMIX и т.п. Такие БД позволяют разработчикам ГИС разделить проблему управления пространственными данными на две части: как представлять геометрию объектов и топологию пространственных объектов (вектор или растр) и как работать с атрибутами этих объектов. Для этого пригодны реляционные СУБД, управляемые ими модели данных иногда называют геореляционными моделями. Основные их преимущества таковы:
♦ нет необходимости хранить атрибуты с пространственными данными, но они всегда могут содержаться где-нибудь в системе или поставляться, например, по сети;
♦ атрибуты могут быть изменены или удалены без изменения пространственной БД;
♦ коммерческие реляционные СУБД стандартны и могут управляться стандартными запросами;
♦ хранение атрибутивных данных в реляционных БД не противоречит основным принципам слоев в ГИС;
♦ атрибуты могут быть привязаны к пространственным единицам и представлены разными способами.
Основными понятиями реляционных баз данных являются: тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Понятие тип данных полностью адекватно понятию типа данных в языках программирования. Обычно в реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких, как «деньги»), а также специальных данных — дата, время, временной интервал. Развивается подход к расширению возможностей реляционных систем абстрактными типами данных.
Понятие домен имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Наиболее правильное интуитивное понимание домена — допустимое множество значений определенного типа. Данные считаются сравнимыми только в том случае, когда они относятся к одному домену.
Отношение — это именованное множество пар {имя атрибута,имя домена (или типа)}. Если все атрибуты одного отношения определены на разных доменах, целесообразно использовать для наименования атрибутов имена соответствующих доменов.
Кортеж, соответствующий данной схеме отношения, — это набор именованных значений заданного типа.
Обычным представлением отношения является таблица, в заголовке которой указывают наименование отношения, а в строках — кортежи; в этом случае имена атрибутов именуют столбцы таблицы. Поэтому когда говорят «столбец таблицы», имеют в виду «атрибут отношения». Такой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Реляционная модель данных. Модель данных с точки зрения СУБД описывает некоторый набор родовых понятий и признаков, которыми должны обладать сама СУБД и управляемые ею базы данных, если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.
Реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной, манипуляционной и целостной.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, являетсянормализованное отношение — некоторый определенный набор ограничений, свойственный этому отношению. Нормализация связана с поиском наиболее простой струетуры для данного множества данных и имеет дело с зависимостью между атрибутами; она позволяет избежать потери общей информации при удалении или вводе записей. Существует несколько формальных типов нормализации (более пяти).
Манипуляционная часть модели определяет механизм манипулирования реляционными БД — реляционная алгебра и реляционное исчисление, базирующиеся на теории множеств и логиче- ском аппарате исчисления отношений.
В целостной части реляционной модели данных фиксируются два базовых требования целостности: целостности сущностей и целостности по ссылкам. Объекту, или сущности, реального мира в реляционных БД соответствуют записи (кортежи) отношений, и требование целостности состоит в сохранении отличий разных записей этого отношения; говорят, что любое отношение должно обладать первичным ключом.
Второе требование более сложно. Сущности реального мира представляются в реляционной БД в виде записей нескольких отношений. Для связи отношений используется атрибут, который служит внешним ключом. Отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам состоит в том, что для каждого значения внешнего ключа должна найтись запись с таким же значением первичного ключа в отношении, на которое указывает ссылка, либо значение внешнего ключа должно быть неопределенным (те. ни на что не указывать).
Выполнение таких требований чрезвычайно важно при модификации отношений или удалении записей. Поддержке целостности при удалении кортежа служат: запрет на удаление кортежа, на который существуют ссылки; автоматическая замена значения внешнего ключа на неопределенное во всех ссылающихся кортежах; автоматическое удаление всех ссылающихся кортежей.
Реляционные СУБД обладают рядом особенностей, влияющих на организацию внешней памяти. К наиболее важным особеннос-тям можно отнести следующие:
• наличие двух уровней системы: уровня непосредственного управления данными во внешней памяти и языкового уровня (например, уровня, реализующего язык SQL); тогда подсистема нижнего уровня должна поддерживать во внешней памяти набор базовых структур, конкретная интерпретация которых входит в число функций подсистемы верхнего уровня;
• информация, связанная с наименованием объектов базы данных и их конкретными свойствами (например, структура ключаиндекса), поддерживается подсистемой языкового уровня;
• регулярность структур данных во внешней памяти, поскольку основным объектом реляционной модели данных является плоская таблица;
• для выполнения операторов языкового уровня над одним или несколькими отношениями во внешней памяти поддерживаются дополнительные «управляющие» структуры — индексы;
• для выполнения требования надежного хранения баз данных поддерживается избыточность хранения данных во внешней памяти.
Следует подчеркнуть, что как бы ни были организованы индексы в конкретной СУБД, их основное назначение состоит в обеспечении эффективного прямого доступа к кортежу отношения по ключу. Обычно индекс определяется для одного отношения, и ключом является значение атрибута (возможно, составного). Организация индексов в больших БД представляет сложную проблему. Все более популярным подходом к организации индексов является использование техники хэширования. Общей идеей методов хэширования является применение к значению ключа некоторой функции свертки (хэш-функции), вырабатывающей значение мень- шего размера. Свертка значения ключа затем применяется для доступа к записи. В самом простом случае свертка ключа используется как адрес в таблице, содержащей ключи и записи.
СУБД в архитектуре клиент-сервер». Архитектура «клиент-сервер» обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети, создавая некоторое подобие распределенных систем БД. Реальное распространение архитектуры «клиент-сервер» стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем. Основой этой концепции является упрощение комплексирования вычислительных систем при международной и национальной стандартизации аппаратных и программных интерфейсов. Стимулом для развития концепции явились, с одной стороны, широкое внедрение локальных компьютерных сетей с комплексированием аппаратно-программных средств, с другой —бурное развитие технологий глобальных коммуникаций. Реальностью становятся и открытые ГИС-системы, несмотря на существующие проблемы в области стандартизации.
Ключевой позицией открытых систем, ориентированных на пользователей, является независимость от конкретного разработчика аппаратного и программного обеспечения. Приобретая любой продукт компании, придерживающейся стандартов открытых систем, потребитель не становится полностью от нее зависимым. Он может развивать свою систему, приобретая продукты любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных, так и программных средств и не является необоснованной декларацией. Примерами всестороннего исследования и реализации подходов к созданию открытых ГИС-систем являются программные и технологические разработки крупнейших фирм конкурентов ESRI и Intergraph — GEONET и GeoMedia соответственно.
Основой системных и прикладных программных средств открытых систем является стандартизованная операционная система. Технологии и стандарты открытых систем обеспечивают возможность производства программных средств, обладающих свойствами мо- бильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту перено са программной системы в различные аппаратно-программные среды, соответствующие стандартам. Интероперабельность означает упрощение разработки новых программных систем на основе комплексирования готовых компонентов со стандартными интерфейсами.
Использование подхода открытых систем выгодно и производителям, и пользователям. Прежде всего открытые системы решают проблемы поколений и версий аппаратных и программных средств. Все производители обязаны только обеспечивать некоторую стандартную среду. Преимуществом для пользователей является то, что они могут постепенно заменять компоненты системы более совершенными, не утрачивая работоспособности системы, решать проблемы постепенного наращивания вычислительных, информационных и других мощностей компьютерной системы.
В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах.
Развитие этой идеи приводит к функциональному выделению компонентов сети: разумно иметь не только доступ к ресурсам удаленного компьютера, но также получать от этого компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства для обеспечения которого нецелесообразно дублировать в нескольких узлах.
Рабочая станция предназначена для непосредственной работы пользователя или категории пользователей и обладает ресурсами, соответствующими локальным потребностям данного пользователя. Специфическими особенностями рабочей станции являются:
— объем оперативной памяти (далеко не все категории пользователей нуждаются в наличии большой оперативной памяти);
— наличие и объем дисковой памяти (достаточно популярны бездисковые рабочие станции, использующие внешнюю память дискового сервера);
— характеристики процессора и монитора (некоторым пользователям нужен мощный процессор, других в большей степени интересует разрешающая способность монитора, для третьих обязательно требуются средства ускорения графики и т.д.). При необ- ходимости можно использовать ресурсы и/или услуги, предостав- ляемые сервером.
Сервер локальной сети должен обладать ресурсами, соответствующими его функциональному назначению и потребностям сети. Заметим, что в связи с ориентацией на открытые системы, пра- вильнее говорить о логических серверах (имея в виду набор ресурсов и программных средств, обеспечивающих услуги над этимиресурсами), которые располагаются не обязательно на разных ком пьютерах. Особенностью логического сервера в открытой системе является то, что если по соображениям эффективности сервер целесообразно переместить на отдельный компьютер, то это можно проделать без реконструкции как его самого, так и использую- щих его прикладных программ.
Примерами серверов могут служить:
♦ сервер телекоммуникаций, обеспечивающий услуги по связи данной локальной сети с внешним миром;
♦ вычислительный сервер, дающий возможность производить вычисления, которые невозможно выполнить на рабочих станциях;
♦ дисковый сервер, обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциям и, возможно, другим серверам;
♦ файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;
♦ сервер баз данных — фактически обычная СУБД, принимающая запросы по локальной сети и возвращающая результаты.
Сервер локальной сети предоставляет ресурсы рабочим станциям и другим серверам.
Принято называть клиентом локальной сети запрашивающего услуги у некоторого сервера и сервером — компонент локальной сети, оказывающий услуги некоторым клиентам.
Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Соблюдая предосторожности при программировании, можно создавать прикладные информационные системы, мобильные в классе SQL-серверов.
Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД опреде- ляется при установке системы.
Особенно важны в системах управления базами данных, основанных на архитектуре «клиент-сервер», протоколы удаленного вызова процедур. Использование механизма удаленных процедур позволяет перераспределять функции между клиентской и серверной частями системы, а также скрывать различия между взаимодействующими компьютерами. Физически неоднородная локальная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате пользователи не обязаны заботиться о разовой закупке совместимых серверов и рабочих станций.
Обычно на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с исполь- зованием языка SQL. С другой стороны, иногда хотелось бы перенести большую часть прикладной системы на сторону сервера.
Очевидно, что требования к аппаратуре и программному обеспечению клиентских и серверных компьютеров различаются в зависимости от вида системы.
Распределенные БД. Основная задача систем управления распределенными базами данных состоит в обеспечении средствами интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных.
Возможны однородные и неоднородные распределенные базы данных. В случае однородных БД каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных — очень сложная проблема. Более успешно практически решается промежуточная задача — интеграция неоднородных SQL-ориентированных систем.
Интегрированные и мультибазы данных. Проблема интегрированных (федеративных) неоднородных БД и мульти-БД возникла в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление возможности автоматического преобразования операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая, тем не менее, иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, развивается направление мульти-БД.
В системах мулы и-БД не создастся глобальная схема интегрирования, а применяются специальные способы наименования для доступа к объектам локальных БД. В таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети, а это в свою очередь приводит к дополнительным проблемам интеграции: управление глобальными транзакциями, сетевая оптимизация запросов и т.д.
Для внешнего представления интегрированных и мульти-БД обычно используется реляционная модель данных, но в настоящее время все чаще предлагаются объектно-ориентированные модели.
Объектно-ориентированные структуры БД. В последнее время, особенно в разработках фирмы ESRI, большое внимание стало уделяться четвертому типу СУБД — объектно-ориентированному(здесь этот термин имеет отношение только к структуре БД и язы- ку программирования, а не к объекту как реальности). Применение таких СУБД направлено на снижение объемов хранимой информации и времени последовательного поиска в БД. В ГИС такие структуры применяются, когда появляется необходимость управления сложными реальными объектами более разумным способом, чем простыми точками, линиями и полигонами, а также модификация БД при оверлее полигонов.
В объектно-ориентированных БД требуется, чтобы географические данные представляли собой совокупность элементов. При этом они характеризуются серией атрибутов и параметров поведения,которые определяют их пространственные, графические, времен- ные, текстовые/численные размерности. Примерами таких элементов могут служить: участок железной дороги и связанное с ним здание вокзала; узел трубопровода с ответвлениями из труб разного диаметра и т.п. Такая структура позволяет унифицировать хранение геометрии и атрибутов при отображении взаимосвязанных объектов.
Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Первые публикации появлялись уже в середине 80-х годов XX в., однако наиболее активно это направление развивается в последние годы. Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработю! сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
Основу развития ООБД обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно ну че заебались читать ориентированных языков программирования. Я тоже вообще дохрена исключительное влияние на концепции ООБД и всего объектно-ориентированного подхода оказал переход к семантическому моделированию данных.
При наличии большого количества функционирующих проектов и коммерческих систем (пример — разработки ESRI) отсутствует общепринятая объектно-ориентированная модель данных по причине отсутствия общего согласия о принятии какой-либо модели. Имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:
♦ объекта и идентификатора объекта;
• атрибутов и методов;
♦ классов;
• иерархии и наследования классов.
Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.
Каждый объект характеризуется состоянием и поведением. Состояние объекта — набор значений его атрибутов. Поведение объекта — набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта — это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов иметодов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.
Допускается порождение нового класса на основе уже существующего класса — наследование. В этом случае новый класс, называемый подклассом существующего класса, наследует все его атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного класса, во втором случае классов может быть несколько.
При таком наборе базовых понятий (кроме наследования) объектно-ориентированный подход очень близок к подходу языков программирования с абстрактными (или произвольными) типами данных.
С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных. Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентиробанном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования — основа формирования классов объектов. ,
Наиболее важным качеством ООБД является поведенческий аспект объектов. В прикладных системах с традиционной организацией БД существовал принципиальный разрыв между структур- ной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать и т.д., а поведенческая часть создавалась изолированно. В среде ООБД проектирование, разработка и сопровождении прикладной системы становятся процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему.
Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения. Эти потребности касаются спецификации знаний при определении класса (ограничений целостности, правил дедукции и т. п.), определении разного рода семантических связей между объектами, вообще говоря, разных классов и пересмотра понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия типа и класса объектов.
Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует.
Принято выделять два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связей. База данных — это набор элементов данных, связанных отношениями «входит в класс» или «является атрибутом». Важными моментами являются поддержание наряду спонятием «объект» понятия «значения», а также четкое разделение схемы БД и самой БД. Не ну это же совсем много
