Address.Street from CUSTOMER C;
As shown in this example, you need to use correlation variables for queries of abstract datatype
attributes even if the query only accesses one table. There are therefore two features of queries
against abstract datatype attributes: the notation used to access the attributes and the correlation
variables requirement. In order to implement abstract datatypes consistently, you may need to alter
your SQL standards to support 100-percent usage of correlation variables. Even if you use correlation
152 Oracle Database 11g DBA Handbook
variables consistently, the notation required to access attribute values may cause problems as
well, because you cannot use a similar notation on tables that do not use abstract datatypes.
Object views provide an effective compromise solution to this inconsistency. The CUSTOMER
table created in the previous examples assumes that an ADDRESS_TY datatype already exists. But
what if your tables already exist? What if you had previously created a relational database application
and are trying to implement object-relational concepts in your application without rebuilding and
re-creating the entire application? What you would need is the ability to overlay object-oriented
(OO) structures such as abstract datatypes on existing relational tables. Oracle provides object
views as a means for defining objects used by existing relational tables.
If the CUSTOMER table already exists, you could create the ADDRESS_TY datatype and use
object views to relate it to the CUSTOMER table.
Pages:
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280