Computer system for creating semantic object models from existing relational database schemas.

-1 COMPUTER SYSTEM TO CREATE SEMANTIC OBJECTS MODELS FROM EXISTING RELATIONAL DATABASE SCHEMES

Field of Invention

The present invention relates to computer systems in general, and in particular to computer systems that store and retrieve information in a relational database.

Background of the Invention

At some point, many computer users have had a need to store and retrieve certain kinds of information. Typically, the information is stored in a computer system using any of several commercially available database programs. These programs allow a user to define the types of information to be stored in the database, and also provide ways for users to enter data into the database and print reports for people who want to retrieve previously stored information. .

One of the most popular types of databases is relational databases. In a relational database, data is stored in rows of a two-dimensional table that has one or more columns that define the types of data that are stored. Traditionally, it has been difficult for users who are inexperienced or do not have sophisticated knowledge to create relational database tables (also referred to herein as a database schema) in a way that

00007.0013

-2 accurately reflects the user's idea of ​​how data should be stored in the database.

A new approach to allowing users to create relational database schemas is a database modeling system called SALSA ™ developed by Wall Data Incorporated of Seattle, Washington. This system allows users to create a model of the data to be stored in the database. The model consists of one or more semantic objects that represent a complete item, such as a person, an order, a company, or whatever else a user might think of in terms of a single entity to be stored in the database. Each semantic object includes one or more attributes that store identifying information about the semantic object and may contain object link attributes that define relationships between two or more semantic objects. After the user has completed the semantic object model, the SALSA database modeling system analyzes the semantic object model and creates a corresponding relational database schema that stores the data on the computer. Details of the SALSA database modeling system are set forth in copending, jointly assigned United States Patent Application No. Serial 08 / 145,997, 25 filed October 29, 1993 which is mentioned herein by reference.

The benefit of the SALSA database modeling system is that it allows users to easily define the data to be stored in a database, as well as the relationships between the data, without requiring the user to know anything about the data. management systems

00007.0013

-3 databases that underlie it, and that control the way data is stored in memory and / or on the computer's hard drive. Users can simply manipulate the building blocks of the semantic object model and do not have to worry about relational database concepts such as tables, columns, primary and foreign keys, intersection tables, and the like. While the database modeling system is described in the '997 patent application which represents a significant improvement in the technique of database modeling, no mechanism is provided to automatically produce an object model. semantics of an existing database schema that could have been created with a traditional relational database program.

Therefore, there is a need for a system that can analyze an existing relational database in order to create a corresponding semantic object model.

Summary of the Invention

The present invention is a computer system programmed to automatically create a semantic object model from an existing relational database schema. The schema is parsed by reading the information from the relational database catalog and creating a corresponding semantic object for each table defined in the database. Each column defined for a table in the database is used to create a corresponding single-valued attribute within the corresponding semantic object. If the database catalog includes the relationship information, the catalog is then parsed to determine if

00007.0013

-4 a box includes any foreign key. Foreign key information is used to create corresponding object binding attributes that define relationships between two or more semantic objects as well as to create multi-value group attributes or multi-valued single-value attributes within a semantic object .

If the database catalog does not provide relational information, the user is prompted to indicate the tables in the database that are related as well as to indicate which columns of the tables represent foreign keys. This information is then used to modify the semantic object model to reflect the relationships and multi-value attributes within the semantic object model.

Brief Description of Drawings

The foregoing aspects and many of the advantages expected with the invention will be more readily appreciated as it is better understood in relation to the detailed description that follows, in conjunction with the accompanying drawings, where:

Figure 1 is a diagrammatic representation of a typical relational database schema;

Figure 2 is a diagrammatic representation of a semantic object model created by the invention corresponding to the database schema shown in Figure 1;

Figure 3 is a block diagram of a computing system according to the present invention, which is programmed to create a semantic object model from an existing relational database schema;

00007.0013

Figures 4A-4D are a series of flow charts showing the steps developed by the computing system of the present invention to create a semantic object model from an existing relational database schema;

Figure 5 is a flow chart showing the steps taken by the computer system of the present invention to detect intersection boxes when the relational database catalog provides relationship information.

Figure 6 is a flowchart showing the steps taken by the computer system to detect the tables in the relational database schema that must be converted to multiple-value groups or 15 single-valued attributes, with multiple values ​​in the semantic object model.

Figures 7A and 7B are flowcharts showing the steps that are followed for the computing system to convert a semantic object within a semantic object model to an object link attribute, when the relational database catalog provides relationship information;

Figures 9A-9D are a series of flow charts showing the steps taken by the computing system to create a multi-valued group attribute within a semantic object;

Figure 10 is a flow chart showing the steps taken by the computer system to create a single-valued, multivalued attribute within a semantic object to correspond to a table in a relational database schema;

00007.0013

-6 Figure 11 is a flow chart of the steps performed by the computing system of the present invention to allow a user to select a profile associated with a group or single-valued attribute within the semantic object model; Y

Figures 12A-12D are a series of flow charts showing the steps developed by the computer system of the present invention to create object link attributes, multi-valued group attributes, and multi-valued single value attributes in an object model when the corresponding relational database catalog does not include relationship information.

Detailed Description of the Preferred Modality

As described above, the present invention is a system for creating a semantic object model to correspond to an existing relational database schema that resides within the memory of a computing system. Once completed, the semantic object model allows a user to easily update or modify the database schema by manipulating the components of the semantic object model. In this way, users can manipulate the relational database without having to understand the relational database management system or the query language that is commonly used to avoid the schema.

Figure 1 shows a representation of a relational database schema. This schema stores database information on a computer system operated by an art gallery owner. The schema includes six relational tables. A frame 5

00007.0013

-7 stores information regarding a gallery client. Table 5 includes two columns labeled Name and Telephone that store the customer's name and the customer's telephone number. As will be appreciated by those skilled in the field of relational databases, the database management system maintains a record to indicate that the primary key in Table 5 is the name column. A frame primary key identifies a unique entry in the frame, that is, a particular gallery customer.

Table 7 shows the information regarding an artist who is represented in the gallery. Table 7 includes two columns labeled Name and Date of Birth that store the name of the artist and the year he was born. The primary key in Table 7 is defined as an entry in the name column.

