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

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

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

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

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

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

Файл "Город"

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

Рис. 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). Путем сложения соответствующих значений, находится искомый адрес в памяти, при этом СУБД вычислит адрес и разместит данные в соответствующей позиции, а при поиске данных вновь выполнит те же расчеты на хранящуюся информацию. Причем эти операции выполняются при минимальных затратах времени. Основным преимуществом этой организации данных является возможность быстрого прямого доступа к данным на основе значений кэшируемого поля.

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