книги / Теоретические основы автоматизированного управления

2. В расширенных (постреляционных) ОРБД предполагается объ­ ектно-ориентированное построение собственно базы данных путем использования известных и введения новых типов данных, связан­ ных между собой. Эта связь чаще всего осуществляется созданием ме­ тодов с помощью триггеров и хранимых процедур. В расширенной объектно-реляционной модели [42,56] в отличие от реляционной мо­ дели данных допускается неатомарность данных в поле. В таких по­ лях может располагаться другая таблица или массив. К подобным СУБД относятся Informix Universal Server, Oracle 8, UniSQL. В таких СУБД широко используется язык SQL3.

Заметим, что постреляционными [56] называют БД, в которых частично проведена денормализация данных, при этом допускается нетомарность записей. Рассмотрим более подробно обе разновидно­ сти.

1. Гибридные ОРБД рассмотрим на примере программного про­ дукта Delphi.

Приложение Delphi изначально предназначалось для автоматиза­ ции программирования (объектно-ориентированного программиро­ вания), поскольку позволяло резко поднять производительность тру­ да программистов за счет использования готовых «кубиков-про­ грамм». Требовалось лишь должным образом соединить эти «куби­ ки».

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

Форма Delphii, сама являясь объектом, служит «коллектором» для объектов. Как только компонент помещается в форму (и получает по­ рядковый номер), он становится объектом.

Заметим, что компоненты TPanel, TBevel также являются контей­ нерами (в форме), используемыми для форматирования, дизайна (разделения объектов и их выравнивания). Другими «миниконтейне­ рами» служат компоненты DataModule и TQuickRep (отчет).

Для активного объекта в форме при построении программ в «Ин­ спекторе объектов» могут использоваться свойства (страница «свой­ ства») и события (закладка «события»), обычно запускающие про­ граммы-методы.

Все компоненты разделены на следующие основные группы: Standard, Additional, Dialogs, Win32, System, VCL, Internet, DataAccess, DataControl, QReport, Decision Cube, ActiveX. В процессе

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

С позиций собственно баз знаний и баз данных следует обратить особое внимание на страницы DataAccess и DataControl. К ним при­ мыкают страницы QReport, Decision Cube.

Состав компонентов некоторых закладок DataAccess и DataControl приведен рис. 7.9. На рис. 7.10 и 7.11 показаны свойства и события компонента ТТаЫе.

Приложение Delphi может работать с тремя реляционными СУБД: dBase, Paradox — в локальном режиме (см. рис. 7.9); InterBase, который инсталлируется отдельно, — в режиме клиент-сервер.

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

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

2. К расширенным ОРБД относится [13] СУБД Informix Universal Server. С помощью этой разновидности ОРБД решают задачу хране­ ния в БД данных большого объема.

Язык программирования Object Pascal редко используется для формирования объектно-ориентированной модели базы данных. Чаще для этих целей применяют языки С++ и SQL.

Чтобы понять перспективы развития ОРБД, следует оценить их достоинства и недостатки.

К достоинствам следует отнести [43]:

•устранение ряда недостатков реляционных БД;

•повторное использование компонентов;

•использование накопленных знаний по реляционным БД.

Кнедостаткам ОРБД можно отнести:

•усложнение структуры БД и частичную утрату простой обозри­ мости результатов, как в реляционных БД;

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

•менее широкий набор типов связей, определяемых языком про­ граммирования SQL, чем в объектно-ориентированных БД;

•менее продуманный, отлаженный и стандартизованный набор типов данных, чем в ООБД.

ОРБД, по-видимому, будут существовать еще достаточно долго, чему есть, по меньшей мере, два объяснения:

1.Быстрое накопление с помощью ОРБД опыта, который можно использовать при создании ООСУБД.

2.Необходимость иметь средства для постепенного эволюцион­ ного «перевода» многочисленных реляционных БД в разряд ООБД, за которыми, видимо, будущее.

7.3. РАЗВИТИЕ ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ АВТОМАТИЗИРОВАННОГО

