Проектирование и разработка БД Oracle для информатизации объектов культуры

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

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

Содержание

Введение

1. Выбор модели БД

1.1 Исходные требования к проектируемой БД

1.2 Обзор основных моделей данных современных БД

1.2.1 Иерархические базы данных

1.2.2 Сетевая СУБД

1.2.3 Многомерная СУБД

1.2.4 Реляционная модель баз данных

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

1.3 Реализация Объектно-ориентированного проектирования в реляционных БД

1.3.1 Объекты как таблицы. Модель ROT

1.3.2 Модификация ROT с учетом наследования

1.3.3 Модель А. Тенцера “База-данных-хранилище объектов”

1.3.4 Модификация модели Тенцера. Модель Entity-Attribute-Value

1.3.5 Сравнительный анализ методов реализации объектно-ориентированного проектирования в реляционных БД

1.3.6 Итоговый анализ эффективности методов объектно-ориентированного проектирования в реляционных СУБД

1.4 Обоснование выбора Entity-Attribute-Value в качестве метода проектирования Базы Данных

2. Разработка БД

2.1 Общая архитектура БД информационной системы

2.2 Модель системных данных

2.2.1 Общая архитектура системных объектов БД

2.2.2 Описание процесса генерации таблиц

2.2.3 Реализация функциональности добавления, редактирования и удаления объектов

2.2.4 Реализация функциональности тщательного контроля доступа на уровне объектов

2.2.5 Реализация аудита на изменение объектов

2.2.6 Реализация механизма поиска объектов

2.3 Модель пользовательских данных

2.3.1 Общая архитектура пользовательских объектов БД

2.3.2 ER-диаграмма фотодокументов архива

2.3.3 ER-диаграмма фонодокументов архива

2.3.4 ER-диаграмма остальных пользовательских объектов

2.3.5 Представления пользователя приложения

3. Апробация функционирования БД

3.1 Описание работы БД как основной части информационной системы

3.2 Тестовые примеры (test cases)

3.3 Сводная таблица тестирования (test log)

Заключение

Приложение 1. Листинги пакетов

Листинг пакета DATAMODIFICATION

Листинг пакета GENERATETABLES

Листинг пакета SEARCHDATA

Листинг пакета SECURITYDATA

Приложение 2. Расширенный список тестовых примеров

Список использованной литературы

Введение

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

В процессе разработки и внедрения системы я столкнулся с проблемой разграничения прав доступа для разных пользователей. Была предложена система разграничения прав пользователей на основе пакета SecurityData. Этот пакет, в зависимости от контекста подключения, предоставляет пользователю права владельца объекта или по умолчанию. Это важно, т.к. права устанавливаются динамически и их легко можно менять в процессе работы системы. Кроме того, нужно отметить, что в БД Oracle существует встроенный пакет DBMS_RLS в рамках реализации Fine Grained Access Control(FGAC), который осуществляет политику прав доступа на объекты. FGAC начиная с Oracle 8i позволяет во время выполнения динамически добавлять условие (конструкцию WHERE) ко всем запросам, обращенным к таблице или представлению баз данных. Можно проверить, кто выполнял запрос, с какого терминала и когда он выполнялся, а затем создать условие на основе данной информации. Однако средства тщательного контроля доступа доступны только в редакциях Enterprise и Personal Edition; в Standard Edition эти примеры не работают. На данный проект разработчики обладают лицензией на Oracle 10 Standart Edition, соответственно пришлось разрабатывать пакет SecurityData.

