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

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

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

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

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

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

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

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

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

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

Парадигма - это пространство идей и законы движения в этом пространстве. В рамках парадигмы определены аксиомы, на которых выстраивается своя логика. Решения, вырабатываемые в рамках парадигмы, непротиворечивы и логичны.

Преимуществами объектных СУБД модно считать:

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

Большинство производителей ООБД предоставляют визуальные средства создания прикладных программ ОСУБД. Если раньше созданием прикладных программ для ОСУБД занимались специалисты в C++, Smaltalk, то теперь использовать ООБД стало намного проще

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

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

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

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

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

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

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

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

Хранилища данных отличаются от баз данных или систем оперативной обработки транзакций (OLTP-систем) своим назначением и устройством:

хранилище содержит данные, позволяющие проводить анализ деловых операций;

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

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

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

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

Классификация баз данных

По типу хранимой информации БД делятся на

· документальные,

· фактографические и

· лексикографические.

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

К лексикографическим базам данных относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т. п.).

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

По характеру организации хранения данных и обращения к ним различают

· локальные (персональные),

· общие (интегрированные, централизованные) и

· распределенные базы данных

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

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

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

По характеру организации данных БД могут быть разделены на

· неструктурированные,

· частично структурированные и

· структурированные.

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

· иерархические,

· сетевые,

· реляционные,

· смешанные и

· мультимодельные.

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

А)Типы моделей данных баз данных подразделяются на:

иерархическую, сетевую и реляционную.

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

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

Реляционная база данных — база данных, основанная на реляционной модели данных. Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

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

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

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

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

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

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

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

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

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

В) Общая модель данных корпоративного хранилища разрабатывается последовательно и состоит из:

концептуальной модели данных;

логической модели данных;

физической модели данных.

Концептуальная модель

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

Логическая модель

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

Физическая модель

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

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

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

Основными достоинствами иерархической модели данных являются:

1) эффективное использование памяти ЭВМ;

2) высокая скорость выполнения основных операций над данными;

3) удобство работы с иерархически упорядоченной информацией.

К недостаткам иерархической модели представления данных относятся:

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

2) трудность в понимании ее функционирования обычным пользователем.

Незначительное число СУБД построено на иерархической модели данных.

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

Достоинствами сетевой модели представления данных являются:

1) эффективность в использовании памяти компьютера;

2) высокая скорость выполнения основных операций над данными;

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

К недостаткам сетевой модели представления данных относятся:

1) высокая сложность и жесткость схемы базы данных, которая построена на ее основе;

2) трудность для понимания и выполнения обработки информации в базе данных непрофессиональным пользователем.

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

Реляционная модель представления данных была разработана сотрудником фирмы 1ВМЭ. Коддом. Его модель основывается на понятии «отношения» (relation). Простейшим примером отношения служит двумерная таблица.

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

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

1) отсутствие стандартных средств идентификации отдельных записей;

2) сложность описания иерархических и сетевых связей.

Большинство СУБД, применяемых как профессиональными, так и непрофессиональными пользователями, построены на основе реляционной модели данных (VisualFoxPro и Access фирмы Microsoft, Oracle фирмы Oracle и др.).

Я вопрос разделила на 4 части, как видите. И, по-моему, тут одно и то же. Очень странный вопрос, но постаралась найти все. По сути первая и последняя части одно и то же, я понятия не имею, как он вопросы составлял. Хз

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

А)Функции СУБД:

Более точно, к числу функций СУБД принято относить следующие:

2.1.1. Непосредственное управление данными во внешней памяти

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состав СУБД

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

· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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

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

По модели данных

Примеры:

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

· Сетевые

· Реляционные

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

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

По степени распределённости

· Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

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

По способу доступа к БД

· Файл-серверные

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

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

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

· Клиент-серверные

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

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

Примеры: Oracle Database, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

· Встраиваемые

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

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Языковые средства СУБД

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

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

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

Язык запросов (ЯЗ) позволяет выбирать массивы данных из БД, агрегировать и подвергать всевозможной аналитической обработке.

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

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

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

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

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

К числу функциональных компонент СУБД относятся:

§ управление средой хранения данных;

§ методы доступа к данным;

§ поддержка уровней представления данных (концептуального, внутреннего и внешнего);

§ механизмы управления транзакциями;

§ поддержка функций администратора системы;

§ интерактивные пользовательские интерфейсы;

§ интерфейсы прикладного программирования.

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

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

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

Пользователи баз данных

 

Доступ к данным

Существуют два класса методов, реализующих доступ к данным по ключу:

· методы поиска по дереву,

· методы хеширования.

Методы поиска по дереву.

Определение: Деревом называется конечное множество, состоящее из одного или более элементов, называемых узлами, таких, что:

1. между узлами имеет место отношение типа "исходный-порожденный";

2. есть только один узел, не имеющий исходного. Он называется корнем;

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

4. отношение "исходный-порожденный" действует только в одном направлении, т.е. ни один потомок некоторого узла не может стать для него предком.

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

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

Упорядоченное дерево, степень которого не больше 2 называется бинарным деревом. Бинарное дерево особенно часто используется при поиске в оперативной памяти. Алгоритм поиска: вначале аргумент поиска сравнивается с ключом, находящимся в корне. Если аргумент совпадает с ключом, поиск закончен, если же не совпадает, то в случае, когда аргумент оказвается меньше ключа, поиск продолжается в левом поддереве, а в случае когда больше ключа - в правом поддереве. Увеличив уровень на 1 повторяют сравнение, считая текущий узел корнем.

Хеширование.

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

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

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

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование более чем одной транзакционной системы и требуют намного более сложной логики (например, two-phasecommit — двухфазный протокол фиксации транзакции). Также в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.