A frame 9 stores information regarding the various media with which an artist can work. The table includes two columns. The first column is labeled Name and serves to link an entry in the second column with a particular artist in relational frame 7. The second column is labeled Medium and stores text that defines a particular artistic medium such as oil, watercolor, glass, ceramic, etc. The primary key in Table 7 is defined as the combination of the entries in the Name and Medium columns.

A table 11 stores information regarding a particular painting that is on display in the gallery. The table includes three columns labeled Name, Date Made, and Name_l that stores a name for the painting, the date the painting was finished, and a key.

00007.0013

-8exterior for a column of table 7 in order to link a painting with its artist. The primary key in Table 11 is an entry in the Name column.

A table 13 stores information regarding purchases made by an art gallery customer. The table includes four columns labeled Name_l, Date, Price, and Name_2. The column labeled Name_l carries the name of a customer while the column labeled Date stores the date the paint was purchased. The column marked Price stores the price paid for the painting. Finally, the column marked Name_2 is named after a painting. Name_l is a foreign key to table 5 and Name_2 is a foreign key to table 11.

The last table in the database is table 15 that relates an entry in table 5 to an entry in table 7. Table 15 includes two columns: Name_l and Name_2. Each column stores a foreign key to table 5 and table 7 respectively. Table 15 allows the database management system to link gallery clients to artists on display in the gallery. The primary key in Table 15 is selected as the combination of entries in the two columns, Name_l and Name_2.

The database schema depicted in Figure 1 is typical of a relational database schema created with traditional relational database programs. Computer users unfamiliar with relational database programming may find it difficult to create the schema without the help of expert database programmers. The

00007.0013

-9creating the schema shown in Figure 1 requires knowledge of database concepts such as tables, primary keys, foreign keys, and intersection tables.

As noted above, the SALSA database modeling system allows a user to create database schemas without knowledge of relational database concepts. Figure 2 shows a semantic object model 20 corresponding to the relational database schema shown in Figure 1. The semantic object model is comprised of three semantic objects. A semantic object 22 represents a gallery client. A semantic object 30 represents an artist whose work is displayed in the gallery and a semantic object 40 represents paintings on display in the gallery. Each semantic object in object model 20 has many attributes. The attributes represent information concerning each semantic object that is stored in the database. For example, semantic object 22 has an attribute labeled "Name" that represents the customer's name, an attribute labeled "phone" that represents the customer's phone number that is stored in the database. Additionally, the customer includes a group attribute labeled Acquisition that represents a sale made in the gallery. The group attribute, Acquisition, comprises three single-valued attributes that represent the date the acquisition was made, the price of the purchased painting, and an object link attribute that relates to the acquisition of a particular painting represented by an example. of the semantic object 40. The attributes that define only one example of the semantic object are shown with two stars to

00007.0013

-1010 to the left of the attribute name. The objerc binding attributes that define relationships between two semantic objects in the semantic object model are enclosed in a box to differentiate them from the other single-value or group objects in the semantic object.

As stated in the patent application ^r997, some attributes have their minimum and maximum cardinality exposed as subscripts in the lower right corner of the attribute name. The minimum cardinality refers to the minimum number of attribute examples that the semantic object must have to be valid, while the maximum cardinality refers to the maximum number of examples that the attribute can have to be valid. For example the group attribute labeled Acquisition on semantic object 22 has a minimum cardinality of zero, indicating that a gallery customer may not have made an acquisition. Similarly, the maximum cardinality of the group acquisition is N, indicating that a client may have made more than one acquisition in the gallery. Cardinality numbers also apply to object binding attributes. For example, semantic object 22 includes an Artist tagged object link attribute that links a client in the database with an artist to keep track of artists the client is interested in. The object link labeled Artist is multi-valued, that is, it has a maximum cardinality of N, thus indicating that the client may be interested in many artists.

Semantic object 30 represents an artist whose work is exhibited in the gallery. The artist semantic object includes two single-valued attributes, labeled

00007.0013

-1111

Name and Date of Birth, which represents the biographical information stored near the artist. The attribute, name, is indicated as unique to mean that two artists in the same database do not have the same name. Additionally, the semantic object 30 includes a single valued, multi-valued attribute, labeled Medium, which represents various media in which the artist can work. Finally, the semantic object 30 also includes two multi-valued object link attributes marked Paint and Customer that link an artist to a painting and an artist to a customer.

The last semantic object 40 in the semantic object model represents a painting on display in the gallery. The semantic object 40 includes two single-valued attributes, marked Name and Date of the Work. The name of the painting is indicated as unique among the names of paintings stored in the database. The semantic object 40 also includes two object link attributes. A first object link attribute is marked "Artist" and represents a relationship between a painting and an artist. The cardinality of this relationship is 1.1, indicating that a painting must have at least one artist and can have at most one artist. The object link attribute labeled Customer represents the relationship between a painting and a customer. This attribute has a cardinality of 0.N, indicating that customers may not be interested in a painting or that many customers may be interested in a painting.

As noted earlier, the benefit of the semantic object model 20 shown in Figure 2, as opposed to conventional database programs, is that a

00007.0013

-12user can update or modify the database by adding or deleting semantic objects, or adding or deleting attributes within a semantic object. By manipulating the components of the semantic object model, a user can create or modify a relational database in a way that reflects the way the user thinks about the data to be stored in the database without having to understand the relational database concepts required to create the schema shown in Figure 1.

As noted above, the SALSA database modeling system being developed by Wall Data Incorporated allows a user to create a semantic object model and parses the model in order to create a corresponding relational database schema. However, many computer users will have already created a database schema using currently available relational database programs such as Microsoft Access® or Borland Paradox®. In order to allow unsophisticated users to easily update or modify these databases, the invention creates a corresponding semantic object model from an existing relational database schema.

Returning to Figure 3, a computer system for augmenting the present invention is shown therein. The computer system generally comprises a central processing unit 70 having an internal memory 72 and a permanent storage medium, for example a disk drive 74. Commands are input to the CPU using a keyboard 78 and a pointing device, for example. example a mouse 80. The CPU generates a graphical interface of

