Ведение баз данных кадастрового учета

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

Рубрика Сельское, лесное хозяйство и землепользование
Вид реферат
Язык русский
Дата добавления 17.12.2015
Размер файла 300,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://allbest.ru

Размещено на http://allbest.ru

Ведение баз данных кадастрового учёта

Введение

кадастровый учет база данных

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

1. Что такое данные

Данные -- зарегистрированная информация; представление фактов, понятий или инструкций в форме, приемлемой для общения, интерпретации, или обработки человеком или с помощью автоматических средств (ISO/IEC/IEEE 24765-2010)

В информатике и информационных технологиях:

Данные -- поддающееся многократной интерпретации представление информации в формализованном виде, пригодном для передачи, связи, или обработки (ISO/IEC 2382-1:1993).

Данные -- формы представления информации, с которыми имеют дело информационные системы и их пользователи (ISO/IEC 10746-2:1996).

В метрологии:

Данные -- совокупность значений, сопоставленных основным или производным мерам и/или показателям (ISO/IEC 15939:2007, ISO/IEC 25000:2005).

Хотя информация должна обрести некоторую форму представления (то есть превратиться в данные), чтобы ей можно было обмениваться, информация есть в первую очередь интерпретация (смысл) такого представления (ISO/IEC/IEEE 24765:2010). Поэтому в строгом смысле информация отличается отданных, хотя в неформальном контексте эти два термина очень часто используют как синонимы.

2. Что такое База данных

База данных -- представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)

Определения из международных стандартов:

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

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

Определения из авторитетных монографий:

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

База данных -- некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

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

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

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

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

3. БД включает схему, или метаданные, описывающие логическую структуру БД в формальном виде (в соответствии с некоторой метамоделью). В соответствии с ГОСТ Р ИСО МЭК ТО 10032-2007, «постоянные данные в среде базы данных включают в себя схему и базу данных. Схема включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных. База данных включает в себя набор постоянных данных, определённых с помощью схемы. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных».

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

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

Классификация по модели данных

· Иерархическая

· Объектная и объектно-ориентированная

· Объектно-реляционная

· Реляционная

· Сетевая

· Функциональная.

Классификация по среде постоянного хранения

· Во вторичной памяти, или традиционная (англ. conventional database): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) -- как правило жёсткий диск. В оперативную память СУБД помещает лишь кеш и данные для текущей обработки.

· В оперативной памяти (англ. in-memory database, memory-resident database, main memory database): все данные на стадии исполнения находятся в оперативной памяти.

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

Классификация по содержимому

· Географическая

· Историческая

· Научная

· Мультимедийная

· Клиентская.

Классификация по степени распределённости

· Централизованная, или сосредоточенная (англ. centralized database): БД, полностью поддерживаемая на одном компьютере.

· Распределённая (англ. distributed database): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.

· Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД

· Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.

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

· Тиражированная (англ. replicated database): методом распределения данных является тиражирование (репликация).

Другие виды БД

· Пространственная (англ. spatial database): БД, в которой поддерживаются пространственные свойства сущностей предметной области. Такие БД широко используются в геоинформационных системах.

· Временная, или темпоральная (англ. temporal database): БД, в которой поддерживается какой-либо аспект времени, не считая времени, определяемого пользователем.

· Пространственно-временная (англ. spatial-temporal database) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.

· Циклическая (англ. round-robin database): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения новых данных они заменяют более старые данные. Одни и те же ячейки для данных используются циклически.

Сверхбольшая база данных:

· Сверхбольшая база данных (англ. Very Large Database, VLDB) -- это база данных, которая занимает чрезвычайно большой объём на устройстве физического хранения. Термин подразумевает максимально возможные объёмы БД, которые определяются последними достижениями в технологиях физического хранения данных и в технологиях программного оперирования данными.

· Количественное определение понятия «чрезвычайно большой объём» меняется во времени; в настоящее время считается, что это объём, измеряемый по меньшей мере петабайтами. Для сравнения, в 2005 г. самыми крупными в мире считались базы данных с объёмом хранилища порядка 100 терабайт.

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

· Исследования в области хранения и обработки сверхбольших баз данных VLDB всегда находятся на острие теории и практики баз данных. В частности, с1975 года проходит ежегодная конференция International Conference on Very Large Data Bases («Международная конференция по сверхбольшим базам данных»). Большинство исследований проводится под эгидой некоммерческой организации VLDB Endowment (Фонд целевого капитала «VLDB»), которая обеспечивает продвижение научных работ и обмен информацией в области сверхбольших БД и смежных областях.

