Система управления базами данных

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

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

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

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

Цель курсовой работы решается через задачи:

- изучение сущности баз данных;

- изучение понятия табличные базы данных

- изучение иерархических баз данных;

- изучение систем управления базами данных;

- изучение свойств программы MS Access.



1. СУЩНОСТЬ, ПОНЯТИЕ, ВИДЫ БАЗ ДАННЫХ

1.1 Свойства СУБД

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

- Живучесть (Persistence): объекты могут пережить завершение отдельных сессий использующих их программ, а также сбои компьютера.

- Программируемая структура (Programmable structure): система рассматривает объекты как структурированные данные, связанные некоторыми точно определенными отношениями. Пользователи системы могут сгруппировать множество объектов в некоторую совокупность, называемую базой данных, и определить структуру конкретной БД.

- Произвольный размер (Arbitrary size): нет никаких заранее заданных ограничений (вытекающих, например, из размера основной памяти компьютера или ограниченности его адресного пространства) на число объектов в базе данных.

- Контроль доступа (Access control): пользователь может «владеть» объектами и определять права доступа к ним.

- Запросы, основанные на свойствах (Property-based querying): имеются механизмы, позволяющие пользователям и программам находить объекты в базе данных, задавая их абстрактные свойства, а не местоположение.

- Ограничения целостности (Integrity constraints): пользователи могут налагать некоторые семантические ограничения на объекты и заставлять базу данных поддерживать их выполнение.

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

- Разделение (Sharing): несколько пользователей или программ могут одновременно получать доступ к базе данных.

- Закрытие (Locking): пользователи или программы могут получать исключающий доступ (только для чтения, для чтения и записи) к одному или нескольким объектам.

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

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

1.2 Сравнение ООБД и РСУБД

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

структура данных регулярна: все объекты данного типа имеют одинаковое число и типы компонентов;

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

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

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

Свойство (3) исключает многие приложения, связанные с мультимедиа, CAD/CAM и обработкой изображений, в которых некоторые элементы данных, такие как битовые образы изображений, имеют сильно различающиеся и иногда очень большие размеры. Этому также мешает требование, чтобы отношения находились в «нормальной форме», налагаемое существующими коммерческими системами, из-за которого один объект не может ссылаться на другой.

Первой формализованной и общепризнанной моделью данных была реляционная модель Кодда [1]. В этой модели, как и во всех следующих, выделялись три аспекта - структурный, целостный и мани-пуляционный. Структуры данных в реляционной модели основываются на плоских нормализованных отношениях, ограничения целостности выражаются с помощью средств логики первого порядка и, наконец, манипулирование данными осуществляется на основе реляционной алгебры или равносильного ей реляционного исчисления. Как отмечают многие исследователи, своим успехом реляционная модель данных во многом обязана тому, что опиралась на строгий математический аппарат теории множеств, отношений и логики первого порядка. Разработчики любой конкретной реляционной системы считали своим долгом показать соответствие своей конкретной модели данных общей реляционной модели, которая выступала в качестве меры «реляционности» системы.

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

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

1.3 Объектные расширения реляционных СУБД. Язык SQL-3

Попытки совместить средства манипулирования данными реляционной модели и способы описания внешнего мира объектно-ориентированной модели получили развитие в языке SQL-3 [7]. Здесь рассматриваются только предлагаемые способы определения данных.

Разработчики SQL-3 считают, что характеристики объекта определяются описанием строки таблицы. Поэтому, вводится специальная возможность описания нового типа данных:

