Базы данных

1 1 1 1 1 1 1 1 1 1 Рейтинг 4.50 (2 Голоса)

Представление атрибутивной информации в ГИС

Для ввода, хранения, манипулирования и вывода атрибутивной (непространственной) информации в ГИС-технологии обычно используются стандартные коммерческие системы управления базами данных (СУБД) - комплексы программ и языковых средств, предназначенные для создания, ведения и использования баз данных. При этом в число атрибутов обычно не включаются геометрические свойства, описывающие топологические характеристики географических объектов. Последние упорядочиваются и организуются с использованием особых свойств ГИС. Необходимая связь между геометрическим описанием объектов и их содержательными атрибутами в таком случае устанавливается через идентификаторы - уникальные номера (коды) географических объектов. Атрибутивную базу данных пользователь может создавать автономно в любой доступной ему СУБД (например, в BASE или электронной таблице QuattroPro), а затем с помощью заполнения идентификационных полей атрибутивной таблицы кодами объектов и программных средств обмена данными связать ее с уже созданной географической базой данных. "Золотое правило" для разработчика здесь состоит в точном соблюдении соответствия (однозначности) номеров (кодов) объектов в географической и атрибутивной базах данных.

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

 Элементарные понятия технологии баз данных

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

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

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

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

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

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

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

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

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

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

·  удаление существующих документов (например, записей, содержащих устаревшие сведения о показателях движения населения);

·  изменение данных в отдельных записях в связи с изменением данных (например, изменился тип производственной специализации сельского хозяйства района и т. п.)

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

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

Способы представления атрибутивных данных в ЭВМ

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

В данном случае мы будем иметь единый файл "Предприятие" с регулярной организацией. Этот файл содержит расположенные последовательно друг за другом пять экземпляров хранимых записей (по одному экземпляру на каждое предприятие), и каждая запись включает все четыре поля: "№", "Предприятие", "Персонал", "Местонахождение". Такой способ хранения информации обладает двумя преимуществами - простотой реализации и способностью быстро давать ответы на вопросы пользователя типа 1: "Дать значения всех полей предприятия". Однако при внимательном рассмотрении можно заметить и ряд недостатков. Во-первых, такой способ слишком расточителен по отношению к ресурсам памяти, так как название местонахождения дублируется в каждой записи нужно дважды занести в память "Город - город 2" Действительно, в реальной ситуации можно иметь несколько тысяч предприятий, расположенных в десятках городов, и дублирование названий приведет не только к чрезвычайно экономному расходованию памяти, но и к физической нехватке реального ЭВМ для размещения такого файла. Поэтому целесообразно перенести из файла "Предприятие" поле "Местонахождение" в отдельный файл "Город", связав их между собой цепочкой указателей (индексов). Такая операция называется индексированием и ее результат в нашем случае представлен на Рис. 2.10.

При такой организации данных достигается значительная экономия памяти, хотя скорость получения ответа на запрос типа 1 уменьшается. Очевидно, что расход времени увеличивается за счет того, что теперь для всех характеристик данного предприятия потребуется не одна, Рис. 2.9, а две операции выборки из базы данных: первая - из файла "Предприятие", вторая - из файла "Город". Другой недостаток этого способа организации данных, как, впрочем, и предыдущего, состоит в том, что слишком много времени тратится для ответов на запросы, которые весьма распространены в географической среде, поскольку они связаны с региональным аспектом рассматриваемого явления. При этом необходимо иметь ввиду, что зачастую формы статистической ости построены по отраслевому принципу, и ни в одной из них не содержится, например, обобщенной информации о том, какие приведенные предприятия находятся в том или ином городе. Поэтому топомико-географам часто необходимо использовать такое обращение в базе данных: запрос типа 2 - "Дать все предприятия, имеющиеся Городе 1".

Файл "Предприятие"

Файл "Предприятие"

Файл "Город"

Файл "Город"

Рис. 2.10. Индексированные файлы (вариант 1)

База данных быстро выдаст ответы на запросы типа 2, если она будет организована следующим образом (см. Рис. 2.11).

Файл "Город"

Файл "Город"1

Файл "Предприятие"

Файл "Предприятие"1

Рис. 2.11. Индексированные файлы (вариант 2)

Здесь также имеются два хранимых файла, но в этом случае (в отличие от Рис. 2.10) указателями снабжается уже не файл "Предприятию" а файл "Город". В результате примерно при тех же требованием к объему памяти такая организация данных обеспечит быстрый ответ на запрос типа 2, хотя для поиска ответа на запрос типа 1 потребуется больше времени.

