Введение в системы БД (542480), страница 257
Текст из файла (страница 257)
Обычно предоставпяется особая поддержка для ограничений целостности специального вида. В качестве примера снова рассмотрим базу данных отделов и сотрудников. В обычной реляционной системе сотрудники имели бы внешний ключ, который ссылался бы на отделы, и этим можно было бы ограничиться. В объектных же системах, напротив, имеется по крайней мере три возможности. 975 Глава 24. Объектные базы данных 1. Объекты сотрудников могут содержать идентификатор, который ссылается на объекты отделов. Такая возможность хотя и аналогична реляционному подходу, но не идентична ему„поскольку внешние ключи и идентификаторы — это не одно и то же.
2. Объекты отделов могут иметь набор идентификаторов, ссылающихся на объекты сотрудников. Эта возможность соответствует подходу, использующему иерархию вложения и описанному в разделе 24.3. 3. Кроме того, указанные выше подходы могут комбинироваться, как в следующих определениях. СИНЯЯ ЕМР ( ... ()ЕРТ КЕР ( ()ЕРТ ) 1МЧЕКЯЕ НЕРТ.ЕИРЯ ) СЬЬЯБ (>ЕРТ ... ( ... ЕИРЯ КЕР ( ЯЕТ ( КЕР ( ЕМР ) ) ) 1ИЧЕКЯЕ ЕИР.БЕРТ ) ... ; Отметим, что ключевое слово 1ЫЧЕВЯЕ относится к двум переменным: ЕИР.))ЕРТ и БЕРТ.ЕМРЯ.
Говорят, что эти две переменные являются обратными одна по отношению к другой. Переменная ЕМР.(>ЕРТ вЂ” это ссылачная переменная, а (>ЕРТ.ЕИРБ— переменная набора ссылок. (Если бы обе переменные были переменными набора ссылок, то связь имела бы тип "многие ко многим", а не "один ко многим".) Конечно, для каждой из указанных выше возможностей требуется определенного вида поддержка ссылочной целостности (см.
ниже). Однако прежде всего необходимо ответить на вполне очевидный вопрос: как в объектных системах обрабатываются связи, в которых используются два и более классов, например, поставщиков, деталей и проектов. Наилучшим (т.е. наиболее симметричным) ответом на этот вопрос, конечно, будет создание объектного класса ЯРЮ. Причем каждый объект класса будет обладать связями, реализованными с помощью "обратных переменных", с соответствующим поставщиком, соответствующей деталью и соответствующим проектом. Если создание нового объектного класса на основе трех объектов является наилучшим подходом для "связей" между двумя и более объектами, возникает вопрос, почему бы не использовать его для связей на основе двух объектов.
Кроме того, зачем нужно вводить асимметрию, задавать направленность и два разных имени лля одного и того же понятия? Например, рассмотрим два слелующих реляционных выражения. ЯР.Р() ИНЕКЕ ЯР.Я() = Я()('Я1>) ЯР.Я(( ИСобеНЕКЕ БР.Р(( = Р((('Р1') Их объектные аналоги выглядят так. Я.РККТЯ.Р() ИНЕКЕ Я.Я() = Я()('Я1') Р.ЯЦРРЯ.Я() ИНЕКЕ Р.Р>) = Р()('Р1') (Здесь использован некий гипотетический синтаксис, выбранный специально таким образом, чтобы избежать несущественных в данном случае различий.) 976 Чаетпь Р7. Объектные и объектно-реляционные базы данных Целостность на уровне ссылок Рассмотрим уже упомянутую ранее объектную поддержку целостности на уровне ссылок, которая, кстати, как часто утверждают, является сильной стороной объектных систем.
Уровни такой поддержки могут быть самыми разными; например, ниже приводится классификация таких уровней, предложенная в работе Каттелла [Сапе!!) [24.11!. ° Отсутствие системной поддержки. За поддержку целостности на уровне ссылок полностью несут ответственность пользователь и созданные им методы (как это, между прочим, и было определено в исходном варианте стандарта языка БОЬ).
° Проверка достоверности ссылки. В системе проверяется соответствие типа данных для объекта, на который задана ссылка. Однако в этом случае может быть запрешено удаление объектов (т.е. объекты, на которые нет ссылок, могут быть "собраны вместе в мусорной куче"), как обусловлено в стандарте языка ОРАЬ. Как уже объяснялось в разделе 24.4, этот уровень поддержки эквивалентен (но лишь весьма приблизительно) правилам каскадного удаления (Ой 0ЕЕЕТЕ СйБСй0Е) в иерархии для подчиненных объектов без возможности совместного доступа и контролируемого удаления (Ой ОЕЕЕТЕ ЕЕБТЕ1СТ) для других объектов (но если только "указатели ссылаются в верном направлении").
° Системная поддержка. На этом уровне отслеживание и обновление ссылок происходит автоматически (например, с помощью установки значения лЬЕ для ссылок на удаленные объекты). Этот уровень в некоторой степени подобен правилу удаления Ой 0ЕЕЕТЕ БЕТ ЕОйй, используемому в реляционной системе.
° "Настраиваемая семантика". Правило каскадного удаления ОН ОЕЕЕТЕ СйБСЕОЕ (применяемое за пределами иерархии вложения) может рассматриваться как пример "настраиваемой семантики". К моменту написания этой книги такие действия не поддерживались в объектных системах и должны были контролироваться соответствуюшими методами, т.е, с помошью процедур, созданных пользователем. Языки программирования баз данных Приведенные в предыдушей главе примеры на языке ОРАЬ демонстрируют, что, в отличие от большинства современных реляционных программных продуктов (на основе языка БОЬ), в объектных системах обычно не используется "встроенный полъязык данных". Вместо этого для операций, выполняемых как с базами данных, так и с другими объектами, используется один и тот же интегрированный язык. Согласно принятой в главе 2 терминологии базовый язык и язык, ориентированный на работу с базами данных, в объектных системах тесно связаны (фактически эти два языка образуют один и тот же язык).
Такой подход, безусловно, обладает определенными преимушествами'з. Одно из самых сушественных — возможность осушествления усовершенствованной проверки типов [24.2]. В предлагаемой цитате из [24.47] отмечено еше одно важное достоинство. "Благодаря простому единаму языку не возникает никакого затруднения из-за несовпадения праиедурнага языка праграилтравания и внутреннего языка, ориентированногоо на обработку данных и обладающего декларативной семантикой. " ЗЗ В языке Тигапа! Э, который широко использугтсл в данной книге, выбран такой же подход. Соображения по этому поводу излолгены в (3.3). 977 Глава 24. Объектные базы данных Термин затруднения из-за несовпадения используется для описания различий между типичными современными языками программирования, функционирующими на основе последовательной обработки записей, и реляционными языками наподобие Б()1., функционирую- шими на основе последовательной обработки множеств.
Очевидно, что такие различия на практике приводят к возникновению разнообразных проблем в реляционных программных продуктах. Но для их решения не нужно переводить язык, ориентированный на работу с базами данных, на уровень последовательной обработки отдельных записей (именно такое решение реализовано в объектных системах!). Необходимо в языках программирования ввести инструменты для последовательной обработки множеств записей. Применение последовательной обработки отдельных записей в объектных языках (т.е. процедурный подход) отбрасывает нас к временам, когда использовались такие дореляционные системы, как 1МБ и! РМБ.
В отношении последнего замечания следует отметить, что в действительности большинство существующих объектных языков является либо процедурными, либо языками третьего поколения (ЗО(.). В результате утрачиваются все преимушества реляционного подхода на основе последовательной обработки множеств.
В частности, заметно уменьшается способность системы к оптимизации запросов пользователя, а значит, как и в дореляционных системах, производительность в значительной степени определяется самим пользователем (разработчиком программы или администратором базы данных). Об этом мы поговорим более подробно в слелуюшем подразделе. Повышение производительности Низкая производительность — один из самых существенных недостатков всех объектных систем, И снова процитируем, несколько перефразировав, Каттелла [24.111: "Различие производительности на порядок реально может привести к функциональному различию, поскольку для решения некоторых задач будет невозможно использовать данную систему, если ее производительность гораздо ниже требуемого уровня". Среди многочисленных факторов, влияющих на общую производительность системы, можно отметить следующие'з.
° Кластеризация. Как сказано в главе !8, физическая кластеризация логически связанных данных, размещенных на жестком диске, является одним из наиболее важных факторов повышения производительности системы. В объектных системах логическая информация из определений базы данных (относительно иерархии классов, иерархии вложения или других явно заданных связей между объектами) обычно основана на макете системы и используется в качестве приблизительного плана для физической кластеризации данных.
Кроме того, часто рекомендуется, чтобы администратор базы данных сам осуществлял явное и непосредственное управление отображением концептуального уровня на внутренний (по терминологии главы 2). ° Кэширование. Объектные системы обычно используются в системах типа "клиент/сервер", в которых пользователи "копируют" на свои рабочие станции информацию из базы данных на сервере и хранят ее на своих рабочих станциях в течение некоторого времени.
Очевидно, что в такой системе было бы полезно кэшировать логически связанные данные на рабочем месте клиента. г> Кроме перечисленных факторов, можно отметинш, что в обьектныл системах произоодительность, дополнительная к той, которая существует на самом деле, достигается за счет "приближения пользователя к колепьютеру", т.е. предоставления таках возможностей, как>казатели, которые должны быть скрыты в реализации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