Любая информационная система не может состоять только из базы данных, в ней должен быть еще и интуитивно-понятный GUI-интерфейс. Данный интерфейс разрабатывался на языке Java c использованием различных J2EE фреймворков. Этот выбор сделан, потому что язык программирования Java - небольшая, простая для изучения система, оснащённая всесторонне расширяющимся набором API. Разработчики могут «написав однажды, запускать всюду», что даёт языку Java огромное преимущество перед другими языками на рынке. Кроме того, программы на Java на всех операционных системах при компиляции преобразуются к одному и тому же двоичному формату. Выигрыш по сравнению с ситуацией, когда для установки программы на нескольких платформах требуется писать и компилировать код отдельно для каждой платформы, очевиден. Программист может работать над приложением под одной платформой, сокращая при этом время и стоимость разработки, и быть уверенным, что его код будет работать везде. Возможность «написав однажды, запускать всюду», для многих программистов является достаточной причиной для перехода к языку Java от таких языков как C или С++, работоспособность приложений на которых зависит от платформы и, также, приложения являются «несетевыми». В дополнение к этому, возможно создание приложений, многократно использующих общедоступные объекты, что ещё более уменьшает стоимость разработок и позволяет разработчикам концентрировать свои усилия только на создании чего-то нового. Java хороша в основном мощными библиотеками, что в значительной степени избавляет разработчика от написания велосипедов. Ну и автоматическое управление памятью позволяет сосредоточиться на реализации самой задачи. Многие библиотеки, как из стандартной поставки, так и сторонних производителей проверены временем и продолжают совершенствоваться. Кроме того, нельзя не забывать что большинство библиотек и фреймворков свободных в доступе и бесплатны. Более того эти библиотеки, как правило, open-source. Также в Java наблюдается ориентация на Internet-задачи, сетевые распределенные приложения, что как раз и нужно при разработке информационной системы для базы данных разрабатываемой в работе.

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

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

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

1. Выбор модели БД

1.1 Исходные требования к проектируемой БД

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

БД должна обеспечивать:

1. Поддержку модификацию схемы.

2. СУБД: Oracle.Версия - 10.2.0.4 Standard Edition.

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

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

5. Поддержку аудита изменения и удаления всех объектов в СУБД.

6. Поддержку логирования изменения и удаления значений атрибутов объектов.

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

8. Генерацию представлений для клиентского приложения.

9. Генерацию XML документов для клиентского приложения.

10. Механизма поиска, как по объектам, так и по атрибутам объекта.

11. Поддержку работы информационной системы на ОС Solaris Operating System (x86-64).

12. Поддержку хранения в БД фото и аудиодокументов.

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

Таблица 1.1. Таблица исходных требований.

№ требования	приоритет	Планируемые трудозатраты, дней
1	1	-
2	1	-
3	2	2
4	4	2
5	3	2
6	3	2
7	3	4
8	2	7
9	2	7
10	2	7
11	1	-
12	1	7

Кратко прокомментирую список исходных требований:

1. БД должна поддерживать модификацию схемы.

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

2. СУБД: Oracle.Версия - 10.2.0.4 Standard Edition.

На данный момент разработчики БД в рамках проекта ограничены лицензией на СУБД Oracle Standard Edition.

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

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

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

В БД Oracle существует встроенный пакет DBMS_RLS в рамках реализации Fine Grained Access Control(FGAC), который осуществляет политику прав доступа на объекты. FGAC начиная с Oracle 8i позволяет во время выполнения динамически добавлять условие (конструкцию WHERE) ко всем запросам, обращенным к таблице или представлению баз данных. Можно проверить, кто выполнял запрос, с какого терминала и когда он выполнялся, а затем создать условие на основе данной информации. Однако средства тщательного контроля доступа доступны только в редакциях Enterprise и Personal Edition; в Standard Edition эти примеры не работают. Необходимо разработать пакет, который реализует политику тщательного контроля доступа (FGAC) на СУБД Oracle Standard Edition.

8. Генерация представлений для клиентского приложения.

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

9. Генерация XML документов для клиентского приложения.

Пользовательскому GUI-интерфейсу для динамического построения списков данных нужно возвращать динамически генерируемые XML-документы для их последующего вывода в клиентском приложении.

1.2 Обзор основных моделей данных современных БД

1.2.1 Иерархические базы данных

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

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

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

В этой модели запрос, направленный вниз по иерархии, прост (например: какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ). Также, трудно представить неиерархические данные при использовании этой модели.

Иерархической базой данных является файловая система, состоящая из корневой директории, в которой имеется иерархия поддиректорий и файлов.

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

