Data models in GIS
В презентациях, пресс-релизах, статьях и докладах сотрудников Esri и ДАТА+ очень часто упоминаются модели данных. На сайте Esri есть даже специальный раздел, который так и называется «Модели данных». Почему такое пристальное внимание к этой сущности?
В учебниках геоинформатики рассматривают лишь базовые (назовем их так) модели пространственных данных – растровая и векторная. Плюс некоторое расширение векторной модели топологией. Если же посмотреть на список моделей данных на сайте Esri, то нетрудно заметить, что: а) их там гораздо больше, б) они все основаны на базовой векторной модели данных, в) эти модели данных – специализированные, прикладные, в отличие от универсальных базовых. Зачем нужно городить весь этот огород?
Есть такое философское высказывание «мысли, которые мы можем мыслить, определяются языком, которым мы владеем». Применительно к геоинформатике это можно перевести так: «задачи, которые мы можем решать, определяются моделями данных, которыми мы владеем».
Поясню эту мысль примером из своего опыта. Когда-то я работал в вычислительном центре МПС. В наших информационных системах сеть железных дорог представлялась в виде множества станций, соединенных перегонами. Программное обеспечение было свое, но постепенно становилось ясно, что своих сил недостаточно. В то время ArcGIS еще не было, и наиболее близкой моделью данных из готовых программных продуктов было покрытие ARC/INFO, содержавшее линейно-узловую топологию. Однако при более близком рассмотрении оказывалось, что цели применения этой топологии в ARC/INFO не совсем совпадают с целями в наших прикладных задачах, и львиную долю функциональности всё равно пришлось бы реализовывать самим.
С появлением ArcGIS и технологии базы геоданных стали появляться и прикладные модели данных, смысл которых сильно отличается от смысла базовых моделей данных. Этот смысл пришел из технологии «обычных» реляционных баз данных и, в дальнейшем, из идеологии объектно-ориентированного проектирования информационных систем. В чем же состоит это столь значительное отличие?
Для начала рассмотрим базовые модели данных.
Растровая и векторная модели пространственных данных позволяют описать то, что находится на поверхности Земли двумя разыми способами. Растровая модель – самая простая, она позволяет указать только какие-то характеристики в отдельных точках пространства, распределенных регулярным образом по поверхности. Детальность такого представления определяется шагом сетки (или размером ячейки, если считать растр множеством смежных ячеек между линиями сетки, а не точками их пересечений). В ячейках могут записываться как качественные признаки (например, классы – водная поверхность, лес, пашня, город и т.д.), так и количественные (температура, влажность, оптическая яркость и т.д.). В первом случае получается так называемый тематический растр, во втором – полутоновой.
Векторная модель данных использует другой подход – выделение объектов на поверхности земли и самостоятельное описание каждого из них. Этот же подход используется в традиционной картографии, рассматривающий так называемые объекты картографирования и правила их отображения на картах. Векторная модель имеет расширения (т.е. надстройки над базовой моделью), такие как топология и триангуляционные сети. Топология далее делится на линейно-узловую (для представления сетей) и полигональную (для представления сплошных покрытий).
Растровая и векторная модели пространственных данных много лет совместно присутствовали на геоинформационном ландшафте, успешно дополняя друг друга. И хотя нередко возникали спекуляции на тему скорого объединения растровых и векторных систем, а также ГИС и систем обработки изображений, слияния этих двух технологий, равно как и этих двух моделей данных, не произошло. Вместо этого к концу ХХ века базовые модели данных «обросли» массой специфических для каждой из них «примочек». Для растров появились эффективные методы сжатия, благодаря которым объем данных растрового представления пространственной информации стал сравним с объемом векторного представления. Тайловые схемы хранения, пирамидные слои, кэширование, квадродерева и другие разработки сделали работу с растровыми данными такой же быстрой и эффективной, как и с векторными.
Векторная модель также не топталась на месте. Появлялись и в различных системах реализовывались идеи представления плавных кривых, третьей (z) координаты, межслойной топологии, множественной геометрии объектов, линейных мер и др.
Революция случилась незаметно, вернее, ее видели не там, где она была. Появление ArcInfo 8 после ARC/INFO 7 поначалу выглядело «всего лишь» продолжением жизни «старой-доброй» системы на новой программной основе (Объектно-компонентная модель, COM). Как Windows была когда-то оболочкой для DOS, так и ArcGIS была поначалу надстройкой над ARC/INFO. Новая подсистема ArcGIS имела чисто графический интерфейс и работала с новым хранилищем данных (база геоданных). Новый графический интерфейс и «потеря» командной строки беспокоили пользователей гораздо больше, чем появление нового хранилища, тем более что покрытия ARC/INFO и шейп-файлы поддерживались как и раньше. База геоданных рассматривалась не более чем перенос хранения данных из отдельных файлов в базу данных, что принципиально не влияло на функциональность приложений на основе новой системы.
Однако скоро роли поменялись, ArcGIS стало семейством продуктов, а ArcInfo – его частью. И вот тут начинается самое интересное. Помимо переноса функциональности из старой системы и развития графического интерфейса, Esri начинает активно развивать модель данных нового хранилища – базы геоданных. Поворотной точкой стал выход ArcGIS 9, когда стало ясно, что идеи, заложенные в ArcGIS 8.3, дают совершенно новое качество системы: возможности моделирования в базе геоданных стали самостоятельной ценностью – такой же, как и всевозможные функции анализа, которыми всегда славилось программное обеспечение Esri.
Таким образом произошла смена геоинформационной парадигмы: от моделирования карт мы перешли к моделированию реальности.
Карта – статичное изображение. Оно не кодирует в явном виде взаимоотношения объектов, об этих отношениях мы можем догадаться только по расположению объектов. Соответственно, в картографической модели данных этой информации нет, а та же топология нужна только для контроля корректности картографического изображения (смежные объекты соприкасаются без пустот и наложений, отрезки протяженных объектов соединяются в концевых точках и т.д.).
Модель реальности уже не обязана быть картой. В ней могут присутствовать не только пространственные объекты, но и непространственные. Например, в модели данных кадастра земельный участок – очевидно пространственный объект, а его владелец – непространственный. Поэтому в базе геоданных табличные (объектные) классы поддерживаются в такой же полной мере, как и классы пространственных объектов.
Разнообразие отношений объектов реальности диктует необходимость какого-то представления всех этих видов отношений и в базе геоданных. Например, земельный участок (ЗУ) может быть в долевой собственности, т.е. отношение ЗУ-владелец должно быть типа «один ко многим». В то же время, один субъект может владеть несколькими участками, и тогда отношение ЗУ-владелец должно быть уже типа «многие ко многим». База геоданных ArcGIS поддерживает и тот, и другой тип отношений, что позволяет выбрать тот тип, который наиболее полно соответствует решаемой задаче.
Идея явной фиксации отношений объектов, связей между ними – не открытие геоинформатики, она лишь применяет эту идею в пространственном контексте. Изначально эта идея принадлежит технологии реляционных баз данных. До появления базы геоданных, как общего универсального механизма моделирования, эти технологии долгое время сосуществовали параллельно, мало взаимодействуя. Например геореляционная модель данных, представленная покрытиями ARC/INFO, шейп-файлами и форматами конкурирующих систем, просуществовала без значительных изменений несколько десятков лет. Когда же стало ясно, что эта модель данных себя исчерпала и не дает нужных сегодня пользователям ГИС возможностей, пришел черед интегрированной модели базы геоданных.
Таким образом, развитие геоинформационных систем привело к их интеграции с технологией реляционных баз данных, результатом которой стало не только внедрение формальных методов моделирования данных, но также и клиент-серверной технологии с многопользовательским редактированием и поддержкой множественных версий данных.
Здесь следует сказать несколько слов о том, что же такое «моделирование данных». Само это словосочетание – не очень удачный перевод английского data modeling. Неудачен он потому, что в действительности моделируются не данные в виде чего-то другого, а реальность – в данных. Очевидно, например, что при моделировании автомобилей создаются модели, то есть, уменьшенные и/или недействующие копии реальных автомобилей. Тогда моделирование данных – создание сокращенных и/или не полнофункциональных копий данных? Абсурд получается. Так что правильнее сказать, что data modeling это моделирование посредством данных. А «модель данных» – это модель из данных, то есть, модель реальности, отраженная в структуре данных, образуемой взаимосвязями элементов данных.
При таком понимании становится ясна ценность прикладных моделей данных. Эти модели являются виртуальной имитацией объектов управления или изучения. В них мы можем воспроизводить свойства и отношения реальных объектов, их поведение. Пользуясь такими моделями, мы можем получать ответы на вопросы о моделируемых объектах, анализировать их взаимодействие, проигрывать различные сценарии. Такие возможности становятся насущной необходимостью, когда приходится оперировать тысячами и даже миллионами реальных объектов, ни список, ни все связи которых в голове удержать невозможно.
Разработка модели данных для небольшой самостоятельной задачи, решаемой одним пользователем – дело довольно простое. Однако для корпоративных, многопользовательских по определению, систем ситуация намного сложнее. Корпоративная информационная система (в том числе и корпоративная ГИС) отличается тем, что охватывает очень многие аспекты деятельности предприятия. В идеале – все. Соответственно, модель данных корпоративной ИС становится моделью самого предприятия. В ней должны присутствовать все сущности, необходимые для описания всех бизнес-процессов предприятия. Поскольку с корпоративной ИС взаимодействуют все (или большинство) отделов предприятия, и деятельность большого количества специалистов основана на работе с ней, становится понятно, насколько важно тщательное проектирование модели данных до запуска системы в эксплуатацию. Когда информационная система уже стала основным инструментом работы, внести какие-то изменения в ее модель данных становится очень сложно и дорого. Ведь придется приостанавливать работу с системой, перелопачивать огромный объем данных, тестировать… Если в системе используются множественные версии данных, то придется все их согласовывать с изменениями модели данных. При решении такой сложной задачи весьма вероятно возникновение ошибок, которые в дальнейшем могут создать затруднения или серьезные проблемы в работе. То есть, проектирование модели данных корпоративной системы – дело и сложное, и ответственное.
Решение сложной задачи становится более простым и контролируемым, если ее разбить на несколько этапов. Каждый этап сам по себе является задачей попроще, со своими исходными данными и результатами на выходе. Создание модели данных конкретной системы является частью более общего процесса создания этой системы. Опыт разработчиков позволил выделить несколько типовых этапов.
На первом этапе определяются круг пользователей системы, задачи, которые они с ее помощью должны решать, информационные продукты, которые система должна создавать, данные, которые для этого потребны. Таким образом формируются требования к информационной системе.
На втором этапе создается концептуальная модель данных, содержащая основные сущности и связи между ними. На этом этапе важно идентифицировать все объекты управления, работа с которыми должна автоматизироваться посредством информационной системы. При этом не требуется подразумевать, что каждой сущности должен соответствовать какой-то класс объектов в физической базе данных. Например, в адресном реестре адрес – вполне самостоятельный объект, существующий независимо от того, есть там здание или нет. А в каталоге объектов строительства адрес – уже атрибут таких объектов. На этом уровне абстрагирования атрибуты (характеристики) объектов не существенны, и в концептуальной модели данных они не отражаются, хотя некоторые сущности могут в дальнейшем оказаться атрибутами, как это было только что показано на примере адресов.
На третьем этапе создается логическая модель данных. Здесь уже показываются все атрибуты объектов, определяются типы их отношений. Логическая модель данных не конкретизирует механизмы реализации, которые будут использоваться в СУБД. Здесь нам не важно, поддерживает СУБД составные ключи или нет, есть в ней специальный тип данных даты-времени или нет. Если в требованиях к создаваемой информационной системе не указано, какую конкретную СУБД она должна использовать, то в результате логического проектирования можно сформулировать набор требований к СУБД, на основе которых можно уже выбирать конкретную систему.
На четвертом этапе создается физическая модель данных. В ней присутствуют все классы (таблицы), которые должны быть созданы в базе данных, указаны механизмы реализации отношений и элементы поведения объектов. Например, отношение между классами объектов может реализовываться как посредством внешнего ключа, т.е. хранения идентификатора-ссылки в отдельном поле таблицы одного из классов, так и посредством класса отношений – отдельной таблицы, содержащей идентификаторы связываемых объектов двух классов. После создания физической модели данных становится понятно, какую часть функциональности ИС берет на себя базовое программное обеспечение, а какую должны написать программисты проекта. Преимущества базы геоданных ArcGIS очень заметны именно на этом этапе: вместо написания собственного кода вы можете использовать готовые функции проверки и поддержки правил топологии, контроля ввода данных средствами атрибутивных доменов, широкий спектр расширений базовых моделей данных (сетевые, геодезические, схематические и т.д.), классы отношений, множественные картографические представления и многое другое.
На пятом этапе создается экземпляр базы данных и проводится его тестирование. Тестирование позволяет оценить правильность выбора того или иного решения в физической модели данных. Если выбранный вариант решения не дает должной производительности, физическая модель данных может быть скорректирована. Параллельно создается программный код, реализующий функции информационной системы и проводится его тестирование на пробном экземпляре базы данных.
На шестом этапе база данных заполняется актуальными данными, и система запускается в работу.
Хотя данная последовательность этапов выглядит как линейный однонаправленный процесс, на каждом из этапов могут обнаруживаться обстоятельства, требующие изменений отдельных решений, принятых на предыдущем этапе. Кроме того, сложные системы могут разбиваться на компоненты, для каждого из которых также может выполняться последовательность этих этапов. Поэтому тщательное проектирование обычно приводит к повторению этапов, а сам процесс становится итеративным.
Весьма эффективным средством повышения качества создаваемой ИС является пилотное проектирование. В пилотном проекте реализуется прототип конечной системы с упрощенным набором исходных требований и/или неполным набором данных. После прохождения всех этапов практически всегда уточняются исходные требования и становятся известны многие нюансы, как в используемых данных, так и в практике работы предприятия, которые могут оказать сильное (и часто пагубное) влияние на конечный результат. В некоторых случаях может даже оказаться, что полная версия системы нереализуема по финансовым или техническим причинам.
Пример фрагмента модели данных адресной системы, показывающий связи между адресами и адресуемыми объектами.
После осознания всей сложности задачи, можно впасть в уныние. Как справиться с множеством ее элементов? С чего начать? В помощь пользователям Esri предлагает книги, описывающие возможности базы геоданных и методы проектирования. Среди них – переведенная на русский «Моделирование нашего мира» Майкла Зейлера. Кроме того, на сайте ресурсов для пользователей Esri имеется большое количество примеров отраслевых и прикладных моделей данных. Примеры сопровождаются документацией (либо ссылками на нее), шаблонами для загрузки в среду проектирования, ссылками на форумы сообщества пользователей, постерами и т.д. Примеры моделей являются не догмой, а хорошей отправной точкой для ваших собственных разработок. Их преимущество в том, что многие из них основаны на отраслевых стандартах для пространственных данных и реальном опыте пользователей программных продуктов Esri.
В заключение хотелось бы еще раз сказать: «не так страшен черт, как его малюют». Моделирование данных, хотя и требует определенных усилий в освоении, открывает качественно новые горизонты развития геоинформационных систем. Благодаря ему ArcGIS соединила лучшее из двух миров – геоинформатики и технологии баз данных.
