Data structure denormalization with Oracle9i

The process of removing redundancy from tables is called data normalization, which attempts to minimize the amount of duplication within the database design. Although normalization was an excellent technique during the 1980s, when disk space was very expensive, the rules have changed in the 21st century, with disk costs dramatically lower. Today, adding redundancy is a very important aspect of designing high-performance Oracle databases. The introduction of redundancy to avoid costly table joins can dramatically improve the speed at which Oracle SQL queries are serviced. It is the challenge of the Oracle design professional to choose the appropriate database design to ensure that SQL queries are serviced as quickly as possible. Instead of removing redundancy, the Oracle designer controls the introduction of redundancy using specific rules. When to add redundancy Essentially, the introduction of redundancy is a function of the size of the redundant column and the frequency with which the column is updated. The ideal candidates for redundant duplication are table columns that meet the following criteria: 1. The introduction of redundancy will eliminate the need to repeatedly join two tables together. 2. The data column is small. 3. The data column is static and rarely updated. Planned data denormalization Oracle was one of the first databases to introduce tools for planned data denormalization. As hard drives became cheaper throughout the 1990s, Oracle recognized that significant performance improvements could be introduced by deliberately introducing redundant data items into the Oracle table and index structures. Snapshots One of Oracle's first forays into data redundancy was the introduction of Oracle snapshots. With Oracle's advanced replication option, copies of tables could be made on remote database servers and refreshed at specific intervals. This redundant duplication of Oracle tables across widely dispersed geographical areas ensured that users were able to retrieve information quickly on a local server without the need to travel across a large network. VARRAYs Oracle also allows the introduction of redundant information using VARRAY table structures. In a VARRAY table, Oracle provides for the introduction of non-first-normal form data structures by inserting repeating groups of values directly within a single Oracle table row. This avoids the overhead of joining the base table into a subordinate table to retrieve the solution set.

Figure A An Oracle8 VARRAY table Frequently updated large data columns can be very cumbersome for Oracle VARRAY tables. This alleviates the additional overhead of re-sorting the test scores every time a student row is retrieved. . we would be required to create a Test_scores table and join the Student table with it to see both the student data and the repeating values of their SAT and ACT test scores. For data warehouse applications and Oracle systems requiring complex SQL queries. Using Oracle8 VARRAY tables. Upon retrieval. However. thus saving thousands of expensive disk I/Os. the information will always be displayed in sorted order. Oracle Materialized views After the popularity of snapshot replication. Another important VARRAY table characteristic is that the repeating information may be stored in presorted order.Let’s look at a simple VARRAY table example. Using this philosophy. Using traditional database design structures. The precompilation process allowed five-way table joins. materialized views can be the difference between subsecond response times and queries that may run for 30 minutes. simply prebuilding complex queries is only a portion of the answer. the cost-based optimizer goes directly to the presummarized information. Assume we have a Student table for a university. A mechanism had to be created to make Oracle SQL aware of a query that had been prebuilt and to tell it to use the precreated summary. the VARRAY tables allow Oracle to retrieve both the student and test information within a single disk I/O operation. thereby allowing the end user to retrieve complex information on a single disk I/O. Oracle automatically checks for materialized views whenever it notices a match between an incoming SQL statement and a prebuilt aggregate. and a host of other timeconsuming and I/O expensive SQL queries that can be precalculated. One of the table requirements is storing student SAT and ACT scores. materialized views boil down to a ”build it now or build it later” philosophy. In the example of our test scores. Using the Oracle parameter query_rewrite_enabled. Oracle called this exciting new feature query rewrite. and the test scores are a very small repeating group that repeats for only a specific number of values. you can create a table structure where repeating groups are automatically stored within the Oracle table itself (Figure A). Oracle recognized that complex queries could be prebuilt to provide end users with the illusion of instantaneous response time. The students may take the test only three times. you can preexecute Oracle queries in anticipation of the end user’s query. If Oracle notices that the information has been presummarized. Basically. complex presummarization of aggregation operations.

