2. Гис приложения используемые для моделирования

2.1 Гис модели данных

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

Есть такое философское высказывание "мысли, которые мы можем мыслить, определяются языком, которым мы владеем". Применительно к геоинформатике это можно перевести так: "задачи, которые мы можем решать, определяются моделями данных, которыми мы владеем".

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

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

Растровая и векторная модели пространственных данных много лет совместно присутствовали на геоинформационном ландшафте, успешно дополняя друг друга. И хотя нередко возникали спекуляции на тему скорого объединения растровых и векторных систем, а также ГИС и систем обработки изображений, слияния этих двух технологий, равно как и этих двух моделей данных, не произошло. Вместо этого к концу ХХ века базовые модели данных "обросли" массой специфических для каждой из них "примочек". Для растров появились эффективные методы сжатия, благодаря которым объем данных растрового представления пространственной информации стал сравним с объемом векторного представления. Тайловые схемы хранения, пирамидные слои, кэширование, квадродерева и другие разработки сделали работу с растровыми данными такой же быстрой и эффективной, как и с векторными.

Векторная модель также не топталась на месте. Появлялись и в различных системах реализовывались идеи представления плавных кривых, третьей (z) координаты, межслойной топологии, множественной геометрии объектов, линейных мер и др.

Таким образом произошла смена геоинформационной парадигмы: от моделирования карт мы перешли к моделированию реальности.

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

Здесь следует сказать несколько слов о том, что же такое "моделирование данных". Само это словосочетание – не очень удачный перевод английского data modeling(Баранов Ю.Б. и др. Толковый словарь по геоинформатике/ – 1998.). Неудачен он потому, что в действительности моделируются не данные в виде чего-то другого, а реальность – в данных. Очевидно, например, что при моделировании автомобилей создаются модели, то есть, уменьшенные и/или недействующие копии реальных автомобилей. Тогда моделирование данных – создание сокращенных и/или не полнофункциональных копий данных. Так что правильнее сказать, что data modeling это моделирование посредством данных. А "модель данных" – это модель из данных, то есть, модель реальности, отраженная в структуре данных, образуемой взаимосвязями элементов данных.

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

Разработка модели данных для небольшой самостоятельной задачи, решаемой одним пользователем – дело довольно простое. Однако для корпоративных, многопользовательских по определению, систем ситуация намного сложнее. Корпоративная информационная система (в том числе и корпоративная ГИС) отличается тем, что охватывает очень многие аспекты деятельности предприятия. В идеале – все. Соответственно, модель данных корпоративной ИС становится моделью самого предприятия. В ней должны присутствовать все сущности, необходимые для описания всех бизнес-процессов предприятия. Поскольку с корпоративной ИС взаимодействуют все (или большинство) отделов предприятия, и деятельность большого количества специалистов основана на работе с ней, становится понятно, насколько важно тщательное проектирование модели данных до запуска системы в эксплуатацию. Когда информационная система уже стала основным инструментом работы, внести какие-то изменения в ее модель данных становится очень сложно и дорого. Ведь придется приостанавливать работу с системой, перелопачивать огромный объем данных, тестировать. Если в системе используются множественные версии данных, то придется все их согласовывать с изменениями модели данных. При решении такой сложной задачи весьма вероятно возникновение ошибок, которые в дальнейшем могут создать затруднения или серьезные проблемы в работе. То есть, проектирование модели данных корпоративной системы – дело и сложное, и ответственное.

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

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

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

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

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

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

На шестом этапе база данных заполняется актуальными данными, и система запускается в работу.

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

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