00007.0013 user displayed on a screen or monitor 76.

Within memory 72 resides a set of programmed instructions that instructs the CPU to parse an existing relational database schema to create a corresponding object model that displays a user on screen 6. The programmed instructions can be permanently stored in a read-only memory or they can be received by the computer system from a floppy disk, a CD-ROM or in a modem connected to the CPU. In the presently preferred embodiment of the invention, the CPU is programmed in an object-oriented language such as C ++. However, those of skill in the art will recognize that other programming languages ​​can be used if desired.

The following flowcharts describe the operation of the computer program implemented by the central processing unit in order to produce a semantic object model from an existing relational database schema. As stated in the '997 patent application, the computer system uses a series of C ++ classes in order to store a representation of a semantic object model. For ease of reference, data members of these classes that are important to an understanding of the invention are reprinted below. The procedure or methods of each class that creates the semantic object model are not shown, but the operation of the procedures is discussed below. Those skilled in the field of computer programming will be able to create the required methods from the description of the present invention, as follows.

00007.0013

Album class

<td>Data Member</td><td>Data Management</td>

<td>Name</td><td>Text</td>

<td>Creation date</td><td>Date</td>

<td>Created by</td><td>Text</td>

<td>Contents</td><td>Unordered list of pointers</td>

00007.0013

-1515

Semantic Object Class

<td>Data Member</td><td>Data Type</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Qualification</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Contents</td><td>Ordered list of pointers</td>

Simple Value Profile Class

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Qualification</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Value Type</td><td>Any DBMS Data Type</td>

<td>Length</td><td>Whole</td>

<td>Format</td><td>TEXT</td>

<td>Initial value</td><td>TEXT</td>

<td>Cardinality Min</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Derived Attributes</td><td>Pointers list</td>

<td>Reference Profiles</td><td>Pointers list</td>

Object Link Profile Class

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Qualification</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Min cardinality</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Base Semantic Object</td><td>Pointer</td>

<td>Derived Attributes</td><td>Pointers List</td>

<td>Reference Profiles</td><td>Pointers List</td>

00007.0013

-16 Class Attribute Value Simple

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Value Type</td><td>No DBMS Data Type</td>

<td>Length</td><td>Whole</td>

<td>Format</td><td>TEXT</td>

<td>Initial value</td><td>TEXT</td>

<td>Min cardinality</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Base Profile</td><td>Pointer</td>

00007.0013

-1717

Group Profile Class

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Min cardinality</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Min Count</td><td>Whole</td>

<td>Max Account</td><td>Whole</td>

<td>Format</td><td>TEXT</td>

<td>Derived Attributes</td><td>Pointers List</td>

<td>Contents</td><td>Pointers list</td>

<td>Reference Profiles</td><td>Pointers list</td>

00007.0013

-18 Class Attribute Group

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Cardinality Min</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Min Count</td><td>Whole</td>

<td>Max Account</td><td>Whole</td>

<td>Format</td><td>TEXT</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Contents</td><td>Ordered list of pointers</td>

<td>Base Profile</td><td>Pointer</td>

00007.0013

-19 Class Attribute of Formula

<td>Data Member</td><td>Data Type</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Expression</td><td>TEXT</td>

<td>Formula Type</td><td>(Not stored, stored)</td>

<td>Value Type</td><td>Any DBMS Data Type</td>

<td>Length</td><td>Whole</td>

<td>Flag Required</td><td>(If not)</td>

<td>Format</td><td>TEXT</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Base Profile</td><td>Pointer</td>

00007.0013

-20 Class Object Link Attribute

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Identification Status</td><td>(Unique, not unique, none)</td>

<td>Min cardinality</td><td>Whole</td>

<td>Max Cardinality</td><td>Whole</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Base Profile</td><td>Pointer</td>

<td>Pointer Pair</td><td>Pointer</td>

Related Attribute Class

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Qualification</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Pointer Pair</td><td>Pointer</td>

<td>Base Profile</td><td>Pointer</td>

00007.0013

-21 Class Attribute Subtype

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Title</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Flag Required</td><td>(If not)</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Base Profile</td><td>Pointer</td>

<td>Torque Pointer</td><td>Pointer</td>

Class Attribute of Subgroup of Subtype

<td>Data Member</td><td>Type of data</td>

<td>ID</td><td>Whole</td>

<td>Name</td><td>TEXT</td>

<td>Qualification</td><td>TEXT</td>

<td>Description</td><td>TEXT</td>

<td>Flag Required</td><td>(If not)</td>

<td>Min Count</td><td>Whole</td>

<td>Max Account</td><td>Whole</td>

<td>Container Pointer</td><td>Pointer</td>

<td>Contents</td><td>Ordered list of pointers</td>

Returning to Figures 4A-4D, the overall operation of the computer system programmed according to the invention is shown in that figure. Starting at step 100, the computer system prompts the user to enter the type or brand of the relational database program used to create the relational database schema that exists in the memory of the computer. In general there are two types of relational databases. The first type has a catalog that includes relationship information. As will be described below, the relationship information indicates which columns of a table are defined as foreign keys to others.

00007.0013 tables in the database. The second type of database does not include the relationship information in the database catalog. The present invention is designed to work with any type of database.

After the user has entered the type of the relational database program that was used to create the existing relational database schema, the program uses a lookup table (not shown) that is stored within internal memory of computer or disk drive to determine if the catalog includes the relationship information in step 102

If the catalog does not include the relationship information, the computer system creates the corresponding semantic object model using the step shown in Figures 12A-12D as will be described below.

If the relational database catalog includes the relationship information, the computer system first opens the relational database catalog in step 106. The catalog includes a definition of each relational table in the database as well as a definition of each column within a particular table.

As in step 108, the computer system first creates an example of the album class defined above. The album class is used to keep track of each semantic object in the semantic object model. After creating the example of the album class, the computer system begins to be a circuit in step 110 that parses each table defined in the database catalog. In step 112, the computer system creates an example of the semantic object class for each table defined in the database catalog. Each example of the class of

00007.0013 semantic object represents a semantic object in the corresponding semantic object model that is displayed to the user.