Oracle professionals are very conscious of introducing redundancy into their Oracle data models to improve performance. being redundant. thereby avoiding expensive table joins and large-table full-table scan operations that are required to recompute the information at runtime. an Oracle materialized view has to specify the rate at which the materialized view is recreated when any of the information that constitutes the materialized view has changed. When any query summarizes sales. that query will be dynamically rewritten to reference the summary table: alter session set query_rewrite_enabled=true. A thirdnormal-form database design in the 21st century may be very efficient from a disk-storage point of view. we see that the sum_sales table is referenced: Execution Plan ---------------------------------------------------------0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=83) 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'SUM_SALES' (Cost=1 Card=423 Bytes=5342) Materialized views. In the execution plan for this query. and materialized views. VARRAY tables. but it will perform very poorly because everything has to be built from its atomic pieces every time the queries are executed. need to be updated when their base tables change. Oracle offers a wealth of options for the frequency of rebuilding the views. set autotrace on select sum(sales) from sales. ranging from instantaneous rebuilds (commit refresh) to more sophisticated refresh intervals that can be done according to the volatility of the base data. BENEFITS OF DENORMALIZED RELATIONAL DATABASE TABLES . Using Oracle's denormalization tools such as replication. Conclusion Because disk prices are falling by orders of magnitude every year. the Oracle database designer can deliberately introduce redundancy into the data model. Just as a snapshot needs to specify a refresh interval.Here is a simple example of a materialized view: create materialized view sum_sales build immediate refresh complete enable query rewrite as select product_nbr.sum(sales) sum_sales from sales.

Conversely. Beyond this. Further." any view requiring more than three joins should be considered as a candidate for denormalization. designers should only denormalize during the physical design phase and never during conceptual modeling.ABSTRACT Heuristics for denormalizing relational database tables are examined with an objective of improving processing performance for data insertions. As firms move away from the mainframe toward cheaper client-server platforms. View analysis must include the specification of primary and secondary access paths for tables that comprise end-user views of the database. perform a detailed view analysis in order to identify situations where an excessive number of table joins appears to be required to produce a specific end-user view. It is difficult to find formal guidance in the literature that outlines approaches to denormalizing a database schema. also termed usage analysis. Denormalization must balance the need for good system response time with the need to maintain data. software. but have not advanced to the point that they produce table structures that guarantee acceptable levels of system processing performance. A fully normalized database schema can fail to provide adequate system response time due to excessive table join operations. denormalization should only be attempted under conditions that allow designers to collect detailed performance measurements for comparison with system performance requirements [1]. on-line. While no hard rule exists for defining "excessive. First. Additionally. system performance testing by simulating the production environment is necessary to prove the need for denormalization. while avoiding the various anomalies or problems associated with denormalized table structures. transaction processing systems. . This paper focuses on identifying heuristics or rules of thumb that designers may use when designing a relational schema. managers face a different set of issues in the development of information systems. usually reflected by system response time. and other constraints. either entity-relationship or object-oriented. are a precursor to designing relational table structures. CASE tools will generate relational database tables at least to the third normal form (3NF) based on conceptual models. One critical issue is the need to continue to provide a satisfactory level of system performance. Relational database theory provides guidelines for achieving an idealized representation of data and data relationships. The final database schema must be adjusted for characteristics of the environment such as hardware. for mission-critical. Denormalization goes hand-in-hand with the detailed analysis of critical transactions through view analysis. Conceptual diagrams. client-server systems require physical database deign measures that optimize performance for specific target systems under less than ideal conditions [1]. We recommend following three general guidelines to denormalization [1]. deletions and selection. INTRODUCTION Relational database table design efforts encompass both the conceptual and physical modeling levels of the three-schema architecture. Client-server applications necessitate consideration of denormalized database schemas as a means of achieving good system performance where the client-server interface is graphical (GUI) and the network capacity is limited by the network channel.