1.2.2 Сетевая СУБД

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

1.2.3 Многомерная СУБД

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

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

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

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

1.2.4 Реляционная модель баз данных

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

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

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

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

1. Неограниченный набор скалярных типов (включая, в частности, логический тип или истинностное значение).

2. Генератор типов отношений и соответствующая интерпретация для сгенерированных типов отношений.

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

4. Операция реляционного присваивания для присваивания реляционных значений указанным переменным отношения.

5. Неограниченный набор общих реляционных операторов (реляционная алгебра) для получения значений отношений из других значений отношений.

Вполне очевидно, что реляционная модель -- это нечто большее, чем просто "таблицы плюс операции сокращения, проекции и соединения", хотя ее неформально довольно часто характеризуют именно таким образом[10].

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

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

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

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

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

Как отмечают многие исследователи и разработчики, объектно-ориентированная система БД представляет собой объединение системы программирования и СУБД (альтернативная, но не более проясняющая суть дела точка зрения состоит в том, что объектно-ориентированная СУБД - это СУБД, основанная на объектно-ориентированной модели данных) [11].

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

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

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

1.3 Реализация Объектно-ориентированного проектирования в реляционных БД

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

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

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

В качестве примера реализации анализируемых в [3] подходов рассмотрим справочную информационную систему «Электронный каталог» книжного магазина. В основу положена база данных реального интернет-магазина. Полное описание структуры представлено в виде диаграммы классов предметной области (рис. 1.1).

Рис. 1.1. Диаграмма классов предметной области.

База данных содержит информацию о 101 087 экземплярах товара, распределенных по 588 разделам, в том числе - 84 287 книг, 6 793 периодических изданий, 10 007 наименований кассет. База данных также содержит информацию о 5 243 издательствах и 42 857 авторах книг.

Основные измерения в [3] касались следующих операций:

- открытия всей базы данных (запуск программы);

- выборки всех данных по одному объекту «Книга» (максимальное количество атрибутов среди всех товаров);

- выборки всех данных по одному объекту «Кассета» (минимальное количество атрибутов среди всех товаров);

- выборки объекта-контейнера (справочника всех товаров со всеми их атрибутами);

- вычисление общей стоимости товаров, добавленных в корзину (взято 7 наименований с различным количеством);

- добавления нового объекта «Книга»;

- изменения данных объекта «Книга».

Сразу оговорим, что независимо от подхода существует необходимость в поддержке уникальных идентификаторов («id») каждого объекта, по крайней мере - в ветке с корнем «Товар».

1.3.1 Объекты как таблицы. Модель ROT

Первым из методов реализации объектно-ориентированного проектирования в реляционных БД рассмотрим подход, известный под названием Representing Objects as Tables (объекты как таблицы) [2] - ROT. Данный подход является наиболее «естественным» для реляционных баз данных. Суть его заключается в том, что каждому классу предметной области ставится в соответствие одна таблица реляционной базы данных с соответствующими атрибутами. Связи реализуются по соответствующим правилам проектирования реляционных баз данных. При этом таблицы для абстрактных классов не создаются, а атрибуты классов-предков присутствуют и в таблицах для классов-потомков.

Реализуемость: подход удобен для быстрой разработки программ, так как все операции над базой данных легко реализуются стандартными конструкциями SQL. Гибкость: очень низкая, практически любые изменения в структуре базы данных неизбежно приводят к необходимости исправления исходного кода. Особенности: нет необходимости в поддержке уникальных идентификаторов в пространстве всей базы данных, в принципе, можно обойтись даже без уникальных идентификаторов ветки «Товар». Объем базы данных и время выполнения почти всех операций - минимальные среди всех рассмотренных подходов [3].

1.3.2 Модификация ROT с учетом наследования

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

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

Реализуемость: данный подход в реализации немного сложнее предыдущего, большинство операций также реализуются заранее подготовленными запросами SQL. Гибкость: выше, чем у модели ROT, однако большинство изменений в структуре базы данных также требуют исправления исходного кода программы. Объем базы данных и время выполнения операций - чуть больше, чем у модели ROT [3].