The example of the semantic object class is assigned with a unique identification number in step 114. In step 116, the member variable Name is initialized to the name of the table defined in the database from which it is created the semantic object. In step 118 (Figure 4B) the Title and Description member variables are initialized as empty strings. In the example shown in Figures 1 and 2, steps 110-118

<td>will create</td><td>the</td><td>object</td><td>semantic</td><td> 22</td><td colspan="2">the client's</td><td>to</td><td>depart</td><td>of</td><td>the</td>

<td>table 5,</td><td>the</td><td>object</td><td>semantic</td><td>of</td><td>Artist</td><td> 30</td><td>to</td><td>depart</td><td>of</td><td>the</td>

<td>table 7</td><td>the</td><td>object</td><td>semantic</td><td>of</td><td>painting</td><td> 11</td><td>to</td><td>depart</td><td>of</td><td>the</td>

table 11.

As already noted, the album class example created by the semantic object model maintains a list of every semantic object included within the model. In a step 120, a pointer · is placed on the newly created example of the semantic object class in the album content list.

For each semantic object created, the computer system creates an example of the object link profile class. As described in the '997 patent application, the profiles are used as templates from which the corresponding attributes are created. Profiles carry a list of attributes that are derived from them. If a user changes a property, that is , the commission values ​​of the member variables of a profile, the computer system can then update the property on each attribute derived from the profile, thus allowing it to be

00007.0013 make simple and efficient attribute property changes globally.

In step 124, the object link profile identification member variable is assigned a unique number. The Object Link Profile Name, Title, and Description member variables are initialized from the corresponding semantic object in step 126. The Identification State member variable is initialized to none in step 128. The Identification State member variable (ID__Status) can be set to any of the listed values ​​none, not unique, or unique. in step 130, the base semantic object pointer is initialized to the address of the semantic object that caused the object binding profile to be created.

Turning now to Figure 4C, once the semantic object and the object link profile skipped, the computer system initiates a circuit at step 140 that parses each column defined in the database catalog for a table within the relational database. For each column defined in a table, the computer system creates an example of the single-valued attribute class defined earlier in step 142.

For example, the column marked Telephone in table 5 is used to create the single-valued attribute marked Telephone in the customer semantic object 22. The member variable ID of the newly created single-valued attribute is assigned with a number unique in step 144 and the Description and Title member variables are initialized as empty strings in step 146. In a step 148, a Minimum Cardinality member variable is initialized to zero and the Cardinality member variable 00007.0013

-2525

Maximum is initialized to one. In step 150, the single-valued attribute container pointer is initialized to address the semantic object in which the attribute is logically contained. Typically, the container pointer points to either an example semantic object class or a group attribute, as will be discussed below.

Once the single-valued attribute has been created, the computer system creates an example of the single-valued profile class in step 152. In a step 154, the Name, Description, Title, Identification Status, Minimum Cardinality and Maximum Cardinality, as member variables, are initialized from the corresponding previously created simple value attribute.

Returning to Figure 4D, a pointer to the corresponding single-valued attribute is placed in the single-valued profile list of derived attributes and the profile address is used to initialize the base profile pointer of the corresponding attribute in step 156 In step 160, the computer system determines whether all the columns defined for the table under consideration have been analyzed. If not, the computer system circuits back to step 140 (Figure 4C). Once all the columns in a particular table have been parsed, the computer system determines whether all the tables defined in the database catalog have been parsed in step 162. If not, the computer system returns from back to step 110 (Figure 4A) and create another example of the semantic object class as described above.

After the steps shown in Figures 4A-4D have been completed by the computer, the corresponding semantic object model will contain a plurality of

00007.0013

-2626 semantic objects, each of which contains a single value attribute for each column defined in the corresponding relational database table. After creating the semantic objects, the computer system interprets the relationship information stored in the database catalog to create the appropriate object link attributes and multivalued group or multivalued single-value attributes.

To determine whether a table in the database catalog should be translated into a multivalued object link attribute instead of a semantic object, the comoutation system sweeps the database catalog for intersection tables that only contain columns that are defined as foreign keys.

In the example shown in Figure 1, table 15 is an intersection table because its columns are labeled

Name 1 ”and

Name 2 as columns outside the tables and 7 respectively.

As shown in Figure 5, the computer system is programmed to detect intersection tables by initiating an outer circuit in step 200 that analyzes the definition of each table in the database catalog. In step 202, the computing system starts an internal circuit that analyzes each column defined by a table. For each column, the computer system reads the relationship information that is stored in the catalog in step 204. In step 206, the computer system determines whether the column is defined as a foreign key. If not, the computer system is programmed to determine that the table cannot be an intersection table and processing continues to the next table.

00007.0013

-2727 defined in the database catalog.

If the answer to step 206 is yes, the computer system then determines whether all the columns of a table have been analyzed. Otherwise, the computer system loops back to step 202 and analyzes the rest of the columns in the table. If each column in a table is defined as a foreign key, the computer system marks the table as an intersection table in step 210. The name of table 10 is then added to a list of intersection tables in step 212.

After adding the table to the list of intersection tables, processing then proceeds to a decision block 214, where the computer system determines whether all the tables in the database catalog have been analyzed. If not, the following table in the database catalog is parsed. Once all the tables in the database catalog have been analyzed, the computer system will have a list of each intersection table 20 defined within the database schema and processing stops in step 216.

Once all the intersection tables in the database have been found, the computer system does a scan of the database catalog for the 25 tables that should have been moved to multivalued group attributes or value attributes simple multivalued. For example, Table 9 shown in Figure 1 is not representative of a semantic object but does keep a record of many media in which an artist can work. Therefore, the computer system will operate to cancel the semantic object model created by this

00007.0013

-28 table and will replace it with a single-valued attribute labeled Medium that has a maximum cardinality of N within semantic object 30.

As shown in Figure 6, the computer system initiates a circuit in step 240 that analyzes each table defined in the database catalog that has not previously been marked as an intersection table. In a decision block 242, the computer system determines whether the primary key of the table under consideration includes two or more columns. Tables that have primary keys that do not include two or more columns are not modeled as multi-valued single-valued or multi-valued group attributes. The process then goes to step 244 where the decision is made whether all the non-intersecting tables in the database catalog have been analyzed.

