WO1997007470A1 - Method and apparatus for storing and retrieving data in a relational database using an object model - Google Patents

Method and apparatus for storing and retrieving data in a relational database using an object model Download PDF

Info

Publication number: WO1997007470A1
Authority: WO; WIPO (PCT)
Prior art keywords: relational database; group; component; data; model
Prior art date: 1995-08-17

Application number

PCT/US1996/013284

Other languages

English (en)

French (fr)

Inventor

Christopher C. Olds

David M. Kroenke

Matthew C. Gordon

Cathryn A. Stanford

Kenji Kawai

Jing Li

Michael D. Miller

Zhiya Cai

Original Assignee

Wall Data Incorporated

Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)

1995-08-17

Filing date

1996-08-15

Publication date

1997-02-27

1996-08-15 Application filed by Wall Data Incorporated filed Critical Wall Data Incorporated

1996-08-15 Priority to EP96928204A priority Critical patent/EP0846299A1/en

1996-08-15 Priority to AU67764/96A priority patent/AU6776496A/en

1997-02-27 Publication of WO1997007470A1 publication Critical patent/WO1997007470A1/en

Links

Classifications

- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/289—Object oriented databases

Definitions

the invention is directed toward database management systems and, more specifically, to a method and apparatus for storing and retrieving data in a relational database using an object model.
a database application consists of forms, reports, queries, menus, and application programs.
Forms, reports and queries are the means though which a user can store and retrieve data in a database.
a form allows a user to input data into the database; queries are commands that cause a computer to search for data in the database meeting some search criteria; and a report is a listing of data that has been retrieved from the database by a query.
Application programs traditionally have included routines that were custom written by database experts based on the requirements of an end user of the database.
Application programs are typically either written in a language that is a part of the DBMS or in a standardized command language and syntax, such as structured query language (SQL).
SQL structured query language
desktop database programs that operate on personal computers have become available in recent years. Examples of such desktop database programs include AccessTM from Microsoft, Inc., and ParadoxTM from Borland, Inc. These programs allow a developer to define the types of information to be stored in a database, and have tools to assist in the creation of forms for users to enter data into the database and print reports that contain previously stored information. Some desktop database programs have the capability of allowing a user to customize the content and look of the forms and reports.
relational database data are logically stored in a row of a two-dimensional table having multiple columns to define the particular data that are stored.
a database schema also referred to as a database schema
traditional DBMSs force the user to define the data to be stored in a database in a way that is determined by the database program. For example, to create a new database, most DBMSs present the user with a blank table and ask the user to identify the type of data to be placed in each column. If more than one table is required for defining the database schema, the user must also create additional tables appropriate for the data. In addition, the user must also define key fields or attributes that are common to two or more tables in order to relate the tables to one another.
a significant disadvantage of traditional methods of creating database applications is that the user most likely does not think of the data to be stored in terms of tables, columns, and keys.
the user who wishes to create a database for investment portfolio data most likely thinks of the data in terms of the names of companies in which stock is held, the number of shares of each company owned, a purchase price, a purchase date, a price-to-earnings ratio, etc.
most prior art DBMSs force the user to think of and characterize the data to be stored in a way that is unnatural.
the relational database concepts carry over into the forms and reports that are generated, making these less intuitive to users as well.
SALSATM database application generating program
SALSATM database application generating program
Portions of the program were described in U.S. Patent Application Serial No. 08/145,997 (the '997 application), entitled "Object Modeling System for Creating Relational Database Schemas,” which is hereby incorporated by reference.
the SALSA program allows users to create a model of data to be stored in a database using one or more semantic objects.
Each semantic object represents a complete item, such as a person, an order, a company, or anything else that a user thinks of in terms of being a unique entity that will be stored in the database.
Each semantic object has one or more attributes or "components" that define identifying information about the object, as well as object links that define relationships between the objects in the database model.
the SALSA computer program analyzes the object model and creates a corresponding relational database schema which can be used to store data in the computer.
a relational database schema which can be used to store data in the computer.
Version 1.0 of the SALSA program allows a user to easily create a database schema without knowledge of traditional relational database concepts, it does not provide a means for automatically creating forms and reports that can be used to store and retrieve information from a database.
An improved database system that automatically generates forms and reports for accessing data in a database using object modeling concepts would be extremely advantageous.
the invention is directed to a method of generating forms and reports in order to store and retrieve data from a relational database using an object model.
a method of creating forms based on a semantic object in a semantic object model comprises: (a) creating, in response to user input, an object model, the object model including a plurality of semantic objects, each semantic object having one or more components that define the semantic object, and wherein two or more of the semantic objects are further defined by relationships therebetween; (b) automatically generating, in accordance with a set of default rules, one or more object view hierarchies for each semantic object in the object model, the object view hierarchies containing information about an associated semantic object, including the component or components defining the corresponding semantic object and relationships with other semantic objects in the model, if present; (c) generating a form from each object view hierarchy; (d) displaying, in response to user input, a current form that is of interest to the user; and (e) determining if modifications have been made by the user to either the current form or the underlying object view hierarchy upon which it is based, and if modifications have been made, changing the contents of the underlying
a semantic object in the object model may contains one or more action components, each action component resulting in a command button being created on a form generated from an object view hierarchy associated with the semantic object.
An action component enables one the following functions to be invoked by a user of a form: reading a record stored in the relational database; inserting a record into the relational database; deleting a record from the relational database; updating a record stored in the relational database; and showing a form for a semantic object that is related to the semantic object that contains the action component.
a semantic object in the object model may also contain an action group component, consisting of two or more action components, that results in a menu bar being created on a form generated from an object view hierarchy associated with the semantic object. The action group component contained by a semantic object may be used to limit access to data in the relational database by a user of a form associated with the semantic object by providing only selected functions on the menu bar created on the form.
a method of storing data in a relational database using an object model is described.
the object model is first translated into a database schema including one or more relational database tables that describe the relational database using techniques disclosed in the '997 application.
the method includes: (a) selecting an object from the object model; (b) automatically generating, according to a set of default rules, a form based on the selected object for storing data in the relational database; (c) combining the form with information about the database schema and information about the selected object, including information regarding any relationships that exist between the selected object and other objects in the object model; (d) prompting a user to enter data to be stored in the relational database into the form; and (f) writing the data that has been entered into the form to the relational database. Steps (a)-(c) may be repeated for each object in the object model.
the objects in the object model are semantic objects.
a computer-readable memory that can be used to direct a computer to function in the manner specified above when used by a computer is described.
the step of writing the data that has been entered into the form to the relational database includes: (a) determining if data entered into the form comprises a valid record in accordance with the object model; and (b) if the data that has been entered is not a valid record, displaying an error message without writing the data that has been entered into the form to the relational database.
each form is comprised of a collection of fields, each field being associated with either a component in the selected object or a component from an object that has a relationship with the selected object.
the fields comprising the form are determined by the set of default rules. A user may change the fields contained in the form from those included by the default rules.
the method includes enabling a user to modify the contents of the form from what is dictated by the default rules.
the step of automatically generating a form for storing data in the relational database includes: (a) automatically generating, according to a set of default rules, an object view hierarchy based on the semantic object, the object view hierarchy including information about the components defining the selected object as well as information regarding the relationships, if any, that exist between the selected object and other objects in the object model; and (b) using the object view hierarchy to generate the form.
a user may modify the contents of the form, if desired.
the step of enabling a user to modify the contents of the form includes: (a) displaying the form; (b) monitoring user inputs relating to the form to determine if the user has made any modifications to the contents of the form, and if modifications have been made, changing the contents of the object view hierarchy associated with the form to reflect the modifications; and (c) automatically generating a new form from the object view hierarchy.
a user may perform queries on data stored in the database using the form.
each form includes a plurality of fields, wherein each field is associated with a component in the object model. If a user wishes to can perform queries on data stored in the database using the form, the method includes (a) prompting the user to enter query information into one or more fields of the form; and (b) retrieving data records, if any, that match the query information and displaying those data records.
the step of writing the data that has been entered into the form to the relational database includes generating SQL statements appropriate for the database from the information about the database schema and information about the selected object.
the step of combining the form with information about the database schema and information about the selected object includes creating a run-time view hierarchy for the form.
each component represents an instance of data stored in the relational database that is represented by the object with which the component is associated, the components including simple value components that represent data entry in a single column of the relational database, group components having one or more member components that represent a logical collection of components, and object link components that represent relationships between the objects in the object model.
One or more components are classified as identifier components that are used to choose between instances represented by the same object, and each component has a minimum and maximum cardinality that define the minimum and maximum instances, respectively, allowed for the component.
the set of default rules includes adding to the form a control for each simple value component and each group component that defines the selected object, and a control for each identifier component in an object related to the selected object by a nonrecursive object link component.
an object in the object model contains one or more action components, each action component resulting in a command button being created on a form generated for the object.
An action component may be added to enable one the following functions to be invoked by a user of the form: reading a record stored in the relational database; inserting a record into the relational database; deleting a record from the relational database; updating a record stored in the relational database; and showing a form for a semantic object that is related to the semantic object that contains the action component.
An object in the object model may also contain an action group component, consisting of two or more action components, that results in a menu bar being created on a form generated for the object. The action group component contained by an object may used to limit access to data in the relational database by a user of a form associated with the object by providing only selected functions on the menu bar created on the form.
a method of storing and retrieving data to and from a relational database using an object model includes: (a) creating, in response to user input, an object model comprising one or more objects, each of which represents an item about which data is stored in one or more tables of a relational database; (b) creating, in response to user input, one or more components associated with one or more objects in the object model and representing data stored in the relational database for the item represented by the object with which the component is associated, the components including object link components that represent relationships between objects in the object model; (c) translating the object model into a database schema including one or more relational database tables that describe the relational database; (d) automatically generating, in accordance with a set of default rules, an object view hierarchy for each object in the object model, each object view hierarchy containing information about its associated object, including the component or components defining the object and the object links, if any, between the associated object and other objects in the model; (e) automatically generating, in accordance with a set of default
the method further includes: (a) prompting a user to enter data to be stored in the relational database into a form; and (b) writing the data that has been entered into the form to the relational database.
the method further includes: (a) displaying, in response to user input, a current form that is of interest to the user; (b) prompting the user to enter modifications to the contents of the form; and (c) if modifications have been made to the current form by the user, changing the contents of the object and run time view hierarchies associated with the form to reflect the modifications, and generating a modified form from the run-time view hierarchy.
a method of retrieving data records stored in a relational database using an object model comprises: (a) automatically generating, according to a set of default rules, a form based on an object in the object model, the form including a plurality of fields, wherein each field is associated with a component in the object model; (b) prompting a user to enter query information into one or more fields of the form; and (c) retrieving data records, if any, that match the query information and displaying those data records.
the step of retrieving data records may be accomplished by combining information about the database schema with information about the selected object, including information regarding any relationships that exist between the semantic object and other objects in the object model and using this information to perform the query on the relational database.
the step of automatically generating, according to a set of default rules, a form based on an object in the object model may be repeated for each object in the object model.
a method of storing data in a relational database using an object model comprises: (a) selecting an object from the object model; (b) automatically generating, according to a set of default rules, an object view hierarchy based on the selected semantic object, the object view hierarchy including information about the components defining the selected semantic object as well as information regarding the relationships, if any, that exist between the selected semantic object and other semantic objects in the object model; (c) automatically generating a form for storing data in the relational database from the object view hierarchy; (d) prompting a user to enter information into the form; and (e) storing data that has been entered into the form into the relational database by combining information about the database schema with information contained in the object view hierarchy.
FIGURE 1 A is a block diagram of a database design tool in accordance with the invention, including both design time and run-time aspects of the invention;
FIGURE 1B is a block diagram of a custom application that is created by the database design tool at run time in accordance with the invention
FIGURE 1C is a block diagram of a computer on which the database design tool may run in accordance with the invention.
FIGURE 2A is a computer display screen shot of a graphical user interface illustrating a sample object model in accordance with the invention
FIGURE 2B is the computer display screen shot shown in FIGURE 2A, but including an exemplary component properties window that may be used to alter one or more property values of a semantic object, template, or model component;
FIGURE 3 A is an example of a default form generated by the design tool for the semantic object "customer" from the object model in FIGURE 2A in accordance with the invention
FIGURE 3B is an example of a default form generated by the design tool for the semantic object "order” from the object model shown in FIGURE 2A in accordance with the invention
FIGURE 4A is an example of a default report generated by the design tool for the semantic object "customer” in accordance with the invention
FIGURE 4B is an example of a default report generated by the design tool for the semantic object "order" in accordance with the invention.
FIGURES 5A-5B illustrate the object model of
FIGURE 2A but where exemplary action item and action group components have been added to the customer semantic object in accordance with the invention
FIGURES 5C-5D illustrate the creation of a windows button and a menu bar on the form of FIGURE 3A in accordance with the invention, resulting from the action item and action group components that were added to the customer semantic object;
FIGURE 6A is a flow chart of an exemplary routine for implementing the design tool in accordance with the invention.
FIGURE 6B is a flow chart of an exemplary routine for constructing forms and reports in accordance with the invention.
FIGURE 7 illustrates the class hierarchy for a generic view object in accordance with the invention
FIGURE 8 represents a computer display screen shot of portions of a graphical user interface that includes an exemplary object model for use in describing the invention
FIGURE 9A illustrates the semantic object hierarchy for the semantic object "order" displayed in FIGURE 8.
FIGURE 9B and 9C illustrate object view hierarchies for the semantic object
FIGURE 10 is an example of a default form generated by the design tool for the semantic object "customer" in accordance with the invention.
FIGURE 11 is an example of a default form generated by the design tool for the semantic object "order" in accordance with the invention.
FIGURE 12 is an example of a default form generated by the design tool for the semantic object "shipping company" in accordance with the invention.
FIGURE 13 illustrates an Add Component dialog box that provides an exemplary user interface for form and report customization
FIGURE 14 illustrates the form for the semantic object "order” in FIGURE 9, but with exemplary modifications to the form
FIGURE 15 illustrates the object view hierarchy that is associated with the form of FIGURE 14;
FIGURE 16 is a flow diagram illustrating the steps performed in creating an action item template
FIGURE 17 is a flow diagram illustrating the steps performed in creating an action item component
FIGURE 18 is a flow diagram illustrating the steps performed to create an action group template
FIGURE 19 is a flow diagram illustrating the steps performed to create an action group component
FIGURE 20 is an exemplary routine for inserting an action item or action group component into a semantic object
FIGURES 21A-21B illustrate an exemplary routine for inserting an action item component into a group component
FIGURE 22 is an exemplary routine for inserting an action item template or action group template into an action group template
FIGURE 23 illustrates an exemplary user interface for storing and retrieving data to and from a relational database using the custom application.
the invention is directed to a tool for creating and generating forms, reports, and queries in order to store and retrieve data from a relational database using an object model.
a user creates a graphic visual representation of the data to be stored in the database and the relationships that exist between various parts of the data.
the visual representation, or "object model,” is then transformed by the invention into a series of computer commands or function calls that cause a database program to create a corresponding relational database schema.
the forms and reports interact with the relational database schema to facilitate the storage and retrieval of data in the database.
a database design tool 50 creates a custom application 51 for storing and retrieving data to and from a database 52 in accordance with the invention.
the database design tool operates in two discrete segments of time. The first is design time, which includes the following steps:
An object model 54 including semantic objects and defining relationships between two or more of the semantic objects is created by the user, using a template if desired;
the design tool generates a relational database schema 55 from the object model
the design tool generates object view hierarchies 56 for each semantic object in the object model that will be used create forms and reports 57 for the semantic objects;
the user may customize the forms and reports 57 during design time to include more or less information or change their appearance, and may create forms and reports that have limited capabilities, e.g., read only, for security purposes, such as ensuring that a record is not changed by an unauthorized user;
the design tool creates "canonical" run-time views 58 that will be used to access the database 52 by combining information from the object model 54 and the relational database schema 55;
the design tool creates "form" run-time views 59 that will be used by the forms and reports to access the database 52 by combining information from the object view hierarchies 56 and the relational database schema 55;
the second segment of time is run time, where the custom application 51 is used to access the database using run-time forms and reports 61.
the run-time forms and reports 61 are adaptations of their design time counterparts, i.e., the relational database schema 55 information has been added via the form run-time views 59 to enable the forms and reports to communicate with the database 52 through run-time view operations 60.
the run-time view operations 60 typically will generate a set of SQL statements to carry out a command. Exemplary commands executed by the run-time view operations include insert, update, query, and delete commands, and are described in detail below.
the custom application is comprised of run-time forms and reports and run-time view operations only.
the design tool 50 runs on a computer 62 that has a processing unit 63 that is controlled by an operating system 64.
the computer includes a memory 65, a keyboard 66, and a pointing device 67, e.g., a mouse, that are coupled to the processing unit for data input and computer control.
a monitor 68 and printer 69 are also connected to the computer 62.
the design tool 50 includes a built-in DBMS that is incorporated into the design tool 50, or in the alternative interacts with a commercially available DBMS, e.g., desktop database program (not shown), to communicate with the database 52.
the memory 65 generally comprises, for example, random access memory (RAM), read only memory (ROM), as well as magnetic or optical storage media such as a hard drive, floppy disk, or magnetic tape.
the computer 62 is typically a personal computer which may be, for example, a MacintoshTM, International Business Machines (IBMTM), or IBM-compatible personal computer.
the operating system 64 may be DOS based or may incorporate a windowing environment such as Microsoft WindowsTM or OS/2TM.
the design tool may, however, run on other types of computers, such as a mainframe or mini-computer, and other operating systems.
FIGURES 2A and 2B illustrate a graphical user interface display screen shot exemplary of that produced by the design tool 50 that allows a user to create and manipulate data that will be stored in the database.
a sample object model 70 is shown in FIGURE 2A.
the object model 70 represents an extremely simple database that could be used by a company to track orders of a single product. To construct such a database, a user interacts with the graphical user interface to create the appropriate semantic objects.
a semantic object simply represents a conceptual unit of data that the user desires to store in the database.
the objects are called "semantic" objects because their definition and structure have meaning for the user developing the database.
the object model 70 includes two semantic objects.
a first semantic object 72 represents a customer that has ordered a product from the company.
the semantic object customer has a number of components, including: company name, address, phone number, and fax number.
the address, phone, and fax components are group components.
Group components are designated with a triangle 73 to the right of the component name and can be expanded on the computer screen to show all the member components within the group.
the triangle by the address component has been expanded to show its member components, which include: street, city, state, and zip code.
the phone and fax components each include an area code and a phone number.
the customer semantic object 72 also includes a link to a second semantic object 74, which holds order information on an order-by-order basis.
the order semantic object 74 also includes a number of components. These are: order number, order date, a subtotal indicating the price of the product being ordered, the tax on that order, and a total price for the order.
the order semantic object 74 includes a link back to the customer semantic object 72.
FIGURES 3A and 3B illustrate default forms that have been created for the customer and order semantic objects 72 and 74, respectively.
a form allows data to be input into a database as well as to perform queries on data already existing in the database.
a default customer form 80 includes a number of edit boxes for entering information regarding a particular customer. More particularly, an edit box 81 may be used to enter a particular company name, e.g., Wall Data.
a series of edit boxes 82 may be used to enter the company's address, including street, city, state, and zip code; and the company's phone and fax numbers may be entered in the edit boxes 83 and 84. After all the information has been correctly entered, the user of the custom application may enter an appropriate command to store the record in the database.
a user may enter query information into one or more fields in the form and then invoke an appropriate command.
the records of the database will then be searched, and the results displayed on the screen.
a data entry grid 86 displays order information related to a customer.
the data entry grid 86 includes a search button 88 that allows a user to search for orders that are unrelated to any customer, but which the user may want to associate with the customer identified in edit box 81.
each link that is associated with a semantic object for which a form is created will have a data entry grid and a search button. The function of the search button will depend upon how the object model is set up and the particular link associated with the search button.
the data entry grid 86 by default only includes access to the order number for a particular company's current orders. If desired, a user may customize the customer form 80 to allow additional order information to be presented, such as the date or dollar amount of each order.
Forms generated by the design tool 50 will by default have an application's menu bar 89 that includes the following menu items: file, edit, record, view, forms, reports, window, and help.
the application's menu stems from a semantic object that is automatically included in each object model.
the "edit” menu item includes the ability to cut, copy, paste, and delete text, as well as resetting a field within the form.
the "record” menu item allows a user to save a record, set search criteria, find a record, go to the first, previous, next, and last records, delete a record, and reset a form.
a user can toggle between displaying and hiding the status bar and toolbar of a form.
each form also includes a toolbar 91 that includes popular commands that are identified by icons in the toolbar. They include, from left to right, cut, copy, paste, save, query, clear form, open a related form, open first record, open the previous record, open the next record, open the last record, and display help contents.
FIGURE 3B illustrates a default order form 90.
the order form 90 includes edit boxes 92 and 94 that allow an order number and order date to be input into the database. Edit boxes 96, 98, and 100 provide areas for entering a subtotal, tax, and total, respectively, associated with a current order. It should be noted that the object model, and hence form, will often be set up so that data in some of the fields are automatically generated in response to data entered in other fields. For example, once a subtotal is entered, the tax and total may be automatically computed.
a platform 102 includes an edit box 104 and a search button 106.
search button 106 a user can query the database for customers matching a name entered in the edit box 104. For example, if a "W" has been entered in the edit box, all customers starting with that letter will be displayed.
the edit box 104 may also be used to create a customer to be associated with an order. The use of queries is discussed in greater detail below.
the order form 90 may be customized to provide more or less information regarding either orders or customers, as desired. See FIGURES 13-15 and accompanying text.
FIGURES 4A and 4B illustrate default reports that have been created for the customer and order semantic objects 72 and 74, respectively.
the customer report in FIGURE 4A includes two exemplary records.
a first record 110 refers to a customer whose company name is Starbucks Coffee and a second record 112 refers to a customer whose company name is Wall Data.
Each record 110 and 112 includes the address, phone number, and fax number for the customer.
the customer record includes the order numbers that have been placed by that customer.
an order number column 214 indicates that order numbers 3 and 4 have been placed by Starbuck's Coffee.
an order/order number column 116 in the record 112 shows that order numbers 1 and 2 are associated with the customer Wall Data.
a default report for the semantic object order includes four exemplary orders listed sequentially that are contained in the database. Specifically, column 118 lists the order number; column 120 the date of each order; column 122 lists the customer (company name) associated with each order; and columns 124, 126, and 128 list the subtotal, tax, and total for each order.
Action items (actions) and action group components may be placed into a semantic object to determine a user's access to a form that is created for a semantic object.
exemplary action item components include: arrange icons, copy, cut, paste, delete field, delete record, find, open form, print report, and run script.
Action group components contain other actions that a user can perform or choose from within a semantic object. For example, the separate actions new, open, close, and exit make up the file action group component. Similarly, the actions undo/redo, copy, cut, and paste together form the edit action group component.
Other exemplary action group components include: forms, help, record, reports, view, and window.
Action items directly contained within a semantic object become command buttons on a form associated with the semantic object; action group components are represented by items on a menu bar. Actions within an action group are displayed as menu items within popup menus on the menu bar resulting from that action group. An action group inside of an action group shows up as a cascading menu. When an action group is added to a semantic object, the default applications menu bar is replaced by the menu bar that is created from action group component(s) in the semantic object. Thus, action groups may be used to limit access to commands in a form. An example will clarify this description.
FIGURES 5A-5B illustrate the object model 70 of FIGURE 2A, but where three exemplary action groups file 131 , record 132 , and help 133 have been added to the customer semantic object 72 .
An action item "related form" 134 has also been added .
the actions that make up the action group components file 131 and help 133 are displayed.
the individual actions for the action group file 131 include: close window 135a, menu separator 135b, print setup 135c and exit 135d.
the individual actions for the action group help 133 include: help contents 136a, search for help 136b, help on help 136c, and about 136d.
FIGURE 5B illustrates the actions that comprise the action group record 132.
These actions include: save 137a, save as new 137b, query mode 137c, find 137d, first 137e, previous 137f, next 137g, last 137h, reset form 137i, clear form 137j, and delete record 137k.
FIGURE 5C illustrates a default form 139 that has been created for the (revised) semantic object customer 72.
the applications menu bar 89 in FIGURE 3 A has been replaced with a custom menu bar 140.
the custom menu bar includes three menu items 141, 142, and 143 that correspond to the action groups components 131, 132, and 133, respectively. Selecting a menu item will display menu picks for each of the actions in the action group associated with the selected menu item. For example, in FIGURE 5D the record menu item 142 has been selected, displaying the actions that were set forth in FIGURE 5B, along with keyboard commands that will invoke those actions.
a windows button 146 entitled "Show Related Form” that was created as a result of the action item 134. Depressing the windows button 134 will display the form of a semantic object that is related to the customer form, e.g., if orders was highlighted, the orders form would appear.
FIGURES 16-22 and the accompanying text Semantic Object Modeling Definitions
semantic object modeling forms, and reports
semantic object modeling definitions that refer to terms that are otherwise defined in the list are presented in italics.
Each component in an object model has a template from which it is created. However, a component is associated with a particular semantic object, and its properties can be overridden from those defined in the corresponding template. Templates are used to allow a user to easily change all the components in the semantic object data model by changing the template from which the components are derived, as many components of the same type might be placed in different semantic objects.
the invention includes a catalog 150 that includes a template manager window 152 from which a user may select a predefined template; alternatively, the user can create his/her own templates which are then stored in the template manager.
the template manager is used when defining components for a semantic object, and includes a listing of the semantic objects in an object model, as well as data items, data groups, action items, and action groups that may be added to the semantic objects in the object model. These are listed in a "show only" window 154.
a user can drag and drop a predefined or newly created template into a semantic object in order to create a corresponding component within that semantic object.
semantic objects are indicated by an icon 156 (page)
data items are indicated by an icon 158 (box)
data groups by an icon 160 (group of boxes)
action items by an icon 162 (lightning bolt)
action groups by an icon 164 (multiple lightning bolts).
Object link components are shown outlined, as shown by reference numeral 166 in the semantic objects 72 and 74.
each component within a semantic object indicates whether a user has defined the component to refer to a particular instance of the semantic object.
Components that refer to a particular instance of the semantic object are called identifiers.
Identifier components may be unique or nonunique.
a unique identifier defines a unique instance of the semantic object. For example, in FIGURE 2A the component company name in the customer semantic object 72 has a pair of asterisks 168 which indicate that the customer's company name uniquely identifies a particular company. If the indication is shown as a single asterisk only, the component refers to a particular instance of the semantic object but the component may not be unique. Finally, the lack of any asterisks to the left of a component indicates the component is not used to specify a particular instance of a semantic object.
each component In the lower right-hand corner of each component is an indication of the component's cardinality. This is shown as a subscript consisting of a pair of integers having the form "n-m.”
the "n” refers to the minimum cardinality of a component. This is the minimum number of instances of the component that the semantic object must have to be valid.
the customer semantic object 72 has a group component "address” having a cardinality 0-1.
the first numeral "0" indicates that a company need not have an address.
the second numeral refers to the maximum cardinality, i.e., the maximum number of instances of the component that a semantic object can have.
the maximum cardinality of the group component address is "1," thereby dictating that a company may at most have a single address. If this value were "N,” multiple addresses would be allowed.
a user may create semantic objects by selecting a "create semantic object” option from a tools menu in the graphical user interface and entering "customer" and "order.” Once the semantic objects have been created, a user then enters components into those semantic objects by choosing a template of the desired component and dragging the template into the boundary of the semantic object. For example, to create the company name component, the user selects the company name template from the template manager 150 and drops it into the customer semantic object 72.
a property sheet 170 may be used to change any of the properties of a component, including the component's name, data type, minimum and maximum cardinalities, etc.
the particular property sheet shown in FIGURE 2B is for the "company name" component.
a user can create relationships between the semantic objects by selecting a semantic object and then dragging the object into the bounds of another semantic object. For example, to create the relationship between the customer and order semantic objects, a user can select the customer semantic object and place it within the physical boundaries of the order semantic object. This action causes the design tool to create an object link component called "order” and place it in the customer semantic object, as well as to create an object link component called "customer” and place it in the corresponding order semantic object.
FIGURE 6A is a flow diagram that illustrates exemplary steps taken by the design tool 50 to create the custom application 51 in accordance with the invention.
a user is prompted to enter an object model that reflects the data for which a custom application is to be generated. This is accomplished by having the user create semantic objects, and defining that object's model components and links to other semantic objects.
the design tool 50 provides templates that give users a "start" for creating their object model. For example, templates may be available for keeping track of an inventory for a small business, creating a roster for an intramural team, keeping track of the attorneys and associates in a law firm, etc.
the current object model is then displayed at block 202.
a test is made to determine whether any modifications to the current model have been made. If modifications have been made, the object model is changed accordingly at block 206, and the program loops to block 202 where the current object model is again displayed. If the user is satisfied with the object model, i.e., additional modifications are not desired, a test is made at block 208 to see if the user wishes to preview any forms or reports that will be generated for each semantic object in the object model at run-time. If the user wishes to preview a form or report, a view routine is called at block 210. An appropriate routine for performing this task is set forth in FIGURE 6B. Otherwise, a test is made at block 212 to determine whether a database application is to be created from the current object model.
the program loops to block 202.
the program proceeds to block 214, where the database schema is generated from the object model.
the custom application 51 is generated based on the object model.
the custom application 51 is run. The custom application 51 is now in run time, and the user is free to store and retrieve information from the database.
an exemplary routine for generating default forms and reports in accordance with the invention is illustrated.
a root view object for which a default form or report is to be generated is selected.
an object view hierarchy for the selected root view object is created. Once the object view hierarchy is created, a default form and report is constructed for the root view object using the object view, as indicated at block 234. Exemplary rules for creating default forms from the object view hierarchy are set forth in Tables 1-3 below.
An exemplary routine that ties all of the form generation rules together is illustrated in the Appendix as LISTING L2.
An exemplary routine for building default reports is illustrated as LISTING L6.
An object view hierarchy is a data structure that is used when generating forms and reports.
the structure of an object view hierarchy is related to the structure of semantic objects, but is separate therefrom because a form or report typically contains information about more than one semantic object.
an object view hierarchy is a hierarchy of "view objects," where each view object is founded from either a semantic object or a model component in the object model.
An object view hierarchy stems from a root view object, defined as a view object for which a form or report is to be generated.
a root view object always stems from a semantic object in the object model (as opposed to a model component).
view objects are containers that hold information necessary for form and report generation.
a view object corresponding to a link will include information about the semantic object coupled to the link.
the type of information held in any particular view object is determined by the object type, e.g., simple value. What is contained in an object view hierarchy is dictated by default rules that are set forth and discussed below.
FIGURE 7 illustrates the class hierarchy for a generic view object 240. From the view object 240 stems a root view object 242 and one or more view components 244. There are eight different categories of view components in an object view hierarchy. The categories are based on categories of model components available in the object model. The '997 application described seven of these: simple value, formula, data group, and object link, which are has-a type components; and parent link, subtype link, and subtype group, which are is-a type components.
Formula attributes (components), which were described in the '997 application, have been combined with simple value components in the current implementation of the design tool. Specifically, simple value components have a source property that may be set to "script" and a formula entered into the formula property.
the two categories not described in the '997 application are action item and action group components. These allow menus and buttons to be added to forms and are described in detail below. From the following stem the view component categories: simple value 246, data group 248, object link 250, parent link 252, subtype link 254, subtype group 256, action 258, and action group 260. The object view hierarchy generation rules will take these categories into account.
FIGURE 8 illustrates an object model 262 that will be used throughout the remainder of this discussion.
the object model 262 is a more complicated version of the object model 70 in FIGURE 2A.
the object model includes the following semantic objects: customer 264, order 266, item 268, shipping company 270, and supplier 272. For the examples provided after each rule, it is assumed that a view object based on the semantic object order 266 in FIGURE 8 is the root view object.
Root view objects can only include view components based on model components directly contained by (topmost level) the semantic object upon which the root view object is based.
the root view object order can contain: order number, order date, customer, line item, subtotal, tax, and total.
Simple Value View Components View components based on simple value model components cannot contain any other view components. Order date, subtotal, tax, total, unit cost, quantity, and extended price are examples of simple value view components that cannot contain any other view components. For a listing of the data held by simple value view components, see the simple value view component class described in TABLE T19, which can be found in the Appendix.
Group view components can only contain view components based on model components that are directly contained by the group view component's base model component.
group view component line item it can only contain item, unit cost, quantity, and extended price.
group view component line item it can only contain item, unit cost, quantity, and extended price.
Object Link View Components Object link view components based on model components that are directly contained in the referenced semantic object of the model component upon which the object link view component is based can be included.
object link view component "customer"; it can contain company name, address, phone, fax, and customer contacts.
view objects based on model components of semantic objects that are referenced by a recursive link are not included.
FIGURE 9A illustrates a semantic object hierarchy 280 for order 266.
the semantic object order directly contains seven model components: an identifier component order number 282; a simple value component order date 284; a link component customer 286; a group component line item 288; and simple value components subtotal 280, tax 292, and total 294.
the group component line item 288 directly contains a link component item 295; and simple value components unit cost 296, quantity 297, and extended price 298. That is the extent of the semantic object hierarchy for order 266.
FIGURE 9B illustrates an object view hierarchy 302 for the semantic object order 266, and includes a partial listing of all of the view objects based on model components that can be included in accordance with the rules set forth above.
a root view object order 304 is based on the semantic object order 266.
the top-level view objects include: order number 306, order date 308, customer 310, line item 312, subtotal 314, tax 316 and total 318.
the second level components include the following ⁇ under customer: company name 320, address 322, phone 324, fax 326, customer contacts 328, and order 330; and under line item: item 332, unit cost 334, quantity 336, and extended price 338.
the third-level components include: (a) components associated with the groups directly contained by customer 310, i.e., the components that are directly contained by the group components address 322, phone 324, fax 326, and customer contacts 328, which are not shown for brevity, and (b) the components directly contained by item 332, which is a link view object.
the components directly contained by item 332 include: product name 340, product type 342, product number 344, standard cost 346, location/bin 348, sales price 350, comments 352, order 354, supplier 356, and shipments 358.
the fourth-level components are shown. These include: company name 360 and supplier contacts 362 under supplier 356; and date shipped 364 and date received 366 under shipment 358. It should be appreciated from the foregoing, however, that the object view hierarchy may include any component that is referenced by a semantic object, whether it be directly contained in the semantic object, in a group, in a link, or through multiple (nonrecursive) links.
the design tool has default rules which govern what will initially be in an object view hierarchy. That is, the rules attempt to anticipate what information will be important to a user that requires a form or report concerning a semantic object. As is discussed in greater detail below, the design tool enables a user to change what is included in a form or report, which in turn will modify the object view hierarchy from its default structure.
the default rules presented directly below, distinguish between link and nonlink components, and also take into account whether or not a link is recursive.
NonRecursive Links For nonrecursive links, review the top- level model components of the semantic object referenced by the link and include any model components carrying a "unique" or "non-unique" identifier. If none of the top-level model components have such a designation, include the first top-level model component encountered. All other model components are not included.
each of the single-value groups under a nonrecursive link are evaluated and those which have a "unique” or “nonunique” component are also included in the group. This rule is applied recursively.
FIGURE 9C illustrates the object view hierarchy 302 of FIGURE 9B, but truncated to include only that information that is provided under the default rules (l)-(3).
the top level components order number 306, order date 308, line item 312, subtotal 314, tax 316, and total 318 remain because they are nonlink components, as dictated by rule (l).
Customer 310 remains because it is a nonrecursive link.
company name 320 is the only model component stemming from the link to a customer that is included in the default; it is a top-level model component of the semantic object referenced by the link (customer) and carries a "unique" identifier, as dictated by rule (2). No other model components are considered in accordance with the rule, and thus that branch is finished.
the only other branch to consider is line item, as the other branches were all data components.
Line item has a nonrecursive link to item 332, so item 332 remains.
Line item also has member components unit cost 334, quantity 336 and price extended 338, which are included in accordance with rule (1).
Item 332 has two "identifier" components in its topmost level: product name 340 and product number 344, which are included under rule (2). Since each branch has been considered, the object view hierarchy 302 is complete.
Default forms are created for each semantic object in the object model at run-time, or earlier if the user requests them, e.g., using the routine of FIGURE 6.
the rules set forth in Tables 1-3 establish the interface or "controls" that are generated for the model components associated with a semantic object in creating a default form.
a control is the interface found within a form (or report) that dictates the format of the information in the form, such as a box or grid. It is noted that, while a single semantic object may have several forms (or reports), each begins with a default structure that may be subsequently modified. It is this default structure that is referred to throughout this description.
the cardinality of a model component is the number of instances of data that may be stored in a database for a corresponding model component.
the path cardinality of a model component is considered to be either one or greater than one for form generation purposes, and is determined by reviewing the cardinalities of a component through any containers (i.e., group components) to the semantic object in which the component is located ⁇ in other words, the cardinality of itself, its parent (if one exists), its parent's parent (if one exists), and so on, until the top-level of the root view object has been reached.
a simple value component's data type will dictate what type of mark goes into its associated edit box, if any.
a model component will have a cardinality greater than one if more than a single instance of the component may exist.
the path cardinality of a model component will be greater than one if any component in the chain, from that model component to the semantic object upon which the form is based, has a cardinality greater than one.
the path cardinality of the parent of a model component will be greater than one if any component in the chain from the parent of the model component to the semantic object has a cardinality greater than one.
TABLE 1 refers to controls associated with group model components
TABLE 2 refers to controls associated with link model components
TABLE 3 depicts the controls for the data components.
the interaction between and explanation of the control generation rules will become more apparent when referenced in conjunction with default forms that have been created for some of the semantic objects in the sample object model 262 illustrated in FIGURE 8. While the object view hierarchies for each semantic object are not presented specifically, FIGURES 10, 11, and 12, respectively, illustrate exemplary default forms for the semantic objects customer 264, order 266, and shipping company 270. Each event in TABLES 1 and 2 is considered.
the following format is used to refer to the lineage of a model component: semantic object_child_grandchild_great grandchild, etc.
the generation of controls for group components will be addressed first.
the first entry in TABLE 1 is groups that have a maximum cardinality of one and whose parents have a path cardinality of one.
groups are represented by a "group box," which is a term used to describe a border that encompasses a control related to each member in the group.
Examples of groups that have a maximum cardinality of one and a "parent" path cardinality of one are shown in a default form 400 for the semantic object customer, illustrated in FIGURE 10. They include customer_address, customer_phone, and customer_fax and are represented by group boxes 402, 404, and 406, respectively.
groups 402, 404, and 406, respectively are represented by group boxes 402, 404, and 406, respectively.
groups Inside each group box are controls for the member components for that group.
the group box 402 includes controls 408 for the street, city, state, and zip code member components. The specifics of control generation for these and other data components are discussed below in TABLE 3 and accompanying text.
the second entry in TABLE 1 is groups that have a maximum cardinality greater than one and whose parents have a path cardinality of one.
groups are represented by a grid.
a grid includes a representation of each member component in the group, e.g., the name of the member component on a title row; and has additional rows underneath the title row for data entry.
An example of this type of group is customer_customer contacts, where a grid 410 has been created.
the grid 410 includes a title row 412 that includes an identifying label "Customer Contacts"; a subtitle row 414 that has identifying labels representing the group's member components; and data entry rows 416.
the third entry in TABLE 1 is groups that have a maximum cardinality of one and whose parents have a path cardinality greater than one. Such groups are not directly represented with a title for a control. Rather, the member components in the group appear as columns in a grid that was constructed for a parent component. An example of this type of group is customer_customer contacts_direct line. With reference to the grid 410, the member component direct line includes an area code, phone number, and extension. Each of these have been identified in the subtitle row 414. However, the title "Direct Line" by default does not appear in conformance with the rules in TABLE 1. As will be discussed below, a user can customize the form to include the "Direct Line" label above the area code, phone number, and extension components.
the fourth entry in TABLE 1 is a group that has a maximum cardinality greater than one and whose parents have a path cardinality greater than one.
Such groups are represented by a detail grid that appears in the proximity of a master grid, where the master grid was created for a parent somewhere in the path from the model component group to the semantic object.
An example of a group that has a maximum cardinality greater than one and a parent path cardinality greater than one is customer_customer contacts_important dates and is represented in FIGURE 10 by a detail grid 420.
the detail grid 420 includes a title row 422 identifying the group name of "Important Dates"; a subtitle row 424 listing each member in the group (Event and Event Date); and data entry rows 426 underneath the subtitle row.
the detail grid 420 is part of a "master-slave" scheme in that the contents in the detail grid will change as different customer contacts in the grid 410 are entered or existing customer contacts highlighted.
the first event is links that have a maximum cardinality of one and whose parents have a path cardinality of one.
Such links are represented by a "platform" and a search button.
a platform is similar to a group box, and is a term used to describe a border that encompasses a control for each component of the referenced semantic object or member component that is of interest in the form, and thus included in the platform.
the platform also includes a search button, which is a standard Windows push button that is used at run-time by the user to perform a query. If the user has typed any information into any of the fields contained within a platform, the information is taken into account when the query is performed.
an example of a link that has a maximum cardinality of one and a parent path cardinality of one is order customer and is shown in a default form 430 for the semantic object order.
the link is represented by a platform 432, a label 434 of "Customer,” and a search button 436. Also included in the platform 432 is a control 438 for company name, which is an identifying model component of the semantic object customer. See the default object view hierarchy in FIGURE 9C. Other model components for this object may also be added to the form, but are not included by default.
the second entry in TABLE 2 refers to links that have a maximum cardinality greater than one and whose parents have a path cardinality of one. These links are represented by a grid, in the same manner as groups having the same coordinating characteristics.
An example of this type of link is customer order in the customer form 400 of FIGURE 10.
a grid 440 has been created identifying the orders for a customer.
the grid 440 includes a title row 442 that includes an identifying label "Orders"; a subtitle row 444 that has an identifying label for the order number; and a data entry row 446.
other components from the link to the semantic object orders may also be added to the form, but are not included by default. If additional member components are added, they would be represented by additional columns in the grid 440.
the third entry in TABLE 2 is links that have a maximum cardinality of one and a parent path cardinality greater than one. As was discussed above in regard to groups (the third entry in TABLE 1), these links are not directly represented in a control. Rather, one or more member components from the semantic object referenced by the link appear as columns in a grid that was constructed for a parent component.
An example of this type of link is order_line item_item, as shown at grid 450 in the object form 430 in FIGURE 11.
the grid 450 includes columns 452 for entering information about an item's product name and product number, but a label of "Item" itself is not included in accordance with the rules. Again, a user may wish to customize the form to include a label for "Item” that would appear above the product name and product number, if desired.
the last entry in TABLE 2 refers to links that have a maximum cardinality greater than one and a parent path cardinality greater than one.
Such links are represented by a detail grid that appears in the proximity of a master grid, and includes a search button.
An example of a link that has a maximum cardinality greater than one and a parent path cardinality greater than one is shown in a default shipping company form 470 illustrated in FIGURE 12.
a detail grid 472 includes a title row 474 identifying the referenced semantic object "Item" upon which the grid is based.
a subtitle row 476 lists the member objects that are included by default in the detail grid 472. These include both the product name and the product number.
the detail grid 472 is part of a "master-slave" scheme and is based on the shipment of interest (shown in a master grid 478). Thus, the contents of the detail grid will change depending upon the particular shipment being entered or reviewed in the master grid 478.
TABLE 3 refers to controls generated for data components. Controls for data components typically include a title (listing the name of the component), a data entry location, and may also include a "mask.” A mask is a preset set of symbols that facilitate entry of data into the appropriate places. The data type will determine the type of mask, if any, a model component will receive. For example, a currency mask will insert a "$ .” in the data entry location. A date mask will insert: " - - " or " / / " in the data entry location.
FIGURES 10-12 illustrate some of the controls described in TABLE 3.
data entry location 480 at the upper left of the order form 430 depicts an example of a numeric mask for the data component order_order number.
An example of a date mask is illustrated in data entry location 482, for the data component order_order date.
the data entry location 438 for order customer company name is an example of an "edit + label" control for a text data component.
currency masks are illustrated in data entry locations 484, corresponding to the data components order_subtotal, order_tax, and order_total. Examples of the other data components are either not pointed out specifically or not shown in the example forms in FIGURES 10-12, but the controls generated using the rules above will be apparent from the controls that are shown and discussed.
An important aspect of the invention is the ability to customize forms and reports before run-time so that the form or report includes access to information in the database that is important to the user.
the look and feel of the form or report may also be modified using the design tool. The underlying processes for implementing aesthetic modifications are not discussed herein, as they will be apparent to those skilled in the art.
the design tool includes a number of user interfaces through which a form or report may be modified. For example, to remove reference to a model component while viewing a form or report, a user can simply highlight and then delete the information using the pointing device and/or keyboard. In doing so, the model component will be deleted from the object view hierarchy for that form or report, and the form or report itself will be automatically updated.
a control palette may be used to add unbound controls, i.e., a control that is not bound to a model component, to a form or report.
FIGURE 13 Another user interface that may be used both to add and remove information about model components from forms or reports is an "Add Component" dialog box 490, illustrated in FIGURE 13.
the dialog box 490 is separated into left and right halves 492 and 494.
the left half 492 displays the semantic object upon which the form is based, in this instance its "order,” as well as semantic objects and model components that are linked to the semantic object upon which the form is based.
the right half 494 displays the contents of a container corresponding to a semantic object or a model component that has been highlighted in the left half 492.
the model components directly contained by the semantic object order are shown in the right half 494.
the group line item has been expanded to show the model components that it directly contains.
Model components that are included in an object view hierarchy for a form or report have checkmarks 496 beside their names. Model components may be added or removed from a form or report by selecting or deselecting the model component of interest in the right half 494.
the object view hierarchy, and hence form or report, is automatically updated to incorporate the selection.
FIGURE 14 illustrates the form 430 for the semantic object "order” in FIGURE 11, but including exemplary modifications made by a user in customizing the form.
the model component "product number” has been removed from the grid 450. This is accomplished, for example, by selecting and then deleting the product number column in FIGURE 11 or by invoking the Add Component dialog box shown in FIGURE 13 and double-clicking on "product number.”
the object view hierarchy for the form 430 is automatically updated by the design tool, and the product number model component is removed from the form.
Model components may be added in much the same way.
the model components order_customer_phone and order_customer_fax have both been added to the form 430.
FIGURE 15 illustrates the object view hierarchy 302 from FIGURE 9C, but modified in response to the changes made to the form in FIGURE 14.
the model component order_line item_item_product number has been removed, and model components order_customer_phone 510 and order_customer_fax 512 have been added.
These reflected changes illustrate how the design tool utilizes object view hierarchies to store the information needed for generating forms and reports for semantic objects.
routines for building a form definition i.e., a hierarchy of form containers, in accordance with the invention are set forth in the Appendix as pseudocode LISTINGS L1-L4.
the routines encompass the form generation rules described in Tables 1-3. Those skilled in the art will appreciate how to generate the code necessary to display or print the form definitions.
the routines are written in pseudocode that resembles the programming language C++. An overview of selected lines in the routine is provided for clarity, particularly for those not versed in C++.
LISTING LI illustrates skeletal class descriptions showing the essential features of the C++ classes used in the routine of LISTING L2.
the classes created include: FormObject at lines 10-170; Form at lines 180-230; Menultem at lines 240-290; PopupMenu at lines 300-350; Grid at lines 360-410; Platform at lines 427-470; and GroupBox at lines 480-530.
the class FormObject is a base class for the Form, PopupMenu, Grid, Platform and GroupBox classes.
the class Form is created for a root view object; the class Menultem is created for actions inside an action group; the class PopupMenu is created for action group view objects; and the class Grid is created for multi-valued view components of all types.
the class Platform is created for single-valued, object link components.
the class GroupBox is created for single-valued, group view components.
the classes created on the second page of LISTING LI include GridColumn at lines 540-600, CheckBoxColumn at lines 610-660, EditGridColumn at lines 670-720, Formltem at lines 730-790, ActionButton at lines 800-850, SearchButton at lines 860-910, CheckBoxItem at lines 920-970, and EditItem at lines 980-1030.
the class GridColumn is a base class for the classes CheckBoxColumn and EditGridColumn.
the class CheckBoxColumn is created for Boolean simple valued columns in a grid.
the class EditGridColumn is created for all other simple valued data items in a grid.
the class FormItem is a base class for the classes ActionButton, SearchButton, CheckBoxItem, and EditItem.
the class ActionButton is a class created for action items that are not an action group; SearchButton is created for object links that have a path cardinality of one; CheckBoxItem is created for Boolean simple valued object view components with a path cardinality of one; and EditItem is created for all other simple valued object view components with a path cardinality of one. Single-valued group or object link view components that have a path cardinality greater than one do not generate specific form objects, and thus a separate class is not required to hold information related to them. It is noted that while the pseudocode does not show the data or implementation of the operations specified, these will be apparent to those skilled in the art.
line 20 declares a parameter called pViewObj that points to a "current" view object in an object view hierarchy.
pViewObj When the routine is called for the first time, pViewObj will point to a root view object that is based on a semantic object for which a form is being created. Subsequent (recursive) calls will address lower level view objects.
Line 30 declares a parameter called pFormObject that points to a form object that will hold the form definitions for the current view object.
the types of form objects that pFormObject may point to include: a form (created for root view objects), a grid (created for multi-valued view objects), a platform (created for single-valued links), or a group box (created for single-valued groups), as described above.
the label of the current form object is set to the title of the current view object. The title will be the name of view object, unless a caption has been created by the user.
Lines 80-100 define local variables "iter,” pChild, and pNewFormObject that the routine will use.
the variable iter will be used to iterate across the contents of the current view object.
iter will return each child of the current view object, in turn.
the block bounded by lines 110-330 takes into account action item and action group view objects.
a test is made to determine if the current child view object is an action item or action group component. If the current child is an action item or action group, a test is made at line 150 to determine if the current child is an action group. If the current child is an action group, at line 170 a local variable pNewMenu is declared.
pNewMenu is declared.
a new popup menu is created and placed in pNewMenu. This routine is then called recursively at line 190, thereby adding menu items to the new menu.
the menu is added to the current FormObject.
the block designated by lines 230-320 is executed.
a test is made to determine if the current FormObject is an action. If the current FormObject is an action, at line 260 a menu item is created and inserted into the form object. Otherwise, at line 300, an action button is created and inserted into the current FormObject. This completes the block designated by lines 130-320.
a test is made to determine if the child of the current view object that is under consideration is multi-valued, i.e., if it has a maximum cardinality that is greater than one.
multi-valued model components will be displayed in a grid. If the child is multi-valued, a grid is created at block 390.
Line 400 is a recursive call to define the contents of the grid. The type of grid created will depend upon whether a grid was also created for the current view object or any parents in the line of succession to the root view object. If so, the child's grid will be a detail grid dependent upon the (master) grid that was created for the parent (or a successor thereto). Otherwise, the newly created grid is not a detail grid.
the grid is inserted into pFormObject.
Lines 430-760 are directed toward children that are based on single-valued components only.
a test to made to determine if the container that was created for the current view object is a grid. If the current form object is a grid, a test is made at line 460 to determine if the child of the current view object is a link or a group. As dictated by the rules, in this case only the contents of the link or group view component are added to the current form object. This is accomplished by the recursive call at line 480.
the else determination at line 500 refers to a child that must be a single-valued, simple value view object.
a grid column is created and added to the current form object.
a suitable routine for creating grid columns based on the data type of the simple value view component is set forth in LISTING L3.
the child view object must be single valued and the current view object must not be a grid.
a platform, group box, or edit field is created at line 600, 670, or 740, respectively.
the following operations are performed: a platform is created at line 600; a search button is added to the newly created platform at line 610; this routine is called recursively at line 620, thereby adding controls to the platform definition; and the platform is added to the current form object (pFormObject) at line 630.
a test is made at line 650 to determine if the child of the current view object is a group. If the child is a group, a group box is created at line 670; this routine is called recursively at line 680, thereby adding controls to the group box; and the group box is added to the current form object (pFormObject) at line 690.
the child of the current view object is neither a link nor a group, it must be a single-valued, simple value view object (line 710).
an appropriate routine is called at line 740 to create a control and add it to the current form object.
a suitable routine for creating controls based on the data type of the simple value view component is set forth in LISTING L4.
a test is made to determine if the current view object is a multi-valued, simple value view object. By definition, such view objects cannot have children. If the current view object is a multi-valued, simple value view object, a routine is called at line 810 to add a column to the current form object (which must be a grid). A suitable routine for accomplishing this task is set forth in LISTING L3, and described next. The routine then terminates.
LISTING L3 illustrates an exemplary routine for creating grid columns based on the data type of simple value view components.
a test is made to determine if the data type of pViewObject is a Boolean variable. If the data type is Boolean, a check box grid column is created and returned at line 70. Otherwise, an edit grid column is created and returned as shown at line 90.
LISTING L4 illustrates an exemplary routine for creating controls in a platform based on the data type of a simple value view component.
a test is made to determine if the data type of pViewObject is a Boolean variable. If the data type is Boolean, a box is created and returned at line 70. Otherwise, an edit box is created and returned, as shown at line 90.
exemplary routines for building a report definition i.e., a hierarchy of report containers, in accordance with the invention are provided in LISTINGS L5-L6.
the routine of LISTING L6 is similar to that in LISTING L2, and the report generation rules will be apparent from the routine and the following discussion. Those skilled in the art will appreciate how to generate the code necessary to display or print the report definitions described in the routine.
a complete report is produced by selecting a set of objects, a.k.a. master records, and printing each of them followed by the appropriate detail records or objects.
the routines presented in LISTINGS L5 and L6 generalize the process by allowing detail records to act as master records for further sets of detail records.
the data to be printed are represented by report items. Report items may also be collected and given a title. These collections can be used wherever a report item can, and print the title above the contained report items.
the hierarchy of master and detail sections on a report is represented by objects of class MVReportContainer.
Titles grouping report items are represented by objects of class SVReportContainer.
Report items are represented by objects of class ReportItem. When these objects are created, they are passed a view object which carries information from the model. The report containers and report items can then obtain any needed information about data type, format, etc., from the view components.
mappings When presenting an object view as a report, the following mappings are used:
a root view object produces a multi-valued container and contents
a multi-valued view object produces a multi-valued container and contents
a single-value group produces a single-value container and contents
a single-value object link produces a single-value container and contents
a single-valued simple value produces a report item
(6) as a special case, multi-valued simple values produce a multi-valued container and a single report item.
LISTINGL5 illustrates skeletal class descriptions showing the essential features of the C++ classes used in the routine of LISTING L6.
the classes created include: ReportContainer at lines 10-100; MVReportContainer (for multi-valued view components) at lines 110-160; SVReportContainer (for single-valued, non simple valued view components) at lines 170-220; and ReportItem (for simple value view components) at lines 230-280.
Each container has a title area and a content area.
the container MVReportContainer is used to specify the outermost formatting of a report.
the multi-value and single-value containers dictate the formatting for multi-value and single-value view objects, respectively.
the class of object created is not specific for different types of view objects, but instead is dependent solely on the maximum cardinality of the view object. It is noted that while the pseudocode does not show the data or implementation of the operations specified, these will be apparent to those skilled in the art.
"current" view object in an object view hierarchy is declared at line 20.
pViewObj When the routine is called for the first time, pViewObj will point to a root view object that is based on a semantic object for which a report is being created. Subsequent (recursive) calls will address lower level view objects.
Line 30 declares a parameter called pContainer that points to a container that will hold the report definitions for the current view object.
the types of containers that pContainer may point to include: a report (created for root view objects), a single-valued report container (SVContainer), or a multi-valued report container (MVContainer).
the title of the current container is set to the title of the current view object. The title will be the name of view object, unless a caption has been created by the user.
Lines 80-100 define local variables "iter,” pChild, and pNewContainer that the routine will use. The variable iter will be used to iterate across the contents of the current view object. During a loop bounded by lines 110-340, iter will return each child of the current view object, in turn. At line 130 a test is made to determine if the current child view object is an action item or action group. If it is, at line 140 the routine loops to line 110.
a test is made to determine if the child of the current view object that is under consideration is multi-valued, i.e., if it has a maximum cardinality that is greater than one.
multi-valued model components will generate a multi-valued container and contents, as shown in lines 150-210.
a new multi-value container is created.
this procedure is called recursively to define the contents of the container.
the new multi-valued container is added to the current container.
Lines 220-340 are directed toward children that are based on single-valued link or group components only.
a test is made to determine if the child of the current view object is a link or a group. As dictated by the rules, in this case a single-valued container is created at line 250.
a recursive call is made to fill up the contents of the new container.
the new container is inserted into the current container.
the else determination at line 290 refers to a child that must be a single-valued, simple value view object.
a report item is created and added to the current container.
a test is made to determine if the current view object is a multi-valued, simple value view object. By definition, such view objects cannot have children. If the current view object is a multi-valued, simple value view object, at line 380 a new report item is created and added to the current container.
Tables T4-T27 illustrate the C++ classes that are used to represent the components listed in FIGURE 7.
the data members of a class are listed in the left column and the data type in the right column.
the description provided below will augment that of the '997 application. Thus, this description will focus only on the classes and data members/data types that have been added. In general, the changes include the addition of data members to the previously defined classes to support the creation of object views.
the data members that have been added to classes described in the '997 application include:
semantic objects only semantic objects; has-a type components (i.e., simple value, object link, and group); and is-a type components (i.e., parent, subtype, and subtype group) were described in the '997 application.
type components i.e., simple value, object link, and group
type components i.e., parent, subtype, and subtype group
action items and action groups define buttons or menus on forms created from semantic objects that perform desirable functions. As with other components, all action items and action groups are based upon some corresponding template.
the design tool provides the user with a predefined list of typical action templates that may be used with a semantic object. Exemplary action templates include: arrange icons, copy, cut, paste, delete field, delete record, find, open form, print report, and run script. Exemplary action group templates include: forms, help, record, reports, view, and window. In addition, a user can create action item or group templates.
FIGURE 16 illustrates exemplary steps that may be taken by the design tool 50 to create a template for an action item.
the action item "Open Form" is used as an example. Other action items follow the same format, but may have more or less information in the template depending upon the action that is being invoked.
sufficient memory is allocated for the new action template.
the new template is assigned a unique integer identifier. The user is prompted to enter a name for the template at block 802. If no name is provided, the system gives the new template a default name descriptive of the action, e.g., "Open Form.”
a test is made to determine if the name of the template is unique among all templates within the object model. If not, a numeric suffix is added to differentiate the name of the new template at block 804.
the accelerator key of the action template is initialized to "None" at block 806.
the accelerator key property allows a user to choose a key sequence which invokes the action.
the action associated with the action template is initialed to "Open Form.”
the action target is then initialized to "None" at block 808.
Some actions require the user to specify a target for implementing the action, which will be an object view. For example, the Open Form action item requires a user to select a form object view.
the caption property of the action template is initialized to an empty string. The caption property provides an alternative field title to be used on a form produced by an application program accessing the database whose schema is defined by the object model.
the description property of the action template is initialized as an empty string at block 810.
the enable property which allows a user to enable or disable a control generated from the action, is then initialized to "yes" at block 812.
the help ID property is initialized to "0.”
the help ID property is used on run-time to connect to user-defined help files.
Form access permissions are initialized to default.
Form access permission is a collective term for grouping of permission to add, permission to delete, and permission to update properties.
the "permission to add” property determines whether or not a user of the form can add new data to the database; the "permission to update” property determines whether a user can update data in the database; and the "permission to delete” property determines whether a user can delete data from the database.
the setting can be yes or no.
the default for each action item is typically set to yes.
the status bar text for the action item is set to a text string that describes the function of the action.
the text would read: "Opens the form for data entry and searching.”
the derived components property list for the action template is initialized as an empty, unordered collection of pointers to components that are derived from the newly created action template. The routine then terminates.
a second action item property that is not mentioned in the "open form” action, but that is advantageous, is called “query form.”
the "query form” action item property allows a user to choose a form that is displayed prior to the printing of a report. This form will then be used to define a query that will dictate the contents of the report.
While creating and modifying an object model a user can add action items to semantic objects in the model by selecting, dragging, and dropping an action template from the template manager into the semantic object. Once an action template is dropped into a semantic object, the system creates a corresponding action item (or action group). An exemplary routine for creating action items is set forth in FIGURE 17. After the action item is created, the design tool immediately inserts it into the semantic object using the routines shown in FIGURES 19 and 20, described below.
the design tool first gets a pointer to the corresponding action template at block 820. Next, sufficient memory is allocated for the new action item at block 821. At block 822, the action item is assigned a unique integer identifier. At block 823, the accelerator key, action, action target, caption, description, enable, help ID, name, permission to add, permission to delete, permission to update, and status bar text properties are initialized from the corresponding property in the action template that is being used to create the action item. If at any time the user desires to change any one of the properties of the action item as they apply only to the semantic object in which the component is placed, the user may do so using the property sheet shown in FIGURE 2B and described above.
the container property is set equal to NULL at block 824.
the contained pointer When the action item is inserted into a semantic object, the contained pointer will be set equal to the address of the containing semantic object. If the action item is placed in a nested action group, the container property will be set to point to the innermost action group that contains the action item during the routine in which it is inserted.
the base template pointer is set equal to the address of the action template from which the action item was created.
a pointer to the newly created action is added to the list of the derived action item components maintained by the corresponding action template.
the derived component list is used by the design tool to effect changes to a property of all components based upon a template if a user changes the property in the corresponding template.
FIGURE 18 illustrates an exemplary routine for creating an action group template in accordance with the invention.
the action group template is then assigned a unique identifier at block 831.
the user is prompted for a name for the action group template. If no name is provided, the system will use the default name "action group.”
a test is made to determine whether the action group name is unique among all groups in the object model. If not, a numeric suffix is added to differentiate the action group name from related names, shown at block 835.
the caption property of the action template is initialized to an empty string at block 836.
the description property of the action template is initialized as an empty string.
the enable property is initialized to "yes.”
the help ID property is then initialized to "0" at block 841.
the status bar text for the action item is set to a text string that describes the function of the action.
the contents property of the action group is initialized as an empty, ordered collection of pointers to the templates that are contained within the action group template.
the derived components list is initialized as an empty, unordered collection of pointers to action groups that are derived from the newly created action group template.
the routine then terminates.
Action group templates will usually have other templates added to then-contents list before being used in the object model. These additions may be performed using an exemplary routine defined in FIGURES 38 A and 38B.
the user can create a corresponding action group component in one or more semantic objects by selecting the action group template, dragging, and dropping it into the boundaries of a semantic object.
the design tool creates a corresponding action group component according to the blocks shown in FIGURE 19.
the container pointer is set equal to NULL.
the container pointer is set equal to the address of the semantic object or the action group component in which the new action group component is logically included. Exemplary routines for performing this task are set forth in FIGURES 20 and 21A-21B.
the container pointer will be set to point to the innermost action group.
the components that are defined by the contents list of the action group template are created.
the design tool creates a new component and places a pointer to the new component in the contents list for the new action group component, as shown at block 858.
a pointer to the new action group component is placed in the corresponding group template's list of derived components.
FIGURE 20 is an exemplary routine for updating the object model when a user has inserted a new component into a semantic object (i.e., the current semantic object).
the design tool gets a pointer to the new component being inserted, be it an action item, action group, or other type of component.
a test is made to determine whether the user is attempting to insert a parent component that is derived from a template, which is based upon a semantic object that is a subtype of the current semantic object, or that is based upon the same template as a parent component that the semantic object already contains.
a test is made to determine whether the user is attempting to create a subtype component created from a template that corresponds to a semantic object, which is a parent of the current semantic object, or is based upon the same template as a subtype component that the current semantic object already contains. If such an insertion is detected at either block 864 or 866, an appropriate error message is produced at block 870, and the insertion is not allowed.
a pointer to the newly added component is included in the current semantic object's contents list at block 872.
the container pointer of the inserted component is updated to point to the current semantic object at block 874.
the design tool ensures that the names of the newly added component and all the component's contents, if a subtype or action group, are unique within the semantic object. If any name is not unique, a numeric suffix is added to the name to differentiate it. The routine then terminates.
FIGURES 21 A and 21B illustrate an exemplary routine for adding a component to an action group.
a test is made to determine if the component being added to the group is an action item or an action group component. If the component is not one of these types, an error message is produced at block 880 indicating that the insertion is not allowed. Assuming that the component can be added to the action group component, a pointer to the new component is added to the action group's ordered contents list at block 882.
the container pointer of the inserted component is changed to the group component that contains the new component.
a test is made to determine if the name of the new component is unique among the components already present in the action group. If not, a numeric suffix is added to differentiate the name at block 887. Once this is accomplished, or if the names of the components in the action group were already unique, a test is made at block 888 to determine if the group component into which the new component has been inserted is the only group that is derived from the corresponding group template. If so, then a pointer to the template of the added component is added to the contents Ust of the group template at block 889 and the routine terminates.
a new group template is created at block 890.
the contents list of the new group template is initialized to include the templates of all the member components, including the new member component, at block 891.
a test is made to determine if the current group is contained within another group, i.e., in a "container group.” If the current group is not contained within another group, the routine terminates. Otherwise, a test is made at block 893 to determine whether the container group is the only group derived from its corresponding template. If the container group is not the only group derived from its corresponding template, a new group template is created at block 894.
the contents list of the newly created group template is initialized to include pointers to all the member components. Once this is accomplished, the routine terminates.
the container group is the only group derived from its corresponding template
the contents list of the corresponding group template is updated to include the template of the newly added component at block 896. The routine then terminates.
FIGURE 22 illustrates an exemplary routine for inserting an action item template or action group template into an action group template.
a test is made to determine if the user is attempting to add a template whose contents list already includes the group template into which the new template is being inserted. If the answer is yes, an error message is presented at block 902, indicating that the insertion is not allowed because it represents a recursive relationship. Assuming that the template can be added to the group template, a pointer to the newly added template is appended to the contents list of the group template at block 904. As indicated above, each template includes a containers list of the templates in which it is included. At block 906, a pointer to the group template is added to the containers list of the newly inserted template.
the design tool considers each component in the derived components list maintained by the group template and creates a new component from the newly inserted component template and inserts it into the derived component. Therefore, each component within the semantic object model is updated to reflect the template newly added in the group template. The routine then terminates.
a run-time view hierarchy is a data structure that is used when running forms and reports.
the structure of a run-time view hierarchy is related to the structure of semantic objects, but is separate therefrom because it incorporates information about the database schema not represented in the object model.
object views there may be many run-time view hierarchies based on a single semantic object. In general, each form and each report will have a separate form view upon which it is based.
a run-time view hierarchy is a hierarchy of "view elements," where each view element is founded from either a semantic object, a model component in the object model, or a view object.
a run-time view hierarchy stems from a root view element, defined as a view element based on a semantic object or a root view object.
view elements are containers that hold information necessary for running forms and reports.
a view element corresponding to a link will include information about the semantic object coupled to the link.
the type of information held in any particular view element is determined by the object type, e.g., simple value. What is contained in a run-time view hierarchy is dictated by the rules that are set forth and discussed below.
the classes of a run-time view hierarchy include: (a) view element and (b) group view element.
View elements are generated in connection with simple value components and simple value object view components, as well as database columns in the schema not otherwise represented in the object model.
Group view elements are generated in connection with semantic objects, all model components except for single-valued simple value components, and all view objects except single-valued simple value view components.
Semantic objects produce a root view element that includes view elements based on model components directly contained by (topmost level) the semantic object.
the root view element order will contain view elements representing: order number, order date, customer, line item, subtotal, tax, and total.
customer and line item are group view elements; the remaining elements are simple view elements.
group view element class described in LISTING 7B and accompanying text.
a root view element will include view elements representing the surrogate key, if any, for the table generated for the semantic object, and may include view elements based on foreign keys used to carry link information between semantic objects.
the root view element order will contain the surrogate key ID_ and foreign key CUSTOMER_ID_FK, shown in lines 430 and 390, respectively, of LISTING L74.
Simple Value Components Simple value model components produce either a single view element, or a group view element containing two or three view elements, depending upon the cardinality and ID status of the component.
Single-valued simple value components produce a view element only.
Multi-valued simple value components produce a group view element associated with the table generated for the component.
Group view elements based on multi-valued simple value components that are ID unique will contain a view element for a foreign key to the parent table group and a view element for the data represented by the component.
Group view elements based on multi-valued simple value components that are not ID unique contain these, and in addition, a view element that represents a surrogate key for the table. For a listing of the data held by non-group view elements, see the view element class described in LISTING L7A and accompanying text.
Group Components Single-valued group components, including subtype groups, produce a group view element that contains view elements generated from the components in the group. Multi-valued group components will contain an ID, foreign key and whatever is generated from the group, including data groups.
group component line item it will contain ORDER_ ID_FK, ITEM_ID_FK, item, unit cost, quantity, and extended price, and ID_.
Object link components include object links, parent links, and subtype links.
An object link component will generate a group view element based on the referenced semantic object and containing those view elements necessary to represent the primary key of the table generated for the referenced semantic object.
one or more view elements representing a foreign key carrying the relationship are created.
the foreign key view elements relate the current table group to the table group generated for the container of the object link component's pair component. Which group view element contains the foreign key view elements is determined during schema generation, and indicated by the schema.
a group view element to contain the foreign key view elements will be created if necessary, as described in LISTING L15 and the accompanying text.
the rules for creating view elements representing object links are set forth in greater detail in LISTING L9 and L10 and accompanying text. For a listing of the data held by group elements, see the group view element class described in LISTING L7B and accompanying text.
LISTING 7A illustrates an exemplary class definition for the C++ class "ViewElement".
Class ViewElement defines the base class for the worker classes of run-time view hierarchies. This base class defines accessors for some data that only make sense in derived classes, e.g., group view elements, as well as accessors and operations useful in the base class.
simple (non-group) view elements hold data, i.e., which may be user data or system data such as primary or foreign keys.
Group view elements provide aggregation and iteration services to clients of the run-time view.
Lines 190-290 define enumerations useful in the operation of view elements.
the "roles" enumeration indicates how a view element, or group view element, is used, i.e., its role in the run-time view hierarchy.
the unnamed enumeration defined on line 290 is used to tell the view element if updated information is acceptable when calling member functions which provide values or status of database data items.
Lines 300-470 declare various constructor functions for view elements; each of these is described in the text accompanying its listing.
Lines 500-510 both provide for the creation of a ViewElementlter which provides any contained ViewElement objects, one at a time. Since base class ViewElements do not contain any other view elements, the iterator object returned is always empty when these functions are invoked on the base class.
Lines 530-630 define various useful informational functions. All of these functions can be computed by examining the role of the view element.
the functions IsGroup() and IsColumn() are inverses, allowing the user to check if a particular view element is a group view element or simply a view element.
the function IsTable(), and its alias IsTableGroup() will return true if the role is ATTR_TABLE, X_TABLE, or SO_TABLE.
the function IsIntersectionTableQ merely checks to see if the role is X_TABLE.
the function IsLink() returns true for any view element having a role of SO_TABLE which also has a parent group view element. It should be apparent that any view element with a role of SO_TABLE will in fact be class Group ViewElement.
Lines 650-690 provide access to information about the view element hierarchy and the key structure of the tables with which it is associated.
the functions PrimaryKey() and ForeignKey() are virtual, with only vacuous implementations in the base class, i.e., they return NULL.
Lines 700-720 define functions used in construction of run-time view hierarchy or in creating SQL statements. These are described in the text accompanying the listings for each function.
Lines 740-780 declare functions which provide read and write access to the values contained by a view element at run time, as well as information about the values. The implementation of these functions is readily apparent.
Line 790 declares the function CopyKey() which will copy the current value of the object pointed to by the keyPair member variable to the current view element, unless the current view element is non-NULL, or has a NULL keyPair; in these cases, a suitable error is returned.
Lines 800-810 provide means to set and retrieve a predicate value associated with the current view element. This value is used when building queries, as can be seen in LISTINGS L48-L57 and the accompanying text.
Line 820 defines the function SubQueryPredicate(), which is shown in LISTING L53 and described in the accompanying text.
Lines 830-990 declare accessor functions for some of the member variables declared on Lines 1010-1240. These are all trivial functions which simply return the appropriate data values; their implementation will be apparaent to one skilled in the art.
the member variables are defined as follows: objectID and viewObejctID are assigned when the object is constructed, indicating the base model object and base view object for the view element. Either or both of these may be zero.
the data members minCard, maxCard, allowedAction, idStatus, valueType, dataSource, initialValue, and recomputeExpresion carry values from the object model, if available, depending on the constructor used. See the constructor listings for further details.
the data members name, maxLength, scale, logicalLength, dataType, and dbDataType carry values from the schema, if available, as appropriate.
the data members role, parent, parentTableGroup, pColumn, and pModelObject are set according to the specific constructor used.
the data member keyPair is set by SetKeyPairQ, if invoked during run-time view construction.
LISTING 7B illustrates an exemplary class definition for the C++ class "Group ViewElement".
Group View Elements provide aggregation and iteration services to clients of the Runtime View. They also provide cursor-like behavior when created in association with a table in a database schema definition.
Lines 120-240 declare various constructor functions for group view elements; each of these is described in the text accompanying its listing.
Lines 270-280 both provide for the creation of a ViewElementlter which provides any contained ViewElement objects, one at a time. The iterator object returned can be used to obtain a pointer to each view element on a particular Group View Element's contents list, in turn.
Lines 300-320 return values from member variables declared on lines 1200, 1210 and 1180 of this listing; these values are set when the Group View Element is constructed.
Lines 330-360 provide access to information about the View Element hierarchy and the key structure of the tables it is associated with.
PrimaryKey() returns the value the pPrimaryKey member variable.
ForeignKey() returns the result of using the supphed pointer as a key in the foreignKeys hash table. Either or both of these functions can return NULL; both of them are sure to return NULL if the Group View Element used to call these functions is not associated with a table in the database schema.
Line 380 declares the member function
Lines 400-580 declare functions used to perform database queries using a runtime view hierarchy. These functions are shown in LISTINGS L46-L57, and described in the accompanying text.
Lines 600-710 declare functions which provide cursor behavior for a Group View Element. The operation of these functions is generally obvious; GetPairCount() returns the number of instances of a Semantic Object connected to the current object instance, and is used to determine if an object is available for connection. NewRow() adds a blank (all-NULL) row to the current set. This is used when extending the set by insertion (prior to calling Value() on the various View Elements contained in the group), or by selection of a queried row (prior to copying the contents of the queried row with CopyQueryRow()). CopyQueryRow() copies the row at the current position in a query result set to the current position in the editable result set.
Lines 720-860 declare functions used to effect changes to a database. These functions are shown in LISTINGS L37-L45, and LISTINGS L66-L71, and described in the accompanying text. Lines 880-1050 declare functions used in the construction of complete runtime views. These functions are shown in LISTINGS L14-L36, and described in the accompanying text.
Lines 1070-1140 declare accessor functions for some of the member variables declared on Lines 1170-1290. These are all trivial functions which simply return the appropriate data values; their implementation is obvious.
the member variables are defined as follows: connectPower, disconnectPower, fDeleteAllowed, fNewAllowed, minCount, maxCount, pairMinCard, and pairMaxCard carry values from the object model, as set by the particular constructor used. See the constructor listings for further detail.
the data member pTable is set by the various constructors as appropriate.
the data member pPrimaryKey is set by AddPrimaryKey(); the data members relatedTables and foreignKeys are added to by calls to AddRelatedTable(); and the contents member variable is populated by the process of building a run-time view. Both versions of DefineRuntimeView() will demonstrate this process.
LISTINGS L8-L12 are exemplary pseudocode routines for constructing view elements and group view elements that will be invoked by the routine described in LISTING L14.
the block defined by lines 60-260 show initializers for data members of the view element class. In essence, each data member is initialized to one of the following: a constant value, a value supplied by the base component object, or a value supplied by the data column definition.
the member variable parentTableGroup is initialized to point to the current view element's containing group view element if it is a table, or to the containing group view element's parentTableGroup if it is not.
a test is made to determine if the parent table group is based on the same model component as that on which the object being constructed (this object) is based. If so, this view element must represent the data column for a multi-valued simple value component. The design tool does not allow NULL values for such columns, and thus the minimum cardinality for the current view element is set to one. The routine then terminates.
LISTING L9 is a pseudocode constructor that will be invoked by the routine illustrated in LISTING L10. Specifically, the constructor initializes the data members listed in lines 60-240 to constant values, to values obtained from the supplied model object, or from a table in the schema. At lines 260-280, the member variable parentTableGroup is initialized to point to the current view element's containing group view element if the containing group view element is a table, or to the containing group view element's parent table group if it is not. The routine then terminates.
LISTINGL10 illustrates an exemplary pseudocode routine for initializing (constructing) a group view element that is associated with a table in the schema. Specifically, at line 60 the constructor of LISTING L9 is invoked to initialize the base view element class portion of the current group view element. The block bounded by lines 70-150 initialize member variables of the group view element object to default or supplied values.
a test is made to determine if the current group view element has no parent or if the model component on which this group view element is based is a link. If so, at line 190, the member variable "role" is set to indicate that the associated table was generated from a semantic object.
a test is made to determine if the current group view element has a parent. If the current group view element does have a parent, it must represent a link. In this case, the data members listed in lines 220-270 are initialized with values obtained from the base model component.
a block defined by lines 300-450 is entered if the base object of the current group view element is a multi- valued group or simple valued component. In this case, at line 320 the role is set to indicate that. At line 330, a test is made to determine if the base object is a group. If so, the data members listed at line 350-380 are initialized to values from the model object. If the current group view element is based on a multi-valued simple value, the data members listed in lines 420-430 are initialized as shown. The routine then terminates.
LISTING L11 illustrates an exemplary constructor invoked by the routine of LISTING L12 and takes into account single-valued groups. Specifically, the constructor initializes the data members listed in lines 50-220 to constant values, or to values obtained from the supplied model object. At lines 240-260, the member variable parentTableGroup is initialized to point to the current view element's containing group view element if it is a table, or to the containing group view element's parent table group if it is not. The routine then terminates.
LISTING L12 illustrates a pseudocode routine for initializing a single-valued group view element.
line 50 invokes the view element constructor of LISTING L11.
Lines 60-140 list the data members, which are initialized to constant values or values obtained from the associated model component.
the member variable role is set to indicate that this group view element represents a single-valued group. The routine then terminates.
LISTING L13 illustrates an exemplary routine for creating a set of canonical views associated with a particular object model.
a parameter "theModel” is declared which references an object model for which run-time views are to be created.
a variable "iter” is initialized from the model as an iterator on the collection of all semantic objects in the model.
Lines 60-70 declare variables used in the iteration.
Line 80 declares and initializes a reference to the schema associated with the object model.
the variable pSO will be set to a pointer to each semantic object in the model, in turn.
a new group view element is created based on the semantic object pointed to by pSO with a parent specified as NULL and associated with the table pointed to by the parameter returned by "theSchema.Lookup(pSO)," which looks up the semantic object in the schema and returns a pointer to a table object representing a database table generated from the given semantic object.
the routine DefineRunTimeView is invoked with a pointer to the current semantic object and the schema as parameters. This routine is described next.
LISTING L14 illustrates an exemplary routine for creating canonical run-time views in accordance with the invention.
a knowledge of relational database schemas and their underlying tables is presumed.
pModelObj is declared that points to a "current" model object in an object model.
pMode1Obj will point to a root semantic object which is the base model object for the current group view element.
Subsequent (recursive) calls will address model components contained within the semantic object.
a parameter called "theSchema" is declared and will be used to provide information about the relational database schema generated for the current object model.
Lines 60-100 define local variables "iter,” pChild, pVE, pGVE, and pTable that the routine will use.
the variable iter will be used to iterate across the contents of the current model object. During a loop bounded by lines 480-850, iter will return each child of the current model object, in turn.
a test is made to determine if the current group view element is associated with a table in the schema. If the current group element is associated with a table in the schema, a routine titled "AddPrimaryKey" is called at line 130 to add a view element representing the primary key of the table to the current group view element.
a test is made to determine if the table associated with the current group view element is an intersection table. If so, at line 160, the schema is consulted to determine a pointer that will point to a table generated from the current model object's referenced semantic object.
a new group view element is created at line 170 based on the current model object (pMode1Obj) having a parent specified as the current group view element (this) and associated with the table pointed to by pTable.
pMode1Obj the current model object having a parent specified as the current group view element (this) and associated with the table pointed to by pTable.
a pointer to the newly created group view element is added to the contents variable, which is a member variable of the current group view element.
a call is made to this routine on the newly created group view element with the current model object (pModelObj) and the schema of the object model as parameters.
a routine titled "AddForeignKey” is called at line 200 to add a view element representing the foreign key between the intersection table and the semantic object table generated from the model object's referenced semantic object.
a view element representing the foreign key between the intersection table and the intersection table's parent table group is added to the current group view element.
the routine terminates.
a test is made to determine if the current group view element is contained within another group view element.
a test is made to determine if the table associated with the current group view element was generated from a semantic object. If the current group view element is contained within another group view element and if the table associated with the current group view element was generated from a semantic object, at line 290 a local variable called pPairObj is declared as a pointer a model object and initialized to the current model object's pair object.
pSO is declared as a pointer to a model object and initialized to the current model object's referenced semantic object.
a variable called pLinkParent is declared as a pointer to a group view element and is initialized to the current group view element.
a test is made to determine if the current model object's referenced semantic object directly contains the current model object's pair object. If it does not, a function titled CreateParentGroup is called to create and return a pointer to a group view object based on the model object that does contain the current model object's pair.
An exemplary routine for performing this function is set forth in FIGURE LI 5.
a test is made to determine if the table associated with the model object based on the container of the current model object's pair contains the foreign key that carries the relationship represented by the current model object and its pair. If so, the routine AddForeignKey() is called to add the appropriate view elements to the group view element based on the container of the current model object's pair. At line 400, the routine terminates.
a test is made to determine if the table upon which the current group view element is based carries the foreign key relating it to the current group view element's parent table group. If so, at line 440 the routine AddForeignKey() is called to add the appropriate view elements to the current group view element.
the loop beginning at line 480 examines each of the children of the current model object, in turn.
a test is made to determine if the child of the current model object (current child object) is a link. If the current child object is a link, at line 530 the schema is consulted to determine if a table has been generated for the current child object. At this point, if a table has been generated it will necessarily be an intersection table.
Intersection tables are considered to be based on both link objects related to the table, i.e., the contents of the table will be reviewed from either side of the link. If an intersection table is not found, at line 550 the schema is consulted to obtain the table generated for the child's referenced semantic object.
a new group view element is created at line 560 based on the current child object (pChild) having a parent specified as the current group view element (this) and associated with the table in the schema pointed to by pTable.
a pointer to the newly created group view element is added to the contents member of the current group view element.
a call is made to this routine on the newly created group view element with the current child model object (pChild) and the schema of the object model as parameters.
a test is made to determine if the table associated with the current group view element contains a foreign key representing the relationship between the current child's referenced semantic object and the table. If so, a routine titled AddForeignKey() is called at line 600 to add the appropriate view elements to the current group view element.
a test is made to determine if the current child object is multi-valued. If so, a new group view element is created at line 650 based on the current child object (pChild) whose parent is the current group view element (this) and associated with the table pointed to by the parameter returned from the schema by Lookup(pChild). At line 660, the newly created group view element is added to the contents member variable of the current group view element. At line 670, a call is made to this routine on the newly created group view element with the current child model object (pChild) and the schema of the object model as parameters.
a test is made to determine if the current child object is a group. In this case, it must be a single-valued group. If so, a test is made at line 720 to determine if a group view element already exists in the current group view element that is based on the current child object. If not, a new group view element is created based on the current child object and having a parent that is specified as the current group view element. At line 750, a pointer to the newly created group view element is added to the contents member variable of the current group view element. A call is then made to this routine on the newly created or preexisting group view element with the current child model object (pChild) and the schema of the object model as parameters, as indicated at line 770.
pChild current child model object
a test is made to determine if the current group view element already contains a view element based on the current child object. If not, at line 820 a new view element is created based on the current child object having a parent specified as the current group view element and associated with a column in the table associated with the current group view element that is based on the current child object, i.e., returned by Table() ⁇ Lookup(pChild). At line 830, the newly created view element is added to the contents member of the current group view element. Line 850 concludes the loop that was started at line 480.
Lines 860-910 take into account view elements that represent data columns in the table generated by a multi-valued simple value model component. Specifically, at line 860 a test is made to determine if the current model object is neither a group nor a link, and if the current group view element is a table group. If all of these conditions are present, a new view element is created at line 890 based on the current model object (pModelObj) and associated with a column in the table associated with the current group view element that is based on the current model object, i.e., returned by Table() ⁇ Lookup(pModelObj). At line 900, a pointer to the newly created view element is added to the contents member variable of the current group view element. The routine then terminates.
LISTING L15 illustrates an exemplary routine in accordance with the invention that creates and returns a group view element based on the model object that contains the model object specified by pTargetModelObject.
pTargetModelObject is declared that points to a current model object in an object model that contains a target model object.
theSchema is declared and will be used to provide information about the relational database schema generated for the current object model.
a variable pNextModelObj is declared and initialized to the model object which contains the target model object.
a pointer variable pNextGVE is declared.
a test is made to determine if the model object containing the target model object is the base object of the current group view element. If so, a pointer to the current group view element is returned. Lines 110-120 will repeat until the model object pointed to by pNextModelObj is directly contained within the model object upon which the current group view element is based.
a test is made to determine if the schema contains a table based on the model object pointed to by pNextModelObj.
a new group view element is created based on the model object pointed to by pNextModelObj having a parent specified as the current group view element and associated with the table pointed to by pTable.
the function AddPrimaryKey is invoked on the new group view element.
the routine AddForeignKey() is called on the new group view element.
the else determination at 190 will be reached if there was not a table generated for the model object pointed to by pNextModelObj.
a new group view element is created based on pNextModelObj with the parent specified as the current group view element.
the group view element pointed to by pNextGVE is added to the contents list of the current group view element.
a test is made to determine if the target model object is directly contained within the model object upon which the current group view element is based. If not, this routine is called on the group view element pointed to by pNextGVE, and the result is assigned to pNextGVE.
the current value of pNextGVE is returned.
LISTING L16 illustrates an exemplary routine for creating primary key view elements associated with a table and adding them to the table group view element.
a variable pPK is declared and initialized to a pointer to a primary key data column of the table associated with the current group view element.
Primary keys may or may not have model objects associated with them, depending upon whether or not surrogate keys are generated for the table. If surrogate keys have been generated for a table, no model object is associated with the table's primary key.
pModelObj is declared.
a pointer to a view element entitled pVE is declared.
a test is made to determine if there is a model object associated with the primary key of the table. If so, a pointer to the model object is assigned to pModelObj and a block defined by lines 80-170 is executed.
a test is made to determine if the model object is a group. If so, at line 110, a new group view element is constructed based on the group model object, with a parent specified as the current group view element, and associated with the (group) data column object pointed to by pPK; a pointer to the new group view element is assigned to pVE.
a suitable constructor for accomplishing this task is set forth in LISTING LI 9, and described in the accompanying text.
model object is not a group
a new view element is created based on the model object with a parent specified as the current group view element and associated with the (simple) data column object pointed to by pPK, as indicated at line 150.
a suitable constructor for accomplishing this task is set forth in LISTING L8, and described in the accompanying text.
a new view element is created with the parent specified as the current group view element and associated with the primary key pPK.
a suitable constructor for performing this task is illustrated in LISTING LI 8, and described in the accompanying text.
a pointer to the newly created view element is added to the contents variable, which is a member variable of the current group view element. The routine then terminates.
LISTING LI 7 illustrates an exemplary routine for adding view elements which represent the foreign key between the current group view element and the group view element specified by a parameter entitled pReferencedGroup.
the object giving rise to the relationship is specified by the variable pLink.
the table associated with the current group view element is consulted to obtain the foreign key columns representing the relationship specified by pLink; and a pointer to this data column is assigned to pFK.
a test is made to determine if the foreign key data column is a group data column. If it is, a new group view element is created based on pLink with a parent specified as the current group view element and associated with the data column specified by the variable pFK. The address of this new group view element is assigned to pVE. If the foreign key represents a single data column, a new view element is created based on pLink with a parent specified as the current group view element and associated with the data column specified by the variable pFK, as indicated at line 150.
a routine called SetKeyPair is invoked on the newly created view element to initialize the key pair member variable(s) of the view element or group view element.
Suitable routines for performing this task are illustrated in LISTINGS L20 and L21, and described in the accompanying text.
the routine AddRelatedTable is invoked on the current group view element to remember that the current group view element has a relationship to the referenced group view element and that the foreign key for this relationship is pVE.
a suitable routing for performing this task is illustrated in LISTING L23, and described in the accompanying text.
the same function is invoked on the referenced group view element to inform it of its relationship with the current group view element.
LISTINGL18 illustrates an exemplary routine for constructing a view element not based on a model object, but associated with a data column object.
Lines 50-290 initialize member variables for the view element class.
the member variables are initialized to either constant or values supplied by the column object, as shown.
the member variable parentTableGroup is initialized to point to the current view element's containing group view element if the containing group view element is a table, or to the containing group view element's parentTableGroup if it is not.
the routine then terminates.
LISTING LI 9 illustrates an exemplary routine for creating a group view element based on a model object and associated with a group data column.
the constructor for the base view element class is invoked.
a suitable routine for performing this task is shown in LISTING L8, and described in the accompanying text.
member variables of the group view element class are initialized to appropriate constant values.
the member variable "role" is set to indicate that this group view element represents a group of columns, as opposed to a table.
Lines 180-250 set member variables to values supplied by the parameters as shown.
an iterator "iter” is defined and initialized to the columns within the supplied group data column.
a pointer to a data column entitled pFKPart is declared.
a pointer to a view element entitled pVE is declared.
the variable pFKPart is assigned to each of the columns determined by iter, in turn.
a test is made to determine if the current group view element is associated with a primary key.
a new view element is created based on the model object which caused the data column pointed to by pFKPart to be generated, having a parent specified as the current group view element and associated with the data column pointed to by pFKPart. If the current group view element is not associated with a primary key, it must represent a foreign key. Accordingly, at line 370, a new view element is created having a parent specified as the current group view element and associated with the data column pointed to by pFKPart. In either case, at line 390 a pointer to the newly created view element is added to the contents member variable of the current group view element. The routine then terminates.
LISTING L20 illustrates an exemplary routine for setting the keyPair member variable of a view element. This routine is called by the AddForeignKey() routine of LISTING L17. At line 60, the supplied group view element is consulted to determine a pointer to the view element it contains which is associated with the primary key column referenced by the foreign key column associated with the current view element. A suitable routine for performing this task is illustrated in LISTING L22. The routine then terminates.
LISTING L21 illustrates an exemplary routine for setting the key pair member variable of a group view element.
the base class version of this routine (LISTING L20) is called on the current group view element.
the variable pVE is assigned as a pointer to each view element contained by the current group view element, in turn.
this routine is invoked on the view element pointed to by pVE. The routine then terminates.
LISTING L22 illustrates an exemplary routine for returning a view element based on a particular column definition.
the variable pVE is assigned as a pointer to each view element contained in the current group view element, in turn.
a test is made to determine if the view element currently pointed to by pVE is associated with the data column supplied as the parameter. If so, the loop terminates.
the current value of the variable is pVE is returned, indicating the desired view element, and the routine terminates.
LISTING L23 illustrates an exemplary routine for setting member variables to remember the existence of a relationship between the current group view element and the supplied group view element and the foreign key view element which carries the relationship.
the related group view element is added to the member variable relatedTables (an unordered collection of pointers to related table group view elements).
the pointer to the foreign key view element is entered into the group view element's foreignKeys hash table, using the related group as the hash key.
LISTING L24 is an exemplary routine for determining if a group view element contains a view element based on a given model object and returning it.
a variable "iter" is declared and initialized from the contents member of the current group view element.
a variable pVE is declared. In the loop bounded by lines 80-120, the variable pVE is set to point at each view element contained by the current group view element, in turn.
a test is made to determine if the current child group view element is based on the given model object. If so, the loop terminates.
the current value of the variable pVE is returned.
LISTTNGL25 is an exemplary routine for determining if a group view element contains another group view element that is based on a given model object and returning it.
a variable "iter" is declared and initialized from the contents member of the current group view element.
a variable pVE is declared. In the loop bounded by lines 80-120, the variable pVE is set to point at each view element contained by the current group view element, in turn.
a test is made to determine if the current child view element is a group and if the current child group view element is based on the given model object. If so, the loop terminates.
the current value of the variable pVE is returned. If the loop bounded by lines 80-120 was terminated at line 110, the variable pVE will be non-NULL. In this case, the value returned at line 130 is a pointer to the desired child group view element. Otherwise, the value returned will be NULL, indicating that no child group view element was found.
LISTINGS L26-L30 are exemplary pseudocode routines for constructing view elements and group view elements that will be invoked by the routine described in LISTING L32.
the block defined by lines 60-260 show initializers for data members of the view element class. In essence, each data member is initialized to one of the following: a constant value, a value supplied by the base view object, a value supplied by the base view object's base model object, or a value supplied by the data column definition.
the member variable parentTableGroup is initialized to point to the current view element's containing group view element if it is a table, or to the containing group view element's parentTableGroup if it is not.
a test is made to determine if the parent table group is based on the same model component that the object being constructed (this object) is based on. If so, this view element must represent the data column for a multi-valued simple value component. The design tool does not allow NULL values for such columns, and thus the minimum cardinality for the current view element is set to one. The routine then terminates.
LISTING 27 is a pseudocode constructor that will be invoked by the routine illustrated in LISTING L28. Specifically, the constructor initializes the data members listed in lines 60-240 to constant values, to values obtained from the supplied view object or its base model object, or from a table in the schema. At lines 260-280, the member variable parentTableGroup is initialized to point to the current view element's containing group view element if the containing group view element is a table, or to the containing group view element's parent table group if it is not. The routine then terminates.
LISTING L28 illustrates an exemplary pseudocode routine for initializing (constructing) a group view element that is associated with a table in the schema. Specifically, at line 60 the constructor of LISTING L27 is invoked to initialize the base view element class portion of the current group view element. The block bounded by lines 70-150 initialize member variables of the group view element object to default or supplied values.
a test is made to determine if the current group view element has no parent or if the view component that this view element is based on is a link. If so, at line 190, the member variable "role" is set to indicate that the associated table was generated from a semantic object.
a test is made to determine if the current group view element has a parent. If the current group view element does have a parent, it must represent a link. In this case, the data members listed in lines 220-270 are initialized with values obtained from the base model component or its base model component.
a block defined by lines 300-450 is entered if the base model object of the base view object of the current group view element is a multi- valued group or simple valued component. In this case, at line 320 the role is set to indicate that.
a test is made to determine if the base view object's base model object is a group. If so, the data members listed at line 350-380 are initialized to values from the base view object or its model object. If the current group view element is based on a multi-valued simple value, the data members listed in lines 420-430 are initialized as shown. The routine then terminates.
LISTING L29 illustrates an exemplary constructor invoked by the routine of
LISTING L30 takes into account single-valued groups. Specifically, the constructor initializes the data members listed in lines 50-220 to constant values, or to values obtained from the supplied view object or its base model object. At lines 240-260, the member variable parentTableGroup is initialized to point to the current view element's containing group view element if it is a table, or to the containing group view element's parent table group if it is not. The routine then terminates.
LISTING L30 illustrates a pseudocode routine for initializing a single-valued group view element.
line 50 invokes the view element constructor of LISTING L29.
Lines 60-140 list data members which are initialized to constant values or values obtained from the supplied view object or its base model component.
the member variable role is set to indicate that this group view element represents a single-valued group. The routine then terminates.
LISTING L31 illustrates an exemplary routine for creating a set of form run-time views associated with a particular object model.
a parameter "theModel” is declared which references an object model for which run-time views are to be created.
a variable "iter” is initialized from the model as an iterator on the collection of all object views in the model.
Lines 60-70 declare variables used in the iteration.
Line 80 declares and initializes a reference to the schema associated with the object model.
the variable pView will be set to a pointer to each object view in the object model, in turn.
a new group view element is created based on the object view pointed to by pView with a parent specified as NULL and associated with the table pointed to by the parameter returned from "theSchema.Lookup(pView-» BaseObj())," which looks up the base semantic object of the object view in the schema and returns a pointer to a table object representing a database table generated from the given semantic object.
the routine DefineRuntimeView is invoked with a pointer to the current view object and the schema as parameters. This routine is described next.
LISTING L32 illustrates an exemplary routine for creating form run-time views in accordance with the invention.
form run-time views are created by combining information about an object model with the information contained in an object view hierarchy.
Each form and each report will have an associated form run-time view.
a parameter called pViewObj is declared that points to a "current" view object in an object view hierarchy that has been constructed for a semantic object in an object model.
pViewObj will point to a root view object.
Subsequent (recursive) calls will address view objects contained within the object view hierarchy.
a parameter called "theSchema" is declared and will be used to provide information about the relational database schema generated for the current object model.
Lines 60-100 define local variables "iter,” pChild, pVE, pGVE, and pTable that the routine will use.
the variable iter will be used to iterate across the contents of the current model object.
pChild pChild
pVE pGVE
pTable pTable
a test is made to determine if the current group view element is associated with a table in the schema. If the current group element is associated with a table in the schema, a routine titled "AddPrimaryKey" is called at line 130 to add a view element representing the primary key of the table to the current group view element.
a test is made to determine if the table associated with the current group view element is an intersection table. If so, the schema is consulted to determine a pointer that will point to a table generated from the current view object's referenced semantic object at line 160.
a new group view element is created based on the current view object (pViewObj) having a parent specified as the current group view element (this) and associated with the table pointed to by pTable.
a pointer to the newly created group view element is added to the contents variable, which is a member variable of the current group view element.
a call is made to this routine on the newly created group view element with the current view object (pViewObj) and the schema of the object model as parameters.
a routine titled "AddForeignKey” is called to add a view element representing the foreign key between the intersection table and the semantic object table generated from the view object's base model object's referenced semantic object.
a view element representing the foreign key between the intersection table and the intersection table's parent table group is added to the current group view element.
the routine terminates.
a test is made to determine if the current group view element is contained within another group view element.
a test is made to determine if the table associated with the current group view element was generated from a semantic object. If the current group view element is contained within another group view element and if the table associated with the current group view element was generated from a semantic object, at line 290 a local variable called pPairObj is declared as a pointer a model object and initialized to the current view object's base model object's pair object.
pSO is declared as a pointer to a model object and initialized to the current view object's base model object's referenced semantic object.
a variable called pLinkParent is declared as a pointer to a group view element and is initialized to the current group view element.
a test is made to determine if the current view object's base model object's referenced semantic object directly contains the current view object's base model object's pair object. If it does not, a function titled CreateParentGroup is called to create and return a pointer to a group view object based on the model object that does contain the current model object's pair, at line 340. An exemplary routine for performing this function is set forth in FIGURE L 15.
a test is made to determine if the table associated with the model object based on the container of the current view object's base model object's pair contains the foreign key that carries the relationship represented by the current view object's base model object and its pair. If so, the routine AddForeignKey() is called to add the appropriate view elements to the group view element based on the container of the current view object's base model object's pair.
the loop beginning at line 500 examines each of the children of the current view object, in turn.
a test is made to determine if the child of the current view object (current child object) is a link. If the current child object is a link, at line 550 the schema is consulted to determine if a table has been generated for the current child object. At this point, if a table has been generated it will necessarily be an intersection table. Intersection tables are considered to be based on both link objects related to the table, i.e., the contents of the table will be reviewed from either side of the link. If an intersection table is not found, at line 570 the schema is consulted to obtain the table generated for the child's referenced semantic object.
a new group view element is created at line 580 based on the current child object (pChild) having a parent specified as the current group view element (this) and associated with the table in the schema pointed to by pTable.
a pointer to the newly created group view element is added to the contents member of the current group view element.
a call is made to this routine on the newly created group view element with the current view object (pViewObj) and the schema of the object model as parameters.
a test is made to determine if the table associated with the current group view element contains a foreign key representing the relationship between the current child's referenced semantic object and the table. If so, a routine titled AddForeignKey() is called at line 620 to add the appropriate view elements to the current group view element.
a test is made to determine if the current child object is multi-valued. If so, a new group view element is created at line 670 based on the current child object (pChild) whose parent is the current group view element (this) and associated with the table pointed to by the table returned by the schema from Lookup(pChild). At line 690, the newly created group view element is added to the contents member variable of the current group view element. At line 700, a call is made to this routine on the newly created group view element with the current child view object (pChild) and the schema of the object model as parameters.
a test is made to determine if the current child object is a group. In this case, it must be a single-valued group. If so, a test is made at line 750 to determine if a group view element already exists in the current group view element that is based on the current child object. If so, at line 770, a routine called Configure() is invoked on the preeexisting group view element to ensure that its member variables are set appropriately. A suitable routine for performing this task is shown in LISTING L34 and described in the accompanying text. If no group view element based on the current child object was found, a new group view element is created based on the current child object and having a parent that is specified as the current group view element, shown at line 810.
a pointer to the newly created group view element is added to the contents member variable of the current group view element.
a test is made to determine if the current group view element already contains a view element based on the current child object. If so, at line 890, a routine called Configure() is invoked on the preeexisting view element to ensure that its member variables are set appropriately.
a suitable routine for performing this task is shown in LISTING L33 and described in the accompanying text.
a new view element is created based on the current child view object having a parent specified as the current group view element and associated with the column in the table of its parent view element that is based on the model object on which the current child object is based, i.e., returned by Table() ⁇ Lookup(pChild ⁇ BaseObj0).
the newly created view element is added to the contents member of the current group view element.
Line 970 concludes the while loop that was started at line 500.
Lines 980-1030 take into account view elements that represent data columns in the table generated by a multi-valued simple value model component. Specifically, at line 980 a test is made to determine if the current view object is neither a group nor a link, and if the current group view element is a table group.
a new view element is created at line 1010 based on the current view object (pViewObj) and associated with the column in the table associated with the current group view element that is based on the model object on which the current view object is based, i.e., returned by Table0 ⁇ Lookup(pViewObj ⁇ BaseObj())-
a pointer to the newly created view element is added to the contents member variable of the current group view element. The routine then terminates.
LISTING L33 illustrates an exemplary routine for performing initialization steps that are necessary for view elements in a form run-time view, and not performed when view elements are constructed solely from model components. Constructing view elements solely from model components occurs during the creation of a form run-time view when AddPrimaryKey() is called for a table defined as using a model object as the primary key (i.e., having a 'data key').
AddPrimaryKey() is called for a table defined as using a model object as the primary key (i.e., having a 'data key').
the variable viewObjID is set to the object ID of the specified view object.
the allowed action for the current view element is set based on the allowed action specified by the supplied view object. The routine then terminates.
LISTING L34 illustrates an exemplary routine for performing initialization steps that are necessary for group view elements in a form run-time view, and not performed when group view elements are constructed solely from model components.
the base class version of this routine is called with pViewObj as a parameter (LISTING L33).
the DeleteAllowed and NewAllowed flags are set, respectively, as specified by the base view object. The routine then terminates.
LISTING L35 is an exemplary routine for determining if a group view element contains a view element based on a given view object and returning it.
a variable "iter" is declared and initialized from the contents member of the current group view element.
a variable pVE is declared. In the loop bounded by lines 80-130, the variable pVE is set to point at each view element contained by the current group view element, in turn.
a test is made to determine if the current child group view element is based on the given model object or on the given view object's base model object. If so, the loop terminates.
the current value of the variable pVE is returned.
variable pVE will be non-NULL.
the value returned by the routine at line 140 is a pointer to the desired child view element. Otherwise, the value returned will be NULL, indicating that no child view element was found.
LISTING L36 is an exemplary routine for determining if a group view element contains another group view element that is based on a given model object and returning it.
a variable "iter" is declared and initialized from the contents member of the current group view element.
a variable pVE is declared. In the loop bounded by lines 80-160, the variable pVE is set to point at each view element contained by the current group view element, in turn.
a test is made to determine if the current child view element is a group and if the current child group view element is based on the given view object or its base model object. If so, the loop terminates.
the current value of the variable pVE is returned.
variable pVE will be non-NULL.
the value returned at line 170 is a pointer to the desired child group view element. Otherwise, the value returned will be NULL, indicating that no child group view element was found.
FIGURE 23 illustrates an exemplary user interface in the form of a state diagram for storing and retrieving data to and from a relational database using the custom application 51.
operations fundamental operations include: inserting a record, deleting a record, updating a record, and query operations, i.e., asking the database to return one or more records that match a search.
a user may begin by selecting a form that has been created by the design tool for a semantic object in the object model, as indicated by reference numeral 910.
the user may invoke an appropriate command to exit the routine, and hence the custom application, as indicated by reference numeral 912.
a form it will be displayed with blanks in each of the form's fields, as indicated at state 914.
a user may enter data and the data will be displayed on the form (event 916); invoke an insert command (event 918), clear the form (event 920); or exit the routine (event 922).
an insert routine is called by the custom application, as shown at state 924.
a suitable routine for inserting a record into the database using a run-time view is set forth in LISTING L41, and described in the accompanying text.
the custom application Upon return from the insert routine, the custom application will display an error message if the insert failed, shown at state 926, and return to state 914, where the form and data, if any, that has previously been entered is displayed. If the insert succeeded, the data is written to the database and the form is cleared and redisplayed, as indicated by state 928. This state will also be reached if the user invokes a "clear form" command at state 914.
the custom application remains at state 914 until a command is entered by the user. If a query command is entered while at state 914, a query routine is called by the custom application to perform the database search, as shown at state 924.
a suitable routine for querying data from the database using a run-time view is illustrated in LISTING 46, and described in the accompanying text.
the query routine will return one of three parameters that are used by the custom application to display the appropriate information to the user. First, if no records were located in the query, the custom application will display a message to the user indicating this, as shown at state 932, and will then return to state 914, where the form and query information are redisplayed. Second, if a single record is found, this record will displayed in the form, as indicated at state 934. Finally, if multiple records are found, the custom application will display a listing of all the records, as indicated at state 935.
the user has the option of selecting a record from the list. Assuming a record is selected, the selected record will be displayed in the form, as indicated at state 934. At this point, the user may perform the following operations: (1) change the contents of the record by entering data (event 936); (2) clear the form without affecting the stored record, wherein the custom application will clear the form at state 928, and then display a blank form, at state 914; (3) update the record by entering text and then invoking an "update" command (event 940); (4) delete the record (event 942); or (5) exit the custom application (event 944).
an update routine is called by the custom application, as shown at state 946.
a suitable routine for updating a record in the database using a run-time view is shown in LISTING L37, and described in the accompanying text. If, after calling the routine, the update was successful, the custom application returns to state 928 where the form is cleared, and then to state 914 where the blank form is displayed. If the update did not succeed, i.e., data inappropriate for that record was entered, an error message is displayed to the user, as indicated at state 948. Once the user acknowledges the message, the custom application returns to state 934, where the record, along with the update information, is redisplayed in the form.
a delete command is entered while at state 934, the custom application will call a delete routine to remove the record from the database, as shown at state 942.
a suitable routine for a deleting record from the database is shown in LISTING L43, and described in the accompanying text. If the delete was successful, the form is cleared by the custom application at sate 928, and the blank form displayed to the user, at state 914. Otherwise, the delete has failed, and an appropriate message is displayed to the user, as indicated at state 950.
a delete record command would fail, for example, if this was the last record for a semantic object or model component that has a minimum cardinality of one.
the custom application returns to state 934, where the record is redisplayed in the form.
Entry of data involves the specification of values to be entered into the database, i.e., column values, as well as where to put the data, i.e., a table specification and a row specification within that table.
Data retrieval involves the selection of a row or rows to examine (and possibly update), the display of candidate rows to associate with a row in some table via foreign keys, and the display of data already so associated.
a table generated from the base portion of a semantic object (“an SO table”) defines "semantic object instances,” one for each row.
Each semantic object instance represents a single thing in the mind of a user or data modeler who defined the object model.
each row in the table generated from semantic object "order” represents a different order instance. This fits well with common experience, where an order is often represented by a single form.
Multi-valued components within a semantic object may also generate a table; multi-valued object link components are the exception to this rule, as described below.
the model component "line item” is a multi-valued group, and will cause a table to be created to hold data for line items in an order.
Tables generated for multi-valued data components are different from SO tables, in that the rows in these tables do not define semantic object instances. Instead, they contain data which cannot be represented in the single row of the SO table, but which are (logically) just as dependent on the existence of such a row as the columns in the SO table.
Object link components are treated differently because they do not represent data values in the database or the object model. Instead, they represent relationships between semantic objects. These relationships are carried in the usual way (by foreign keys), and since semantic objects always generate a table, object links do not cause another table to be generated if the relationship is one to one or one to many. In these cases, the relationship can be represented by placing the foreign key columns in one of the SO tables. If, however, the relationship is many to many, an intersection table is generated with rows defined as containing pairs of foreign keys, one for each of the related SO tables. Each row in an intersection table is dependent on both of the related object instances; if either instance related to a given intersection table row is deleted or the relationship it represents is disconnected, the intersection table row must be deleted.
Inherent in semantic object modeling is a method of restricting the amount of freedom one has in using a relational database.
the structure added by these restrictions allows the definition of a small set of query operations to cover all semantically valid cases.
the types of queries include: 1) queries defining a set of semantic object instances to be examined using a given object view hierarchy, i.e., for report printing or for display in a form; 2) finding the set of rows in a table related to a particular object instance, e.g., the line items for an order, or information about the customer related to a particular order; 3) queries defining a set of semantic object instances available for connection on a particular relationship. This is different from a type 1 query in that if an object instance is already related to as many other object instances as the maximum cardinality for that relationship, the object will not be returned by a type 3 query.
database systems When working with query results, database systems must provide a mechanism for determining the number of result rows and moving among them, and run-time views are no exception.
the group view elements provide operations for defining and executing queries of all three types defined above, and working with the resulting sets of rows. These operations are equivalent to those provided by conventional cursors, with the addition of semantic object based querying (type 2 and 3 queries - type 1 queries are similar to traditional queries).
View elements can provide access to two different result sets of rows at once, one called a "query result set,” which may not be updated, and one editable set, called the "current" set, which may contain updated or new values, including entire new rows. It is possible to move a row from the query result set to the current set. This is required, for example, if a user desires to make changes to data which has been saved in the database. Positioning in a result set is handled by means of requests to group view elements.
View elements and group view elements with parent group view elements take the current position of the parent group view element into account when returning values or current positions.
Dependent multi-valued group view elements must, in general, maintain the effect of separate cursors for each parent table row position.
Movement in the current result set is defined for all table group view elements; that is group view element's created in association with a database table, i.e., having a role of SO_TABLE (a semantic object table), ATTR_TABLE (a component table), or X_TABLE (an intersection table) in the routines discussed below.
Movement in the query result set (and type 1 & 3 queries) is defined for group view elements with a role of SO_TABLE or X_TABLE.
Type 2 queries return their results sets as current results, as opposed to query results.
the cursor operations that may be performed for a group view element include:
View elements provide access to database column values corresponding to the result sets, and additionally, can provide the original value in the current result set if the column represented by the view element has been updated on the row specified by the parentTableGroup.
Semantic object models generate databases in domain-key normal form, and the procedures given herein maintain the referential integrity of the database without any DBMS support. If the DBMS implements declarative referential integrity constraints, it may be necessary to group several group view element operations into one DBMS transaction. If the DBMS enforces constraints on per-statement basis within a single transaction, it may be necessary to order the statements within a transaction appropriately. Relationships which are mandatory from both sides are a particular case of this; these arise not only from one-to-one object links which are required on both sides, but also from required multi-valued group or simple value components.
the primary conflict is between the natural order of operations on the DBMS and the view elements.
the DBMS wants to have the SO table row inserted first, but the ValidateCountsAndCards() function will return an error if the required dependent multi-valued group view element has no rows.
Alternative implementations of the DoDatabaseA() functions which create SQL statements as strings and execute them as a single batch (after suitable reordering) will be obvious to those skilled in the art.
Surrogate keys are assumed to be supplied by the run-time view programmer, immediately after making a call to NewRow(), thereby adding a row to the 'current' result set and positioning the group view element (GVE) to the new row. If this step is delayed for any reason, suitable modifications to Connect() will be needed to track the need to fill in appropriate values for the foreign keys before (or as) the row containing the foreign key is added to or updated in the database.
DoDatabaseUpdate() and DoDatabaseDelete() show a common form of optimistic locking which checks that none of the data columns read by the current group view element have been changed by another user. Large string, e.g., memo, and binary objects are excluded from this check procedure. If the database can only be accessed by a single user, or records are locked when read from the DBMS, simpler predicates can be used which only reference the primary key of the row to be updated or deleted. The changes needed to do this are obvious.
LISTING L37 illustrates an exemplary routine for saving updated values entered into view elements contained by a table group view element.
the table group view element must be bound to data read from the database before any contained view elements are updated. This routine is called on the table group view element.
a test is made to determine if the current group view element allows only read access. If so, an appropriate error is returned.
a test is made to determine if the current group view element is associated with an intersection table. If so, as a convenience for the programmer writing code which calls this routine, this routine is invoked on the child group view element which is associated with the table generated by the referenced semantic object of the object link on which the current group view element is based (i.e., the call is forwarded to the child table group view element). This is correct because intersection table rows are only added and deleted by the Connect() (LISTING L39) and Disconnect() (LISTING L40), and are never updated. Forwarding the call allows the programmer to treat updates to any multi-valued object link uniformly, without regard for the maximum cardinality of the object link's pair.
the function ValidateCountsAndCards (LISTING L42) is called.
a test is made to determine if an error was returned. If an error was not returned, at line 200 the function DoDatabaseUpdate is called to generate and execute appropriate SQL statements to perform the update.
a suitable routine for performing this task is illustrated in LISTING L66, and described in the accompanying text.
an indication of the success or failure of this routine is returned. The routine then terminates.
LISTING L38 illustrates an exemplary routine for determining the group view element contained by an intersection table associated with a semantic object table.
the loop bounded by the lines 70-110 assigns the variable pFK as a pointer to each foreign key carrying a relationship between this group view element and another group view element (the iterator fkIter returns only the values in the foreignKeys hash table; it does not return the keys themselves).
a test is made to determine if the current group view element is the table group which contains the table group associated with the key pair of the current foreign key (the grandparent table of the current foreign key's key pair). If so, the variable pGVE is set to the current foreign key's key pair's parent table group, shown at line 100. This will cause the loop to terminate.
a pointer to the desired group view element is returned, and the routine terminates.
LISTING L39 illustrates an exemplary routine for establishing a relationship between two semantic object instances.
this routine connects the current instance of a group view element to its parent table group. More specifically, the current instance is defined as an instance that is in the current buffers, i.e., a newly created instance or an instance that was returned from a query. If the current instance is defined from a group of instances returned from a query, the routine will be invoked on the instance that is currently highlighted.
the parameter fUseQuery determines whether the connection is from a current instance stemming from the data located in the current buffers or from a query, and is declared at line 30.
a variable pFK is declared and assigned a pointer to the foreign key relating the current group view element to its parent table group.
a test is made to determine if the current group view element represents an intersection table. If so, a test is made to determine if the request is to connect to a queried result, as indicated at line 90. If the current request is not specified as connecting to a query, a suitable error is returned at line 100. This is because intersection tables are not represented in the object model, and therefore are not represented on forms as such. In other words, a user cannot connect to a new row of an intersection table because there is no user specified data in an intersection table row.
a function entitled NewRow is called to create a new row in the current data buffer and make it the current row of this group view element.
a routine for doing this is not set forth herein, but will be apparent to those skilled in the art.
a routine entitled CopyKey is called on the foreign key view element to cause it to copy the primary key value of the parent table group to the current row.
this routine is invoked on the intersection table child semantic object table group view element. This will cause the foreign key connecting this group view element to be placed in the child semantic object table group view element.
a routine entitled DoDatabaseInsert is called to add the current row to the database.
a suitable routine for performing this task is described in LISTING L71, and described in the accompanying text.
the block defined by lines 160-290 is executed. Specifically, at line 180, a test is made to determine that the specified object instance is available for connection. A connection is available if the foreign key view elements are NULL. If not, an appropriate error is returned at line 210 indicating to the programmer that an error has occurred.
a test is made to determine if a connection is to the current instance of the query result set of the current group view element. If so, at line 250, a new row is allocated by calling an appropriate routine. At line 260, the current instance of the query result set is copied to this new row. At line 280, a routine entitled CopyKey is called on the foreign key view element, causing it to set its value from the value of its key pair, i.e., the appropriate primary key value(s). At line 300, an indication of the success or failure of this routine is returned. The routine then terminates.
LISTING L40 Illustrates an exemplary routine for removing a relationship between two semantic object instances.
this routine disconnects the current instance of a group view element from its parent table group's current instance. For example, if a user wishes to delete an order that is associated with a particular customer, the Disconnect routine will be called to break that association. In deleting the order on an order form, the routine would be invoked on the customer group view element. Connections (associations) between semantic objects can also be broken as a result of a user command to clear (disconnect) the link, or as a preliminary step in changing connected instances (e.g., if an order instance was connected to the wrong customer instance, the existing link must be cleared before a new connection is made).
a test is made to determine if the object link pair of the model object upon which the current group view element is based has a non-zero minimum cardinality. If so, an error will be returned at line 100 if the minimum cardinality is one, or if removing the connection to this instance will violate the specified minimum cardinality of the object link pair. For example, if a customer must have at least one order, and this deletion would eliminate the customer's last order, a suitable error will be returned.
a test is made to determine if the current group view element represents an intersection table. If the current group view element does represent an intersection table, the table will contain only foreign key columns, all of which are to be set to NULL as a result of this operation. As will be appreciated by those skilled in the art, this would result in a blank row, which is undesirable. Thus, the entire row is deleted, as shown at line 160. If the current group view element does not represent an intersection table, a pointer to the view element representing the foreign key connecting the two tables is obtained by using the parent table group as a hash key in the "foreignKeys" hash table and assigning the result to the variable pFK. This is shown at line 200.
view elements representing the foreign key are set to NULL, thereby breaking the relationship.
an indication of the success or failure of this routine is returned. This operation is not final until sent down to the database using the update routine shown in LISTING L37.
LISTING L41 illustrates an exemplary routine for inserting a row into a relational database table corresponding to an instance of a semantic object or a multi- valued group in the object model.
a test is made to determine if the current group view element represents an intersection table.
rows in an intersection table represent a many-to-many relationship between two semantic objects and are created and deleted using the routines Connect and Disconnect, respectively, shown in LISTINGS L39 and L40, and discussed above.
a view element is minimally complete if it contains view elements for all the required simple value components and links in the group component or semantic object upon which it is ultimately based. For example, assume an order must have a customer. If a user is reviewing an order form which does not contain view elements for a customer, it is not possible to create an order instance from that form. An associated customer is required. Other examples in which permission to insert is denied include: where the "add permission" has been set to false in a form, or where the current form is opened using an open form action where "allow new" has been set to false.
a routine called ValidateCountsAndCards is called to validate the count of the current group view element and the cardinalities of all the view elements it contains.
AN exemplary routine for performing this task is illustrated in LISTING L42.
a test is made to determine if an error indication has been returned by the ValidateCountsAndCards routine. If not, a test is made at line 140 to determine if the current group view element has a parent and does not represent a link, i.e., it is not a semantic object table. In essence, this check will look to see if the current group view element is based on a multi-valued group or simple value component. If these conditions are met, a routine is invoked to connect this group view element's instance with its parent table group.
a suitable routine for performing this task is the Connect routine in LISTING L39.
a test is made to determine if an error has occurred. If no error has occurred, a routine entitled DoDatabaselnsert is called at line 190. A suitable routine for performing this task is set forth in FIGURE L32, and described in the accompanying text. At line 210, an indication of the success or failure of the routine is returned to the caller.
LISTING L42 illustrates an exemplary routine for validating the count of a current group view element and the cardinalities of all the view elements it contains.
this routine will look to the contents of the current group view element to see if the cardinality of each view element is satisfied (lines 90-490) and that the counting constraints on the current group are satisfied (lines 500-630).
a while loop begins in which the view elements contained by the current group view element are returned by iter and assigned to the variable pVE.
a test is made to determine if the current child view element is multi-valued, i.e., has a maximum cardinality greater than one. If so, a local variable count is declared and initialized to the number of rows in the set associated with the current child view element, as indicated at line 130.
a test is made to determine if this count is greater than the maximum cardinality for the current group view element. If the maximum cardinality has been exceeded, an error indication is set at line 160 to indicate to the calling routine, and ultimately to the user, that the maximum cardinality has been exceeded.
a test is made to determine if the count is less than the minimum cardinality for the current child view element. If so, an error indication is set at line 210 to indicate to the calling routine, and ultimately to the user, that the minimum cardinality requirements have not been met.
a test is made to determine if the count is non-zero. If so, one is added to the number of non-NULL view elements contained in the current group view element. To reach line 270, the current child view element must be single-valued.
a test is made to determine if the child view element is NULL.
a test is made to determine if the current child view element has a minimum cardinality greater than zero. If both conditions are met, an error is set at line 330 to indicate to the calling routine, and ultimately to the user, that a required item is missing from the current group view element.
a test is made to determine if the current child view element is associated with an object in the object model. If so, at line 400 one is added to the number of non-NULL view elements contained in the current group view element.
a test is made to determine if the current child view element is a single-valued group view element. If so, this routine is called on the current child view element.
a test is made to determine if the non-NULL count is not equal to the maximum count (shown at line 520). If the non-NULL count is equal to the maximum count, there is no error, and the routine returns. Otherwise, a test is made at line 540 to determine if the non-NULL count is greater than the maximum count. If so, an error indication is recorded to this effect at line 480. At line 580, a test is made to determine if the non-NULL count is less than the minimum count. If it is, an error indication to this effect is recorded at line 600. At line 640, an indication of the success or failure of this routine is returned.
LISTING L43 illustrates an exemplary routine for deleting a row from a relational database table corresponding to an instance of a semantic object or a multi-valued group in the object model.
the variable "err" is initialized to SUCCESS, which is defined as zero.
SUCCESS which is defined as zero.
a test is made to determine if the current group view element is not an intersection table. If it is not an intersection table, the variable iter is declared and initialized to a collection of group view elements called relatedTables.
variable relatedTables is a member variable of the current group view element and defines group view elements that have a direct relationship with the table on which the current group view element is based, i.e., the table on which the current group view element is based has a foreign key to a related table, or the related table has a foreign key of the table on which the current group view element is based.
a local variable pGVE is declared.
a test is made to determine if the current related group view element is a link. If so, a routine titled DisconnectAll is called on the related group view element to disconnect all of the instances represented by it from the current row of the current table. A suitable routine for performing this task is illustrated in LISTING L44. As an example, when an order is deleted, it needs to disconnect from its associated customer. Otherwise, at line 150, a test is made to determine if the current related group view element is the current group view element's parent table group.
a routine entitled DeleteAll is called on the current related group view element to delete all related instances of the current group view element, as indicated at line 170.
a routine entitled DeleteAll is called on the current related group view element to delete all related instances of the current group view element, as indicated at line 170.
all the line items related to that order must also be deleted.
An exemplary routine for performing this task is set forth in LISTING L45, and described in the accompanying text.
a test is made to determine if an error has occurred. If so, the while loop is terminated. This concludes the loop defined by lines 90-210.
a test is made to determine that no error has yet occurred. If an error has not yet occurred, a routine entitled DoDatabaseDelete is called at line 240 to delete the current row in the database corresponding to the current instance of this group view element.
a routine entitled DoDatabaseDelete is called at line 240 to delete the current row in the database corresponding to the current instance of this group view element.
an indication of the success or failure of this routine is returned.
LISTINGL44 illustrates a suitable routine for disconnecting instances of a semantic object related to the current table.
the variable "err" is set to the result of a function call to "First," which positions the cursor represented by the current group view element to the first row in its set.
the loop bounded by lines 60-110 will continue until the variable err becomes non-zero. Specifically, at line 80, a routine entitled Disconnect is called to disconnect the current instance of this group view element from its parent table group. At line 90, a test is made to determine if the disconnect was successful. If so, the variable err is set to the result of moving the cursor represented by the current group view element to the next row. This concludes the loop bounded by lines 60-110.
a test is made to determine if the current value of err indicates that all the rows in the cursor represented by the current group view element have been examined. In the test is positive, either there were no rows or all the rows were successfully disconnected. Thus, at line 140 the variable err is set to indicate this routine was successful. At line 160, an indication of the success or failure of this routine is returned.
LISTING L45 is an exemplary routine for deleting all the object instances in the set represented by a group view element.
the variable "err” is set to the result of a function call to "First,” which positions the cursor represented by the current group view element to the first row in its set.
variable err becomes non-zero. Specifically, at line 80 a function entitled Delete is called to delete the current row in the table represented by the current group view element. At line 90, a test is made to determine if the deletion was successful. If so, the variable err is set to the result of moving the cursor represented by the current group view element to the next row.
a test is made to determine if the current value of err indicates that all the rows in the cursor represented by the current group view element have been examined. In the test is positive, either there were no rows or all the rows were successfully deleted. Thus, at line 140 the variable err is set to indicate this routine was successful. At line 160, an indication of the success or failure of this routine is returned.
LISTING L46 illustrates an exemplary routine for performing a query on a relational database using a group view element.
every view element may have a predicate string associated with it. This permits a user of the query routine to construct a database predicate without direct reference to database column or table names.
a parameter entitled newPredicate is declared, which will replace the current predicate on the current group view element, if the new predicate is not NULL.
a parameter entitled fUseConnectPower is declared, which if true (non-zero) indicates a type 1 query is desired, and if false (zero) a type 3 query is desired. Query types 1-3 were described above in pages 78-79 of the detailed description.
a test is made to determine if the current group view element represents an intersection table. If so, this routine is invoked on the child semantic object table of this intersection table, as indicated at line 240. At line 250, an indication of the success or failure of the call invoked at line 240 is returned. Otherwise, at line 270, a test is made to determine if a new predicate was supplied. If so, the predicate value of the current group view element is replaced with the new predicate, at line 280.
a routine entitled Select is invoked to generate and execute an appropriate SQL query.
a suitable routine for performing this task is set forth in LISTING L48, and described in the accompanying text.
an indication of the success or failure of the routine is returned. This routine then terminates.
LISTING L47 illustrates an exemplary routine for selecting all of the data represented by the current group view element that is related to the current instance of this group view element's parent group view element.
a test is made to determine if the current group view element is single-valued. If so, a suitable error is returned. This is done because in the implementation described tables which have a single-valued relationship to their parent table group are read at the same time as the parent table group. This restriction is possible because the routine Select is always called with the extended read indicator set to true.
a test is made to determine if the current group view element has a parent table group. If it does not, it is a top-level group view element and only type 1 queries should be invoked.
LISTING L48 is an exemplary routine for constructing and executing an SQL string to perform a query.
a predicate is built for the select statement being generated.
a hierarchy of table references (rooted at tableRef) that describes the tables involved in the Select and the join conditions between them is constructed
a function entitled Gather Join is invoked on the root of the TableRef hierarchy, which generates strings containing all of the column names and table names required, as well as the join portion of the predicate to be used. The remainder of the function constructs a SQL string and executes it.
a root TableRef object is declared referencing the current group view element, since the table associated with the current group view element will always be involved in the generated select.
a test is made to determine if the parent constraint flag is specified as true, i.e., this is a type 2 query. If it is, at line 130 a routine entitled ParentlnstancePredicate is called to generate an appropriate predicate string. A suitable routine for performing this task is illustrated in LISTING L49, and described in the accompanying text. Otherwise, at line 170 a test is made to determine if the connect power flag is specified as true, i.e., this is a type 3 query. If so, at line 200 a function entitled ConnectPowerPredicate is called to construct a suitable predicate string. A suitable routine for performing this task is illustrated in LISTING L52, and described in the accompanying text.
a routine entitled DefinePredicateDown is called to traverse the run-time view hierarchy and compose an appropriate predicate string from any predicate strings found in group view elements directly or indirectly contained in the current group view element. This is done for all types of queries.
the Gather Join is called, as previously described.
a SQL command string is constructed from the strings generated above.
a function entitled ExecuteSQLString is called to execute the select on the database. While not shown explicitly, this routine is intended to suggest one of the many ways of executing a SQL string generated by an application program. Similarly, the binding and retrieval of the returned data is not shown, but will be apparent to those skilled in the art.
an indication of the success or failure of this routine is returned. The routine then terminates.
LISTING L49 Illustrates an exemplary routine for defining a predicate string specifying rows of a table associated with a group view element which are related to the parent table group of the group view element by the relationship specified by the current group view element.
a variable pFK is declared and initialized as a pointer to a view element representing the foreign key carrying the relationship between the current group view element and its parent table group.
a variable pFKTableGroup is declared and initialized as a pointer to the group view element associated with a table which contains the foreign key.
a test is made to determine if the foreign key resides in the table associated with the current group view element. If so, a function entitled ParamJoin is invoked on the foreign key view element.
This routine set forth in LISTINGS L50 andL51, generates strings which compare a foreign key column to a primary key value or a primary key column to a foreign key value, depending upon its second parameter. The result is returned in the variable ParentPredicate.
the foreign key does not reside in a table associated with the current group view element, a test is made to determine if it resides in an intersection table, as indicated at line 200.
the variable pFK is assigned as a pointer to the foreign key that relates the intersection table to its parent table group.
the routine ParamJoin is invoked on the foreign key to produce a predicate which relates rows of the intersection table to the table associated with its parent table group.
a routine entitled SubQueryStr described in LISTING L54, is invoked to generate a sub-query specifying appropriate rows of the intersection table.
variable parentPredicate is assigned a string defining a predicate which evaluates to true only for those rows of the table associated with the current group view element which are shown in the intersection table as being linked to a current instance of the intersection group view element's parent table group.
the block defined by lines 340-410 will be entered if the foreign key resides in the table associated with the current group view element's parent table group, and that parent table group is not an intersection table.
the routine ParamJoin will be invoked on the foreign key view element to define a suitable predicate.
the block defined by lines 440-620 will be entered if the foreign key is neither in the table associated with the current group view element nor the table associated with the parent table group. This block constructs a predicate string which evaluates to true for any row of the table associated with the current group view element which is related to one or more rows in the child table which contains the foreign key relating this group view element to its parent table group.
the generated predicate string is copied to the predicates parameter, and is thereby returned to the calling routine. The routine then terminates.
LISTING L50 illustrates an exemplary routine for generating a join relating a primary key column to a foreign key value, or vice versa. This routine is defined on a group view element and invokes itself on each of its contained view elements, thereby causing a concatenated equijoin predicate to be generated.
lines 120-210 determine which of the current view element and its key pair is to supply the value and which is to supply the column name in the database to be examined.
Lines 230 and 240 build a string specifying the comparison.
the generated string is appended to the predicate being accumulated. If the predicate was not empty, the generated string will be connected to the predicate using "AND".
LISTING L52 illustrates an exemplary routine for generating a predicate selecting rows in a semantic object table satisfying the connection power specified for this group view element. Specifically, if the connection power is specified as AVAILABLE, a predicate clause will be generated which evaluates to true for all rows of the semantic object table associated with this group view element that are connected to fewer instances of the semantic object containing the object link upon which the current group view element is based than the maximum cardinality of the pair of the object link upon which the current group view element is based.
connect power of the current group view element is specified as FREE
a predicate clause will be generated which selects all rows of the semantic object table associated with this group view element that are not connected to any instances on the relationship specified by the pair of the object upon which the current group view element is based. If the connect power of the current group view element is specified as NONE, then a predicate which is always false is generated. The generated predicate is returned at line 730. The routine then terminates.
LISTING L53 illustrates an exemplary routine for defining a subquery which evaluates to true if there are any rows satisfying the predicates specified on the current group view element or any view element it contains, directly or indirectly. If there are no such predicates, no subquery is defined. The various functions for accomplishing this task are described next.
LISTING L54 illustrates an exemplary routine for generating a select statement from the supplied values and using the given TableRef object to generate a list of tables to select from, along with appropriate join conditions.
LISTING L55 illustrates an exemplary routine for gathering together predicates on the current group view element and view elements contained within it.
Predicates on contained view elements fall within three broad categories. The first are predicates on simple view elements directly contained within the current group view element. These predicates are prefixed with the table and column name of the given child view element and joined to the predicate string being generated using AND, if necessary. Second, group view elements not representing tables add any predicates they contain to the current predicate string by a call to this routine on the group view element.
the third category is group view elements representing tables. These may be directly or indirectly related and may be single-valued or multi-valued. If they are indirectly related, i.e., the foreign key carrying the relationship is not directly contained within the current table group view element or the child group view element, then a routine entitled DefinePredicateUp (LISTING L57) is invoked to construct an appropriate predicate string. If the relationship is direct and multi-valued, then the routine SubQueryPredicate is invoked on the related group view element to generate an appropriate predicate string. If the relationship is direct and single valued, the routine JoinPredicate is invoked on the child group view element. This routine is set forth in LISTING L56, and described next.
the routine DefinePredicateDown returns three distinct values. The first is the number of predicates found on this branch of the view element hierarchy; the second is the generated predicate string; and the third is returned in the form of modifications to the TableRef object passed as a parameter.
LISTING L56 illustrates an exemplary routine JoinPredicate.
This routine encapsulates a call to DefinePredicateDown and converts any joins implied by the specified predicates to inner joins. This conversion is both possible and necessary because any rows in the table associated with the current group view element that are selected by a generated predicate must necessarily have a connection to the rows of the table which cause them to be selected.
LISTING L57 illustrates a routine entitled DefinePredicateUp that is similar to the routine DefinePredicate Down of LISTING L55 in that it gathers predicates within a run-time view hierarchy. However, DefinePredicateUp will traverse a hierarchy from a foreign key up (via parent view elements, rather than through child view elements, including across table group view elements) until a semantic object table group element is reached. This semantic object table group will be related to its parent by the foreign key that initiated the sequence of calls to the routine.
the specific lines of code illustrated in the pseudocode routine will be apparent to those skilled in the art.
LISTING L58 illustrates a class definition for the class TableRef.
the TableRef class is used to define a hierarchy of table group elements and join conditions.
Each TableRef object is associated with a group view element pointed to by its pGroupView member variable, as indicated at line 310.
the type of the join is indicated by the joinType member variable, which takes on values from the enumeration listed in lines 40-70.
the member variables pParent and tableRefList define the hierarchy by carrying the parent and child relationships respectively, as indicated at lines 330 and 340.
the non-trivial member functions are set forth in LISTINGS L59-L65, and discussed below.
LISTING L59 illustrates a constructor for the TableRef object.
a test is made to determine if this is the root of the TableRef tree or is associated with a group view element which is required in its parent context, i.e., its minimum cardinality is non-zero. In this case, the joinType is set to INNER. Otherwise, the joinType is set to indicate that a left outer join should be used.
Attach() function is called to add the current object to the parent's tableRefList. At this point, construction of the object is complete.
LISTING L60 illustrates the destructor for a TableRef object.
a loop bounded by lines 40-70, all of the objects on this object's tableRefList are destroyed.
a test is made to determine if the current object has a parent. If so, the function Detach is invoked on the parent object, which removes the current object from the parent tableRefList. This concludes the operation of the destructor.
LISTING L61 illustrates a function entitled TableNames that recursively generates a string containing names of all the tables in the TableRef hierarchy, separated by commas.
LISTING L62 illustrates a routine entitled ColumnNames that generates a list of all the columns in all the tables in a TableRef hierarchy, which may be optionally limited to the primary key columns only.
LISTING L63 illustrates a routine entitled InnerJoins which is used to generate a string representing a TableRef hierarchy as a series of equijoins.
LISTING L64 illustrates a routine entitled JoinCondition which is used to generate a string defining an equijoin between the current TableRef and its parent, if any.
LISTING L65 illustrates a routine entitled GatherJoin that is used to generate a string representing all the joins specified by a TableRef hierarchy, which may include outer joins.
the routine generates a list of qualified column names to be selected, a Ust of table names, and a where clause representing the join relationships.
LISTING L66 illustrates a routine entitled DoDatabaseUpdate which generates a SQL update statement to update the table associated with the current group view element with values from the group view element's current row.
a SQL command is begun that specifies the name of the table to be updated.
the function FindColumns shown in LISTING L68, is called to generate a Ust of updates to columns, separated by commas. The columns to be included, and the new value to be used are determined by the function UpdateColumnValues, shown in LISTING L69.
the function FindColumns is called to generate an appropriate predicate specifying the row to be updated.
the columns to be included are specified by the fUnction WherePredicate, which is illustrated in LISTING L70, and separated by AND.
a call to the function ExecuteSQLString is called to update the database.
an indication of the success or failure of this routine is returned. The routine then terminates.
LISTING L67 illustrates the routine entitled DoDatabaseDelete that generates a SQL statement to delete the row in the table associated with the current group view element specifed by the group view element's current row.
a SQL command is begun that specifies the name of the table from which an instance is to be deleted.
the function FindColumns shown in LISTING L68, is called to generate generate an appropriate predicate specifying the row to be deleted.
the columns to be included are specified by the function WherePredicate, which is illustrated in LISTING L70.
a call to the function ExecuteSQLString is called to update the database.
an indication of the success or failure of this routine is returned. The routine then terminates.
LISTING L68 illustrates a routine entitled FindColumns that will call a predicate function passed as a parameter with every non-group view element in the current table group view element. If the predicate fUnction returns a non-empty string, it is added to the return value, called "answer". If more than one non-empty value is returned, they will be separated in the "answer" string by the string passed as the column separator (colSep) parameter.
colSep column separator
view elements specifying potentially large data values. It will be appreciated by those skilled in the art that this serves to implement optimistic locking, and a system which obtained locks when the rows are read from a database would only need to specify primary key values.
LISTING L71 illustrates a routine entitled DoDatabaselnsert that generates a
InsertColumns is a predicate function which returns the column name of any view element it has passed.
Insert Values is a predicate function which returns a string representing the value of any view element it has passed.
the predicate functions InsertColumns and InsertValues are set forth in LISTINGS L72 and L73, respectively.
Listing L74 sets forth the database schema generated for the object model illustrated in FIGURE 8.

PCT/US1996/013284 1995-08-17 1996-08-15 Method and apparatus for storing and retrieving data in a relational database using an object model WO1997007470A1 (en)

Priority Applications (2)

Application Number	Priority Date	Filing Date	Title
EP96928204A EP0846299A1 (en)	1995-08-17	1996-08-15	Method and apparatus for storing and retrieving data in a relational database using an object model
AU67764/96A AU6776496A (en)	1995-08-17	1996-08-15	Method and apparatus for storing and retrieving data in a relational database using an object model

Applications Claiming Priority (2)

Application Number	Priority Date	Filing Date	Title
US51644695A	1995-08-17	1995-08-17
US08/516,446		1995-08-17

Publications (1)

Publication Number	Publication Date
WO1997007470A1 true WO1997007470A1 (en)	1997-02-27

Family

ID=24055634

Family Applications (1)

Application Number	Title	Priority Date	Filing Date
PCT/US1996/013284 WO1997007470A1 (en)	1995-08-17	1996-08-15	Method and apparatus for storing and retrieving data in a relational database using an object model

Country Status (4)

Country	Link
EP (1)	EP0846299A1 (pt-BR)
AU (1)	AU6776496A (pt-BR)
CA (1)	CA2229569A1 (pt-BR)
WO (1)	WO1997007470A1 (pt-BR)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
EP0982670A2 (en) *	1998-08-25	2000-03-01	Informix Software, Inc.	Dynamic object visualization and code generation
EP0982671A3 (en) *	1998-08-25	2005-08-10	International Business Machines Corporation	Dynamic object properties
US8032484B2 (en)	2007-03-30	2011-10-04	International Business Machines Corporation	Creation of generic hierarchies

Citations (4)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
GB2253500A (en) *	1990-08-23	1992-09-09	Data General Corp	Object oriented-data bases
US5263167A (en) *	1991-11-22	1993-11-16	International Business Machines Corporation	User interface for a relational database using a task object for defining search queries in response to a profile object which describes user proficiency
WO1995003586A1 (en) *	1993-07-21	1995-02-02	Persistence Software, Inc.	Method and apparatus for generation of code for mapping relational data to objects
WO1995012172A1 (en) *	1993-10-29	1995-05-04	Wall Data Incorporated	Semantic object modeling system for creating relational database schemas

1996
- 1996-08-15 CA CA002229569A patent/CA2229569A1/en not_active Abandoned
- 1996-08-15 WO PCT/US1996/013284 patent/WO1997007470A1/en not_active Application Discontinuation
- 1996-08-15 EP EP96928204A patent/EP0846299A1/en not_active Withdrawn
- 1996-08-15 AU AU67764/96A patent/AU6776496A/en not_active Abandoned

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
GB2253500A (en) *	1990-08-23	1992-09-09	Data General Corp	Object oriented-data bases
US5263167A (en) *	1991-11-22	1993-11-16	International Business Machines Corporation	User interface for a relational database using a task object for defining search queries in response to a profile object which describes user proficiency
WO1995003586A1 (en) *	1993-07-21	1995-02-02	Persistence Software, Inc.	Method and apparatus for generation of code for mapping relational data to objects
WO1995012172A1 (en) *	1993-10-29	1995-05-04	Wall Data Incorporated	Semantic object modeling system for creating relational database schemas

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BUTTERWORTH P ET AL: "THE GEMSTONE OBJECT DATABASE MANAGEMENT SYSTEM", COMMUNICATIONS OF THE ASSOCIATION FOR COMPUTING MACHINERY, vol. 34, no. 10, 1 October 1991 (1991-10-01), pages 64 - 77, XP000266967 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number	Priority date	Publication date	Assignee	Title
EP0982670A2 (en) *	1998-08-25	2000-03-01	Informix Software, Inc.	Dynamic object visualization and code generation
EP0982670A3 (en) *	1998-08-25	2005-08-10	International Business Machines Corporation	Dynamic object visualization and code generation
EP0982671A3 (en) *	1998-08-25	2005-08-10	International Business Machines Corporation	Dynamic object properties
US8032484B2 (en)	2007-03-30	2011-10-04	International Business Machines Corporation	Creation of generic hierarchies

Also Published As

Publication number	Publication date
CA2229569A1 (en)	1997-02-27
AU6776496A (en)	1997-03-12
EP0846299A1 (en)	1998-06-10

Legal Events

Date	Code	Title	Description
1997-02-27	AK	Designated states	Kind code of ref document: A1 Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG UZ VN AM AZ BY KG KZ MD RU TJ TM
1997-02-27	AL	Designated countries for regional patents	Kind code of ref document: A1 Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA
1997-04-17	DFPE	Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
1997-06-18	121	Ep: the epo has been informed by wipo that ep was designated in this application
1998-02-11	WWE	Wipo information: entry into national phase	Ref document number: 1996928204 Country of ref document: EP
1998-02-16	ENP	Entry into the national phase	Ref document number: 2229569 Country of ref document: CA Ref country code: CA Ref document number: 2229569 Kind code of ref document: A Format of ref document f/p: F
1998-06-10	WWP	Wipo information: published in national office	Ref document number: 1996928204 Country of ref document: EP
1998-06-18	REG	Reference to national code	Ref country code: DE Ref legal event code: 8642
2000-07-21	WWW	Wipo information: withdrawn in national office	Ref document number: 1996928204 Country of ref document: EP

Publication	Publication Date	Title
US5418950A (en)	1995-05-23	System for interactive clause window construction of SQL queries
US6108004A (en)	2000-08-22	GUI guide for data mining
US7120646B2 (en)	2006-10-10	Method and system for interfacing with a multi-level data structure
US5787416A (en)	1998-07-28	Methods for hypertext reporting in a relational database management system
US6035300A (en)	2000-03-07	Method and apparatus for generating a user interface from the entity/attribute/relationship model of a database
US7401094B1 (en)	2008-07-15	Automated generation of dynamic data entry user interface for relational database management systems
US5455945A (en)	1995-10-03	System and method for dynamically displaying entering, and updating data from a database
USRE44652E1 (en)	2013-12-17	Computer-readable data product for managing sales information
US5195178A (en)	1993-03-16	Adaptive window system for dynamically modeling information systems
US5212771A (en)	1993-05-18	System for establishing concurrent high level and low level processes in a diagram window through process explosion and implosion subsystems
US6360223B1 (en)	2002-03-19	Rule-based approach to object-relational mapping strategies
US5734887A (en)	1998-03-31	Method and apparatus for logical data access to a physical relational database
US7546291B2 (en)	2009-06-09	Data source task pane
US5950190A (en)	1999-09-07	Dynamic, self-modifying graphical user interface for relational database applications
US5193182A (en)	1993-03-09	Computer system for defining logical operations on design data including retrieve entity-set, send, receive, signal, when, reference to entity-set, reference to entity method, connect and disconnect
US20080195649A1 (en)	2008-08-14	Dynamic User Interface and a Method For Generating a Dynamic User Interface For Interfacing With an Electronic Data Repository Storing a Collection of Data Elements
US20070106629A1 (en)	2007-05-10	System and method for accessing data
US20070094306A1 (en)	2007-04-26	Method and model for enterprise system development and execution
WO1996026484A2 (en)	1996-08-29	Graphical environment for managing and developing applications
US20060271885A1 (en)	2006-11-30	Automatic database entry and data format modification
AU2002303296A1 (en)	2003-04-10	Method and system for interfacing with a multi-level data structure
CA2526045A1 (en)	2006-06-15	Complex data access
WO1997007470A1 (en)	1997-02-27	Method and apparatus for storing and retrieving data in a relational database using an object model
WO2003042865A2 (en)	2003-05-22	Taxonomy management
EP0569188A1 (en)	1993-11-10	Accessing a computer database