Капралов Е.Г., Кошкарев А.В., Тикунов В.С. и др. Геоинформатика

Подождите немного. Документ загружается.

вие между типами данных SQL и типами данных Си: CHARACTER

соответствует строкам Си;

INTEGER

— long;,SMALLINT —

short;

REAL —

float;

DOUBLE

PRECISION

—

double

(именно такое со-

ответствие утверждено в стандарте

SQL/92).

Описанный набор операторов SQL предназначен для встраи-

вания в программу на обычном языке программирования. Поэтому

в этом наборе перемешаны операторы «истинного» реляционно-

го языка запросов и операторы работы с курсорами, позволяющи-

ми обеспечить построчный доступ к таблице — результату запроса.

В диалоговом режиме набор операторов SQL и их синтаксис не-

сколько другие, более сложные и динамичные. Примером может

служить реализация языка в СУБД

Oracle.

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

вер» обеспечивает простое и относительно дешевое решение про-

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

создавая некоторое подобие распределенных систем БД. Реальное

распространение архитектуры «клиент-сервер» стало возможным

благодаря развитию и широкому внедрению в практику концеп-

ции открытых систем. Основой этой концепции является упроще-

ние комплексирования вычислительных систем при международ-

ной и национальной стандартизации аппаратных и программных

интерфейсов. Стимулом для развития концепции явились, с одной

стороны, широкое внедрение локальных компьютерных сетей с

комплексированием аппаратно-программных средств, с другой —

бурное развитие технологий глобальных коммуникаций. Реальнос-

тью становятся и открытые ГИС-системы, несмотря на существу-

ющие проблемы в области стандартизации.

Ключевой позицией открытых систем, ориентированных на

пользователей, является независимость от конкретного разработ-

чика аппаратного и программного обеспечения. Приобретая лю-

бой продукт компании, придерживающейся стандартов открытых

систем, потребитель не становится полностью от нее зависимым.

Он может развивать свою систему, приобретая продукты любой

другой компании, соблюдающей стандарты. Причем это касается

как аппаратных, так и программных средств и не является необос-

нованной декларацией. Примерами всестороннего исследования и

реализации подходов к созданию открытых ГИС-систем являются

программные и технологические разработки крупнейших фирм-

конкурентов

ESRI

Intergraph

—

GEONET

GeoMedia

соответ-

ственно.

Основой системных и прикладных программных средств откры-

тых систем является стандартизованная операционная система. Тех-

нологии и стандарты открытых систем обеспечивают возможность

производства программных средств, обладающих свойствами мо-

бильности (portability) и интероперабельности

(interoperability).

Свойство мобильности означает сравнительную простоту перено-

са программной системы в различные аппаратно-программные

среды, соответствующие стандартам. Интероперабельность озна-

чает упрощение разработки новых программных систем на основе

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

фейсами.

Использование подхода открытых систем выгодно и произво-

дителям, и пользователям. Прежде всего открытые системы ре-

шают проблемы поколений и версий аппаратных и программных

средств. Все производители обязаны только обеспечивать некото-

рую стандартную среду. Преимуществом для пользователей явля-

ется то, что они могут постепенно заменять компоненты системы

более совершенными, не утрачивая работоспособности системы,

решать проблемы постепенного наращивания вычислительных,

информационных и других мощностей компьютерной системы.

В основе широкого распространения локальных сетей компью-

теров лежит известная идея разделения ресурсов. Высокая пропус-

кная способность локальных сетей обеспечивает эффективный до-

ступ из одного узла локальной сети к ресурсам, находящимся в

других узлах.

Развитие этой идеи приводит к функциональному выделению

компонентов сети: разумно иметь не только доступ к ресурсам уда-

ленного компьютера, но также получать от этого компьютера не-

который сервис, который специфичен для ресурсов данного рода

и программные средства для обеспечения которого нецелесооб-

разно дублировать в нескольких узлах.

Рабочая станция предназначена для непосредственной работы

пользователя или категории пользователей и обладает ресурсами,

соответствующими локальным потребностям данного пользовате-