If the answer to step 242 is yes, and the primary key includes at least two columns, the computer system initiates an internal circuit that parses each column defined as part of the primary key of the table in step 246. In step 248 , the relationship information for each column defined as part of the primary key of the table can be read. At decision block 250, the computing system determines whether the column under consideration is also defined as a foreign key to a column in another relational table. If not, the computer system then determines whether all columns defined as the 2nd primary key of the table have been parsed in step 252. Otherwise, the processing circuits return to step 246 and the next defined column as the primary key is parsed. If the answer to step 252 is yes, then the process continues to step

00007.0013

244 and the next non-intersection table in the database catalog is parsed.

If the answer to decision step 250 is yes, the computer system then determines whether the table under consideration has more than one non-foreign key column in step 254. Otherwise, the table is marked as a single-valued attribute multivalued and the table name is added to a list of multivalued single-valued attributes in step 256. If the table has more than one non-foreign key column, the table is marked as a multi-valued group and the table name for that table is added as a list of the multi-valued groups in a step 258. In addition to adding the table to In the multivalued group list, the computer records the number of columns defined as the primary key of the table for the reasons explained below.

Processing then proceeds to step 244 which determines if all non-intersecting tables in the database catalog have been analyzed. If not, the next table defined in the catalog is parsed in step 240. If all non-intersecting tables have been parsed, processing ends in step 260. After the computer system has performed the steps shown in Figure 6, it will have created a list of all the tables in the database that represent the multi-valued single-valued and multi-valued group attributes.

After performing the step shown in Figure 6, the computer system then searches the database catalog to find tables not marked as intersection tables, multi-valued single-valued or multi-valued group attributes that include foreign keys for others.

00007.0013

-3030 tables in the database. If the foreign keys are not part of the primary key of a table, the present invention translates the foreign keys to the corresponding object binding attributes that define the relationship between two semantic objects. In the example shown in Figure 1, table 11 includes a column marked Name_l that must be translated into an object link attribute to link the Artist 30 semantic object to the Painting 40 semantic object.

As shown in Figures 7A and 7B, the computer system initiates a circuit at step 280 that analyzes each table in the database that had not previously been marked as an intersection table, multivalent single value attribute, or multi-valued group. In a step 281, the computing system initiates an internal loop that analyzes each defined column for the remaining tables. The relationship information of a column is read in step 282 and the decision is made in step 284 as to whether the column is defined as a foreign key to a column in another table in the related1 database.

Those skilled in the art will recognize that a foreign key can be defined as multiple columns in a table. In that case, step 284 should parse the entire foreign key such that only one pair of object binding attributes is created for the entire foreign key. If a column under consideration is not a foreign key, the process then goes to step 28 6, where it is determined whether all the columns in the table have been parsed. Otherwise, the process returns to step 281 and the next column in the table is parsed.

Once all the columns in the table have been

00007.0013

-3131 parsed, the process goes to step 288, where it determines if all the remaining tables in the database catalog have been parsed. Otherwise, the process returns to step 280 and the next multi-valued attribute 5 or multi-valued group non-intersection type table is analyzed.

This process continues until all of those tables have been parsed and the process stops at step 289.

If the answer to decision block 284 is yes, meaning that a table includes a column 10 that is defined as a foreign key to a column in another table, the computer system creates two examples of the object binding attribute class in step 290.

After the object binding attribute class examples have been created, the attributes are placed into the corresponding semantic objects to represent the relationship defined by the foreign keys. For example, as shown in Figure 1, table 7 that stores data regarding an artist is linked to table 11 that stores data regarding a painting by means of the foreign key stored in the column labeled Name_l.

This relationship is represented in the corresponding semantic object model (shown in Figure 2) by the object link attribute labeled Painting within the semantic object 30 and the corresponding object link attribute 25 labeled Artist remaining within the semantic object. 4 0.

To logically place the newly created object link attributes on the correct semantic object, the computer system first places a pointer to the 30 newly created object link attributes in the list of attributes derived from the link profiles of

00007.0013

-32object associated with the semantic object that represents the table that has the foreign key and the semantic object that represents the table to which the foreign key refers in step 292. In the Artist-Painting example described above, a pointer to an object link attribute would be placed on the list of attributes derived from the object link profile associated with the Artist 30 semantic object and the list of attributes derived from the link profile of object associated with semantic object Painting 40. In addition, the base profile pointers of the object link attributes are set equal to the address of its associated object link profile.

In a step 294, the member variables of the object link attributes are initialized from their associated object link profile. The even pointers of the object link attributes are then adjusted to point to each other in step 295.

In step 296 (FIGURE 7B), a pointer to the object binding attribute associated with the table that has the foreign key is added to the Contents list of the semantic object associated with the table to which the foreign key refers. In step 298, a pointer to the object binding attribute associated with the table to which the foreign key refers is added to the Contents list of the semantic object associated with the table that has the foreign key. The Container pointers of the object link attributes are updated with the address of the semantic object in which they are logically contained in step 300.

In a step 302, the maximum cardinality of the object binding attribute contained in the semantic object,

00007.0013 associated with the table that does not have the foreign key, is initialized to N to represent a one-to-many relationship. For example, in the Artist-Painting example described above, it can be seen that the object link attribute marked Painting "within the semantic object 30 Artist has a maximum cardinality of N, representing the fact that an artist may have painted many paintings . In a step 304, the computing system loops back to step 280 (FIGURE 7A) and the next table in the database catalog is analyzed.

Those skilled in the art will recognize that the steps shown in FIGS. 7A and 7B will incorrectly identify one-to-one relationships as one-to-many relationships. However, the user can easily correct this by altering the Maximum Cardinality property of the object binding attribute after the entire semantic object model is complete. Alternatively, the computer system can look at the database catalog to determine if the foreign key is unique. If so, the maximum cardinality of the object binding attribute on the semantic object associated with the table that does not have the foreign key is set to one.

After the object binding attributes representing one-to-many relationships (or one-to-one if the foreign key is unique) have been added to the semantic object model, the computing system then parses the list of tables intersection to create multivalued object binding attributes that represent many-to-many relationships in the semantic object model.

