Институт телекоммуникаций докт
Работа добавлена на сайт samzan.net:
Санкт-Петербургский государственный университет
В.Ю. ТРЕТЬЯКОВ
БАЗЫ ЭКОЛОГИЧЕСКИХ ДАННЫХ
Методическое пособие
Санкт-Петербург
2005
УДК 91(075.8)
ББК 26.8я73
Т66
Рецензенты: докт. геогр. наук Г.К. Осипов (НИО-3 ЗАО «Институт телекоммуникаций»),
докт. геогр. наук В.А. Шелутко (Российский государ-
ственный гидрометеорологический университет)
Печатается по решению
Ученого совета Учебно-научного центра
географии и геоэкологии
Санкт-Петербургского государственного университета
Третьяков В.Ю.
Т66 Базы экологических данных: Метод. пособие. – СПб.: Изд-во С.-Петерб. ун-та, 2005. – 16 с.
ISBN 5-288-03635-7
В пособии изложены понятия, связанные с базами данных (БД) и системами управления базами данных (СУБД) и рассмотрены методы их применения для компьютерной обработки геоэкологической информации. Разработано на основе курса лекций «Базы экологических данных» для студентов 3-го курса специальностей геоэкология и природопользование.
Пособие предназначено для студентов географических факультетов высших учебных заведений, обучающихся по специальностям “Геоэкология”, “Природопользование”, “География” и направлению “Экология и природополь зование”.
ББК 26.8я73
© В.Ю. Третьяков2005
© Факультет географии и геоэкологии
Санкт-Петербургского государственного
ISBN 5-288-03635-7 университета, 2005
ИСТОРИЯ И КЛАССИФИКАЦИЯ БАЗ ДАННЫХ И СУБД
Успех или неудача в разных сферах деятельности во многом зависят от скорости получения и обработки информации. Очевидный путь ускорения работы с данными – формализация и структурирование их хранения. Ещё задолго до изобретения первых ЭВМ существовали картотеки, данные сводились в таблицы. В конце 19 века была изобретена перфокарта – карточка из плотной бумаги с прямоугольными дырочками. Расположение этих дырочек определяло записанную на перфокарте числовую и символьную информацию. Перфокарты предназначались для автоматизированной обработки данных при помощи электромеханических счетных устройств. В 40-е годы 20-го века появились первые ЭВМ. Данные хранились в колодах перфокарт, на перфолентах (бумажная лента с круглыми дырочками) и на магнитных лентах. Естественно, структурированное хранение данных не является самоцелью – это необходимое условие их автоматизированной обработки. В 40-50 гг. 20-го века для обработки каждого набора данных приходилось разрабатывать свои компьютерные программы. Ситуация в чем-то напоминала зарю артиллерии, когда каждое орудие имело свой уникальный калибр. При этом, что гораздо хуже, уход разработчика программного обеспечения в большинстве случаев означал необходимость новой разработки форматов хранения данных и компьютерных программ. К концу 50-х гг. в связи с ростом парка ЭВМ ситуация стала совершенно недопустимой. Стала ясной необходимость унификации структур наборов данных и программных средств их обработки. Тогда и были созданы первые базы данных (БД) и программные средства для их обработки – системы управления базами данных (СУБД). База данных - совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и обработки данных, независимо от прикладных программ. СУБД - комплекс программ и языковых средств, предназначенных для создания, ведения и использования баз данных. Конкретная СУБД имеет свой собственный формат файлов баз данных, однако можно создать другие программные продукты, способные обрабатывать файлы этого формата. Принципы обработки данных определяются именно их структурой. Аналогия: в России расстояние между колесами локомотивов и подвижного состава с середины 19 века определяется неизменной шириной железнодорожной колеи.
СУБД иерархической модели получили широкое распространение в начале 60-х гг. 20-го века. Тогда основным носителем информации служили магнитные ленты, и СУБД для поиска данных было необходимо знать их физическое местоположение на ленте. В них единицы хранения данных - записи образуют древовидную структуру - каждая из них связана с одной записью, находящейся на более высоком уровне иерархии. Доступ к любой из записей осуществляется путем прохода по строго определенной цепочке узлов дерева с последующим просмотром соответствующих этим узлам записей. Например, база данных студентов университета подразделяется на факультеты, отделения, курсы, группы (кафедры). Чтобы «добраться» до данных по конкретному лицу, было необходимо указать всю цепочку указателей: факультет, отделение, курс, группа. Только в этом случае ЭВМ «понимала», в какой части магнитной ленты искать данные.
Сетевые модели были призваны устранить некоторые из недостатков иерархических моделей. Они являлись стандартом в середине 70-х гг. Здесь каждый из узлов может иметь не один, а несколько узлов-родителей. Записи, входящие в состав сетевой структуры, содержат в себе указатели, определяющие местоположение других записей, связанных с ними. При сетевой модели появилась возможность «прохода» к данным не по одному возможному пути, а по сети соединяющих узлы маршрутов. Если продолжить пример, то здесь до данных конкретного студента можно было добраться, имея отправной точкой или факультет, или курс. Такая модель позволила ускорить доступ к данным, но изменение структуры базы данных по-прежнему требовало значительных усилий и времени. Модификация и удаление данных требовали перестановки указателей, а манипулирование данными осталось ориентированным на записи и описывалось алгоритмическим языком процедурного типа. Для поиска отдельной записи в иерархической или сетевой структуре программист был должен вначале определить путь доступа, а затем просмотреть все записи, лежащие на этом пути. На каждом шагу приходилось определять индивидуальные управляющие команды и условия, с помощью которых обрабатываются исключительные ситуации (например, обнаружение конца просматриваемых записей).
В 1969 г. сотрудником фирмы IBM Е.Ф.Коддом была предложена реляционная модель базы данных. Она представляет собой хранилище данных, содержащее набор двухмерных таблиц. Набор средств управления подобным хранилищем называется реляционной системой управления базами данных (РСУБД). РСУБД может содержать утилиты, приложения, сервисы, библиотеки, средства создания приложений и другие компоненты.
СУБД реляционного типа освобождают пользователя от всех сложностей, связанных с физической организацией хранения данных и спецификой аппаратуры. Пользователь совершенно не обязан знать распределение данных на магнитном носителе. Изменение физической структуры базы данных не влияет на работоспособность прикладных программ. Однако развитие этих СУБД стало возможно только после создания устройств хранения данных с произвольным (прямым) доступом: магнитных барабанов и дисков, поскольку реализация реляционных баз данных (БД) на накопителях с последовательным доступом к физическим элементам данных (магнитных лентах) практически невозможна. Реляционными они названы потому, что данные в них представлены в виде отношения (англ. relation), т.е. таблицы. Колонки называются полями, строки - записями. (Иногда колонки называются атрибутами отношений, а записи – кортежами отношений.) Существует качественное отличие СУБД от электронных таблиц: при создании нового файла необходимо описать его структуру, т.е. определить наименования и характеристики полей - их ширину и тип (числовое, текстовое и т.д.). В электронной таблице можно, конечно, записать в верхнюю клетку столбца его название. В БД название поля "записано" вне самой таблицы. Современные реляционные СУБД автоматически выполняют такие системные функции, как восстановление после сбоя и одновременный доступ к разделяемым данным нескольких пользователей. Такой подход избавляет пользователя от необходимости знать методы доступа и методы управления памятью компьютера. Преимущества реляционных моделей данных заключаются в следующем: 1) в распоряжение пользователя предоставляется простая структура данных - они рассматриваются как таблицы; 2) пользователь не обязан знать, каким образом данные расположены в базе; 3) возможно использование простых непроцедурных языков запроса; 4) имеется механизм блокировки, предотвращающий переход системы в противоречивое состояние в результате одновременного поступления двух или более запросов к одному и тому же элементу данных. Недостаток - пути доступа к данным заранее не определены и при обработке запросов приходится просматривать всю базу. Для его устранения допускается задание вспомогательных описаний путей доступа.
Любая таблица реляционной базы данных состоит из строк (записей) и столбцов (полей). Строки таблицы содержат сведения о представленных в ней однотипных объектах. На пересечении столбца и строки находятся значения содержащихся в таблице данных - характеристики объекта.
Таблицы строятся по следующим принципам: 1) Каждое значение, содержащееся на пересечении строки и колонки, должно быть атомарным (то есть не расчленяемым на отдельные величины); 2) Значения данных в одной и той же колонке (поле) должны принадлежать к одному и тому же типу, доступному для использования в данной СУБД;
3) Каждая строка (запись) в таблице уникальна, то есть в таблице не должно существовать двух записей с полностью совпадающим набором значений ее полей; 4) Каждое поле имеет уникальное имя; 5) Последовательность полей в таблице несущественна; 6) Последовательность записей также несущественна.
Хотя порядок строк в таблице не важен, но в любой момент физически строки в таблице расположены в определенном порядке. В первых СУБД существовала возможность вызова строки по её номеру. Любая СУБД позволяет сортировать строки таблицы по значениям определенного поля или совокупности полей. Например, отсортировать таблицу с данными студентов в алфавитном порядке их фамилий, имен и отчеств. При этом таблица с новым порядком строк может быть записана в новый файл.
Последовательность колонок (полей) в таблице несущественна, обращение к ним производится по имени, и эти имена для данной таблицы должны быть уникальны, но не обязаны быть уникальными для всей базы данных, поскольку база данных может состоять более чем из одной таблицы.
Широкое применение реляционных СУБД стало возможно лишь после распространения персональных компьютеров (ПК), т.е. с середины 80-х гг. 20-го века. В настоящее время СУБД подразделяются на настольные и серверные. Первые предназначены для работы на персональных компьютерах, вторые – использования компьютерных сетей. Если персональный компьютер имеет выход в сеть, то и настольная СУБД может обращаться к удаленным данным, хранящимся на другом компьютере. Однако в этом случае обработка удаленных данных выполняется самим ПК, что требует загрузки данных в его память и «перекачки» всей таблицы по компьютерной сети. В серверной СУБД данные и хранятся, и обрабатываются на одном мощном компьютере, где функционирует специальная программа (приложение или сервис), называемая сервером баз данных. На подключенных к сети персональных компьютерах функционируют программы – клиентские приложения, которые посылают на сервер запросы. Сервер в соответствии с ними производит обработку баз данных и посылает на персональные компьютеры только результаты запросов.
Первая коммерческая настольная СУБД - dBase II была разработана в 1984 г. американской компанией Ashton-Tate. В 1986 г. вышла версия dBase III Plus, занявшая лидирующие позиции среди настольных СУБД и средств создания использующих их приложений. Хранение данных в dBase было основано на принципе «одна таблица — один файл». Эти файлы имеют расширение *.dbf. Впоследствии права на эту СУБД перешли компаниям Borland, затем - dBase Inc. Современная версия этой СУБД имеет название Visual dBase. Формат файлов dBase применяется в ГИС фирмы ESRI для хранения атрибутивной (семантической) информации.
СУБД Paradox была разработана компанией Ansa Software в 1985 г. и впоследствии приобретена компанией Borland. С 1996 г. она принадлежит компании Corel и является составной частью Corel Office Professional. Хранение данных в Paradox сходно с dBase — каждая таблица хранится в своем файле с расширением *.db.
СУБД FoxPro происходит от СУБД FoxBase фирмы Fox Software конца 80-х гг. Эта компания стремилась создать СУБД, функционально совместимую с dBase по организации файлов и языку программирования, но существенно превышающую ее по производительности. Впоследствии эта СУБД была приобретена компанией Microsoft. Её версии с 1995 году получили название Visual FoxPro. Особенностью этой СУБД является разнотипность файлов её объектов. База данных (*.dbc) может состоять из многих отдельных таблиц (*.dbf). Ссылки на все компоненты создаваемого приложения хранятся в файле проекта. Отличительная особенность СУБД - интеграция с технологиями Microsoft, в том числе поддержка COM (Component Object Model — компонентной объектной модели, являющейся основой функционирования 32-разрядных версий Windows), интеграция с Microsoft SQL Server, возможность создания распределенных приложений, основанных на концепции Windows DNA (Distributed interNet Applications). Из настольной СУБД Visual FoxPro превращается в средство разработки приложений в архитектуре «клиент/сервер» и распределенных приложений в архитектуре Windows DNA. Впрочем, и dBase, и Paradox также позволяют осуществлять доступ к наиболее популярным серверным СУБД.
Первая версия СУБД Access появилась в начале 90-х годов. Она являлась первой СУБД для 16-разрядной версии Windows. Её популярность значительно возросла после включения в состав Microsoft Office.
Visual FoxPro фактически превратился в средство разработки приложений, т.е. рассчитан на лиц, занимающимися программированием. Access же в первую очередь ориентирован на рядовых пользователей Microsoft Office, не знакомых с программированием. Поэтому вся относящаяся к конкретной базе данных информация хранится в одном файле с расширением *.mdb, что удобно для начинающих пользователей. Microsoft Access используется в качестве настольной СУБД и составной части офисного пакета. С другой стороны он может использоваться в качестве клиента Microsoft SQL Server, осуществляющего манипуляцию его данными и создание приложений для этого сервера. Access позволяет также в качестве хранилища данных использовать Microsoft Data Engine (MSDE), представляющий собой по существу настольный сервер баз данных, совместимый с Microsoft SQL Server.
Наиболее популярными серверными СУБД являются Oracle, Microsoft SQL Server, Informix, Sybase, DB2.
СУБД могут выполнять обработку данных в соответствии с командами пользователя, отдаваемыми при помощи средств интерфейса данной СУБД (кнопки, ниспадающие меню и т.д.), либо при помощи разработанного приложения (программы). СУБД для этого имеют языки создания приложений интерпретирующего и компилирующего типов. В первом случае приложение может быть запущено только в самой СУБД. Во втором случае создается исполняемый exe-файл, для работы которого не требуется СУБД. Некоторые СУБД, например FoxPro, предоставляют обе эти возможности.
Пользователю, знакомому с интегрированной средой разработки Windows-приложений Visual Basic (VB) для работы с некоторыми БД нет необходимости изучать конкретные СУБД - Visual Basic предоставляет широкие возможности создания баз данных и их обработки. С появлением версии Visual Basic 6 простые приложения стало возможно создавать, практически не прибегая к написанию программного кода, а в сложных приложениях процесс создания программного кода сведен к минимуму. Редактором баз данных здесь служит утилита (включенная в пакет VB сервисная программа) Visual Data Manager. Необходимо заметить, что базы данных Microsoft Access являются для системы Visual Basic «родными», поэтому с таблицами Access написанные на VB приложения управляются лучше всего. Однако базы данных dBase, Paradox, FoxPro, таблицы Excel и текстовые файлы также можно создавать и обрабатывать при помощи созданных на VB приложений.
ТИПЫ ДАННЫХ
В полях реляционных СУБД могут храниться данные разных типов: строки (String); логические значения (Logical) – «да» (true) или «нет» (false); числа (Number) разных типов; валюта (Currency) - специальный тип числовых данных для хранения денежных величин; дата и время (Date). Некоторые БД, например, dBase, поддерживают только формат даты, но не имеют возможности хранить в специализированном формате время. В этом случае приходится хранить время в строковом типе; MEMO-поля для хранения длинных текстов. Фактически текст находится во внешнем файле, в таблице же хранится ссылка на него и при необходимости текст «подгружается» в память компьютера. Обычно максимальная длина текста все же ограничена какой-нибудь величиной (например, 32 Kбайт, 2 Гбайт); BLOB-поля - BLOB (Binary Large Object) представляет собой просто набор байтов. В таком поле можно хранить любые данные (текст, графику, multimedia-данные, и т.д.). Некоторые СУБД поддерживают специальные типы BLOB-данных, например специальные поля для хранения графических данных. Существуют БД, поддерживающие более сложные типы, такие как массивы, «вложенные» таблицы и т.п.
НОРМАЛИЗАЦИЯ ДАННЫХ
Поскольку порядок строк в реляционной таблице не важен, нужно поле (или набор из нескольких полей) для уникальной идентификации каждой записи (строки). Такое поле или их набор называется первичным ключом (primary key). Первичный ключ любой таблицы обязан содержать уникальные непустые значения для каждой строки. Если первичный ключ состоит из нескольких полей, он называется составным (composite) первичным ключом.
В общем случае БД обычно состоит из нескольких связанных таблиц. Таблицы связываются между собой при помощи значений в каком-либо поле. Поле, указывающее на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign key). Т.е. внешний ключ — это поле или набор полей, чьи значения совпадают с имеющимися значениями первичного ключа другой таблицы. Подобное взаимоотношение между таблицами называется связью (relationship). Если значение в первой таблице связано только с одним значением в другой таблице, то эти две таблицы связаны соотношением «один-к-одному» (one-to-one relationship). Если же значение (объект) в первой таблице может быть связано с произвольным числом объектов во второй таблице, то эти две таблицы связаны соотношением один-ко-многим (one-to-many relationship) или соотношением master-detail. Подобные соотношения между таблицами используются наиболее часто. В этом случае таблица, содержащая внешний ключ, называется detail—таблицей, а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа, называется master-таблицей.
Группа связанных таблиц называется схемой базы данных (database schema). Информация о таблицах, их полях (имя, тип данных, длина), первичных и внешних ключах, а также иных объектах базы данных, называется метаданными (metadata). Любые манипуляции с данными в базах данных, такие как выбор, вставка, удаление, обновление данных, изменение или выбор метаданных, называются запросом к базе данных (query). Обычно запросы формулируются на каком-либо языке, который может быть как стандартным для разных СУБД, так и зависящим от конкретной СУБД.
Первичный ключ любой таблицы должен содержать уникальные непустые значения для данной таблицы. Это утверждение является одним из правил ссылочной целостности (referential integrity). Некоторые СУБД могут контролировать уникальность первичных ключей.
Если две таблицы связаны соотношением master-detail, внешний ключ detail-таблицы должен содержать только те значения, которые уже имеются среди значений первичного ключа master-таблицы. Если корректность значений внешних ключей не контролируется данной СУБД, возможны нарушения ссылочной целостности. Например, в master-таблице приводится перечень ландшафтов, в detail-таблице – сведения о конкретных участках местности, или в master-таблице содержатся сведения о наблюдаемых параметрах, в detail-таблице – данные конкретных измерений. Внешние ключи – идентификаторы типов ландшафтов или регистрируемых величин. Если в master-таблице с перечнем регистрируемых параметров будет удалена запись, то соответствующие этому параметру значения в detail-таблице будут характеризовать неизвестный параметр и произойдет нарушение ссылочной целостности. Большинство современных СУБД способны контролировать соблюдение правил ссылочной целостности, если таковые описаны в базе данных. В этом случае все попытки нарушить правила ссылочной целостности будут подавляться с одновременной генерацией диагностических сообщений.
Процесс проектирования данных представляет собой определение метаданных в соответствии с задачами создаваемой информационной системы. Одним из основных принципов проектирования баз данных является принцип нормализации: процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий в хранении данных с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных.
Теория нормализации основана на концепции нормальных форм (НФ). Таблица находится в данной нормальной форме, если она удовлетворяет определенному набору требований. Теоретически существует пять нормальных форм, но на практике обычно используются только первые три. Первые две нормальные формы являются промежуточными шагами для приведения базы данных к третьей нормальной форме.
Чтобы таблица соответствовала первой НФ, все значения ее полей должны быть атомарными, и все записи — уникальными. Поэтому любая не содержащая повторов строк реляционная таблица уже находится в первой нормальной форме. С ней уже можно работать. Однако эта таблица может содержать избыточные данные. Например, в базе данных результатов мониторинга среды наименование параметра (концентрация такого-то вещества), размерность и величина ПДК будут неоднократно повторяться. Результатом избыточности данных являются аномалии модификации данных — проблемы, возникающие при добавлении, изменении или удалении записей. Например, при редактировании данных возникнут следующие проблемы: сведения о ПДК данного вещества содержатся лишь в том случае, если произведено его хотя бы однократное определение; при удалении записи удаляются сведения об этом веществе и его ПДК; неизбежно обновление всех записей по данному веществу при изменении величины его ПДК.
Некоторые из этих проблем решаются путем приведения базы данных ко второй НФ. Таблица находится в ней, если она находится в первой нормальной форме и ее неключевые поля полностью зависят от всего первичного ключа.
Предположим, разрабатывается база данных для хранения результатов мониторинга окружающей среды. Первая возможная ошибка – пытаться создать структуру таблиц исходя из соображений оптимизации их представления в тексте. То, насколько читабельна будет реляционная таблица на экране или в распечатанном виде, лучше вообще не принимать во внимание. В идеале непосредственно таблицу пользователю вообще не придется рассматривать. Занесение данных в базу данных производится при помощи разработанных форм заполнения, результаты обработки представляются в виде отчетов. Сама обработка осуществляется средствами интерфейса СУБД или при помощи специально созданного приложения. В текстовых таблицах обыкновенно для каждого определенного параметра отводится отдельный столбец, строки отводятся для отдельных проб. Если в какой-либо пробе определены не все параметры, в соответствующих местах таблицы просто ставится прочерк. Что же произойдёт, если создадим реляционную таблицу с подобной структурой? Если БД создаётся в формате FoxPro, то в пустых местах числовых полей можно будет поставить значение «нет данных» и неприятности ограничатся перерасходом памяти. Но в формате dBase такой возможности нет, и СУБД в незаполненные ячейки числовых полей поставит значение 0, что приведет к вопиющим ошибкам при обработке БД. Можно, конечно, для каждого числового поля создать логическое поле, разъясняющее, являются ли числовые значения действительными или нет, и учитывать значения логических полей при обработке БД. Однако такой подход громоздок и чреват ошибками. Поэтому в таблицах вообще не должно быть пустых ячеек.
Поэтому для хранения числовых значений различных определяемых параметров можно использовать одно поле, а в другом (строковом или числовом) держать идентификаторы параметров. Разумеется, число строк таблицы увеличится, но зато теперь мы гарантированы от появления пустых ячеек. Для получения исчерпывающей информации понадобится поле с «расшифровкой» параметров, а также единиц измерений (определений). Специфика геоэкологических данных заключается в том, что в абсолютном большинстве случаев они должны иметь пространственную и временную привязку. Также при создании базы экологических данных необходимо иметь в виду возможность её последующего использования в геоинформационных системах. В качестве первичного ключа рассматриваемой таблицы можно использовать комбинацию из поля с уникальным номером (или символьным идентификатором пробы) и поля идентификаторов параметров, т.к. в одной пробе может определяться много параметров. Обыкновенно мониторинг производится периодически в одних и тех же пространственных точках. Поэтому необходимо поле уникальных идентификаторов точек мониторинга. Также понадобятся поля с пространственными координатами точек, датами и, возможно, временем измерений или отбора проб. Если в БД сводятся результаты исследований водных объектов, то необходимы поля с данными о глубинах точек, глубинах (горизонтах) отбора проб. Возможны два случая: просто горизонт отбора пробы (например, 5 м) или слой (от 5 до 10 м), что часто встречается при гидробиологических исследованиях (вертикальный «облов» гидробионтов при помощи сети). Если исследуются также и донные грунты, то, вероятно, придется добавить поле, идентифицирующее объект исследований – водная толща или дно, глубину слоя донных осадков и т.д. Если БД посвящена наземным геосистемам, то в ней должны быть поля со сведениями о типе исследуемой среды (почва, растительность), глубине отбора почвенных образцов, почвенном горизонте, типе почв, типе ландшафтного таксона и т.д.
Очевидно, что рассматриваемая таблица будет находиться в первой, но не во второй нормальной форме, так как, например, поле номеров точек зависит только от поля номеров проб, являющегося частью составного первичного ключа. Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги: 1) Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (эти части не обязаны состоять из одного поля!); 2) Создать новую таблицу для каждой такой части первичного ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы; 3) Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех их них, которые станут внешними ключами.
Например, все данные по точкам отбора проб (координаты, глубина и т.д.) перемещаются в отдельную таблицу, в которой поле идентификаторов точек становится первичным ключом. Связь между таблицей результатов мониторинга и таблицей характеристик точек отбора проб будет осуществляться по этому полю, которое будет внешним. При этом связь будет связью типа многие-к-одному.
Однако таблицы, находящиеся во второй, но не в третьей нормальной форме, по-прежнему содержат аномалии модификации данных, вызванные тем, что существуют взаимосвязи между неключевыми полями (транзитивные зависимости). Устранить эти аномалии можно путем перехода к третьей нормальной форме. Таблица находится в ней, если она уже находится во второй нормальной форме и все ее неключевые поля зависят только от первичного ключа (не одно из неключевых полей не зависит функционально от любого другого неключевого поля). Пример транзитивной зависимости: значение параметра зависит от единиц измерения. Чтобы перейти от второй нормальной формы к третьей, следует выполнить следующие шаги: 1) Определить все поля (или группы полей), от которых зависят другие поля; 2) Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы; 3) Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Нормализация устраняет избыточность данных, что позволяет снизить объем хранимых данных и избавиться от аномалий их изменения. Теоретики реляционных систем Кодд и Бойс обосновали и предложили более строгое определение для третьей НФ, которое учитывает, что в таблице может быть несколько возможных ключей. Таблица находится в нормальной форме Бойса-Кодда (НФБК), только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа. Возможный ключ – это минимальный набор полей, по значениям которых можно найти требуемую строку таблицы (запись). Минимальность означает, что исключение из набора полей любого поля не позволяет найти запись по оставшимся полям. Каждая таблица обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального количества полей. Нецелесообразно также использовать ключи с длинными строковыми значениями – предпочтительнее использовать целочисленные атрибуты. Для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества и номера группы и дополнительных атрибутов, т.к. не исключено появление в группе двух студентов с одинаковыми фамилиями, именами и отчествами. Не допускается, чтобы любой атрибут, участвующий в первичном ключе, принимал неопределенное значение.
Таблицу можно разбить на несколько таблиц, называемых проекциями. Полной декомпозицией таблицы называют такую совокупность произвольного числа ее проекций, соединение которых полностью совпадает с содержимым таблицы. Таблица находится в пятой НФ форме только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в пятой НФ. Четвертая НФ является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ.
В большинстве реляционных СУБД ключи реализуются с помощью объектов, называемых индексами, которые можно определить как список номеров записей, указывающий, в каком порядке их предоставлять. Индекс по определенному полю — это последовательность номеров записей, в соответствии с которой их нужно обрабатывать или выводить на экран. Возможно создание индексов по совокупности полей. Хранение индексов требует существенно меньше места, чем хранение по-разному отсортированных версий самой таблицы. Использование индексов снижает время выборки данных. В современных СУБД любое изменение данных в таблице влечет за собой автоматическое изменение связанных с ней индексов (они называются поддерживаемыми), что увеличивает время операций. Поэтому следует создавать только те индексы, которые реально необходимы, и руководствоваться при этом наиболее частыми запросами.
Большинство современных серверных СУБД содержат ограничения (constraints) или правила (rules). Они содержат сведения об ограничениях, накладываемых на возможные значения полей. Существуют также ссылочные ограничения возможных значений связанных полей. СУБД поддерживают представления (views) – виртуальные таблицы, предоставляющую данные из одной или нескольких реальных таблиц. Фактически view — это хранимый запрос.
Триггеры и хранимые процедуры современных серверных СУБД используются для хранения исполняемого кода. Хранимые процедуры выполняются сервером баз данных. Они пишутся на процедурном языке, который зависит от конкретной СУБД. Их обычно используют при выполнении часто встречающихся задач. Триггеры также содержат исполняемый код, но их, в отличие от процедур, нельзя вызвать из клиентского приложения или хранимой процедуры. Триггер всегда связан с конкретной таблицей и выполняется тогда, когда при редактировании этой таблицы наступает событие, с которым он связан.
Выбор и модификация данных, изменение метаданных осуществляются с помощью запросов (query). Большинство современных СУБД и некоторые средства разработки приложений содержат средства для генерации таких запросов. Простой запрос позволяет только вывести на экран определенный набор полей, сложный – выделить в таблице ряд записей по значениям полей. Один из способов запросов называется «queries by example» (QBE)— запрос по образцу, т.е. средство для визуального связывания таблиц и выбора полей, которые следует отобразить в результате запроса. В большинстве СУБД визуальное построение запроса с помощью QBE приводит к генерации текста запроса с помощью специального языка запросов SQL (Structured Query Language). Можно также написать запрос непосредственно на языке SQL. Это непроцедурный язык, используемый для формулировки запросов к базам данных. Непроцедурность означает, что на нем можно указать, что нужно сделать с базой данных, но нельзя описать алгоритм этого процесса. Все алгоритмы обработки SQL-запросов генерируются самой СУБД. Статистическую обработку данных можно выполнять при помощи специально созданных приложений, либо при помощи запроса создать новую таблицу, сохранить её в файле, а затем выполнить обработку вне данной СУБД, например, в среде программного пакета MathCAD.
Транзакция (Transaction)— это группа операций над данными, которые либо выполняются все вместе, либо все вместе отменяются. Завершение транзакции означает, что все операции, входящие в состав транзакции, успешно завершены, и результат их работы сохранен в базе данных. Откат транзакции означает, что все уже выполненные операции, входящие в состав транзакции, отменяются и все объекты базы данных, затронутые этими операциями, возвращены в исходное состояние. Транзакция может состоять из нескольких вложенных транзакций.
Для поддержки распределенных транзакций (то есть транзакций над базами данных, управляемых разными СУБД), существуют специальные средства, называемые мониторами транзакций.
У ч е б н о е и з д а н и е
Третьяков Виктор Юрьевич
БАЗЫ ЭКОЛОГИЧЕСКИХ ДАННЫХ
Методическое пособие
Печатается без издательского редактирования
Обложка В.Ю. Третьякова
Оригинал-макет В.Ю. Третьякова
Лицензия ИД № 05679 от 24.08.01
Подписано в печать 4.03.2005. Формат 60х841/16
Бумага офсетная. Печать офсетная. Усл. печ. л. 1.
Тираж 100 экз. Заказ
Издательство СПбГУ. 199034, С.-Петербург, Университетская наб., 7/9.
Тел. (812) 328-96-17; факс (812) 328-44-22
E-mail: editor@unipress.ru
www.unipress.ru
По вопросам реализации обращаться по адресу:
С.-Петербург, 6-я линия В.О., 11/21, к.21
Телефоны: 328-77-63, 325-31-76
E-mail: post@unipress.ru
Типография Издательства СПбГУ.
199061, С.-Петербург, Средний пр., 41.
2. тема энергосистема состоит из электрических станций электрических сетей и потребителей электроэнергии со.1
3. 1Основные направления деятельности Правительства России
4. ВВЕДЕНИЕ Оборотные активы составляют существенную долю всех активов предприятия
5. ЧиМ Естествознание в нач школе призвано познакомить детей с конкретными явлениями окр мира объяснить
6. Анализ произведений А Камю
7. товарищей по работ
8. Тема- Нерозгалужене коло змінного струму з активним опором і індуктивністю
9. ТЕМА БЕЗНАЛИЧНЫХ РАСЧЕТОВ [3
10. 50 квтч-кг диспергированного металла
11. ТЕМА 1 Вступ Предмет і методологія науки Історія держави та права зарубіжних країнrdquo; Мета заняття- осві
12. Правотворческая деятельность государства
13. Экологическое право для специальности 030501
14. Отчет по практике- Деятельность индивидуального предприятия, оказывающего различного вида юридические услуги
15. Такими сигналами могут быть физические воздействия температура ионизирующее и другое электромагнитное из
16. Тема- Показники наукової та інноваційної діяльності 1 Питання які треба опрацювати- Показники науко
17. ПБОЮЛ или ООО Что выгоднее
18. Право социального обеспечения инвалидов в России
19. ПОГОДЖЕНО ЗАТВЕ
20. тема команд 1 Формат команд