ля.

Специфическими особенностями рабочей станции являются:

— объем оперативной памяти (далеко не все категории пользо-

вателей нуждаются в наличии большой оперативной памяти);

— наличие и объем дисковой памяти (достаточно популярны

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

дискового сервера);

— характеристики процессора и монитора (некоторым пользо-

вателям нужен мощный процессор, других в большей степени

интересует разрешающая способность монитора, для третьих обя-

зательно требуются средства ускорения графики и т.д.). При необ-

ходимости можно использовать ресурсы и/или услуги, предостав-

ляемые сервером.

Сервер локальной сети должен обладать ресурсами, соответ-

ствующими его функциональному назначению и потребностям сети.

Заметим, что в связи с ориентацией на открытые системы, пра-

вильнее говорить о логических серверах (имея в виду набор ресур-

сов и программных средств, обеспечивающих услуги над этими

ресурсами), которые располагаются не обязательно на разных ком-

пьютерах. Особенностью логического сервера в открытой системе

является то, что если по соображениям эффективности сервер

целесообразно переместить на отдельный компьютер, то это мож-

но проделать без реконструкции как его самого, так и использую-

щих его прикладных программ.

Примерами серверов могут служить:

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

данной локальной сети с внешним миром;

• вычислительный сервер, дающий возможность производить

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

• дисковый сервер, обладающий расширенными ресурсами

внешней памяти и предоставляющий их в использование рабочим

станциям и, возможно, другим серверам;

• файловый сервер, поддерживающий общее хранилище фай-

лов для всех рабочих станций;

• сервер баз данных — фактически обычная СУБД, принимаю-

щая запросы по локальной сети и возвращающая результаты.

Сервер локальной сети предоставляет ресурсы рабочим станци-

ям и другим серверам.

Принято называть клиентом локальной сети запрашивающего

услуги у некоторого сервера и сервером — компонент локальной

сети, оказывающий услуги некоторым клиентам.

Хотя обычно одна база данных целиком хранится в одном узле

сети и поддерживается одним сервером, серверы баз данных пред-

ставляют собой простое и дешевое приближение к распределен-

ным базам данных, поскольку общая база данных доступна для

всех пользователей локальной сети.

Доступ к базе данных от прикладной программы или пользова-

теля производится путем обращения к клиентской части системы.

В качестве основного интерфейса между клиентской и серверной

частями выступает язык баз данных SQL. Собирательное название

SQL-сервер относится ко всем серверам баз данных, основанных

на SQL. Соблюдая предосторожности при программировании, мож-

но создавать прикладные информационные системы, мобильные

в классе SQL-серверов.

Одним из перспективных направлений СУБД является гибкое

конфигурирование системы, при котором распределение функ-

ций между клиентской и пользовательской частями СУБД опреде-

ляется при установке системы.

Особенно важны в системах управления базами данных, осно-

ванных на архитектуре «клиент-сервер», протоколы удаленного

вызова процедур. Использование механизма удаленных процедур

позволяет перераспределять функции между клиентской и сервер-

ной частями системы, а также скрывать различия между взаимо-

действующими компьютерами. Физически неоднородная локаль-

ная сеть компьютеров приводится к логически однородной сети

взаимодействующих программных компонентов. В результате пользо-

ватели не обязаны заботиться о разовой закупке совместимых сер-

веров и рабочих станций.

Обычно на стороне клиента СУБД работает только такое про-

граммное обеспечение, которое не имеет непосредственного дос-

тупа к базам данных, а обращается для этого к серверу с исполь-

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

нести большую часть прикладной системы на сторону сервера.

Очевидно, что требования к аппаратуре и программному обес-

печению клиентских и серверных компьютеров различаются в за-

висимости от вида системы.

Распределенные БД. Основная задача систем управления распре-

деленными базами данных состоит в обеспечении средствами ин-

теграции локальных баз данных, располагающихся в некоторых

узлах вычислительной сети, с тем, чтобы пользователь, работаю-

щий в любом узле сети, имел доступ ко всем этим базам данных