УПРАВЛЕНИЯ НА ОСНОВЕ РАСПРЕДЕЛЕННЫХ

БАЗ ДАННЫХ

До сих пор изучались централизованные, локальные базы данных. В то же время распределенные базы данных (РБД) находят все более широкое применение в связи с массовым распространением «сете­ вых» технологий.

Теория создания, использования и функционирования РБД име­ ет свои особенности по сравнению с централизованными БД.

Базы данных явились в значительной мере следствием развития [49] автоматизированных систем управления (АСУ). Первоначально АСУ строились по централизованному принципу: данные из источ­ ников передавались в центральный вычислительный центр с супер­ ЭВМ и там обрабатывались. В силу этого базы данных первоначально назывались банками данных.

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

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

Быстрое распространение сетей передачи данных, резкое увели­ чение объема внешней памяти ПК при ее удешевлении в 80-е годы XX в., развитие возможностей персональных компьютеров, которые по своим характеристикам в 90-е годы уже превосходили суперЭВМ 80-х годов, создали необходимую базу для реализации и широкого внедрения РБД.

Кдостоинствам РБД относятся:

•соответствие структуры РБД структуре организаций;

•гибкое взаимодействие локальных БД;

•широкие возможности централизации узлов;

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

•высокие системные характеристики (малое время отклика за счет распараллеливания процессов, высокая надежность);

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

•возможность распределения файлов в соответствии с их актив­ ностью;

•независимые разработки локальных БД через стандартный ин­ терфейс.

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

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

Возникла необходимость в теоретической проработке процессов в РБД.

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

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

Дополнительными специфическими требованиями являются:

•ЯОД в рамках схемы должен быть один для всехлокальных БД;

•доступ должен быть коллективным к любой области РБД с соот­ ветствующей защитой информации;

•подсхемы должны быть определены в месте сосредоточения ал­ горитмов (приложений, процессов) пользователя;

•степень централизации должна быть разумной;

•необходимы сбор и обработка информации об эффективности функционирования РБД.

Вдальнейшем К. Дейт сформулировал 12 правил для РБД [42,56].

1.Локальная автономность.

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

3.Непрерывное функционирование (развитие) РБД.

4.Независимость РБД от расположения локальных БД.

5.Независимость от фрагментации данных.

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

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

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

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

10.Независимость от операционной системы. И. Независимость от сетевой архитектуры.

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

При рассмотрении РБД выделим:

Рис. 7.12. Схема РБД

1)общие вопросы (состав, работа РБД);

2)теоретические вопросы РБД, в которых по-прежнему имеем три составляющих (создание, использование и функционирование

РБД).

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

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

Не все данные глобального уровня доступны конкретному поль­ зователю. Наиболее полные данные (пользовательский, внешний уровень) имеются в узле 1 (см. рис. 7.12) головного предприятия. В уз­ лах (участках) 2,3 данные менее полные. Так, в узле 3 они имеют вид, приведенный в табл. 7.5.

Пользовательский уровень состоит из фрагментов (например, фрагментов А, В, С, табл. 7.4) глобального уровня, которые составля­ ют фрагментарный, логический уровень.

Выделяют горизонтальную и вертикальную фрагментацию (рас­ членение). Горизонтальная фрагментация связана с делением данных по узлам. Горизонтальные фрагменты не перекрываются. Вертикальная фрагментациясвязана с группированием данных по задачам.

Фрагментация чаще всего не предполагает дублирования инфор­ мации в узлах. В то же время при размещении фрагментов по узлам (локализации) распределенного уровня в узлах разрешается иметь ко­ пии той или иной части РБД.

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

Иначе говоря, РБД можно представить в виде, показанном на рис. 7.12.

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предна­ значавшихся для использования в сети, следует назвать BTrieve, Oracle, InterBase, Sybase, Informix.

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

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

Пользовательский запрос, определяемый приложением, поступа­ ет в систему управления распределенной базы данных (СУРБД), че-

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

В этой структуре один из компьютеров, имеющий самый большой объем памяти и наиболее высокое быстродействие, становится при­ оритетным, называемым сервером.