05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 10 ■ DATABASE TABLES 413<br />

• SYS_NC_OID$: This is the system-generated object ID of the table. It is a unique RAW(16)<br />

column. It has a unique constraint on it, <strong>and</strong> there is a corresponding unique index<br />

created on it as well.<br />

• SYS_NC_ROWINFO: This is the same “magic” function we observed with the nested table.<br />

If we select that from the table, it returns the entire row as a single column:<br />

ops$tkyte@ORA10G> select sys_nc_rowinfo$ from people;<br />

SYS_NC_ROWINFO$(NAME, DOB, HOME_ADDRESS(CITY,STREET,STATE,ZIP), WORK_ADDRESS<br />

----------------------------------------------------------------------------<br />

PERSON_TYPE('Tom', '15-MAR-65', ADDRESS_TYPE('Reston', '123 Main Street',<br />

'Va', 45678), ADDRESS_TYPE('Redwood', '1 <strong>Oracle</strong> Way', 'Ca', 23456))<br />

• NAME, DOB: These are the scalar attributes of our object table. They are stored much as we<br />

would expect, as regular columns.<br />

• HOME_ADDRESS, WORK_ADDRESS: These are “magic” functions as well. They return the collection<br />

of columns they represent as a single object. These consume no real space<br />

except to signify NULL or NOT NULL for the entity.<br />

• SYS_NCnnnnn$: These are the scalar implementations of our embedded object types.<br />

Since the PERSON_TYPE had the ADDRESS_TYPE embedded in it, <strong>Oracle</strong> needed to make<br />

room to store them in the appropriate type of columns. The system-generated names<br />

are necessary since a column name must be unique, <strong>and</strong> there is nothing stopping us<br />

from using the same object type more than once as we did here. If the names were not<br />

generated, we would have ended up with the ZIP column twice.<br />

So, just like with the nested table, there is a lot going on here. A pseudo primary key of<br />

16 bytes was added, there are virtual columns, <strong>and</strong> an index was created for us. We can change<br />

the default behavior with regard to the value of the object identifier assigned to an object, as<br />

we’ll see in a moment. First, let’s look at the full verbose SQL that would generate our table for<br />

us. Again, this was generated using EXP/IMP since I wanted to easily see the dependent objects,<br />

including all of the SQL needed to re-create this object. This was achieved via the following:<br />

[tkyte@localhost tkyte]$ exp userid=/ tables=people rows=n<br />

Export: Release 10.1.0.3.0 - Production on Sun May 1 14:04:16 2005<br />

Copyright (c) 1982, 2004, <strong>Oracle</strong>. All rights reserved.<br />

Connected to: <strong>Oracle</strong> <strong>Database</strong> 10g Enterprise Edition Release 10.1.0.3.0 - Production<br />

With the Partitioning, OLAP <strong>and</strong> Data Mining options<br />

Export done in WE8ISO8859P1 character set <strong>and</strong> AL16UTF16 NCHAR character set<br />

Note: table data (rows) will not be exported<br />

About to export specified tables via Conventional Path ...<br />

. . exporting table PEOPLE<br />

Export terminated successfully without warnings.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!