ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.11.2023
Просмотров: 77
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Закрытая область – это та часть определения класса, которая не видна другим объектам. Пользователю объекта предоставляется информация только о том, как работать с объектом при помощи его методов. Сама же работа объекта скрыта от пользователя. Например, могут существовать дополнительные свойства с закрытыми значениями, а также скрытые связи и сообщения другим объектам.
Свойства объектов описываются либо одним из стандартных типов, заложенных в системе, например, строковым типом String, либо типом, который конструирует сам пользователь. Этот тип определяется словом Class. Значением свойства типа Class является объект, являющийся экземпляром соответствующего класса. Каждый объект – экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект – экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в базе образуют связанную иерархию объектов.
Важным достоинством объектно-ориентированной базы является то, что пользователю не нужно знать о взаимодействии объектов: он просто обращается к конкретному объекту и использует конкретный метод. А то, что при этом осуществляется воздействие на другие объекты базы, скрыто от пользователя. Различные правила, руководящие использованием объектов, также могут быть скрыты от пользователя. Например, выбранный метод может, в свою очередь, обращаться к другим методам, например, методу проверки кредитоспособности выбранного клиента.
Чтобы определить класс объектов, нужно задать его свойства и методы, а также определить его взаимодействие с другими объектами. Понятие класс объекта во многом аналогично понятию тип. Поэтому при проектировании объектно-ориентированной базы данных нужно, прежде всего, осуществить процесс классификации, то есть выявить объекты с аналогичными свойствами и поведением и объединить их в классы.
Этих действий можно добиться и реляционных базах. Но для этого надо создать специальные приложения, предоставляющие пользователю интерфейс, производящий определенные действия, основанные на работе других частей базы данных. При объектной ориентации подобная деятельность может быть частью определенного объекта
, а не представлять собой отдельное приложение. Таким образом, используя объекты и методы, можно хранить и неоднократно использовать не только структуру объекта базы данных, но и его поведение.
Инкапсуляция означает объединение в единое целое данных и алгоритмов (функций и методов) их обработки, а также скрытие данных внутри объектов, что повышает надежность разрабатываемого программного обеспечения. То есть вся информация об объекте заключена в определении его класса. Доступ к объекту может осуществляться только через его интерфейс. Поведение объекта полностью определяется принадлежностью к конкретному классу.
Наследование распространяет множество свойств и методов на всех потомков объекта. Аналогом наследования можно считать разбиение на подтипы. Например, можно определить классы Мужчина и Женщина как наследующие класс Человек. Все эти классы будут иметь общие свойства и методы. Однако в определении новых классов можно добавить дополнительные свойства и методы.
Полиморфизм допускает в объектах разных типов иметь методы (процедуры и функции) с одинаковыми именами, что означает способность одного и того же программного кода работать с разнотипными данными.
Создание объектной модели начинается с классификации – выявлении объектов с аналогичными свойствами и поведением и объединении их в классы. Например, в базе данных, содержащей диаграммы, можно классификацию начать с выделения объектов диаграмм, имеющих дату их создания. Процесс классификации позволяет выделить объекты с общими свойствами и методами. Однако, некоторые их свойства и методы различны. В этом случае производят генерализацию и специализацию.
Генерализация выявляет классы объектов с аналогичными свойствами и образует на основе этих свойств абстрактный суперкласс. Например, в базе данных, содержащей описание геометрических фигур, можно начать проектирование с выделения классов: треугольников, прямоугольников, окружностей, – а затем образовать из них абстрактный суперкласс Фигуры, состоящий из свойств, общих для всех фигур. Специализация – процесс обратный генерализации. При использовании этих процессов создается иерархия классов. Иерархии указывают цепочку наследования.
Важным процессом в объектно-ориентированной базе является агрегация. С помощью агрегации классы объектов могут связываться друг с другом, образуя класс агрегатов
. Например, банковская база может содержать информацию о клиентах, счетах, филиалах, а также связи между ними. В объектно-ориентированной базе всю эту информацию можно инкапсулировать в одном агрегированном классе объектов.
Таким образом, создание объектно-ориентированной базы данных основано на процессах: классификации, генерализации, специализации и агрегации, – которые проводятся параллельно.
Резюмируя все вышеизложенное, можно сказать следующее:
объектно-ориентированная база данных – это попытка применить идеологию объектно-ориентированного программирования к технологии баз данных;
объектно-ориентированная база данных состоит из объектов, причем каждый объект принадлежит к определенному классу;
поведение объекта полностью определяется его принадлежностью к определенному классу;
процесс проектирования объектно-ориентированной базы основан на выявлении классов объектов.
Основным достоинством объектно-ориентированной модели данных по сравнению с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель позволяет также идентифицировать отдельные записи в базе и определять функции их обработки. Учитывая эти достоинства, сегодня уже некоторые реляционные СУБД дополняют функциями, позволяющими воспользоваться преимуществами объектной технологии.
Подводя итоги, можно сказать следующее. Основной недостаток объектно-ориентированной модели состоит в сложности понимания ее сути и низкой скорости выполнения запросов. В настоящее время объектно-ориентированные базы данных достаточно сложны, и потому их коммерческое использование идет медленно. Но у этих моделей есть потенциал, а, стало быть, и будущее. А потому исследования в области объектной ориентации становятся главным направлением в теории СУБД.
Сегодня уже разработаны и успешно функционируют такие системы управления базами данных как: 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):
Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.