It is helpful to examine an example problem for those new to the concept of normalization and denormalization. Phone) Denormalized: CUSTOMER (CustomerId. The normalized solution would require at least two indices for the Cust_Phone table . In the denormalized solution. .. Phone2. Phone3. Phone3. Consider a situation where a customer has several telephone numbers that must be tracked. the designer should attempt to reduce the number of foreign keys in order to reduce index maintenance during insertions and deletions. Phone2. Phone1. The third normal form (3NF) solution and the denormalized table structure is given below with telephone number (Phone1. . smaller index structure for the CustomerId key field. CustomerName. This stems from the fact that repeating fields occur fairly often in business information systems.) CUST_PHONE ( on the composite key to ensure uniqueness integrity. this denormalized solution is usually only appropriate if one can guarantee that a customer will have a limited finite number of telephone numbers. Both solutions provide good data retrieval of telephone numbers as indicated by the following SQL statements. Third. CustomerName. Thus. The denormalized solution requires a simpler. designers and relational database theoreticians have been forced to come to grips with the issue... and one on the CustomerId field to provide a fast primary access path to records..Second. therefore. or if the firm makes a management decision not store more than "X" number of telephone numbers. …) as a repeating field: 3NF: CUSTOMER (CustomerId. Reducing foreign keys is closely related to reducing the number of relational tables. Select * from Customer where CustomerId = '3344'. a satisfactory approach would not require excessive programming code (triggers) to maintain data integrity and consistency. code must be written (or a screen designed) to enable any new telephone number to be stored in any of the three Phone fields.) Which approach is superior? The answer is that it depends on the processing and coding steps needed to store and retrieve the data in these tables.. still. Select * from Cust_Phone where CustomerId = '3344'. DENORMALIZING FIRST NORMAL FORM (1NF) TO UNNORMALIZED TABLES There are more published formal guidelines for denormalizing 1NF than for any other normal form. Clearly this is not a difficult task and can be easily accomplished with modern CASE tools. the ease of data maintenance provided by normalized table structures must also be provided by the denormalized schema.

for example. ItemId. A true 3NF alternative solution would store price data in an ItemPriceHistory table. CustomerId) ORDERLINE (OrderId.. once complete. . Customer C where C. CustomerName. While the OrderPrice field is functionally determined by the combination of ItemId and OrderDate. and Phone may be prohibitive in terms of processing efficiency. a dedicated fax line. Even if an order is partially or fully deleted at the request of the customer. but such a solution is not central to the discussion of denormalization. and Items provides a realistic situation where denormalization is possible without significant data maintenance anomalies.) ORDER (OrderId..If the customer name is also required in the query. Phone) PHONE (Phone. The OrderPrice is stored in the Orderline table because this monetary value may differ from the value in theCurrentPrice field of the Item table since prices may change over time.. each having two or three telephone numbers. the only factor favoring a 3NF solution is the number of potential telephone numbers that an individual customer may have. Orders. for example.CustomerId. The decision to denormalize is most crucial when the Customer table is large in a client-server environment. Customer C where CP. Select * from Cust_Phone CP.. The OrderPrice field in the Orderline table represents the storage of data that is time-sensitive.CustomerId = '3344' and CP. Amount. CustomerName. one hundred thousand customers. The effort required to extract telephone numbers for a specific customer based on the customer name is also more difficult for the 3NF solution as a table join is required. storing the OrderDate field in the Orderline table is not necessary. CurrentPrice) The many-to-many relationship between the Order and Item entities represents a business transaction that occurs repeatedly over time. QtyOrdered.CustomerName = 'Tom Thumb' and CP.) Again the denormalized solution is simpler for data storage and retrieval and. most designers would consider the above solution 3NF for all practical purposes. then the denormalized solution is superior as no table joins are involved. other tables not shown above will be used to record the deletion of an item or an order as a separate business transaction for archive purposes. and a dedicated modem line. then the appropriate table structures are: 3NF: CUSTOMER (CustomerId. ) CUST_PHONE (CustomerId. CustomerName.. PhoneType) Denormalized: CUSTOMER (CustomerId. Select * from Cust_Phone CP. while Orderline is not technically in 3NF. Therefore.CustomerId = C. Consider the following 3NF table structures. DeliveryDate. DENORMALIZING TO SECOND NORMAL FORM (2NF) TO 1NF The well-known order entry modeling problem involving Customers. . are essentially "written in stone" since the transaction records would never be deleted. VoicePhone.CustomerId = C. as before. OrderDate. FaxPhone. If the telephone number fields represent different types of telephones.. ItemDescription. Further. OrderPrice) ITEM (ItemId. .. The Phone table would be at least 30 to 50 percent the size of the Cust_Phone table. a voice line. ModemPhone. The join of Customer. such transactions. 3NF: CUSTOMER (CustomerId. since the OrderPrice is recorded at the time that the transaction takes place. Cust_phone.CustomerId.

the savings in processing time may offset the cost of extra storage. DeliveryDate.. in order to meet processing requirements. OrderDate.. in addition to the Customer and Orderline tables from the denormalized 1NF solution given in the preceding section. An additional issue concerns the storage of consistent data values for the ItemDescription field in the Orderline and Item tables. for example. OrderPrice.) ORDER (OrderId. this denormalized solution must be evaluated for the potential effect on data storage and retrieval. The 3NF solution for the Salesperson and Order tables is given below. SalespersonName. SalespersonId) Denormalized 2NF: SALESPERSON (SalespersonId. Amount. a comparison of the 3NF solution and the denormalized 2NF solution reveals that the . 3NF: SALESPERSON (SalespersonId. not their identification number on order invoices and order forms. DeliveryDate. QtyOrdered. As before. The relationship between the Salesperson and Order entities is one-to-many (many orders can be processed by a single salesperson. Suppose. CurrentPrice) Orderline records for a given order are added to the appropriate tables at the time that an order is made. Thus. Denormalizing the table structures by duplicating the SalespersonName in the Order table results in a solution that is 2NF because the nonkey SalespersonName field is determined by the non-key Salesperson field. the retrieval of records from the Orderline and Item tables may also be via indexes. The 3NF solution requires joining four tables to produce an invoice view of the data. Denormalized 1NF: ORDERLINE (OrderId.In the proposed denormalized 1NF solution shown below (the Customer and Order tables remain unchanged) the Item. Amount. the 3NF solution requires joining the Salesperson and Order two tables.. SalespersonId. and Orderline tables. ItemDescription) ITEM (ItemId. theOrder table will be accessed by an indexed search based on the OrderId field. SalespersonName) Note that the SalespersonId in the Order table is a foreign key linking the Order and Salesperson tables. The denormalized 1NF solution requires only the Customer. but an order is normally associated with one and only one salesperson). Mahogany. This solution violates second normal form (2NF) since the ItemDescription field is fully determined by ItemId and is not determined by the full key (OrderId + ItemId). Again.. Similarly. DENORMALIZING THIRD NORMAL FORM (3NF) TO 2NF An example for denormalizing from a 3NF to a 2NF solution can be found by extending the above example to include data for salespersons. along with a denormalized 2NF solution. The additional expense of storing Orderline. still. Consider the production of a printed invoice. SalespersonName. ItemDescription. What is the effect of this denormalized solution? By using view analysis for a typical printed invoice or order form. we may discover that most end-user views require printing of a salesperson's name. the additional processing required to retrieve and store the ItemDescription value in the Orderline table is negligible. an item description of a record in the Item table is changed from "Table" to "Table. Since the OrderPrice for a given item is retrieved from the CurrentPrice field of the Item table at the time that the sale takes place..ItemDescription field is duplicated in the Orderline table. ItemId. Clearly..) ORDER (OrderId." Is there a need to also update corresponding records in the denormalized Orderline table? Clearly an argument can be made that these kinds of data maintenance transactions are unnecessary since the maintenance of the non-key ItemDescription data field in the Orderline table is not critical to processing the order.ItemDescription must be weighed against the processing required to produce various end-user views of these data tables. Order. OrderDate.

Denormalizing from 4NF to a lower normal form would almost always lead to excessive data maintenance problems. The objective is to improve system response time without incurring a prohibitive amount of additional data maintenance requirements. Additional consideration may be given table partitioning that goes beyond the issues that surround table normalization. unseen ad hoc data queries may be adversely affected by denormalized table structures. Vertical partitioning may improve performance by minimizing the size of rows involved in table joints. The resulting 4NF solution. 2NF. If denormalization offers the promise of improving performance among the entities that are paired in these binary relationships. DENORMALIZING HIGHER NORMAL FORMS The concept of denormalizing also applies to the higher order normal forms (fourth normal form . since the important issue for salesperson's usually revolves around whether or not they get paid their commission.5NF). the 5NF modeling problem is the mirror-image of the 4NF problem. then the guidance given earlier under each of the individual 1NF. A 5NF anomaly only arises when a database designer has modeled what should be a ternary relationship as a set of two or more binary relationships. This analysis must include the identification of primary and secondary access paths to data. Horizontal table partitioning may improve performance by minimizing the number of rows involved in table joins. we find that the requirement to support name changes for salespeople is very small. This is especially important for client-server systems.4NF or fifth normal form . the necessity to update the Order table in such a situation is a decision for management to make.salesperson name could easily be recorded to the denormalized Order table at the time that the order transaction takes place. and only occurs. While denormalization may also be used in 5NF modeling situations. An entirely conceivable notion is that such data maintenance activities may be ignored. Denormalization must be accomplished in conjunction with a detailed analysis of the tables required to support various end-user views of the database. thus. Oracle Varray and Nested table performance Oracle Tips by Burleson Consulting . and the denormalized 2NF solution supports payroll activities as well as the production of standard end-user views of the database. and 3NF sections applies. Recall that denormalization is used to improve processing efficiency. denormalization with 4NF would not require new heuristics. but occurrences of the application of denormalization in these situations are rare. but should not be used where there is the risk of incurring excessive data maintenance problems. Furthermore. This is because the number of tables required for data storage have already been minimized. By definition. SUMMARY This article has described situations where denormalization can lead to improved processing efficiency. Denormalization requires thorough system testing to prove the effect that denormalized table structures have on processing efficiency. In this situation. for the most part. Once a sales transaction takes place. when modeled in the form of an E-R diagram usually results in two binary one-tomany relationships. the tables that result from the application of 5NF principles are rarely candidates for denormalization. One should also question the need to maintain the consistency of data between the Order and Salesperson tables. the probability of changing the salesperson credited with making the sales is very unlikely. A detailed discussion of table partititioning my be found elsewhere [1]. we normalize to 4NF to avoid the problem of having to add multiple records to a single table as a result of a single transaction. when a salesperson changes names due to marriage. Data anomalies associated with 4NF violations only tend to arise when sets of binary relationships between three entities have been incorrectly modeled as a ternary relationship. Furthermore. In essence.

Oracle supports the full use of binary large objects (BLOB). For a full treatment of the performance of nested tables vs. This technique also lets you prebuild aggregate objects. 24.It is now possible to violate first normal form and have a cell in a table that contains a pointer to repeating table values. varray tables. It is a challenge to many Oracle design professionals to know when to use these Oracle data model extensions. an EMPLOYEE table could contain a pointer called JOB_HISTORY_SET.Datatypes can be placed within other user-defined datatypes to create data structures that can be easily reused within Oracle tables and PL/SQL. and object-oriented table structures. The ability of Oracle to support object types (sometimes called user-defined datatypes) has profound implications for Oracle design and implementation. see my book "Oracle Tuning: The Definitive Reference". you could create a type called FULL_ADDRESS that contains all of the subfields necessary for a complete mailing address. Allow "pointers" to non-database objects in a flat file . such that you could preassemble all of the specific rows that comprise the aggregate table. It even treats flat data files as if they were tables within the Oracle database. which in turn contains a datatype called JOB_HISTORY. Nest user-defined datatypes . nested tables. non–first-normal-form table structures (VARRAY tables).For example.This would alleviate the need for relational • • . and so on. The ability to store these row IDs inside a relational table extends the traditional relational model and enhances the ability of an object-relational database to establish relationships between tables. a table cell could contain a pointer to a flat file that contains a non-database object such as a picture in . This article provides a brief review of advanced Oracle topics and how they are used to design high-performance Oracle databases. 2002. you could create a datatype called CUSTOMER that contains a datatype called CUSTOMER_DEMOGRAPHICS.Aggregate datatypes are datatypes that contain other datatypes.gif or .jpeg format. The new abilities of pointer data types include: • Referencing "sets" of related rows in other tables . For example. updated 1 November 2008 Oracle offers a variety of data structures to help create robust database systems. which in turn could contain pointers to all of the relevant rows in a JOB_HISTORY table. For example. For example. User-defined datatypes will enable the database designer to: • Create aggregate datatypes . a pointer is a unique reference to a row in a relational table. • One of the new user-defined data types in the Oracle object-relational model is a "pointer" data type.April. The ability to establish one-to-many and many-to-many data relationships without relational foreign keys . Essentially.

each Oracle developer was essentially a custom craftsman writing custom SQL to access Oracle information. and all processes that manipulate the object are encapsulated inside Oracle's data dictionary. By using member methods. This functionality has huge benefits for the development of all Oracle systems. Oracle can use arrays of pointers to represent these complex objects. you could retrieve rows from other tables without ever using the time-consuming SQL JOIN operator. Removing unnecessary table joins—This is achieved by deliberately introducing redundancy into the data model. Queries that required complex and time-consuming table joins can now be retrieved in a single disk I/O operation.JOIN operations. the Oracle developer’s role changes from custom craftsman to more of an assembly-line coder. because table columns could contain references to rows in other tables. • • . By dereferencing these pointers. a member method can be created upon the Oracle object. Data model extension capabilities The Oracle table data model extensions provide the following capabilities: • Modeling real-world objects—It is no longer required for the relational database designer to model complex objects in their smallest components and rebuild them at run-time. real-world objects can have a concrete existence just like c++ objects. In Oracle. Coupling of data and behavior—One of the important constructs of object orientation is the tight coupling of object behaviors with the objects themselves. You simply choose from a list of prewritten member methods to access Oracle information. This way. all interfaces to the Oracle database are performed using pre-tested methods with known interfaces. Prior to the introduction of member methods. Using Oracle's object-oriented constructs.

prior_employer_name_arr( employer_name('IBM'). . employer_name('ATT'). below is an Oracle table created with abstract data types and a nested table.Object orientation and Oracle Oracle offers numerous choices for the introduction of object-oriented data model constructs into relational database design. In addition. and limited polymorphism and inheritance support. we use extensions to standard Oracle SQL to update these abstract data types. abstract data types. data model constructs used in C++ or Smalltalk programming can be translated directly into an Oracle structure. For example. CHAR. CREATE OR REPLACE TYPE employee AS OBJECT ( last_name varchar(40).'Rocky Ford'. and DATE. Next.'NC'. insert into emp values ( 'Burleson'. full_mailing_address_type('7474 Airplane Ave. employer_name('CNN') ) ). prior_employers prior_employer_name_arr ).'. VARCHAR. Oracle offers the ability to dereference table row pointers. create table emp of employee. full_address full_mailing_address_type. In Oracle. Oracle supports abstract data typing whereby you create customized data types with the strong typing inherent in any of the standard Oracle data types like NUMBER.'27445').

At runtime. Oracle allows similar constructs whereby the components of the complex objects reside in real tables with pointers to the subordinate objects. One of the remarkable extensions of Oracle is the ability to reference Oracle objects directly by using pointers as opposed joining relational. In order to support the concrete existence of complex objects. Next. Whereas a person is likely to have a small number of previous employers. subordinate data items can be directly linked to the base table by using Oracle's newest construct:. Proponents of the object-oriented database model criticize standard relational databases because of the requirement to reassemble an object every time it is used.Oracle nested tables Using the Oracle nested table structure. (They make statements such as “It doesn’t make sense to dismantle your car every time you are done driving it and rebuild the car each time you want to drive it. a nested table is used to represent a repeating group for previous addresses. Just as a C++ program can use the char** data structure to have a pointer to an array of pointers. the object ID (OID). we create a type using our full_mailing_address_type: create type prev_addrs as object (prior_address full_mailing_address_type ). Oracle introduced the ability to build arrays of pointers with row references directly to Oracle tables. A nested table example In this example.”) Nested and varray tables use internal pointers Oracle has moved toward allowing complex objects to have a concrete existence. we create the nested object: . Oracle simply needs to dereference the pointers. most people have a larger number of previous addresses. and the complex object can be quickly rebuilt from its component pieces. First.

create table employee ( full_name full_mailing_address_type. The locator enables Oracle to use the pointer structures to dereference pointers to the location of the nested rows. current_address full_mailing_address_type. Now. The link to the nested tables uses an Oracle OID instead of a traditional foreign key value. returning the entire nested table at query time can be time-consuming. you can dereference the OID and see the data for that customer. previous_employer_two varchar(40). create table emp1 ( last_name char(40). last_name varchar(40). A nested table appears as a part of the master table. previous_employer_three varchar(40) ). .create type nested_address as table of prev_addrs. we would need to represent repeating groups in a table in a very clumsy and non-elegant fashion. In many cases. previous_employer_one varchar(40). if you have a pointer to a customer row. A pointer dereference happens when you take a pointer to an object and ask the program to display the data the pointer is pointing to. we create the parent table with the nested table. In other words. The store as clause allows the DBA to give the nested table a specific name: The nested_prev_address subordinate table can be indexed just like any other Oracle table. Internally. it is a separate table. A varray table example Before Oracle8. Also. notice the use of the return as locator SQL syntax. prev_address nested_address ) nested table prev_address store as nested_prev_address return as locator.

'Rocky Ford'. embedding our varray of prior employers. prior_employer_name_arr( employer_name('Oracle'). employer_name('CNN') ) ). we create the employee type. full_mailing_address_type('7474 Bearpond Ave. prior_employer_name_arr( employer_name('IBM'). insert into emp values ( 'Burleson'. prior_employers prior_employer_name_arr ). full_address full_mailing_address_type. we create the emp table. . insert into emp values ( 'Lavender'.'NC'. Now we insert rows into the object table.'17545'). Next.'. employer_name('ATT'). CREATE OR REPLACE TYPE prior_employer_name_arr AS VARRAY(10) OF employer_name. Next. full_mailing_address_type('7474 Airplane Ave. CREATE OR REPLACE TYPE employer_name AS OBJECT (e_name varchar(40)) . Note the use of the full_mailing_address_type reference for the ADT and the specification of the repeating groups of previous employers.'. using the employee type.We begin by creating a Oracle type to hold the repeating group of prior employers. CREATE OR REPLACE TYPE employee AS OBJECT ( last_name varchar(40).'NC'. SQL> create table emp of employee.'Big Lick'.'27445'). Table Created.

Overall. re-displaying the information. Next. select p. SELECT emp. PRIOR_EMPLOYERS(E_NAME) ----------------------------------------------------------------PRIOR_EMPLOYER_NAME_ARR(EMPLOYER_NAME('IBM').prior_employers from emp p where p. Note that we can select all of the repeating groups with a single reference to the prior_employers column. column l_name heading "Last Name" format a20. employer_name('Computer Associates') ) ). In the example below. the performance of .* FROM emp emp.employer_name('Sybase').prior_employers) prior_emps WHERE p. we use a new BIF called table that will flatten-out the repeating groups. Here we see a flattened output from the query. prior_emps.last_name = 'Burleson'. and the single information is replicated onto each table row. table(p. we need to take a look at the SQL performance ramifications of using object extensions.----------------------------------Burleson Burleson ATT Burleson CNN IBM Performance of Oracle nested and varray tables To fully understand Oracle advanced design. Last Name E_NAME -------------------.last_name l_name. EMPLOYER_NAM E('CNN')) This output can be difficult to interpret because of the nature of the repeating groups. we perform the select SQL.last_name = 'Burleson'. EMPLOYER_NAME('ATT').

and those unique data structure extensions that make Oracle clearly one of the fastest and most robust databases in the marketplace . the longer row length of varray tables causes fulltable scans to run longer. Varray tables are also problematic because the nonstandard SQL is very clumsy and hard to use: SQL> SELECT * FROM person. and the items inside the varray cannot be indexed. More importantly. NAME DOB -----------------------------. Relational professionals can no longer stay content with a basic understanding of relational algebra. 'Line 3') • • Conclusion The evolution of Oracle into an object-relational database has provided a huge number of extensions to the relational database model.--------ADDRESS_V ---------------------------------------------ADDRESS_N ------------------------------------------------------Jones 01-JAN-60 ADDRESSES_V('Line 1'. However.Abstract Data Type (ADT) tables is the same as any other Oracle table. it sometimes takes longer to dereference the OID to access the nested table entries as opposed to ordinary SQL tables join operations. Most Oracle experts see no compelling benefit of using nested tables over traditional table joins. 'Line 2'. Nested tables allow for an infinite number of repeating groups. varrays cannot be used when the number of repeating items is unknown or very large. Doing ADTs also provides uniform data definitions for common data items. and the only downside for SQL syntax is the requirement that all references to ADTs be fully qualified. including abstract data typing. However. but we do see significant performance differences when implementing varray tables and nested tables: • ADT tables—Creating user-defined datatypes simplifies Oracle database design. and the repeating groups are separated into another table so as not to degrade the performance of full-table scans. It is the challenge of all Oracle design professionals to use these Oracle extensions to improve the performance and maintainability of Oracle databases. The successful Oracle designers must master all object-oriented concepts. Nested tables—Nested tables have the advantage of being indexed. There is no downside for SQL performance. 'Line 2'. nested tables. array tables. 'Line 3') ADDRESSES_N('Line 1'. Varray tables—Varray tables have the benefit of avoiding costly SQL joins. and they can maintain the order of the varray items based upon the sequence when they were stored.

Sign up to vote on this title
UsefulNot useful