Что из нижеперечисленного реализовано в современных субд

Реализация абстрактной модели активных баз данных средствами современных СУБД Текст научной статьи по специальности «Компьютерные и информационные науки»

Текст научной работы на тему «Реализация абстрактной модели активных баз данных средствами современных СУБД»

Шибанов С.В. , Лысенко Э.В., Скоробогатько А.А., Зудов А.Б. , Вишняков П.В.

РЕАЛИЗАЦИЯ АБСТРАКТНОЙ МОДЕЛИ АКТИВНЫХ БАЗ ДАННЫХ СРЕДСТВАМИ СОВРЕМЕННЫХ СУБД

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

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

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

Те же проблемы распространяются и на системы мониторинга, контроля и планирования. Речь идёт о более узкоспециальных и разнотипных системах, таких как системы планирования и управления рабочим процессом [3], мониторинга физических процессов и так далее. Эти задачи требуют своевременного обнаружения критических ситуаций и ответа на них, а значит, необходима высокая адаптивность всей системы, что для базы данных значит автоматическую реакцию на определённые события, описанную в терминах триггеров.

Всё большее распространение получают базы данных движущихся объектов (Moving Objects Database -MODB). [4] Эти объекты изначально не статичны и обладают поведением, перемещаясь по локациям разных типов, меняя тем самым свои характеристики и влияя на характеристики локаций. Таким образом, ситуаций возникает много, а на них нужно реагировать всё так же быстро. Сейчас стали необходимы системы, позволяющие моделировать и прогнозировать пробки и аварии, проектировать транспортные пути и автоматизировать управление трафиком. Похожими на мониторинг трафика задачами являются моделирование сражений, контроль перемещения животных и птиц в экологии и, конечно же, средства мобильной коммуникации.

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

Обширная область исследований — пиринговые (одноранговые, децентрализованные) сети, то есть сети, в которых каждый узел (пир) является одновременно клиентом и сервером. Сложность таких систем не только в том, что база данных оказывается распределённой, но и в том, что число источников событий постоянно изменяется [5]. Пирами могут быть не только стационарные машины, но и мобильные устройства. В этом случае БД будет объединять некоторые особенности баз данных движущихся объектов и систем на основе пиринговые сетей. [6] С такой задачей традиционные СУБД часто не справляются даже в аспекте производительности. Чтобы решить эту проблему, необходим подход, при котором неким образом упрощалась бы обработка запросов.

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

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

2.1. Классическая модель знаний (модель ECA-правил). Классическая модель знаний АБД основывается на правилах, которые содержат три компонента: событие (event), условие (condition) и действие (ac-

tion). Такого рода правила называют ECA-правилами.

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

Структурная операция (structure operation) — событие порождается операцией над некоторой частью структуры данных, например, вставить кортеж, изменить атрибут, получить доступ к кортежу;

Вызов поведения (behavior invocation) — событие порождается выполнением некой операции, описанной пользователем, часто событие может порождаться до или после выполнения операции;

Транзакция (transaction) — событие порождается командами транзакций (например, begin transaction, commit, rollback);

Абстрактные (abstract) — описанные пользователем события, механизм программирования которых позволяет сигнализировать о возникновении события явно, например, в ответ на некоторую информацию, введённую пользователем;

Исключения (exeptions) — событие появляется в результате некоторого возникшего исключения, например, была сделана попытка получить доступ к данным без соответствующей авторизации;

Часы (clock) — событие возникает в некоторый момент времени — абсолютное, например, 1З Ноября 199B в 15:00, относительное, например, 10 дней после того, как акции проданы, и периодическое, например, в первый день каждого месяца временные события;

Внешние (external) — событие порождается чем-то извне, например, измеряемая датчиком температура выше 3 0 градусов.

Масштаб события (Event Granularity) указывает на то, что событие определено:

для каждого объекта в наборе (set) — например, каждого экземпляра класса;

для заданных поднаборов (subset) — например, все штатные сотрудники, кроме профессоров;

для некоторых членов (members) набора — например, чтобы предотвратить неавторизованный доступ к некоторым экземплярам, или чтобы сделать возможным обновление тех объектов, которые сейчас отображаются на экране.