Returning now to FIGURE 8, the computer system creates the object link attributes that

00007.0013 represent many-to-many relationships by parsing each of the tables within the intersection table lists beginning with step 350. In step 352, two instances of the object link attribute class are created. In step 354, a pointer to the newly created object binding attributes is added to the Derived Attributes list of the object binding profiles associated with the tables to which the foreign keys in the intersection table refer. The member variables of the object binding attributes are initialized from their corresponding object binding profiles in step 356. The even pointers of the two object link attributes are then initialized to point to each other in step 358.

In step 360, the computer system logically places the object link attributes on the associated semantic object by adding a pointer to the object link attribute in the Contents list of the corresponding semantic object. For example, as shown in FIGURE 1, Table 15 is an intersection table representing the many-to-many relationship between a client and an artist. In the semantic object model shown in FIGURE 2, the intersection table is represented as multi-valued object link attribute marked Artist within semantic object 22 and multi-valued object link attribute marked Customer found in semantic object 30 . Therefore, the object link attribute initialized from the object link profile associated with the Customer 22 semantic object is added to the Contents list of the Artist 30 semantic object and the object link attribute initialized from the link profile of object associated with

00007.0013

-3535 Artist 30 semantic object is added to the Contents list of Customer 22 semantic object. The container pointers of each object binding attribute are updated to match the address of the semantic object in which they are logically contained in step 362. In a step 364, the maximum cardinality of both object link attributes is analyzed for N ".

Because the computer system initially creates a semantic object for each table found in the database, the semantic objects will be inappropriately created for each intersection table defined in the database schema. Therefore, the computer system deletes the semantic object and its corresponding object link profile created for the intersection table in step 3G6.

In a step 368, the computing system determines whether each table in the list of intersection tables has been analyzed. If not, the system returns to step 350 and retrieves the next entry in the list of intersection tables. Once all the entries in the list of intersection tables have been analyzed, the process is complete.

After the steps shown in FIGS. 7A-7B and 8 are completed, the semantic object model will contain object link attributes representing one-to-many and many-to-many relationships.

FIGURES 9A-D show the steps taken by the present invention to correctly model attributes that must be placed in a multi-valued group attribute. As can be seen in FIGURE 2, the Customer 22 semantic object includes a multi-valued group marked Acquisition. The multivalued group included two single-valued attributes

00007.0013

-3636 marked 'Roof and Prices, as well as an object link attribute marked Paint that relates semantic object 22 to semantic object 40. Because multivalued groups are stored in their own table in the relational database, the The computer system will incorrectly create a semantic object that corresponds to the multivalued group table during the first step of the analysis. Therefore, the steps shown in FIGURES 9A-9D operate to remove the semantic object created by the table that stores the multivalued group data and will place the attributes corresponding to the columns of the table within a multivalued group attribute within the appropriate semantic object ·.

Starting at step 380, the computer system sorts the entries in the multivalued group list created by the steps shown in FIGURE 6, by the number of columns in their primary key. Once this is complete, the computer system processes each entry in the multivalued group list starting with the entry that has the most columns in its primary key in step 382.

In a step 384, the computer system parses each entry in the multivalued group list. For each multivalued group table in the list, the computer system creates a Group Attribute class instance in a step 386. The variable of ID member is assigned to a unique number in step 388 and Title and Description member variables are initialized to empty strings in step 390. In a step 392, the Minimum Cardinality of the group is initialized to zero and the Maximum Cardinality is initialized to N.

00007.0013

-3737

Each group attribute stores an indication of the minimum number of member attributes within the group that must be present in order for the entire group to be valid. This number is stored in the Minimum Count member variable and is initialized to zero in step 394. Similarly, the member variable, Maximum Count, stores the maximum number of member variables that can be present in the group. in order for the group to be valid.

Returning now to FIGURE 9B, the group attribute container pointer is set equal to the address of the semantic object associated with the table referenced by the foreign key that is part of the primary key of the multivalued group table in step 398. Finally, in a step 400, the computing system adds a pointer to the newly created group attribute in the Contents list of the semantic object it contains.

Once the group attribute has been created, the computer system creates a corresponding instance of the group profile class in a step 402. The id member variable is assigned a unique number in a step 404 and the variables of the members of Name, Description, Title, Minimum Cardinality, Maximum Cardinality, Account Min. and Basin Max. they are initialized from the associated group attribute in a step 406.

During the first pass that the computer system makes to create the semantic object model, the computer system will have created a single-valued attribute for the foreign key column (s) that is part of the primary key. Therefore, the computing system removes the simple value attribute (or attributes if the key

00007.0013

-3838 external is defined as multiple columns) and its corresponding profile from the semantic object model in step 408.

Columns in a multivalued group table might contain a foreign key that was incorrectly identified as a single-valued attribute. Therefore, the computing system begins a cycle at step 401 that parses the remaining columns of the table, for example, those columns not defined as part of the primary key. In a step 412, the computer system reads the relationship information for each column and determines if the column is a foreign key in a step 414. If it is not, the computer system proceeds to a step 416 where it determines whether all the columns of the table have been analyzed. This process is repeated until all the remaining columns in the table have been analyzed.

If the answer to step 414 was yes, it means that the column was defined as a foreign key, the computer system performs the steps shown in FIGURE 9C. Again, if the foreign key was defined as two or more columns, the steps in FIGURE 9C are performed for each column included in the foreign key. Starting at a step 420, the computing system overrides the single-valued attributes and profiles originally created for the foreign key columns from the semantic object model. In a step 422, the computer system then creates two instances of the object link attribute class. The member variables of the object binding attribute class are initialized from their corresponding object binding associated profiles, with the semantic object

00007.0013

-3939 created by 1st multivalued group attribute table and the object binding profile associated with the semantic object created from the table referred to by the foreign key in a step 424.

In step 426, the Pair pointers of the object link attributes are positioned to point to each other. A pointer to the object binding attribute associated with the semantic object created from the multi-valued group table is added to the Contents list of the semantic object associated with the table to which the foreign key refers in step 428. Similarly, a pointer to the object binding attribute associated with the semantic object created from the table that the foreign key refers to is added to the list of contents of the semantic object associated with the multi-valued group table in one step. 430.

