Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-09-28
2004-03-16
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06708186
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to database systems of the kind which store metadata in catalogs or data dictionaries and more specifically to techniques for reading and manipulating the metadata.
2. Description of Related Art
FIG. 1
provides an overview of the invention disclosed herein. A preferred embodiment of the invention is implemented in an improved version of the Oracle8™ Server, manufactured by Oracle Corporation, Redwood City, Calif. The Oracle8 server includes an object-relational database system. The object-relational database system appears in
FIG. 1
as DBMS
103
; prior to modification as required for the invention, DBMS
103
includes database
108
, together with those tables
107
in data dictionary
106
that are required to implement database
108
.
Information is stored in DBMS
103
as objects. In
FIG. 1
, all objects have the reference number
105
. Objects are divided into classes according to the kind of information they contain. Shown in
FIG. 1
are objects of the TABLE class
141
, the TRIGGER class
143
, the INDEX class
145
, the UDT (user-defined type) class
147
, and the VIEW class
149
. Many other classes of objects exist as well in DBMS
103
. Object classes that are of particular importance for the present discussion are TABLE class
141
, UDT class
147
, and VIEW class
149
. DBMS
103
is a relational database system. In such systems, most of the data is stored in objects of TABLE class
141
. As implied by the name, an object of TABLE class
141
contains a table. The table is made up of rows and columns. Each row has a field for each of the columns. A column specifies a kind of data value and a row represents an entity which has values of the kinds specified by the column. For example, in a table for storing personal information, the columns might be called last_name, first_name, m_i, street_addr, and so forth, with each row representing a person and the fields in the row having the appropriate values for that person.
DBMS
103
is an object relational database system. In such a system, the data values in a column may be objects which have user-defined types or UDTs. For instance, a user might define a type called contact_info which contained fields for all of the contact information for an individual and a column in a table of persons might specify a field for which the values are objects of type contact_info. Objects of class UDT are objects with user-defined types.
The objects of the TABLE class are what is termed base tables, that is, the information contained in an object of the TABLE class is stored as a table in DBMS
103
's memory system. DBMS
103
has other tables which use the information contained in one or more base tables, but do not make separate copies of the information. These tables are termed views and the objects that represent views are objects of VIEW class
149
. Views can be used to combine information from a number of different base tables and even other views. A kind of view which is of particular interest in the present discussion is an object view. An object view is a view that is associated with a user-defined type. Each row in the table specified by the object view is an object of the user-defined type associated with the object view. The information which the object view obtains from the base tables either directly or via other views is mapped into fields of the objects which make up the rows in the view.
The objects in DBMS
103
belong either to data dictionary
106
or to database
108
. The information in data dictionary
106
is metadata, that is, information that defines all of the objects in DBMS
103
, those in database
108
, and also those in data dictionary
106
. In the Oracle8 server, most of the objects in data dictionary
106
are TABLE objects
105
that belong to system tables
107
. For example, there is a table named tab$ in system tables
107
that contains a row for every table defined in DBMS
103
, including the tables in system tables
107
.
A problem with present-day database systems is that there is no simple way of obtaining all of the metadata that describes an object
105
in DBMS
103
. For example, to obtain a definition of a TABLE object
141
, a user or a client executing a program written by a user may have to make over a dozen queries to retrieve table, column, object, partition, sub-partition, tablespace, index, grant, storage, nested-table and owner information associated with the base table. Moreover, in order to select the views to query, the user must know what subtype of object one is dealing with (e.g., relational vs. object table, partitioned vs. non-partitioned table, index-organized vs. heap table, temporary vs. persistent table), i.e., in order to obtain the metadata for an object, the user must have a good understanding of the structure of data dictionary
106
.
The difficulty of obtaining the metadata for an object adds to the expense and effort required to use and maintain DBMS
103
. For example, in today's networked environment, it is often useful to have partial copies of database
108
at different locations within the network. To make such a partial copy, one needs to extract the metadata from data dictionary
106
that defines the partial copy and then use that information to create the partial copy. Easy access to information about the logical structure of a database is of course also useful whenever one is modifying the database's logical structure. In present-day database systems, a user who wishes to obtain a useful definition of an object in the database faces three main problems:
No Simple Means of Obtaining Complete Database Object Definitions
Present-day database systems provide no facility which permits a user to obtain the complete definition of any object in DBMS
103
. The Oracle8 server provides an example of what is available in present-day systems for obtaining metadata from data dictionary
106
. The Oracle8 server provides a series of views onto data dictionary
106
, but, like the tables within the data dictionary itself, these views are normalized for efficiency; hence, several queries against multiple views need to be executed in order to retrieve the complete metadata for what is logically a single object in the database.
No Means to Perform Transformations on Database Object Definitions
Often, the reason for extracting a definition of an object is to transform it. For example, a client that is maintaining a local copy of a portion of a database generally wishes to perform transformations such as adding a column to a table, changing a table definition into a snapshot definition, changing object ownership, removing specific storage attributes, etc. Today, the client requires custom code to perform these sorts of transformations.
No Means to Generate Creation SQL DDL for Database Objects
Once an object's definition is extracted and perhaps transformed, a client invariably wants to recreate that object somewhere; perhaps in another schema of the source database or perhaps in some other target database. In SQL databases such as that provided by the Oracle8 server, objects are created by defining them in a data definition language (DDL) and then providing the DDL to the database system, which creates the object as defined in the DDL. Present-day database systems provide no simple way of getting from the metadata for an object to the DDL needed to create another such object. At present, the client must use custom code to produce this DDL from the metadata for the object.
The absence of a facility which makes it easy to obtain complete and accurate metadata for objects in the database also to put the metadata into a form which makes it easy not only to modify the metadata, but also to produce creation DDL from the metadata has led to large amounts of duplicated effort within the organizations that produce database systems and even larger amounts of duplicated effort within the organizations that use the database systems. It is thus an object of the invention
Barton Lee B.
Claborn George H.
Mizrahi Diane D.
Nelson Gordon E.
Oracle International Corporation
LandOfFree
Aggregating and manipulating dictionary metadata in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Aggregating and manipulating dictionary metadata in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Aggregating and manipulating dictionary metadata in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3251361