Юрий Сергеевич Избачков, Владимир Николаевич Петров Информационные системы: учебник
| Вид материала | Учебник |
- Горелик Александр Владимирович, д т. н., проф. Панков Юрий Николаевич, к т. н учебно-методический, 549.99kb.
- Программа дисциплины "Математические модели и методы теории решений" для направления, 146.63kb.
- Владимир Николаевич Лавриненко Философия Философия: учебник, 6688.53kb.
- Артеменко Юрий Николаевич исследование и разработка информационно-измерительной системы, 450.64kb.
- «Охотник и рыболов Поволжья и Урала» №9 (202), сентябрь 2009, 85.58kb.
- Рыкунов Юрий Николаевич, канд пед наук, доцент, зав кафедрой гимнастики факультета, 1058.29kb.
- Уткин В. Б. У 84 Информационные системы в экономике: Учебник для студ высш учеб, заведений, 3846.67kb.
- Владимир Николаевич Горбатенко, заместитель директора по воспитательной части программа, 49.57kb.
- Автор Карпухин Владимир Борисович учебно-методический комплекс, 473.72kb.
- Направление 230400 «Информационные системы и технологии», 20.25kb.
Глава 4
Реляционные базы данных
По мере развития вычислительной техники изменялись основные направления ее использования. Первоначально средства вычислительной техники предназначались для разного рода математических вычислений, которые невозможно было выполнить «вручную» за разумное время. Развитие этого направления привело к появлению разделов математики, связанных с численными методами вычислений, и алгоритмических языков, удобных для реализации алгоритмов численных методов и ориентированных на выполнение математических расчетов (одним из наиболее популярных языков программирования такого типа является Fortran, до сих пор широко применяющийся для научных расчетов).
Затем, по мере расширения возможностей и снижения стоимости вычислительных средств, получило развитие второе направление, связанное с использованием средств вычислительной техники в автоматизированных информационных системах. Здесь вычислительные возможности компьютеров отходят на второй план – основные функции вычислительных средств в информационных системах направлены на надежное хранение информации, выполнение специфических для данного приложения преобразований информации и/или вычислений, предоставление пользователям удобного и легко осваиваемого интерфейса.
Примечание.
Несмотря на то, что сложность вычислений, выполняемых в информационных системах, несоизмеримо ниже, чем при проведении научных расчетов, требования к вычислительной мощности компьютеров в таких системах выше. Это связано с тем, что объемы обрабатываемой информации, как правило, достаточно велики, а сама информация имеет сложную структуру. Этим же объясняется существенное возрастание требований к объему оперативной памяти и устройств постоянного хранения информации.
Со временем именно второе направление, связанное с хранением и обработкой данных, стало доминирующим, особенно после появления персональных компьютеров. Использование персональных компьютеров для выполнения сложных научных расчетов сейчас является скорее исключением. Интересно также отметить, что современные персональные компьютеры, оборудованные процессорами с громадными тактовыми частотами (на сегодняшний день рядовой дешевый процессор работает на частоте 1400–1500 МГц) при решении сложных научных задач могут даже уступать по вычислительным возможностям «большим» компьютерам 15-20-летней давности.
Общие сведения о базах данных
Развитие компьютерных технологий, связанных с хранением и обработкой данных, привело к появлению в конце 60-х – начале 70-х годов специализированного программного обеспечения, получившего название систем управления базами данных, или СУБД (DataBase Management Systems, DBMS). СУБД позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Именно системы управления базами данных являются основой практически любой информационной системы.
СУБД можно определить как некую систему управления данными, обладающую следующими свойствами:
• поддержание логически согласованного набора файлов;
• предоставление языка манипулирования данными;
• восстановление информации после разного рода сбоев;
• обеспечение параллельной работы нескольких пользователей.
Основные функции систем управления базами данных
К основным функциям, выполняемым системами управления базами данных, обычно относят:
• непосредственное управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• протоколирование;
• поддержка языков баз данных.
Рассмотрим каждую из указанных функций более подробно.
Непосредственное управление данными во внешней памяти
Функция непосредственного управления данными во внешней памяти включает предоставление необходимых структур внешней памяти (постоянных запоминающих устройств, как правило, магнитных дисков) как для хранения данных, непосредственно входящих в базу данных, так и для служебных целей, например, для ускорения доступа к данным в некоторых случаях (обычно для этого используются индексы). Причем пользователям базы данных в общем случае не нужно знать, применяет ли СУБД файловую систему, а если применяет, как организованы файлы. Обычно СУБД поддерживает собственную систему именования объектов базы данных. В зависимости от способа реализации СУБД может либо использовать возможности существующих файловых систем, либо работать с устройствами внешней памяти на низком уровне.
Управление буферами оперативной памяти
Объем информации, хранящейся в базе данных, с которой работает СУБД, обычно достаточно велик и практически всегда превышает доступный объем оперативной памяти. При этом время доступа к данным, хранящимся в оперативной памяти, существенно меньше, чем к данным, хранящимся на устройствах внешней памяти. Очевидно, что если при обращении к любому элементу данных требуется обмен с внешней памятью, то вся система будет работать со скоростью функционирования устройства внешней памяти.
Повышения скорости обмена данными можно достичь, используя буферизацию данных в оперативной памяти. При этом даже если операционная система выполняет общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, у которой гораздо больше информации, позволяющей судить о полезности буферизации той или иной части базы данных. Поэтому в СУБД обычно поддерживается собственный набор буферов оперативной памяти с собственным механизмом замены буферов.
Примечание.
Следует отметить, что существует направление развития СУБД, ориентированное на постоянное присутствие в оперативной памяти всей информации из базы данных. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что буферизация станет лишней.
Управление транзакциями
Транзакцией называется последовательность операций над базой данных, рассматриваемых СУБД как единое целое. Если все операции успешно выполнены, то транзакция также считается успешно выполненной, и СУБД фиксирует (commit) все изменения данных, произведенные этой транзакцией (то есть заносит изменения во внешнюю память). Если же хотя бы одна операция транзакции заканчивается неудачей, то транзакция считается невыполненной, и производится ее откат(rollback) с отменой всех изменений данных, произведенных в ходе выполнения транзакции, и возвращением базы данных к состоянию до начала выполнения транзакции.
Управление транзакциями необходимо для поддержания логической целостности базы данных.
Поддержка механизма транзакций является обязательным условием работы даже однопользовательских, а тем более многопользовательских СУБД. Поскольку каждая транзакция начинается при целостном состоянии базы данных и оставляет это состояние целостным после своего завершения, понятие транзакции очень удобно использовать как единицу активности пользователя по отношению к базе данных. При должном управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может, в принципе, ощущать себя единственным пользователем СУБД.
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации и плана сериализации смеси транзакций. Под сериализаций понимается параллельное выполнение смеси транзакций, результат которого эквивалентен результату их последовательного выполнения. План сериализации смеси транзакций – это такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться реальной сериализации смеси транзакций, то для каждого пользователя, по инициативе которого начата транзакция, выполнение других транзакций будет незаметным (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизированных захватах объектов базы данных. При использовании любого алгоритма сериализации возможны конфликты между несколькими транзакциями по доступу к объектам базы данных. В этом случае для поддержания сериализации необходимо выполнить откат одной или нескольких транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе обработки транзакций других пользователей.
Протоколирование
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.
Аппаратные сбои обычно подразделяются на два вида:
• мягкие сбои связаны с внезапной остановкой компьютера и обычно являются следствием внезапного выключения питания или «зависания» операционной системы;
• жесткие сбои характеризуются потерей информации на носителях внешней памяти.
Программные сбои обычно возникают вследствие ошибок в программах. Причем эти ошибки могут быть как в самой СУБД, что может привести к аварийному завершению ее работы, так и в пользовательской программе. Первый случай можно рассматривать как разновидность мягкого аппаратного сбоя. Во втором случае незавершенной остается только одна транзакция.
В любом случае, для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для надежного хранения данных требуется их избыточность. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных.
Журнал представляет собой недоступную пользователям и поддерживаемую с особой тщательностью часть базы данных, в которую поступают записи обо всех изменениях основной части базы данных. Иногда используются две копии журнала, располагаемые на разных физических дисках.
В разных СУБД изменения базы данных протоколируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда – минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба подхода.
Во всех случаях придерживаются стратегии упреждающей записи в журнал (Write Ahead Log, WAL). Несколько утрируя, можно сказать, что эта стратегия подразумевает внесение в журнал записи об изменении любого объекта базы данных до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД поддерживается протокол WAL, то с помощью журнала можно решить все проблемы восстановления базы данных после любого сбоя.
Самая простая ситуация восстановления – откат отдельной транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а откат отдельной транзакции выполняют по общесистемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части базы данных могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине очистки буферов оперативной памяти при мягком сбое). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью восстановления после мягкого сбоя является приведение внешней памяти основной части базы данных в такое состояние, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не сохранились во внешней памяти.
Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия – это полная копия базы данных, полученная к началу заполнения журнала (хотя имеются и другие варианты трактовки этого термина). Естественно, для нормального восстановления базы данных после жесткого сбоя необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что на основе данных архивной копии по журналу повторно выполняются все транзакции, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков баз данных
Для работы с информацией, хранящейся в базе данных, используются специальные языки, носящие общее названиеязыков баз данных. Чаще всего выделяется два языка:
• язык определения схем данных (Schema Definition Language, SDL) служит главным образом для определения логической структуры базы данных;
• язык манипулирования данными (Data Manipulation Language, DML) содержит набор операторов манипулирования данными, то есть операторов, позволяющих заносить данные в базу, а также удалять, модифицировать или выбирать существующие данные.
Несколько разных специализированных языков баз данных поддерживалось лишь в ранних СУБД. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language – язык структурированных запросов). Таким образом, указанные выше языки баз данных на сегодняшний день фактически являются подмножествами единого стандартного языка SQL.
Язык SQL позволяет определять схему реляционной базы данных и манипулировать данными. При этом именование объектов базы данных (для реляционной базы данных – именование таблиц и их полей) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов.
Язык SQL содержит специальные средства определения ограничений целостности базы данных. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и контроль целостности базы данных производится на языковом уровне – при компиляции операторов модификации базы данных компилятор SQL на основании имеющихся в базе данных ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления базы данных, фактически являющиеся хранимыми в базе данных запросами (результатом любого запроса к реляционной базе данных является таблица) с именованными столбцами, называемыми полями. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в базе данных, но с помощью представлений можно ограничить или, наоборот, расширить видимость данных для конкретного пользователя. Поддержка представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам базы данных тоже производится на основе специального набора SQL-операторов. Идея состоит в том, что для выполнения разных SQL-операторов пользователь должен обладать разными полномочиями. Пользователь, создавший таблицу базы данных, обладает полным набором полномочий для работы с данной таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
Примечание.
Здесь дается лишь общее представление о языке SQL. Более подробно данный язык и его функции рассматриваются далее.
Эволюция систем управления базами данных
На эволюцию СУБД существенное влияние оказывает бурное развитие микроэлектронных технологий и связанное с этим развитие персональных компьютеров. Темпы развития персональных компьютеров за последние 15–20 лет существенно превышают темпы развития «больших» ЭВМ. Область применения персональных компьютеров за последние несколько лет существенно расширилась. Можно выделить основные причины этой тенденции:
• цена персональных компьютеров значительно ниже, чем больших ЭВМ;
• по функциональным возможностям персональные компьютеры превосходят большие ЭВМ;
• существенно сократился разрыв между производительностью персональных компьютеров и больших ЭВМ, кроме того, для многих задач обработки данных производительность компьютера не является решающим фактором;
• архитектура систем на основе персональных компьютеров обладает большей гибкостью и мобильностью, а сфера их использования значительно шире области применения больших ЭВМ.
Общая тенденция движения от отдельных больших вычислительных машин (mainframes) к открытым распределенным системам оказала огромное влияние на развитие архитектур СУБД и поставила перед их разработчиками ряд сложных проблем. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД с собственными моделями, форматами представления данных и языками доступа к данным, к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в сеть компьютеров различных моделей и производителей.
Постепенный переход от вычислительных систем на основе больших ЭВМ и централизованного управления данными к распределенным системам на основе персональных компьютеров, а также внедрение персональных компьютеров практически во все сферы деятельности, привели и к изменению подходов к организации систем управления базами данных. В истории развития и совершенствования систем управления базами данных можно условно выделить три основных этапа. Кратко рассмотрим каждый из них.
СУБД первого поколения
Первый этап был связан с созданием первого поколения СУБД, опиравшихся на иерархическую и сетевую модели данных (на основе спецификаций CODASYL). В этот период времени на рынке вычислительной техники доминировали большие вычислительные машины, такие как IBM 360/370, которые в совокупности с СУБД первого поколения составили аппаратно-программную платформу больших информационных систем. СУБД первого поколения были в подавляющем большинстве закрытыми системами: отсутствовал стандарт внешних интерфейсов, не обеспечивалась переносимость прикладных программ.
Ранние СУБД, с сегодняшней точки зрения, имели массу недостатков, из которых наиболее существенными были:
• сложность использования;
• необходимость знать физическую организацию базы данных;
• сильная зависимость прикладных систем от физической организации базы данных;
• перегрузка логики прикладных систем деталями организации доступа к базе данных;
• отсутствие средств автоматизации проектирования баз данных;
• очень высокая стоимость.
Среди достоинств СУБД первого поколения можно отметить:
• наличие развитых средств управления данными во внешней памяти на низком уровне;
• возможность построения эффективных прикладных систем вручную;
• возможность экономии памяти за счет совместного использования объектов (в сетевых системах).
Несмотря на все свои недостатки, СУБД первого поколения оказались весьма долговечными: разработанное на их основе программное обеспечение используется по сей день, и большие ЭВМ по-прежнему хранят огромные массивы актуальной информации. Главной причиной этого является, вероятно, экономический фактор – в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства, в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат.
Реляционные СУБД
Началом второго этапа в эволюции СУБД можно считать публикации в начале 70-х годов ряда статей Э. Кодда (Coad), в которых выдвигались, по сути, революционные идеи, существенно изменившие устоявшиеся представления о базах данных.
Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двухмерных таблиц особого вида, известного в математике как отношение (по-английски – relationship, отсюда и название – реляционные базы данных).
Одна из главных идей Кодда заключалась в том, что связь между данными должна устанавливаться в соответствии с их внутренними логическими взаимоотношениями.
Примечание.
В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае, когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, то для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать обращения к файлам. Естественно, это существенно упрощает работу с базами данных.
Второй важный принцип, предложенный Коддом, заключается в том, что в реляционных системах одной командой могут обрабатываться целые файлы данных, в то время как в ранних СУБД одной командой обрабатывалась только одна запись. Реализация этого принципа существенно повысила эффективность программирования баз данных.
Реализация реляционных принципов в СУБД сделала возможным разработку простых языков запросов, вполне доступных пользователям, не являющимся специалистами в области программирования. Таким образом, благодаря снижению требований к квалификации существенно расширился круг пользователей баз данных.
Примечание.
На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны QBE (Query by Example – запрос по образцу), Quel (Query Language – язык запросов) и SQL (Structured Query Language – структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение имеет SQL, который в 1986 г. был принят институтом ANSI (American National Standards Institute – Американский национальный институт стандартов) в качестве стандарта языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL-92.
Сейчас реляционные базы данных получили очень широкое распространение и фактически их можно рассматривать как стандарт СУБД для современных информационных систем.
Объектно-ориентированные СУБД
Несмотря на большую популярность реляционных СУБД, развитие технологии управления данными на них не остановилось. Следующим этапом этого развития стало появление объектно-ориентированных баз данных, для которых характерны объектно-ориентированный подход, распределенность данных, наличие активного сервера баз данных, языки программирования четвертого поколения, фрагментация и параллельная обработки запросов, технологии тиражирования данных, многопоточная архитектура и другие революционные достижения в области обработки данных.
Объектно-ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:
• возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;
• простота эволюции системы за счет таких элементов объектного подхода как наследование и полиморфизм;
• возможность объектного моделирования системы, позволяющего проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки.
Объектная модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов.
При занесении сложного объекта в реляционную базу обязательна процедура декомпозиции его данных для того, чтобы разместить их в таблицах. При чтении объекта из реляционной базы он собирается из отдельных элементов и только затем может использоваться. В объектных же СУБД данные объекта, а также методы изменения этих данных помещаются в хранилище как единое целое.
Использование объектной модели представления данных (и, соответственно, объектно-ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.
Примечание.
Несмотря на все достоинства объектно-ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае применение реляционной модели может быть более эффективным. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конкретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными объектно-реляционными СУБД.