1.3.3 Модель А. Тенцера “База-данных-хранилище объектов”

Главной идеей является неизменность схемы базы данных: по сути дела, предложенная в работе [3] схема является универсальной и готовой к использованию в любых объектно-ориентированных приложениях. К тому же заранее определена универсальная реализация методов материализации и дематериализации объектов.

Во-первых, описание свойств классов и связей между ними не дублируется у наследников, а восстанавливается благодаря зависимости Id -ParentId.

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

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

Рис. 1.2. Представление атрибута связи в виде ассоциативного класса

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



Рис. 1.3. Представление трехсторонней связи в виде совокупности бинарных отношений

Реализуемость: для реализации в программе данной модели необходимо, в первую очередь, реализовать подсистему управления данными, которая «на лету» собирает объекты. Подход применим при долговременной разработке либо при наличии уже реализованной подсистемы управления данными. Гибкость: высокая, практически все изменения в предметной области требуют внесения исправлений на уровне данных (конфигурирования) и не влияют на исходный код. Особенности - для универсальности программы имеется необходимость поддержки уникального идентификатора в пространстве всей базы данных. Разделение таблиц для атрибутов по типам приводит к необходимости выборки или поиска по всем таким таблицам. В таблицах такой базы данных очень удобно строить списки элементов (справочники). Объем базы данных и время выполнения операций - достаточно высокие, в большинстве тестов - максимальные [3].

1.3.4 Модификация модели Тенцера. Модель Entity-Attribute-Value

Рассмотрим возможную модификацию модели Тенцера. Внесенные изменения, с одной стороны, вызваны обобщением подхода: описание атрибутов всех объектов производится в одной таблице Attributes. Хранение значений всех атрибутов объектов производится в пределах одной таблицы. При этом возникают естественные проблемы, связанные с увеличением объема таких данных. Однако объем в данном случае является ценой за универсальность подхода.

С другой стороны, введение таблицы Containers продиктовано соображениями, вытекающими из практического опыта работы. Дело в том, что наиболее часто встречающимся видом ассоциации (кроме наследования) между классами является агрегация. Например, подсистема нормативно-справочной информации любой информационной системы обязательно будет содержать такой вид связи [4].

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

На рис. 1.4 представлена схема базы данных для предлагаемой модели.

Рис. 1.4. Схема базы данных модифицированной модели Тенцера.

Таблица Classes содержит описание классов системы. Атрибут Id - уникальный идентификатор, Parent_Id - ссылка на Id предка в этой же таблице, Caption - короткое (возможно, англоязычное - для исходного кода программы) название класса, Description - подробное описание класса.

Таблица Attributes содержит описание атрибутов классов. Id - уникальный идентификатор атрибута, Class_Id - ссылка на Id класса (в таблице Classes), к которому относится атрибут, Caption и Description - аналогично предыдущему. Для классов-наследников описание атрибутов не повторяется. Таким образом, для материализации описания класса необходимо восстановить всю структуру наследования «вверх» и выбрать описания всех атрибутов классов этого поддерева.

Таблица Objects содержит список экземпляров объектов. Id - уникальный идентификатор объекта, Class_Id - ссылка на Id класса (в таблице Classes), к которому относится экземпляр, Caption - краткое обозначение объекта (для быстрого вывода в списках), формируется программной системой, обычно соответствует значению одного (или комбинации нескольких) из свойств.

Таблица ObjectData содержит значения свойств объектов. Object_Id - ссылка на Id объекта (в таблице Objects), Attribute_Id - ссылка на Id атрибута (в таблице Attributes), Value - значение этого атрибута для данного объекта.

Таблица Containers содержит ключи ассоциации агрегирования. Здесь Container_Id - ссылка на Id объекта-владельца (в таблице Objects), Object_Id - ссылка на Id обекта (там же), содержащегося в контейнере. Сразу оговорим, что агрегирование в данном случае означает «содержит ссылку» и не подразумевает полное владение вложенными объектами.

