Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-02-20
2004-10-26
Rones, Charles (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000
Reexamination Certificate
active
06810400
ABSTRACT:
TECHNICAL FIELD
This invention relates to databases, database management systems, and database management schemas.
BACKGROUND
Database management systems (DBMS) are core components of virtually every enterprise (e-business) application. The ability to effectively configure, monitor, and manage a DBMS is critical to the success of enterprise applications.
Most DBMSs are designed for compatibility with relational databases. A relational database comprises a plurality of tables. Each table has a plurality of data records (rows) and each table includes a definition of the fields (columns) that the records will contain. A relational database includes the specification of relationships between fields of different tables. A DBMS performs common management tasks such as creating databases, adding tables, replication management, data backup, etc.
The Desktop Management Task Force (DMTF) Common Information Model (CIM) is an approach to the management of systems, software, users, and networks that applies the basic structuring and conceptualization techniques of the object-oriented paradigm. More specifically, the purpose of CIM is to model various computer-related systems—both hardware and software. It is important to recognize that object-oriented modeling is different from object-oriented programming.
This type of modeling uses schemas to represent systems. A schema is an abstraction of something that exists in the real world. Generally, a schema comprises a collection of classes and associations.
A class models a set of objects that have similar properties and fulfill similar purposes. In a database management schema, for example, individual classes might define such things as files, users, tables, etc.
Classes follow a hierarchical structure. Classes can have subclasses, also referred to as specialization classes. The parent class of a subclass is referred to as a superclass or a generalization class. A class that does not have a superclass is referred to as a base class.
A typical schema might comprise a collection of different schemas, which in this case can also be referred to as subschemas. Such subschemas are often located in various different namespaces. A namespace is simply a way to logically group related data. Within a given namespace, all names are unique. Within the following disclosure, the terms “schema” and subschema are used interchangeably.
A subclass inherits properties of its superclass. All properties and methods of a superclass apply to the subclass.
It is conventional to represent a class by a rectangle containing the name of the class.
FIG. 1
shows an example. A class with properties is represented by a rectangle divided into two regions as in
FIG. 2
, one containing the name of the class and the other a list of properties. Inheritance, or a subclass/superclass relationship, is represented by a line drawn between the subclass and the superclass, with an arrow adjacent to the superclass indicating the superclass. Lines representing inheritance are shown in
FIG. 3
, indicated by reference numeral
10
.
Classes contain instances that are collections of values that conform to the type established by the class. Instances are identified by keys that are unique within the class. In other words, no two instances in the same class in the same namespace may have the same values for all of their key values. The term “object” may be used to refer to either an instance or a class.
An association represents a relationship between two or more objects. More specifically, an association is a mechanism for providing an explicit mapping between classes. Associations can be within a namespace or across namespaces. Associations are conventionally shown as a line between two classes, as indicated by reference number
12
in FIG.
3
.
CIM schemas describe the gamut of managed elements: servers and desktops (operating systems, components, peripherals, and applications, all layers of the network (from Ethernet switches to IP and HTTP connections), and even end-users. Schema properties model the attributes that apply to objects, such as the type of printer or storage medium, RAM and CPU capacity, storage capacity, etc.
The discussion above gives a general overview of object-oriented modeling and CIM. Please refer to Winston Vumpus, John W. Sweitzer, Patrick Thompson, Andrea R. Westerinin, and Raymond C. Williams;
Common Information Model
, John Wiley & Sons, Inc., New York (2000) for further information regarding CIM. Also refer to Common Information Model (CIM) Specification, V2.0, Mar. 3, 1998, available from the Distributed Management Taskforce. DMTF has a number of other resources on its Internet web site.
SUMMARY OF THE INVENTION
A database schema described herein is an extension of the CIM core model. It has database classes that represent various database objects (e.g., tables, views, etc.) and user classes that represent users and roles of the database.
Unique to the database schema is a set of one or more permission classes that represent permissions of the users/roles with respect to the database objects. The permission classes are modeled in the database schema as associations between database object classes and user/role classes. By modeling the permissions as associations, the database schema effectively models methods of granting, denying, and revoking privileges. Additionally, the database schema provides a convenient way to query for users and roles that have permissions to utilize various database objects.
REFERENCES:
patent: 5569207 (1996-10-01), Gisselberg et al.
patent: 5596745 (1997-01-01), Lai et al.
patent: 5692129 (1997-11-01), Sonderegger et al.
patent: 5794030 (1998-08-01), Morsi et al.
patent: 5937409 (1999-08-01), Wetherbee
patent: 5956725 (1999-09-01), Burroughs et al.
patent: 5956730 (1999-09-01), Burroughs et al.
patent: 6081808 (2000-06-01), Blackman et al.
patent: 6085198 (2000-07-01), Skinner et al.
patent: 6125363 (2000-09-01), Buzzeo et al.
patent: 6134559 (2000-10-01), Brumme et al.
patent: 6157928 (2000-12-01), Sprenger et al.
patent: 6163776 (2000-12-01), Periwal
patent: 6170005 (2001-01-01), Meandzija
patent: 6243709 (2001-06-01), Tung
patent: 6289339 (2001-09-01), Weber
patent: 6317748 (2001-11-01), Menzies et al.
patent: 6330555 (2001-12-01), Weber
patent: 6374252 (2002-04-01), Althoff et al.
patent: 6374256 (2002-04-01), Ng et al.
patent: 6405202 (2002-06-01), Britton et al.
patent: 6493719 (2002-12-01), Booth et al.
patent: 6496833 (2002-12-01), Goldberg et al.
patent: 2002/0059293 (2002-05-01), Hirsch
patent: 2002/0107872 (2002-08-01), Hudis et al.
patent: 2002/0116385 (2002-08-01), Kagalwala et al.
patent: 2002/0156790 (2002-10-01), Kagalwala et al.
Kagalwala Raxit A.
Thompson John Patrick
Abel-Jalil Neveen
Lee & Hayes PLLC
Microsoft Corporation
Rones Charles
LandOfFree
Representing database permissions as associations in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Representing database permissions as associations in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Representing database permissions as associations in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3314984