Create type Address ( number char (6), street char (30), aptno integer, city char (30), state char (2), zip integer;

На основе нового типа могут быть определены таблицы, например:

Create table Addresses of Address;

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

Oreate table People of new type Person ( name char (30), address Address, birthdate date,

) ;

Наследование определяется с помощью фразы under.

Create type Employee under Person ( empno char(10), dept ref(Department)

) ;

Здесь атрибут dept является ссылкой на объект, хранящийся в таблице Department. Т.е. в понятиях реляционной модели в этом столбце должен быть записан внешний ключ, указывающий на одну из строк таблицы Department. На самом деле, в SQL-3 предполагается, что каждый объект имеет уникальный идентификатор - OID, именно он используется при создании ссылок на объекты.

Также в операторе CREATE TABLE можно определить и методы доступа к вновь созданным типам данных:

Create table People of new type Person ( name char(30), address Address, birthdate date

function age(:p ref(Person)) return

date;

begin

current_age:=:p.birthdate-current_date;

return current_age; end;

);

В этом примере задана функция age, которая вычисляет текущий возраст объекта типа Person, хранимого в таблице People. К данной функции можно обращаться из оператора SELECT.



2. ОСНОВНЫЕ ПОНЯТИЯ О БАЗАХ ДАННЫХ MS ACCESS

2.1 Краткая характеристика MS Access

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

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

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

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

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

Особенности MS Access, отличающиеся от представления об «идеальной» реляционной СУБД.

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

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

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

Однако при известных недостатках MS Access обладает большим количеством преимуществ по сравнению с системами подобного класса.

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

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

Поскольку VBA является единственным средством для выполнения многих стандартных задач в Access (работа с переменными, построение команд SQL во время работы программы, обработка ошибок, использование Windows API и т. д.), для создания более-менее сложных приложений необходимо его знание и знание объектной модели MS Access.

2.2 Обеспечение сохраняемости объектов

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

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

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

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

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

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

Отображение свойств. Свойство объекта - это либо физический атрибут (например, Name - строка символов для хранения имени объекта), либо виртуальный, реализованный через операцию (например, Redraw, которая перерисовывает объект). Атрибуты указываются в столбцах реляционной таблицы, при этом необходимо помнить, что не все атрибуты объекта требуется хранить, некоторые из них вычисляются приложением. Объект может иметь атрибуты, которые в свою очередь также являются объектами, эта ассоциация между двумя классами также должна быть отражена в базе данных. В результате получаем рекурсивное определение - атрибут может быть отображен на ноль или более столбцов.

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

Отображение структур наследования. Реляционные базы данных не поддерживают наследования, поэтому приходится проецировать структуры наследования в схеме объектов на схему данных. Существуют следующие подходы для реализации такого отображения [2, 3, 4]:

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

Отображение каждого конкретного класса на свою собственную таблицу. Каждая таблица включает как новые атрибуты своего класса, так и унаследованные от предков атрибуты. Таблицы для абстрактных классов не создаются.

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

4) Отображение информации о классе на несколько таблиц.

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

Отображение связей между объектами. Связи в объектной схеме реализуются при помощи комбинации ссылок на объекты и операций. Когда кардинальность связи равна единице (0..1 или 1), связь реализуется ссылкой на объект и операциями установки и получения значений (setter и getter). Когда кардинальность определена как «много» (N, 0..оо, 1.. оо), связь реализуется через коллекцию атрибутов, например, через массив или множество, и через операции, позволяющие манипулировать ими. Связи в реляционной базе данных реализуются через использование внешних ключей. Следующая стратегия может значительно облегчить процесс объектно-реляционного отображения. Во-первых, необходимо предпочитать создавать ключи, состоящие из одного атрибута, и, во-вторых, лучше использовать суррогатные ключи, что всегда обеспечит совместимость типов ключевых атрибутов.

Рассмотрим связь один к одному между объектами Сотрудник и Должность (сотрудник занимает одну должность или должность занята одним сотрудником). Рассмотрим логику извлечения объекта из базы с использованием связей, направление связи будет от Должности к Сотруднику:

объект Должность читается в память, срабатывает связь «занята»;

значение атрибута Идентификатор Сотрудника таблицы Должность используется для того, чтобы определить единственного сотрудника и извлечь его в память;

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

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

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

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

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

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

К этим принципам относятся поддержка сложных объектов (complex objects), идентификации объектов (object identity), инкапсуляции (encapsulation), типизации и классификации (types and classes), переопределения (override), перегрузки (overloading) и позднего связывания (late binding), полноты манипулирования (computational completeness), расширяемости (extensibility), сохранения (persistence), использования вторичных хранилищ (secondary storage management), обеспечения совместного параллельного доступа (concurrency), возможностей восстановления (recovery), реализации динамических запросов (ad hoc query facility).

3. ОСОБЕННОСТИ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

3.1 Архитектура ODMG

ODMG (Object Data Management Group) - консорциум поставщиков ООБД и других заинтересованных организаций, созданный в 1991 году. Его задачей является разработка стандарта на хранение объектов в базах данных. В настоящее время опубликована третья версия стандарта, которую так и называют ODMG 3.0 [8]. Рассмотрим кратко основные положения этого документа.

В этой архитектуре определяются способ хранения данных и разные виды пользовательского доступа к этому «хранилищу данных». Единое хранилище данных доступно из языка определения данных, языка запросов и ряда языков манипулирования данными. ODL означает Object Definition Language (язык определения объектов), OQL - Object Query Language (язык объектных запросов) и OML - Object Manipulation Language (язык манипулирования объектами).

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

Основные компоненты архитектуры:

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

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

- Язык объектных запросов (ODL ). Язык имеет синтаксис, похожий на синтаксис языка SQL, но опирается на семантику объектной модели ODMG . В стандарте допускается прямое использование OQL и его встраивание в один из языков категории OML .

- Языки манипулирования объектами (OML). Для программирования реализаций операций и приложений требуется наличие объектно-ориентированного языка программирования. OML представляет собой интегрирование языка программирования с моделью ODMG; это интегрирование производится за счет определенных в стандарте правил языкового связывания (language binding). Дело в том, что в самих языках программирования, естественно, не поддерживается стабильность объектов. Чтобы разрешить программам на этих языках обращаться к хранимым данным, языки должны быть расширены дополнительными конструкциями или библиотечными элементами. Эту возможность и обеспечивает языковое связывание. В одной ООСУБД могут поддерживаться несколько OML . В стандарте ODMG -2 были специфицированы правила связывания для языков C ++ и Smalltalk . Практически завершена работа над спецификациями правил связывания для языка Java.

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

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

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

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

- гео-информационные системы;

- системы управления движущимися объектами;

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

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

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

Выбор модели активных правил зависит от особенностей предметной области и логики выполнения активных правил. Например, применительно к техническим системам контроля и управления предпочтительней именно расширенная модель SECA-правил. Тем не менее, была разработана интегрированная модель активной базы данных [8], объединяющая классическую и расширенную модель активных правил (рис. 1), что позволяет разработчикам АБД использовать как ECA-правила, так и SECA-правила для описания активностей. Реализованы алгоритмы и программные средства преобразования ECA-правил в SECA-правила и обратно.

Интегрированная модель активных правил содержит следующие классы:

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

- State - класс состояний информационных объектов активной базы данных;

- Event - класс событий активной базы данных, на которые будет реагировать СУАБД;

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

- ECA - класс ECA-правил активной базы данных;

- SECA - класс SECA-правил активной базы данных.

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

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

Кроме того, применение монолитной СУАБД, может «утяжелить» информационную систему. В СУАБД, в которых применена многоуровневая архитектура, и слой активности находится «поверх» стандартной СУБД, активные компоненты менее связаны и ограничены относительно целевой СУБД. [22]

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

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

Кроме того, в настоящее время реализовано серверное программное обеспечения СУАБД для таких целевых СУБД, как Microsoft SQL Server 2008, Oracle 11g, Cache 2009.1, Postgre SQL 8.4 [17].

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

3.3 Концептуальные особенности систем управления активными базами данных

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

1) возможности СУАБД по определению правил;

2) возможности СУАБД по выполнению правил;

3) особенности реализации и применения СУАБД.

Рассмотрим концептуальные особенности СУАБД в пределах каждой группы.

1 Определение правил. Основные возможности СУАБД по определению правил сведены в таблице 1.

Таблица 1- Группа особенностей СУАБД «Определение правил»

№ п/п	Особенность СУАБД	Описание
1.1	СУАБД есть просто СУБД	Наличие функциональных возможностей, характерных для «пассивных» СУБД
1.2	Поддержка модели правил	Определение типов событий	Наличие инструментов для определения различных типов событий, как простых, так и сложных (состоящих из нескольких простых или сложных событий), отслеживания возникновения событий и определения дополнительных параметров для событий
		Определение условий	Наличие инструментов для определения условие выполнения правил
		Определение действия	Под действие понимается реакция на событие. Наличие инструментов для определения для определения действий, как возможных реакций на наступление событий
1.3	Наличие средств управления базами правил и их эволюции	Управление базами правил	База правил, содержащая определенный набор правил, должна быть представлена в виде метаинформации и должна быть доступна пользователям и приложениям
		Поддержка эволюции баз правил	Возможность изменения событий, условий, действий в существующих правилах
		Возможность активировать или деактивировать правила	Одно или несколько правил могут быть деактивированы, и не будут учитываться при возникновении событий. И наоборот, одно или несколько деактивированных правил могут быть активированы, после чего они станут доступны при обработке событий

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

В АБД могут присутствовать различные типы событий. Например, события «до» и события «после». Событие «до» характеризуется тем, что сигнал о нем подается до, того как само событие начнет выполняться.

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

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

Определение условий. Условие определяет, в каком состоянии должны находиться критические части база данных, чтобы выполнить действие из соответствующего правила. Условие может быть простым предикатом SQL-запросов, например, «where» или же запросом к базе данных, возвращающим пустое ли непустое множество записей. Условие выполняется, если принимает значение истины или выбранное множество записей является непустым.

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

браузер правил;

конструктор правил;

анализатор базы правил;

отладчик правил;

средство трассировки правил;

сервисные средства.

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

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

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

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

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



ЗАКЛЮЧЕНИЕ

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

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

Области применения Microsoft Access можно выделить следующие структуры: применение в малом и среднем бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах, кадрах и т.п.); при разработке программ и хранилищ данных на заказ (разработка внутриотраслевых приложений, разработка межотраслевых приложений, автоматизация некоторых функций предприятий); в крупных корпорациях (приложения для рабочих групп, системы обработки информации, документооборот); в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.); в качестве средства хранения данных, которое используется в других приложениях. Например, один из лидеров среди геоинформационных систем - ArcGis, создает и использует файлы MDB в качестве «персональной геобазы», то есть хранилища данных, где не требуется одновременное многопользовательское редактирование.

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

Модель знаний активной базы данных определяет принципы построения активных правилах и базируется на таких элементах, как: состояние, событие, условие, действие (State, Event, Condition, Action). Модель выполнения описывает обработку правил во время выполнения, и определяет режим связывания условий и действий, масштаб транзакций, политику сетевого эффекта, цикловая политика, приоритеты, планирование активности, управление ошибками и т. д.

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

архитектура object объектный access

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Акулов, О. А. Информатика: базовый курс: учебник для вузов / О. А. Акулов, Н. В. Медведев. - М.: Омега-Л, 2009.

2. Волков, В. Н.Проектирование информационных систем [Электронный ресурс]: лабораторный практикум / В. Н. Волков, А. И. Фролов , ОрелГТУ, Каф. "ИС". - Орел : Изд-во ОрелГТУ , 2008.- Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана.

3. Балабанов,И.Т. Электронная коммерция: учеб. пособие / И.Т.Балабанов.- СПб.: Питер, 2008.

4. Батищева, А. В. Основы организации и управления в электронном бизнесе [Электронный ресурс] : учеб. пособие для вузов / А. В. Батищев, Л. И. Старикова . - Орел : Изд-во ОрелГТУ , 2008. - Режим доступа: http: elib.ostu.ru, свободный. - Загл. с экрана.

5. Батищев, А. В.Основы организации и управления в электронном бизнесе [Электронный ресурс] : учеб. пособие для вузов / А. В. Батищев, Л. И. Старикова . - Орел : Изд-во ОрелГТУ, 2008. - Режим доступа: http: elib.ostu.ru, свободный. - Загл. с экрана.

6. Информатика: учебник для вузов / под ред. Н. В. Марковой. - М.: Финансы и статистика, 2007.

7. Информатика: базовый курс: учебник для втузов / под ред. С. В. Симоновича. - СПб.: Питер, 2007.

8. Информатика. Общий курс: учебник для вузов / А. Н. Гуда [и др.]. - М.: Дашков и Ко; Ростов-н/Д: Наука-Спектр, 2009.

9. Информатика. В 3 ч. Ч. 3. Методы, модели и средства обработки графической информации [Электронный ресурс]: учеб. для вузов / А. П. Фисун [и др.]. - Орел : Изд-во ОрелГТУ ; Орел : Изд-во ОГУ , 2010 .-Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана.

10. Информатика. В 3 ч. Ч. 2. Организационные и технико-экономические основы [Электронный ресурс] : учеб. для вузов / А. П. Фисун [и др.]. - Орел : Изд-во ОрелГТУ ; Орел : Изд-во ОГУ , 2010 .-Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана.

11. Информатика. В 3 ч. Ч. 1. Методологические и технологические основы [Электронный ресурс] : учеб. для вузов / А. П. Фисун [и др.]. - Орел : Изд-во ОрелГТУ ; Орел : Изд-во ОГУ, 2010 .-Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана. Информатика и информационные технологии: учеб. пособие / Ю. Д. Романова [и др.]. - М.: Эксмо, 2008.

12. Константинов, Л. В. Информатика: конспект лекций / Л. В. Константинов. Ростов-н/Д: Феникс, 2009.

13. Киреева, Г. И., Курушин В. Д., Мосягин А. Б., Нечаев Д. Ю., Чекмарев Ю. В. Основы информационных технологий: учеб. пособие. - М.: ДМК Пресс, 2010. - 272 с.: ил.

14. Компьютерное моделирование менеджмента: учебник / А. Ф. Горшков [и др.]; под ред. Н. П. Тихомирова. - М.: Экзамен, 2007.

15. Михеева, Е. В. Информационные технологии в профессиональной деятельности : учеб. пособие / Е. В. Михеева. - М.: Велби; Проспект, 2007.

16. Озаренко, О. В. Проектирование распределенных информационных систем [Электронный ресурс]: учеб. пособие для высшего проф. образования О. В. Озаренко, Д. И. Федоров. - Орел : Изд-во ФГБОУ ВПО осуниверситет - УНПК", 2011. - Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана

17. Амелина, О.В. Базы данных. Объектно-ориентированные базы данных в информационных системах: конспект лекций для высшего профессионального образования / О.В. Амелина. - Орел: ФГОУ ВПО «Госуниверситет-УНПК», 2011. - 48 с.

18. Попов,В.М. Глобальный бизнес и информационные технологии / В.М.Попов, Р.А.Маршавин, С.И.Ляпунов; под ред. В.М.Попова.- М.: Финансы и статистика, 2009.

19. Румянцева, Е. Л. Информационные технологии: учеб. пособие / Е. Л. Румянцева, В. В. Слюсарь. - М.: ФОРУМ - ИНФРА-М, 2007.

20. Угринович, Н.Д. Информатика и информационные технологии: учебник для 10-11 классов / Н.Д. Угринович. - М.:БИНОМ. Лаборатория знаний, 2013. - 512 с.: ил.

21. Фролов, А. И. Основы анализа алгоритмов [Электронный ресурс]: учеб. пособие Алексей Иванович Фролов. - Орел : Изд-во ОрелГТУ , 2008 .-Режим доступа: http://elib.ostu.ru, свободный. - Загл. с экрана.

22. Хлебников, А. А. Информационные системы в экономике / А. А. Хлебников. - Ростов-н/Д, 2007.

23. Яшин, В. Н. Информатика: аппаратные средства персонального компьютера: учеб. пособие для вузов / В. Н. Яшин. - М.: ИНФРА-М, 2008.

Размещено на Allbest.ru