Максимов Н.В., Голицына О.Л., Васина Е.Н. Управление данными

Подождите немного. Документ загружается.

291

Контрольные вопросы

1. Определите понятие «база данных» в рамках СУБД

2. В чем состоит сходство и различие кластеризованного и некла-

стеризованного индексов.

3. Какие компоненты включает в себя модель безопасности

4. Когда нужно использовать систему аутентификации Windows

NT и SQL Server

5. Дайте сравнительный анализ типов ролей уровня сервера,

уровня базы данных, уровня приложений

6. Назначение и типы «ролей»

7. Назначение хранимых процедур и триггеров. В чем состоит

сходство и различие хранимых процедур и триггеров.

8. Использование «представлений» для управления доступом

9. Назначение и обобщенная схема репликации баз данных

10. Назначение и использование «контрольных точек» для восста-

новления БД

11. Назначение и основные способы резервного копирования

292

Глава 11. Направления развития концепций и систем обработки

данных

11.1. Еще раз о проектировании и реализации систем баз данных

Приведем из [7] обзор проблем, связанных с реальностью проек-

тирования и использования систем баз данных.

Прежде всего, необходимо отметить, что многое из классических

подходов и методов на практике не используется или используется пло-

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

методов и моделей, если только они не входят в используемую модель

данных непосредственно, а должны применяться проектировщиками для

получения и верификации высокого качества проектных решений. На-

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

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

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

оптимизация размещения БД на устройствах внешней памяти и по сети

проводится "на глазок". В последнее время значительно меньше внима-

ния уделяется и инструментальным средствам автоматизации физиче-

ского проектирования БД, включая математическое и натурное модели-

рование характеристик, в том числе, распределенных БД.

Это объясняется несколькими, отчасти субъективными, причина-

ми:

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

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

вость больших интегрированных решений в мире с постоянно меняю-

щимися требованиями к информационным системам;

- высокими требования к квалификации проектировщиков в об-

ласти теоретических основ классического проектирования БД;

- относительной легкостью выполнения реорганизации логиче-

ской и физической структуры БД в современных СУБД, что зачастую

становится одной из ловушек для проектировщика.

Существенны и ограничения, свойственные классическим мето-

дам. Классические модели и методы ориентировались на организацию

хранения и обработки хорошо структурированных данных, чему отвеча-

ло понятие "атрибута" как свойства объекта, представляемого атомар-

ным элементом данных. Именно вследствие этого, как отмечалось ранее,

документальные БД выделились в особый тип баз данных.

Спустя годы и десятилетия после объявления своих классических

моделей и концепций классики в явном виде указали на их ограничен-

ность. Так, в [25] было признано, что "при обсуждении моделирования

семантики данных акцент делается на структурные аспекты в ущерб ас-

пектам обработки. Структура без соответствующих операций или подра-

зумеваемых методов подобна анатомии в отсутствии физиологии". А в

293

[26] отмечается, что "...обладание большой корпоративной БД имеет ма-

ленькое значение, если конечные пользователи не имеют возможностей

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

ных". Проектирование БД (и ИС в целом) по классическим правилам

полноты и целостности часто стало признаваться практически бессмыс-

ленным. "К 1990 году почти все аспекты стандартной процедуры работы

с информационными технологиями были оспорены, и вычислительные

архитектуры вырвались из-под контроля. ... Стандарты программирова-

ния размывались, а понятие неизбыточных, непротиворечивых, высоко-

качественных данных годилось разве что для груды хлама" [16].

Вместе с тем становились значимыми новые причины появления

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

ние удельной стоимости средств вычислительной техники привели ко

многим новым возможностям. Список типов хранимых и обрабатывае-

мых данных расширился до пределов, определяемых самым общим нор-

мативным значением понятия "данное". В базы данных включаются не

только неформатированные элементы и полнотекстовые фрагменты: ус-

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

мационные и другие БД. Более того, новые возможности ИТ привели к