как к единой базе данных.

Возможны однородные и неоднородные распределенные базы

данных. В случае однородных БД каждая локальная база данных

управляется одной и той же СУБД. В неоднородной системе локаль-

ные базы данных могут относиться даже к разным моделям данных.

Сетевая интеграция неоднородных баз данных — очень сложная

проблема. Более успешно практически решается промежуточная

задача — интеграция неоднородных SQL-ориентированных систем.

Интегрированные и мультибазы данных. Проблема интегриро-

ванных (федеративных) неоднородных БД и мульти-БД возникла

в связи с необходимостью комплексирования систем БД, осно-

ванных на разных моделях данных и управляемых разными СУБД.

Основной задачей интеграции неоднородных БД является пре-

доставление возможности автоматического преобразования опе-

раторов манипулирования БД глобального уровня в операторы,

понятные соответствующим локальным СУБД.

При строгой интеграции неоднородных БД локальные системы

БД утрачивают свою автономность. После включения локальной

БД в федеративную систему все дальнейшие действия с ней, вклю-

чая администрирование, должны вестись на глобальном уровне.

Поскольку пользователи часто не соглашаются утрачивать локаль-

ную автономность, желая, тем не менее, иметь возможность рабо-

тать со всеми локальными СУБД на одном языке и формулировать

запросы с одновременным указанием разных локальных БД, раз-

вивается направление мульти-БД.

В системах мульти-БД не создается глобальная схема интегри-

рования, а применяются специальные способы наименования для

доступа к объектам локальных БД. В таких системах на глобальном

уровне допускается только выборка данных. Это позволяет сохра-

нить автономность локальных БД.

Как правило, интегрировать приходится неоднородные БД,

распределенные в вычислительной сети, а это в свою очередь при-

водит к дополнительным проблемам интеграции: управление гло-

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

Для внешнего представления интегрированных и мульти-БД

обычно используется реляционная модель данных, но в настоя-

щее время все чаще предлагаются объектно-ориентированные мо-

дели.

Объектно-ориентированные структуры БД. В последнее время,

особенно в разработках фирмы

ESRI,

большое внимание стало

уделяться четвертому типу СУБД — объектно-ориентированному

(здесь этот термин имеет отношение только к структуре БД и язы-

ку программирования, а не к объекту как реальности). Примене-

ние таких СУБД направлено на снижение объемов хранимой ин-

формации и времени последовательного поиска в БД. В ГИС такие

структуры применяются, когда появляется необходимость управ-

ления сложными реальными объектами более разумным спосо-

бом, чем простыми точками, линиями и полигонами, а также

модификация БД при оверлее полигонов.

В объектно-ориентированных БД требуется, чтобы географиче-

ские данные представляли собой совокупность элементов. При этом

они характеризуются серией атрибутов и параметров поведения,

которые определяют их пространственные, графические, времен-

ные,

текстовые/численные размерности. Примерами таких элемен-

тов могут служить: участок железной дороги и связанное с ним

здание вокзала; узел трубопровода с ответвлениями из труб разно-

го диаметра и т.п. Такая структура позволяет унифицировать хра-

нение геометрии и атрибутов при отображении взаимосвязанных

объектов.

Направление объектно-ориентированных баз данных (ООБД)

возникло сравнительно давно. Первые публикации появлялись уже

в середине 80-х годов XX в., однако наиболее активно это направ-

ление развивается в последние годы. Возникновение направления

ООБД определяется прежде всего потребностями практики: необ-

ходимостью разработки сложных информационных прикладных

систем, для которых технология предшествующих систем БД не

была вполне удовлетворительной.

Основу развития ООБД обеспечивают как предыдущие работы

в области БД, так и давно развивающиеся направления языков

программирования с абстрактными типами данных и объектно-

ориентированных языков программирования. Исключительное вли-

яние на концепции ООБД и всего объектно-ориентированного

подхода оказал переход к семантическому моделированию данных.

При наличии большого количества функционирующих проек-

тов и коммерческих систем (пример — разработки

ESRI)

отсут-

