Модели данных концептуального уровня

Семантическая модель данных типа «сущность-связь» - ER -модель - впервые предложена в 1976 г. Ченом. Существует несколько вариантов графического представления модели «сущность-связь». На данное время единого графического формата представления ER -диаграмм не установлено.

Сущность - реальный или абстрактный объект ПрО, характеризующийся свойствами - атрибутами.

Атрибут сущности (класса объектов) – это именованное имманентное свойство объектов класса, описывающее множество значений, которые могут принимать экземпляры класса.

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

Например, сущность - «Транспортное_средство» (ТС) содержит в себе легковой автомобиль и грузовик – экземпляры сущности. Марка, цвет и государственный_номер ТС – атрибуты этой сущности (рис. 1).

Рис. 1. Класс «Транспортное_средство»
с именами атрибутов

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

Описание операции может содержать ее сигнатуру, т.е. имена и типы всех параметров, а если операция является функцией, то и тип ее значения. Класс «Транспортное_средство» с определенными операциями показан на рисунке 2:

Рис. 2. Класс «Транспортное_средство»
с операциями над объектами класса

Для класса «Транспортное_средство» мы определили три операции. Операции «Выдать_Имя_Владельца» и «Выдать_Код_Города » используют значение атрибута «Государственный_Номер». Операция «Сохранить_Текущий_Пробег» позволяет зафиксировать в состоянии объекта количество пройденных километров на текущую дату для данного ТС. Эти данные могут быть использованы, например, для определения суммарного пробега указанного ТС за указанное время. Заметим, что состояние объекта меняется при выполнении только третьей операции. Результаты первой и второй операций формируется на основе текущего состояния объекта.

Между сущностями устанавливаются связи. Связь - соответствие или отображение между элементами (объектами) двух или более экземпляров сущности (класса).

Различают несколько разновидностей связей:

Ø 1:1 - один к одному: один экземпляр сущности связан с одним и только одним экземпляром другой сущности.

Ø 1:M или М:1 - один ко многим: один экземпляр первой сущности соответствует нескольким экземплярам второй сущности.

Ø M:N - многие ко многим: каждому экземпляру одной сущности соответствует несколько экземпляров другой сущности и наоборот.

При проектировании в диаграмме классов могут присутствовать связи трех разных категорий: зависимость, обобщение и ассоциирование. Для проектирования реляционных БД наиболее важны вторая и третья категории связей [Замулин А.В. Системы программирования баз данных].

Зависимостью называют связь по использованию, когда изменение в спецификации одного класса может повлиять на поведение другого, использующего первый класс. Чаще всего зависимости применяются в диаграммах классов, чтобы отразить в сигнатуре операции одного класса тот факт, что параметром этой операции могут быть объекты другого класса. Понятно, что если интерфейс второго класса изменяется, то это влияет на поведение объектов первого класса. Простой пример диаграммы классов со связью-зависимостью показан на рисунке 3. Зависимость показана прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость. Легко видеть, что связи-зависимости существенны для объектно-ориентированных систем (в том числе и для объектно-ориентированных баз данных).

Рис. 3. Зависимость между классами «Маршрут» и
«Расписание_Движения_Транспортного_Средства»

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

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

С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Ассоциации может быть присвоено имя, характеризующее природу связи. Пример именованной ассоциации показан на рисунке 4. Стрелка определяет направление связи: именованная ассоциация читается как: «Транспортное средство движется по данному маршруту».

Рис. 4. Именованная ассоциация

Ассоциация двух классов характеризует связь между равноправными сущностями: оба класса находятся на одном концептуальном уровне. Ассоциация двух классов, имеющая специальный вид «целое-часть» («part_of» - является частью), подразумевает, что класс «целое» имеет более высокий концептуальный уровень, чем класс «часть». Ассоциация такого рода называется агрегацией. Пример агрегатной ассоциации показан на рисунке 5: класс «Дорожно-Транспортное_Происшествие» (ДТП) является частью класса «Улица».

Рис. 5. Агрегатная ассоциация

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

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

Рис. 6. Композитная агрегатная ассоциация

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

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

2.1.1. Модели данных логического уровня

На логическом уровне данные представляются так, как они выглядят в реальном мире. Объектами логического уровня являются сущности и атрибуты. Модель логического уровня является универсальной, не связана с конкретной БД и представляется некоторой структурой данных.

Рис. 2.7. Сокращенная ER -модель атрибутивных данных ИТС