Таким образом, таблицы Classes и Attributes содержат описание (метаданные), а остальные таблицы - сами данные.

Авторы измерений в [3] не стали касаться вопросов реализации описания типов атрибутов, контроля за совместимостью типов для ссылок и описания ролей классов в ассоциациях, так как это не является существенным для производимых измерений.

Реализуемость: аналогично предыдущей модели требует наличия подсистемы управления данными, облегчает ее реализацию благодаря представлению данных всех типов в одной таблице и требует лишь приведения типов. Гибкость: очень высокая, изменения в предметной области требуют внесения исправлений на уровне данных и не влияют на исходный код программы. Особенности - аналогичны модели Тенцера, для универсальности программы имеется необходимость поддержки уникального идентификатора в пространстве всей базы данных. Однако здесь эту проблему решить проще благодаря меньшему количеству таблиц. Объединение всех атрибутов в одну таблицу облегчает реализацию поиска и выборки их значений. Объем базы данных и время выполнения операций - очень высокие[3].

1.3.5 Сравнительный анализ методов реализации объектно-ориентированного проектирования в реляционных БД

Результаты измерения времени выполнения операций и объема базы данных приведены в табл. 1.2 и на рис. 1.5-1.14.

Таблица 1.2. Время выполнения операций и объемы баз данных

В [3] был произведен анализ рассмотренных выше методов реализации объектно-реляционного проектирования в реляционных БД. Ниже изложу основные итоги данного анализа.

Открытие всех таблиц базы данных. Суммарное время открытия всех таблиц базы данных в модели Тенцера и ее модификации значительно превышает этот показатель для ROT и ее модификации (рис. 1.5.). Это связано с «гигантскими» таблицами Objects, Links и т.д.



Рис. 1.5. Открытие всех таблиц базы данных, с

Выборка всех данных по одной Книге. На проведение выборки данных по одной Книге (рис. 1.6, 1.7) не влияет определение типа на этапе выполнения, так как в любом случае количество атрибутов остается одинаковым - максимальным. Хорошие результаты показывает модифицированная модель Тенцера, так как выборка самих значений производится по одной таблице ObjectData.

Рис. 1.6. Выборка всех данных по одной Книге без определения типа, с



Рис. 1.7. Выборка всех данных по одной Книге с определением типа, с

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

Рис. 1.8. Выборка всех данных по одной Кассете без определения типа, с



Рис. 1.9. Выборка всех данных по одной Кассете с определением типа, с

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

Рис. 1.10. Выборка всех данных по всем товарам, с

Вычисление суммы товаров в корзине. Время выполнения данной операции в модели Тенцера и ее модификации значительно больше, чем в модели ROT. Связано это с необходимостью учета ссылок через таблицу Links (или Containers) и вытекающим отсюда «каскадированием» запроса. К тому же, в модифицированной модели время вычисления суммы еще больше из-за необходимости преобразования данных строковых типов в числовые.

Рис. 1.11. Вычисление суммы товаров в корзине, с

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

Рис. 1.12. Добавление новой Книги, с



Рис. 1.13. Изменение данных по одной Книге, с

Рис. 1.14. Объем базы данных, МБ

1.3.6 Итоговый анализ эффективности методов объектно-ориентированного проектирования в реляционных СУБД

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

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

1.4 Обоснование выбора Entity-Attribute-Value в качестве метода проектирования Базы Данных

В качестве метода проектирования БД, я выбрал набирающую популярность в наши дни модель Entity-Attribute-Value, более известную в нашей литературе как модифицированная модель Анатолия Тенцера. Приведу причины, по которым я решил остановиться на данной модели.

Во-первых, Гибкость модели. Теоретически не существует ограничений на количество атрибутов на сущность. Число параметров может быть увеличено, когда это необходимо без изменения схемы БД.

