Abstract:
Certain types of modeling problems solvable using object oriented computer programming languages can be solved using standard structure query programming languages (SQL). By appropriately tabulating relationships of these problems, the tables can be operated on using predetermined SQL procedures that can use well-known object oriented computer programming language concepts.

Description:
TECHNICAL FIELD 
     The invention generally relates to computer relational database programming languages, systems, and more particularly to methods and system for implementing the notions of object oriented programming using a structured query language. 
     RELATED APPLICATION 
     The Detailed Description of the U.S. patent application Ser. No. 08/790,302 filed Jan. 31, 1997 now U.S. Pat. No. 5,819,257 for &#34;Process for Providing Transitive Closure Using Fourth Generation Structured Query Language (SQL)&#34; and which is assigned to Lucent Technologies, Inc., is incorporated herein by reference. 
     DESCRIPTION OF THE PRIOR ART 
     Object oriented computer programming and design methodology has become popular as a way of modeling and solving many programming problems. Traditionally, the implementation of such systems has been performed using an object oriented programming language such as C++. 
     Those skilled in the art know that object oriented programming languages share at least five unique and defining concepts or notions. These concepts, which are discussed fully in the relevant literature pertaining to object oriented programming, are known as: CLASSES, OBJECTS; INHERITANCE; POLYMORPHISM, and ENCAPSULATION. 
     The literature on object-oriented programming contains a more complete discussion of the notions of object-oriented programming. 
     Briefly, a CLASS can be considered to be a template or collection of attributes and methods (i.e. procedures). An OBJECT is an instance of a class that has specific attributes and corresponding values. INHERITANCE provides the ability for one class to share attribute and method specifications with other classes. 
     Objects communicate with one another via &#34;message passing.&#34; A &#34;message&#34; is a text string such as &#34;redraw --  ourself&#34;. When an object receives a message, a corresponding class method is executed. 
     It is well-known that in object-oriented programming, different OBJECTS of an object-oriented programming language will respond to messages differently. 
     POLYMORPHISM is the ability for all objects to respond appropriately to messages received. For example, a &#34;check box&#34; graphical user interface object and a &#34;list box&#34; graphical user interface object both know how to respond to a &#34;redraw yourself&#34; message, but respond differently in performing a redraw of themselves. Of course, each OBJECT must be written to respond to the particular message, but the response after a message is recognized and accepted is unique to the class specification. 
     ENCAPSULATION is the ability to hide data and processing in an OBJECT when an OBJECT is passed a message. 
     The notions of object-oriented programming are believed to make programming easier for many problem domains. Once the code for a CLASS definition is written, tested, and found to work, the OBJECT instances can be created. By using class definitions in different object instance contexts, programming time is reduced. 
     In writing a computer program, only the OBJECTS need to be known and the messages recognized by them, not necessarily how they were written or how they work. The software design process time period can be considerably shortened for programs written using an object-oriented language. 
     The inventor has demonstrated that it is possible to determine the transitive closure of a directed acyclical graph using SQL which includes the steps of. 1) determining a table of vertices of the directed acyclical graph, 2) determining an edge table from all of the vertices; 3) deriving a path table from the vertex table and the edge table, and from the path table determining the existence of a path between any two nodes in the graph. This methodology is disclosed in U.S. patent application Ser. No. 08/790,302 filed on Jan. 31, 1997 now U.S. Pat. No. 5,819,257 for &#34;Process for Providing Transitive Closure Using Fourth Generation Structured Query Language (SQL)&#34;. 
     A structured query language offers three advantages over object oriented programming languages. First, SQL is declarative: a request need only be specified, not the steps of a method to achieve the result. Second, SQL can be modeled using relational algebra or relational calculus meaning that it has a strong mathematical foundation by which program correctness can be assured. Finally, SQL is interpreted, not compiled meaning that CLASS and INSTANCE information can be changed at run time. 
     A method and system by which an interpretive, structured query language might be used to implement the constructs of an object oriented programming language would reduce software development time and simplify program maintenance while insuring program correctness. 
     Accordingly, an object of the present invention is to provide a method and system by which the notions and constructs of an object oriented programming language can be implemented using a structured query language. 
     SUMMARY OF THE INVENTION 
     The characteristics and operation of an object oriented programming language can be implemented using a structured query language. The notions of CLASSES and OBJECTS can be modeled as directed acyclic graphs. Since directed acyclical graphs can be represented using several tables, and since these tables can be analyzed and operated on using a structured query language, SQL can provide functionality that duplicates the object oriented programming language concepts of CLASSES, OBJECTS, INHERITANCE, POLYMORPHISM and ENCAPSULATION. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a directed acyclic class graph model of a planning problem for an example software and hardware project. 
     FIG. 2 shows a table listing attributes of the nodes of the directed acyclic graph of FIG. 1. 
     FIG. 3 shows a table of methods used by the nodes of the directed acyclic graph of FIG. 1. 
     FIG. 4 shows another directed acyclic graph but of instances of the directed acyclic graph of FIG. 1. 
     FIG. 5 is a table of classes of tracking entities and a description of each. 
     FIG. 6 is a table listing parent and child nodes of the directed acyclic graph of FIG. 1 and the classification of edges linking them as either &#34;IS-A&#34; or &#34;HAS-A&#34; edges. 
     FIG. 7 is a tabulation of types of data of the attributes of each class shown in FIG. 1. 
     FIG. 8 is a tabulation of methods associated with messages exchanged between the classes shown in FIG. 1. 
     FIG. 9 is a tabulation of tracking entities organization and classes. 
     FIG. 10 is a tabulation of edges in the directed acyclic graph of FIG. 1 and the characterization of each as &#34;HAS-A&#34; or &#34;IS-A&#34;. 
     FIG. 11 lists attributes of the tracking entities. 
     FIG. 11-A is a continuation of FIG. 11. 
     FIG. 12 lists paths, lengths, and a count of edges of the directed acyclic graph shown in FIG. 1 
     FIG. 13 is a transitive closure table for the directed acyclic graph shown in FIG. 1. 
     FIG. 13-A is a continuation of FIG. 13. 
     FIG. 14 shows the inheritance hierarchy of features of FIG. 1. 
     FIG. 15 shows inheritance hierarchy and messages passed between objects shown in FIG. 14. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     The implementation of object oriented programming concepts using SQL can be illustrated by way of an example of a planning problem modeled using directed acyclic graphs and tables that can be used to model directed acyclic graphs. In the examples that follow, the directed acyclic graphs are merely abstract, graphical representations of tabular data stored within and retrieved from the random access memory, or other storage media including a disk or tape for example, of any suitably programmable digital computer. Such tables can be created in the memory of a computer using SQL, as is well known to those skilled in the art. 
     FIG. 1 is a directed acyclic graph representing software and hardware development of a project by a company. The nodes of the directed acyclic graph are graphically linked by edges to which there is associated one of two characteristics: &#34;HAS-A&#34; and &#34;IS-A.&#34; &#34;HAS-A&#34; edges represent a decomposition of a project into smaller segments. &#34;IS-A&#34; edges represent relationships between object-oriented programming language superclasses. The semantics of &#34;HAS-A&#34; and &#34;IS-A&#34; edges are well-known to those skilled in the art of object oriented programming languages. 
     With respect to FIG. 1, a &#34;large --  feature&#34; is a superclass of an &#34;extra --  large&#34; feature. Similarly, a &#34;feature&#34; is a superclass of a &#34;large --  feature.&#34; 
     Using terminology and concepts of object oriented programming language, FIG. 1 shows that each project (100) HAS-A feature (102). Each feature (102) has both software and hardware by virtue of the fact that the feature HAS-A software node (104) to which it is associated and a hardware node (106) to which it is also associated. Software (104) in turn has code (108) as a HAS-A edge links the software node (104) to the code node (110). 
     The feature node (102) is a parent node of two vertices (112 and 114). The child nodes (112 and 114) of the feature node (102) are large --  feature (116) and small --  feature (118). Large --  features (116) and small --  features (118) are both IS-A linked to features (102). In turn, a small --  features (118) IS-A extra small feature, i.e. xsmall --  feature (120). Similarly, an extra large feature (122) IS-A large --  feature (116). 
     The nodes in the graph shown in FIG. 1 can be considered to be objected oriented CLASSES. Those skilled in the art will recognize that the graph of FIG. 1 is a directed acyclical graph which can be represented by a table listing the nodes and a table listing the edges linking them. The graph is FIG. 1 is really an abstraction of data represented in tables. Tabular data can be operated on and processed using SQL. Such processing includes that which is taught in the aforementioned patent application of the inventor. 
     FIG. 2 shows the attributes associated with each CLASS shown in FIG. 1. 
     FIG. 3 shows the methods, i.e. the procedures, defined for each class shown in FIG. 1. 
     FIGS. 1, 2 and 3 collectively describe all of the object oriented CLASSES and definitions representing software and hardware development of a project by a company. 
     From the foregoing, the object oriented programming concept of CLASS can be implemented using tables. One table is needed to show the nodes of a graph (FIG. 5), another table is required to show the edges coupling the nodes (FIG. 6), yet another table is needed to show attributes of each node (FIG. 7), finally, a table showing class methods (FIG. 8). 
     FIG. 4 shows an OBJECT graph. FIG. 4 can also be represented using tables. While the CLASS graph can be represented with four tables, the OBJECT graph of FIG. 4 is represented with three tables. One table lists the nodes of the object graph (FIG. 9); a second table lists the edges of the object graph (FIG. 10); a third table lists the attributes defined for each node in the graph (FIG. 11). These three tables represent OBJECT definitions. 
     For both the CLASS and OBJECT graphs, the creation and deletion of nodes and edges in these graphs can be represented by corresponding insertions and deletions into the appropriate tables using SQL statements. 
     Demonstrating INHERITANCE requires the existence of a transitive closure table for the CLASS graph. (FIG. 12). Determination of a transitive closure table (FIG. 12) is set forth in the Detailed Description of the application for &#34;Process for Providing Transitive Closure Using Fourth Generation Structured Query Language&#34;, (Ser. No. 08/790,302, filed on Jan. 31, 1997, now U.S. Pat. No. 5,819,257 and assigned to Lucent Technologies, Inc.) which is incorporated herein by reference. 
     A transitive closure table of the OBJECT graph (FIG. 13) provides the ability to ask graph-traversing questions about objects in the OBJECT graph. 
     INHERITANCE is the ability for one CLASS to share attribute and method specifications with other CLASSES. Adding a node to an OBJECT graph requires the construction of attributes that a node will inherit from the node or nodes to which it is coupled through the (aforementioned) IS-A edges of the CLASS graph. 
     A transitive closure table, as described in the aforementioned application, lists all of the paths (of edges coupling nodes) through a directed acyclical graph. Knowing all of the paths through a graph means that all of the nodes of the paths are known. Inasmuch as the nodes have characteristics associated with them, knowing the nodes of a path establishes all of the characteristics of the nodes along a path. Knowing the characteristics of a path means that the descendants of a nodes have the attributes of the parent nodes. Inasmuch as SQL extracts data from the tables by which a directed acyclical graph is represented, and to construct the transitive closure table showing all of the paths through such a graph, SQL can provide INHERITANCE of an object oriented programming language if a transitive closure table is generated. 
     From FIG. 14 it can be seen that small --  feature is a specialization of a feature, small --  feature therefore inherits attributes of status and cost. Since xsmall --  feature is a specialization of a small --  feature, it inherits attributes of status, cost, and deploy. Therefore, whenever a record is inserted into tracking --  entity for an xsmall --  feature, four records are inserted into the tables for tracking --  entity --  attribute (FIG. 11) for attributes status, cost, deploy, and target by processing data within and comprising the tables using the following SQL procedure and rule to achieve this: 
     
         __________________________________________________________________________Create procedure attribute.sub.-- insert.sub.-- proc( Tracking.sub.-- entity.sub.-- varchar(255) not null not default, Tracking.sub.-- entity.sub.-- class varchar(255) not null not default) asbegin insert into tracking.sub.-- entity.sub.-- attribute (tracking.sub.--entity.sub.-- class, attribute)  select distinct :tracking.sub.-- entity, a.attribute  from tracking.sub.-- entity.sub.-- class.sub.-- attribute a,tracking.sub.-- entity.sub.-- class.sub.-- path p  where p.child.sub.-- tracking.sub.-- entity.sub.-- class=:tracking.sub.-- entity.sub.-- class  and a.tracking.sub.-- entity.sub.-- class=p.parent.sub.-- tracking.sub.-- entity.sub.-- class  and p.edge in (REFLEXIVE`, `IS-A`)endcreate rule attribute.sub.-- insert after insert of tracking.sub.--entity execute procedure attribute.sub.-- insert.sub.-- proc(  tracking.sub.-- entity=new.tracking.sub.-- entity,  tracking.sub.-- entity.sub.-- class=new.tracking.sub.-- entity.sub.--class )__________________________________________________________________________ 
    
     POLYMORPHISM is the ability for all objects to respond appropriately to messages received. As set forth above, a &#34;check box&#34; graphical user interface object and a &#34;list box&#34; graphical user interface object both know how to respond to a &#34;redraw yourself&#34; message, but respond differently in performing a redraw of themselves. Of course, each OBJECT must be written to respond to the particular message, but the response after a message is recognized and accepted is unique. 
     In an object oriented system, the occurrence of an external event triggers the passing of messages to objects. In an object oriented system wherein the objects are database elements (i.e. tabular data), external events comprise: inserting, updating, or deleting records from tables. 
     By way of example, assume that an attribute of a node is to be updated, for example, the attribute &#34;status&#34; that might be listed in an &#34;attribute&#34; table for the nodes of an object graph. Updating an attribute table for the object graph shown in FIG. 4 using SQL requires processing data within the table by the execution of an SQL statement that might look like: 
     
         update.sub.-- attribute set status=`green` where name=99-NS-2261 
    
     The execution of the foregoing statement causes the following database &#34;rule&#34; to fire (as the term &#34;fire&#34; is known in the art of SQL programming). 
     
         ______________________________________Create rule authorize after update of tracking.sub.-- entity.sub.--attribute Execute procedure event.sub.-- handler(  Message=`authorize`,  Tracking.sub.-- entity=new.tracking.sub.-- entity  Attribute=new.attribute );______________________________________ 
    
     Firing the foregoing database &#34;rule&#34; results in the execution of the following SQL procedure. 
     
         __________________________________________________________________________create procedure event.sub.-- handler( Message varchar(255) not null not default, Tracking.sub.-- entity varchar(255) not null not default Attribute varchar(255) not null not default)asdeclare method varchar(80) not null; return.sub.-- value varchar(255) not null; error.sub.-- string varchar(255) not null; parameters varchar(255) not null;begin method= ``; return.sub.-- value=0; parameters=:tracking.sub.-- entity+`, `+:attribute; select m.method into :method from tracking.sub.-- entity e1, tracking.sub.-- entity.sub.-- class.sub.-- path p1, tracking.sub.-- entity.sub.-- class.sub.-- method m1 where e1.tracking.sub.-- entity =: tracking.sub.-- entity and p1.child.sub.-- tracking.sub.-- entity.sub.-- class= e1.tracking.sub.-- entity.sub.-- class and p1.edge in (`REFLEXIVE`, `IS-A`) and m1.tracking.sub.-- entity.sub.-- class = p1.parent.sub.-- tracking.sub.-- entity.sub.-- class and m1.message =: message and p1.path.sub.-- length in (  select min(p2.path.sub.-- length)  from tracking.sub.-- entity e2, tracking.sub.-- entity.sub.-- class.sub.-- path p2, tracking.sub.-- entity.sub.-- class.sub.-- method m2  where e2.tracking.sub.-- entity =: tracking.sub.-- entity  and p2.child.sub.-- tracking.sub.-- entity.sub.-- class= e2.tracking.sub.-- entity.sub.-- class  and p2.edge in (REFLEXIVE`, `IS-A`)  and m2.tracking.sub.-- entity = p2.parent.sub.-- tracking.sub.--entity  and m2.message =: message ); if method != `` then  return.sub.-- value = execute procedure :method(  tracking.sub.-- entity =: tracking.sub.-- entity, attribute=:attribute); endif; if return.sub.-- value != 0 then  error.sub.-- string = `Error executing method `+:method  raise error -1 :error.sub.-- string; endif; raise dbevent :message :parameters;end__________________________________________________________________________ 
    
     When this SQL procedure is called and executed, a message parameter is passed to the procedure along with the name of the OBJECT and name of the OBJECT&#39;s attribute being updated. Upon executing, this procedure will look up an appropriate method to execute corresponding to the message passed to the procedure. From FIG. 15, it can be seen that the appropriate method to execute is small --  feature --  authorize. Once the appropriate method has been determined, the procedure executes the method. 
     Those skilled in the art will recognize that each of the foregoing SQL procedures might be altered in numerous ways to achieve the desired result. 
     Inasmuch as the foregoing SQL procedure updates OBJECTs transparently, the aforementioned SQL procedure demonstrates object oriented programming POLYMORPHISM. For any message passed to this procedure, the procedure determines the appropriate method to execute. 
     As set forth above, ENCAPSULATION is the ability to hide data and processing in an OBJECT when an OBJECT is passed a message. 
     Since SQL is a declarative programming language. Stating what data is wanted from a database, without specifying how to retrieve the data or how data is to be stored is precisely what ENCAPSULATION does. By way of example, ENCAPSULATION can be shown by defining a view that hides how attributes in the tracking --  entity --  attribute table (FIG. 7) are physically stored. The values of these attributes use tri-state logic and therefore can have a value, have no value, or have an unset, undetermined, unknown state (i.e. nullable). From the definition of tracking --  entity --  attribute that an attribute value is stored in either charvalue, intvalue, or floatvalue depending upon whether the data type in the associated tracking entity --  class --  attribute table (FIG. 11) is a char, int or float value. The following view definition hides these storage details. 
     
         ______________________________________Create view tracking.sub.-- entity.sub.-- attribute.sub.-- view asSelect  tracking.sub.-- entity.sub.-- attribute. *,  ifnull(charvalue,Ifnull(varchar(intvalue), Ifnull(varchar(floatvalue),  &#34;))) as attribute.sub.-- valuefrom  tracking.sub.-- entity.sub.-- attribute.______________________________________ 
    
     It is well-known that certain classes of mathematical problems can be modeled and solved using any one of several computer programming languages. It is also well-known that many of these problems are solved using object oriented languages. 
     Heretofore, Structured Query Language has been used for solving certain problems largely associated with tabular data. By using the methods taught herein, it is now possible to solve much wider classes of problems using SQL, by modeling the problems in a tabular format and employing SQL methodologies taught herein.