Требования к модели данных

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

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

  • иерархическая модель данных
  • сетевая модель данных
  • реляционная модель данных
Логическая
(внутренняя)
Методы доступа к данным, логическая структура файлов.
ФизическаяПоддержка ОС и аппаратными средствами устройств хранения данных.

Рис.2.1. Процесс проектирования информационной модели

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

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

Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Здесь имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы.
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели.

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

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

    • Физическая модель , определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.
    • Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных.

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

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

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

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

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

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

      Выбор моделей данных

      Второй проблемой является выбор модели данных и СУБД. Действительно, можно взять лишь два критерия: быстродействие и удобство обновления. По первому критерию следует предпочесть иерархическую МД, тогда как по второму – реляционную.

      На самом деле критериев значительно больше: стоимость, производительность, неизбыточность и т. д.

      На выбор влияет и множество факторов: 1) типы элементов данных; 2) интерфейс пользователя; 3) структура и отношения данных; способы манипулирования данными; 4) целостность БД и защита данных; 5) поддержка программная и техническая; 6) коммерческая поддержка; 7) критерии качества (надежность, точность, соответствие промышленным стандартам); 8) возможности роста и развития.

      Сюда следует добавить, что не все требования могут быть сформулированы одинаково четко, а одним и тем же требованиям могут соответствовать разные МД.

      В силу сложности задачи выбора СУБД ее целесообразно решать в два этапа: выбор МД; выбор СУБД в рамках принятой МД.

      При решении первой задачи возникает проблема выбора по векторному критерию. Ее можно решать различными методами: методом анализа иерархий Саати Т., с помощью матриц (таблиц) принятия решений. Решение задачи последним способом приведено в работе [39]. Следует отметить, что этот вариант решения достаточно трудоемок. К тому же на результат решения сильно влияют неформальные факторы.

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

      Для баз данных, реализуемых на суперЭВМ, иногда называемых мейнфреймами, самым важным требованием, предъявляемым к БД, является быстродействие. В силу этого предпочтительным является использование иерархической модели данных или ее разновидности – многомерной модели данных. По тем же причинам для хранилищ данных предпочтительна многомерная модель.

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

      Объектно-ориентированные модели данных только начинают использовать в России. В настоящее время фактически единственной СУБД такого класса является CACHE.

      Объектно-реляционные СУБД используют преимущественно гибридную разновидность.

      В этих условиях задача выбора СУБД (для ПК) для построения операционных БД сводится практически к выбору среди реляционных СУБД. Этот выбор в итоге определяется требованиями, предъявляемыми к БД и формулируемыми в техническом задании на разработку базы данных.

      Сравнительные характеристики некоторых реляционных СУБД приведены в табл. 9.2.

      Сравнительная характеристика некоторых реляционных СУБД

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

      Понятия отношения и веерного отношения в иерархической модели данных не изменяются.

      Иерархической базой данных пазь івается множество отношений и веерных отношений, для которых соблюдаются два ограничения. 1.

      Существует единственное отношение, называемое корневым, которое не является зависимым ни в одном веерном отношении. 2.

      Все остальные отношения (за исключением корневого) являются зависимыми отношениями только в одном веерном отношении.

      Схема иерархической БД по составу компонентов идентична сетевой базе данных. Названные выше ограничения поддерживаются иерархическими СУБД.

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

      В графических иллюстрациях структуры приводятся ключи соответствующих отношений.

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

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

      На рис. 2.6 приводится связь значений отношений из иерархической базы данных, структура которой показана на рис. 2.5,а. Каждое значение представляется соответствующей величиной первичного ключа.

      Далее эта информация организуется в линейную последовательность значений, как это показано на рис. 2.6,6.

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

      Правила концевого прохождения 1.

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

      Перечисляются все значения в том веерном отношении, На котором остановился шаг 1. 3.

      Перечисляются значения всех вееров этого веерного отношения. Запись 1

      |фАК-0і|ГР=Юі|СТ—91001 |CT=910Q2[ . |СТ=9Ю21(ГР=102|СТ=91022| j . |ГР=50б[ . |СТ=8715б| КАФ=11 |ПР=1101 |ПР=1102[ . |ПР=1109[ |КАФ=12[ПР=12011 . І КАФ=17 | . |ПР=1711|

      |фАК=02|ГР=1іО|СТ°91188[ СТ=9Ю211 ГР-111 6

      Рис. 2.6. Линейное представление значений

      в иерархической базе данных: а — иерархическая взаимосвязь значений; б — линейное представление данных

      4. От достигнутого уровня происходит подъем иа предыдущий уровень, и если возможно применить шаг 1, то процесс повторяется.

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

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

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

      Рассмотрим алгоритм формирования иерархической БД на основе известного множества атрибутов и функциональных зависимостей. Исходное множество функциональных зависимостей и атрибуты первичного ключа получаются так же, как при формировании множества отношений в ЗНФ. Алгоритм иллюстрируется тем же примером, что и в п. 2.2.2.

      Требования к модели данных

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

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

      Методология — совокупность методов решения проблемы.

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

      К современным базам данных, а следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования.

      Высокое быстродействие (малое время отклика на запрос).

      Время отклика — промежуток времени от момента запроса к БД до фактического получения данных. Похожим является термин время доступа — промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их. Часто операции записи, удаления и модификации данных называют операцией обновления .

      Простота обновления данных.

      Совместное использование данных многими пользователями.

      Безопасность данных — защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

      Стандартизация построения и эксплуатации БД (фактически СУБД).

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

      Дружелюбный интерфейс пользователя.

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

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

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

      Безопасность данных включает их целостность и защиту.

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

      1) отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

      2) защиту от ошибок при обновлении БД;

      3) невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

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

      5) сохранность данных при сбоях техники (восстановление данных).

      Целостность обеспечивается триггерами целостности — специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

      1) введением системы паролей;

      2) получением разрешений от администратора базы данных (АБД);

      3) запретом от АБД на доступ к данным;

      4) формирование видов — таблиц, производных от исходных и предназначенных конкретным пользователям.

      Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language — SQL, часто называемого SQL2.

      Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

      Представляет интерес эволюция концепции баз данных .

      Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства — MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных (рис. 2.1, а) было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

      В 1963 году С. Бахманом была построена первая промышленная база данных />CODASYL для сетевой модели данных.

      Фактически начала использоваться (рис. 2.1, б) современная архитектура базы данных. Под архитектурой понимается разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Существенный скачок в развитии технологии баз данных дала предложенная М. Коддом в 1970 году парадигма реляционной модели данных. Под парадигмой понимается научная теория, воплощенная в систему понятий, отражающих существенные черты действительности. Теперь логические структуры могли быть получены из одних и тех же физических данных, т.е. доступ к одним и тем же физическим данным мог осуществляться различными приложениями по разным путям. Стало возможным обеспечение целостности и независимости данных.

      В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектно-ориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования и интеллектуализации БД.

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

      Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).

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

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

      Данные о поставках

      Код поставщика Имя поставщика Вид товара Кол-во товара Дата поставки

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

      Отчет о поставках за квартал

      Код поставщика Имя поставщика Вид товара Кол-во товара Цена единицы Стоимость товара

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

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

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

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

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

      В последующих разделах первоначально будет рассмотрен классический подход для централизованных БД, а затем — современный. Распределенным БД посвящена часть III настоящей работы.

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

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

      На рис. 2.5 показана совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа.

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

      Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя (рис. 2.4) при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.

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

      В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации (рис. 2.4). Цель нормализации — минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации. Заметим, что навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на запрос. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.

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

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

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

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

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

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

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

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

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

      Основными причинами низкой эффективности проектируемых БД могут быть:

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

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

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

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

      В БД имеется три уровня представления данных (рис. 2.4): концептуальная, логическая и физическая базы данных.

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

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

      В логическом представлении применяются следующие виды моделей данных: иерархические, сетевые, реляционные, объектно-ориентированные (объектно-реляционные).

      Иерархическая модель является разновидностью сетевой, являющейся совокупностью деревьев (лесом).

      Сетевая модель является моделью объектов-связей, допускающей только бинарные связи «многие к одному», и использует для описания модель ориентированных графов.

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

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

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

      В общем случае процесс запроса состоит из ряда этапов (И1 — И2 на рис. 2.4). Пользователь должен знать структуру БД или обратиться к АБД.

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

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

      При эксплуатации БД используют и две специфические операции: навигацию и спецификацию.

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

      Спецификация — операция, результатом которой является новая структура (таблица), построенная на основе структур таблиц базы данных. Эта таблица получила название «вид».

      Для работы с БД используется специальный обобщенный инструментарий в виде СУБД, предназначенный для управления БД и обеспечения интерфейса пользователя.

      Существует два основных направления реализации СУБД: программное и аппаратное.

      Программная реализация (в дальнейшем СУБД) представляет собой набор программных модулей, работает под управлением конкретной ОС и выполняет следующие функции: описание данных на концептуальном и логическом уровнях; загрузку данных; хранение данных; поиск и ответ на запрос ( транзакцию); внесение изменений; обеспечение безопасности и целостности; предоставление пользователю языковых средств: языка описания данных (ЯОД), языка манипулирования данными (ЯМД), языка запросов.

      Аппаратная реализация предусматривает использование и так называемых машин баз данных (МБД). Их появление вызвано возросшими объемами информации и требованиями к скорости доступа.

      Таким образом, в соответствии с рис. 2.4, 2.5 теоретические вопросы можно скомпоновать в две группы (рис. 2.6).

      Общая теория баз данных. Сюда относятся вопросы, не зависящие от моделей данных:

      а) математический аппарат баз данных (глава 3);

      б) описание структуры БД, в том числе различных МД с их сравнительными характеристиками, выбор МД, структурные преобразования БД.

      Теория реляционных БД (глава 4). Для них наиболее продвинута прикладная математическая теория БД. Она включает три фактически автономных раздела (рис. 2.6):

      а) организация структур таблиц БД (прежде всего нормирование), их заполнение и обеспечение составляющих целостности — при проектировании БД;

      б) обеспечение целостности данных и их восстановление за счет соответствующих характеристик СУБД — в процессе работы СУБД;

      в) организация запросов и обновления данных — при эксплуатации БД.

      В дальнейшем изложении материала будем руководствоваться рис. 2.6.

      © Центр дистанционного образования МГУП

      Проблема выбора модели данных для хранения сложных структур данных и классов Текст научной статьи по специальности « Общие и комплексные проблемы естественных и точных наук»

      Похожие темы научных работ по общим и комплексным проблемам естественных и точных наук , автор научной работы — Казакова Е.А., Шибанов С.В., Хмелевской Б.Г.,

      Текст научной работы на тему «Проблема выбора модели данных для хранения сложных структур данных и классов»

      ?Казакова. Е.А., Шибанов С.В. , Хмелевской Б.Г.

      ПРОБЛЕМА ВЫБОРА МОДЕЛИ ДАННЫХ ДЛЯ ХРАНЕНИЯ СЛОЖНЫХ СТРУКТУР ДАННЫХ И КЛАССОВ

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

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

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

      Для решения этой задачи существует несколько подходов:

      использование плоских файлов и ПО для управления ими;

      использование специализированных хранилищ, таких как Storage от Microsoft;

      использование систем управления базами данных (СУБД).

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

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

      своими достоинствами и недостатками. Иерархические и сетевые СУБД предназначены для обработки иерархий и сетей соответственно, но для работы с неиерархическими или несетевыми данными требуют разработки специализированных жестко определенных запросов. Иерархические и сетевые СУБД морально устарели, да и найти их реализацию под IBM PC совместимые компьютеры с операционными системами Windows от компании Microsoft проблематично, а именно на этой программно-технической платформе приходится работать многим разработчиками ПО. Объектно-ориентированные СУБД хорошо работают с объектами и коллекциями объектов, но не имеют универсальных и стандартизованных интерфейсов обработки данных. Реляционные СУБД (РСУБД) обладают неоспоримыми преимуществами по сравнению с другими: основаны на формальной математической модели, являются своего рода стандартом хранения данных, занимают львиную долю рынка СУБД. В то же время РСУБД, как и другие СУБД, непосредственно не поддерживает хранение и обработку сложных структур данных, таких как списки, массивы, деревья, графы, стеки и очереди.

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

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

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

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

      Технология объектной СУБД (ОСУБД) предполагает существенное интегрирование языковой среды, которая одновременно позволяет конструировать объектную базу данных, но и программный код.

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

      Кроме ООБД, можно рассматривать и вариант отображения схем баз данных в на схему языка программирования. Объектно-реляционное отображение (ORM — object relational mapper) — это библиотека языка программирования, выполняющая отображение объектов реляционной модели (отношения, строки и атрибуты) на объекты языка программирования (классы, экземпляры, методы, атрибуты). Отображение это обычно двунаправлено: манипуляции с атрибутами объекта приводят к чтению информации из (и записи в) соответствующие таблицы базы данных. Могут также поддерживаться искусственные атрибуты (транслирующие значения в колонках таблицы во что-то более содержательное для прикладной задачи). При использовании ORM- библиотек, программист манипулирует привычными элементами языка программирования — классами, объектами (экземплярами классов), атрибутами и методами и может получить автоматически сгенерированные SQL-запросов. Но реализации ORM бывают сильно негибки. Они могут требовать своей собственной схемы БД, и могут не быть применены к базам данных, созданным другими средствам.

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

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

      При построение логической модели данных можно выделить два подхода: предметно-ориентированный и

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

      ориентированной и универсальной модели данных.

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

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

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

      Представляется актуальной разработка система автоматизации процесса отображения структур данных и классов приложений, которая предоставляла возможность выбора вида логической модели данных (предметно-ориентированную, универсальную или смешанную). Результатами могут быть как реляционная модель данных, так и объектно-ориентированная модель данных или описание данных для ОЫМ-библиотек. Это позволит выполнить предварительный анализ полученных вариантов моделей данных для моделируемой предметной области по заданным характеристикам (например, объем базы данных, скорость выполнения запросов к базе данных, возможность реорганизации и т.д.).

      4 (55) | 2010 Модели данных в ГИС

      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 соединила лучшее из двух миров – геоинформатики и технологии баз данных.

      Смотрите так же:  13 гражданский кодекс рф

Оставьте комментарий