ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.11.2023
Просмотров: 356
Скачиваний: 1
, а не представлять собой отдельное приложение. Таким образом, используя объекты и методы, можно хранить и неоднократно использовать не только структуру объекта базы данных, но и его поведение.
Инкапсуляция означает объединение в единое целое данных и алгоритмов (функций и методов) их обработки, а также скрытие данных внутри объектов, что повышает надежность разрабатываемого программного обеспечения. То есть вся информация об объекте заключена в определении его класса. Доступ к объекту может осуществляться только через его интерфейс. Поведение объекта полностью определяется принадлежностью к конкретному классу.
Наследование распространяет множество свойств и методов на всех потомков объекта. Аналогом наследования можно считать разбиение на подтипы. Например, можно определить классы Мужчина и Женщина как наследующие класс Человек. Все эти классы будут иметь общие свойства и методы. Однако в определении новых классов можно добавить дополнительные свойства и методы.
Полиморфизм допускает в объектах разных типов иметь методы (процедуры и функции) с одинаковыми именами, что означает способность одного и того же программного кода работать с разнотипными данными.
Создание объектной модели начинается с классификации – выявлении объектов с аналогичными свойствами и поведением и объединении их в классы. Например, в базе данных, содержащей диаграммы, можно классификацию начать с выделения объектов диаграмм, имеющих дату их создания. Процесс классификации позволяет выделить объекты с общими свойствами и методами. Однако, некоторые их свойства и методы различны. В этом случае производят генерализацию и специализацию.
Генерализация выявляет классы объектов с аналогичными свойствами и образует на основе этих свойств абстрактный суперкласс. Например, в базе данных, содержащей описание геометрических фигур, можно начать проектирование с выделения классов: треугольников, прямоугольников, окружностей, – а затем образовать из них абстрактный суперкласс Фигуры, состоящий из свойств, общих для всех фигур. Специализация – процесс обратный генерализации. При использовании этих процессов создается иерархия классов. Иерархии указывают цепочку наследования.
Важным процессом в объектно-ориентированной базе является агрегация. С помощью агрегации классы объектов могут связываться друг с другом, образуя класс агрегатов
. Например, банковская база может содержать информацию о клиентах, счетах, филиалах, а также связи между ними. В объектно-ориентированной базе всю эту информацию можно инкапсулировать в одном агрегированном классе объектов.
Таким образом, создание объектно-ориентированной базы данных основано на процессах: классификации, генерализации, специализации и агрегации, – которые проводятся параллельно.
Резюмируя все вышеизложенное, можно сказать следующее:
объектно-ориентированная база данных – это попытка применить идеологию объектно-ориентированного программирования к технологии баз данных;
объектно-ориентированная база данных состоит из объектов, причем каждый объект принадлежит к определенному классу;
поведение объекта полностью определяется его принадлежностью к определенному классу;
процесс проектирования объектно-ориентированной базы основан на выявлении классов объектов.
Основным достоинством объектно-ориентированной модели данных по сравнению с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель позволяет также идентифицировать отдельные записи в базе и определять функции их обработки. Учитывая эти достоинства, сегодня уже некоторые реляционные СУБД дополняют функциями, позволяющими воспользоваться преимуществами объектной технологии.
Подводя итоги, можно сказать следующее. Основной недостаток объектно-ориентированной модели состоит в сложности понимания ее сути и низкой скорости выполнения запросов. В настоящее время объектно-ориентированные базы данных достаточно сложны, и потому их коммерческое использование идет медленно. Но у этих моделей есть потенциал, а, стало быть, и будущее. А потому исследования в области объектной ориентации становятся главным направлением в теории СУБД.
Сегодня уже разработаны и успешно функционируют такие системы управления базами данных как: Iris, Orion и др., – обслуживающие эти модели.
Объектно-реляционная модель
В связи со значительным усложнением приложений появилась новая модель – расширенная реляционная модель (Extended Relation Data Model –ERDM). Эта модель включила в себя основные достоинства объектно-ориентированной модели и одновременно унаследовала простоту структуры реляционных моделей, и потому стала называться объектно-реляционной моделью данных. В отличие от объектно-ориентированной модели (OODM) объектно-реляционная модель (ERDM) основана на стратегии реляционной модели, в то время как OODM модель основана на объектной стратегии. Исходя из этого, модель ERDM наиболее приспособлена для бизнес-приложений, а модель OODM используется в специальных инженерных и научных приложениях. Некоторые специалисты полагают, что в будущем произойдет слияние OODM и ERDM моделей.
Однако у объектно-реляционной и объектно-ориентированной моделей есть и ряд недостатков, основные из которых следующие:• отсутствие унифицированной теории, которая есть в реляционных моделях;• отсутствие формальной методологии проектирования баз данных, как нормализация в реляционных базах;• отсутствие специальных средств создания запросов;• отсутствие общих правил определения целостности и др.Многомерная модельОдновременно с реляционной моделью данных появилась многомерная модель. Однако хоть идеи многомерной модели возникли одновременно с реляционной, но в ту пору практической реализации таких моделей не было. И лишь в 90-х годах ХХ века к ним стал проявляться интерес. Это было вызвано появлением статьи Э. Кодда, в которой он сформулировал 12 требований к системам класса OLAP (Online Analytical Processing – оперативная аналитическая обработка), связанных с возможностью представления и обработки многомерных массивов.Правило 0: Основное правило (Foundation Rule):Система, которая рекламируется или позиционируется как РСУБД, должна быть способной управлять базами данных, используя исключительно свои реляционные возможности.Правило 1: Информационное правило (The Information Rule):Вся информация в реляционной базе данных на логическом уровне должна быть явно представлена единственным способом: значениями в таблицах.Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):В реляционной базе данных каждое отдельное (атомарное) значение данных должно быть логически доступно с помощью комбинации имени таблицы, имени столбца и значения первичного ключа.Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):Неизвестные, или отсутствующие значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных — как пустые строки.Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):
Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который(а) имеет линейный синтаксис,(б) может использоваться как интерактивно, так и в прикладных программах,(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).Правило 6: Возможность изменения представлений (View Updating Rule):Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, изменения и удаления данных.Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):Операции вставки, изменения и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но и по отношению к любому множеству строк.Правило 8: Физическая независимость данных (Physical Data Independence):Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных.Правило 9: Логическая независимость данных (Logical Data Independence):Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.Правило 10: Независимость контроля целостности (Integrity Independence):Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.Правило 11: Независимость от расположения (Distribution Independence):База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияния на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.Правило 12: Согласование языковых уровней (The Nonsubversion Rule):Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.