Введение в системы БД (542480), страница 251
Текст из файла (страница 251)
3. Обратите внимание, что определение каждого класса содержит определения (подробности кода в ннх опушены) методов, которые применяются к объектам этого класса. Целевыми классами для подобных методов являются, безусловно, классы, определение которых включает определение данного методаь.
На рис. 24.4 приведено несколько примеров экземпляров объектов для опрелеленных ранее классов ОЕРТ и ЕИР. Рассмотрим объект ЕМР, показанный в верхней части рисунка (с идентификатором (О(Р) еее), который содержит перечисленные ниже компоненты. ° Неизменяемый объект 'Е00! ' (символьная строка) в открытой переменной экземпляра ЕИР$ ° Неизменяемый объект 'ЯМТсл' (другая символьная строка) в открытой переменной экземпляра ЕИВИЕ ° Неизменяемый объект '$50 000' определенного пользователем класса МОМЕУ в открытой переменной экземпляра Яа!АЕТ ° Идентификатор (О!Р) объекта определенного пользователем класса ЮОВ в открытой переменной экземпляра РОЯТТТОМ Объект ЕИР также включает по крайней мере две закрытые переменные, одна из которых (010) содержит идентификатор еее самого объекта ЕМР, а другая (СЬАЯЯ) — идентификатор, определяющий класс объекта (с!азз-бейл!пЕ оЬ)есг — СРО) для объектов сотрудников, что позволяет найти код методов данного объекта.
Замечание. Эти два идентификатора физически могут храниться как вместе с объектом, так и отдельно от него. Например, значение еее необязательно должно храниться как часть соответствующего объекта ЕИР; необходимо только, чтобы в приложении был задан некоторый способ обнаружения объекта ЕМР по данному значению еее (т.е. чтобы Отметим, что в нашел~ гипотетическом синтаксисе понятия модели и реализации сл~ешиваются (хотя это и нежелательно, но весьма типично).
Кроме того, в (13,11) доказано, что, несолтенно, отделы и сотрудники — это плохие прииеры для объектных классов! Однако данный вопрос мы здесь обсуждать не будем, поскольку это слишкоч далеко увело бы нас от основной темы. 954 Частв И. Объектные и объектно-реляционные базьс данных было задано некоторое отображение величины ввв на физический адрес объекта ЕМР). Однако концептуально пользователь всегда может представить себе идентификатор объекта как часть этого объекта. Рис.
24.4. Пример экземпляров объектов классов ВЕРТ и ЕНР Теперь рассмотрим объект ЭЕРТ, расположенный в центре рисунка с идентификатором (ОПЭ) Ыс(, который содержит перечисленные ниже объекты. ° Неизменяемый объект '001' (символьная строка) в открытой переменной экземп- ляра ЮЕРТР ° Неизменяемый объект 'М)г~й' (другая символьная строка) в открытой переменной экземпляра ЮМВМЕ$ ° Неизменяемый объект '$1 000 000' (другая символьная строка) определенного пользователем класса МОМЕУ в открытой переменной экземпляра ВБВБЕТ ° Идентификатор ввв изменяемого объекта определенного пользователем класса ЕМР в открытой переменной экземпляра МБЕ (это идентификатор объекта, представляющего менеджера отдела) ° Илентификатор ввв изменяемого объекта определенного пользователем класса БЕТ(ЕЕР(ЕМР)) в открытой переменной экземпляра ЕМРБ, которая подробнее описана ниже ° Две закрытые переменные экземпляра, содержащие идентификатор (О!Р) йИ объекта БЕРТ и идентификатор соответствующего объекта, определяющего класс Объект с идентификатором ввв состоит из набора идентификаторов индивидуальных (изменяемых) объектов класса ЕМР, а также обычных закрытых переменных экземпляра.
955 Глава 24. Объектные базы г) анньп На рис. 24.4 экземпляры объектов представлены в том виде, в котором они реально сушествуют, т.е, на рисунке отображается компонент структуры данных "объектной модели", что позволяет яснее представить саму объектную модель. Обычно в книгах или документации такие диаграммы не используются; вместо этого данные представляются так, как на рис. 24.5„на более высоком уровне абстракции, что, как принято считать, облегчает понимание объектной модели.
Рис. 24.5. Пример представления экземпляров объектов РЕРТ и ЕМР в соответствии с ие- рирхией их вложения Приведенная на рис. 24.5 схема в большей степени согласуется с интерпретацией на основе иерархии вложения. Однако в ней остается скрытым важный факт; в объектах часто содержатся не собственно другие объекты, а их идентификаторы. Например, согласно рис. 24.5 можно предположить, что объект класса 0ЕРТ для отдела с номером '001' содержит два экземпляра объекта класса ЕМР для сотрудника с номером 'Е001' (при этом, помимо всего прочего, может получиться, что сотрудник с номером 'Е001' получает две различные зарплаты). Такая ситуация может привести к путанице, поэтому предпочтение следует отдавать схемам, подобным приведенной на рис. 24.4.
В дополнение к этому следует заметить, что реальные объектные определения данных способствуют возникновению запутанных ситуаций, поскольку переменные экземпляра в них обычно определяются не на основе "ссылок" (как в приведенных выше выражениях с использованием гипотетического синтаксиса), а на основе непосредственного отображения иерархии вложения.
Например, переменные экземпляра ЕМРЯ в объектном классе РКРТ обычно определяются не как МЕР(ЯЕТ(КЕР(ЕМР) ) ), а в более краткой форме: ЯЕТ(ЕМР). Несмотря на некоторую громоздкость полной записи, мы все же предпочитаем наш стиль, как более ясный и точный. 956 Часть И. Объектные и объектна-реляционные базы даннып Следует отметить, что вся прежняя критика иерархического подхода (например, иерархии вложения, воплошенной в СУБД 1МБ) в основном относилась именно к иерархиям вложения. Подробное рассмотрение данного вопроса заняло бы слишком много места, поэтому достаточно сказать, что основным аргументом такой критики было отсутствие симметрии. В частности, иерархии не совсем улобны для прелставления отношений типа "многие ко многим".
Например, для рассматриваемого ранее отношения поставщиков и деталей может возникнуть вопрос, содержатся ли объекты-поставщики в объектах-деталях или наоборот. А может, верно и то, и другое? А что можно сказать об отношениях поставшиков, деталей и проектов? Действительно, подобных вопросов больше, чем можно было бы предположить. С одной стороны, как мы убедились, объекты представляют собой иерархию, и к ним также относятся привычные критические замечания относительно иерархий. А с другой стороны, как явствует из рис. 24.4, такие объекты на самом деле образуют не иерархию, а кортежи с перечисленными ниже компонентами. !.
Неизменяемые "подобъекты", т.е. самоидентифицируемые значения, такие как целые числа и денежные суммы. 2. Идентификаторы изменяемых "подобъектов", т.е. ссылки или указатели на другие !возможно, совместно используемые) изменяемые объекты. 3. Множества, списки, массивы и т.д. объектов, перечисленных в пп.
1, 2 и в этом пункте. К этому списку следует также добавить скрытые идентификаторы объектов, идентификаторы объектов, определяющих классы, и т.д, В частности, обратите внимание на п. 3: обычно объектные системы поддерживают несколько "коллекций" генераторов типов (ЯЕТ, ПЯТ, яЕНАХ и др.), но обычно не поддерживают тип ЕЕьаТХОЕ (отношение).
Такие генераторы могут сочетаться сколь угодно сложно. Например, массив списков пакетов массивов указателей на целые переменные может составлять при определенных условиях отдельный изменяемый объект. В следующем подразделе мы продолжим обсуждение этого вопроса. Еще раз об идентификаторе объекта Чтобы сослаться на объект или идентифицировать его, в современных реляционных СУБД обычно используются ключи, определяемые и управляемые пользователями (далее для краткости будем называть их пользовательскими ключами), хотя, как нам известно из главы 3, в реляционных базах данных указатели наподобие идентификаторов объектов фактически намеренно запрещены. Также хорошо известно, что применение пользовательских ключей сопряжено с некоторыми проблемами.
Эти проблемы достаточно подробно рассматриваются в 113.10) и !13.! 61, где сделан вывод, что реляционные СУБД, по крайней мере в качестве альтернативы, должны поддерживать и ключи, определяемые системой (" суррогатные" ). Аргументы в пользу идентификаторов объектов в объектных системах подобны аргументам в пользу суррогатных ключей в реляционных системах. (Однако их не следует приравнивать друг к другу, поскольку суррогатные ключи — это доступные пользователю значения, а идентификаторы объектов — это адреса или указатели, которые, по крайней мере концептуально, от пользователя скрыты. В !24.19) широко обсуждается это различие и другие связанные с ним вопросы.) 9.з7 Глава 24.
Объектные базы данных Здесь следует отметить некоторые важные моменты. 1. Необходимо понимать, что, как будет показано в разделе 24.4, наличие идентификаторов объектов не позволяет полностью исключить применение пользовательских ключей. Точнее, пользовательские ключи необходимы для общения с внешним миром, хотя внутри базы данных все объекты могут ссылаться один на другой только с помощью идентификаторов объектов.
2. Что является идентификатором производного объекта, например "соединения" некоторого объекта класса ЕМР и соответствующего объекта класса ОЕРТ или "проекции" объекта класса ОЕРТ по атрибутам ВСОСЕТ и МСЕ? Это очень важный вопрос лля производных объектов, рассмотрение которого мы отложим до раздела 24.5.
3. Идентификаторы объектов часто служат предметом критических замечаний, вызванных тем, что объектные системы выглядят, как "модифицированный стандарт СОРАБУЬ". Стандарт СОРАБУЬ использовался для сетевых систем управления базами данных (например, для СУБД 1РМБ), которые были созданы до появления реляционного подхода. Использование идентификаторов объектов приводит к низкоуровневому стилю программирования (см, раздел 24.4.), что очень напоминает устаревший стиль программирования согласно стандарту СОРАБУЬ. Кроме того, поскольку идентификаторы объектов являются указателями, часто можно услышать, что системы типа СОРАБУЬ ближе к объектным системам, чем реляционные, и что реляционные системы основаны на эначениси, в то время как объектные системы — на идентичности. Классы, экземпляры и коллекции В области объектных систем четко разделяются концепции класса, экэемиеяра и коллекции.
Как уже отмечалось, объектный класс является, в основном, типом данных, причем он может быть встроенным или определенным пользователем, а также быть сколь угодно сложнымэ. Каждый класс способен принять сообщение (ь(Е%, которое приводит к созданию нового (изменяемого) экземпляра объекта данного класса. Замечание. Вызываемый этим сообщением метод иногда называют конструктором класса. Ниже приводится пример такого сообщения, записанного с помощью некоторого гипотетического синтаксиса. Е := ЕМР МЕМ ( 'Е001', 'ЕпЕС)с', МОМЕТ ( 50000 ), РОЯ ) Здесь программная переменная РОЯ содержит идентификатор некоторого объекта класса ЛОВ, а метод МЕМ вызывается для создания нового экземпляра класса ЕМР, инициализации его переменных экземпляра заданными значениями, возвращения идентификатора нового экземпляра и присвоения его программной переменной Е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
