Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-12-07
2004-10-26
Rones, Charles (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C709S201000
Reexamination Certificate
active
06810399
ABSTRACT:
CROSS-REFERENCE TO RELATED APPLICATIONS
Not Applicable
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not Applicable
INCORPORATION BY REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISC
Not Applicable
BACKGROUND OF THE INVENTION
(1) Field of the Invention
The present invention relates to a repository which stores properties of database objects and in particular to a metadata repository for a relational database.
(2) Description of Related Art
Relational databases generally comprise of two main portions, namely an informational database which stores data in the form of objects, and a metadata repository which stores information concerning the properties of the objects.
Thus, for example, in Oracle's Discoverer database, the metadata defining the properties of objects stored within the database are contained within the EUL (End User Layer) of the database.
This system allows the data stored in the informational database to be updated, whilst the properties of the data can be maintained separately in the repository.
Typically, the properties of the database objects are stored in the metadata repository in the form of object tables. In general, each object table defines the properties of a respective type of object contained within the database, with each row in the table defining the properties for a specific object.
Thus for example, “Folder” objects contained within the database would have a corresponding “Folder” table within the metadata repository. The folder table defines the properties of all of the “Folder” objects, with the properties of each object being set out on a respective row of the table. A typical example of such an object table is shown in FIG.
1
and will be described in more detail below.
The structure of both the informational database and the metadata repository, are determined by the database designers. The tables used in the metadata repository have a fixed structure which allows a limited number of properties to be defined, as envisaged by the database designers.
Typically, relational databases are provided centrally for a number of different clients. In this case, the properties of the objects are initially set by the database operators.
However, it is common for different clients using the database to want to add in additional properties for certain database objects. Currently, this can only be achieved by having each respective user define their own property information in an alternative data store, separate from the repository.
In this case, the additional property information, which for example could be stored on the user's own personal computer, must then be referenced back to the respective object in the repository.
However, there are a number of disadvantages to this technique. Firstly, there is no longer a single source of truth for the properties of the database objects. This means, that should the properties of the object need to be referred to, then it is necessary to check both the repository and the separate data store to ensure all the property data is retrieved.
Secondly, there is no integrity between the separate data sources. Accordingly, if the element is removed from the original repository there is no effect on the additional information provided in the secondary data store.
Thirdly, transferring or duplicating the repository requires having separate processes for moving the additional property information. Thus, if the additional property information is to be provided to an alternative user, it must be copied from the original user's processing system and onto the additional user's processing system.
As an alternative, repositories can utilise a fixed set of attributes for client extensions. This allows clients to define a limited number of properties for each object. However, because of the use of the fixed table structures within the repository, this has the disadvantage that there is a limit to the number of extended attributes and there is a limit to the size of any individual extended attributes, thereby limiting the properties that can be defined.
BRIEF SUMMARY OF THE INVENTION
In accordance with the present invention, we provide a repository which stores properties of database objects, the repository including:
a. a first store for storing a number of predetermined properties;
b. a second store for storing additional properties; and,
c. a processor coupled to the first and second stores for determining or modifying the properties stored in the first and second stores for at least one of the database objects.
Accordingly, the present invention provides a repository which stores properties of database objects. The repository includes a first store for storing predetermined properties and a second store for storing additional properties. With both the first and second stores being provided within the repository, a processor can be used for accessing or modifying the properties within both stores simultaneously. This ensures that a single source of truth is provided for all the properties of the database objects, with integrity being maintained between the properties stored in the first and second store. Furthermore, by providing both first and second stores centrally within the repository, this overcomes the need for additional information to be located at a user's remote location, thereby ensuring that the property information is available to all users of the database.
Typically the first store comprises a fixed table structure, the predetermined properties of each object being stored in the respective portion of the fixed table structure. The properties of each object are generally stored in a respective row of the fixed table structure, with each property being stored in a respective column. In this case, each table generally relates to a different type of object with the properties of each object of the given type being stored in a respective row. However, alternative table structures may be provided. Thus, for example each table could include details of multiple types of object, or details of separate objects individually. Alternatively, the elements could be arranged in columns with the properties arranged in the rows of the table.
Typically, the second store comprises a segmented table structure, the additional properties of each object being stored in one or more respective portions of the segmented table structure. By using a segmented table structure, this allows a number of rows to be assigned to a given object (or element). This ensures that any number of properties can be stored for a given object thereby vastly increasing the versatility of the repository system.
Typically the additional properties of each object are provided as an XML file. This provides a simple way of allowing a user, or an operator of the database system, to define additional properties for objects within the database. The nature of XML files means that there is no limit to the number of additional properties that can be defined. Alternative techniques could however be used, such as the use of a simple text file or another SGML file format. However, the use of an XML file is particularly advantageous as it allows the elements, and attributes of the XML schema to be used to define the properties of the data.
Typically the XML file is divided into one or more segments which each segment being stored in a respective row of the segmented table structure. This allows the segmented table to store a limited number of characters in each row whilst still accommodating the entirety of the XML file, thereby ensuring that all the properties of the respective object are stored. However, the table may be modified to include an additional number of columns, for example with different portions of the XML file being stored in different columns.
The processor is usually adapted to extract the additional properties from the second data store by extracting and recombining the segments of the XML file. Once the XML file has been recombined, this allows the processor to determine the properties of the object contained within
Cave Stephen David
Fragapane Paolo
Lavender Robert Lloyd
Osborn Andrew
Steadman James Adam
Mahmoudi Hassan
Oracle International Corporation
Rones Charles
Swidler Berlin Shereff & Friedman, LLP
LandOfFree
Property extensions does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Property extensions, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Property extensions will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3306983