zabika.ru 1 2 ... 7 8

БАЗЫ И БАНКИ ДАННЫХ


Содержание

Реляционные базы данных

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


  1. Распределенная база данных – этот способ обработки требует использования нескольких серверов, на которых может храниться пересекающаяся или даже дублирующаяся информация. Для работы с такой базой данных используется система управления распределенными базами данных.

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

Система централизованных баз данных с сетевым доступом имеет различные архитектуры:

─ файл-сервер;

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

─ клиент-сервер.

При использовании этой архитектуры выделенный компьютер используется не только в качестве хранилища файлов, но и выполняет основной объем действий по обработке информации. Пользователь рабочей станции отправляет список операций обрабатываемых данных (запрос), которые необходимо выполнить центральному компьютеру, т. е. серверу. Сервер выполняет необходимые вычисления и выборку данных и отправляет готовый результат клиенту. Для описания запросов часто используют структурированный язык запросов SQL (Structured Query Language). Этот язык специально разработан для создания запросов.


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

К настоящему времени разработано множество различных моделей данных. На практике используются три основных.

1. Иерархическая модель данных.

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

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

Достоинства иерархической модели данных:

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

─ использование отношений предок-потомок;

─ быстродействие.

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


2. Сетевая модель данных.

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

3. Реляционная модель данных.

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

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

Теория реляционных баз данных, разработанная в 70-х гг. в США доктором Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Коддом теоретическая база стала основой для разработки теории проектирования баз данных. Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Кодд доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида известных в математике как отношения. От английского слова relation произошло название «реляционная модель данных». Термин «отношение реляционной модели данных» обозначает таблицу. Наименьшая единица данных, которой оперирует реляционная модель данных, - это отдельное атомарное для данной предметной области значение данных, которое не может быть разложено на более простые составляющие. Так в одной предметной области составляющие адреса могут рассматриваться как различные значения, а в другой как единое целое. Множество атомарных значений одного и того же типа образуют домен. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементам данных. В простейшем случае домен определяется как допустимое потенциальное множество значений одного типа. Например, совокупность дат рождений всех сотрудников составляет домен дат рождения, а имена – домен имен сотрудников. Домен дат рождений имеет тип данных, позволяющий хранить информацию о моментах времени, а домен имен сотрудников должен иметь символьный тип данных.


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

Каждый элемент данных в отношении может быть определен с указанием его адреса в формате А[i, j], где А – элемент данных, i – строка отношения, j – номер атрибута отношения. Количество атрибутов в отношении определяет его порядок. Множество значений А[i, j] при постоянном i и всех возможных j образуют кортеж или просто строку таблицы. Количество всех кортежей в отношении определяет его мощность или кардинальное число. Мощность отношения в отличие от порядка отношения может со временем меняться. Совокупность всех кортежей образует тело отношения или таблицу. Поскольку отношения являются математическими множествами, которые по определению не могут содержать совпадающих элементов, никакие два кортежа в отношении не могут быть дубликатами друг друга в любой момент времени.

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

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

2)минимальность - ни один не входящий в ключ атрибутов не может быть исключен из ключа без нарушения уникальности.

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

Реляционная база данных


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

Описание колонок, которое составляет разработчик, принято называть макетом таблицы.

Функции СУБД. Типовая организация СУБД

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

1) Непосредственное управление данными во внешней памяти.

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


2) Управление буферами, оперативной памяти.

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

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

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

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


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

4) Журнализация.

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


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

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


5) Поддержка языков баз данных.

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



следующая страница >>