ствует общепринятая объектно-ориентированная модель данных по

причине отсутствия общего согласия о принятии какой-либо мо-

дели. Имеются и более конкретные проблемы, связанные с разра-

боткой декларативных языков запросов, выполнением и оптими-

зацией запросов, формулированием и поддержанием ограничений

целостности, синхронизацией доступа и управлением транзакци-

ями и т.д.

В наиболее общей и классической постановке объектно-ориен-

тированный подход базируется на следующих концепциях:

• объекта и идентификатора объекта;

• атрибутов и методов;

• классов;

• иерархии и наследования классов.

Любая сущность реального мира в объектно-ориентированных

языках и системах моделируется в виде объекта. Любой объект при

своем создании получает генерируемый системой уникальный иден-

тификатор, который связан с объектом все время его существова-

ния и не меняется при изменении состояния объекта.

Каждый объект характеризуется состоянием и поведением. Со-

стояние объекта — набор значений его атрибутов. Поведение объек-

та — набор методов (программный код), оперирующих над состо-

янием объекта. Значение атрибута объекта — это тоже некоторый

объект или множество объектов. Состояние и поведение объекта

инкапсулированы в объекте; взаимодействие объектов производится

на основе передачи сообщений и выполнении соответствующих

методов.

Множество объектов с одним и тем же набором атрибутов и

методов образует класс объектов. Объект должен принадлежать толь-

ко одному классу (если не учитывать возможности наследования).

Допускается наличие примитивных предопределенных классов,

объекты-экземпляры которых не имеют атрибутов: целые, строки

и т.д. Класс, объекты которого могут служить значениями атрибу-

та объектов другого класса, называется доменом этого атрибута.

Допускается порождение нового класса на основе уже суще-

ствующего класса — наследование. В этом случае новый класс, на-

зываемый подклассом существующего класса, наследует все его

атрибуты и методы. Различаются случаи простого и множествен-

ного наследования. В первом случае подкласс может определяться

только на основе одного класса, во втором случае классов может

быть несколько.

При таком наборе базовых понятий (кроме наследования) объек-

тно-ориентированный подход очень близок к подходу языков про-

граммирования с абстрактными (или произвольными) типами

данных.

С другой стороны, если абстрагироваться от поведенческого

аспекта объектов, объектно-ориентированный подход весьма бли-

зок к подходу семантического моделирования данных. Фундамен-

тальные абстракции, лежащие в основе семантических моделей,

неявно используются и в объектно-ориентиробанном подходе. На

абстракции агрегации основывается построение сложных объек-

тов,

значениями атрибутов которых могут быть другие объекты.

Абстракция группирования — основа формирования классов объек-

тов.

Наиболее важным качеством ООБД является поведенческий

аспект объектов. В прикладных системах с традиционной организа-

цией БД существовал принципиальный разрыв между структур-

ной и поведенческой частями. Структурная часть системы поддер-

живалась всем аппаратом БД, ее можно было моделировать, вери-

фицировать и

т.

д., а поведенческая часть создавалась изолирован-

но.

В среде ООБД проектирование, разработка и сопровождение

прикладной системы становятся процессом, в котором интегри-

руются структурный и поведенческий аспекты. Конечно, для этого

нужны специальные языки, позволяющие определять объекты и

создавать на их основе прикладную систему.

Специфика применения объектно-ориентированного подхода

для организации и управления БД потребовала уточненного тол-

кования классических концепций и некоторого их расширения. Эти

потребности касаются спецификации знаний при определении

класса (ограничений целостности, правил дедукции и т.п.), опре-

делении разного рода семантических связей между объектами, во-

обще говоря, разных классов и пересмотра понятия класса. В кон-

тексте ООБД оказывается более удобным рассматривать класс как

множество объектов данного типа, т.е. одновременно поддержи-

вать понятия типа и класса объектов.

Основные трудности объектно-ориентированного моделирова-

ния данных проистекают из того, что такого развитого математи-

ческого аппарата, на который могла бы опираться общая объект-

но-ориентированная модель данных, не существует.

