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

Вид материалаЛекция

Содержание


База данных
Управление буферами оперативной памяти.
Управление транзакциями.
Поддержка языков БД.
Подобный материал:

Лекция 1. Введение


План.
  1. Понятие БД
  2. Понятие СУБД
  3. Типы БД


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

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

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

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

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

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

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

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

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

Наибольшее же распространение в настоящее время получили реляционные базы данных. Часто слово «реляционная» опускается и говорится просто «база данных», подразумевая именно этот тип. Так же будем поступать и мы, делая в нашем курсе упор на изучение реляционных баз данных.

Теория реляционных баз данных была разработана доктором Коддом из компании IBM в 1970 году. В реляционных базах данных все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Запросы к таким таблицам возвращают таблицы, которые сами могут становиться предметом дальнейших запросов. Каждая база данных может включать несколько таблиц. Кратко особенности реляционной базы данных можно сформулировать следующим образом:
  • Данные хранятся в таблицах, состоящих из столбцов ("атрибутов") и строк ("записей", "кортежей");
  • На пересечении каждого столбца и строчки стоит в точности одно значение;
  • У каждого столбца есть своё имя, которое служит его названием, и все значения в одном столбце имеют один тип.
  • Запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов.

В дальнейшем структура информации в реляционных БД будет рассмотрена более подробно.

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

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

Сейчас существует большое количество различных СУБД: MS SQL Server, Oracle, MySql, DB2 и пр., точно также как существует большое количество текстовых редакторов (MultiEdit, MS Word и др.) или операционных систем (MS Windows, Unix, OS/2 и др.). Производители СУБД в ходе непрерывной конкуренции постоянно развивают свои продукты, снабжая все более и более широкими возможностями. Можно выделить несколько основных функций, которыми обладает любая современная СУБД.

Основные функции СУБД:
  1. Управление данными во внешней памяти.

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

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

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

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

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

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

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

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

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

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

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

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