Указанный недостаток может быть устранен в результате объединения двух описанных представлений путем снабжения специальными указателями как файла "Город", так и файла "Предприятие". При этом расход памяти несколько возрастет, зато ответы на запросы типа 1 и 2 будут выдаваться очень быстро. Однако и у такой организации данных будут серьезные недостатки. Главный из них состоит в значительных неудобствах, возникающих при внесении каких-либо изменений. Такая ситуация, например, возникает при переносе промышленного предприятия из одного города в другой (запрос типа 3). Для отражения такого изменения придется исправлять указатели в обоих файлах.

Можно предложить следующую организацию данных, которая упростит эту задачу. Каждая запись в файле "Город" независимо от количества находящихся в нем пунктов имеет лишь один указатель, связывающий данный город с первым (по порядку) предприятием этого города в соответствующем файле; Здесь в свою очередь содержится указатель на второе предприятие города, от второго - на третье и так далее до последнего указателя, который возвращается на исходную позицию в файле "Город". Следовательно, для каждого города имеется цепочка записей всех его предприятий, и для внесения изменений согласно запросу типа 3 достаточно модифицировать всего лишь один указатель. В этом случае, однако, цепочка организует базу данных таким образом, что увеличивается продолжительность поиска ответа на запросы типа 1, если порядковый номер интересующего нас предприятия достаточно велик. Ведь единственный в этом случае способ доступа к этому предприятию заключается в перемещении по цепочке указателей от первого предприятия ко второму и так до П-1-то предприятия. В случае большой по размеру базы данных следование таким маршрутом может занять значительное время. Тем не менее такая организация данных, получившая название Многосписочной организации, Используется довольно часто. В нашем случае соединением указателей всех предприятий одного и того же города составляется для каждого из них список предприятий. Подобным образом можно организовать и другие списки, в соответствии с интересами пользователей. Например, весьма полезен может быть и запрос типа 4: "Дать все предприятия с численностью персонала свыше 2000 человек". В этом случае можно организовать списки предприятий по группам численности персонала. Теоретически многосписочная организация данных может содержать любое необходимое число списков. В нашем примере для быстрого ответа на запрос типа 4 необходимо образовать файл "Персонал" с соответствующими указателями на файл "Предприятие" аналогично тому, как это было сделано при организации файла "Город". При индексировании всех имеющихся полей получается так называемая инвертированная организация БД с вырожденным файлом "Предприятие", содержащим только их порядковые номера. Эта организация данных изображена на Рис. 2.12, где символ * имеет смысл "указывает на...".

Инвертированная организация данных

Инвертированная организация данных обеспечивает быстрые ответы на запросы о всех предприятиях типа 2-4. Но для ответа на запрос типа 1 потребуется более продолжительное время, так как необходимы обращения и выборка данных из четырех файлов. В этом смысле такая организация данных является антиподом регулярной организации, и в ситуациях, когда позволяют ресурсы компьютера, данные хранятся одновременно в двух этих структурах.

Следует упомянуть еще один вариант организации данных в БД - иерархический (см. Рис. 2.13). В этом случае организуется единствен-

Файл с иерархической организацией

Рис. 2.13. Файл с иерархической организацией

Файл, включающий три экземпляра записей (по одному на город). Экземпляр записи содержит список произвольной длины, включающей все поля данных о предприятиях. Сходство этого варианта с вариантом на Рис. 2.12 очевидно, поэтому сохраняются все его преимущества и недостатки.

Во включение рассмотрим полезный способ (вероятно и самый необычный) организации данных - упаковка информации с помощью так кэширования. Суть метода заключается в том, что со специальной кэш-функции определяется место в памяти ЭВМ, по которому будет храниться та или иная запись. Аргументом может быть значение какого-либо поля в этом экземпляре записи например, сумма порядковых номеров начальных пяти букв названия (при условии, что А=1, Б=2, В=3,..., Я=33). Путем сложения соответствующих значений, находится искомый адрес в памяти, при этом СУБД вычислит адрес и разместит данные в соответствующей позиции, а при поиске данных вновь выполнит те же расчеты на хранящуюся информацию. Причем эти операции выполняются при минимальных затратах времени. Основным преимуществом этой организации данных является возможность быстрого прямого доступа к данным на основе значений кэшируемого поля.

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

Базы данных - 4.5 out of 5 based on 2 votes