Принято выделять два уровня моделирования объектов: ниж-

ний (структурный) и верхний (поведенческий). На структурном

уровне поддерживаются сложные объекты, их идентификация и

разновидности связей. База данных — это набор элементов дан-

ных, связанных отношениями «входит в класс» или «является ат-

рибутом». Важными моментами являются поддержание наряду с

понятием «объект» понятия «значения», а также, четкое разделе-

ние схемы БД и самой БД.

Качество данных и контроль ошибок. Представления о качестве

данных, их точности и оценке погрешности становятся чрезвы-

чайно важными при создании баз и банков данных ГИС. Суще-

ствует практически всеобщая тенденция забывать об ошибках в

данных, если последние представлены в цифровой форме. Все про-

странственные данные до некоторой степени неточны, но в циф-

ровой форме они обычно представляются с высокой точностью,

определяемой параметрами памяти компьютера. Необходимо каж-

дый раз рассматривать два вопроса:

— насколько правильно представляемые в БД цифровые струк-

туры отражают реальный мир;

— насколько точно алгоритмы позволяют рассчитать истинное

значение результата.

Методы расчета точности определений по картам рассматрива-

ются в курсе картографии, с понятиями надежности и качества

географических данных можно ознакомиться в работе [Б. Б. Сера-

пинас,

1983].

Показатели качества данных определяются стандар-

тами [И. К. Лурье,

2002].

Основные из них: позиционная точность

и точность атрибутов объектов, а также логическая непротиворе-

чивость, полнота, происхождение, относящиеся к базе данных в

целом.

Позиционная точность данных и типы ошибок. Позиционная

точность определяется как величина отклонения измерения дан-

ных о местоположении (обычно координат) от истинного значе-

ния. При ее определении, как правило, исходят из масштаба ис-

следования или первичного материала, например в данных о при-

родных ресурсах стремятся достичь точности карты заданного мас-

штаба. Обеспечение большей точности требует более качественных

исходных материалов, но всегда следует задаться вопросом, оп-

равданны ли дополнительные затраты задачами исследования.

Точность координат определяется по-разному в растровом и

векторном представлении.

Точность растра зависит от размера ячеек сетки. Для избежания

потери информации можно использовать ячейки меньшего разме-

ра с тем, например, чтобы показать искусственные объекты, но

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

в заданном масштабе. В большинстве случаев неясно, относятся ли

координаты, представленные в растровом формате, к централь-

ной точке ячейки или к одному из ее углов; точность привязки,

таким образом, составляет 1/2 ширины и высоты ячейки.

Координаты в векторном формате могут кодироваться с любой

мыслимой степенью точности; она ограничивается возможностя-

ми внутреннего представления координат в памяти компьютера.

Обычно для представления используется 8 или 16 десятичных зна-

ков (одинарная или двойная точность), что соответствует ограни-

чению по точности соответственно до 1/10

1/10

измерения на

местности. Для получения такой же точности растра необходимо,

соответственно, 10

х 10

или 10

х 10

ячеек, что невозможно даже

При специальном сжатии данных. Но лишь некоторые классы дан-

ных соответствуют такой точности векторного представления: дан-

ные,

полученные точной съемкой, карты небольших участков,

составленные на основе крупномасштабных топографических карт;

лишь для немногих природных явлений характерны четкие грани-

цы,

которые можно представить в виде математически определен-

ных линий. Поэтому можно утверждать, что тонкие линии в век-

торном формате дают ложное ощущение точности. Обычно на кар-

те толщина линии отражает неопределенность положения объекта.

Поэтому в векторной системе фиксируется неопределенность по-

ложения векторного объекта, а не точность координат. В растровой

системе эта неопределенность автоматически выражается размером

ячейки, который и дает действительное представление о точности.

Точность базы данных. Практически на каждом этапе создания

БД возможно внесение ошибок.

Карты имеют погрешности, которые при цифровании автома-

тически переносятся в базу данных; из-за генерализации они не

всегда точно фиксируют информацию о местоположении объекта;

