Semantic object modeling system for creating relational database schemas5809297Abstract A computer-based system for allowing a user to create a relational database schema. The system allows a user to create a semantic object data model of the database schema. The semantic object data model is defined by one or more semantic objects, each of which includes one or more attributes that describe a characteristic of the semantic objects. The attributes are defined as being either simple value attributes that describe a single characteristic of the semantic object; group attributes that include one or more member attributes that collectively describe a characteristic of the semantic object; formula attributes that set forth a computation that describes a characteristic of a semantic object; or object link attributes that define a relationship between two or more semantic objects. Once the semantic object data model is created, the system validates the semantic objects to ensure no modeling errors have been made and transforms the semantic objects and their included attributes into a plurality of relational database tables that will store data as defined by the semantic object data model. Claims The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows: Description FIELD OF THE INVENTION
______________________________________
Class Album
Data Member Data Type
______________________________________
Name Text
Creation date Date
Created by Text
Contents Unordered list of pointers
______________________________________
Creating the Semantic Object Data Model The above-referenced tables describe the C++ classes that are used to create the building blocks for the semantic object data model. FIGS. 4-15 describe the operations that must be completed when a user creates an instance of each of the various building blocks as the user defines the semantic object data model described above. The user accomplishes this task by interacting with the user interface on display screens such as those shown in FIGS. 1, 2, and 3. FIG. 4 shows the steps implemented in the present invention when a user creates a new semantic object. First, the computer allocates memory for a new semantic object block at step 100. Next the computer assigns the semantic object a unique identifier at step 102. In the present preferred embodiment, a counter is incremented each time a semantic object, profile or attribute is created in the semantic object data model. The value of the counter is assigned to each object, attribute or profile in order to uniquely identify the semantic object, profile, or attribute in the semantic object data model with a numeric value. At step 104, the user is prompted for a name of the semantic object created. The name is tested to determine whether it is unique among all the semantic objects created in the semantic object data model, at a step 106. If the name is not unique, a numeric suffix is added to differentiate the name of the semantic object at a step 108. For example, if two semantic objects are created with the name "person," the second one would be given a name "Persona.sub.-- 1" to differentiate it from the former. Once the name of the semantic object is determined to be unique or differentiated, the caption is initialized to be an empty string at a step 110. The description is then initialized to be an empty string at a step 112 and, finally, the contents data member of the semantic object is initialized as an empty, ordered collection of pointers to attributes that are contained within the semantic object at a step 114. As indicated, all semantic objects within a particular semantic object data model are stored in an album. The album is simply a list of pointers to each semantic object. Each time a new semantic object is created, a corresponding pointer to the new semantic object must be added to the contents list of the album. Once the semantic object has been created, the system automatically creates a corresponding object link profile according to the steps set forth in FIG. 11. Object link profiles are used to relate one semantic object to another within the semantic object data model. For example, as soon as the user creates the student semantic object 20, shown in FIG. 1, the system creates a corresponding object link profile based upon the student semantic object profile. The object link profile is used by the system to create corresponding object link attributes that related the student semantic object to other semantic objects. To create the object link profile, the system first provides a pointer to the semantic object that causes the corresponding object link profile to be created at step 400. Memory for the new object link profile is then created at a step 402, and the profile is assigned a unique identifier at a step 404. The name of the base semantic object determined through the pointer received from a step 400, is copied to the name property of the object link profile at a step 406. At a step 408, the system determines whether the name is unique among all profiles in the semantic object data model. If the name is not unique, a numeric suffix is added to differentiate the newly created profile from the remaining profiles, at a step 410. Once the name of the object link profile has been differentiated, the caption is initialized to an empty string at a step 412. Next, the description is initialized to an empty string at a step 414. At a step 416, the ID status is initialized to "none." As described above, the ID status of a semantic object or an attribute indicates whether or not the attribute is used to uniquely identify an instance of the semantic object. After initializing the ID status, the minimum cardinality for the object link profile is initialized to zero at a step 418. Again, the minimum cardinality refers to the minimum number of object instances an object link attribute derived from this profile must connect to in order for the data to be valid. The maximum cardinality for the object link profile is set to one at a step 420. At a step 422, the base semantic object pointer is set to the address of the semantic object that caused the object link profile to be created. Finally, in a step 424, the derived attribute list is initialized as an empty, unordered collection of pointers to object link attributes that are derived from the object link profile. As indicated above, semantic objects are defined by the attributes they contain. An attribute defines the characteristics of the semantic object as well as relationships between semantic objects. The most common type of attribute is the simple value attribute that holds a single value in the database. All simple value attributes are based upon some corresponding simple value profile. The logic system of the present invention provides the user with a predefined list of typical simple value profiles that can be used to describe an object. Such simple value profiles include: area code, city, currency amount, description, event date, event time, identifier-numeric, identifier-text, local number, percent, person name, quantity, state, street, and ZIP code. However, if the user desires, he/she can create a simple value profile and use it in any number of semantic objects in the semantic object data model. For example, a user may wish to define a simple value "salary" to describe how much money a person in the database makes per year. While a user could utilize the identifier-numeric profile for this, a customized profile may better suit the user's needs, because it is more easily recognizable. Additionally, by having a specifically created attribute profile, a user can easily change the properties of any attribute created from the profile by simply changing the profile properties. Because each profile maintains a list of derived attributes, it is a simple matter to update any property of all attributes based upon the profile. FIG. 5 shows the steps taken by the present invention to create a simple value profile. First, sufficient memory is allocated for the new simple value profile at a step 160. Then, the new profile is assigned a unique integer identifier at a step 162. The user is then prompted for a name for the profile at a step 164. If no name is provided, the system gives the new profile a default name of "value." At a step 166, it is determined whether the name of the profile is unique among all profiles within the semantic object data model. If not, a numeric suffix is added to differentiate the name of the new profile at a step 168. Once the name of the profile is different from all other profiles in the semantic object data model, the caption property of the simple value profile is initialized as an empty string at a step 170. The caption property provides an alternative field title to be used on a form or report produced by an application program accessing the database whose schema is defined by the semantic object data model. The description property of the simple value profile is initialized as an empty string at a step 172. The ID status property is then initialized to "none" at a step 174. At a step 176, the value type is initialized to "text" at a step 176. By changing the value type of the profile, the user can select the type of data that the simple value profile represents. The user can select any of a predefined set of common DBMS data types, including text, currency, date, time, memo, tiny integer, short integer, long integer, true/false, counter, floating point, double floating point, OLE object, and binary. Once the value type has been value profile is initialized toy of the simple value profile is initialized to ten at a step 178. As will be appreciated, the length property is only useful with variable length value types. The format property is initialized as an empty string in a step 182. The format property defines a field that holds data to be used by a database application program in order to determine how the data is to be displayed. The initial value property for the simple value profile is initially defined as an empty string at a step 184, and the minimum cardinality for the profile is set to zero at a step 188, while the maximum cardinality is set to one at a step 190. Finally, the derived attributes property list for the simple value profile is initialized as an empty, unordered collection of pointers to attributes that are derived from the newly created simple value profile at a step 192. While modeling the data to be stored on the database, the user creates semantic objects and places attributes within the semantic objects. The user can add a simple value attribute to the semantic object by selecting, dragging, and dropping a simple value profile from the profile manager 50, shown in FIG. 1, into the semantic object. Once a simple value profile is dropped into a semantic object, the system creates a corresponding simple value attribute. These steps are set forth in FIG. 6. After the simple value attribute is created, the system immediately inserts it into the semantic using the steps shown in FIGS. 16 and 17 as described below. Referring to FIG. 6, the system first gets a pointer to the corresponding simple value profile at a step 210. Next, sufficient memory is allocated for the new simple value attribute object at a step 212. The new simple value object is then given a unique integer identifier at a step 214. In a step 216, the name, caption, description, ID status, value type, length, format, minimum cardinality, and maximum cardinality properties are initialized from the corresponding property in the simple value profile used to create the simple value attribute. If at any time the user desires to change any one of the properties of the simple value attribute as they apply only to the semantic object in which the attribute is placed, the user may do so using the property sheet 60 shown in FIG. 3 and described above. The container property is set equal to null at a step 217. When the simple value attribute is inserted into a semantic object, the contained pointer will be set equal to the address of the containing semantic object. If the simple value attribute is placed in a nested group, the container property will be set to point to the innermost group that contains the attribute during the routine that inserts the attribute. At a step 218, the base profile pointer is set equal to the address of the simple value profile from which the attribute was created. Finally, at a step 220, a pointer to the newly created simple value attribute is added to the list of the derived attributes maintained by the corresponding simple value profile. The derived attribute list maintained by a simple value profile is used by the system to effect changes to a property of all attributes based upon a profile if a user changes the property in the corresponding profile. Some attributes used to describe a semantic object are normally thought of as groups. For example, the address attribute shown in FIGS. 1 and 2 is used to define where a person lives. Included in the address group are street, city, state, and ZIP code simple value attributes. A phone group attribute includes area code and local number simple value attributes. In addition to the predefined group attributes for address and phone provided by the system, a user may define their own group by first creating a group profile. The profile can then be used to generate corresponding group attributes in one or more semantic objects. FIG. 7 shows the steps performed by the system to create a group profile. First, sufficient memory is allocated for the new group profile at a step 240. The group profile is then assigned a unique identifier at step 242. At a step 244, the user is prompted for a name for the group profile. If no name is provided, the system will use the default name "group." At a step 246, the system determines whether the group name is unique among all groups in the semantic object data model. If not, a numeric suffix is added to differentiate the group name from related names at a step 248. Next, the caption and description properties of the group profile are initialized to empty strings at steps 250 and 252. The ID status is then initialized to "none" at a step 254. The minimum cardinality is initialized to zero at a step 256 while the maximum cardinality is initialized to one at a step 258. At a step 260 the minimum group count is initialized to zero and the maximum group count is initialized to "N" at a step 262. The minimum group count property defines the number of attributes within the group that must be present in order for the group to be valid. Similarly, the maximum group count property defines the maximum number of attributes that can be present in order for the group to be valid. For example, suppose a group profile is created called "Lunch Special." The group contains 10 simple value attributes each describing a particular side dish. A customer must select two items but can select no more than three items. Therefore the group has a minimum count of 2 and a maximum count of 3. An additional use for the minimum and maximum counts is to specify exclusivity, which is particularly useful in subtype groups described below. For example, the Persontype subtype group shown in FIGS. 1 and 2 contains two subtype attributes. By specifying the minimum count of the Persontype group to be 1 and the maximum count to be 1, the user indicates that a person must be either a professor or a student, but not both. If the subtype group is required, then some choice must be made (i.e., a person must be either a student or a professor), but if the group is not required, then a person might be neither a student nor a professor. The format property for the group is initialized to an empty string in a step 264. At a step 266, the contents property of the group is initialized as an empty, ordered collection of pointers to the profiles that are contained within the group profile. Finally, at a step 268, the derived attributes list is initialized as an empty, unordered collection of pointers to group attributes that are derived from the newly created group profile. Group profiles will usually have other profiles added to their contents list before being used in the semantic object data model. These additions are performed using the mechanisms defined in FIG. 18. Once a new group profile has been created, the user can create a corresponding group attribute in one or more semantic objects by selecting the group profile, dragging, and dropping it into the boundaries of a semantic object. Once a group profile is dropped within a semantic object, the system creates a corresponding group attribute according to the steps shown in FIG. 8. In order to create a group attribute, it is first necessary to get a pointer to the corresponding group profile, as shown at a step 280 in FIG. 8. Next, sufficient memory is allocated for the new group attribute at a step 282. The group attribute is assigned a unique identifier at a step 284. At a step 286, the group's name, caption description, ID status, minimum cardinality, maximum cardinality, minimum group count, maximum group count, and format are initialized from the properties of the corresponding group profile. At a step 288, the container pointer is set equal to null. When the group attribute is inserted into a semantic object the container pointer is set equal to the address of the semantic object or the group attribute in which the new group attribute is logically included using the methods of FIGS. 16 and 17. If the group attribute is nested in another group attribute, the container pointer will be set to point to the innermost group. Next, the attributes that are defined by the contents list of the group profile are created. For each profile in the contents list, the system creates a new attribute and places a pointer to the new attribute in the contents list for the new group attribute using the methods of FIG. 17. Finally, at a step 292, a pointer to the new group attribute is placed in the corresponding group profile's list of derived attributes. Another type of attribute used to model the data in the semantic object data model is the formula attribute. As will be appreciated, formulas calculate values or manipulate data types according to a predefined set of common arithmetic operators. The type of operation performed depends upon the types of the operands and expression of the formula. For example, the addition of two values of integer types produces a third value of integer type, while the addition of two expressions of string type produces a concatenated string-type expression. FIG. 9 shows the steps taken by the present invention to create a new formula profile. First, a new block of memory is allocated for the new profile at a step 320. Next, the profile is assigned a unique integer identifier at a step 322. At a step 324, the user is prompted for a name for the formula. If no name is given, the system provides the default name "formula." At a step 326, the system determines whether the name is unique among all the profiles within the semantic object data model. If the name is not unique, a numeric suffix is added to the name to differentiate it from similar names. At a step 330, the caption of the formula is initialized to an empty string. At a step 334, the expression of the formula is initialized to an empty string. The expression is a string that is used to define the formula being calculated. At a step 346, the formula property is initialized to "not stored." The formula-type property indicates to the system whether a value for the formula is to be stored in the relational database or is computed each time the database program is run. The value-type property of the formula is always initialized to type "text" at a step 348, while the initial length is initialized to ten at a step 350. The required flag is initialized to "no" at a step 352 and the format property that defines the way in which the output of the formula is displayed is set as an empty string at a step 354. Finally, the derived attributes property of the formula profile is initialized as an empty, unordered collection of pointers to formula attributes that are derived from the new formula profile at a step 356. Once a user has created a formula profile, the profile can be inserted into one or more semantic objects to create a corresponding formula attribute. FIG. 10 defines the steps required to create a formula attribute. First, the system gets a pointer to the corresponding formula profile in a step 380. A new block of memory is allocated for the formula attribute at a step 382. The new formula attribute is assigned a unique integer identifier in a step 384. In a step 386, the name, caption, description, expression, formula type, value type, length, required flag, and format properties are initialized from the corresponding formula profile properties. The container pointer for the formula attribute is set equal to null. When the formula attribute is inserted into a semantic object, the container pointer will be set equal to the address of the semantic object or group attribute in which the formula attribute is logically included in a step 388 using the methods shown in FIGS. 16 and 17. Next, the base profile pointer is set equal to the address of the corresponding formula profile in a step 390. Finally, a pointer to the new formula attribute is added to the corresponding formula profile's list of derived attributes at a step 392. As described above, once a user creates a semantic object, the present invention automatically creates a corresponding object link profile. The object link profile is used to create object link attributes in the semantic objects that specify relations between the various semantic objects. For example, in FIG. 1, a pair of object link attributes connect the professor semantic object and the student semantic object. The name of the object link from the professor to the student is "advisee" and its cardinality is 0.N, indicating that a professor may have zero advisees or may have more than one. Similarly, the student semantic object has an object link attribute called "advisor" that links the student semantic object to a professor semantic object. The advisor object link has a cardinality of 0.1, indicating that a student might have no advisors, but has at most one advisor. The present invention creates an object link attribute when a user selects an object link profile and drops it into a semantic object or selects the entire semantic object by clicking the mouse pointer in the box in the upper right hand side of the semantic object and drops an icon produced by the system into another semantic object. FIG. 12 shows the steps taken by the present invention to create an object link attribute. First, the system gets a pointer to the corresponding object link profile upon which the new attribute is based at a step 440. At a step 442, a new block of memory is allocated for the object link attribute. The new attribute is assigned a new unique integer identifier at a step 444. The name, caption, description, ID status, and minimum and maximum cardinality properties are initialized from the corresponding object link profile properties in a step 446. Next, the container pointer is set equal to null at a step 448. The container pointer will be updated to reflect the address of the semantic object or group in which the object link attribute is logically included using the methods shown in FIG. 16 and FIG. 17. Initially, the pair pointer that points to a corresponding object link attribute disposed within the referenced semantic object indicated by the object link attribute is initialized to null at a step 450. The base profile pointer is set to the address of the object link profile on which the object link attribute is based at a step 452. Finally, a pointer to the new object link attribute is added to the base profile's list of derived attributes at a step 454. Another attribute similar to an object link attribute is the parent attribute. The parent attribute allows a user to specify that a semantic object is a subtype of another semantic object. For example, as shown in FIG. 1, the student and professor semantic objects both contain parent-type attributes called "person." The person attribute indicates that both the professor and the student semantic objects are persons (i.e., are subtypes of the person semantic object) in the data model. Because a parent-type attribute is so similar to the object link type attributes, no corresponding parent-type profiles are separately created. Instead, the object link profile is used. As shown in FIG. 13, to create a parent attribute, the system first gets a pointer to the corresponding object link profile that is associated with the parent-type semantic object at a step 480. A new memory block is allocated for the new parent-type attribute at a step 482, and the attribute is assigned a unique integer identifier at a step 484. At a step 486, the new parent-type attribute's name, caption, and description are initialized from the corresponding object link profile properties. The container pointer is set equal to null at a step 488. The pair pointer that points to the corresponding subtype attribute is initialized to null in a step 490. At a step 492, the base profile pointer is set equal to the address of the object link profile used to create the parent attribute. Finally, a pointer to the new parent attribute is added to the base profile's list of derived attributes in a step 494. The properties of the parent-type attribute will be updated when the attribute is placed in the subtype semantic object. Once a parent-type attribute has been placed in a semantic object, a corresponding subtype attribute is automatically created by the system and placed in the corresponding parent semantic object. FIG. 14 shows the steps taken by the present invention to create such a corresponding subtype attribute. First, the system gets a pointer to the object link profile that is associated with the subtype semantic object at a step 520. A block of memory is allocated for a new subtype attribute at a step 522, and the new subtype attribute is given a unique integer identifier at a step 524. At a step 526, the name, caption, description, and required flag are initialized from the corresponding object link profile associated with the subtype semantic object. The container pointer is set equal to null at step 528 and will be updated to reflect the address of the semantic object or subtype group in which the new subtype attribute is logically contained when the subtype attribute is inserted into a semantic object. The pair pointer is initialized to null at a step 530, and the base profile pointer is set equal to the address of the corresponding object link profile from which the subtype attribute was created at a step 532. Finally, a pointer is added to the new subtype attribute in the corresponding object link profile's list of derived attributes at a step 534. It is possible to include subtype attributes within a group in the semantic object data model. An example of a subtype group, shown in FIG. 2, is the Persontype group contained within the Person semantic object. This group indicates that a person must be either a professor or a student. Subtype groups are indicated with the subscript "ST" next to the brackets that identify the members of the group. FIG. 15 shows the steps taken by the present invention to create a subtype group. First, sufficient memory is allocated for the new subtype group attribute at a step 550. A unique identifier is assigned at a step 552, and the user is prompted for the name of the subtype group at a step 554. If no name is provided, the system uses the default name "subtype group." In the preferred form of the present invention, there are three name spaces within a single semantic object. The first name space holds the names of subtypes and subtype groups. No subtype or subtype group can have the same name within a single semantic object. Similarly the second name space holds the names of all parent attributes in a single semantic object. No two parent attributes can have the same name within a semantic object. The third name space holds the names of all other attributes immediately within the semantic object. The three different name spaces allow a user to easily model the situation whereby a semantic object has an object link attribute and a parent or subtype attribute with the same name. Suppose, for example, a user creates a semantic object called "Employee". The semantic object has an object link attribute called "Manager" as well as a subtype attribute called "Manager". This is because an employee may have a manager, and a manager is an employee. Without allowing the user to have object link attributes with the same name as a subtype or parent, it would be cumbersome for the user to model examples like the one presented above. The caption and description for the subtype group attribute are initialized to empty strings at steps 560 and 562. The required flag is initialized to "false" at a step 564. The minimum group count is initialized to zero at a step 566, while the maximum group count is initialized to "N" at a step 568. The container pointer is initialized to null at step 570. Once the subtype group is inserted into a semantic object, the container pointer is set equal to the address of the semantic object or subtype group attribute, which logically contains the new subtype group object using the method shown in FIG. 16 or FIG. 19. Finally, the contents list of the subtype group attribute is initialized as an empty, ordered list of pointers to subtype attributes and other subtype group attributes that are contained within the newly created subtype group attribute at a step 572. FIGS. 4-15 describe the steps implemented by the present invention when a user creates semantic objects, profiles, or attributes in the course of developing a semantic object data model. However, it is also possible to manipulate objects within the graphical user interface to further refine the data model. As described above, one of the ways of manipulating the model is by selecting a profile, dragging, and dropping the profile into a semantic object to create a corresponding attribute. FIGS. 16A-16C describe the steps taken by the present invention to update the semantic object data model when a user has inserted a new attribute into a semantic object (i.e., the current semantic object). Referring again to FIG. 2, assuming the user is trying to create the attribute labeled "Social.sub.-- Sec.sub.-- No" in the person attribute 40. The user does this by selecting the "IdentifierNumeric" profile from the profile manager 50 and dropping the selected profile into the physical boundaries of the person semantic object. The user then changes the name of the newly created attribute to "Social.sub.-- Sec.sub.-- No" using the property sheet 60 shown in FIG. 3. The user can then change the ID status, minimum and maximum cardinalities to reflect the type of attribute, i.e., a social security number, added to the semantic object. Beginning at a step 590, the system gets a pointer to the new attribute being inserted. At a step 592, the system determines whether the user is attempting to insert a parent attribute that is derived from a profile, which is based upon a semantic object that is a subtype of the current semantic object, or is based upon the same profile as a parent attribute that the semantic object already contains. In the present example, neither professor nor student may be a parent type of person, since the parent attribute that would specify that relationship would be based on an object link profile based on the person semantic object. Similarly, neither professor nor student may have a second parent attribute based on the person semantic object, since they each already have one. Because the professors and student semantic objects are already direct subtypes of the person semantic object, another such connection is redundant. If the answer to step 592 is yes, an error message is produced as indicated in a step 594, and the user is not allowed to insert such a parent attribute into the current semantic object. At a step 596, the system determines whether the user is attempting to create a subtype attribute created from a profile that corresponds to a semantic object, which is a parent of the current semantic object, or is based upon the same profile as a subtype attribute that the current semantic object already contains. Using the model of FIGS. 1 and 2, step 596 prevents a subtype attribute based on the profile created from the person semantic object from being inserted into either the professor or student semantic objects. Similarly, no additional subtype attributes based on the profiles created from the professor or student semantic objects may be inserted into Person semantic objects. If the answer to step 596 is yes, an error indication is produced at a step 598, and the insertion is not allowed. Assuming that the user is not attempting an illegal insertion of an attribute into a semantic object, a pointer to the newly added attribute is included in the current semantic object's contents list at a step 600. Next, the container pointer of the inserted attribute is updated to point to the current semantic object at a step 602. The system then ensures that the name of the newly added attribute and all the attribute's contents, if a subtype group, is unique within the semantic object, at a step 604. If any name is not unique, a numeric suffix is added to the name to differentiate it. At a step 606, the system determines if the newly added attribute is a object link-type attribute. If yes, the system determines whether the attribute has a corresponding paired object link attribute located in another semantic object at a step 608. If such a paired attribute exists, the base profile of the paired object link attribute is changed at a step 610 to be the profile created from the current semantic object in which the link attribute has been inserted. If no corresponding paired attribute exists, the system creates a new object link attribute based upon the profile of the current semantic object at a step 612. The pair pointers of the newly created object link attribute and the inserted object link attribute are set to point to each other at a step 614. Finally, at a step 616, the newly created object link attribute is inserted into the semantic object that is listed as the base object in the profile of the inserted object link obtained at step 590. For example, if an object link attribute called student is placed in the class semantic object shown in FIG. 1, then a corresponding object link is created and placed in the semantic object listed as the base semantic object of the profile from which the student object link was created, i.e., the student semantic object. If the inserted attribute is not a object link attribute, the system determines whether the inserted attribute is a parent-type attribute at a step 618. If the inserted attribute is a parent, in a step 620, the system determines if the parent attribute has a paired subtype attribute located in another semantic object. If yes, the object link profile of the paired subtype attribute is changed to be the object link profile based on the current semantic object at a step 622. If no corresponding subtype attribute exists, a new subtype attribute is created from the object link profile, based upon the current semantic object, at a step 624. The pair pointers of the attributes are set to point to each other at a step 626. Finally, the new subtype attribute is inserted into the semantic object that is the base object of the profile from which the newly inserted parent attribute was derived at a step 628 in the same way as the insertion described with respect to step 590. If the inserted attribute was not of the parent type, a test is performed at a step 630 to determine if the newly inserted attribute is a subtype attribute. If the attribute is a subtype, a test is performed at a step 632 to determine if there exists a corresponding parent-type attribute. If the answer is yes, the profile of the paired parent attribute is changed to be the profile based upon the semantic object that is being added to at a step 634. If no corresponding parent-type attribute exists, a new parent-type attribute is created based upon the profile associated with the semantic object being added to at a step 636. The pair pointers of both attributes are then set to point to each other at a step 638, and the newly created parent attribute is inserted into the semantic object that is the base object of the profile from which the subtype attribute was derived. In the course of developing a semantic object data model, the user may wish to add an attribute to a group attribute. This change is accomplished by selecting an attribute within the semantic object data model and dropping it into the group attribute. FIGS. 17A-17B show the steps taken by the present invention to add an attribute to a group attribute. Beginning at a step 641, the system determines if the attribute being added to the group is a simple value, group, formula, or object link attribute. If the attribute is not one of these types, an error message is produced at a step 642, indicating the insertion is not allowed. Once it has been determined that the attribute can be added to the group attribute, a pointer to the new attribute is added to the group's ordered contents list at a step 643. At a step 644, the container pointer of the inserted attribute is changed to the group attribute that contains the new attribute. A decision block 645 determines if the name of the attribute is unique among attributes in the group. If not, a numeric suffix is added to differentiate the name at a step 646. The logic then determines if the group attribute into which the new attribute has been inserted is the only group that is derived from the corresponding group profile at a step 647. If so, then a pointer to the profile of the added attribute is added to the contents list of the group profile at a step 650. If more than one group has been created from the corresponding group profile, a new group profile is created at a step 648. The contents list of the new group profile is initialized to include the profiles of all the member attributes, including the new member attribute, at a step 649. At a step 651, a check is made of whether the current group is contained within another group, i.e., in a "container group." If so, in a step 652, the logic determines whether the container group is the only group derived from its corresponding profile. If yes, then the contents list of the corresponding group profile is updated to include the profile of the newly added attribute at a step 655. If the container group is not the only group created from its corresponding group profile, then a new group profile is created at a step 653. The contents list of the newly created group profile is initialized to include pointers to all the member attributes at a step 654. This process continues until all container groups have been changed, or until a container group does not create a new profile. At a step 656, the newly added attribute is checked to determine if it is of type object link. If yes, then the system determines whether the object link has a paired object link attribute at a step 657. If a paired object link exists, then the profile of the paired attribute is changed to the profile based on the semantic object that contains the group, which includes the newly added object link attribute, at a step 658. If no corresponding paired object link attribute exists, then the system creates a new object link attribute that is derived from the profile based on the semantic object, which contains the group at a step 659. At a step 661, the pair pointers of the inserted and newly created object link attributes are set to point to each other. At a step 663, the newly created object link attribute is inserted into the semantic object that is the base object of the inserted object link attribute. In some instances, a user may wish to change all groups in the semantic object data model by changing the profile of the group attributes. For example, a group attribute representing a phone number includes an area code and a phone number. However, if the user wishes to allow foreign telephone numbers, then a provision must be made for a country code attribute to be inserted into each phone number group. This modification is accomplished by adding a country code profile to the corresponding phone group profile. A country code attribute will then be automatically inserted into each attribute that was created from the corresponding phone group profile as listed in the derived attributes list. FIG. 18 describes the steps performed by the present invention when a user inserts a profile into a group profile. Beginning at a step 665, the system determines if the user is attempting to add a profile whose contents list already includes the group profile into which the new profile is being inserted. If the answer is yes, an error message is presented at a step 667, indicating that the insertion is not allowed, because it represents a recursive relationship. Assuming that the profile can be added to the group profile, a pointer to the newly added profile is appended to the contents list of the group profile at a step 669. As indicated above, each profile includes a containers list of the profiles in which it is included. At a step 671, a pointer to the group profile is added to the containers list of the newly inserted profile. Finally, the system looks at each attribute in the derived attributes list maintained by the group profile and creates a new attribute from the newly inserted attribute profile at a step 673 and inserts it into the derived attribute. Therefore, each attribute within the semantic object album is updated to reflect the profile newly added in the group profile. FIGS. 19A-19B describe the steps taken by the present invention when a subtype or subtype group attribute is inserted into another subtype group. Beginning at a step 675, a determination is made if the attribute being added is a subtype or a subtype group. If neither, the system produces an error warning at a step 677, indicating to the user that the insertion is not allowed. The present invention only allows subtype groups to include subtypes or other subtype groups as member attributes. Assuming that the attempted insertion meets these requirements, the system determines whether the attribute being added is derived from a profile of a semantic object that is a parent of the current semantic object that contains the subtype group into which the new attribute is being inserted. If the answer is yes, then an error message is produced at step 677, indicating that the insertion is not allowed, because it represents a recursive relationship. At a step 681, the system determines whether the semantic object already contains a subtype attribute, based upon the same profile from which the new subtype attribute was derived. If so, an error message is again produced at step 677, indicating that the insertion behavior is not allowed. The present invention only allows a semantic object to include one subtype attribute created from any given profile. Once it has been determined that the insertion performed by the user is allowed, a pointer to the new subtype attribute is inserted into the ordered contents list of the subtype group at a step 683. At a step 685, the container pointer of the newly inserted attribute is changed to the current subtype group attribute, and at a step 687, the system determines if the name of the inserted attribute (and the names of all member attributes if the inserted attribute is a group) are unique among all subtype and subtype groups contained within the semantic object at step 687. If a name is not unique, a numeric suffix is added to it as appropriate, at a step 689. At a step 691, the system checks whether each subtype attribute inserted has a paired parent attribute. If yes, then the profile of the paired attribute is changed to be the profile based on the current semantic object at a step 699. If the subtype attribute inserted does not have a paired parent attribute, then a new parent attribute is created from the profile based on the current semantic object at a step 693. Next, the pair pointers of the subtype and newly created parent-type attribute are set to point to each other. Finally, the newly created parent-type attribute is inserted into the semantic object that is the base object of the profile of the inserted subtype attribute at a step 697. Formula Processing The present invention allows a user to define a formula within a semantic object and to have that formula interpreted in a way that makes semantic sense to the user. This object is accomplished by enabling the user to express the formula in terms of the semantic objects or attributes contained within the semantic data model, but not necessarily with the same semantic object as the formula attribute. The system then searches the entire semantic object data model to determine the attribute that the user intends to be used in the formula. As an example of the ambiguity that can be created within a formula attribute, suppose a user has created a semantic object that represents an order form. The order form includes numerous attributes that define the line items of the order, as well as an object link attribute, to the customer who placed the order and an object link attribute to the salesman who completed the order. Assume that the semantic object order contains a formula "Tax" which is defined as the quantity of items in the order multiplied by the item price and the tax rate. However, the semantic object order may not include an attribute called "tax rate." However, the customer and salesman semantic objects both include addresses which specify the street, city, state, and zip of where the salesman and customer live. If state is defined as its own semantic object, it may further include an attribute called "tax rate." Therefore, the formula attribute within the order semantic object needs to search the entire semantic object data model for the tax rate attribute. In this example, both the customer and the salesman semantic objects would be linked to the state semantic object, thus creating an ambiguity whether the path to the tax rate was through the customer or through the salesman semantic objects. If both distances were equally far from the formula attribute, then the system would prompt the user to indicate whether the system was to use the customer's or the salesman's tax rate. Before the semantic object data model is transformed into a set of relational database tables, the present invention formula validates a formula attribute by performing an expanding ring search for the terms of the formula within the semantic object data model. If there are more than two ways to specify a term in the formula, the system applies a set of rules to ensure that the correct attribute is used. Interpretation of formula attributes is shown in FIGS. 20A-20C. To begin interpreting a formula attribute, the expression property is parsed and tokenized at a step 660, in FIG. 20A. Techniques for parsing and tokenizing string expressions are well known in the art of computer programming and therefore will not be discussed in further detail. After the expression string has been tokenized, a test is made in a step 662 to determine if the expression is grammatically correct, i.e., does it conform to predefined allowed mathematical and logical operations? In the present embodiment, provisions are made for adding, subtracting, dividing, and multiplying numbers as well as adding and subtracting dates and strings. The techniques for ensuring that a mathematical expression is grammatically correct are also well known to those of ordinary skill in the computer programming arts. In the present example shown in FIGS. 1, 2, and 3, a student semantic object has a formula attribute for grade point average, labeled GPA, which is defined as the sum of (grades)/count(grade). In order to interpret this formula correctly, the formula processor must find the term "grade" in the semantic object data model. The term "grade" in the formula can be specified by the name of the attribute itself or specified by its path name. In the present example the full path name of the grade attribute is "student.classes.grade." The terms "student" and "classes" are referred to as path references while the term "grade" is the target name for which the system searches. In order to evaluate a formula, the system begins looking at each reference in the path to the target name, i.e., in the present example "student" and "classes." At a step 664, the system determines if the formula processor is looking at the first reference in the path to the target name. If the answer is yes, the formula's container name and included attributes are added to a current ring list of objects being searched at a step 666. If the reference being searched is not the first reference in the path to the target name, then only those attributes contained by the previous reference are added to the current ring list at a step 668. Beginning at a step 670, the system begins a series of steps that analyze every attribute in the current ring list. A decision block at a step 672 determines if the name of the attribute matches the target name. If the name matches, then the name is added to a list of matches at a step 674. If the name does not match, then the formula processor gets the data type of the attribute in the current ring list. If the attribute is a subtype, then the semantic object referenced by the subtype is added to a next ring of attributes to be searched at a step 678. Subtype objects are considered by the present invention to be logically farther away than objects that are located in the same semantic object as the formula attribute that is being analyzed. On the other hand, parent objects are considered by the present invention to be at the same logical distance as the objects in the semantic object that contains the formula attribute. Therefore, if the data type is a parent object, then the referenced semantic object and its attributes are added to the current ring at a step 680. If the data type is a group object, then the formula processor proceeds to a step 682a (shown in FIG. 20B) where the list of the containers attributes is added to the current ring list. For group attributes, a decision is made at step 684 whether the system is processing the first reference in the path to the target name. If the answer is yes, then a decision is made at a step 686 whether the container of the group attribute exists in the path to the containing semantic object. If the answer is yes, a further decision is made at a step 688 to determine if the parent container's maximum count is greater than one. If the answer is yes, then a determination is made at a step 690 of whether the type of attribute being processed is of type subtype. If the answer is yes, then the container of the current container is added to the current ring list, at a step 692. If not, then the container of the current container is added to the next ring list, at a step 694. If any of the answers to the determinations in steps 684, 686, or 688 is no, then only the list of the container's attributes is added to the current ring list at a step 682a. If the type of attribute being processed is a semantic object, then the list of all the container's attributes is added to the current ring at a step 700. Finally, if the data type is an object link, then the attributes of the referenced semantic object are added to the next ring list at a step 702. Beginning at a step 709 (FIG. 20C) a determination is made if the current ring list of attributes being searched is empty. If so, the system searches the next ring list at step 670. Once an entire ring list has been searched, a check is made at a step 710 to determine if the match list is empty. If the answer is yes, then a decision is made at a step 712 whether all ring lists have been searched. If the answer is yes, an error message is shown to the user at a step 714, indicating that the target name has not been found. If not all ring lists have been searched, then the next ring list is evaluated at a step 716, in accordance with the method beginning at step 670 described above. If the matched list is not empty, a decision is made at step 718 whether there is more than one path to an attribute with the given name. If the answer is yes, then the user is asked at a step 720 to identify the attribute or path to the attribute that is intended. Assuming that the matched list contains only one attribute, a decision is made at a step 722 of whether the entire expression has been evaluated. If the answer is no, then a search begins for the next target name at a step 724. When all attribute references have been uniquely identified, their value types are examined to ensure validity in their context within the expression Album Validation As described above, before the user can transform the semantic object data model defined by the album into one or more relational tables, the album must be validated to make sure the user has not created any modeling errors. FIGS. 20D-20I describe the steps taken by the present invention to validate a semantic object data model defined in an album. As will be discussed in further detail, the present invention analyzes the album to make sure the user has not created any recursive relationships in the data model. For example, a formula attribute cannot contain an expression property which defines the formula in terms of itself. Similarly, a first semantic object cannot include an object link attribute which is used to uniquely identify the first semantic object if the object link attribute refers to a second semantic object which is uniquely determined by the first. Finally, the validation routine determines if a semantic object exists in the semantic object data model without any links to all other semantic objects. This condition is referred to as a partitioned semantic object data model. In order to determine whether a recursive relationship exists in the data model or the data model is partitioned, the present invention builds three maps, a circular formula map, a circular ID map, and a partition map. A map is the logical equivalent of an array or matrix. A map differs from a normal array in that the indices can be of (nearly) any type. For instance, while a standard array's contents are referenced by indexing the array with an integer (array ›2!), maps can use strings for indexing (map ›"Hello World"!). The present invention uses maps to track connectivity of certain items: formulas, semantic object IDs, and the data model as a whole. Each map has a slightly different purpose and maintains different lists of information at each index. The circular formula map uses a formula attribute as the map's index and each cell in the map references a list of formula attributes used within the indexing formula's expression property. The circular ID map uses a semantic object as the index and references a list of other semantic objects used to uniquely identify the indexing semantic object. Lastly, the partitioned album map uses a semantic object as its index but (as opposed to the circular ID map discussed above) references a list of all other semantic objects directly referenced by object link attributes contained somewhere within the indexing semantic object. It should be noted that while for formulas and semantic object IDs circularity (also called self-reference) is an error, within this context it indicates a fully connected (i.e., nonpartitioned) album. After all of the album's profiles have been examined (and are without error), the three maps are fully populated and are examined with regard to their connectivity. To test circularity, a recursive test is applied. This test is as follows: 1) For each nonvisited index in the map do: 2) Mark it as being visited. 3) For each item in the list referenced at this cell do: 4) Using the list item as this map's index; 5) If the map index has already been visited 6) if not testing for a partitioned album, return an error message, indicating a recursive relationship 7) If testing album partitioning, and not all cells have been visited after applying the recursive test to the first cell, then the album is partitioned. Return error. FIG. 20D describes the steps taken by the present invention to validate an album. Beginning at a step 1100, the system begins by analyzing each profile within the album. At a step 1102, the profile's type is determined. At a step 1104 the system performs a series of steps depending upon the type of profile being analyzed. FIG. 20E shows the steps taken when a profile analyzed in the album validation routine is a simple value type. Beginning at a step 1140, the system determines if the initial value of the profile matches the value type property. If not, an error message is produced at a step 1142 indicating a data type mismatch and the validation routine ends. At a step 1144, the system analyzes each attribute in the profiles list of derived attributes. At a step 1146, it is determined whether the initial value of the attribute matches its value type. If the answer is no, then an error message is produced at a step 1148 indicating a data type mismatch and the validation routine ends. FIG. 20F shows the steps taken by the present invention when the profile analyzed in the validation routine is a formula type. Beginning at a step 1160, the system checks the syntax and grammar of the profile's expression property. If the syntax and grammar are incorrect, an appropriate error message is generated at a step 1161. Once the expression property of the profile has been checked, the system then analyzes each formula attribute contained in the formula profile's list of derived attributes at a step 1162. At a step 1164, the system performs a formula expression validation as set forth as step 662 in FIG. 20A. In step 1166 it is determined whether the expression is valid. If not, an error message indicating an invalid expression is produced at a step 1168 and the validation routine ends. If the expression is valid, the system adds the formula attribute and referenced formula attributes contained in the expression property to the circular formula map at a step 1170. If the profile being analyzed in the validation routine is a group, the system performs the step shown in FIG. 20G. Beginning at a step 1190, the system begins a loop that analyzes each attribute contained in the group profile's list of derived attributes. First, the system determines at a step 1192 whether the group attribute's contents list only contains other groups. If so, a warning is produced at a step 1194 indicating there are no attributes in the group. As will be appreciated, step 1192 is performed recursively for any nested groups that a group may contain. Assuming that a group attribute contains at least one non-group attribute, the system sums the minimum cardinality of all member attributes at a step 1 196. At a step 1198, it is determined whether the sum of the minimum cardinalities is greater than the group's maximum count. If so, an error message is produced at a step 1200 indicating that the maximum count is too low. If the maximum count is set correctly, the system sums the maximum cardinality of all the member attributes at a step 1202. At a step 1204 it is determined whether the sum of the maximum cardinalities is less than the group's minimum count. If so, an error message is produced at step 1206 indicating that the minimum count is too high. If the profile analyzed by the validation routine is an object link, the system performs the steps shown in FIGS. 20H-20I. Beginning at step 1220, the system adds the base semantic object of the object link attribute to the partition map. At a step 1222, it is determined whether the contents list of the base semantic object is empty. If so, the system produces a warning at a step 1224 indicating the referenced semantic object is empty. At a step 1226, the system begins a series of steps that analyze each object link attribute contained in the profile's list of derived attributes. At a step 1228, the system determines the containing semantic object for the object link attribute being analyzed. At a step 1230, the base semantic object for the object link attribute is added to the containing semantic object's list in the partition map. At a step 1232, the system calculates the maximum path cardinality from the object link attribute to the containing semantic object. The system determines whether the maximum path cardinality to the containing semantic object is equal to one at a step 1234. If so, the system then determines whether the ID status of all containing groups that exist between the object link attribute and the containing semantic object are unique at a step 1236. If so, the system adds the base semantic object of the object link attribute to the containing semantic object's list in the circular ID map at a step 1238. At a step 1240, the system determines whether the ID status of the object link attribute is unique. If the ID status is unique, the system determines whether the maximum path cardinality from the object link attribute to the containing semantic object is equal to one at a step 1242. If not, the system then determines whether the maximum cardinality of the object link attribute is equal to one at a step 1244. If the maximum cardinality is greater than one, a warning is provided to the user to step 1246 indicating that the user has in fact modeled a group and therefore a surrogate group will be created. At a step 1248, it is determined whether the semantic object is the object link's container. If so, an error message is produced at a step 1250 indicating that the user has modeled an unexpressed subtype. If the semantic object is not the object link's container a warning message is produced at step 1252 indicating that the semantic object ID is nested in a group. At a step 1254, it is determined whether the object link's paired attribute has a maximum cardinality that is greater than one. If so, an error message is produced at step 1256 indicating a cardinality mismatch of the semantic object ID pairs exists. At a step 1258, the system determines whether the object link being analyzed is a subtype or parent type. If so, it is determined at a step 1260 whether the container of the subtype or parent type is a group. If so, the system performs the group count testing set forth in step 1196 in FIG. 20G. Returning now to FIG. 20D, the system analyzes the three maps produced. in FIGS. 20E-201 described above. At a step 1106, the circular formula map is analyzed. At a step 1108 it is determined whether the circular formula map indicates a formula attribute includes a recursive formula expression property. If so, an error message is produced at a step 1110 indicating the formula attribute is recursively defined. At a step 1112, the circular ID map is analyzed. At a step 1114 it is determined whether the circular ID map indicates a semantic object that is uniquely identified by itself. If so, an error message is produced at step 1116 indicating the semantic object includes a recursive identification. At a step 1118, the partition map is analyzed. Step 1120 determines whether all semantic objects in the album are connected. If not, the system produces a warning message at step 1122 indicating the album is partitioned. As can be seen, the validation routine operates to determine if the user has made any errors in creating the semantic object data model. In addition to determining whether the data types of the attributes are correctly created, the system looks for recursive relationshi | ||||||