Во-вторых, Эффективная организация пространства для сильно рассеянных данных. Отпадает нужда в резервировании места для атрибутов, у которых значения - null. Данная модель предполагает возможное наличие NULL значений для атрибутов, например, сотрудники архива создали новый объект, начали заполнять значения атрибутов, но по каким-либо причинам не заполнили все атрибуты (например, на момент создания объекта было известно значение определенного атрибута). Однако пользователям БД необходимо чтобы данный объект находился в БД (например, чтобы заполнить атрибуты объекта позднее, когда появится соответствующая информация). Механизм полного заполнения значений всех атрибутов объектов недопустим по этой причине, т.к. это приведет к неудобству и невозможности работы пользователей. Однако у данного механизма, очевидно, есть слабое место, а именно вероятность появления дубликатов объектов. Для устранения данной проблемы, для плоских таблиц создаются уникальные индексы на атрибуты, которые определят уникальность данного объекта. Кроме того, необходимо отслеживать объекты, на которые ни один другой объект не ссылается, и удалять их в нужный момент (например, раскрытия дампа на production server). Для выполнения этой задачи спроектирована процедура DropUnusedObjects пакета SystemData.

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

В-четвертых, описание атрибутов всех объектов производится в одной таблице Attributes со структурой. Хранение значений всех атрибутов объектов производится в пределах одной таблицы. При этом возникают естественные проблемы, связанные с увеличением объема таких данных. Однако объем в данном случае является ценой за универсальность подхода.

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

Кроме того, Entity-Attribute-Value model (EAV) - Сущность - Атрибут - Значение модель - модель данных, в которой одна строка хранит в себе одиночный факт. Модель EAV очень полезна в случаях, когда число параметров, которые потенциально будут применимы к сущности, изменится в большую или меньшую сторону по сравнению с тем, что на данный момент есть. Это представляется весьма полезным ввиду возможной реорганизации работы архива.

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

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

Проектирование БД состоит из двух частей:

1. Проектирование системных таблиц, которые содержат в себе информацию обо всех несистемных таблиц, т.е. метаданные схемы.

2. Проектирование несистемных таблиц, которые содержат пользовательские данные.

На основе системных таблиц осуществляется генерация несистемных таблиц в функции doGenerate пакета GenerateInstance. Системные таблицы организованы по модели Entity-Attribute-Value, а несистемные таблицы реализованы в виде плоских таблиц.

Концептуально EAV таблица состоит из 3 составляющих:

1. ID Сущности/Объекта.

2. Атрибут/Параметр объекта.

3. Значение атрибута.

2. Разработка БД

2.1 Общая архитектура БД информационной системы

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

Составные части общей архитектуры БД отражены на рис2.1.

Рис. 2.1. Составные части архитектуры БД.

Итоговая ER-диаграмма с полным набором объектов БД, состоящей как из системных так и из пользовательских таблиц, представлена на рис. 2.2. Более детальное рассмотрение изложено в главах 2.2. “Модель системных данных” и 2.3. “Модель пользовательских данных”.

Рис. 2.2. ER-диаграмма общей архитектуры БД.

Перейдем к рассмотрению непосредственно архитектуры БД. Рассмотрим вначале модель системных данных, а затем модель пользовательских данных.

2.2 Модель системных данных

2.2.1 Общая архитектура системных объектов БД

В модели системных данных можно выделить: модель генерации таблиц, модель функциональности добавления, редактирования и удаления объектов, модель функциональности тщательного контроля доступа на уровне объектов, модель аудита и модель поискового механизма. ER-диаграмма модели системных объектов БД показана на рис. 2.3.

2.2.2 Описание процесса генерации таблиц

В модели EAV пользовательские таблицы создаются динамически на основе информации системных таблиц в ходе так называемого процесса генерации БД. Процесс генерации заключается в создании или пересоздании, т.е. удалении и создания вновь, схем всех несистемных пользователей БД. Таким образом, будут пересозданы все объекты пользовательских схем: вначале будут созданы пользовательские таблицы, затем на них пользовательские представления. Итак, приведу ER-диаграмму объектов, определяющую создание пользовательских таблиц (рис. 2.4).

Коротко опишу структуру объектов рис.2.4.:

Таблица Datatypes содержит в себе следующие поля: