Выбор варианта лабораторной работы осуществляется по общим правилам с использованием следующей формулы:

V = (N × K) div 100,

где V – искомый номер варианта,

N – общее количество вариантов, div – целочисленное деление,

при V = 0 выбирается максимальный вариант,

K – код варианта.

Лабораторная работа № 1

«Разработка функциональной модели процесса создания хранилища данных»

Задание для выполнения лабораторной работы.

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

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

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

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

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

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

В первую очередь создайте диаграмму А0, затем, обобщив ее, создайте диаграмму А-0.

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

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

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

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

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

Модель может быть построена как с применением программ, автоматизирующих процесс построения моделей IDEF0 (Design/IDEF, BPWin, ERWin), так и просто любых программ, позволяющих нарисовать диаграммы по правилам IDEF0, например Microsoft Visio.

После изучения методического руководства рекомендуется ознакомиться со стандартами по семейству IDEF-технологий, найти их Вы сможете самостоятельно в сети Интернет. Особое внимание обратите на ресурсы, публикующие материалы Г. Верникова – создателя самого полного русскоязычного свода стандартов по семейству IDEF-технологий (например такие, как http://consulting.ru/econs_wsrc_989622737, http://www.cfin.ru/vernikov/idef/idef0.shtml и др.).

Указания к выполнению лабораторной работы

Рассмотрим типовую модель бизнес-процессов разработки ХД, которая может быть положена в основу реализации любого конкретного проекта. Эта модель содержит минимально достаточное число обязательных этапов для реализации небольшого или среднего по масштабу проекта.

Проект разработки ХД начинается после того, как выбраны инструменты разработки и сформирована команда проекта. В проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):

– формулирование требований;

– создание вычислительной среды;

– моделирование данных;

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

– проектирование аналитических отчетов;

– разработка приложений ХД;

– настройка производительности;

– проверка качества;

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

Каждый типовой этап разработки ХД будем описывать по следующей схеме:

· Описание задачи. Что обычно должно быть достигнуто в течение данного этапа разработки ХД.

· Временные требования. Приблизительная оценка количества времени для решения задачи данного этапа.

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

· Потенциальные опасности.

Теперь перейдем к рассмотрению отдельных компонентов представленной бизнес-модели.

Формулирование требований

Описание задачи. Главной задачей данного этапа является идентификация требований будущих пользователей ХД и оформление их в виде документа «Каталог требований». Обычно сбор требований осуществляется путем опроса групп потенциальных пользователей ХД на специальных совещаниях и переговорах. Конечные пользователи, как правило, не знакомы с концепцией ХД и процессом складирования данных. Поэтому для успешного решения этой задачи важна помощь лиц, принимающих решения (ЛПР), т. е. руководителей организации. На этом этапе определяются:

– масштаб проекта создания ХД (границы предметной области);

– перечень и содержание отчетов;

– требования по анализу данных (перечень задач анализа данных);

– требования к аппаратному обеспечению;

– требования к системному программному обеспечению;

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

– требования к квалификации персонала (программа обучения персонала);

– перечень источников данных;

– конкретизация плана реализации проекта разработки ХД (определяется дата завершения проекта).

В дополнение на основе собранной выше информации составляется план восстановления хранилища данных в случае аварийных сбоев. Разрабатывается стратегия архивирования и восстановления ХД.

Временные требования. Время выполнения этапа – от двух недель до двух месяцев.

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

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

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

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

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

Создание вычислительной среды для хранилища данных

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

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

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

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

Временные требования. Закупка и установка серверов – до двух недель.

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

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

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

В этом случае могут возникнуть конфликты между различными участниками проекта создания ХД и ИТ-службой организации в случае непредусмотренной остановки сервера БД.

Кроме того, в тестовой среде будет невозможно промоделировать ожидаемые показатели нагрузки на систему и оценить ее производительность.

Моделирование данных

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

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

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

Временные требования. Время выполнения этого этапа – от двух недель до двух месяцев.

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

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

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

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

Определение процедур извлечения, преобразования и загрузки данных

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

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

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

Временные требования. Время выполнения этапа – от одной недели до полутора месяцев.

Результатом выполнения этапа являются схема соответствия данных подающих систем и ХД, программы или ETL-инструменты.

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

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

Проектирование аналитических отчетов

Описание задачи. Главной задачей выполнения этого этапа является проектирование и разработка аналитических отчетов на спроектированной структуре данных. Это также специфичный этап для проекта ХД.

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

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

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

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

Хороший способ избежать такой опасности – тестирование разработанных отчетов с целью минимизации времени их получения.

Разработка приложений хранилища данных

Описание задачи. Главной задачей данного этапа является формирование программной среды, в которой пользователи будут извлекать данные из ХД и просматривать предопределенные отчеты.

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

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

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

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

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

Настройка производительности

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

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

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

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

Временные требования. Время выполнения этого этапа не должно превышать одной-двух недель.

Результатом выполнения этапа является перечень рекомендаций по настройке производительности.

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

Проверка качества

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

Временные требования. Срок выполнения этого этапа – от одной до четырех недель.

Результатом выполнения этапа являются план тестирования ХД и заключение о готовности ХД к эксплуатации.

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

Передача системы ведения хранилища данных в эксплуатацию

Задача этапа. Главная задача этапа – передача системы ведения хранилища данных заказчику и представление ее конечным пользователям.

Временные требования. Срок выполнения этого этапа – от одного дня до нескольких недель.

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

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

Сопровождение и модификация хранилища данных

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

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

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

Резюме

Процесс разработки ХД может быть представлен в виде модели бизнес-процессов. Бизнес-модель процесса разработки позволяет:

– отобразить субъективное мнение руководителя автоматизируемой организации и ключевых участников команды разработчиков на процесс проектирования конкретного ХД;

– учесть особенности ИТ-проекта, в рамках которого проектируется ХД;

– достаточно быстро составить план проектирования конкретного ХД;

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

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

Лабораторная работа № 2

«Разметка географической информации на языке KML»

Задание для выполнения лабораторной работы.

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

В ходе выполнения лабораторной работы Вы должны будете разметить один из вариантов маршрута. В маршруте должны быть представлены не менее 11 точек. Для каждой точки создайте метку с презентацией данного местоположения с использованием разметки на HTML. Метки соседних точек должны иметь разные стили. В начале, конце и по ходу маршрута на основе полигонов (многоугольники) покажите не менее 5 зданий, сооружений или участков территории с учетом их высоты. Учтите, что разные части здания могут иметь разную высоту. Для представления зданий используйте разные стили. Сам маршрут должен быть представлен линейным объектом и явно выделяться на фоне растровой подложки.

Полученный в результате kml-файл представить в качестве отчета.

Задачи, решаемые при выполнении лабораторной работы:

· получение навыков использования языков разметки;

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

· знакомство с географическими сервисами сети Интернет на примере Google Earth.

После знакомства с методическим руководством в обязательном порядке следует просмотреть ресурс https://developers.google.com/kml/?hl=ru, являющийся самым полным русскоязычным сводом стандартов и практических примеров разметки геопространственных объектов на языке KML.

Самый лучший способ изучить KML – экспериментировать с имеющимися файлами, меняя разные значения и наблюдая за результатами в геобраузере «Google Планета Земля» (Google Earth). Если браузер ничего не показывает, значит, Вы где-то допустили ошибку. В программе Google Earth есть механизм проверки ошибок, который, возможно, будет Вам полезен. (Выберите из меню пункт «Инструменты» => «Настройки» и на вкладке «Общие» в разделе «Обработка ошибок KML» отметьте переключатель «Показывать сообщения об ошибках».) Кроме того, для проверки своего KML-кода можете воспользоваться какой-нибудь специализированной программой. Одна такая программа, разработанная компанией Galdos Systems, имеется на сайте www.kmlvalidator.com.

Основные конструкции языка разметки KML приведены в прилагающемся к пособию файле KML Samples.kml.

Указания к выполнению лабораторной работы

