Экономическая информация в автоматизированных информационных системах

На рынке СУБД лидируют серверные СУБД, сведения о производителях которых приведены ниже: 

 

СУБД	Производитель
Oracle8, Oracle8i	Oracle Corp.
Microsoft SQL  Server 7.0, Microsoft SQL  Server 2000	Microsoft
Informix	Informix
Sybase	Sybase
DB2	IBM

Краткий обзор данных СУБД см. в пособии [11]. 

 

4.4.3. Распределенные СУБД 

 

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

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

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

Требования к РаБД и РаСУБД изложены в правилах К. Дейта, сформулированных в 1987 году:

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

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

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

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

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

 

 

 

 

 

4.5. Тенденции  развития СУБД

 

4.5.1. Объектно-ориентированные и  объектно-реляционные СУБД 

 

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

Шла напряженная работа в двух направлениях:

1) объединение  объектно-ориентированного подхода  и реляционных систем;

2) замена реляционной  модели, ориентируясь исключительно  на объекты.

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

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

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

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

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

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

Наиболее известные коммерческие ООСУБД – GemStone, Vbase, ORION, PDM,   IRIS. Их краткий обзор см. в пособии [11].

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

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

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

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

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

Результаты многолетних исследований в области расширенных реляционных СУБД воплотились в 1996-1997 гг. в ряде коммерческих программных продуктов, представляющих собой объектно-реляционные серверы баз данных с расширяемой системой типов данных. К числу первых систем такого типа относятся: Informix Universal Server (Informix Software, 1996), Oracle8 (Oracle Corp., 1997), DB2 Universal Database (IBM Corp., 1997). Эти программные продукты составляют значительную долю рынка СУБД, и можно сказать, что объектно-реляционная технология уже состоялась.

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

 

4.5.2. Системы управления базами  знаний

 

 

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

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

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

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

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

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

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

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

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

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

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