увеличению рыночных возможностей и требований потребителей, как

следствие - к резкому усилению конкуренции в различных отраслях

промышленности и услуг. Это в свою очередь стимулировало появление

технологии бизнес-реинжиниринга [27] и строительство киберкорпора-

ций [15]. Эти подходы ориентированы, в первую очередь, на осуществ-

ление радикальных изменений в организации основной деятельности

предприятий и, в частности, на резкое снижение затрат времени, числа

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

партнерами в любой точке мира, в том числе в режиме 24*365; увеличе-

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

ми для самостоятельного получения конечного результата и ориентаци-

ей на будущие потребности клиента.

Новые требования к архитектуре корпоративных ИС и, как следст-

вие - новые требования к корпоративным БД должны рассматриваться

как интеграция трех составных частей: требований бизнес-

реинжиниринга, человеческого фактора и методов новых ИТ. Реальное

объединение этих трех составных частей, каждая из которых приобрела

в 90-е годы качественно новое наполнение, включает следующие требо-

вания:

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

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

работником, который и получает конечный результат;

- использование архитектуры и программных средств хранилища

данных, средств Оперативной Аналитической Обработки Данных

294

(OLAP), применение средств быстрой разработки приложений (RAD),

средств поддержки принятия решений (DSS) на основе хранилища дан-

ных, OLAP и RAD/EIS; применение средств DSS на основе анализа БД

прецедентов, а также методов логического вывода, нейронных сетей и

др.;

- предложение единого интерфейса пользователя для работы с

разными компонентами данных и приложений

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

для новой ИС, реализация структуры БД, предполагающая снятие (су-

щественное уменьшение) ограничений на ее развитие, в том числе, при

смене функций или функциональных компонентов обработки информа-

ции; применение методов компонентного проектирования БД

- постоянная актуализация понятийной модели деятельности

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

прикладных компонент на функционально сходные и при изменении ви-

дов деятельности предприятия, и построение на этой основе новых ин-

терфейсов между компонентами ИС;

- динамическое администрирование фрагментами распределен-

ной корпоративной БД при изменении частоты их использования, при

модификации их структуры и при изменении их размещения.

Объединение требований к динамике и разнообразию типов ин-

формационных потоков, обрабатываемых в ИС, с учетом роста их объе-

мов и требований к разнообразию методов обработки позволяет дать

следующую обобщенную характеристику технологий, определяющих

архитектуру БД:

- компонентная технология проектирования и представления

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

вателей через общие интерфейсы;

- расширенная технология Хранилища Данных, интегрирующая

наследованные форматированные данные, архивные текстовые доку-

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

аналитической обработки данных, необходимые виды "дружественных"

интерфейсов;

- открытость БД для включения в нее и получения из нее инфор-

мации с использованием принципов и средств глобальной сети Internet;

- использование архитектуры Открытых Систем, расширенной

методами и средствами, обеспечивающими открытость компонентного

проектирования БД, переносимость, интероперабельность, масштаби-

руемость и др.

Еще раз напомним, что требование интеграции ресурсов появи-

лось в связи с необходимостью комплексирования ресурсов и, в первую

очередь систем БД, основанных на разных моделях данных и управляе-

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

295

доставление пользователям интегрированной системы некоторой гло-

бальной схемы БД, обеспечение метода доступа к данным, в том числе

автоматическое преобразование операторов манипулирования данными

в операторы, понятные соответствующим локальным СУБД, организа-

ция доступа к данным на сетевом уровне.

Среди направлений исследований и разработок последних лет, в

той или иной степени ориентированных на решение этих задач, и полу-

чивших не только развитие, но также нашедших практическое воплоще-

ние и применение, можно выделить следующие:

- объектно-ориентированные базы данных, как развитие пара-

дигмы построения баз данных на основе хорошо формализованных мо-

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

атрибутивных представлений объектов и процессов предметной области,

