The present invention relates to a design for a database system, and in particular to methods, systems, and machine-readable media for designing and using a generic object database system.
Most data-driven applications use a relational database system to store information for multiple entities. Relational database systems store all data within tables, which include a set of rows and columns. Each row of the table is analogous to a record of a file and each column is analogous to a field of a record.
A relationship may be established between two tables in a relational database system by having one or more common columns in each of the two tables. Thus, rows from two tables may be joined by using the one or more common column values.
A database schema describes a structure of a database and defines data contents and relationships. Some relationships in a relational database system may be many-to-many relationships between two different types of entities. Many-to-many relationships permit one to relate each row in one table to many rows in another table, and vice versa. Such relationships are represented in a relational database system by defining a junction table, which is an intermediate table that is created to implement a many-to-many relationship between two entities. The intermediate table includes primary keys from the two entities as foreign keys.
If user requirements of a database system change, the database schema may require modifications. Such modifications may be difficult and time consuming, particularly if user requirements change frequently. For example, if a new entity (table) is to be added to a relational database system, the schema must be modified to define a new table. If the new entity has a many-to-many relationship with another entity, then a new junction table must be defined to implement the many-to-many relationship. If a new attribute is to be added to an entity, the schema must be modified to add a new column to the table corresponding to the entity. Further, in an n-tier system architecture, component code changes may also be required as a result of changes to the schema.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Embodiments discussed below relate to designing a schema to implement an object database system. A first table type may be defined in the schema that may include a layout for an object table. The object table may define an instance of an object in the object database system. A second table may be defined in the schema that may include a layout of an object relations table. The object relations table may define a type of relation between instances of at least two objects in the object database system. Each of the instances of the at least two objects may be defined by a respective entry of the object table.
In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description is described above and will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting of its scope, implementations will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Embodiments are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the invention.
Implementations consistent with the principles of the invention provide a database system that is flexible with respect to changes in user requirements. A generic database schema may be used to represent most common entity-relationship data requirements. The generic database schema may provide an ability to add or remove entities without a need to modify a physical database schema.
Implementations that use a generic database schema may fulfill data store requirements for most applications that include a typical entities-relationship model. Such implementations may accommodate any number of entities, or objects, each of which may have any number of attributes, or object properties. Further any number of one-to-many or many-to-many relationships, or object relations, may be generated between any of the entities. New objects, object relations and object properties may be created at run-time without altering the physical database schema.
Network 102 may include a number of different types of networks, such as, for example, a packet-switching network, a wireless network, an ATM network, a Frame Relay network, an optical network, a Public Switched Telephone Network (PSTN), the Internet, or an intranet or other types of networks, or any combination of the above networks.
First processing device 104 may be a stand-alone processing system that includes a database system consistent with the principles of the invention. First processing device 104 may be used by a number of different users and applications that access the database system.
Second processing device 106 may be a processing device that includes a database system and may act as a server to client processing devices that may include applications for accessing the database system of second processing device 106 via network 102.
Third processing device 108 may be a processing system that may act as a client processing device and may include applications that access the database system of second processing device 106 via network 102.
System 242 may include a hard disk drive 256 for reading from and writing to a hard disk (not shown), a magnetic disk drive 258 for reading from and writing to a removable magnetic disk (not shown), and an optical disk drive 262 for reading from or writing to a removable optical disk (not shown) such as a CD ROM or other optical media. Hard disk drive 256, magnetic disk drive 258, and optical disk drive 262 may be connected to bus 248 by a Small Computer System Interface (SCSI) 266 or some other appropriate interface. The drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for system 242. Although exemplary system 242 described herein may employ a hard disk, a removable magnetic disk and a removable optical disk, it should be appreciated by those skilled in the art that other types of machine-readable media which can store data that is accessible by a processing system, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in an exemplary operating environment.
A number of program modules may be stored on the hard disk (not shown), magnetic disk (not shown), optical disk, ROM 250, RAM 252, or other media. The program modules may include an operating system 270, one or more application programs 272 (such as a database system), cache/other modules 274, and program data 276 (such as a database). A user may enter commands and information into system 242 through input devices such as, for example, a keyboard (not shown) and a pointing device (not shown). These and other in-put devices may be connected to processing unit 244 through an interface 282 that may be coupled to bus 248. A monitor 284 or other type of display device may be connected to bus 248 via an interface, such as, for example, a video adapter 286.
System 242 may implement a server, such as, for example, second processing device 106, or a client, such as third processing device 108. Second processing device 106 and third processing device 108 may operate in a networked environment using logical connections to one or more remote processing devices, such as a remote processing device 288. Remote processing device 288 may be a server processing device or a client processing device and may typically include many or all of the elements described above relative to system 242. The logical connections depicted in
When used in a LAN networking environment, system 242 may be connected to the local network through a network interface or adapter 294. When used in a WAN networking environment, system 542 may include a modem 296 or other means for establishing communications over wide area network 292, such as the Internet. Modem 296, which may be internal or external, may be connected to bus 248 via a serial port interface 268. In a networked environment, program modules depicted relative to system 242, or portions thereof, may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
When system 242 is used to implement first processing device 104 as a stand alone processing device, system 242 may not include networking hardware and/or software. For example, system 242 may not include network interface 294 and may not interface to modem 296.
One or more processing units 244 of system 242 may be programmed by instructions stored at different times in various computer-readable storage media. Programs and operating systems may be distributed, for example, on floppy disks, CD-ROMs, or via a network, such as network 102. The programs or operating systems may be installed or loaded into a secondary memory of a processing system. At execution, they are loaded at least partially into the computer's primary memory. Aspects of embodiments of the invention, described herein, include these and other various types of machine-readable storage media.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks, although it is recognized that such programs and components may reside at various times in different storage components of the processing system, and may be executed by the data processor(s) of the processing system.
Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more processing devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
The following illustrates two exemplary schemas that may be used in embodiments. The exemplary schemas each illustrate an exemplary layout for a number of tables of a database, such as, for example, a relational database. The schemas may include definitions for a number of tables, including tables for defining objects, object types, properties of object types, properties of objects, object relations and relation types.
ObjectTypes 302 may be a table that defines types of objects that may be included in the database system. ObjectTypes 302 may include ObjectTypeCode, Name, ParentObjectTypeCode and one or more attributes. ObjectTypeCode may be a primary key used to uniquely identify an entry in table ObjectTypes 302. Name may be a name of an object type. ParentObjectTypeCode may be a foreign key to ObjectTypeCode, which may indicate an ObjectTypeCode for an object type that may be a parent to the current object type in a hierarchical structure or relationship. A foreign key is a key that may be used to point to and access an entry in a table that is uniquely identified by the foreign key and uses the foreign key as a primary key. Attributes may be one or more fields that may store additional information about the object type. The additional information may be defined in a markup language, such as, for example, eXtensible Markup Language (XML).
Table ObjectTypeProperties 304 may be a table that defines properties of an object type. Table ObjectTypeProperties 304 may include ObjectTypeCode, PropertyCode, PropertyTypeCode, Name and one or more attributes. ObjectTypeCode may be a foreign key to ObjectTypeCode in table ObjectTypes 302. Thus, ObjectTypeCode of ObjectTypeProperties 304 may be used to point to and access a particular entry of table ObjectTypes 302. PropertyCode may be a value that may be combined with ObjectTypeCode to form a composite key that may be used as a primary key to uniquely identify an entry in ObjectTypeProperties 304. PropertyTypeCode may specify a property data type, such as for example, a name field, an address field, or user interface data types, such as, for example, textbox, richtextbox, choice, dropdownlist, etc. Name may be a name of a property. Attributes may be one or more fields that may store additional information about the property. The additional information may be defined in a markup language, such as, for example, eXtensible Markup Language (XML).
Table Objects 306 may be a table that defines instances of objects. Table Objects 306 may include ObjectID, Name and ObjectTypeCode. ObjectID may be a unique value and may be a primary key to uniquely identify an instance of an object. Name may be a name of an instance of an object. ObjectTypeCode may be a foreign key that may be used to point to and access an unique entry in table ObjectTypes 302.
Table ObjectProperties 308 may be a table that defines properties of instances of objects. Table ObjectProperties 308 may include ObjectTypeCode, PropertyCode, ObjectID and a value, which may be the value of the particular property. ObjectTypeCode and Propertycode may be combined to form a composite key, which may be used to point to and access an entry in table ObjectTypeProperties 304 that may be uniquely identified by the composite key. ObjectID may be a foreign key that may be used to point to and access an entry in Table Objects 306 that may be uniquely identified by ObjectID.
Table ObjectRelations 310 may be a table that defines relation types between two objects. Table ObjectRelations 310 may include ObjectID, RelatedObjectID, RelationTypeCode and one or more attributes. ObjectID may be a foreign key that may be used to point to and access a unique entry in Table Objects 306. RelatedObjectID may be a foreign key to point to and access another unique entry in Table Objects 306, which may correspond to a second object of a relation defined by the entry of table ObjectRelations 310. RelationTypeCode may define a type of relation between two objects and may be a foreign key that may be used to point to and access a unique entry in table RelationTypes 312. Attributes may be one or more fields that may store additional information about a relation, such as, for example, a strength of a relation or other information. The additional information may be defined in a markup language, such as, for example, extensible Markup Language (XML).
Table RelationTypes 312 may be a table that defines relations between two objects. Table RelationTypes 312 may include RelationTypeCode, Name, Direction, ReverseRelationTypeCode and one or more attributes. RelationTypeCode may be a primary key used to uniquely identify an entry in table RelationTypes 312. Name may be a name of a relation. Direction may be a value that indicates a hierarchical direction of a relation type. In one implementation, integer values may be used, although other values may be used in other implementations. In one implementation that uses integer values, a 0 value may indicate a relation that is equally bi-directional between two objects, a I value may indicate that an object indicated by ObjectID is at a higher level than an object indicated by RelatedObjectID and a 2 value may indicate that the object indicated by ObjectID is at a lower level that the object indicated by RelatedObjectID. Other values may be used in other implementations consistent with the principles of the invention. ReverseRelationTypeCode may be a foreign key that may be used to point to and access a unique entry of table RelationTypes 312 that may define an opposite or reverse relation between the two objects. Attributes may be one or more fields that may store additional information about a relation, such as, for example, “is part of”, “works for”, “is a member of” or other information. The additional information may be defined in a markup language, such as, for example, extensible Markup Language (XML).
Table ObjectTypes 402 may be a table that defines types of objects that may be included in the database system. Table ObjectTypes 402 may include ObjectTypeCode, Name, ParentObjectTypeCode and one or more attributes. ObjectTypeCode may be a primary key used to uniquely identify an entry in table ObjectTypes 402. Name may be a name of an object type. ParentObjectTypeCode may be a foreign key that may be used to point to and access a unique entry of table ObjectTypes 402 that may be a parent to the current object type in a hierarchical structure. Attributes may be one or more fields that may store additional information about the object type. The additional information may be defined in a markup language, such as, for example, extensible Markup Language (XML).
Table ObjectTypeProperties 404 may be a table that defines default properties of an object type. ObjectTypeProperties 404 may include ObjectTypeCode and PropertyCode. ObjectTypeCode may be a foreign key to point to and access a unique entry in table ObjectTypes 402. PropertyCode may be a foreign key to point to and access a unique entry in table Properties 405.
Table Properties 405 may be a table that defines properties of objects. Table Properties 405 may include PropertyCode, Name, PropertyTypeCode and one or more attributes. PropertyCode may be a primary key used to uniquely identify an entry of table Properties 405. Name may be a name of a property. PropertyTypeCode may specify a property data type, such as for example, a name field, an address field, or user interface data types, such as, for example, textbox, richtextbox, choice, dropdownlist, etc. Attributes may be one or more fields that may store additional information about the property. The additional information may be defined in a markup language, such as, for example, eXtensible Markup Language (XML).
Table Objects 406 may be a table that defines instances of objects. Table Objects 406 may include ObjectID, Name and ObjectTypeCode. ObjectID may be a unique value and may be a primary key that uniquely identifies an instance of an object. Name may be a name of an instance of an object. ObjectTypeCode may be a foreign key that may be used to point to and access a unique entry in table ObjectTypes 402.
Table ObjectProperties 408 may be a table that defines properties of instances of objects. Table ObjectProperties 308 may include, ObjectID, PropertyCode and a value. Object-ID may be a foreign key that may be used to point to and access a unique entry in table Objects 406. PropertyCode may be a foreign key that may be used to point to and access a unique entry of table Properties 405. Value may indicate the value of the particular property for an instance of an object.
Table ObjectRelations 410 may be a table that defines relation types between two objects. Table ObjectRelations 310 may include ObjectID, RelatedObjectID, RelationTypeCode and one or more attributes. Object]D may be a foreign key that may be used to point to and access a unique entry in table Objects 406. RelatedObjectID may be a foreign key to point to and access another unique entry in table Objects 406, which may correspond to a second object of a relation. RelationTypeCode may define a type of relation between two objects and may be a foreign key that may be used to point to and access a unique entry in table RelationTypes 412. Attributes may be one or more fields that may store additional information about a relation, such as, for example, a strength of a relation or other information. The additional information may be defined in a markup language, such as, for example, eXtensible Markup Language (XML).
Table RelationTypes 412 may be a table that defines relations between two objects. RelationTypes 412 may include RelationTypeCode, Name, Direction, ReverseRelationTypeCode and one or more attributes. RelationTypeCode may be a primary code used to uniquely identify an entry in Table RelationTypes 412. Name may be a name of a relation. Direction may be a value that indicates a hierarchical direction of a relation type. In one implementation, integer values may be used, although other values may be used in other implementations. In one implementation that uses integer values, a 0 value may indicate a relation that is equally bi-directional between two objects, a 1 value may indicate that an object indicated by ObjectID is at a higher level than an object indicated by RelatedObjectID and a 2 value may indicate that the object indicated by ObjectID is at a lower level that the object indicated by RelatedObjectID. Other values may be used in other implementations consistent with the principles of the invention. ReverseRelationTypeCode may be a foreign key that may be used to point to and access a unique entry of table RelationTypes 412 that may define an opposite or reverse relation between the two objects. Attributes may be one or more fields that may store additional information about a relation, such as, for example, “is part of”, “works for”, “is a member of” or other information. The additional information may be defined in a markup language, such as, for example, eXtensible Markup Language (XML).
The schemas illustrated in
Table ObjectTypes 302 may define a corresponding object type for each object instance. Some object instances may have the same object type. In the example of
Table ObjectTypeProperties 304 may have an entry associated with the above two object types to define properties associated with each of the object types. For example, an entry of table ObjectTypeProperties 304 associated with DeptObject 702 may have a value of ObjectTypeCode of“Dept905”, which may be a foreign key for accessing an associated entry of ObjectTypes 302, a value of PropertyCode of, for example, “D8765”, a value of PropertyTypeCode of, for example, “DType666”, a value of Name of “Department Name”, and a value of one or more attributes that may further describe the property. Similarly, an entry of table ObjectTypeProperties 304 associated with EmployeeObject 704 may have a value of ObjectTypeCode of “Empl167”, which may be a foreign key for accessing an associated entry of table ObjectTypes 302, a value of PropertyCode of, for example, “E8744”, a value of PropertyTypeCode of, for example, “Etype744”, a value of Name of, for example, “EmployeeIDNum”, and a value of one or more attributes that may further describe the property.
Table ObjectProperties 308 may have an entry associated with each of the above two objects. An entry of table ObjectProperties 304 associated with DeptObject 702 may have a value for ObjectTypeCode of “Dept905” and a value for PropertyCode of “D8765”, which may be used as a composite foreign key for accessing an associated entry of table ObjectTypeProperties 304, a value for ObjectID of “OBJ123”, which may be a foreign key to an associated entry of table Objects 306, and a value of the property corresponding to an instance of DeptObject 702, such as, for example, “Advanced Projects”. Similarly, an entry of table ObjectProperties 308 associated with EmployeeObject 704 may have a value for ObjectTypeCode of “Empl167” and a value for PropertyCode of “Etype744”, which may be used as a composite foreign key for accessing an associated entry of table ObjectTypeProperties 304, a value for ObjectID of “OBJ124”, which may be a foreign key to an associated entry of table Objects 306, and a value of the property corresponding to an instance of EmployeeObject 704, such as, for example, “00198”.
Table ObjectRelations 310 may have an entry associated each of the above two objects. An entry of ObjectRelations 310 associated with DeptObject 702 may have a value for ObjectID of “OBJ123”, which may be a foreign key to an associated entry of table Objects 306. RelatedObjectID may have a value of “OBJ124”, which may indicate a relationship with EmployeeObject 704, which may be a foreign key to the entry of table Objects 306 corresponding to an instance of EmployeeObject 704. RelationTypeCode may be a foreign key to access an associated entry of table RelationTypes 312, which may include information that further describes the relationship. Similarly, an entry of table ObjectRelations 310 associated with EmployeeObject 704 may have a value for ObjectID of“OBJ124”, which may be a foreign key to an associated entry of table Objects 306. RelatedObjectID may have a value of“OBJ123”, which indicates a relationship with DeptObject 702, which may be a foreign key to the entry of table Objects 306 corresponding to an instance of DeptObject 702. RelationTypeCode may be a foreign key to an associated entry of table RelationTypes 312, which may include information that further describes the relationship.
Table RelationTypes 312 may have entries associated with a relationship between the above-mentioned two objects. An entry of RelationTypes 312 that describes a relation between DeptObject 702 and EmployeeObject 704 may have a unique value for RelationTypeCode, for example, “DM993” which may be a primary key for the entry of RelationTypes 312. Name may have a value of, for example, “DepartmentMembers” as a name of the relationship. Direction may have a value of, for example, 1, indicating that DeptObject 702 is of a higher level than EmployeeObject 704. ReverseRelationTypeCode may be a foreign key to access a unique entry of table RelationTypes 312 associated with a reverse relationship and may have a value such as, for example, “WO8765”. Attributes may include other information about the relationship. Similarly, an entry of table RelationTypes 312 that describes a relation between EmployeeObject 704 and DeptObject 702 may have a unique value for RelationTypeCode, for example, “WO8765” which may be a primary key for the entry of table RelationTypes 312. Name may have a value of, for example, “EmployeesInDept” as a name of the relationship. Direction may have a value of, for example, 2, indicating that EmployeeObject 704 is of a lower level than DeptObject 702. ReverseRelationTypeCode may be a foreign key to an entry of table RelationTypes 312 associated with a reverse relationship and may have a value such as, for example, “DM993”. Attributes may include other information about the relationship.
Table ObjectTypeProperties 304 may have an entry corresponding to the new object type, if SectionObject 703 is a new type of object. Otherwise, an existing entry of table ObjectTypeProperties 304 may be associated with SectionObject 703.
Table ObjectProperties 308 may have an entry associated with SectionObject 703. The entry of table ObjectProperties 308 may have an ObjectTypeCode and a PropertyCode that may be a composite foreign key to an associated entry of table ObjectTypeProperties 304. ObjectID may be a foreign key to an entry of table Objects 306 corresponding to the instance of SectionObject 703. Value may be a value of the property corresponding to the instance of SectionObject 703.
Object Relations 310 and RelationTypes 312 may have entries corresponding to a relation between instances of objects DeptObject 702 and SectionObject 703, SectionObject 703 and DeptObject 702, SectionObject 703 and EmployeeObject 704, and EmployeeObject 704 and SectionObject 703.
Thus, the above exemplary database change illustrates that such a change may be made without any changes to the schema.
The schema of
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms for implementing the claims.
Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.
Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Those of skill in the art will appreciate that other embodiments of the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. For example, hardwired logic may be used in implementations instead of processors, or one or more application specific integrated circuits (ASICs) may be used in implementations consistent with the principles of the invention. Further, implementations consistent with the principles of the invention may have more or fewer acts than as described, or may implement acts in a different order than as shown. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.