3. Что такое система управления базами данных

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

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

Основные положения

База данных (БД) в строгом смысле слова представляет собой совокупность взаимосвязанных файлов данных определенной организации. БД, как правило, включает целый ряд файлов, но может состоять и из единственного файла. Данные, составляющие БД, отражают характеристики объектов и их отношений в соответствующей прикладной области. Каждый файл, входящий в БД, содержит определенное число записей (изменяемое в процессе функционирования БД), отражающих ту или иную сторону (это определение таблицы, а не файла БД) предметной области, на которую ориентирована БД. Как правило, файлы БД содержат большое число однотипных записей (совершенно не правило). Думаю, лучше ввести понятие таблица или набор записей). Записи, в свою очередь, состоят из полей, представляющих определенные типы информации об объектах. Поле является наименьшей информационной единицей, непосредственно доступной в записи. Если файл_1 БД (рис. 1) содержит п однотипных записей (имеющих одинаковую структуру полей и их смысловую нагрузку),то j-запись (1<j<n) файла состоит из фиксированного набора (кортежа полей А1--Ак), каждое из которых содержит в общем случае различного типа информацию. При наличии БД прикладные программы могут использовать ее информацию (записи и их поля) для решения конкретных задач в прикладной области, на которую ориентирована данная БД.

TODO: таблица Файловая организация баз данных

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

Классификация СУБД, типы СУБД, виды СУБД

По типу управляемой базы данных СУБД разделяются на:

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

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

Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Definition Language -- язык определения данных) и DML (Data Manipulation Language -- язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие, программист по-прежнему должен знать структуру базы данных. В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

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

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

С помощью ООСУБД решаются две проблемы. Во-первых, сложные информационные структуры выражаются в них лучше, чем в реляционных базах данных, а во-вторых, устраняется необходимость транслировать данные из того формата, который поддерживается в СУБД. Например, в реляционной СУБД размерность целых чисел может составлять 11 цифр, а в используемом языке программирования -- 16. Программисту придется учитывать эту ситуацию. Объектно-ориентированные СУБД выполняют много дополнительных функций. Это окупается сполна, если отношения между данными очень сложны. В таком случае производительность ООСУБД оказывается выше, чем у реляционных СУБД. Если же данные менее сложны, дополнительные функции оказываются избыточными. В объектной модели данных поддерживаются нерегламентированные запросы, но языком их составления не обязательно является SQL. Логическое представление данных может не соответствовать реляционной модели, поэтому применение языка SQL станет бессмысленным. Зачастую удобнее обрабатывать объекты в памяти, выполняя соответствующие виды поиска. Большим недостатком объектно-ориентированных баз данных является их тесная связь с применяемым языком программирования. К данным, хранящимся в реляционной СУБД, могут обращаться любые приложения, тогда как, к примеру, Java-объект, помещенный в ООСУБД, будет представлять интерес лишь для приложений, написанных на Java.

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

По архитектуре СУБД и организации хранения данных:

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

По способу доступа СУБД к базе данных:

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

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

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

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

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

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

Управление транзакциями

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

Журнализация

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что, исходя из архивной копии по журналу, воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

4. Использование БД в кадастровом учете

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

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

При формировании системы показателей земельно-кадастровых баз и банков данных возможно использовать следующие основные подходы:

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

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

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

Рисунок - Структура банка земельно-кадастровых данных.

Земельно-кадастровые показатели

При формировании системы земельно-кадастровых показателей области должна быть использована следующая информация:

-- данные государственного учета и оценки земель;

-- информация о коммуникациях, инженерных сетях,

-- статистическая информация;

-- картографические материалы, в том числе топографические, почвенные, геоботанические и другие карты;

-- материалы наземных почвенных, геоботанических и других наземных обследований, осуществляемых службами МСХ, Минприроды, РосИМЗа;

-- материалы дистанционного зондирования. По длительности периода наблюдений может быть использована следующая информация:

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

-- периодическая, собираемая с определенным интервалом (например, 1 раз в 5 лет);

-- данные мониторинга земель;

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

Заключение

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

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

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

Список литературы

1. http://websecuregroup.ru/

2. http://www.consultant.ru/

3. https://ru.wikipedia.org/wiki/

4. http://elhow.ru/programmnoe-obespechenie/

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.