Компоненты Stock Allocations теперь находятся в двух разных объектах. Конечно, необходимо сделать Stock Allocations отдельным объектом и связать этот новый объект (строго говоря, это не объект, а класс объектов) с объектами Orders и Stock. Однако это означает, что наши "объекты" начинают все больше и больше соответствовать тому, что мы раньше называли таблицами. Является ли это проблемой? Вообще-то, именно этого, т.е. обеспечения несколько более богатой структуры таблиц, чем сейчас, мы и ожидаем от объектной поддержки в OracleS для приложений масштаба предприятия.
Роль LOB
Для понимания внутренней структуры объекта нам не всегда нужна схема базы данных. В Oracle?, где этого не требовалось, большие объекты можно было хранить в столбцах типа LONG и LONG RAW, а в OracleS эти объекты можно представить с использованием типа LOB, который мы рассмотрели в главе 4.
LOB по сравнению с типом данных LONG обладает несколькими преимуществами:
•    память лучше организована, и для хранения данных можно использовать файловую систему;
•    приложения могут выполнять как порционную выборку, так и порционную запись данных;
•    функции PL/SQL могут принимать LOB-объекты (или по крайней мере, LOB-локаторы) как аргументы.
Способность PL/SQL обрабатывать LOB означает, что мы можем (и это всего лишь вопрос эффективности) выполнять проверку LOB как часть предиката WHERE. Для этой цели в OracleS применяется пакет DBMS_LOB. Использование LOB и пакета DBMS_LOB освещается в главе 4.
Представьте ситуацию, в которой одним из атрибутов строки таблицы является таблица Microsoft Excel, отражающая динамику доходности капиталовложений некоторого проекта. SQL-предложение для создания этой таблицы может быть простым и не содержать сложных объектных синтаксических конструкций:
CREATE TABLE projects
( proj_id       NUMBER         PRIMARY KEY , proj_name     VARCHAR2(30)   NOT NULL , manager      NUMBER        NOT NULL
REFERENCES  project__members , roi	BFILE
-- оставить электронную таблицу в файле );
5. Объекты	93