Наверняка многие из Вас пользовались уникальной программой «Google Планета Земля» (Google Earth) (http://www.google.com/earth/index.html) или хотя бы слышали о ней. Эта программа позволяет на экране компьютера совершать виртуальные путешествия по всей нашей планете, просматривая спутниковые аэрои фотоснимки, рельефные карты, отдельные здания в 3D; знакомиться с интересными географическими материалами, а также добавлять собственные пометки с фотографиями и описаниями различных достопримечательностей и просматривать такие пометки, оставленные другими пользователями. Данная программа сегодня очень популярна, количество ее скачиваний, по заявлению компании Google, уже превысило сотни миллионов, и даже если в это число входят неоднократные скачивания разных версий программы одним и тем же пользователем, все равно нужно признать, что количество ее активных пользователей поистине колоссально.

Заметим, что проект «Google Планета Земля» – это далеко не единственный веб-ресурс, предоставляющий доступ к космическим фотоснимкам. Желающие, например, могут посмотреть их на сайте http://kosmosnimki.ru, причем по качеству отечественные спутниковые фотоснимки практически не уступают американским в сопоставимом разрешении. Но почему большинство пользователей, даже в России, все же предпочитает работать с продуктом компании Google?

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

Язык KML (аббревиатура от Keyhole Markup Language – язык разметки Keyhole) – это специализированный язык разметки, созданный на основе языка XML для представления трехмерных геопространственных данных и являющийся сегодня международным стандартом Open Geospatial Consortium. Этот язык был разработан компанией Keyhole Inc., которая была приобретена компанией Google в 2004 г. (Название Кеуhole – это дань уважения спутникам космической разведки серии KeyHole, обеспечивающим американцев фотоснимками начиная с 1976 г.) Программа «Google Планета Земля» стала первой программой, использующей этот язык, сейчас она уже не является единственной.

Как уже было сказано, язык KML создан на основе стандарта XML, а тот, в свою очередь, в качестве прототипа использовал языки SGML и HTML.

Однако в отличие от языка HTML в языке XML и всех других языках разметки, «произошедших» от XML, в записи тегов учитывается регистр, поэтому их необходимо вводить в точности так, как указано в справочном руководстве.

Создавать KML-файлы можно с помощью программы «Google Планета Земля», обладающей графическим интерфейсом специально для этой цели. А можно воспользоваться простым XML-редактором и вводить KML-код с нуля. Файлы с разметкой на языке KML (так же, как файл HTML) можно создать в любом текстовом редакторе (например, в стандартном приложении «Блокнот»). Если Вы будете создавать его самостоятельно, то не забудьте сохранить текст в кодировке UTF-8, иначе русские буквы в программе «Google Планета Земля» будут отображаться некорректно. Расширение имени файла, как нетрудно понять, должно быть kml.

KML-файлы модели и относящиеся к ним изображения можно упаковать в KMZ-архив, чтобы весь материал находился в одном контейнере. Если Вы хотите поделиться своими KML или KMZ-файлами, то можете присоединить их к электронному письму в виде вложения, поместить в общую папку в домашней или корпоративной сети или выложить на вебсервер. После того как Вы правильно сконфигурируете веб-сервер и опубликуете адрес своего KML-файла, любой человек, установивший Google Earth (или какое-нибудь совместимое приложение), сможет просмотреть созданный Вами файл.

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

Простые KML-документы. Самые простые KML-документы можно создавать прямо в интерфейсе «Google Планета Земля», для этого даже не потребуется текстовый редактор. Таким способом можно создавать и изменять метки, наложения на земную поверхность, пути и многоугольники.

Метки. Метка является одним из самых часто используемых компонентов в «Google Планета Земля». Она служит для указания положения на земной поверхности и представлена значком в виде булавки желтого цвета. В самом простом варианте метка содержит только элемент <Point>, который определяет ее положение. Вы также можете указать ее название и персонализированный значок или добавить другие элементы.

Откройте файл KML_Samples.kml в «Google Планета Земля» и перейдите в папку Placemarks. В ней представлены три типа меток: простая (simple placemarks), плавающая (floating placemark) и выдавленная (extruded placemark) (рис. 1.1).

Рис. 1.1 – Окно Google Earth после открытия файла KML_Samples.kml

Разметка простой метки на языке KML выглядит следующим образом:

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://www.opengis.net/kml/2.2">

<Placemark>

<name>Простая метка</name>

<description> Привязана к земной поверхности. Приспосабливается к рельефу местности.</description>

<Point>

<coordinates>-122.0822035425683,37.42228990140251,0</coordinates>

</Point>

</Placemark> </kml>

Рассмотрим структуру этого файла.

Заголовок XML: с него начинается каждый KML-файл. Перед заголовком не должно быть никаких символов или пробелов.

Декларация пространства имен KML: вторая строка каждого файла формата KML 2.2.

Объект Placemark, содержащий следующие элементы: Name – имя, которое используется в качестве ярлыка метки;

Description – описание, которое отображается во всплывающем окне, привязанном к метке;

Point – координаты, определяющие положение метки на земной поверхности (долгота и широта, иногда также высота).

Если Вы не можете найти эту метку на карте, подсказываем: она расположена прямо на 41-м корпусе Google – именно там разрабатывалась программа «Google Планета Земля».

То, что пользователи «Google Планета Земля» видят как метку, является элементом <Placemark> с дочерним элементом <Point> в формате KML. Это единственный способ отобразить метку с ярлыком в окне 3D-просмотра. По умолчанию метка имеет вид уже знакомой Вам желтой булавки. В KML-коде элемент <Placemark> может содержать один или несколько базовых векторных элементов, таких как ломаные линии (LineString), многоугольники (Polygon) или модели (Model), но только <Placemark> с дочерним элементом <Point> может отображаться как метка с ярлыком. Элемент <Point> служит для правильного размещения метки на карте, но сам не имеет графического представления.

Описательный HTML в метках. В файле KML_Samples.kml приведены исчерпывающие примеры форматирования текста метки, включая добавление ссылок, изменение размера и стиля шрифта, выравнивание и использование таблиц. Чтобы просмотреть полный список возможностей, скопируйте и вставьте в текстовый редактор пример Descriptive HTML (в папке Styles and Markup). Для выделения кликните правой кнопкой мыши на имени данной папки и выберите операцию копирования.

Этот файл (так же, как файл HTML) можно создать в любом текстовом редакторе (например, в стандартном приложении «Блокнот»). Если Вы будете создавать его самостоятельно, то не забудьте сохранить текст в формате Unicode, иначе русские буквы в программе «Google Планета Земля» будут отображаться некорректно. Расширение имени файла, как нетрудно понять, должно быть kml.

Авторазметка в «Google Планета Земля 4.0» и более поздних версиях. В «Google Планета Земля» предусмотрена функция авторазметки, которая преобразует текст наподобие www.google.com в активные гиперссылки. Текст, заключенный в теги <description> или <Snippet>, а также в элемент <text> внутри <BalloonStyle>, автоматически преобразуется в стандартные HTTP-ссылки. Добавлять теги <a href= ...> вручную не нужно.

Использование элемента CDATA. Чтобы добавить стандартный HTML-код в элемент <description>, его необходимо заключить в тег CDATA. Если этого не сделать, угловые скобки придется записывать в виде ссылок на объекты, иначе HTML-код будет неправильно анализироваться (например, символ >потребуется писать как >, а символ < – как <). Это особенность языка XML в целом, а не только в «Google Планета Земля».

Обратите внимание на HTML-разметку с тегами CDATA и без них.

ПРИЛОЖЕНИЕ А

Варианты заданий к лабораторной работе № 1

«Разработка функциональной модели процесса создания хранилища данных»

1. Управление недвижимым имуществом города.

2. Управление недвижимым имуществом региона.

3. Производство нефтехимической продукции.

4. Торговля автомобилями в регионе.

5. Фармацевтическое производство на уровне региона.

6. Ведение аптечной сети.

7. Ведение региональной сети общественного питания.

8. Книготорговля на уровне республики.

9. Ведение сети продовольственных магазинов.

10. Ведение сети косметических магазинов.

11. Система здравоохранения региона.

12. Система муниципального здравоохранения.

13. Система среднего образования города.

14. Система среднего образования региона.

15. Система управления средним и малым предпринимательством региона.

16. Система управлением средним и малым предпринимательством муниципального образования.

17. Управление общественным транспортом города.

18. Управление общественным транспортом региона.

19. Комитет по управлению памятниками культуры региона.

20. Муниципальная музейная сеть.

21. Региональная музейная сеть.

ПРИЛОЖЕНИЕ Б

Варианты заданий к лабораторной работе № 2

«Разметка географической информации на языке KML»

1. Маршрут от Вашего дома до корпуса ФЭТ ТУСУР. В случае иногороднего проживания точкам маршрута будут соответствовать населенные пункты, располагающиеся на маршруте. Для проживающих в Томске это будут точки на территории города.

2. Маршрут от главного корпуса ТУСУР до корпуса ФЭТ.

3. Маршрут Вашего летнего вояжа от дома до места отдыха.

4. Маршрут от Томска до Владивостока.

5. Маршрут от Вашего дома до места Вашего обычного места отдыха в выходные дни.

6. Маршрут для ознакомления потенциальных инвесторов с инвестиционно-привлекательными территориями Вашего города.

7. Маршрут от Вашего дома до места Вашей работы или обычного времяпровождения не в выходные дни (в случае надомной работы).

8. Маршрут от Вашего дома до места на Земном шаре, где Вы хотите побывать.

9. Маршрут от Вашего дома до места на Земном шаре, где Вы отдыхаете в зимнее время.

10. Маршрут от Вашего дома до места на Земном шаре, где Вы отдыхаете в летнее время.

11. Маршрут для ознакомления потенциальных инвесторов с инвестиционно-привлекательными туристическими территориями Вашего города.

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

13. Маршрут для ознакомления жителей старых районов с новыми достопримечательностями Вашего города.

14. Маршрут от Вашего дома до места на Земном шаре, где бы Вы хотели бы жить.

15. Маршрут от Вашего дома до места на Земном шаре, где бы Вы хотели бы отдыхать в летнее время.

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

17. Маршрут для ознакомления потенциальных инвесторов с инвестиционно-привлекательными территориями Вашего региона.

18. Маршрут по памятным местам Вашего региона.

19. Маршрут от Вашего дома до средней школы, которую Вы окончили.

20. Маршрут к ближайшему от места Вашего проживания учреждению здравоохранения.