а также учет поведенческого аспекта;

- ориентированная на интеграцию данных технология Хранилища

данных - построение федеративных систем неоднородных БД, объеди-

няющая на логическом или физическом уровне наследованные форма-

тированные данные, архивные текстовые документы, звуковые и видео-

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

данных, необходимые виды "дружественных" интерфейсов;

- интеграция с Internet-технологиями – не только включение в со-

став СУБД средств и интерфейсов поддержки Internet-доступа, но и соз-

дание Internet-протоколов и технологий, ориентированных на задачи

информационного (документального) поиска.

11.2. Объектно-ориентированные базы данных

В объектно-ориентированной парадигме модель предметной об-

ласти – это класс взаимодействующих объектов, каждый из которых

представляется набором свойств (статическими характеристиками) и на-

бором методов работы с этим объектом (что и позволяет отразить «по-

ведение» объекта) и обладающих следующими свойствами.

1. Инкапсуляция - объекты наделяются некоторой структурой и

обладают определенным набором операций (методов). Внутренняя

структура объекта скрыта от пользователя; манипуляция объектом, из-

менение его состояния возможны лишь посредством его методов. Таким

образом объекты можно рассматривать как самостоятельные сущности

2. Наследование - возможность создавать из объектов новые объ-

екты, которые унаследуют структуру и поведение своих предшествен-

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

альность.

3. Полиморфизм - различные объекты могут получать одинаковые

сообщения, но реагировать на них по-разному, в соответствии с тем, как

реализованы у них методы, реагирующие на сообщения.

296

В [1] определены следующие свойства

, положенные в основу

создания объектно-ориентированных баз данных.

1. Сложные объекты строятся из более простых при помощи

конструкторов. Простейшими объектами являются такие объекты, как

целые числа, символы, и др. Минимальный набор конструкторов, кото-

рый должна иметь система, - это конструкторы множеств, списков и

кортежей.

2. Идентифицируемость объектов. В модели с идентифицируемо-

стью объектов объект существует независимо от его значения. Таким

образом, имеется два понятия эквивалентности объектов: два объекта

могут быть идентичны (они представляют собой один и тот же объект)

или они могут быть равны (имеют одно и тоже значение). Это влечет два

следствия: первое – существование совместно используемых (разделяе-

мых) объектов, а второе - изменения объектов.

3. Инкапсуляция. Идея инкапсуляции связана с одной стороны, с

потребностью четко различать состояния (время) спецификации и реа-

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

ся основой для структурирования сложных приложений, разрабатывае-

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

данных состоит в том, что объект инкапсулирует и программу, и данные.

Таким образом, имеется единая модель для данных и операций,

причем информация может быть скрыта, т.е. никакие операции, кроме

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

чивает "логическую независимость данных": можно изменить реализа-

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

4. Типы и классы. В объектно-ориентированной системе тип обоб-

щает общие черты множества объектов с одинаковыми характеристика-

ми. Понятие класса отличается от понятия типа. Его спецификация сов-

падает со спецификацией типа, но является более динамическим поня-

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

скорее для создания и манипулирования объектами. В большинстве сис-

тем классами можно манипулировать во время выполнения, т. е. изме-

нять их и передавать как параметры.

5. Иерархии классов или типов. Наследование обладает двумя по-

ложительными достоинствами. Во-первых, оно является мощным сред-

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

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

могает факторизовать спецификации и реализации, совместно исполь-

зуемые в приложениях.

6. Перекрытие, перегрузка и позднее связывание. Чтобы исклю-

чить переписывание программ при введении нового типа и добавлении

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

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

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

297

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

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

трансляция называется поздним связыванием. Отметим, что хотя позднее

связывание затрудняет проверку типов (а в некоторых случаях делает ее

невозможной), оно не отменяет ее полностью.

7. Вычислительная полнота. С точки зрения языка программиро-

вания это свойство является очевидным: оно просто означает, что лю-