Тип (Type)события может быть:

примитивным (primitive) — событие порождается одиночным низкоуровневым действием, что описанным как источник. Например, событие on insert to Owns контролирует вставку новых кортежей в отношение Owns;

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

Роль события указывает, должно ли оно всегда задаваться для активных правил, или же явное обозначение не является необходимым. Если роль опциональна (optional), то речь идет о существовании правил условие-действие (помимо ECA), в которых событие опущено. Если роли нет (none), то события не могут быть определены, и все правила являются условиями-действиями. Если роль обязательная (mandatory), то поддерживаются только ECA-правила.

Часть условия (condition) правила проверяет контекст, при котором событие произошло. Роль условия показывает, должно ли оно обязательно присутствовать. В ECA-правилах роль условия обычно опциональны. Когда оно не задано, или когда роли нет (none), получается правило событие-действие. В системах, в которых и событие, и условие необязательны, должно присутствовать хотя бы одно.

Контекст указывает на окружение, в котором условие вычисляется. Различные компоненты правила не вычисляют изолированно друг от друга, и более того, они не могут быть вычислены моментально. Как результат, обработка одиночного правила может быть потенциально ассоциировано, как минимум, с четырьмя разными состояниями БД:

1) DBT — база данных в начале транзакции;

2) DBE — база данных в момент; когда событие появилось;

3) DBC — база данных в момент, когда вычислено условие;

4) DBa — база данных в момент, когда выполнено действие.

Системы активных правил должны поддерживать внутри условия возможность доступ к нулю или больше состояний DBt, DBe и DBc, и также обеспечить доступ к связкам с событием (BindE).

Действие (action) описывает задачу, которая должна быть выполнена правилом, если соответствующее событие произошло и условие оказалось истинным. Список задач, которые могут быть выполнены действием определяются как его Опции. Действия могут менять структуру (structure) базы данных или набора правил, выполнять некоторый вызов поведения (behavior invacation) внутри базы данных или внешний (external) вызов, информировать (inform) пользователя или системного администратора о какой-либо ситуации, прерывать (abort) транзакцию или принимать альтернативную линию поведения, используя do-instead.

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

2.2. Расширенная модель знаний (SECA-модель). Классическая ECA-модель не учитывает, что в реальных приложениях поведение объекта часто зависит от его состояния.

Например, учетная запись пользователя может быть «активна» или «заблокирована», и в зависимости от этого различной может быть реакция на попытку входа пользователя в систему.

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

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

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

Добавление в классическую ECA-модель понятия состояния сокращает количество необходимых правил и упрощает процесс разработки активной системы. Возможные типы поведения объекта группируются в соответствии с его состояниями, поведение объекта структурируется и становится доступнее для понимания. Модель ECA-правил, учитывающую состояние объекта называется расширенной моделью ECA-правил, или SECA-моделью (State-Event-Condition-Action).

Графической интерпретацией SECA-модели являются диаграммы состояний UML. Диаграмма состояний -это граф, узлами которого являются состояния, а направленными дугами — переходы между состояниями.

Понятие перехода (transition) от исходного к целевому состоянию в SECA-модели аналогично понятию ECA-правила в ECA-модели. С переходом связывается вызывающее его событие, сторожевое условие и выполняемое при переходе действие, а также два состояния — исходное и целевое. При возникновении события и выполнении сторожевого условия происходит не только выполнение действия, но и переход объекта из исходного состояния в целевое. Исходное и целевое состояния могут совпадать, что аналогично простому ECA-правилу.

Диаграммы состояний UML позволяют наглядно изобразить поведение объекта. В этом кроется еще одно преимущество SECA-модели перед классической ECA-моделью, которая представляется списком правил.

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

1) Набор метаданных, содержащих информацию о возможных состояниях, событиях, условиях и действиях, а также о возможных переходах между состояниями;

2) Набор процедур, настраивающих СУБД на поведение в соответствии с диаграммой состояний;

Метаданные SECA-модели целесообразно разделить на две части:

1) Модель состояний с абстрактными событиями, условиями и действиями, не привязанными к конкретной модели данных и СУБД;

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

