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

Назначение и основные функции системы управления базами данных СУБД, особенности и признаки их классификации. Архитектура баз данных (БД). Разработка распределенных БД. Язык структурированных запросов (SQL). Правила Кодда: требования к реляционным БД.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 21.07.2012
Размер файла 376,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

57

Шахунское СГП

Курсовая работа

По дисциплине: Базы данных

Тема: Системы управления базами данных

Студента Козлова Алексея Александровича

Содержание

  • Введение
  • 1. Основная часть
  • 1.1 Назначение и основные функции СУБД
  • 1.1.1 Назначение СУБД
  • 1.1.2 Функции СУБД
  • 1.1.3 Архитектура СУБД
  • 1.2 Классификация СУБД
  • 1.3 Распределённые СУБД
  • Заключение
  • Глоссарий
  • Список использованных источников
  • Приложения
  • Язык запросов SQL
  • Правила Кодда

Введение

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

Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation - DEC), разных моделях HP (фирмы Hewlett Packard). Особенности этого этапа развития выражаются в следующем:

Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.

Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС).

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

Значительная роль отводится администрированию данных.

Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных.

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

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

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

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

Особенности этого этапа следующие:

Стандартизация высокоуровневых языков манипулирования данными (разработка и внедрение стандарта SQL92 во все СУБД).

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

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

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

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

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

Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286. В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.

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

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

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

1. Основная часть

1.1 Назначение и основные функции СУБД

1.1.1 Назначение СУБД

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

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

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

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

компактное хранение данных (без дублирования);

оптимизацию доступа к данным;

логическую целостность (согласованность) данных;

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

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

1.1.2 Функции СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала. Конечно, для нормального восстановления БД после жесткого

сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования.

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

5. Поддержка языков БД

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

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

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

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

Внешний уровень

Внешний уровень - это индивидуальный уровень пользователя. У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования.

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

Концептуальный уровень

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

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

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

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

Внутренний уровень

Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи.

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

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

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

Локальная архитектура.

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

Файл - серверная архитектура.

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

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

Клиент - серверная архитектура.

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

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

Распределенная архитектура.

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

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

Интернет-архитектура.

Доступ к базе данных и СУБД (распространенных на одном компьютере или в сети) осуществляется из браузера по стандартному протоколу. Это предъявляет

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

1.2 Классификация СУБД

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

По модели данных классифицировать СУБД можно следующим образом:

Иерархические

Сетевые

Реляционные

Объектно-ориентированные

Объектно-реляционные

Рассмотрим эти модели более подробно.

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

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

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

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

Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Definition Language - язык определения данных) и DML (Data Manipulation Language - язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие программист по-прежнему должен знать структуру базы данных.

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Большим недостатком объектно-ориентированных баз данных является их тесная связь с применяемым языком программирования. К данным, хранящимся в реляционной СУБД, могут обращаться любые приложения, тогда как, к примеру, Java-объект, помещенный в ООСУБД, будет представлять интерес лишь для приложений, написанных на Java.

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

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

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

Следующим важнейшим классифицирующим признаком СУБД является степень распределённости. Здесь можно выделить локальные и распределённые СУБД.

В случае локальных СУБД и сама программа и база данных находятся на одном компьютере.

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

1.3 Распределённые СУБД

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

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

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

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

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

Набор логически связанных разделяемых данных.

Сохраняемые данные разбиты на некоторое количество фрагментов.

Между фрагментами может быть организована репликация данных.

Фрагменты и их реплики распределены по различным сайтам.

Сайты связаны между собой сетевыми соединениями.

Работа с данными на каждом сайте управляется СУБД.

СУБД на каждом сайте способна поддерживать автономную работу локальных приложений.

СУБД каждого сайта поддерживает хотя бы одно глобальное приложение.

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

управление база реляционная распределенная

Рис.1 Топология системы управления распределенной базой данных

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

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

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

Расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети.

Средства обработки распределенных запросов, включая механизмы оптимизации запросов и организации удаленного доступа.

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

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

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

Правило 1

Основной принцип. Локальная автономность

С точки зрения конечного пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная система.

Сайты в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:

локальные данные принадлежат локальным владельцам и сопровождаются локально;

все локальные процессы остаются чисто локальными;

все процессы на заданном сайте контролируются только этим сайтом.

Правило 2

Отсутствие опоры на центральный сайт

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

Правило 3

Непрерывное функционирование

В идеале, в системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения таких операций, как:

добавление или удаление сайта из системы;

динамическое создание или удаление фрагментов из одного или нескольких сайтов.

Правило 4

Независимость от расположения

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

Правило 5

Независимость от фрагментации

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

Правило 6

Независимость от репликации

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

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

Правило 7

Обработка распределенных запросов

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

Правило 8

Обработка распределенных транзакций

Система должна поддерживать выполнение транзакций, как единицы восстановления.

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

Правило 9

Независимость от типа оборудования

СУРБД должна быть способна функционировать на оборудовании с различными вычислительными платформами.

Правило 10

Независимость от операционной системы

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

Правило 11

Независимость от сетевой архитектуры

СУРБД должна быть способна функционировать в сетях с различной архитектурой и типами носителя.

Правило 12

Независимость от типа СУБД

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

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

Преимущества

Отражение структуры организации

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

Разделяемостъ и локальная автономность

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

используют. В результате заинтересованные пользователи получают локальный контроль над требуемыми им данными и могут устанавливать или

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

Повышение доступности данных

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

Повышение надежности

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

Повышение производительности

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

Экономические выгоды

В шестидесятые годы мощность вычислительной установки возрастала

пропорционально квадрату стоимости ее оборудования, поэтому система, стоимость

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

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

Модульность системы

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

Недостатки

Повышение сложности

Распределенные СУБД, способные скрыть от конечных пользователей распределенную природу используемых ими данных и обеспечить необходимый

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

Увеличение стоимости

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

Проблемы защиты

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

Усложнение контроля за целостностью данных

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

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

Отсутствие стандартов

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

Недостаток опыта

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


Подобные документы

  • Система управления базами данных как составная часть автоматизированного банка данных. Структура и функции системы управления базами данных. Классификация СУБД по способу доступа к базе данных. Язык SQL в системах управления базами данных, СУБД Microsoft.

    реферат [46,4 K], добавлен 01.11.2009

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

    реферат [118,3 K], добавлен 29.11.2010

  • Особенности управления информацией в экономике. Понятие и функции системы управления базами данных, использование стандартного реляционного языка запросов. Средства организации баз данных и работа с ними. Системы управления базами данных в экономике.

    контрольная работа [19,9 K], добавлен 16.11.2010

  • Классификации баз данных по характеру сберегаемой информации, способу хранения данных и структуре их организации. Современные системы управления базами данных и программы для их создания: Microsoft Office Access, Cronos Plus, Base Editor, My SQL.

    презентация [244,3 K], добавлен 03.06.2014

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

    курсовая работа [434,7 K], добавлен 20.07.2012

  • Программные продукты компании Microsoft: Access, Visual FoxPro7.0, dBASE. Возможности интеграции, совместной работы и использования данных. Системы управления базами данных (СУБД), их основные функции и компоненты. Работа с данными в режиме таблицы.

    курсовая работа [805,5 K], добавлен 15.12.2010

  • Теоретические сведения и основные понятия баз данных. Системы управления базами данных: состав, структура, безопасность, режимы работы, объекты. Работа с базами данных в OpenOffice.Org BASE: создание таблиц, связей, запросов с помощью мастера запросов.

    курсовая работа [3,2 M], добавлен 28.04.2011

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.