Abstract:
Business transactions or other events may be structured as a series of database-objects formed of combinations of sub-objects which in turn may depend on yet a lower level of objects. By creating object templates for the objects that progressively group inter-correlated data and inter-correlated objects, large amounts of event data may be captured with modest data storage requirements. The system is particularly well suited for capturing sales events comprised of a large range of data of different attributes.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application hereby claims the benefit of provisional application 60/195,670, filed Apr. 7, 2000. 
    
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
     BACKGROUND OF THE INVENTION 
     The present invention relates to a method for storing data about events in time, such as sales of a product, and in particular to a method of using database-objects to track large amounts of data associated with such events in an efficient manner. 
     Computer databases allow the storage and retrieval of data. The data may be linked in records holding data elements so that a particular data element may be identified or sorted based on other elements of its record. 
     Such electronic databases can be extremely useful in tracking business information particularly where the information can be easily fit into a small number of records with a limited number of data elements. For example, a physician might readily track patients, their addresses and insurance carriers using a record-type structure. 
     Some business data does not readily lend itself to the simple record structure. For example, it might be desirable to track a large number of attributes related to sales of product. The attributes of such sales events may include for example: the time of the sale, the product, the product components, the selling division, the customer purchasing agent, the buying enterprise, the location of the enterprise, the responsible sales and manufacturing units, and many others. 
     The importance of a sales event to a business enterprise makes it desirable for the number of attributes recorded not be unduly limited. The data of these attributes can be used for a variety of purposes including the coordination of different operations within the business, strategic planning and record keeping. On the other hand, the number of sales events in even a modest company can be extremely large. A conventional record structure in which one record is allocated to each sales event and one data element to each recorded attribute of each sales event, rapidly exhausts the storage capacity and power of conventional business computers. 
     BRIEF SUMMARY OF THE INVENTION 
     The present inventors have recognized that “database-objects” being part of an object-oriented database, can provide for efficient storage of extremely large numbers of attributes associated with frequent events. Database-objects operate in some ways analogously to software objects, that is, they can inherit data and structure from other objects without the need to reproduce the data or structure. By breaking event data into groups of increasing intercorrelation (i.e. groups whose elements are relatively stable across events) through the use of database-objects, data storage requirements are much reduced and event data is easier to assemble. 
     For example, the extremely dynamic concept of a sales event can be assembled from the intersection of relatively static groupings data about products, customer and fulfillment of the sale. Each sales event can be an instance of a database-object template referencing instances of database-objects of product, customer and fulfillment. These underlying database-objects in turn can be further reduced to more stable database-objects, for example, the customer&#39;s database-object can be assembled from data representing an enterprise, an agent and a location. The need for new instances of database-objects is reduced as the groupings of the objects become more stable, and the use of database-objects, which reference but do not duplicate data, makes the overall storage requirements low. 
     Specifically then the present invention provides a method of capturing “event data” of events over time using an object-oriented database having database-object templates that may reference attributes of the event data and other database-object templates that may be instantiated to create database-object instances referencing data of the attributes of the database-object templates and instances of the other database-object templates. 
     The method includes a first step of defining a set of underlying database-object templates each possibly referencing at least a portion of the attributes of the event data. In a second step, an event database-object template referencing at least a portion of the underlying database-objects templates is defined. Upon each event, having given event data, given ones of the set of underlying database-object templates referencing attributes of the given event data are instantiated. Finally, an event database-object template referencing the instanced given ones of the set of underlying database-object templates is referenced. 
     Thus it is one objective of the invention to provide a rapid method of capturing complex and variable event-type data. By defining database-objects in a hierarchical fashion, event database-objects, capturing the required data, can be easily defined by identifying a smaller number of underlying objects. 
     Intermediate database-objects may be positioned between the underlying database-objects and the event database-objects in a multi-layered hierarchy. 
     Thus it is another objective of the invention to leverage recorded data through multiple layers of database-objects further reducing storage requirements and simplifying recordation of event data. 
     Each progressive layer of database-objects is defined to reference attributes of increasing intercorrelation or increasingly intercorrelated database-objects over different events. 
     Thus it is another objective of the invention to minimize the burden of instantiating database-objects. The groupings provide some permanence to each instanced database-object while the layers of objects reduce the propagation of any changes in the data in the direction of the event database-object. 
     In one embodiment, the event database-object template may represent a sales event and be made up of: 
     (1) a customer database-object in turn referencing: 
     (a) a location database-object template referencing attributes indicating customer locations; 
     (b) an agent database-object template referencing attributes indicating customer agents; 
     (c) an enterprise database-object template referencing attributes indicating customer enterprises; and a 
     (2) a product database-object in turn referencing: 
     (a) a product information database-object template referencing attributes indicating product information; 
     (b) a product business database-object template referencing attributes indicating product business; 
     (c) a product design database-object template referencing attributes indicating product designs; and a 
     (3) a fulfillment database-object in turn referencing: 
     (a) a fulfillment logistics database-object template referencing attributes indicating fulfillment logistics; 
     (b) a fulfillment services database-object template referencing attributes indicating fulfillment services; and 
     (c) a fulfillment manufacturing support chain database-object template referencing attributes indicating fulfillment manufacturing support chain. 
     Thus it is another objective of the invention to provide a practical structure for recording sales events comprised of a complex set of underlying data. 
    
    
     The foregoing and other objectives and advantages of the invention will appear from the following description. In this description, reference is made to the accompanying drawings, which form a part hereof, and in which there is shown by way of illustration, a preferred embodiment of the invention. Such embodiment and its particular objects and advantages do not define the scope of the invention, however, and reference must be made therefore to the claims for interpreting the scope of the invention. 
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of computer architecture suitable for use with the present invention providing a processor and a memory holding an object-oriented database program executed by the processor into which the structures of the present invention may be placed; 
     FIG. 2 is a simplified diagram of the operation of a method of instancing a database-object showing the relatively low memory overhead of such an instancing; 
     FIG. 3 is a hierarchical diagram showing inheritance of combination objects providing a high degree of data leverage and the ability to create highly variable high level objects from less variable low level objects; 
     FIG. 4 is a representation of the hierarchy of data objects per the present invention in which a customer object is built from enterprise, agent, and location objects; and 
     FIG. 5 is a figure similar to that of FIG. 4 showing the customer object of FIG. 4 as incorporated into a larger hierarchy leasing to a sales event object built of the customer object, a product object and a fulfillment object, the latter two which are in turn constructed of lower level objects. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Referring now to FIG. 1, an electronic computer  10  suitable for use with the present invention includes a processor  12  communicating on an internal bus  14  with an internal memory  20  such as may comprise a combination of solid-state memory and mass storage devices such as magnetic disk drives. The processor may also communicate via internal bus  14  with a port  16  connected with input/output terminals  18 . The processor  12  executing an operating system  22  may thus act as a server for the terminals  18  according to well-known architectures. 
     The memory  20  also includes an object-oriented database  24  such as is commercially available from the Oracle Corporation of Redwood Shores, Calif., U.S.A. under the trade name of Oracle 8i. Such an object-oriented database  24  includes a query engine  26  of a type well known in the art and object management modules  28  whose operation will be described below. 
     The object-oriented database  24  deals with an underlying database  30  of data elements  52  entered by the users through various terminals  18  together with user defined object templates  32  and instanced database-objects  34 , each of which will be described. 
     Referring now to FIG. 2, the principles of object oriented design, well known in the areas of program development, provide for program reusability and efficient memory management through the generation of a variety of “software objects” which may be “instanced” and which may be combined to form more complex objects through the process of “association”. 
     A “database-object” is analogous providing an object template  32  having an object name  38  and a data structure  40  comprised of data types  42  describing data that may be held in elements  52  within the database  30 . In the present invention, a database-object of AGENT representing a person who may buy products on behalf of a business customer, includes a data structure providing text variable of NAME being the name of a person representing the AGENT, a TITLE being the title of that person within an organization of which the AGENT is part and also a text variable, an AUTHORIZATION which may be a text or numeric variable indicating the authorization of the AGENT for purchases, a VOCATIONAL DISCIPLINE which may be a selection from a set of possible disciplines or a text field, and a text variable of SUPERIOR which indicates the superior of the AGENT. In this way, the object template  32  like a template for a software object, represents a physical object, in this case, a person. 
     Like a software object, the object template  32  may be instanced in an instancing process  36  to create an instanced database-object  34  representing a particular object in highly compressed form. The instanced database-objects  34  provide source template data  47  indicating the template from which it is formed, in this case the template  32 . Also included is a unique instance number  48  and various database references  50  ultimately leading to particular data elements  52  satisfying each of the data structures  40 . The database references may point to memory locations (or more typically memory offsets) or may point to another database-object in the case of inheritance as will be described below. 
     In all cases, however, the data will not be stored in the instanced database-objects  34  and thus, multiple instanced database-objects  34  having possibly redundant data elements  52  may be efficiently represented. Normally the instancing process requires relatively little storage compared to duplicating the data of the instanced database-object  34 , but there is some storage overhead in holding references  50  necessary in the instanced database-object  34  and therefore even instancing is desirably held to a minimum. 
     The instancing process  36  is a method inherent in the program  24 , which creates an instanced database-object  34  and prompts the user to provide the necessary references to data to complete that object. Default data values may be provided when the object is initially instanced. In this regard, the generation of the lowest level of instanced database-objects  34  is not much different, in terms of effort, from entering a data record in a conventional database. The properties of inheritance, however, provide considerable leverage in creating higher-level data objects. 
     Referring now to FIG. 3, the properties of inheritance may be used to create combination instanced database-objects  46   a  and  46   b  from instanced database elements  44   a ,  44   b  and  44   c . The combination instanced database-objects  46   a  and  46   b  are defined by a template  44  similar to template  32  but providing the name of a combination database-object and referencing other database-objects in the structure portion as well as data types. In the former case, the template  44  incorporates the structure  40  of the templates  32  which it references. 
     Each combination instanced database-objects  46   a  and  46   b  may be rapidly created by identifying previously instanced database-objects  34 . Thus, combination instanced database-object  46   a  inherits the data of instanced database-objects  34   a ,  34   b  and  34   c  while combination instanced database-object  46   b  inherits the data of instanced database-objects  34   a ,  34   b  and  34   d . Thus combination instanced database-objects  46   d  may be rapidly created from pre-existing instances of lower level objects. This process can be repeated for an arbitrary number of levels of database-objects each formed of database-objects and data from a lower level. A reference of a given database-object may thus pass through many intermediate database-objects prior to reaching actual data elements  50 . 
     The hierarchical structure provides not only for rapid generation of new combination instanced database-objects  46  in a memory efficient way, but allows for the unrestrained definition of objects that are extremely variable in their data in an efficient manner as resulting from an effect in which highly variable high level objects may be constructed of less variable low level objects so that each level down in the hierarchy greater stability in the data is found. The ability to utilize this effect of the object oriented database structure requires proper definition of the high level objects and the objects from which they are created. Such a definition forms a key to the present invention which generally groups data elements  52  into database-objects  34  then database-objects  34  into higher database-objects  46  such that the elements of each group are highly correlated with respect to each other (inter-correlated) over different events. What this means is that it is likely that each new event object  46  can be constructed of pre-existing lower database-objects  34 . This simplifies creation of the event objects  46  and reduces instantiations of lower database-objects  34  such as uses storage capacity. 
     Referring now to FIG. 4, one example of the present invention provides such a structure in which a CUSTOMER combination instanced database-objects  46   c  may be defined from an ENTERPRISE instanced database-objects  34   a , an AGENT instanced database-objects  34   b  and a LOCATION instanced database-objects  34   c . Generally the ENTERPRISE instanced database-objects  34   a  will point to data elements  52  within the database providing: a name of an enterprise, its type of industry, its size, its purpose, its credit rating, its revenue, its profitability, and a parent organization, if any. Generally these will be text variables. The AGENT instanced database-objects  34   b  will point to data elements  52  of the database  30  providing: a first name, last name and middle initial of an agent, the job title of the agent, various information about the agent, the agent&#39;s purchasing authority, the agent&#39;s preferences, the agent&#39;s vocational discipline, and who the agent reports to. These will also generally be text variables. The LOCATION instanced database-objects  34   c  points to data elements  52  providing a description of a location of the enterprise and a site address which may include a conventional post office address providing street, suite, post office box, city, state, postal code, country and the like, and/or an Internet based address including a path, domain, a suffix, and a start address, and/or a telephone address including country code, area code, number and extension. 
     As will be understood, these data elements  52  of the LOCATION, ENTERPRISE and AGENT instanced database-objects  34   a-c  are relatively stable. 
     A CUSTOMER combination instanced database-objects  46   c  inherits the structures of each of the LOCATION, ENTERPRISE and AGENT templates  32  (not shown) and points to specific instances of the ENTERPRISE, instanced database-objects  34   a , the AGENT instanced database-objects  34   b  and the LOCATION instanced database-objects  34   c  per their instance numbers  48 . Thus CUSTOMER combination instanced database-objects  46   c  may be freely defined representing various combinations of pre-existing or newly instanced ENTERPRISE, AGENT and LOCATION instanced database-objects  34   a-c  without undue effort of memory usage. Generally many of the CUSTOMER combination instanced database-objects  46   c  will share one or more of the ENTERPRISE AGENT and LOCATION instanced database-objects  34   a-c  thus greatly simplifying their enrollment and providing for an efficient representation. 
     Referring now to FIG. 5, the CUSTOMER combination instanced database-objects  46   c  may in fact be part of a larger structure providing for a SALES EVENT high-level instanced database-object  56 . This database-object inherits the qualities of the CUSTOMER combination instanced database-objects  46   c , a PRODUCT combination instanced database-objects  46   d  and a FULFILLMENT combination instanced database-objects  46   e  and like the CUSTOMER combination instanced database-objects  46 , may take on data values from specific instances of each of these combination instanced database-objects  46   c  through  46   e.    
     The PRODUCT combination instanced database-objects  46   d  in turn is based upon objects of a PRODUCT DESIGN instanced database-objects  44   d , DESCRIPTIVE CONTENT instanced database-objects  44   e  and BUSINESS OWNERSHIP instanced database-objects  44   f . These database-objects may include intermediate objects as well. The FULFILLMENT database-object may in turn be made up of instanced database-objects  44   g  of LOGISTICS, instanced database-objects  44   h  of MANAGEMENT MANUFACTURING SUPPLY CHAIN, and instanced database-objects  44   i  of SERVICE which may include intermediate objects as well. 
     The structure as shown in FIG. 5 also allows for the generation of additional high-level instanced database-objects  58   a  through  58   c  made evident by this structure in various combinations of combination instanced database-objects  46   c  through  46   e . For example, a CONTRACT high-level instanced database-object  58  may be defined as the combination of the CUSTOMER and PRODUCT combination instanced database-objects  46   c  and  46   d . A COMPLIANCE additional high-level instanced database-object  58   b  may be defined as the combination of PRODUCT combination instanced database-objects  46   d  and FULFILLMENT combination instanced database-objects  46   e . Further a FINANCE high-level instanced database-object  58   c  may be defined as the combination of a CUSTOMER combination instanced database-objects  46   c  and a FULFILLMENT combination instanced database-objects  46   e.    
     It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein, but modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims.