Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-03-30
2004-04-13
Amsbury, Wayne (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C717S165000
Reexamination Certificate
active
06721758
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to computer-based directory services, and more particularly to a system and method for using schema attributes as meta-data in a directory service.
BACKGROUND OF THE INVENTION
Computer systems generally comprise two or more computers networked together to enable the sharing of applications, services, and information. Most computer systems store and maintain data (in various formats) relating to the many network resources that comprise the system. Examples of such resources may include, but are not limited to computers and various peripheral devices (e.g.—printers, RAID devices, etc.), as well as users, files, and e-mail addresses. Directory services are a valuable tool utilized by computer systems to aid in storing and maintaining this data.
A directory service typically identifies all of the resources on a network and makes them accessible to users and applications. Currently, many computer systems utilize distributed directories. A distributed directory is a single directory that spans (and is shared by) multiple networking servers. Most distributed directories are based on the X.500 ITU (International Telecommunication Union) standard which structures directories in a hierarchical fashion, having different levels for different categories of information. Many directory service providers utilize hierarchical databases, which may be referred to as either “directory service databases” or “directory service repositories.” Distributed directories based on the X.500 standard allow for information to be created, read, and modified by clients having the appropriate access rights. This information may be shared across a plurality of servers and clients.
One example of a well-known directory service or system that uses a distributed directory with a hierarchical database structure is NetWare Directory Services™ (“NDS”) by Novell Corporation. The structure of at least one NDS directory system may be understood by defining terms such as meta-data, schema, and instance.
Traditionally, meta-data in a directory system may describe the syntax or format of data so that the system may understand how data is being represented in the system. Meta-data may also specify that a directory system may have attributes, and that these attributes may be grouped into entities known as classes. Generally, meta-data defines the model for schemas in a directory system.
A schema typically defines a set of attributes that are defined together to define or describe a class. NDS allows network administrators to create classes in the schema using attributes defined by the administrators. Each attribute in a class has certain information associated with it, such as an attribute name and an attribute syntax type. The attribute name identifies the attribute, while the attribute syntax limits the values that are assumed by the attribute. In addition to defining attributes or properties, classes may also contain other meta-data describing the behavior of the class.
Once a network administrator has created a class, users having appropriate access rights may then create objects based on that class. These objects, also referred to as instances of the class, are then entered into the distributed directory. Multiple instances of the same class may exist in a directory as long as each possesses a unique name. Although objects in a distributed directory tend to represent computer-related entities (e.g.—computers, printers, users), those skilled in the art understand that objects may also represent a variety of non-computer-related entities such as companies, departments, buildings, or the like.
One feature of directory service hierarchical databases allows for classes to be derived from (or based upon the declaration of) other classes. This concept, known as inheritance, is explained with reference to FIG.
1
.
FIG. 1
illustrates a portion of a distributed directory
100
wherein each block illustrated represents a class. For ease of explanation, assume that a help desk policy class
110
exists in distributed directory
100
, and is derived from (or based on the declaration of) a general policy class
120
, a WINDOWS 98™ type policy class
130
, a user type policy class
140
, and a scheduled feature policy class
150
. Because help desk policy class
110
is derived from policy classes (
120
,
130
,
140
,
150
), any instances (or objects) of the help desk policy class
110
created in directory
100
must contain all of the mandatory attributes defined by its own class definition (which may be none), as well as all of the mandatory attributes defined in the class definitions of policy classes (
120
,
130
,
140
,
150
). This is because valid instances or objects of a derived class must include the mandatory attributes of the base class or classes from which it is derived. Help desk policy class
110
may be referred to as a derived class or subclass because it inherits the characteristics of policy classes (
120
,
130
,
140
,
150
). In turn, policy classes (
120
,
130
,
140
,
150
) are referred to as base classes or super classes because their characteristics are inherited by another class, namely help desk policy class
110
. It should be recognized that
FIG. 1
is an illustration of multiple inheritance, as the derived help desk policy class
110
is inheriting the characteristics of more than one base class.
Through the derivation described above, the directory system may now make a determination that help desk policy class
110
is a policy class that is acceptable for WINDOWS 98™ systems, and for users, and that it is a policy class that may be scheduled. Such a determination may be made by examining the names of the base policy classes (
120
,
130
,
140
,
150
) that help desk policy class
110
is derived from. Since the names of the base policy classes (
120
,
130
,
140
,
150
) are well known and constant, and because help desk policy class
110
is derived from these base policy classes, the system is able to make this determination about the help desk policy class
110
and any eventual instances of the help desk policy class
110
that may be created.
Those skilled in the art will realize that policy classes (
110
,
120
,
130
,
140
,
150
) are but a few representative examples of policy classes that may be created to manage resources of a computer system such as users, workstations, or servers. These policy classes may also apply to various operating systems and may be capable of supporting various features.
One drawback associated with using hierarchical database structures is that derivation is generally a one-time process. In other words, when an administrator or other individual creates a new subclass that is to be derived from a base class, he or she may be limited in the future to only those attributes that were included in the class definition of the new subclass at the time of creation.
In
FIG. 1
, for example, help desk policy class
110
was derived from policy classes (
110
,
120
,
130
,
140
,
150
) and was defined to include any new attributes along with the attributes that were inherited from policy classes (
110
,
120
,
130
,
140
,
150
). If a network administrator, in the course of organizing or managing objects or instances of classes, later discovers that help desk policy class
110
shares the structure and behavior of some other existing base class (not shown), it may be disadvantageous for the help desk policy class
110
to derive from this newly discovered base class. If the help desk policy class
110
is allowed to derive from the newly discovered base class, any subsequent objects or instances of the help desk policy class
110
created would conflict with objects or instances of the help desk policy class
110
already in existence. The network administrator would most likely be forced to create a new help desk policy class and re-create all of the old objects already in existence.
The inability to modify a class schema by adding attributes later may result in an inflexible and inefficient system. T
Brough Farrell Lynn
Jex Alan R.
Tanner Ronald M.
Amsbury Wayne
Mintz Levin Cohn Ferris Glovsky and Popeo PC
Novell Inc.
LandOfFree
System and method for using schema attributes as meta-data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for using schema attributes as meta-data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for using schema attributes as meta-data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3223773