Method and system for representing and accessing...

Details Method and system for representing and accessing... Method and system for representing and accessing...

1998-12-07

2003-07-01

Coby, Frantz (Department: 2171)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000, C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06587856

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is related to the storage of data within database systems. More particularly, the present invention is directed to the storage and access of object-oriented entities within a relational database management system.
2. Background
Many computer programming languages and applications utilize object-oriented structures to model real world information. Object-oriented languages and applications access and store data in the form of entities such as objects and attributes. For example, many conventional applications used for querying and maintaining directory information systems are modeled using aspects of object-oriented techniques and entities. Directory information systems provide a framework for the storage and retrieval of information that are used to identify and locate the details of individuals and organizations, such as telephone numbers, postal addresses, and email addresses.
One common type of object-oriented based directory systems is a directory based on the Lightweight Directory Access Protocol (“LDAP”). LDAP is a directory protocol that was developed at the University of Michigan, originally as a front end to access directory systems organized under the X.500 standard for open electronic directories (which was originally promulgated by the Comite Consultatif International de telephone et Telegraphe “CCITT” in 1988). Standalone LDAP server implementations are now commonly available to store and maintain directory information. Further details of the LDAP directory protocol can be located at the LDAP-devoted website maintained by the University of Michigan at http://www.umich.edu/~dirsvcs/ldap/, including the following documents (which are hereby incorporated by reference): RFC-1777 Lightweight Directory Access Protocol; RFC-1558 A String Representation of LDAP Search Filters; RFC-1778 The String Representation of Standard Attribute Syntaxes; RFC-1779 A String Representation of Distinguished Names; RFC-1798 Connectionless LDAP; RFC-1823 The LDAP Application Program Interface; and, RFC-1959 An LDAP URL Format.
LDAP directory systems are normally organized in a hierarchical structure having entries (i.e., objects) organized in the form of a tree, which is referred to as a directory information tree (“DIT”). The DIT is often organized to reflect political, geographic, or organizational boundaries. A unique name or ID (which is commonly called a “distinguished name”) identifies each LDAP entry in the DIT. An LDAP entry is a collection of one or more entry attributes. Each entry attribute has a “type” and one or more “values.” Each entry belongs to one or more object classes. Entries that are members of the same object class share a common composition of possible entry attribute types.
Referring to
FIG. 1
, shown is an example of a hierarchical tree of directory entities. Entry
96
is the top most level of DIT
20
and is of object class “organization” having an attribute type “Org. Name” with an attribute value of “Oracle”. Entry
96
is the “parent” entry for three “child” entries (
97
,
98
, and
99
) directly beneath it in DIT
20
. Entries
97
,
98
, and
99
are objects of object class “Department” each having attributes “Dept. Name” and “State.” Entry
97
has an attribute type “Dept. Name” having a value of “Administration” and an attribute type “State” with the value “CA”. Entry
98
has an attribute “Dept. Name” with the value “Sales” and an attribute type “State” with an attribute value “NY”. Entry
99
has an attribute type “Dept. Name” with an attribute value “R&D” and an attribute type “State” with a value of “CA”.
Entry
103
is a child entry of entry
97
. Entry
103
represents an object of class “Person” having the following attribute type-value pairs: (1) attribute type “Last Name” with a value of “Founder”; (2) attribute type “First Name” with a value of “Larry”; (3) attribute type “Tel. No.” with a value of “555-4444”; and (4) attribute type “State” with a value of “CA”.
Entry
102
is a child entry of entry
98
. Entry
102
represents an object of class “Person” having the following attribute type-value pairs: (1) attribute type “Last Name” with a value of “Jones”; (2) attribute type “First Name” with a value of “Joe”; (3) attribute type “Tel. No.” with a value of “555-3333”; (4) attribute type “Manager” having the value of “Jim Smith”; and (5) attribute type “State” having the value “CA”. Note that entries
102
and
103
are both members of object class Person, but entry
102
has more listed object attributes than entry
103
. In many object-oriented systems, objects that are members of the same object class may share a common set of possible object attributes, but some members of the class may not necessarily have values for some of the possible attributes. In this example, entry
103
does not have a value for attribute type “Manager” while entry
102
does have a value for this attribute.
Entries
100
and
101
are child entries of entry
99
. Entries
100
and
101
are both members of object class “Person.” Entry
100
is defined by the following attribute type-value pairs: (1) attribute type “Last Name” with a value of “Doe”; (2) attribute type “First Name” with a value of “John”; (3) attribute type “Tel. No.” with a value of “555-1111”; (4) attribute type “Manager” having the value of “Larry Founder”; and (5) attribute type “State” having the value “CA”. Entry
101
is defined by the following attribute type-value pairs: (1) attribute type “Last Name” with a value of “Smith”; (2) attribute type “First Name” with a value of “Jim”; (3) attribute type “Tel. No.” with a value of “555-2222”; and (4) attribute type “Manager” having the value of “John Doe”; and (5) attribute type “State” having the value “NY”.
One significant issue that has been faced by organizations seeking to develop an LDAP system is the selection of the type and configuration of a database system used to store the object-oriented LDAP data. A particularly desirable choice for many database configurations is to utilize a relational database management system (“RDBMS”). The relational database model provides many benefits when implementing a database application. For example, the relational database model has well-defined structures and entities (e.g., tables, views, indexes, etc.) to store or access the data of a database. RDBMS systems provide advanced database transaction, data consistency, recovery, and backup support. RDBMS systems also provide for clearly defined actions and operations to manipulate the data and structures of the database. Moreover, many RDBMS applications are designed to interoperate with standard database query languages (e.g., SQL) to access and modify data on the system.
The difficulty with implementing object-oriented applications, such as LDAP directory systems, in an RDBMS is that object-oriented data are based upon a fundamentally different data model than relational data. Object-oriented data are formed as entities which have specific object-oriented characteristics (e.g., objects and attributes). In contrast, the data in a relational database model are normally stored in database tables that are organized as an array of rows and columns. The values in the columns of a given row are typically associated with each other in some way. For example, a row may store a complete data record relating to a sales transaction, a person, or a project. Columns of the table define discrete portions of the rows that have the same general data format or data type. Thus, there are significant differences in structure between object-oriented data and relational data.
FIGS. 2A
,
2
B, and
2
C depict one approach to storing object-oriented data, such as the entries from DIT
20
of
FIG. 1
, into an RDBMS. In this approach, a separate table is provided for each object class in the system.
FIG. 2A
shows an object class table
202
for the Organization class, which includes entry
96
from DIT
20
as a member of that class.
FIG. 2B
is an example of an object class table
204
for the ob

Affiliated with

Also associated with

Rating

Method and system for representing and accessing... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method and system for representing and accessing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for representing and accessing... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3008257