бую вычислимую функцию можно выразить с помощью языка манипу-

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

это является новшеством, так как SQL, например, не является полным

языком.

8. Расширяемость. Система базы данных поставляется с набором

предопределенных типов, но этот набор должен быть расширяемым:

должны иметься средства для определения новых типов и не должно

быть различий в использовании системных и определенных пользовате-

лем типов. Способы поддержания системой системных и пользователь-

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

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

9. Стабильность. Стабильность (persistence) означает возмож-

ность обеспечить сохранность данных после завершения выполнения

одного процесса для последующего использования в другом процессе.

10. Управление вторичной памятью. Управление вторичной памя-

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

Эта возможность обычно поддерживается с помощью набора механиз-

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

ция данных, выбор метода доступа и оптимизация запросов.

11. Параллелизм. Система должна обеспечивать пользователям

возможность одновременно работать с базой данных. Следовательно,

система должна поддерживать стандартное понятие атомарности после-

довательности операций и управляемого совместного доступа.

12. Восстановление. В случае аппаратных или программных сбоев

система должна восстанавливаться, т. е. возвращаться к некоторому со-

гласованному состоянию данных.

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

должна позволять обрабатывать запросы, не предусмотренные при про-

ектировании базы данных.

С точки зрения вышеуказанных требований можно отметить сле-

дующие ограничения реляционной технологии:

1. Неестественное представление данных со сложной структурой.

Реляционная модель данных не допускает «естественного» моделирова-

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

моделирование лишь с помощью плоских отношений (таблиц). Так как

все отношения принадлежат одному уровню, многие значимые связи

298

между данными либо теряются, либо их поддержку приходится осуще-

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

2. Затруднительно должным образом смоделировать свойства дан-

ных. Чтобы смоделировать структуру сложных данных, пользователь

должен иметь возможность определять свои типы данных, не ограничи-

ваясь типами данных, предоставляемыми определенной СУБД.

3. Реляционная модель данных не позволяет определить набор

операций, связанных с данными определенного типа, что часто является

естественным требованием при моделировании данных со сложной

структурой. Операции приходится задавать в конкретном приложении.

4. Реляционная модель не позволяет рассматривать данные по-

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

ясь от ненужных деталей.

5. Усложненный доступ к базе данных. Интерфейс между языком

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

каждый язык имеет свой набор типов и свою модель вычислений. Орга-

низуя обращение к базе данных из прикладной программы, написанной,

например, на C++, приходится подвергать данные структурной транс-

формации при передаче их из/в базу данных.

Модель данных, созданная на этапе концептуального конструиро-

вания, не находит непосредственного выражения в структуре базы дан-

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

димых средств.

Однако также необходимо привести ряд, в той или иной степени

важных, недостатков, отмеченных, например, в [10].

Большинство современных ООБД не делают существенного шага

вперед к полным возможностям обработки запросов по сравнению с ре-

ляционными БД; они обладают простыми средствами извлечения посто-

янных объектов.

Так или иначе, объектно-оринтированные БД (ООБД) накладыва-

ют некоторые ограничения в части определения постоянных данных. В

частности, большинство систем по-разному трактуют постоянные и не-

постоянные данные; поэтому пользователи должны явно объявлять, по-

стоянный объект или нет.

Второй, гораздо более серьезный, показатель незрелости большей

части современных ООБД - недостаток средств, к которым привыкли и

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

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

работка запросов, одновременный доступ, авторизация, динамическое

изменение схем, обработка вложенных подзапросов, операции над мно-

жествами (объединение, пересечение, разность), функции агрегирова-

ния.

299

Большинство современных ООБД предоставляют возможность

только добавлять новые классы к базе данных, но не позволяют доба-

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

Ведутся жаркие споры о степени однородности таких систем. Яв-

ляется ли тип и метод объектами? На уровне реализации необходимо