несоответствия на границах листов могут обусловить несоответ-

ствия в базе данных.

Ошибки характерны для данных, взятых из некартографиче-

ских источников. Они могут появиться и при проведении инвента-

ризации по аэрофотоснимкам, если изображения дешифрирова-

ны неверно, часто возникают потому, что слишком велико дове-

рие к базовым картам. Другие ошибки связаны с проблемой гра-

ниц и погрешностями классификации. Многие ошибки обусловле-

ны особенностями сбора данных. Ручной ввод цифровых данных

весьма утомителен, и трудно сохранять необходимое качество ра-

боты на протяжении долгого времени.

Для снижения ошибок в измерении местоположения использу-

ют геодезический контроль и системы спутникового позициони-

рования, а также создание массивов данных географической привяз-

ки.

К последним предъявляют особенно высокие требования по

точности и достоверности еще на этапе сбора исходной информа-

ции. Их применение в качестве основы для интеграции данных в

известных оригинальных масштабах и проекциях не вызывает за-

труднений. Во всех других случаях требуется преобразование ин-

формации, которое должно выполняться по правилам картогра-

фической генерализации и согласования.

Большая часть данных о местоположении объектов берется с

аэроснимков, при этом точность зависит от правильного разме-

щения контрольных точек. Данные космической съемки труднее

расположить с большой точностью — не позволяет разрешение

снимка.

На весь набор данных влияют: ошибки регистрации и опреде-

ления контрольных точек, преобразования координат, особенно

когда неизвестна проекция исходного документа; ошибки обра-

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

и проблемы интерпретации; математические ошибки; потеря точ-

ности представления из-за невысокой точности вычислений; пе-

ревод векторных данных в растровый формат.

В БД обычно используются данные из разных источников с

разной степенью точности. При наложении множества карт точ-

ность результирующего материала может оказаться очень низкой.

Однако больший интерес представляет показатель пригодности

полученной карты. Для некоторых типов операций степень при-

годности карт определяется точностью наименее точного слоя

БД. Показатель пригодности можно оценить также по его устой-

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

атрибута.

Часто возникают искусственные признаки ошибок (артефак-

ты) — нежелательные последствия применения высокоточных

процедур для обработки пространственных данных, имеющих не-

большую точность. Использование растровых данных позволяет

застраховаться от артефактов до тех пор, пока размер элемента

растра больше или равен позиционной точности данных. При ра-

боте с векторными данными артефакты возникают при кодирова-

нии (цифровании) и наложении полигонов.

Чтобы проверить позиционную точность, нужно использовать

независимый, более точный источник, например, карту более

крупного масштаба, данные спутникового позиционирования,

первичные («сырые») данные съемки. Для контроля можно ис-

пользовать и внутренние признаки: незамкнутые полигоны, ли-

нии, проходящие выше или ниже узловых точек, и т. п. Величина

этих погрешностей может служить мерой позиционной точности.

Наиболее надежным путем создания качественных БД, особен-

но для ее многократного и многопользовательского применения,

является хранение информации о точности в самой БД в виде ат-

рибутов или метаданных.

Точность атрибутивных данных. Точность атрибутов определя-

ется как близость их к истинным показателям (на данный момент

времени). В зависимости от природы данных точность атрибутов

может быть проанализирована разными способами.

Для непрерывных атрибутов, представляющих модель поверх-

ности, например ЦМР, точность определяется как погрешность

измерений по этой модели.

Для атрибутов объектов, выделяемых в результате классифика-

ции, точность выражается в оценках соответствия, определеннос-

ти или правдоподобия. В случае двух объектов ситуация, в которой

они представлены сочетанием 70 % атрибута объекта А и 30 % ат-

рибута В, выгоднее, чем когда объекты А и В недостаточно опре-

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

для оценки точности атрибутов полезно составить матрицу оши-

бок классификации. Для этого нужно взять несколько случайных

точек, определить их категорию по базе данных, затем на местно-

сти определить истинный класс и заполнить матрицу классифика-

ции (соответствия). Если, например, число классов 4, а число об-