Такое разделение упрощает перенос модели между различными СУБД: для использования модели в новой

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

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

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

Триггеры реализуют реакции сервера данных на определенные события. По своей сути триггер — это особая разновидность хранимой процедуры, выполняемая автоматически при возникновении события на сервере базы данных. Триггеры языка обработки данных выполняются по событиям, вызванным попыткой пользователя изменить данные с помощью языка обработки данных. Событиями DML являются процедуры INSERT, UPDATE или DELETE, применяемые к таблице или представлению. Эти триггеры срабатывают при запуске любого допустимого события независимо от того, влияет ли оно на какие-либо строки таблицы.

По своей сути триггеры являются ECA-правила, для которых событиям возникновения являются операции NSERT, UPDATE или DELETE. В них также можно определить условие, для дальнейшего выполнения и действие, которое может быть отличным от первоначального события, которое инициировало триггер

Таблица 1 — Возможности СУБД Microsoft SQL Server 2008 по реализации основных особенностей АБД

Особенность СУАБД Microsoft SQL Server Оценка

І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере + + +

1.2 Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + — —

Определение условий Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности — C# и C++.NET) + + +

Определение действия Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности — C# и C++.NET). + + +

1.3 Средства для управления базами правил и их эволюции Управление базами правил Ядро СУБД предопределяет список обнаруживаемых событий + — —

Поддержка эволюции базы правил Условие и действие могут быть изменены с помощью директив SQL, требуется повторная компиляция только измененных данных. + + —

Возможность активировать или деактивировать правила Присутствует возможность селективного управления активностью триггеров

1 2 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Сложные события не обнаруживаются + — —

Поддержка режима связывания Событие связывается с конкретным объектом + — —

Механизм проверки условий Условие имеет доступ как к текущему, так и к предыдущему (последующему) состояниям объекта, а также другим объектам БД + + +

Механизм выполнения действий Существуют ограничения, определяемые возникшим событием + + —

2.2 Методы сцепления транзакций Реализованы различные механизмы сцепления транзакций +++

2.3 Способы выявления сложных событий Механизм выявления сложных событий отсутствует

2 Управление историей событий Любые события записываются в системный журнал базы данных + + —

2.5 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного способа блокировок, возможна дополнительная эскалация блокировок + + —

1 3 Поддержка программной окружающей среды Специализированные средства разработки правил отсутствуют. Наращивание возможностей по обработке возможно только в рамках существующей схемы событий.

3.2 Настройка СУАБД Проектирование может быть осуществлено с использованием двух- или трехуровневой модели. + + +

Таблица 2 — Возможности СУБД Oracle 11д по реализации основных особенностей АБД

№ Особенность СУАБД Характеристики СУБД Oracle Оценка

1.1 СУАБД есть просто СУБД В полной мере поддерживает возможности реляционных СУБД + + +

1.2 Поддержка модели ЕСА- правил Определение типов событий Простейшими событиями, которые можно обнаружить внутри базы данных, являются вставка, обновление и удаление, остальные же события должны быть реализованы как сложные. Сложных событий в Oracle нет, и их необходимо добавить разработчику СУАБД. На внешние события такое ограничение не распространяется + + —

Определение условий Условия можно задавать различными языками (PL/SQL, C++, Java) + + +

Определение действия Как и в случае условий, ограничений в определении действий нет + + +

1.3 Средства для управления базами правил и их эволюции Управление базами правил Базу правил можно хранить как совокупность скриптов, хранимых процедур и триггеров + + +

Поддержка эволюции базы правил Если хранить скрипты в таблицах, то их можно изменять как обычные строковые данные. В зависимости от того, на каком языке написаны правила, их изменения может требовать (в случае PL/SQL) или не требовать перекомпиляции. Ограничений в модификации триггеров тоже нет. + + +

Возможность активировать или деактивировать правила Деактивация правил — это деактивация обнаружения событий. Так как оно реализуется через триггеры, которые в Oracle можно деактивировать, данный способ управления базой правил поддерживается полностью + + +

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