решить, будет ли информация о типе храниться как объект, или будет

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

вопрос, с которым сталкиваются проектировщики систем реляционных

баз данных при принятии решения о том, как следует хранить схему: в

виде таблицы или некоторым специальным образом.

Наконец, на уровне интерфейса требуется принять еще одно реше-

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

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

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

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

язык программирования не делает между ними различия. Это решение

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

11.3. Интеграция БД и хранилища данных

Направление появилось в связи с необходимостью комплексиро-

вания систем БД, основанных на разных моделях данных и управляемых

разными СУБД

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

рачивают свою автономность. После включения локальной БД в федера-

тивную систему все дальнейшие действия с ней, включая администри-

рование, должны вестись на глобальном уровне. Однако, на практике

возможны два следующих способа интеграции.

В первом случае – создания мультибаз, ресурсы объединяются ло-

кально (например, в составе конкретной организационной структуры,

для решения некоторого класса задач, организации доступа определен-

ного круга пользователей и т.д.), при этом пользователи не теряют авто-

номность и имеют возможность работать со всеми локальными СУБД на

одном языке, адресуя запросы одновременно в разные локальные БД. В

системах мульти-БД не поддерживается глобальная схема интегриро-

ванной БД и применяются специальные способы идентификации объек-

тов и методов для доступа к локальным БД. Чаще всего в таких системах

на глобальном уровне допускается только выборка данных, что позволя-

ет достаточно просто сохранить автономность локальных БД. В послед-

нее время для внешнего представления интегрированных и мульти-БД

все чаще предлагается использовать объектно-ориентированные модели,

но на практике пока чаще встречаются частные решения, ориентирован-

ные на конкретные СУБД.

В контексте эволюции концепции реляционных баз данных это направление иногда связывают с

отказом от нормализации отношений.

300

Во втором случае, как правило, интегрировать приходится неод-

нородные БД, распределенные в вычислительной сети. Это в значитель-

ной степени усложняет реализацию. Дополнительно к собственным про-

блемам интеграции приходится решать все проблемы, присущие распре-

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

тимизацию запросов и т. д. В этом случае добиться эффективности ре-

шений очень трудно.

11.3.1. Основы технологии интеграции распределенных данных

Одна из главных задач, которую призваны решать системы управ-

ления - это интеграция данных из различных источников, в том числе со

слабоструктурированными данными. Системы интеграции данных

должны обрабатывать запросы, для ответа на которые может потребо-

ваться извлечение и обобщение данных из различных источников. При

этом возможны следующие варианты:

− Регулярные источники, где представление и организация дан-

ных в той или иной степени формализованы, хотя при этом могут ис-

пользоваться различные модели данных и интерфейсы доступа к ним,

или данные источника могут быть не структурированными (HTML-

файлы, текстовые файлы и т.д.).

− Источники уникальные, т.е. взаимодействовать с источником

можно только через предоставляемый им интерфейс и нет никакой воз-

можности повлиять на его внутренние процессы.

Теоретически и практически возможны два подхода к решению

задачи интеграции данных – хранилища данных и виртуальные храни-

лища (или «витрины данных»).

При использовании первого подхода хранилище физически или

логически объединяет данные из различных источников, и затем все за-

просы обрабатываются с использованием этих данных. В этом случае

актуальность данных не гарантируется, поскольку никакой синхрониза-

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

что объединение централизовано и, следовательно, время выполнения

запроса не велико.

При использовании второго подхода, данные хранятся в источни-

ках, а запросы к системе интеграции транслируются в запросы или опе-

рации понятные источнику. Данные, полученные в ответ на эти запросы

к источникам, объединяются и предоставляются пользователю. Пре-

имущество виртуальных хранилищ заключается в гарантии того, что

пользователь получает только актуальные данные. Но поскольку источ-

ники могут значительно отличаться, возникают трудности связанные с

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

вертирование данных, что существенно снижает общую производитель-

ность системы.