In a step 432, the Container Pointers of each object binding attribute are updated to point to its containing semantic object. The Maximum Cardinality of the object binding attribute that is included in the semantic object associated with the table to which the foreign key refers is initialized to N in a step 434. In a step 436, the process returns to step 416 in FIGURE 9B and the remaining columns of the table are analyzed.

After each column in the multivalued group attribute table has been analyzed, the process continues with the steps shown in FIGURE 9D. In a step 440, the Contents list of the semantic object originally created for the multivalued group table is copied into the Contents list of a newly created group attribute.

In step 442, the Derived Attributes list of the group attribute profile is updated to include 00007.0013

-4040

<td>attribute</td><td>of</td><td>group</td><td>new and pointer</td><td>of</td><td colspan="2">profile</td><td>base</td><td>of</td>

<td>attribute</td><td>of</td><td>group</td><td>he gets to aim</td><td colspan="2">toward</td><td>the</td><td>profile</td><td>of</td>

<td>attribute</td><td>of</td><td>group</td><td>newly created.</td><td>In</td><td>the</td><td colspan="2">step 444,</td><td>the</td>

The group attribute's Contain pointer is set equal to the address of the contained semantic object.

Any object link attributes within a multi-valued group are paired with a corresponding object link attribute that is located on another semantic object. For example, as can be seen in FIGURE 2, the group attribute marked "Acquisition" includes an object link attribute marked Paint that is included within the semantic object 22. Paired with the object link attribute is a corresponding object link attribute marked '' Customer that is found within semantic object 40. At the time the object link attribute pair was created, the link attribute of The object shown as Customer will initially be created to correspond to the semantic object defined for the multi-valued group marked Acquisition. However, the present invention does not allow an object link attribute to associate a semantic object with a group attribute. Therefore, the object binding attribute located on the paired semantic object must be updated to refer to the semantic object in which the multivalued group is contained. In the example shown in FIGURE 2, the object binding attribute marked Customer must be reinitialized with the object binding profile created for semantic object 22.

To complete this, the computer system begins a cycle that retrieves the list of Contents of the semantic object that defines the multivalued group in the

00007.0013

-41 step 446. In step 448, the computer system begins analyzing each entry in the Contents list. In step 450, the computing system reads the type of each attribute in the Contents list, namely, single value, group, or object link attribute. In a step 452, the computer system determines whether the attribute in the Contents list is a group. If so, the computer system obtains the list of Contents from the group attribute in step 454 and returns the process to step 448 where each attribute within the new list of Contents is analyzed. This recursive process continues until no additional included group attributes are found.

If the answer to step 452 was no, the computer system determines whether the attribute is an attribute of the object link type in step 456. If so, the computer system retrieves the object link attribute mentioned by the Pair of pointer. attribute in a step 458. In a pass 46C, the object binding attribute mentioned by the Pair pointer is reinitialized based on the object binding profile associated with the semantic object to which the group attribute was added. As explained above, in the example shown in FIGURE 2, the object link attribute marked Customer in semantic object 40 was initially originally created from an object link profile associated with a semantic object marked Purchase. Step 460 serves to reinitialize the object link attribute based on the object link profile created from the Customer 22 semantic object. After the object link attribute has been reset, the process continues to step 462 where it is determined if all the attributes in the Contents list have been analyzed.

00007.0013

If not, go back to step 448 and analyze the next entry. In a step 464, the semantic object and its corresponding object binding profile originally created for the multi-valued group table are removed from the semantic object model.

After the intersection tables and the multivalued group tables have been analyzed, the computer system updates the semantic object model to correct for single-valued, multivalued attributes that were previously identified as their own semantic objects. At a step 490 in FIGURE 10, the computer system parses each entry in the list of single-valued, multi-valued attributes. In a step 492, the container pointer of the single value attribute is adapted to be the address of the semantic object associated with the table referenced by the foreign key of the table. In a step 94, the computing system adds a pointer to the newly addressed single-valued attribute in the Contents list of the contained semantic object. The semantic object and its corresponding link object profile for the single-valued, multi-valued attribute table are removed from the semantic object model in step 496. In a step 498, the computer system determines whether all entries in the list multivalued attributes have been analyzed. If not, the process continues as above until all improperly classified semantic objects are removed and the corresponding multi-valued, single-valued attributes are inserted into the appropriate semantic object.

To explain the logic of FIGURE 10, reference was made to FIGURE 1 as the semantic object model

00007.0013 is initially created, the computer system will create a semantic object and a corresponding object link profile for table 9. However, because an artist can paint on many media, the simple value attribute, marked Medium, found in the semantic object that will be created for table 9 it must be placed appropriately in the semantic object that is created for table 7. Therefore, the logic operates to remove the semantic object and associated profile created for table 9 and places the simple value attribute marked Medium inside the semantic object 30.

As described above, the present invention operates to create a semantic object for each table in the database. Each column within a table

<td>It transforms in</td><td>a</td><td>profile of</td><td>attribute</td><td>of</td><td>value</td><td>simple</td>

<td>corresponding</td><td>So</td><td>like a</td><td>attribute</td><td>of</td><td>value</td><td>simple</td>

<td>correspondent.</td><td colspan="2">This will give</td><td>result</td><td>a</td><td>profile</td><td>created</td>

for each tribute within the semantic object model. However, many single-valued attributes can be created from the same profile. For example, many of the named attributes can be created from a generic attribute profile called identifier text that is predefined by the SALSA database modeling system. Therefore, the present invention allows the user to identify attributes that are derived from a common profile.

As shown in FIGURE 11, common profiles are parsed starting a loop at step 522 that parses each semantic object defined in the Album Contents list. In a step 524, the computing system a begins an inner loop that analyzes each

00007.0013 ticket attribute: 'simple within the Contents list of a given semantic object. In a step 526, the property values ​​(for example, values ​​of its member variables) of the corresponding profile are displayed on the property sheet. The property sheet is a window (not shown) that appears in the graphical user interface that shows the name of the property and its corresponding value. In a step 528, the computing system determines whether the properties in the profile differ from the properties of the attribute. If so, the user is signaled in step 530 to indicate whether the user wishes to select a new profile for the corresponding attribute. If the user wishes to select a new profile, the user is asked to indicate which profile is associated with the attribute in a step 534. A pointer to the attribute is added to the Derived Attributes list of the selected profile in a step 536. The base profile pointer of the attribute is updated to match the address of the newly selected profile in a step 538. Finally, a pointer to the Old profile is added to a list of profiles to delete in a step 540.

If the answer to step 530 is no, it means that the user does not want to select a new profile, the process proceeds to pass 550 and the computer system determines whether the profiles for all single-valued attributes in the semantic object under consideration have been analyzed under consideration. If not, the process returns to step 524. If the profiles for all single-valued attributes in a semantic object will do. analyzed, the computer system determines if all the semantic objects in the album have been analyzed. If not, the process returns to step 522 and the semantic object in the album is analyzed.

00007.0013

Once all the semantic objects in the album have been analyzed, the computer system then removes each profile in the profile list to be removed at step 554 and ends the process at step 556.

The preceding discussion describes how a semantic object model is created from a database schema when the DBMS catalog provides relationship information. however, some database programs do not store this relationship information. Therefore, in order to create a semantic object method for these types of databases, it is necessary to direct the user to indicate how various tables in the database are related. FIGURES 12A through 12D show the steps carried out by the present invention to create a corresponding semantic object model for databases that does not provide the relational information.

Starting at a step 600, the computer system first performs the steps outlined in FIGS. 4A-4D. As noted above, this will create a semantic object model that includes semantic objects for each table defined in the relational database catalog as well as single-valued attributes for each column defined by a table.

In a step 602, the computer system provides a dialog box on the graphical user interface that allows a user to indicate two semantic objects that are related. In a step 604, the computer system signals 1 user to indicate the maximum cardinality of both sides of the relationship. This relationship can be one-to-one, one-to-many, many uncle or one-to-one.

-4646 to-one, or many-to-many.

In a step 606, the computational system determines whether the user indicated that the relationship was of the many-many type. if so, the computer system then prompts the user to identify the semantic object associated with the corresponding intersection table in the database in step 608. in step 610, the computer system adds the database table related associated with the identified semantic object to the list of intersection tables. The process then proceeds to step 612, where the user can either leave or continue providing the relational information.

If the answer to the decision in step 606 is no, it means that the relationship was not a many-to-many type, the process continues to step 620 shown in FIGURE 12B. At step 620, the computer system determines whether the user-indicated relationship is one of the one-to-many or many-to-one type. If so, the user is required to identify the foreign key in the table associated with the semantic object on the many side of the relationship in step 624. In a 6/6 step, the computer system then determines if the foreign key is part of the primary key of this table. If so, the process proceeds to step 628 and the computer system determines if the table has more than one non-foreign key column. Tables that have more than one non-foreign key column are added to the list of multi-pool tables in step 630. Additionally, the number of cclumrms in the primary key of the multivalued group table are stored. If the answer to step 628 is no, the table is assumed to represent a single-valued, multivalued attribute, and is added to the list of

00007.0013

-4747 multi-valued single-value attribute, at step 632. The process then returns to step 612 of FIGURE 12A.

If the answer to step 626 is no, then the computer system determines that the semantic objects must be related by a one ~ to-many object link attribute. Therefore, the process continues to step 650 shown in FIGURE 120, whereby two instances of the Object Link Attribute class are created. In a step 652, pointers to the object binding attributes are added to the Derived Attributes list of the object binding profiles associated with the table that has the foreign key and with the tac-la to which the key refers. external. The object link attributes are initialized from the corresponding object link profiles in step 654.

In a step 656j, the Even pointers of the newly created object link attributes are positioned to point to each other. In step 658, a pointer to the object binding attribute is added to the Correct Semantic Object Contents list, in the manner described above.

Er. At a step 661, the Container pointer of each link attribute dr- c ... j oto is updated with the address of its contained semantic object. After updating the Container pointer, the Maximum Cardinality of the object binding attribute on the semantic object associated with the table without the foreign key is set to ”N.

In a step 664, the computer system then removes the single value attribute and profile that was created for the foreign key column:, s) which is now represented by the object binding attributes. The process then returns to step 612 shown in FIGURE

00007.0013

-4848

12Α.

If the answer to step 620 in FIGURE 12B was no, then the relationship is assumed to be represented by a one-to-one object link attribute. Therefore, the computer system user is asked to identify which column (s) in the tables associated with the related semantic objects is the foreign key in step 622.

<td>The process then proceeds to</td><td>the</td><td colspan="3">steps shown in</td><td>the</td>

<td>FIGURE 12 D.</td><td></td><td></td><td></td><td></td><td></td>

<td colspan="2">Starting in one step</td><td> 670,</td><td>the</td><td>system</td><td>of</td>

<td>computation creates two instances</td><td>s of</td><td>the</td><td>class</td><td>Attribute</td><td>of</td>

<td>Object Link. In one step</td><td> 672,</td><td>the</td><td>point</td><td>rivers for</td><td>the</td>

<td>object binding attributes</td><td>I know</td><td colspan="2">add to</td><td>the list</td><td>of</td>

Attributes associated with the relational table which object binding profile has the foreign key and associated with the table that the foreign key refers to.

In an object link step they are initialized from their corresponding profiles.

Object links are then placed to point to each other in step 6/8.

In a step 680, the computer system updates the Contents list of the semantic object with a pointer to the attribute of en '. ; object me correct in the manner described above. The Container pointers of the object link attributes are then updated with the address of the contained semantic object, in a step 682.

In a step 684, the maximum cardinality of both object link attributes is set equal to one. After the maximum cardinalities have been initialized, the computer system then removes the attribute and the

00007.0013

-4949 simple valued profile that were created for the foreign key column (s), and the process returns to step 612 shown in FIGURE 12A.

As can be seen, the present invention operates to create a semantic object model from an existing, relational database schema. The semantic object model allows the user to easily manipulate or modify an existing relational database without requiring the user to understand the outlined database management system, or the language that the database requires.

While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein, without departing from the spirit and scope of the invention. It is, therefore, intended that the scope of the invention be determined solely from the claims.

00007.0013