Лекция Системы управления базами данных. Классификация субд
 Скачать 39.56 Kb.
|
Лекция 2. Системы управления базами данных. Классификация СУБДКлассификация СУБД. В общем случае под СУБД можно понимать любой программный продукт, поддерживающий процессы создания, ведения и использовании БД. Классифицировать СУБД можно: по виду программ, по характеру использования, по способу доступа к БД, по модели данных и т.д. Классификация по виду программ. К СУБД относятся следующие основные виды программ: полнофункциональные СУБД; серверы БД; клиенты БД. Полнофункциональные СУБД (ПФСУБД) являются наиболее многочисленными и мощными по своим возможностям. ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. д. Многие ПФСУБД включают средства программирования. Некоторые системы имеют средства проектирования схем БД или CASE-подсистемы. К ПФСУБД относятся: Clarion Database Developer, Data Ease, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro, Paradox R:BASE... Серверы БД предназначены для организации центров обработки данных в сетях ЭВM. Серверы БД реализуют функции управления БД, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL. Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress). Клиенты БД. В роли клиентских программ для серверов БД могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т.д. Элементы пары «клиент-сервер» могут принадлежать одному или разным производителям ПО. Если клиентская и серверная части выполнены одной фирмой, распределение функций между ними выполнено рационально. Классификация по характеру использования. По характеру использования СУБД делят на персональные и многопользовательские. Персональные СУБД обеспечивают возможность создания персональных БД и приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД относятся Visual FoxPro, Paradox, dBase, Access и др. Многопользовательские СУБД включают в себя сервер БД и клиентскую часть, могут работать в однородной и в неоднородной вычислительной среде (с разными типами ЭВМ и ОС). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix. Классификация по способу доступа к БД СУБД бывают: файл-серверные, клиент-серверные, встраиваемые. В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере. Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: высокая загрузка локальной сети; затруднённость или невозможность централизованного управления и обеспечения важных характеристик (высокая надёжность, доступность и безопасность). Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД. На данный момент файл-серверная технология считается устаревшей. Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro. Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно в монопольном режиме. Клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД: повышенные требования к серверу. Достоинства: более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения важных характеристик (высокая надёжность, доступность и безопасность). Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР. Встраиваемая СУБД – СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы. Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР. Классификация по модели данных. По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы. Некоторые СУБД могут одновременно поддерживать несколько моделей данных. Функции СУБДС точки зрения пользователя, СУБД реализует функции хранения, модификации (добавления, редактирования и удаления) и обработки информации, а также разработки и получения различных выходных документов. Перечисленные выше функции СУБД, в свою очередь, используют следующие основные функции более низкого уровня: управление данными во внешней памяти; управление буферами оперативной памяти; управление транзакциями; журнализация и восстановление БД после сбоев; поддержка языков БД. Управление данными во внешней памяти заключается в обеспечении необходимых структур внешней памяти для хранения данных, входящих в БД, и для служебных целей (например, для ускорения доступа к данным). Возможность сохранять, извлекать и обновлять данные в базе – фундаментальная функция СУБД. Способ реализации этой функции должен быть скрыт от конечного пользователя (использует ли СУБД файловую систему, как организованы файлы и т.д.) Контроль доступа к данным – это возможность обеспечения только санкционированного доступа к БД, используя защиту паролем, поддержку уровней доступа к БД и к отдельным ее элементам и т.д. Каждый пользователь должен иметь возможность работы только с теми данными БД, которые доступны для него в соответствии с его пользовательскими правами. Т.о. обеспечивается безопасность в СУБД. Управление параллельностью заключается в том, что СУБД имеют механизм, который гарантирует корректное обновление данных многими пользователями при одновременном доступе. Коллизии при совместной работе могут привести к нарушению логической целостности данных, поэтому СУБД должна предусматривать меры, не допускающие обновление дынных пользователем, пока эти данные используются кем-то еще. В описанных случаях используются, так называемые, блокировки. Существуют различные типы блокировок – табличные, страничные, строчные и т.д., которые различаются количеством заблокированных записей. Поддержка целостности данных осуществляется для того, чтобы данные и их изменения соответствовали заданным правилам. Целостность БД – это свойство БД, которое означает, что в ней содержится непротиворечивая, полная и адекватно отражающая предметную область информация. Подержание целостности БД включает в себя проверку целостности и ее восстановление в случае обнаружения противоречий в БД. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять данные, хранимые в базе. Примеры условий: ограничение диапазонов вводимых данных, отсутствие повторяющихся записей в таблицах БД и т.д. Управление буферами оперативной памяти заключается в поддержании СУБД собственного набора буферов оперативной памяти с собственными правилами замены буферов. Это связано с тем, что СУБД обычно работают с БД значительного размера; чаще всего размер БД существенно больше доступного объема оперативной памяти. Если при обращении к элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. Общесистемной буферизации, производимой ОС, недостаточно для целей СУБД, которая располагает гораздо большей информацией о необходимости буферизации той или иной части БД. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в БД после обработки. Управление транзакциями. Механизм транзакций используется в СУБД для поддержания логической целостности данных в базе. Транзакция – это некоторая неделимая последовательность операций над данными БД, которую СУБД рассматривает как единое целое и отслеживает от начала до завершения. Если транзакция успешно выполняется, то СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти. Если все изменения в рамках транзакции отменяются по какой-либо причине (сбои и отказы оборудования, ошибки в ПО…), то ни одно из них не отражается на состоянии БД, т.е. транзакция отменяется. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (это несколько идеализированное представление, т.к. в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег). Транзакции присущи три основных свойства: атомарность (выполняются все входящие в транзакцию операции или ни одна); сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций); долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции). Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Здесь необходим, по крайней мере, двухшаговый процесс. Сначала снимают деньги с одного счета, затем добавляют их к другому счету. Если хотя бы одно из действий не выполнится успешно, результат операции окажется неверным и будет нарушен баланс между счетами. Контроль транзакций важен в однопользовательских и в многопользовательских СУБД, где транзакции могут быть запущены параллельно. С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Сериализация параллельно выполняющихся транзакций – это такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций – это план, который приводит к сериализации транзакций. Если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно. При параллельном выполнении смеси транзакций возможно возникновение конфликтов (блокировок), разрешение которых является функцией СУБД. При обнаружении таких случаев обычно производится «откат» путем отмены изменений, произведенных одной или несколькими транзакциями. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей. Функция журнализации заключается в обеспечении СУБД надежности хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. К аппаратным сбоям относятся: внезапная остановка работы ПК (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (например, по причине ошибки в программе) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. В любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. То есть поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал – это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда – минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. СУБД придерживаются стратегии «упреждающей» записи в журнал протокола WAL (Write Ahead Logging – «пиши сначала в журнал»). Она заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия – это полная копия БД к моменту начала заполнения журнала. Для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным. Поддержка языков БД. Для работы с БД используются специальные языки, называемые языками БД. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Выделялись два языка – язык определения схемы БД (SDL – Schema Definition Language) и язык манипулирования данными (DML – Data Manipulation Language). SDL служил для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными (операторы ввода, удаления, модификации и выборки данных). В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с БД. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД – именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Язык SQL содержит специальные средства определения ограничений целостности БД. Ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код. На языковом уровне производится поддержание представлений. Специальные операторы языка SQL позволяют определять представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В их число входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. |