Поддержка режима связывания Любое событие может снабжаться информацией о связанных с событием данных без каких-либо ограничений, так как в случае простых событий для этой цели служат переменные new и old, а для сложных событий детектор может объединять значения этих переменных, пришедших от разных простых событий + + +

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

Механизм выполнения действий Так как в Oracle поддерживаются триггеры типов AFTER и BEFORE, правило может выполняться до и после события. Действию доступны те же данные, что и условию + + +

2.2 Методы сцепления транзакций По умолчанию используется немедленное сцепление транзакций, при использовании автономных транзакций возможна реализация расцепленного метода + + —

2.3 Способы выявления сложных событий Встроенные средства реализации обнаружения сложных событий отсутствуют + — —

2.4 Управление историей событий Не все структуры, подходящие для хранения истории событий, могут быть реализованы эффективно. + + —

2.5 Механизмы разрешения коллизий Oracle поддерживает гибкие возможности параллельного выполнения + + +

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

3.2 Настройка СУАБД Ограничений в возможности реализации настройки СУАБД нет + + +

Таблица 3 — Возможности СУБД Progress по реализации основных особенностей АБД

№ Особенность СУАБД Характеристики СУБД Progress Оценка

\—і \—і СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +

2 \—і Поддержка модели ECA-правил Определение типов событий Определяет события CREATE, DELETE, WRITE, ASSIGN, FIND. Все события имеют тип «до». Определение сложных событий отсутствует. + — —

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Определение условий Для представления условий и действий используется язык Progress 4GL (ABL). С версии 10 в нем реализована полная поддержка + + +

1.3 Средства для управления базами правил и их эволюции Управление базами правил Информация о триггерах хранится в системных таблицах и доступна пользователям посредством специального инструмента — Data Dictionary. Код триггеров хранится отдельно от базы данных в файлах процедур(p-модулях). + + +

Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция соответствующего p-модуля. + + —

Возможность активировать или деактивировать правила Для активации и деактивации правил используется специальная утилита. + + +

2.1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + — —

Поддержка режима связывания CREATE, WRITE, DELETE и FIND связаны с отдельным картежом, ASSIGN — с отдельным полем. + + —

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

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

2 2 Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. Триггер всегда выполняется внутри вызвавшей его транзакции. + — —

3 2 Способы выявления сложных событий Механизм выявления сложных событий отсутствует. — — —

2 Управление историей событий История событий отсутствует — — —

LO 2 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию используется разделяемая (shared) блокировка для чтения и эксклюзивная (exclusive) для записи. + — —

1 3 Поддержка программной окружающей среды Доступны средства разработки классов, которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + — —

2 3 Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + +

Тип триггера определяется тем, какое событие его активизирует — INSERT (вставка), UPDATE (изменение) или DELETE (удаление). Триггеры могут активизироваться до (BEFORE) или после (AFTER) наступления события, а также для строки таблицы (кортежа) или оператора, вызвавшего события в целом. Если триггер является строковым (кортежным), то он активизируется один раз для каждой из строк, на которые воздействует оператор, который вызвал срабатывание триггера. Если триггер является операторным, то он активизируется один раз до или после выполнения оператора. Строковые триггеры содержат фразу FOR EACH ROW в описании триггера.

В таблице 1 представлены основные возможности СУБД MS SQL Server 2008 для реализации абстрактной модели и построения АБД. В таблице 2 представлены основные возможности СУБД Oracle 11g для реализации абстрактной модели и построения АБД. В таблице 3 представлены основные возможности СУБД Progress для реализации абстрактной модели и построения АБД.

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

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

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

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

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

%OnNew — вызывается при создании нового объекта в оперативной памяти в тот момент, когда выделена память под объект и инициализированы его свойства.

%OnOpen — функция вызывается перед извлечением существующего объекта из базы данных.

%OnDelet — данная функция вызывается перед удалением объекта.

%OnBeforSave и %OnAfterSave -вызываются непосредственно перед и сразу после сохранения объекта в базу данных соответственно.

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

Автоматическое добавление оберток к наблюдаемому методу требует доступа к информации об атрибутах и методах классов. Другими словами, должна иметься возможность изменять определение класса во время выполнения. В Cache эту задачу решает механизм классов-определений (Class Definition Classes). Механизм реализован в виде отдельного пакета (%Dictionary, словарь определений классов) и позволяет просматривать определения существующих в базе данных классов и вносить в них изменения.

