Теория и практика построения баз данных (1088289), страница 152
Текст из файла (страница 152)
Это знание скрыло в объекте ПРОДАВЕЦ и не является частью логики объекта ЗАКАЗ. Эта характеристика может быть как преимуществом, так и недостатком, в зависимости от того, как на это смотреть. Предположим, что один заказ могут обрабатывать несколько продавцов, и у одного продавца может быть много заказов. Выражаясь языком баз данных, объекты ЗАКАЗ и ПРОДАВЕЦ имеют связь М."гс В этом случае в реляционной базе данных создается таблица пересечения, содержащая идентификаторы объектов ЗАКАЗ и ПРОДАВЕЦ, связанных между собой. В обьектном мире продавец знает, что у него есть много заказов, а заказ «знает», что его обрабатывают много продавцов, однако они не знают этого друг о друге.
Следовательно, структуры данных, в которых хранятся связи, будут разделены. В объекте ЗАКАЗ будет место д чя хранения множества ссылок на объекты ПРОДАВЕЦ, а в объекте ПРОДАВЕЦ будет место для хранения множества ссылок на объект ЗАКАЗ. Эти наборы ссылок будут изолированы друг от друга.
Имеет .чи это значение? Нет, пока нет ошибок в обработке объектов, но есть такой риск, поскольку ссылки на объекты хотя и разделены, но не независигньг. Если заказ 1000 связан с продавцом А, то, по определению, продавец А связан с заказом 1000. В мире реляционных СУБД, поскольку связь представляется строкой в таблице пересечения, удаление строки с одной стороны автоматически принодит к удалению соответствующей строки с другой стороны. Однако в мире объектов может случиться так, что связь будет удалена только с одной стороны и не будет удалена с другой. Так, заказ 1000 может быть связан с продавцом А, но продавец А может и не быль связанным с заказом 1000.
Очевидно, что это ошибка и что такого не следует допускать, но такая ситуация может возникнуть, если определение связей происхолнт исключительно с обьектно-ориентированной точки зрения. При использовании реляционной СУБД для постоянного хранения объектов объем работы для программиста оказывается меньше, чем при использовании традиционных файловых структур. Однако остается необходимость преобразовывать объекты в реляционные конструкции, писать запросы на БЯ) (илп другом языке), считывать и записывать обьекты с помощью СУБД и производить настройку по адресам.
Для выполнения этих задач были разработаны объектноориентированные СУБД. Постоянное хранение объектов с использованием ООСУБД Третий способ постоянного хранения объектов — использование объектно-ориентированных СУБД. Такие продукты специально приспособлены для постоянного хранения объектов и, следовательно, сводят к минимуму труд прикладных программистов. ООСУБД изначально интегрирована с объектно-ориентированным языком программирования.
Таким образом, в код приложения не нужно встраивать никаких дополнительных структур типа ЯЯЦ В примере на рис. 18.2, возможно, методы Сохранить фактически предоставляются ООСУБД. Следовательно, вызывая метод Сохранить, программист обращается к ООСУБД. Кроме того, в состав ООСУБД входит компилятор (нли ООСУБД входят в состав компилятора — все зависит от точки зрения), которьш обрабатывает исходный текст и автолюатически создает в объектной базе данных структуры для хранения объектов.
Соответственно, в отличие от реляционных СУБД или систем обработки файлов, программист не должен преобразовывать объекты в реляционные или файловые структуры — ООСУБД делает это автоматически. Наконец, поскольку ООСУБД специально предназначены для постоянного хранения объектов, в них обеспечивается та или иная форма настройки по адресам. Таким образом, для кода, подобного показанному в листинге 18.1, этой проблемы не будет. Обьект получает ссылку на другой объект, и эта ссылка всегда является дейстщпельной.
Если ссылка принимает другие формы, программа не знает об этом. 704 Глава 18. Объектно-ориентированные базы данных Постоянное хранение обьектов в Огас1е 705 Это приводит нас к характеристике ООСУБД, которая называется одноуровневой памятью. В некоторых ООСУБД программе (а следовательно, и программисту) не нужно знать, находится обьект в памяти или нет. Если заказ 1000 имеет связь с продавцом А, заказ 1000 может смело использовать доступные свойства продавца А, не проверяя, загружены ли эти данные в память, не выполняя чтения и не посылая 5Я1.-запрос.
Если объект продавца А находится в памяти, ООСУБД создает ссылку, а если нет, ООСУБД загружает обьект в память и затем создает на него ссылку. В табл. 18.3 сравнивается объем работ, которую приходится проделать программисту при каждом из трех способов постоянного хранения объектов. Очевидно, что ООСУБД предоставляет программисту ООП существенные преимушества. Почему же тогда эти продукты не используются повсюду? Этому вопросу посвяшен следуюший раздел. Таблица 18.3.
Сравнение различных способов постоянного хранения объектов по требуемому объему работы ООСУБД Реляционные СУБД Традиционныа системы обработки файлов + Вызов специального метода ООСУБД Постоянное хранение объектов в Огас!е Компания Огас1е расширила возможности своих СУБД, включив в них поддержку объектного моделирования и постоянного хранения объектов. Как уже говорилось, такие базы данных иногда называются объектно-реляционными базами данных. По ходу чтения подумайте над тем, каким образом Огас!е удалось соединить объектна-ориентированное мышление с реляционной моделью.
Даже если в некоторых отношениях этот гибрид довольна неуклюж, он позволяет организациям постепенно мигрировать от реляционного способа хранения данных к объектному. Как уже упоминалось, чистые объектно-ориентированные СУБД, требовавшие резкой смены парадигм, были отвергнуты. Во многих отношениях Огас!е выполнила блестящую работу, обеспечив поддержку текущей клиентской базы и, в то же время, распространив возможности продукта в объектном мире. + Преобразование адресов объектов в памяти в постоянные идентификаторы и наоборот(настройка по адресам) + Создание реляционных структур данных + Написание процедуры нв ВСС (или на другом языке) + Встраивание ЗОС в программу + Преобразование адресов объектов в памяти в постоянные идентификаторы и наоборот(настройка по адресам) + Соз/ьзние реляционных структур данных + Написание процедуры сохранения объекта в постоянной форме + Вызов процедуры сохранения объекта в постоянной форме + Преобразование обьектов в файловую структуру и наоборот + Нахождение объектов по требованию + Управление дисковым пространством + Другие задачи по управлению файлами Настоягцее изложение основывается на 8-й версии Огас!е.
Эти возможности и функции, несомненно, будут совершенствоваться и расширяться, так что стоит просмотреть документацию па более новые версии Огас!с, чтобы узнать о последних достижениях Огас1е в области храпения объектов. Типы объектов и коллекции Для постоянного хранения объекта в Огас!е нужно сначала создать тип, представляющий этот объект.
Этот тип может дазее использоваться в отношении любьгм из четырех возможных способов. В простейшем случае столбцового обьвкта (со1цшп оЪ)ест) объектный тцн используется для определения столбца таблицы. В остальных трех случаях создается коллекция объектов одного из трех типов: массивы перенвппой длины (уаг)аЫе 1епц(Ь аыауз), вложенные таблицы (пезгег) таЬ!ез) ц обьвкты-строки (готу оЬ)ес(з). Рассхютрнм каждый из этих типов. Столбцовые объекты Следующий оператор определяет обьектиый тип оЬ) Айаг(тел(, описывающий квартиру: СКЕАТЕ ГУРЕ аЬВ Арагглепг А5 ОВОЕСТ ( Вцз1б1псйапе ЧАКСНАК2(25), АрагглепгйцеЬег СНАК(4), ИцпбегВебгаощз ИОНВЕК) l Этот тип имеет три столбца (название здания, номер квартиры и число спальных комнат), использующих встроенные типы данных Огас1е.
(Вспомните, что косая черта командует 5Я). Р!сз выполнить только что введенный оператор. С этого момента мы будем опускать косую черту в конце всех примеров.) Следуюцгий оператор СКЕАТЕ определяет столбцовый объект с именем Еосабоп (место жительства), имеющий объектный тип оЬ) Араг(тепб СКЕАТЕ ТАВСЕ РЕК50И ( ИанеЧАКСНАК (50).
Ссса11спаЬ) Араг1леп() Данные из этой таблицы об имени и месте проживания людей можно запрашивать и обрабатывать так же, как данные пз всякого другого отношения. Однако синтаксис операторов 1И5ЕКТ и 0РОАТЕ несколько отличается. Следующий оператор выполняет вставку строки в таблицу РЕК50И: 1И5ЕКТ 1ИТО РЕК5ОИ (Иапе. Ссса11сп) ЧАСОЕ5 ('5е1па НП1 1Ьгеаб', сЬ) Араггкеп1('Еаз11айе', '206', 2)); Обратите внимание на то, как используется имя типа данных в предложении НАШ Е5.
Следующий оператор выполняет обновление строки: ОРОАТЕ Ргй5ОИ 5ЕТ Ссса11оп=оЬВ Араг1ееп(('Еаз11аке'. '412'. 3) ННЕКЕ Иапе='5е1еа НЬ11Ьгеаб'; 706 Глава 18. Объектна-ориентированные базы данных Постоянное хранение объектов в Огас(е 707 И снова обратите внимание па использование имени типа данных. На рис. !8А показан результат запроса из этой таблицы. 5ОЕ> 5Е(ЕСТ е ЕВОН РЕВ5ОЙ; няне ьесйттом(во»ьатнвнйне, йййвтнеитиоивея, нонвеваеввоанв» (вава аваев Ооа йвйативмт( Еевттайе , 29» , 2) Те1ва ТВЕТЬгеаа аза явяятивмт('Еав11аяе , ааа , З) ОН115(йРййтиЕНТЙОНВЕЯ, ИОНВЕВВЕОВОО»В) т Еав21айе йРйя1НЕНТ 1.15Т1(йРТ ОИ1Т('199 ', 1), йР1 ОН1Т('299 ', 2), йРТ ОН1Т('399 ', 1») 2 Оевтвкев йвйятнемт «зтт(ййт Ои»т( тот , 1), йвт Омтт( 291 .
2), ййт витт( вот . 1») 50Ь> 5ЕЬЕСТ е РООИ ВО1Ь01ЙО21 ВОТЬОТНВ»О Ийнв Онттнйаййтнемтионвея. неивеявеойоонв) 1 Еаве1аве йгйятиемт «атз(йвт ОИТТ('199 2 Оеввв1ев йвявтиеит «ага(яот ОЙТТ( твт а Рис. т 8.4. Работа оператора ВЕСЕСТ с объектными структурами: а — выборка столбцового объекта; б — выборка массива переменной длины; а — выборка ело>канной таблицы; г — выборка строчного обьекта Массивы переменной длины Массивы переменной длины — зто один из способов создания коллекций объ- ектных типов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
