Понятие СУБД. Архитектура СУБД. Однопользовательские и многопользовательские СУБД

Содержание

1. Понятие системы управления базами данных (СУБД). Архитектура СУБД. Однопользовательские и многопользовательские СУБД. Стр.2

1.1 Понятие системы управления базами данных. Стр.2

1.2 Архитектура СУБД. Стр.6

1.3 Однопользовательские и многопользовательские СУБД. Стр.9 

2. Методы  защиты информации: организационно-административные и организационно-технические. Стр.10

2.1 Организационно-административные. Стр.11 

2. Организационно-технические. Стр.11

Заключение. Стр.13

Список литературы. Стр.14 
 
 

I. Понятие системы управления базами данных (СУБД). Архитектура СУБД. Однопользовательские и многопользовательские СУБД.

1.1 Понятие системы управления базами данных

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

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

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

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

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

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

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

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

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

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

  Во  всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия  заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала  раньше, чем измененный объект попадет  во внешнюю память основной части  БД. Известно, что если в СУБД корректно  соблюдается протокол 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 разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с  этой таблицей. В число этих полномочий входит полномочие на передачу всех или  части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются  в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.

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

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

Быстрое развитие потребностей применения БД выдвигает новые требования к  СУБД:

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

1.2 Архитектура СУБД

     Три уровня архитектуры.

     Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих  чертах они представляют собой следующее:

1. Внутренний уровень-это уровень, наиболее близкий к физическому хранению, т.е. связанный со способами сохранения информации на физических устройствах хранения.
2. Внешний уровень наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей.
3. Концептуальный уровень-это «промежуточный» уровень между двумя первыми.

     Внешний уровень (индивидуальные представления пользователей). Концептуальный уровень (обобщенное представление пользователей). Внутренний уровень (представление в памяти).

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

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

     У каждого пользователя есть свой язык общения. Для прикладного программиста это либо один из распространенных языков программирования, такой как C, COBOL или PL/1, либо специальный язык рассматриваемой системы. Такие оригинальные языки называют (неформально) языками четвертого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками трех первых «поколений», а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера. Для конечного пользователя это или специальный язык запросов, или язык специального назначения, возможно, основанный на формах и меню, созданный специально с учетом требований и поддерживаемый некоторым оперативным приложением.

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

     Язык  обработки данных состоит из таких  выполняемых операторов PL/1, которые  передают информацию в и из БД; опять  же, возможно, включая, новые специальные  операторы.

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

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

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

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

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

     Теперь  перейдем к более детальному исследованию трех уровней архитектуры.

     Внутренний  уровень. Третьим уровнем архитектуры является внутренний уровень. Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи. Термин «внутренняя запись» принадлежит терминологии ANSI/SPARC и означает конструкцию, называемую хранимой записью. Внутреннее представление так же, как внешнее и концептуальное, не связано с физическим уровнем, так как в нем не рассматриваются физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает бесконечное линейное адресное пространство; подробности того, как адресное пространство отображено на физическое устройство хранения, очень зависят от системы и умышленно не включены в общую архитектуру.

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

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

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

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

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

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

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

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

     Основной  недостаток этой архитектуры не очень  высокая надежность. Если сервер выходит из строя, вся работа останавливается.

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

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

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

     1.3 Однопользовательские и многопользовательские системы управления базами данных

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

     Для персональных компьютеров было разработано  много компактных СУБД, имеющих дружественные  интерфейсы и мощные и простые  в использовании средства разработки приложений. Наиболее известными СУБД для РС являются: Clarion, Paradox, FoxPro, dBase, Clipper, Rbase, dbVista. В начале эти СУБД разрабатывались  как однопользовательские и их архитектура  была ориентирована на максимально  эффективное использование возможностей РС. В дальнейшем появились сетевые  версии этих СУБД, но они являются просто развитием однопользовательских версий и вынуждены сохранять принципы и концепции заложенные при разработке однопользовательских версий. В то же время реализация мнопользовательских  СУБД, позволяющих эффективно работать с БД десяткам и тысячам пользователей  выдвигает ряд новых требований к архитектуре СУБД. Они должны минимизировать задержки и ожидания, обеспечить высокую надежность и  защиту данных при многопользовательской  работе, свести к минимуму блокировку данных, обеспечить мощные средства администрирования  данных и разработки приложений.