Классы пакета %Dictionary позволяют получить полный доступ к определениям классов, находящихся в базе данных. Они дают возможность просматривать списки методов и атрибутов класса, добавлять новые атрибуты и методы и изменять существующие. Cache позволяет работать с определениями классов как с обычными объектами базы данных. Например, для создания нового класса необходимо создать объект класса %Dictionary.ClassDefinition, добавить к объекту методы и свойства и сохранить его в базу данных.

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

1) Тип события UserDefined. Пользовательская операция позволяет клиентской программе запустить выполнение некоторой программы на сервере. Этот тип события отличается от простого вызова метода тем, что метод может быть вызван не только по запросу пользователя, но и самой СУБД. При обнаружении данного типа события следует удостоверится, что запуск активности был инициирован пользовательской программой. Это может быть реализовано созданием в базе данных отдельного класса для хранения пользовательских событий (UserAction). Объекты класса будет хранить описание события и дополнительную связанную с событием информацию (Например, событие «Пользователь входит в систему» может в качестве дополнительной информации хранить введенные пользователем логин и пароль). Активация события будет производиться вызовом специального метода объекта UserAction.FireAction().

2) Тип события Clock. Можно выделить два способа обнаружения событий наступления определенного

момента времени. Первый способ заключается в написании программы на Cache Object Script, выполняющейся на сервере и периодически проверяющей наступление события. Этот подход обладает более высокой производительностью (отсутствуют затраты на взаимодействие сервера Cache и клиента планировщика), но страдает недостаточной гибкостью. Второй способ заключается в использовании сторонних программ-планировщиков для запуска задач по расписанию (at, Cron, Anacron в Linux, TaskScheduler в Windows). В качестве задачи планировщику можно назначить выполнение автоматически генерируемого скрипта или запрос URL, содержащего CGI программу активации события. Преимущество этого способа заключается в возможности использования различных программ-планировщиков или даже написания своих для поддержания особой функциональности. На мой взгляд, при разработке уровня активности следует поддержать оба подхода: первый для обеспечения базовой функциональности и второй, в виде Web-интерфейса для внешних

программ-планировщиков, для обеспечения расширяемости.

3) Тип события External. Внешние события можно разделить на две категории: события периферийных

устройств и удаленные события. Для обнаружения событий периферийных устройств можно использовать библиотеку управления вводом/выводом (Cachte I/O Device). Данная библиотека позволяет работать с периферийными устройствами напрямую из методов объектов с использованием языка Cache Object Script. Cache поддерживает работу с разнообразным периферийным оборудованием, в том числе принтерами, жесткими дисками, магнитными лентами, терминалами и многими другими.

Если событие происходит на удаленном компьютере и обнаружить его напрямую невозможно, назовем его удаленным событием. Например, Cache может получать данные от внешних web-сервисов и при определенных сочетаниях полученных значений активировать ECA-правила. Для работы с web-сервисами по протоколу HTTP из Cache Object Script можно использовать библиотеку %Net и класс %Net.HttpRequest.

4) Тип события Exception. Для обнаружения возникновения ошибочных ситуации в СУБД используется механизм обработчика ошибок (Error handler). Cache позволяет при возникновении ошибки передать управление пользовательской функции-обработчику.Для этого устанавливается значение системной переменой $ETRAP.

SET $ETRAP=»GOTO LogErrorAErrRoutine»

Переменная $ETRAP содержит код на Cache Object Script, который выполняется при возникновении ошибки. В приведенном выше примере управление передается функции LogError (которая является частью функции ErrRoutine). Функции-обработчикудоступна следующая информация:

1) Тип контекста (DO, EXCUTE или функция пользователя);

2) Номер строки в исходном тексте, где произошла ошибка;

Таблица 4 — Возможности СУБД Cache по реализации основных особенностей АБД

№ Особенность СУАБД Характеристики СУБД Cache 2009.1 Оценка

І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +

2 І Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + — —

Определение условий Для представления условия используется язык Cache Object Script, являющийся полноценным объектноориентированным языком программирования. + + +

Определение действия Для представления действия используется язык Cache Object Script, являющийся полноценным объектно-ориентированным языком программирования. + + +

1.3 Средства для управления базами правил и их эволюции Управление базами правил Централизованное хранение правил отсутствует, но информацию о правилах можно получить из описания класса. + — —

Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция класса. + + —

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

\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + — —

Поддержка режима связывания Событие связывается только с конкретным объектом + — —

Механизм проверки условий Условие имеет доступ только к текущему состоянию объекта, может обращаться к другим объектам БД. + + —

Механизм выполнения действий Возможно выполнение любого действия с базой данных (создание и удаление объектов, вызов методов и т.д.) + + +

Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. + — —

ГО CN Способы выявления сложных событий Механизм выявления сложных событий отсутствует.

CN Управление историей событий История событий отсутствует

LO CN Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию блокировки не используются. + — —

\—1 ГО Поддержка программной окружающей среды Доступны средства разработки классов (Cache Studio), которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + — —

CN ГО Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + —

Таблица 5 — Обобщенные результаты анализа возможностей СУБД по реализации абстрактной модели и

№ Особенность СУАБД Cache Progress Oracle

\—і \—і СУАБД есть просто СУБД + + + +++ + + + + + +

\—1 Поддержка модели ЕСА-правил Определение типов событий + — — + — — + — — + + —

ГО \—1 Средства для управления базами правил и их эволюции Управление базами правил + — — + — — + + + + + +

Поддержка эволюции базы правил + + — ++- + + — + + +

Возможность активировать или деактивировать правила + + + + + +

\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. + — — + — — + — — + + —

Поддержка режима связывания + — — + — — + + — + + +

Механизм проверки условий + + — +++ + + + + + +

Механизм выполнения действий + + + ++ — + + + + + +

Методы сцепления транзакций + — — +++ + — — + + —

ГО Способы выявления сложных событий — — — — — — + — —

Управление историей событий — — — ++ — — — — + + —

LO Механизмы разрешения коллизий + — — ++ — + — — + + +

\—1 ГО Поддержка программной окружающей среды + — — + — — + — —

ГО Настройка СУАБД + + — +++ + + + + + +

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

5) Тип события Transaction. Из событий управления транзакциями Cache поддерживает обнаружение только событие отката транзакции. Обнаружить событие можно с помощью функции обратного вызова %OnRollBack. Функция вызывается перед началом отката транзакции.

Откат транзакции может быть остановлен (для этого необходимо вернуть код ошибки, отличный от $$$OK). Начало транзакции может быть косвенно определено как вызов метода %Save объекта (вызов %Save автоматически начинает транзакцию). Однако этот метод не является надежным, т.к. Cache позволяет сохранить несколько объектов в одной транзакции с помощью специальных конструкций Cache Object Script (TSTART, TCOMMIT, TROLLBACK).

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

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

Что такое СУБД

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

Подробнее о СУБД
SQL и реляционные БД: почему в них важно разбираться
Наиболее популярные СУБД

Подробнее о СУБД

Основные функции СУБД:

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

Каждая СУБД основывается на какой-либо модели данных, это является одним из признаков классификации. По модели данных СУБД бывают:

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

SQL и реляционные БД: почему в них важно разбираться

Сегодня по-прежнему наиболее популярными при создании веб-приложений и сервисов остаются реляционные базы данных. Для управления реляционными базами данных используется язык SQL (Structured Query Language — структурированный язык запросов). Изначально SQL был инструментом работы пользователя с базой данных, однако со временем язык усложнился и стал скорее инструментом разработчика, чем конечного пользователя.

Наиболее популярные СУБД

Различные рейтинги самых популярных СУБД возглавляют Oracle, MySQL , Microsoft SQL Server, PostgreSQL.

MySQL

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

Кроме того, это надежная бесплатная система с простым интерфейсом и возможностью синхронизации с другими базами данных. В совокупности эти факторы позволяют использовать MySQL как крупным корпорациям, так и небольшим компаниям.

Microsoft SQL Server

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

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

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

PostgreSQL

