Введение в системы БД (542480), страница 256
Текст из файла (страница 256)
010 ОР ЯЕТ ОГ АЬЬ ЕМРЯ ЕЕИОЧБ : Б001 Но как в такой ситуации реализовать правило каскадного удаления ОЕЬЕТЕ СЛЕСАРЕ? Например, как при удалении некоторого сотрудника одновременно удалить и сведения обо всех потоках, в которых он проходит обучение? Для этого, естественно, придется создать соответствующую процедуру. Можно прийти к заключению, что механизм реализации удаления с помощью процесса сборки мусора является всего лишь некоторой разновидностью реализации правила ограничения удаления ОМ ОЕЬЕТЕ ЕЕБТЕ1СТ, поскольку объект не удаляется до тех пор, пока на него существует хотя бы одна ссылка.
Однако в данном случае это не совсем так. Например, объекты потоков (ОГГЕЕ1М6) не содержат идентификаторов соответствующего объекта курса (СООЕЯЕ), а потому потоки не накладывают "ограничений" на удаление обьектов курсов. (В иерархиях вложения неявно подразумевается некоторая разновидность правила каскадного удаления, кроме случаев, когда пользователь выполняет следующее: ° либо включает илентификатор родительского объекта в дочерний объект; ° либо включает идентификатор дочернего обьекта в какой-то другой объект. В таких ситуация интерпретация "иерархии вложения" не имеет никакого смысла.
В следующем разделе этот вопрос будет рассмотрен при обсуждении обратных переменных.) В заключение заметим, что операция удаления ЕЕМОЧЕ может быть использована для эмуляции реляционной операции ОЕОР, например для удаления всего класса ЕМЕОЬЬИЕИТ. Подробности оставляем читателю в качестве упражнения. 972 Часть й7.
Объектные и объектно-реляиионные базы данных 24.5. Дополнительные аспекты В этом разделе обсуждаются некоторые традиционные аспекты управления базами данных, но в объектном контексте. ° Произвольные запросы ° Целостность базы данных ° Реализация связей ° Языки программирования баз данных ° Повышение производительности ° Является ли объектная СУБД действительно СУБД Произвольные запросы До сих пор мы преднамеренно не подчеркивали, что если для манипулирования объектами заданы только заранее определенные методы, то произвольные запросы (не предусмотренные этими методами) просто невозможны, если только классы и методы не разработаны в соответствии со специальными правилами. Например, если для объекта класса йЕРТ определены только методы Н1ЕЕ ЕМР (нанять сотрудника), Р1ЕЕ ЕМР (уволить сотрудника) и СОТ Ейй6ЕТ (урезать бюджет), то даже такой простой запрос, как "Кто является менеджером (начальником) отдела программирования", выполнить будет невозможно.
По существу, по той же причине невозможно определить представления и декларативные ограничения целостности для объектов, опять же, если не следовать некоторым конкретным правилам. По нашему мнению, решение этих проблем ("специальные правила") может быть следующим. 1. Определить множество операторов ("операторов ТНЕ "), с помощью которых можно было бы получить некоторые возможные представления рассматриваемых объектов, как в главе 5. 2.
Надлежащим образом внедрить объекты в реляционную структуру. Эта часть решения подробно обсуждается в следующей главе. Однако разработчики объектных систем обычно не придерживаются данных рекомендаций. Вместо этого они поступают следующим образом'о. 1. Обычно определяются операторы, которые предоставляют не некоторые возможные представления, а реальные представления (см.
обсуждение открытых переменных экземпляра в разделе 24.2). "В настоящее время для всех продуктов объектных СУБД требуется, чтобы [переменные экземпляра], которые упоминаются в... запросах, были открытыми" [24.38). Ю Здесь подразумевается, что рассматриваемая объектная система действительно поддерлсивает произвольные запросы, как и болыиинспзво современныз обьектныз систем. Однако более ранние объектные системы иногда не поддерлсивали такие запросы, частично в силу причин, которые будут рассмотрены в этом разделе.
973 Глава 24. Объектные базы данньп 2. Обычно поддерживается ие реляционная структура, а множество других структур, которые основываются иа пакетах, массивах и т.д. В связи с этим напомним наше утверждение, что классы, т.е. типы, плюс отношения необходимы и достаточны иа логическом уровне (см. главу 3). А поскольку речь идет об основной модели, мы считаем, что массивы и все остальное является ненужным и нежелательным. На иаш взгляд, причиной того, что в объектных системах отдано предпочтение коллекциям, а ие отношениям (фактически отношения почти полностью отвергнуты), является, опять же, путаница между понятиями модели и реализации. В связи с выполнением произвольных запросов возникает еше один важный вопрос, а именно: какой класс является результатом.
Предположим, например, что необходимо выполнить запрос "Получить имена и размер заработной платы всех служащих в отделе программирования" по базе данных отделов и служащих из раздела 24.3. Предположительно результат будет содержать открытые переменные экземпляра ЕМВИЕ и ЯВЬВВУ. Однако в базе данных иет класса, который имеет такую структуру. Должны ли мы предварительио определить такой класс, прежде чем выполнять запрос? (Обратите внимание иа последствия: если бы было необходимо определить такой класс, для класса с л перемеииыми экземпляра потребовалось бы по крайней мере 2 " предварительно определениых класса только для поддержки операций выборки!) А если есть какой-либо класс результатов, то какие методы применимы к нему? Аналогичные вопросы возникают в связи с операциями соединения.
Если соединить объекты отдела и служащего, то какой класс получится в результате? Какие методы нужно использовать? Возможно, из-за того, что иа такие вопросы нелегко ответить, опираясь иа чисто объектиую структуру, в некоторых объектных системах поддерживаются операции "прохождения пути" (см. ~24.25), [24.47]) вместо самих операций соединения. Для базы даииых ОРАЬ из раздела 24.4, например, допустимо следующее выражение пути. ЕИВОЬЬИЕИТ . ОРРЕВХМЯ .
СОУВЯЕ Оио означает следующее. "Найти уникальный объект класса СОУВЯЕ, иа который ссылается уникальный объект класса ОРРЕВТИЯ, иа который ссылается данный объект класса ЕИВОЬЬИЕИТ'*". Реляционный аналог этого выражения обычно включает две операции соединения и одну операцию проекции. Иными словами, в результате прохождения пути предоставляется доступ только по предварительно определенным путям (как в дореляциоииых системах) и только к объектам предварительно определенных классов (опять же, как в дореляциоииых системах). Целостность базы данных В главе 8 утверждалось, что целостность данных в базе имеет фундаментальное зиачеиие.
Тем ие менее даже те объектные системы, которые поддерживают произвольные запросы, декларативные ограничения целостности обычно ие поддерживают. Выполиеиие подобных ограничений достигается с помощью процедурного кода, т.е, методов или ЗЗ На самом деле зто выраъсение ие является допустимым путел~ для базы данныл, как.иы ее определили, поскольку указатели определяют неверное направление. Например, объекты класса ОРРЕВРЕО не ссылаются на объекты класса СООВЯЕ: наоборопс объекты к~асса СООВЯЕ ссылаются на нил. 974 Часть уХ Объектные и объектно-реляционные базы Данных прикладных программ.
Рассмотрим, например, сведующее ограничение (или "бизнесправило") из раздела 8.5: "Поставщики со статусом меньше 20 не должны поставлять более 500 деталей". Ддя того чтобы обеспечить выполнение этого ограничения, в процедуре ее реализации должны содержаться по крайне мере следующие методы. ° Метод дяя создания объекта поставки ° Метод ддя изменения количества поставляемых деталей ° Метод для изменения статуса поставщика ° Метод для переназначения некоторой поставки другому поставщику При внимательном изучении этого примера можно отметить важные особенности.
1. При такой организации, очевидно, утрачивается возможность проверки соблюдения ограничений целостности с помощью системы. 2. Как убедиться в том, что все эти методы содержат весь необходимый для поддержки целостности базы данных код? 3. Как, например, при создании объектного класса для поставок предостеречь пользователя от случайного пренебрежения методом "создания поставки" и ошибочного непосредственного использования метода аЕИ (т.е. без проверки целостности)? 4.
Как при изменении ограничений целостности найти и внести соответствующие изменения во все методы, в которых они были определены? 5. Как убелиться в корректности кода, с помощью которого приводятся в действие ограничения целостности? б. Как выполнить проверку целостности для отложенных (во время выполнения) операций? 7. Как поступить с транзитными ограничениями? 8.
Как узнать обо всех ограничениях, которые заданы для данного объекта иди комбинации объектов? 9. Будут ли ограничения целостности приводиться в действие во время загрузки системы или во время выполнения каких-либо других действий? 1О. Можно ди осуществить семантическую оптимизацию (т.е. упростить запросы с помощью ограничений целостности так, как описано в главе 17)? Кроме того, как повлияют перечисленные выше особенности на производительность работы во время создания приложения и при последующем его использовании? Реализация связей Термин "связи" используется в объектно-ориентированных продуктах и в соответствующей литературе в основном для связей, представленных в реляционной базе данных внешничи кдючами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