В литературе предложено и опубликовано достаточно много моделей данных. Они подразделяются на модели данных на основе записей (record-based)и объектные (object-based) и используются для описания данных на концептуальном уровне [Дейт К. Дж. Введение в системы баз данных].

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

В модели данных на основе записей база данных содержит записи фиксированного формата, которые могут иметь разные типы. Существует три основных типа логических моделей данных на основе записей: сетевая модель данных (network data model), иерархическая модель данных (hierarchical data model) и реляционная модель данных (relational data model).

Сетевая модель данных

Данные в сетевой модели представлены в виде ориентированной сети: вершины – это коллекции записей, а дуги – это связи, определенные в виде наборов, реализуемых с помощью указателей. Сетевую модель можно представить в виде графа, возможно имеющего циклы и петли: в сетевой структуре любой элемент может быть связан с любым другим элементом. Циклом считается ситуация, в которой родитель узла одновременно является его потомком. Отношение исходный - порожденный образуют при этом замкнутый контур. Петли часто представляют собой связь типа M: N.

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

Любая сетевая структура может быть приведена к более простому виду путем введения избыточности. Например, сеть может быть преобразована в дерево, если указать некоторые имена дважды.

Главное достоинство сетевых моделей – высокая общность: любую модель можно представить в виде сетевой модели, используя аппарат теории графов. К недостаткам следует отнести сложность реализации сетевой модели: не существует простых и легко реализуемых алгоритмов работы с графовыми структурами [Дейт К. Дж. Введение в системы баз данных].

Иерархическая модель данных

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

Иерархическая декомпозиция предметной области позволяет разбить ее на отдельные поименованные части и для каждой части (за исключением корня дерева) определить отношение предшествования.

Иерархическая модель реализуется в виде дерева, терминальные вершины которого соответствуют элементарным данным, корень – всей базе данных, а прочие вершины – структурным информационным объектам различной сложности: сущностям, экземплярам сущностей, атрибутам и значениям атрибутов (рис. 2.8). Древовидная структура имеет один особый узел - корень дерева, узлы-предки и узлы-потомки. Узлы дерева, не уточняемые на более низких уровнях иерархии, определяются как листья дерева.

Иерархические структуры реализуют отображения 1:1 и 1:М, однако, представление связи M: N имеет избыточность, т. к. возникает дублирование информации.

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

Рис. 2.8. Иерархическая модель БД

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

Недостатками являются избыточность при реализации связей типа M: N и проблемы, возникающие при манипулировании данными: удаление узла-предка регламентирует удаление всех узлов-потомков, невозможно хранить порожденный узел без исходного - нужен пустой исходный узел [Автоматизация проектирования вычислительных систем. Языки, моделирование и базы данных // Под ред. М. Брейера].

Реляционная модель данных

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

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

Элементами отношения являются кортежи – строки таблицы. Кортежи могут располагаться в любом порядке, при этом отношение будет оставаться тем же самым и иметь тот же смысл.

Степень отношения определяется количеством атрибутов, которое оно содержит. Унарное отношение имеет степень 1 и содержит один атрибут. Отношение с двумя атрибутами – бинарное, для отношений с большим количеством атрибутов используется термин n-арное.

Список имен атрибутов отношения называют схемой отношения. Схема отношения «Транспортное_Средство» представлена в табл. 1.

Таблица 1.

Схема отношения «Транспортное_Средство»

Государственный_номер	Марка	Цвет	...
Х371ОО 63 rus	ВАЗ 21102	Серебристый	...
A 001 BC 77 rus	ГАЗ 21102	Синий	...
...	...	...	...

Реляционная база данных – это совокупность взаимосвязанных отношений. Каждое отношение в компьютере представляется в виде файла. В таблице 2 приведено соответствие понятий, используемых в реляционных моделях.

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

Ø поле – наименьшая поименованная единица данных;

Ø запись – поименованная совокупность полей;

Ø файл – поименованная совокупность экземпляров записей одного типа;

Ø набор файлов или библиотека – поименованная совокупность файлов, обладающая семантическим единством.

Таблица 2.

Соответствие понятий реляционных моделей

Машинная реализация	Наглядное представление	Реляционный алгоритм	Концептуальный уровень
Файл	Таблица	Отношение	Сущность
Запись	Строка	Кортеж	Экземпляр сущности
Файл	Столбец	Подмножество домена	Атрибут

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

Объектно-ориентированная модель
данных

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

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

Объектно-ориентированная СУБД обладает возможностями:

Ø предоставления функциональных средств базы данных;

Ø поддержки идентичности объектов;

Ø обеспечения инкапсуляции и наследования.

Таким образом, «объектно-ориентированный подход» = «абстрактные типы данных» + «наследование» + «идентичность объектов»; «объектно-ориентированная СУБД» = «объектно-ориентированный подход» + «возможности базы данных». Дополнительные требования, предъявляемые к объектно-ориентированным СУБД:

Ø наличие высокоуровневого языка запросов, обладающего средствами оптимизации, реализованными в базовой системе;

Ø поддержка перманентности и сохранение неразрывности транзакций, обеспечиваемые механизмами управления параллельным выполнением и восстановлением;

Ø поддержка сложных объектных хранилищ, индексов и методов доступа, предназначенных для быстрой и эффективной выборки данных.

2.2. Проектирование объектно-ориентированных СУБД

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

Ø Автоматизированное проектирование (CAD – Computer Aided Design). Как правило, проекты имеют большие объемы со многими взаимозависимыми проектами подсистем. Проекты эволюционируют во времени, обновление данных сопровождается далеко идущими последствиями из-за имеющихся связей, функциональных зависимостей и т.д.

Ø Автоматизированная разработка программного обеспе­чения (CASE – Computer Aided Software Engineering). В базах данных таких систем хранятся данные, относящиеся к различным этапам жизненного цикла разработки программного обеспечения. Проекты CASE, подобно проектам CAD, могут быть очень большими, поэтому для их реализации применяется коллективная разработка.

Ø Офисные мультимедийные системы (OIS – Office Infor­mation System). Современные системы способны работать с текстами произвольных форматов, фотографиями, диаграммами, аудио- и видеокомпонентами. Кроме того, документы могут иметь особую структуру, особенно те, которые описываются с помощью языков разметки: HTML, XML. Пользователю может быть предоставлена возможность сформулировать запрос на поиск информации в базе данных по графическим признакам, характеризующим объект поиска.

Ø Геоинформационные системы (GIS – Geographic Information System). В базах данных ГИС хранятся пространственные и атрибутивные данные, часто полученные в результате фотосъемки со спутников и, соответственно, имеющие большой объем. Процедуры поиска информации заключаются в нахождении некоторых объектов или их признаков, например, по форме, цвету или текстуре, для чего необходимо использование сложных методов распознавания образов.

Ø Интерактивные и динамические Web-узлы. Рассмотрим Web -узел, на котором имеется оперативный каталог ведущихся на улично-дорожной сети ремонтных работ. Он позволяет посетителю выполнять следующие операции:

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

· выполнять поиск элементов (районов, улиц, дорожных знаков и т. п.), соответствующих критериям, указанным пользователем;

· определять срок проведения дорожно-аварийных работ;

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

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

2.3. Концепции распределенных СУБД

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

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

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

2.3.1. Трехслойная архитектура клиент-сервер

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

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

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

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

Ø контроль непротиворечивости и согласованности данных как в пределах одной и той же базы, так и между различными базами данных;

Ø единообразие преобразования и передачи информации снизу вверх, обусловленное правилами верхнего уровня, называемыми также централизованными правилами;

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

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

Трехслойная архитектура предлагает в качестве основы построения системы модель клиент–сервер.

Клиентская часть обеспечивает средства взаимодействия информационной системы и ее пользователей.

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

2.3.2. Взаимодействие компонентов

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

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

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

Взаимодействие компонентов клиентского и среднего слоя обеспечивается посредством COM+ (Distributed Component object model), т. е. распределенной модели компонентных объектов. COM является моделью программирования на основе объектов, упрощающей взаимодействие различных приложений, а COM + – это, своего рода, «клей», связывающий воедино разнообразные технологии, применяемые в распределенных приложениях. COM + дает возможность нескольким компонентам легко взаимодействовать друг с другом независимо от того, на каком языке программирования они написаны, а также где именно они находятся и под какой операционной системой работают.

Рис. 2.17. Схема взаимодействия компонентов

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

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

Развитие информационных технологий поддержки иерархических клиент-серверных систем позволило заменить использование платформы проектирования на основе COM -технологии технологией более высокого уровня -. Net, а вместо COM + -. Net Remoting и WebService.

2.4. Геоинформационные СУБД

Вследствие интенсивного развития геоинформационных систем и систем дистанционного зондирования Земли из космоса значительно увеличился объем доступных геопространственных данных, как векторных, так и растровых. Цифровая карта в терминах объектно-ориентированного подхода принимает особый вид, становясь более интеллектуальной, способной видоизменяться в зависимости от масштаба и назначения: топографическая, тематическая и др. Это позволяют эффективно использовать СУБД в ГИС-технологиях и в цифровой картографии [Михеева Т.И., Демьяненко Р.В., Чугунов И.А. Архитектура ГИС «Организация дорожного].

Автоматизированная информационная система, поддерживающая работу с геоинформационными технологиями, как правило, содержит следующие подсистемы и, соответственно, базы данных, обеспечивающие работу этих подсистем:

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

Ø Система автоматизированного картирования и распознавания объектов, предназначенная для обработки пространственной и графической информации, данных аэрофотоснимков, космического зондирования.

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

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

Рассмотрим методы и средства реализации распределенной ГИС на примере геоинформационной системы ARCView GIS.

Наборы данных в ГИС могут храниться как локально, так и удаленно, в частности, распределенными наборами данных. Методы доступа к локальным и распределенным данным существенно отличаются. ГИС ARCView GIS обеспечивает ряд интерфейсных механизмов, с помощью которых организуется доступ как к локальным, так и к удаленным источникам данных.

На рис. 2.18 схематически изображены имеющиеся в ARCView механизмы доступа к локально хранимым данным. В основе реализации интерфейса лежат классы объектов Vtab, FTheme, ITheme, DBTheme, GTheme. Vtab - «виртуальная таблица» - обеспечивает доступ к атрибутивной информации пространственных объектов. В качестве источника данных могут использоваться INFO -файлы, файлы DBF, текст с разделителями и другие табличные форматы. Объекты FTheme, ITheme, DBTheme, GTheme обеспечивают доступ к пространственной информации - слоям изображения. Источниками данных для этих классов служит пространственная информация во внутренних форматах ARCView, растровые изображения, информация, хранимая в базах данных, и грид-файлы, соответственно. ARCView поддерживает динамический обмен данными с локальными приложениями посредством механизма DDE.

Рис. 2.18. Средства доступа к локально хранимым данным

Для хранения локальных данных ГИС имеет встроенный интерфейс, обеспечивающий доступ к информации, хранимой в формате данной ГИС. Некоторые ГИС имеют интерфейсы доступа к данным, представленным в других, не «родных» форматах. Например, ARCView ГИС, кроме «собственных» данных, поддерживает такие типы данных, как растровые изображения, базы данных различных форматов и др. Эта возможность реализуется в ARCView посредством поддержки соответствующих классов объектов.

Доступ к распределенным данным представлен на рис. 2.19. В ARCView для этой технологии использованы два механизма.

Во-первых, входящий в комплект стандартной поставки данной ГИС, объектно-ориентированный язык программирования Avenue поддерживает обращения к базам данных SQL посредством объектного класса SQLCon и системного интерфейса ODBC. Это дает возможность обращаться через SQL -запросы к удаленным и распределенным базам данных, производить выборку и обработку хранящихся в них данных.

Во-вторых, технология SDE (Spatial Database Engine) предоставляет разнообразные возможности оперирования географическими данными, проведения их многостороннего пространственного анализа, рассылки данных и результатов анализа по сети, введения функций запроса и анализа в любые приложения. При этом SDE является объектно-ориентированной системой, работающей со многими коммерческими реляционными СУБД. Доступ к данным, управляемым SDE -сервером из ARCView GIS, осуществляется использованием объектного класса DBTheme, экземпляры которого отображаются на слои пространственных данных SDE (рис. 2.19).

Рис. 2.19. Средства доступа к распределенным данным

Рис. 2.20 иллюстрирует основные механизмы обработки данных, поддерживаемые ГИС ARCView. Основным средством обработки информации средствами ARCView являются приложения объектно-ориентиро­ванного языка Avenue. Кроме собственного программного кода приложения Avenue могут использовать для обработки данных дополнительные механизмы.

Ø При удаленном вызове процедур ARCView выступает в роли RPC -клиента, запрашивающего выполнение отдельных функций у RPC -серверов (например, на базе ARC / INFO), и в роли сервера, обслуживающего запросы клиентов на выполнение функций обработки данных.

Ø Функции обработки, реализованные во внешних динамически загружаемых библиотеках (DLL), используются языком Avenue.

Ø Через механизм DDE язык Avenue может использовать для обработки данные других локальных приложений.

Рис. 2.20. Средства распределенной обработки данных

2.5 Сетевые базы данных

2.5.1. СУБД в архитектуре «клиент-сервер»

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

Дата добавления: 2014-01-04