СУБД PostgreSQL — еще одна популярная и бесплатная система. Наибольшее применение нашла для управления БД веб-сайтов и различных сервисов. Она универсальна, то есть подойдет для работы с большинством популярных платформ.

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

Oracle

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

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

XIII Международная студенческая научная конференция Студенческий научный форум — 2021

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

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

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

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

Цель настоящей работы – проклассифицировать СУБД по различным признакам.

В соответствии с поставленной целью необходимо решить следующие задачи:

– изучить теоретическую литературу по заданной теме,

– систематизировать полученный материал,

– изложить различные классификации СУБД.

1 КЛАССИФИКАЦИЯ СУБД ПО МОДЕЛИ ДАННЫХ

По модели данных СУБД можно разделить на:

Здесь и далее при описании типа СУБД имеется в виду, что данная СУБД поддерживает конкретную модель данных.

Рассмотрим каждый из перечисленных выше типов СУБД подробнее.

1.1 Иерархические СУБД

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

Иерархическая модель данных – это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней [4].

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

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

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

Рисунок 1 – Схема иерархической модели данных

Когда иерархические СУБД были на пике популярности, их достоинствами считались:

– эффективное использование памяти,

– достаточно высокая скорость выполнения простейших операция над данными,

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

– простота работы с небольшим объёмом данных [3].

Ещё при активном использовании данной модели был выявлен ряд следующих недостатков:

– при большом объёме данных медленный доступ к объектам нижних уровней,

– сложность организации неиерархических связей,

– трудность в понимании модели конечным пользователем [5].

С появлением других моделей данных были обнаружены другие существенные недостатки иерархической модели, основным из которых является её строгая ориентация на конкретные виды запросов. Это лишает пользователя возможности гибко изъяснять свои намерения при фильтрации объектов модели. Одной из первых СУБД с поддержкой иерархической модели считается Information Management System (IMS), разработанная компанией IBM [4].

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

1.2 Сетевые СУБД

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

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

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

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

Пример сетевой модели представлен на рисунке 2.

Рисунок 2 – Пример сетевой модели данных

1.3 Реляционные СУБД

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

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

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

Следует отметить, что любая таблица в реляционной БД отвечает следующим принципам:

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

– порядок следования строк и столбцов не имеет значения,

– в таблице отсутствуют одинаковые кортежи (строки с заданным набором конкретных атрибутов) и домены (значения некоторого атрибута).

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

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

Таким образом, использование первичного и вторичного ключей позволяет устанавливать связи между таблицами. Совокупность таблиц, связанных между собой, принято называть схемой данных [8].

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

Рисунок 3 – Пример реляционной модели данных

Преимуществами реляционной модели данных являются:

– легкость понимания пользователем,

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

К недостаткам модели относятся:

– высокие расходы памяти,

– относительно низкая скорость доступа к данным [2].

Первые реляционные СУБД появились в начале 80-х годов от компаний IBM , Oracle , Relation Technology Inc .

На современном этапе своего развития реляционные СУБД совершенствуются с каждым днем и предоставляют возможности решения всё более и более сложных задач. Примеры таких СУБД: MySql, PostgreSql, Visual FoxPro, Access.

1.4 Объектно-ориентированные СУБД

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

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

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

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

К ООСУБД можно отнести GemStone [10].

Пример объектно-ориентированной модели приведён на рисунке 4.

Рисунок 3 – Пример объектно-ориентированной модели данных

1.5 Объектно-реляционные СУБД

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

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

То есть объектно-реляционная СУБД предоставляет программистам возможность внедрять специальный код без перестройки всей СУБД и оставляет привычную реляционную организацию данных [6].

В качестве примеров таких СУБД можно привести DB2 и Microsoft SQL Server. Довольно часто СУБД, называемые реляционными, относятся на самом деле к объектно-реляционным [10].

2 КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ РАСПРЕДЕЛЁННОСТИ

2.1 Локальные СУБД

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

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

ПримерылокальныхСУБД : Microsoft Access, Paradox, dBase.

2.2 Распределённые СУБД

В таком типе СУБД её части могут располагаться сразу на нескольких ЭВМ. Распределённые СУБД используются для создания распределённых баз данных.

Распределённая база данных – это совокупность нескольких взаимосвязанных баз данных, которые физически распределены по различным местам, которые обмениваются данными через компьютерную сеть [7].

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

Примеры распределённых СУБД: Ingres и Oracle.

3 КЛАССИФИКАЦИЯ СУБД ПО СПОСОБУ ДОСТУПА К БД

3.1 Файл-серверные СУБД

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

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

В настоящее время файл-серверные СУБД считаются устаревшей технологией и обычно не применяются.

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

3.2 Клиент-серверные СУБД

Как сама СУБД, так и созданные с помощью неё БД располагаются на одном сервере, и доступ к БД осуществляется непосредственно. Любые пользовательские запросы обрабатываются прямо на сервере, поэтому к самому серверу предъявляются существенные требования. Достоинствами таких СУБД, по сравнению с файл-серверными, являются:

– более низкая нагрузка на локальную сеть,

– удобство централизованного управления,

– обеспечение надёжности, доступности и безопасности.

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

3.3 Встраиваемые СУБД

Такие СУБД связаны с некоторым программным продуктом и не требуют самостоятельной установки.

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

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

Примеры встраиваемыхСУБД : OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР [10].

4 КЛАССИФИКАЦИЯ СУБД ПО СТЕПЕНИ УНИВЕРСАЛЬНОСТИ

По степени универсальности СУБД принято разделять на общего назначения и специального.

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

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

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

В ходе данной работы:

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

– представлена история и теория вопроса,

– выявлены преимущества и недостатки различных типов СУБД,

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

– проведена подробная классификация СУБД.

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

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

– необходимость в совместном использовании СУБД по сети,

– необходимость встраивания СУБД в конечное приложение,

– направленность на конкретную предметную область,

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Что такое реляционная база данных?

Облако AWS

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

Важные аспекты реляционных БД

SQL (Structured Query Language) – основной интерфейс работы с реляционными базами данных. SQL стал стандартом Национального института стандартов США (ANSI) в 1986 году. Стандарт ANSI SQL поддерживается всеми популярными ядрами реляционных БД. Некоторые из ядер также включают расширения стандарта ANSI SQL, поддерживающие специфичный для этих ядер функционал. SQL используется для добавления, обновления и удаления строк данных, извлечения наборов данных для обработки транзакций и аналитических приложений, а также для управления всеми аспектами работы базы данных.

Целостность данных

Целостность данных – это полнота, точность и единообразие данных. Для поддержания целостности данных в реляционных БД используется ряд инструментов. В их число входят первичные ключи, внешние ключи, ограничения «Not NULL», «Unique», «Default» и «Check». Эти ограничения целостности позволяют применять практические правила к данным в таблицах и гарантировать точность и надежность данных. Большинство ядер БД также поддерживает интеграцию пользовательского кода, который выполняется в ответ на определенные операции в БД.

Транзакция в базе данных – это один или несколько операторов SQL, выполненных в виде последовательности операций, представляющих собой единую логическую задачу. Транзакция представляет собой неделимое действие, то есть она должна быть выполнена как единое целое и либо должна быть записана в базу данных целиком, либо не должен быть записан ни один из ее компонентов. В терминологии реляционных баз данных транзакция завершается либо действием COMMIT, либо ROLLBACK. Каждая транзакция рассматривается как внутренне связный, надежный и независимый от других транзакций элемент.

Соответствие требованиям ACID

Для соблюдения целостности данных все транзакции в БД должны соответствовать требованиям ACID, то есть быть атомарными, единообразными, изолированными и надежными.

Атомарность – это условие, при котором либо транзакция успешно выполняется целиком, либо, если какая-либо из ее частей не выполняется, вся транзакция отменяется. Единообразие – это условие, при котором данные, записываемые в базу данных в рамках транзакции, должны соответствовать всем правилам и ограничениям, включая ограничения целостности, каскады и триггеры. Изолированность необходима для контроля над согласованностью и гарантирует базовую независимость каждой транзакции. Надежность подразумевает, что все внесенные в базу данных изменения на момент успешного завершения транзакции считаются постоянными.