ГИТ лекционный курс / Тема 6 текст
.pdfТЕМА № 6. Базы данных и управление ими.
Слайд 2 . Основные структуры компьютерных файлов.
Файлы - всего лишь простая система учета, позволяющая компьютеру отслеживать записи данных, которые вы в него вводите, и получать эти записи в любом угодном вам порядке.
Неупорядоченные файлы. Простейшей структурой файла является неупорядоченный массив записей. Вы помещаете записи в файл в последовательности их появления.
Единственным преимуществом такой структуры файла является то, что для добавления новой записи нужно просто поместить ее в конец файла, позади всех других записей.
Допустим, ваша база данных содержит 200'000 записей. Если файл неупорядочен, то вам, возможно, потребуется просмотреть все 200'000 записей, чтобы найти нужную.
Если, например, для выборки одной карточки требуется одна секунда, то просмотр всей картотеки займет 55 часов.
Последовательно упорядоченные файлы. Как вы знаете, большинство картотек,
как, например, телефонные справочники, упорядочены по алфавиту. Этот метод использует сравнение каждой новой записи с имеющимися для определения того, где ее место. Такие последовательно упорядоченные файлы могут использовать буквы алфавита или числа, которые тоже имеют определенную последовательность. Обычной стратегией поиска здесь является так называемый поиск делением пополам (или дихотомия). Поиск начинается разделением всего массива записей на две половины и выборкой записи в середине. Если она оказывается той, что нужна, то процедура поиска закончена. Если искомая запись находится прежде выбранной, то мы выполняемтужеоперациюспервойполовиной, еслипосле— совторойит.д.
Таким образом, программе не требуется просматривать большую часть файла. Среднее количество операций в этой стратегии определяется как log 2 (n + 1). В нашем прежнем примере времяпоискасокращается донемногим болеедвухчасов вместопрежних 55-и.
Однако скорость поиска не достается бесплатно, поскольку теперь каждая новая запись должна вставляться в соответствующее место последовательности, иначе ваш файл быстро превратится в неупорядоченный.
Слайд 3. Внешний индекс.
Каждому объекту может быть приписано большое количество атрибутов, но мы физически не можем отсортировать записи в файле одновременно более чем одним способом. И если для того атрибута, по которому мы отсортировали массив записей, мы можем применить быстрый поиск делением пополам, то для всех других атрибутов нам придется выполнять утомительный последовательный поиск. Решение этой проблемы- внешний индекс. Строится он так: из исходного файла в новый файл копируются значения одного атрибута для всех записей вместе с положениями этих записей. То есть каждая запись в новом файле состоит из значения атрибута и адреса записи в исходном файле, из которой это значение было взято. Затем нужно упорядочить записи нового файла в соответствии со значениями атрибута. Теперь, чтобы найти запись с заданным значением атрибута, мы можем в новом файле использовать поиск делением пополам. Найдя нужные записи в индексном файле, мы получим адреса записей исходного файла, по которым можем получить все атрибуты объектов. Таким образом, для поиска в основном файле используется дополнительный индексный файл, который называется внешним индексом, а сам исходный файл, таким образом, становиться индексированным.
Очевидно, что мы можем выносить в индексный файл несколько атрибутов, чтобы организовывать поиск сразу по значениям этих нескольких атрибутов. В этом случае используется составной индекс.
Индексные файлы используются всеми видами баз данных, т.к. существенно ускоряют поиск нужной информации. Пользователь сам может создавать индексные файлы с простыми или составными индексами, ускоряя тем самым свою текущую работу. Однако следует помнить, что индексный файл – это физический файл, занимающий место на диске, и его объем может быть большим.
Слайд 4 . Индексированная структура данных.
Этот слайд демонстрирует индексированную структуру данных в аналоговом, а не
вцифровом виде.
Вкачестве примера индексированного файла – указатель книги, который показывает, как найти информацию в большом файле с помощью ключевой характеристики.
Другими словами, книга - это индексированная структура данных, а предметный указатель книги - это аналоговый индексный файл.
Слайд 5. База данных.
Всвоей работе мы редко ограничиваемся одним файлом, обычно мы собираем и используем многие файлы.
Организованный набор взаимосвязанных файлов данных называется базой данных. Сложность работы с множественными файлами в базе данных требует более сложного и совершенного управления, которое реализуется системами управления базами данных (СУБД).
ВГИС пользователь рассматривает реальный мир через призму тематической базы данных. Данные, содержащиеся в базе данных, должны как можно полнее и точнее соответствовать предмету исследования и его основным характеристикам.
Как вы уже знаете, географические объекты, моделируемые с помощью карты или ГИС, имеют три формы представления:
o объект в действительности;
o объект, представленный в базе данных;
o знак (символ), который используется для показа объекта на карте или на другом
графическом изображении.
Объект в БД - это цифровое представление всего реального объекта или его части. Это цифровое представление и его геометрии, и атрибутов. Представление данных должно учитывать типы их возможных преобразований.
К созданию БД ГИС предъявляются высокие требования, связанные с пространственной формой организации и представления данных.
База данных должна быть:
- согласованной по времени - хранящиеся в ней количественные данные должны соответствовать определенному времени, быть актуальными;
-полной, достаточно подробной для предполагаемого создания ГИС или картографического произведения; категории данных и их подразделения должны включать все необходимые сведения для осуществления анализа или математикокартографического моделирования исследуемого объекта или явления;
-позиционно точной, абсолютно совместимой с другими данными, которые могут добавляться в нее;
-достоверной, правильно отражающей характер явлений. Для этого необходимо четко определить включенные в нее атрибуты явлений;
-легко обновляемой;
-доступной для пользователей.
Слайд 6. Проектирование базы данных.
В процессе проектирования БД обычно выделяют три основных уровня: концептуальный, логический и физический.
Концептуальный уровень не зависит от имеющихся аппаратных и программных средств. Для БД ГИС он связан с концептуальной моделью географических данных и включает ответы на следующие вопросы:
oКакие данные будут храниться в БД. На концептуальном уровне определяется и содержание базы данных – список и значения атрибутов
oКаким способом будут представляться географические объекты в базе данных; выбор базовых типов пространственных объектов - точки, линии, полигоны, ячейки растра
o В какой проекции будут храниться данные
o Желаете ли вы установить специфические отношения между объектами. Например, будут ли объекты иметь топологию или специальные правила, контролирующие их редактирование и т.д.
o Какая задача основная: задачи создания одной или серии карт, или комплексного картографирования, или создания синтетических карт для многоцелевого и многократного использования.
Логический уровень определяется имеющимися программными средствами и практически не зависит от технического обеспечения. Он включает разработку логической структуры элементов базы данных в соответствии с системой управления базами данных (СУБД), используемой в программном обеспечении. Логическая система – это то, как ваша концептуальная модель представляется в компьютере с помощью программных средств.
Логический уровень отличается от концептуального также как материнская плата компьютера от ее принципиальной электрической схемы.
Физический уровень связан с аппаратными и программными средствами. На этом уровне определяются объемы хранимой в БД информации и необходимые объемы памяти компьютера (оперативной и долговременной), рассматриваются вопросы о структурировании файлов на диске или других носителях информации для обеспечения программного доступа к ним, представления данных в памяти компьютера (целые, действительные числа, байты или буквенно-цифровые характеристики).
Слайд 7. Системы управления базами данных в ГИС.
Как правило, ГИС создаются на основе уже существующих систем управления база-
ми данных (СУБД), приобретение или аренда СУБД составляет основную часть затрат на программное обеспечение системы. СУБД выполняет множество функций, которые в противном случае следовало бы программировать в ГИС. Отличают два пути использования СУБД в ГИС:
1) выполнение ГИС-процедур полностью через СУБД, тогда доступ ко всем данным осуществляется только через СУБД и все данные должны удовлетворять требованиям, заложенным при ее разработке;
2) некоторые данные (обычно таблицы атрибутов и их отношений) доступны через СУБД, поскольку они вполне соответствуют модели, а к некоторым данным (обычно пространственно локализованным) доступ прямой, так как они не удовлетворяют требованиям модели СУБД.
Наиболее распространенными моделями БД и их СУБД являются иерархическая, сетевая, реляционная и объектно-ориентированная .
Слайд 8. Иерархическая СУБД.
Во многих случаях существует взаимосвязь между данными, называемая отношением «один ко многим». Это отношение подразумевает, что каждый элемент данных имеет прямую связь с некоторым числом так называемых "потомков", и, конечно каждый такой потомок, в свою очередь, может иметь связь со своими потомками и т.д. Как следует из названия, предки и потомки напрямую связаны между собой, что делает доступ к данным простым и эффективным. Такая система хорошо иллюстрируется иерархической системой классификациитерриториальныхсубъектовРФ.
В иерархической модели записи данных образуют древовидную структуру, при этом каждая запись связана только с одной записью, находящейся на более высоком уровне. Ветвление основано на формальных ключевых признаках, которые определяют продвижение по этой структуре от одной ветви к другой. Иерархические модели хорошо подходят для задач с явно выраженной иерархически соподчиненной структурой информации и запросов.
Если ваше изначальное описание структуры неполно или если вы хотите двигаться по ней на основе корректного критерия, который не включен в структуру, то поиск становится невозможным.
Для создания иерархической структуры совершенно необходимо знание всех возможных вопросов, которые могут задаваться, поскольку эти вопросы используются как основа для разработки правил ветвления или ключей.
А это одна из наиболее трудных вещей – предвосхитить все возможные запросы пользователя. Помимо этого серьезного ограничения, иерархическая структура часто порождает большие индексные файлы. Это требует дополнительных затрат памяти для хранения данных и иногда вносит свой вклад также и в рост времени доступа. В связи с этим иерархические структуры обладают низким быстродействием, трудно модифицируемы, но эффективны с точки зрения организации машинной памяти.
Слайд 9. Сетевые СУБД.
Сетевые БД ГИС используют отношение "многие ко многим", при котором один элемент может иметь многие атрибуты, при этом каждый атрибут связан явно со многими элементами. Например, исследуемый участок может иметь много квадратов, с каждым из которых могут быть связаны несколько животных и растительных видов, при том, что каждый вид может присутствовать в более чем одном квадрате. Для реализации таких отношений вместе с каждым элементом данных может быть связана специальная переменная, называемая указателем (pointer), которая направляет нас ко всем другим элементам данных, связанным с этим. Каждый отдельный элемент данных может быть прямо связан с любым местом базы данных, без введения отношения "предок-потомок".
Слайд показывает два квадрата (№ 3 и №7) исследовательской площадки №4. Обратите внимание на то, как указатели используются для связи отдельных квадратов с представляющими их видами. Указатели обеспечивают и обратную связь от видов к квадратам, вкоторых онинаходятся.
В сетевых моделях каждая запись в каждом из узлов сети может быть связана с несколькими другими узлами; кроме данных записи содержат в себе указатели, определяющие местоположение других записей, связанных с ними. Подобные модели хорошо работают в случае решения сетевых, коммуникационных задач. Сетевые структуры обычно рассматриваются как усовершенствование иерархических структур, поскольку они менее жесткие и могут представлять отношение "многие ко многим". Поэтому онидопускают, гораздобольшуюгибкость поиска, нежели иерархические структуры. Также в отличие от иерархическихструктурониуменьшаютизбыточностьданных.
Их главным недостатком является то, что в крупных БД ГИС количество указателей может стать очень большим, требуя значительных затрат памяти. Вдобавок, хотя связи между элементами данных более гибкие, они все же должны быть явно определены с помощью указателей. Такие модели очень трудно редактировать, например, удалять записи, так как вместе с данными нужно редактировать и указатели. Многочисленные возможные связи
могут превратиться в весьма запуганную сеть, приводя часто к путанице, потерянным и ошибочнымсвязям.
Слайд 10. Реляционные СУБД.
Реляционные СУБД завоевали самую широкую популярность. Они свободны от всех ограничений, присущих иерархическим и сетевым структурам. Эти модели имеют табличную структуру: строки таблицы (записи) соответствуют одной записи сведений об объекте, а столбцы таблицы (поля) - содержат однотипные характеристики всех объектов. Способы индексации данных существенно сокращают время поиска и запроса к данным. К числу наиболее известных СУБД реляционного типа относятся dBASE, Foxbase, Paradox, ORACLE (последняя особенно подходит для больших объемов данных).
Реляционные системы основаны на наборе математических принципов, называемых реляционной алгеброй или алгеброй отношений, устанавливающей правила проектирования и функционирования таких систем. Поскольку реляционная алгебра основывается на теории множеств, каждая таблица отношений функционирует как множество, и первое правило гласит, что таблица не может иметь строку, которая полностью совпадает с какой-либо другой строкой. Поскольку каждая из строк уникальна, одна или несколько колонок могут использоваться для определения критерия поиска.
Реляционные системы ценны тем, что позволяют нам собирать данные в достаточно простые таблицы, при этом задачи организации данных также просты. Используя механизм реляционных баз данных, вы можете быстро сочетать данные, хранящиеся в отдельных таблицах. Этот связующий механизмназывается реляционнымсоединением.
Любое количество таблиц может быть "связано". Вы можете скомбинировать две таблицы по общему полю. Общие поля дифференцируются терминами первичный ключ и внешний ключ. Первичный ключ - это ключевое поле в таблице данных. Внешний ключ является общим полем в другой таблице. Соединение происходит по равенству значений записей первичного ключа одной таблицы с записями внешнего ключа второй таблицы. Записи с одинаковыми значениями полей первичного и внешнего ключей называются совпадающими.
Вы можете привязать сюда третью таблицу, взяв колонку второй таблицы, которая будет использоваться как первичный ключ к соответствующей ключевой колонке (теперь называемой внешним ключом) третьей таблицы. Процесс может продолжаться присоединением все новых простых таблиц для проведения довольно сложного поиска, причем набор таблиц остается очень простым и легко поддерживаемым. Этот подход устраняет путаницу, присущую разработке баз данных с использованием сетевых систем.
Слайд 11. Отношения между таблицами.
Чтобы соотнести таблицы правильно, вам необходимо знать, какой тип отношения существует между таблицами. Тип отношений характеризует понятие
кардинальность. Кардинальность определяет, сколько объектов типа А связано с объектами типа Б. Возможными отношениями между записями являются 1:1 (один-к- одному), 1:N (один-ко-многим), N:l (много-к-одному), а также N:N (много-ко-многим).
Способ, посредством которого осуществляется сообщение между таблицами, зависит от кардинальности. Поэтому необходимо знать кардинальность до установления связей между таблицами.
Слайд 12. Соединения и связи.
ArcGIS основана на реляционной СУБД. В зависимости от кардинальности отношений, возможны два способа сопоставления таблиц: соединение таблиц и связывание таблиц.
Операции соединения или связывания таблиц выполняются в ArcMap и вызываются из контекстного меню слоя.
Слайд 13. Соединение таблиц (Join).
Соединение – это операция, которая осуществляет сопоставление и присоединение двух таблиц. Выберите общее для каждой таблицы поле (первичный и внешний ключи) и сделайте активной целевую таблицу (таблицу назначения). Запустите функцию Соединение (Join). Когда операция соединения будет выполнена, записи из таблицы источника будут добавлены к таблице назначения. Результирующая таблица отображает все поля из таблицы назначения и таблицы источника, за единственным исключением: общее поле таблицы источника является скрытым. Файл таблицы источника остается существовать отдельно.
Соединение используется, прежде всего, с таблицами, отношение между которыми 1:1 (один-к-одному) или N:1 (многие-к-одному). Каждая запись в таблице назначения (уникальная или нет) соответствует одной уникальной записи из таблицы источника.
Чтобы осуществить соединение трех и более таблиц, сначала соедините первые две таблицы, затем повторите операцию, используя таблицу назначения от предыдущей операции соединения, а также новую таблицу источника.
Слайд 14. Связывание таблиц (Relate).
Связывание используется в первую очередь теми таблицами, которые находятся между собой в отношении 1:N или N:N. Когда таблицы связаны, выбор записей в таблице назначения влечет за собой автоматический выбор записей в связываемой таблице.
Связывание определяет отношение между записями двух таблиц, однако, в отличие от соединения, не происходит присоединения полей к таблице назначения. Исходные таблицы остаются независимыми.
Вы можете наблюдать результат связывания в момент, когда производите выбор в таблице назначения: «связанные» записи в таблице источника также становятся выбранным.
Слайд 15. Объектно-ориентированная модель данных.
Объектно-ориентированные модели данных, являясь более новой разработкой по сравнению с реляционными моделями, обеспечивают возможность многостороннего и комплексного описания реального мира и создания структуры данных, которую пользователи смогут легко понять. Здесь объекты являются моделями, очень близкими по своим свойствам и характеристикам объектам реального мира. Эта близость настолько сильна, что пользователи здесь оперируют не абстрактными понятиями баз данных, а привычными понятиями и названиями, такими как канализационные коллекторы, пожары, леса, владельцы зданий, проселочная дорога и т.д. и задают им поведение, копирующее или моделирующее какой-либо аспект их поведения в реальном мире. В упрощенном виде разницу между этими типами моделей можно представить так: объект хранит информацию о себе (все свои атрибуты) внутри себя, а не во множестве взаимосвязанных таблиц.
Например, в объектной модели речной сети будут использоваться линии, изображающие участок реки или приток, и каждый сегмент реки будет демонстрировать поведение, моделирующее его поведение в реальном мире: скорость течения, средняя глубина, объем потока, объем переносимого осадочного материала и т.д.
Такой подход возможно несколько ближе к структуре человеческого мышления. Ведь мы не мыслим таблицами или указателями. Нам проще всего воспринимать какойлибо объект в целом, при необходимости рассматривая его более детально. Здесь на слайде схематично показана объектно-ориентированная организация данных такого
сложного объекта, как мегаполис. Москва делиться на районы, каждый район делится на улицы и кварталы, каждый квартал имеет конкретное содержание: дома, парки, земельные участки, пруды, дороги и т.д.
Существуют три отличительных составляющих объектно-ориентированного подхода: полиморфизм, инкапсуляция и наследование.
Полиморфизм означает, что поведение объектов может адаптироваться к вариациям объектов. Сущность полиморфизма состоит в возможности программного кода работать с объектами разных классов одинаковым образом. Например, класс геометрических фигур (эллипс, многоугольник) может иметь методы для геометрических трансформаций (смещение, поворот, масштабирование). Полиморфизм позволяет писать более абстрактные программы и повысить коэффициент повторного использования кода.
Инкапсуляция означает, что всякий объект доступен только через четко определенный набор программных кодов, организованных в программные интерфейсы. Объекты доступа к данным БД скрывают внутренние детали устройства объектов данных и обеспечивают им единый стандартный программный интерфейс.
Инкапсуляция также обеспечивает степень независимости данных, чтобы не возникало необходимости изменять объекты при их взаимодействии с объектом, поведение которого изменилось.
Таким образом, инкапсуляция защищает данные от повреждения другими объектами, а также закрывает внутренние детали объектов от остальной системы.
Наследование означает, что класс объектов может включать в себя поведение другого класса объектов, а также иметь свое собственное дополнительное поведение. Это означает, что можно создавать собственные классы объектов, наследующие поведение стандартных классов. Например, класс объектов, «геологический полигон» может быть создан из стандартного класса «Полигон», наследуя все свойства полигонов, включая его атрибуты (периметр, площадь), поведение (способность изменять свою форму, масштабироваться, поворачиваться и др.), отношения с другими объектами (например, соседство или пересечение с объектами других классов).
Слайд 16. Компоненты объектно-ориентированной модели данных.
Кратко рассмотрим компоненты объектно-ориентированной модели данных.
Тот, кто знаком с современными объектно-ориентированными языками программирования, легко поймет структуру и идеология объектно-ориентированной