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

Главная

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

Разработка Базы Данных для информационной системы архива. Обоснование выбора Entity-Attribute-Value в качестве метода проектирования БД. Модификация ROT с учетом наследования, модели Тенцера. Процесс генерации таблиц. Тестовые примеры (test cases).


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
1.1 Исходные требования к проектируемой БД
1.2 Обзор основных моделей данных современных БД
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.1 Общая архитектура БД информационной системы
2.2.1 Общая архитектура системных объектов БД
2.2.2 Описание процесса генерации таблиц
2.2.3 Реализация функциональности добавления, редактирования и удаления объектов
2.2.4 Реализация функциональности тщательного контроля доступа на уровне объектов
2.2.5 Реализация аудита на изменение объектов
2.2.6 Реализация механизма поиска объектов
2.3.1 Общая архитектура пользовательских объектов БД
2.3.2 ER-диаграмма фотодокументов архива
2.3.3 ER-диаграмма фонодокументов архива
2.3.4 ER-диаграмма остальных пользовательских объектов
2.3.5 Представления пользователя приложения
3.1 Описание работы БД как основной части информационной системы
3.3 Сводная таблица тестирования (test log)
Приложение 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 Исходные требования к проектируемой БД
Разрабатываемая база данных (далее БД) предназначена для хранения и обработки информации архива, а именно аудиофайлов, фотофайлов и текстовой информации, которая характеризуется сильной разреженностью данных. Под разреженностью данных здесь понимается отношение занятых позиций данных к количеству всех возможных позиций.
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. БД должна поддерживать модификацию схемы.
В СУБД 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 Обзор основных моделей данных современных БД
Иерархическая модель базы данных состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй -- объекты второго уровня и т. д.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможно, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами.
Например, если иерархическая база данных содержала информацию о покупателях и их заказах, то будет существовать объект «покупатель» (родитель) и объект «заказ» (дочерний). Объект «покупатель» будет иметь указатели от каждого заказчика к физическому расположению заказов покупателя в объект «заказ».
В этой модели запрос, направленный вниз по иерархии, прост (например: какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ). Также, трудно представить неиерархические данные при использовании этой модели.
Иерархической базой данных является файловая система, состоящая из корневой директории, в которой имеется иерархия поддиректорий и файлов.
Преобразование концептуальной модели в иерархическую структуру данных во многом схоже с преобразованием ее в сетевую модель, но и имеет некоторые отличия в связи с тем, что иерархическая модель требует организации всех данных в виде дерева. Преобразование связи типа "один ко многим" между предком и потомком осуществляется практически автоматически в том случае, если потомок имеет одного предка, и происходит это следующим образом. Каждый объект с его атрибутами, участвующий в такой связи, становится логическим сегментом. Между двумя логическими сегментами устанавливается связь типа "один ко многим". Сегмент со стороны "много" становится потомком, а сегмент со стороны "один" становится предком. Ситуация значительно усложняется, если потомок в связи имеет не одного, а двух и более предков. Так как подобное положение является невозможным для иерархической модели, то отражаемая структура данных нуждается в преобразованиях, которые сводятся к замене одного дерева, например, двумя (если имеется два предка). В результате такого преобразования в базе данных появляется избыточность, так как единственно возможный выход из этой ситуации -- дублирование данных. Такие ситуации в проектируемой системе неизбежны, именно по этой причине данная модель не является наиболее предпочтительной для всех.
В сетевой структуре каждый элемент может быть связан с любым другим элементом. Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию. Несмотря на то, что эта модель решает некоторые проблемы, связанные с иерархической моделью, выполнение простых запросов остается достаточно сложным процессом. Также, поскольку логика процедуры выборки данных зависит от физической организации этих данных, то эта модель не является полностью независимой от приложения. Другими словами, если необходимо изменить структуру данных, то нужно изменить и приложение, что существенно усложнит поддержку приложения ввиду неизбежной модификации структуры объектов используемых в ней[6].
В СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов: гиперкубов (все хранимые в базе данных ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) и/или витрин данных, представляющих собой предметно-ориентированные подмножества хранилища данных, спроектированные для удовлетворения нужд отдельной группы (сообщества) пользователей и удовлетворяющие требованиям защиты от несанкционированного доступа в организации; они обеспечивают более быструю реакцию на запросы сведений за счет того, что обращения поступают к относительно небольшим блокам данных, необходимых для конкретной группы пользователей. Для достижения сравнимой производительности реляционные системы требуют тщательной проработки схемы базы данных, определения способов индексации и специальной настройки. В случае многомерных баз данных, как правило, не требуется даже указание на то, по каким реквизитам (группам реквизитов) требуется индексация данных. Ограничения 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. Гибко
Проектирование и разработка БД Oracle для информатизации объектов культуры дипломная работа. Программирование, компьютеры и кибернетика.
Реферат по теме Кинематика химических реакций
Контрольная работа: Оценка хозяйственного риска на предприятии
Курсовой Проект Модернизация Линии Для Производства
Пособие по теме УСТАВ муниципального общеобразовательного учреждения средней общеобразовательной школы № 48 (новая р...
Реферат: Классическая школа менеджмента
Реферат На Тему Восточный Крым В Творчестве Максимилиана Волошина
Учебное пособие: Особенности изучения темы "Закон Архимеда" в малокомплектных школах
Реферат: Луи-Никола Даву
Реферат по теме Обзор технических вузов России
Контрольная Работа На Тему Особенности Процесса Снабжения
Реферат: Благотворительность Рябушинских
Реферат по теме Парламентская реформа 1832 года в Англии и ее последствия
Дипломная работа по теме Методика расследования хищения нефтепродуктов
Сочинение Про Телефон
Реферат: История развития 2
Реферат: Управление кредитными рисками 3
Сочинение Описание Собора Василия Блаженного 8 Класс
Реферат: Новгородская феодальная республика. Скачать бесплатно и без регистрации
Доклад: Анализ финансовой и налоговой ситуации в лесном хозяйстве и лесопользовании
Подготовка К Контрольной Работе По Информатике
Зарубежные модели бухгалтерского учета: Великобритания - Бухгалтерский учет и аудит курсовая работа
Управление воспитанием - Педагогика контрольная работа
Надежность и помехоустойчивость замкнутых систем - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа