Программирование комплекса «Библиотека»

• Отсутствие упорядоченности кортежей.
• Отсутствие упордоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.
• Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества значений (отношения).

Реляционное исчисление.

В реляционной модели определяются два базовых механизма манипулирования данными:

• основанная на теории множеств реляционная алгебра
• основанное на математической логике реляционное исчисление.

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

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

Заметим, что порядок выполнения шагов может повлиять на эффективность выполнения запроса. Так, время выполнения приведенного выше запроса можно сократить, если поменять местами этапы. Машинное время экономится за счет того, что в операции соединения участвуют меньшие отношения.

Ограничения реляционных баз данных.

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

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

По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения. Однако, в таких приложениях как САПР (системы автоматизированного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно - структурированными объектами.

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

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

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

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

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

Первые работы, в которых отмечались эти и ряд других недостатков, появились уже в начале 80-х годов. Одна из наиболее ярких статей была опубликована в 1990 г. - Системы баз данных третьего поколения: Манифест. Вслед за первым манифестом последовали Манифест систем объектно-ориентированных баз данных. (М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник, СУБД № 4 1995) и Третий манифест (Х.Дарвин, К.Дэйт, СУБД № 1 1996).

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

2.2.4. Постреляционные СУБД.

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

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

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

Термин "объект" в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается "нечто, имеющее четко определенные границы" (определение известного американского специалиста Г.Буча). Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка - объекты класса "птицы"). Обычно класс описывается как новый тип данных, а объекты (экземпляры класса) - определенные на его основе переменных.

Объектно-ориентированная парадигма.

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

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

Структура:

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

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

Т.е. объект скрывает свою внутренню структуру, именно это свойство и называется "инкапсуляцией".

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

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

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

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

Средства манипулирования данными:

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

Подведем теперь некоторые итоги:

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

1. естественное представление данных. В реляционной модели все отношения принадлежат одному уровню, именно это осложняет преобразование иерархических связей модели "сущность-связь" в реляционную модель. ОО-модель можно рассматривать послойно, на разных уровнях абстракции.
2. имеется возможность определения новых типов данных и операций с ними.
3. В то же время, ОО-модели присущ и ряд недостатков:

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

• вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

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

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

В качестве примера рассмотрим объектно-ориентированную СУБД ObjectStore, которая обеспечивает долговременное хранение в базе данных объектов, созданных программами на языках C++ и Java. Вся работа с объектами ведется обычными средствами включающего ОО-языка. При этом СУБД как бы расширяет виртуальную память операционной системы. Происходит это следующим образом. Когда прикладная программа обращается к объекту, то ищет его по адресу в оперативной памяти. Нужная страница оперативной памяти может быть вытеснена в виртуальную память (область хранения неиспользуемых страниц оперативной памяти на диске). Если объекта с таким адресом в виртуальной памяти не существует, то операционная система генерирует ошибку. СУБД эту ошибку перехватывает и извлекает объект из базы данных.

ObjectStore поддерживает транзакции (в данный момент времени может существовать только одна транзакция), допускает методы доступа: хеш-таблица для несортированных данных и B-дерево для сортированных, также возможно использование SQL.

3. Практическая реализация

Целью дипломного проекта является создание программы, которая облегчила бы учет книг, журналов, отчетов и статей, находящиеся на хранении в библиотеке НОУ «ОНУТЦ ОАО «Газпром». Автоматизация данного процесса облегчит не только работу библиотекаря, но и всех сотрудников организации. Этому способствует интерфейс модуля «Библиотекарь», в котором общение с базой данных и с самими данными проводится в удобном виде, каждое поле БД отдельно и доступно к редактированию. Одним из средств быстрой работы с приложением является поиск, а также отдельное окно расширенного поиска, в котором поиск можно осуществлять по всем полям базы данных. Это очень удобно, если в библиотеке находится много книг одного и того же автора или если несколько книг имеют одно и тоже название. Данный проект был поручен нам во время прохождения практики в НОУ «ОНУТЦ ОАО «Газпром», однако в связи с недостатком общего времени практики ПК «Библиотека» не была закончена. Тем не менее, стартовый функционал ПК работает. За основу была взята БД Firebird версии 2.1, а в качестве языка программирования C# (Си шарп). В будущем программа будет дописана, а также будет реализован модуль «Читатель», который будет представлять собой Веб-интерфейс, это еще больше облегчит доступ работников ОНУТЦ к библиотеке, т.к. в любой момент можно будет узнать, если эта книга в библиотеке или отсутствует. Узнать информацию по литературе и ее наличию можно будет воспользовавшись любым интернет браузером просто зайдя на страницу библиотека ОНУТЦ на сайте. Такой тип приложения позволить сэкономить большое количество времени.

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

3.1. Пояснения к техническому заданию.

Разберем основные моменты:

• Модуль «Библиотекарь» – это приложение Windows, основная часть программного комплекса, где происходит заполнение базы данных карточками литературы. Также в этом модуле заносится информация о сотрудниках. В качестве разработки данного модуля использовалась среда Visual Studio 2010, в частности С#. В качестве базы данных использовался Firebird версии 2.1. В качестве редактора базы данных (временно использовался для тестирования содержимого базы данных и проверки корректности работы приложения) был выбран IBExpert.
• Модуль «Читатель» – это серверное приложение с Веб-интерфейсом, предназначенным для обеспечения сотрудникам ОНУТЦ доступа к базе данных библиотеки. В данном модуле сотрудники могут найти книгу, используя поиск (по названию книги) или расширенный поиск (по всем или определенным полям), а также неотходя от рабочего места проверить статус книги (в библиотеке, или на руках). В качестве средства разработки использовались языки php, HTML, JavaScript. Также как и «Библиотекарь» этот модуль будет подключен к базе данных.
• Карточка литературы (карточка книги) – это запись в базе данных содержащая информацию о книге. Это основной элемент библиотеки, над которым будут проводиться все действия.
• Технические требования – это рекомендуемые параметры персонального компьютера на который будет установлено данное приложение. Для работы модулей «Библиотекарь» и «Читатель» необходимо: IBM PC-совместимый компьютер с тактовой частотой процессора не менее 2 ГГц (2 000 МГц), оперативная память не менее 1 Гбайт. На компьютере должна быть установлена операционная система Windows ME/2000/XP/Vista/Win 7. А также ПК должен иметь интернет браузер (IE, Opera, Firefox, Google Chrome и т.п.). Серверное приложение должно быть установлена на серверный компьютер с установленными на ней Firebird 2.1 и Apache, а также работать под управление операционный системы Windows Server или Ubuntu.