Распределенные и централизованные базы данных. Архитектура файл-сервер. Архитектура клиент-сервер.

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

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

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

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

 

 

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

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

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

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

 

 

Реляционная модель данных. История развития. Основные понятия (тип данных, домен, отношение, кортеж, атрибут, ключ).

Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерных таблиц. В простейшем случае реляционная модель описывает единственную двумерную таблицу, но как правило эта модель описывает структуру и взаимодействие нескольких двумерных таблиц. Развитие реляционных баз данных началось в 60х годах когда появились первые работы в которых обсуждалась возможность использования при проектировании баз данных привычных и естественных способов представления данных, так называемых табличных дата-логических моделей. Теория реляционных баз данных разработана в 60х годах в США Коддом. Теория имеет мощную математическую основу описывающую правила эффективной организации данных. Разработанная Коддом теоретическая база стала основой теории проектирования баз данных. Кодд предложил использовать для обработки данных классический аппарат теории множеств и доказал что любой набор данных можно представить в виде двумерных таблиц особого вида известных в математике как отношения. Термин отношения в реляционной модели данных обозначает таблицу. Наименьшая единица данных, с которой оперирует реляционная модель данных это отдельное для данной предметной области атомарное значение данных, которое не может быть разложено на более простые составляющие. Множество атомарных значений одного и того же типа образует домен. Домен определяется как допустимое потенциальное множество значений одного типа. В один домен могут входить значения из нескольких колонок объединенных помимо одинакового типа данных еще и логически. Каждый элемент данных в отношении может быть определен с указанием его адреса в формате aij, где a – элемент данных, i – строка отношения, j – номер атрибута отношения. Количество атрибутов в отношении определяет его порядок. Множество значений aij-x при постоянном i и всех возможных j образует кортеж отношения или просто строку таблицы. Количество всех кортежей в отношении определяет его мощность или кардинальное число. Совокупность всех кортежей образует тело отношения. Некоторые множества атрибутов образуют ключ для данного отношения если задание значений этих атрибутов определяет значение всех остальных атрибутов таблицы. Множество атрибутов отношения является возможным ключом этого отношения, когда выполняются два независимых условия.

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

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

 

 

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

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

Требования к проектированию реляционных баз данных можно свести к правилам:

1. Каждая таблица в базе данных имеет уникальное имя и состоит из однотипных строк.

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

3. Ни в какой момент времени в таблице не должно быть двух строк дублирующих друг друга.

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

5. При выполнении обработки данных можно свободно обращаться к любой строке или к колонке таблицы. Значение хранимое в таблице не накладывает никаких ограничений на порядок обращения к данным.

 

 

18 Функции системы управления базами данных (СУБД): управления данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями.

Считается, что система управления данными является СУБД при условии что она выполняет следующие функции:

1. Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти, как для хранения данных, так и для служебных целей.

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

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

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

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

 

 

19 Функции системы управления базами данных: журнализация, поддержка языков баз данных.

Считается, что система управления данными является СУБД при условии что она выполняет следующие функции:

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

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

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

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

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

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

5. Поддержка языков баз данных. Стандартным языком наиболее распространенных СУБД является SQL.