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

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

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

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

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

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

-язык определения схем баз данных – служит главным образом для определения логической структуры баз данных;

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

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

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

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

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

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

Эволюция систем управления базами данных

   На эволюцию СУБД существенное влияние оказывает бурное развитие микроэлектронных технологий и связанное с этим развитие персональных компьютеров. Темпы развития персональных компьютеров за последние 15-20 лет существенно превышают темпы развития «больших» ЭВМ. Область применения персональных компьютеров за последние несколько лет существенно расширилась. Можно выделить следующие основные причины этой тенденции:

- цена персональных компьютеров значительно ниже, чем больших ЭВМ;

- по функциональным возможностям персональные компьютеры превосходят большие ЭВМ;

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

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

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

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

СУБД первого поколения

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

    Ранние СУБД, с сегодняшней точки зрения, имели массу недостатков, из которых наиболее существенными были следующие:

- сложность использования;

- необходимость знать физическую организацию базы данных;

- сильная зависимость прикладных систем от физической организации базы данных;

- перегрузка логики прикладных систем деталями организации доступа к базе данных;

- отсутствие средств автоматизации проектирования баз данных;

- очень высокая стоимость.

   Среди достоинств СУБД первого поколения можно отметить:

-наличие развитых средств управления данными во внешней памяти на низком уровне;

- возможность построения эффективных прикладных систем вручную;

- возможность экономии памяти за счет совместного использования объектов.

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

Реляционные СУБД

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

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

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

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

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

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

Объектно-ориентированные СУБД

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

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

- возможность разбить систему на совокупность независимых сущностей и провести их строгую независимую спецификацию;

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

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

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

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

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

Реляционная модель данных

   Реляционная модель данных была предложена Э. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в 1970 году в статье «A Relational Model of Data for Large Shared Data Banks». Реляционная модель позволила решить одну из важнейших задач в управлении базами данных – обеспечить независимость представления и описания данных от прикладных программ, следствием чего было бы существенное упрощение проектирования и программирования баз данных. Поэтому после опубликования работ Кодда начались активные исследования по созданию реляционной системы управления базами данных. В результате этих исследований во второй половине 1970-х годов был создан ряд коммерческих и некоммерческих реляционных СУБД.

   К основным достоинствам реляционного подхода к управлению базой данных следует отнести:

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

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

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

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

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