WO1997033241A1 - System and apparatus for loading and retrieving information - Google Patents

System and apparatus for loading and retrieving information Download PDF

Info

Publication number
WO1997033241A1
WO1997033241A1 PCT/US1997/003615 US9703615W WO9733241A1 WO 1997033241 A1 WO1997033241 A1 WO 1997033241A1 US 9703615 W US9703615 W US 9703615W WO 9733241 A1 WO9733241 A1 WO 9733241A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
dmr
record
source
software component
Prior art date
Application number
PCT/US1997/003615
Other languages
French (fr)
Inventor
Keith B. Ballurio
Matthew R. Edlestein
Brian B. Puckett
Original Assignee
Information Projects Group, Inc.
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.)
Filing date
Publication date
Application filed by Information Projects Group, Inc. filed Critical Information Projects Group, Inc.
Priority to AU20730/97A priority Critical patent/AU2073097A/en
Publication of WO1997033241A1 publication Critical patent/WO1997033241A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing

Definitions

  • This invention relates to an information management system, particularly a system suitable for developing and administering large and complex centralized or distributed databases Unlike conventional database systems, the system and apparatus for loading and retrieving information does not store data records in static, structured tables or files Instead, the system stores all data in a common data repository The data stored in this repository are "independent" of the source records and the source fields used for data entry and display The system allows hierarchical, network, and relational dynamic record alignment, which provides multiple database managers with the flexibility to structure data according to each manager's needs.
  • a manager In order to cross-reference related information from one table to another, a manager must conduct multiple searches across a number of tables or even databases As the relationships between desired information becomes more and more complex, a manager must conduct many searches to obtain a complete set of cites or references. To avoid conducting multiple searches, a manager may simply store data in a raw text block and employ a full text query to search for relevant information. This solution, while avoiding the problem of multiple searches, prevents a manager from itemizing or categorizing data found using the query and also prevents a manager from using fields to further describe the information found.
  • a hierarchical database structure uses one- way pointers to relate tables together in a fixed parent-to-child relationship.
  • a hierarchical database constructs a one-to-many relationship between tables that looks like a tree. This hierarchical structure aids in understanding the relationship of a particular table with respect to other tables in the hierarchy, yet this rigid relationship limits the types of information that can be available on any particular table in the hierarchy.
  • a network database structure is similar to a hierarchical structure in that tables are related in a fixed manner using pointers.
  • a network structure uses two-way pointers to create a many-to-many relationship between tables that looks more like a web than a tree.
  • a network structure has duplexed relationships between tables, rather than the one-way parent- child relationships of a hierarchical structure.
  • a network database system can support a pure hierarchical structure as required.
  • a relational database structure is not a navigational structure and does not have fixed pointers from one table to another.
  • a relational structure consists of indices that are not limited to a hierarchical structure, but nevertheless relate records to each other. Relational databases operate using the principle of commonality between record formats to relate records to each other. For example, a "Name and Address” table might contain a "Customer Number.” Associated tables, such as "Customer Orders,” “Customers Handled,” “Credit Profiles,” and “Customer Complaints” might also include a ustomer um er e , w c wou e use o assoc a e recor s n e various tables
  • Relational database indices can be either single-key or multiple-key.
  • a single-key index is one column, usually with entries in an ascending or descending order, that point to individual records.
  • a single-key index could be a list of customer numbers in ascending order.
  • a multiple-key index uses more than one column and allows several columns to point to the same record.
  • a second index could be a list of customer surnames in alphabetical order.
  • Relational linkage structure enables records to be accessed and viewed from different perspectives, however, relational indices do not convey the relationship between individual records as well as hierarchical and network tables do. Also, hierarchical and network databases retrieve queries faster and use less computer processing power than relational databases, because the relationships in hierarchical and network databases are pre-established.
  • the system and apparatus for loading and retrieving information is a computer-implemented superstructure over an existing relational database management system
  • the system uses hierarchical, network, and relational structures to establish and maintain relationships between data, fields, and records in the system. Initially, the system uses hierarchical structures to order massive amounts of information possibly obtained from various disparate, distributed sources Next, the system uses a network structure to cross-reference related data residing in different hierarchical structures Finally, the system uses a relational structure to access the various hierarchical and network structures and report results of user queries
  • the system establishes in memory a common data repository for disparate data with disparate record structures originating from different sources within an organization or many different organizations
  • the common data repository is held on disk located in the server.
  • the system holds some (the most recent) information in the physical memory of the server, but all data is held in permanent storage on disk.
  • the physical storage of the repository is limited only by the number of servers and drives of the linked system Almost all current hardware and operating system platforms allow for the connection and sharing of distributed information across multiple machines of the same type, therefore, the repository for all intents and purposes, can be unlimited.
  • each source field When source data enters the system, the common data repository stores each source field independently from its source record definition.
  • the basic storage unit a "block,” needs to be introduced.
  • the system exploits a variable length character field structure to store the field definitions and other information in a computer's storage devices in a single, variable length, appendable flat file.
  • These variable length character fields are formed into a base data storage unit called a block.
  • Each block contains a Record Type ID, chain reference information, a unique Record ID, an Aspect string for referential integrity, several internal system IDs, and a data array that is a matrix of one hundred positions that can grow to 175 characters each.
  • DMR data modeling record
  • the system can store each DMR and field independently and in relation to any number of other fields and DMRs.
  • the source record definition does not determine the structure of the data storage, instead it merely provides a means for referencing data using relevant fields.
  • the record definition resides "above" the common ata reposi ory an a ows a a o remain in epen en o e source recor structure
  • the system unifies different DMR structures for purposes of uniform query reporting, and it allows individual application managers to manipulate and present data uniquely One information manager may even point or link to another manager's data to create a virtual information management environment
  • An advantage of this invention is that it facilitates multiple management of and multiple access to disparate data in computer memory without concern for the source field and source record structure of the data
  • Another advantage of this invention is that it provides a system that supports hierarchical, network, and relational record alignment
  • Other advantages of this invention are that it allows any record in the system to act as a menu, filter, or gateway to other records or applications and to provide a data security system that gives multiple information managers sophisticated control over access to data and applications within the system
  • Another advantage of the system is that it allows continuous modification of the data without computer system down-time.
  • Figure 1 shows a preferred embodiment using hierarchical, network, and relational structures.
  • Figure 2 shows a data modeling record (DMR) with three blocks incorporating data from Tables A and B.
  • DMR data modeling record
  • Figure 3 shows a source field and source record structure for Table A.
  • Figure 4 shows a source field and source record structure for Table B.
  • Figure 5 shows a schematic for a loader.
  • Figure 6 shows a schematic for a query engine.
  • Figure 7 shows query results.
  • Figure 8 shows a rights matrix
  • Figure 9 shows a schematic for an intelligent DMR command executor.
  • the preferred embodiment is designed as a computer-implemented superstructure for use with existing relational database management systems (RDBMSs) such as Progress RDBMS, designed by PROGRESS Software Corp., Bedford, Massachusetts RDBMS structure is processor intensive, because the retrieval of related records forces heavy processing by the database management system to establish current relationships
  • RDBMSs relational database management systems
  • the RDBMS uses a computer to direct the creation of the common data repository, the hierarchical linking of data modeling records (DMRs), the network linking of blocks withm a DMR, the query engine, the intelligent DMR, and the rights matrix.
  • DMRs data modeling records
  • FIG. 1 shows related DMRs linked using hierarchical, network, and relational structures according to the preferred embodiment.
  • Each hierarchy 11, 12 includes a single root DMR 111, 121 and multiple children DMRs linked using one-way pointers. Pointers, both one-way and two-way, are stored as references to the linked item within DMR blocks, specifically within each DMR's data array.
  • hierarchy 11 may represent a mail-order database for a mail-order company with one general division and two specialty divisions. Such a database may contain customer "Name and Address" DMR 111, customer "Credit Profiles" DMR 112, "Customer Orders -
  • Hierarchy 12 may be a human resources database for the employees of the mail order company with employee "Name and Address” DMR 121, “Customers Handled - General” DMR 122, employee "Timekeeping and
  • two-way pointers 141, 142, 143, 144, 145 establish network links between the two hierarchies 11, 12. Like one-way pointers, two-way pointers are stored references with the blocks at each end of the linked reference - A points to B, and B to A. These two-way pointers provide further perspec ve to e var ous s.
  • e us omer r ers - Automotive" DMR 116 of hierarchy 11 may be linked to the "Customers Handled -- General" DMR 122 and to the "Customers Handled - Automotive" DMR 125 using, two-way pointers 143, 144 so that when a user views hierarchy 11, the user can also see whether a automotive division customer order was handled by an employee of the mail order company's automotive division, despite the fact that the "Customers Handled" DMRs are not children of hierarchy 11. Conversely, if a user is traversing hierarchy 12, the user can see related DMRs from hierarchy 11 through the network links even though those DMRs are not children of hierarchy 12. If desired, two-way pointers may also be established within a single hierarchy as well as between two hierarchies.
  • Figure 1 also shows relational structure 13 with a single-key alphabetical index.
  • the preferred embodiment uses a unified single-key alphabetical index into which every common repository DMR is placed. This index is held in the traditional RDBMS that is incorporated "under" the system and stored on a server's storage devices.
  • Each key in the relational structure 13 has a one-to-one relationship with every DMR in each hierarchy 11, 12. This relational structure can be used to access quickly the various hierarchical and network structures. Note that the various hierarchical structures may be products of not only different divisions within a single company, but they may also be products of completely different companies.
  • the preferred embodiment is based upon the use of DMRs, rather than tables, as basic building units for hierarchical structures.
  • data structure rules developed by individual managers control the development of a hierarchy.
  • Data structure rules may allow only certain types of Record Types to be hierarchical children of a certain DMR.
  • Information may be entered in a number of different ways depending on the number of Record Types a manager has created. Part of the root block content is the Record Type ID. All associated DMR blocks must contain the same Record Type ID. All DMR block information is held within the flat file on the services storage devices.
  • Record Types define the basic fields used in a particular type of DMR. For example, an "article” Record Type may contain "author,” “title,” “date of
  • Recor Type may contain "name,” “date of discovery,” “description,” “use, ' and “chemical symbol” fields. According to a preferred embodiment, up to 1000 Record Types, such as persons, locations, bibliographic, books, conference, notes, topics, or projects, may be defined by multiple managers of the system.
  • Record Types may be diverse and contain no common fields
  • a manager's data structure rules may allow these different Record Types to reside in a single hierarchy. This allows for great flexibility in entering and listing data.
  • more than one data structure can contain a particular Record Type, and a Record Type may have any number of fields in common with another Record Type.
  • Figure 2 shows a DMR with three blocks incorporating data from Table A of Figure 3 and Table B of Figure 4.
  • a DMR contains at least one and at most 999 blocks. If more blocks are needed in a single DMR, however, blocks from two or more DMRs can be bound together to make a larger DMR. Blocks are bound together as required by storing the next block sequence number in one of the Internal System ID areas of the "owning" block, be this the root block or one of the subsequent blocks. In this manner, blocks can be bound together in unlimited fashion.
  • a block may be created and maintained by a RDBMS such as Progress under the direction of the system. The block contents are stored as part of the contiguous single flat file on a server ⁇ storage devices.
  • Each DMR contains at least a root block 50 as shown in Figure 2.
  • a DMR may also have one or more non-root blocks 51, 52. Both the root block and non-root blocks contain system fields. All blocks include the following system fields: Term
  • Block types either a root or a child, are differentiated in an internal system ID area of the block.
  • the system has a global definitions methodology that defines the values to be stored for the different types.
  • the system uses the underlying RDBMS to store the system global definitions. These are kept in separate flat files on the server machine.
  • the Record Type is "153,” which a manager may define as the numeric identifier for an “automobiles” Record Type.
  • Record Type 153 may contain the fields "owner,” “make,” “model,” “year,” “dealer,” “color,” “license plate number,” “date of purchase,” and “warranty information” as defined by a manager.
  • Root In addition to the system fields listed above, a root block contains two unique additional system fields that relate each DMR to a hierarchy: Root
  • each DMR has a place in one hierarchical database structure having a root DMR.
  • the Root Record Identifier contains the Record Identifier of the root DMR in a DMR's hierarchical structure.
  • the Aspect contains a string of Record Identifiers tracing the hierarchy of the DMR.
  • the Root Record Identifier in this example is "111,” which is the Record Identifier for the DMR with the Term "Name and Address” in the customer hierarchy 11 shown in Figure 1.
  • the Aspect, "111:113” represents that the DMR with the Record Identifier "113" is the parent of the instant DMR, and that the DMR with the Record Identifier "111" is the grandparent of the instant DMR.
  • Every Aspect lists all of the parents of the instant DMR, from the direct parent to the root DMR of the hierarchy.
  • the system fields indicate that the DMR shown is in a hierarchical structure of data for mail-order customers related to each other through customer order classification.
  • the Root Record Identifier and the Aspect are used mainly to maintain the hierarchical referential integrity of the system.
  • Each block also contains a first data array called Chain-1.
  • Chain-1 a first data array
  • all of the block content is stored contiguously in a flat file on the system server.
  • the title of the Chain-1 data array maintains the order of the blocks within a DMR.
  • the title of the Chain-1 array of the root block contains the Record Identifier plus the suffix ".0" while the title of the Chain- 1 array of non-root blocks contain non-zero suffixes.
  • the convention of the system is to indicate root blocks with the suffix ".0" in the Chain- 1.
  • Non-root blocks are usually assigned suffixes in ascending order.
  • a Chain- 1 data array contains a single-column with the look-up references to data entries.
  • a data array may have up to 100 alphanumeric look-up references and 50 real number look-up references.
  • a look-up reference can refer to almost any type of data, such as alphanumeric characters, integers, decimals, date/time, program applications, graphic pictures, digitized voice, spread sheet data, or word processing data
  • a block may have an unlimited number of data entries, because two or more 150-field blocks may be bound together to compose a larger unitary block
  • Figure 2 shows the contents of the root block data array 50 including look-up references to owners, automobile make and model, automobile color, and automobile year
  • a Mapper catalogues the source fields for each datum and notes that a "name" is in data array elements 0-25, an "automobile make” is in data array elements 26-45, an “automobile model” is in data array elements 46-70 and so forth
  • there are several processes or procedures such as the Mapper, preferably written in
  • Block 51 contains information pertaining to purchase orders.
  • the Chain- 1 data array contains look-up references to shipping addresses, date of order, date order filled, item number, quantity, and color.
  • the data array contains look-up references that describe payment methods, type of payment and subtotal, tax, shipping, and total.
  • the Mapper When used by another program, whether in a create record sequence or look-up record query sequence, the Mapper will use the block ID information held in the internal system area to negotiate to succeeding blocks.
  • Each DMR also contains a unique Cha ⁇ n-2 data array that contains
  • Chain-2 data arrays are contained per DMR; they are specific to each DMR, not just to any block, and they contain internal system fields to identify and associate the array to the DMR.
  • the "owners" elements in Chain- 1 of the root block in the DMR in Figure 2 have a Chain-2 network linkage to Record Identifier 550 to a DMR with the Term "U.S Telephone Directory.”
  • the Chain-2 also lists the Record Identifiers to the parents of the directly-lmked DMR, such as Record Identifier 547 to a DMR with the Term "North American Telephone Directory” and Record Identifier 593 to a DMR w th the Term "Global Telephone Directory "
  • the Cha ⁇ n-2 data array a so contains a irect networ n age rom item num er oo -up references in the Cha ⁇ n-1 of block one 51 to a DMR with the Term "Catalog” and other direct network linkages from "
  • Chain-2 data arrays may be used to link not only related DMRs, but Chain-2 linkages may also be used as a gateway to processes such as ordering a document, downloading a file, or starting an electronic mail subsystem.
  • the contents of the data array would be made up of the particular commands required to perform the specific action. For example, to download a file, the data array would contain the specific commands to connect, open the file, and close the file.
  • the Chain-2 data array, which is per DMR, is contained in the file structure of the preferred embodiment. For instance the "total" look-up references in block two 52 could be network linked to a "print receipt" process.
  • Source table A represents manufacturer orders of automobile parts.
  • the fields available in source Table A are: dealer number, date of order, customer name, year of car, model of car, item number, quantity, and warranty information.
  • Source table B represents automobile replacement parts orders.
  • the available fields in Source table B are: name, address, make, model, catalog number, description, color, quantity, price per item, subtotal, tax, shipping, total, payment type, and account number.
  • FIG. 5 shows a schematic for a loader that can be implemented on a computer.
  • a loader as shown in Figure 5 can load data from disparate data sources with disparate record structures into a single data repository.
  • the loader can take the source tables shown in Figures 3 and 4 and integrate them into a single DMR as shown in Figure 2.
  • the "customer name” field in source Table A contains the same type of information as the "name” field does in source Table B.
  • the "model of car” field in source Table A contains the same type of information as the "model” field of source Table B.
  • the loader can blend source Tables A and B into a cohesive whole for use in, for example, a "Customer Orders - Automotive" DMR, while allowing managers and users of the individual systems to operate on the individual systems as if the original systems were unchanged.
  • Source data 20 can be either derived from a pre-existing table transferred using magnetic tape or other machine structure or keyed into the loader using a computer keyboard.
  • 4GL program on file inspects the source data and segregates the source data according to source fields and source records using field delimiters (for example, a TAB character) and record delimiters (for example, a hard RETURN character).
  • the segregated data is sent to a Block Creator 28, preferably implemented by a 4GL program on file.
  • the typer also determines an applicable Record Type, such as persons, locations, documents, or projects, from the types available for this database. According to a preferred embodiment, there are 1,000 available Record Types, each having a unique programmable format.
  • the Record Type is sent to the DMR Creator 22, preferably implemented using a 4GL program on file, which initiates a call to a DMR Sequencer 23, which is preferable a 4GL program on file that maintains and generates a unique sequence for Record IDs.
  • the DMR Sequencer 23 returns a unique identifier for each DMR to be created by the DMR Creator 22.
  • DMR Creator 22 establishes the system fields for a DMR, such as Term, Record Identifier, Record Type, Root Record Identifier, and Aspect. These system fields are also sent to Block Creator 28.
  • the names of the source fields used in the source data 20 are sent from the typer 21 to the mapper 24.
  • the mapper 24 places look-up references to data in the Chain- 1 data array based on Mapper rules and the source field names. Field names are stored inside the Root block of that field s DMR.
  • a Chain- 1 data array element may be forcibly linked to a DMR using the Chain- 2 data array based on the name of the source field.
  • data from a source field "item number” in the Chain-1 data array of block one may be forcibly linked to a DMR with the Term "Catalog.”
  • data from a source field named "colors” in the Chain-1 data array of block one may be forcibly linked to a DMR with the Term “Color Chart.”
  • data from source fields named "make” and "model” in the Chain- 1 data array of block two may both be forci y lin e to a containing a taxonomy o automobile classifications
  • links between hierarchies may be made based on a set of linking rules 27 preferably stored as a 4GL program on file
  • the linker 25 may survey the hierarchies already residing in the common data repository 29 The linker looks at the Cha ⁇ n-2 data arrays of all the associated hierarchy DMRs in the repository using the single key alphabetical index It scans the array for the current Record ID to see if any mention a link that applies to the current rules If they do, then these associated DMRs are entered into the current DMR s Cham-2 data array as having additional links to these other DMRs
  • the linking rules may direct the linker 25 to enter into a Cha ⁇ n-2 data array appropriate network pointers similar to pointers 141-45 shown in Figure 1.
  • Block Creator 28 can construct blocks to form a DMR
  • the Block Creator 28 is preferably a 4GL program on file. When completely constructed in memory, blocks are stored in the RDBMS.
  • the Block Sequencer 27 returns a unique block identifier for each block to be created by the Block Creator 28
  • the Block Sequencer 27 is a 4GL program on file that maintains and generates a unique sequence for Record IDs
  • the DMRs are hierarchically linked according to instructions found in each root block
  • the data is then stored in a common data repository 29
  • the preferred embodiment may support large-scale multi-user information services that require real-time operational management and limited downtime. Prior database systems may require that the data be taken off-line before changes to field and record definitions can be made. This period of down-time is not only inconvenient for users, but it can also result in significant loss of revenues to the information provider
  • a manager may add data, add
  • Block Types add Record Types, and assign new fields while the system is still on-line
  • a manager may make any modification that does not affect currently an open DMR.
  • Interaction to the system can occur in three different manners: (1) through a new script processing language developed for the system, (2) through embedded ANSI standard SQL scripts executed from within the new script processing language; and (3) through the included RDBMS commands and features, which can only be performed against the RDBMS database, not the system as a whole. All three of these methods use script files written with any standard editor.
  • the system simply modifies the mapping rules to specify the new field. This does not affect any users of the DMR at the time.
  • a manager seeks to make modifications such as adding data that would affect an open DMR, the preferred embodiment would prevent the modification from occurring at that time. The preferred embodiment would delay the implementation of the modification until the DMR was not being accessed. Alternatively, the system could simply bar the manager from trying to make the modification at that time.
  • RDBMS relates, searches, and finds data as it is in the database flat file, the return of the data is ordered by the contents of the index used to search it (or with an "order by” clause).
  • the preferred embodiment uses both a horizontal and vertical "connecting" of the data through the horizontal and vertical structures, and it is this extra horizontal index based on the vertical index key that adds order to the resultant return set.
  • the system uses a "unified index structure.”
  • the preferred embodiment uses a "unified single key alphabetical index” into which every common repository DMR is placed. This index is held in the traditional
  • the unified index structure operates in at least two dimensions. Preferably, the first dimension, horizontal, allows single-key indexing all of the DMRs as one numeric index according to Record Identifier.
  • the relational structure 3 (shown in Figure 1) is the structure used to establish and maintain the single-key index. Because the unified index structure is pre-established, associations between DMRs can be determined by working with only the single-key index. The actual data do not need to be retrieved from the common data repository 29 until the relational operations are completed.
  • This unified index structure provides quick retrieval for even the most complex queries, minimum processing overhea for the database server, and the ability to segment the processing overhead on multiple processors in a multi-processor or client-server environment
  • the preferred embodiment uses matrix operations and filtering to refer to any block within a DMR as a subset of the first dimension of the unified index structure.
  • the linker 25 (shown in Figure 5) associates field names with other DMR hierarchies to augment second-dimensional links between DMRs.
  • This single-key index can be manipulated to establish sorts within sorts, relational structures, query results, and other operations.
  • Figure 6 shows a schematic for a database management system query engine that can be implemented using a computer.
  • This incoming request is sent to the Macro Constructor 61, preferably a 4GL program on file, which parses the incoming request into its constituent boolean operations and variables.
  • This data output is sent to a Language Generator 62, preferably implemented using a 4GL program on file, which translates the boolean operations into an executable address.
  • the translated query is sent to the Query Optimizer 63 preferably implemented using a 4GL program on file, which creates an optimized executable search and simultaneously checks the query for validity.
  • the Query Optimizer returns an executable pointer address relating to the query, which is then sent to the Macro Constructor 61.
  • the Macro Constructor 61 enables the Query Extractor 64 to survey the common data repository 29 for the requested variables.
  • the Query Extractor 64 preferably a 4GL program on file, matches found query variables against the single-key horizontal index, which means when a user queries the common data repository, the Query Extractor will find the results in reference to the Record Identifier.
  • the Query Extractor 64 preferably a 4GL program on file, matches found query variables against the single-key horizontal index, which means when a user queries the common data repository, the Query Extractor will find the results in reference to the Record Identifier.
  • the Query Extractor continues to survey the common data repository 29 until no more Record Identifiers are returned
  • the Display Manager 65 preferably implemented using a 4GL program on file, formats the query results according to the display selection preferred by the user (or the default display selection)
  • the default display selection format preferably shows query results according to Record Identifier, Term, and Record Type.
  • Display Selection formats could be either a listing by Record Type only, or a listing by Term only, or even a listing by source table
  • the output of the Display Manager goes to a display such as a monitor
  • the display selection may also control the display border, the margins, the font, and the colors used in the display.
  • a user may inquire who assisted Mark Daniels in purchasing automobile tires
  • the Incoming Request may be: "Mark Daniels” AND “tire” AND “hierarchy (12)”
  • a query variable that is a name e.g , "Mark Daniels”
  • a search for the surname alone e.g., "Daniels”
  • first and last names with or without a middle name or middle initial (e. , "Mark” within 2 of "Daniels”).
  • Optimizer 63 the query engine will traverse DMRs in hierarchy 12 for references to "Mark Daniels” and “tires” in the Chain- 1 and Cha ⁇ n-2 data arrays.
  • the query engine will search the common data repository 29 for every entry of "Mark Daniels” to find every data array (Cha ⁇ n-1 or Cha ⁇ n-2) that contains a look-up reference to "Mark Daniels " Once a first DMR is found that corresponds to the variable "Mark Daniels," the Record Identifier of that DMR is returned to the Query Extractor 64.
  • the Query Extractor 64 will inspect the Chain- 1 and Chain-2 arrays of that DMR for a reference to "tire " If the DMR contains a reference to "tire,” the Query Extractor 64 inspects the DMR for a Chain- 1 or Cha ⁇ n-2 reference to “hierarchy (12) " If the DMR contains references to all three variables, the Record Identifier is sent to the Display Manager 65 for appropriate display If at any time the Query Extractor 64 finds that the DMR does not contain a query variable, the Query Extractor 4 oes not pass t e ecor Identi ier to t e isp ay Manager 65.
  • the query engine has found a look-up reference to "Mark Daniels," because look-up references are stored in Chain- 1 data arrays. Possibly, the Chain- 1 data array is associated with the customer "Names and Addresses" DMR 111 shown in Figure 1.
  • the Query Extractor 64 looks for query request variable "tire" in either the Chain-1 or Chain-2 data array of the found DMR.
  • the query engine has found a single DMR with look-up references to both “Mark Daniels” and “tire.”
  • the Query Extractor 64 looks for a reference to "hierarchy (12)" in the Chain- 1 and Chain-2 data arrays of the found DMR. If the Query Extractor 64 finds such a reference, the Record Identifier of that DMR is passed to the Display Manager 65.
  • Finding a query variable in a Chain-2 data array signifies that the found DMR contains a network reference pointer to the variable, because only network references are stored in a Chain-2 data array.
  • a network reference pointer to "hierarchy (12)” is stored in the Chain-2 data array of the "Customer Orders - Automotive" DMR 116.
  • DMR 116 containing two variables, "Mark Daniels” and “tires,” in a Chain- 1 data array and the final variable, "hierarchy (12),” in a Chain-2 data array is also passed to the Display Manager 65.
  • the query engine may return many Record Identifiers, each containing a reference to "Mark Daniels” AND “tire” AND “hierarchy (12).” There may be multiple "Mark Daniels” entries in the common data repository 29. Also, the query engine may return DMR references to automobile tires, bicycle tires, or other types of tires, because the query does not specify a certain type of tire.
  • Figure 7 shows query results.
  • the display will usually show the Term of the DMR containing the Chain- 1 result as shown in screen 72.
  • the user can instruct the system to display different information as the query result, such as the Record Type as shown in screen 73.
  • a found DMR's Term in this case could be "Customer Orders - Automotive.”
  • the user could check that DMR to find the entry that the user was specifically looking for.
  • the query results are displayed in alphanumeric order
  • the user of the system could enter the "Customer Orders - Automotive" DMR 116 (from Figure 1) and look for Mark Daniels, which could be highlighted or otherwise indicated
  • the user can also immediately link from "Customer Orders - Automotive” DMR 116 (from Figure 1) in another hierarchy and go to "tires", which may be highlighted
  • the user of the system may or may not know that the entry "tires" is not in the same hierarchy or DMR from which the user is presently operating
  • a user can browse through a selected hierarchy with only minor processing.
  • the user may see additional two-way pointer references to other DMRs containing a look-up reference for "Mark Daniels" in the Chain-1 data array.
  • the user can immediately look at all the references and know that Mark Daniels is linked to DMRs with Terms such as "Universities” and “Companies.”
  • a user can also maintain the reference to "tire.” By maintaining this reference, a user keeps a filter on while perusing down the "Customers" hierarchy 11 (from Figure 1) and network linkages. So, "tire” will always appear, and the user can look for types of tires such as radial tires, snow tires, or bicycle tires.
  • the Display Manager 65 may display an updated summary of query responses as the user travels through different hierarchies. As a user traverses hierarchies and perhaps enters a hierarchy that contains fewer and fewer query variables, the updated summary will show that fewer and fewer DMRs contain results of the query.
  • Figure 8 shows a rights matrix.
  • the preferred embodiment rights matrix is a Progress RDBMS table used at the system level for subsystem control. Another aspect of the preferred embodiment is multiple control domains within the common data repository. Most databases offer two levels of basic security (user vs. nonuser & user vs. superuser). The preferred embodiment provides an additional level of security through individual subsystem operational control. A rights matrix controls access and use of the subsystems and the discrete functions encompassed in those subsystems.
  • Figure 8 shows eight levels of security, with level 8 being analogous to a superuser The preferred embodiment can support any number of security levels with preferab y t e highest security level hav ng access to a subsystems.
  • a manager at level 6 may use the functions for creating, deleting, and modifying DMRs as well as creating, deleting, and modifying fields.
  • each subsystem as well as its underlying functions appears as a discrete element. This enables a manager to decide exactly which rights are assigned to certain user groups on a function-by-function basis. Every request to access a function is matched against the rights matrix before the function can be performed. User level and subsystem requested are looked up in the rights matrix table for permission.
  • the preferred embodiment also provides a second level of security which is DMR-specific -- controlling the security of data, the format of data, and the usage of data on the DMR level.
  • This resident intelligence located in a Chain-4 data array (shown in Figure 2) section of a DMR, is programmed by the application owner and the data owner and interacts with the rights matrix.
  • a manager may determine which DMRs have read/write privileges for certain user groups.
  • a manager may determine whether to allow others to modify a DMR or even reply to notes in a conference.
  • This level of control enables a manager to have complete control in a shared system. For example, in Figure 2, case 1 shown in Chain-4 does not allow a user access to block two
  • Case 2 shown in Chain-4 of Figure 2 is applicable to a user having a color monitor.
  • the system can establish formats for a particular DMR, create associations (or pointers) to other data, implement security controls, and trigger applications for use with a particular DMR.
  • the control property could load an appropriate word processor and display a file in the word processor format when a manager retrieves a "word processing text file" from one of the variable length fields in a block.
  • a document image contained in a DMR field could be automatically displayed by the appropriate graphic image display application.
  • accessing a DMR imported from an Oracle"" database could trigger a control event to check the remote database for the last time the DMR was updated.
  • igure s ows a sc ema c or an in e igen comman executor Intelligent commands (triggers) are held in the system DMR Cha ⁇ n-4 data arrays If a user processes a DMR with Cha ⁇ n-4 array content that performs an action, then that action will "trigger.” If a user trips a DMR trigger, the Record Identifier of the DMR is sent to the script language processor 81, preferably a 4GL program on file, which starts the operation of the resident intelligence in the DMR Cha ⁇ n-4 arrays.
  • the various triggers include: requesting to read data in a DMR, traversing through a DMR to see hierarchical children DMRs, traversing back through a DMR to see hierarchical parent DMRs, using a DMR as a menu, requesting to trigger the
  • triggers are in the context of an event-driven model.
  • a trigger When a trigger is tripped, the user starts an event that completes a particular action.
  • data-driven models where data can reprogram the user interface. For example, if the data value of the field matches a criteria held in the Chain-4 array, then the instructions to download and execute a new version of the user interface "xx.exe” file could be performed, which would result in a "reprogrammed” user interface.
  • the system merges the event-driven model with the data-driven model by allowing an event to gather or rearrange information, and then allowing that information to dictate the user interface.
  • the information returned by the event could allow a DMR to act as a menu, a filter, or a gateway to other DMRs. In this situation, the user interface responds to the data returned by the event.
  • the Record Identifier is sent to the script language processor 81.
  • the script language processor inspects the Chain-4 of the DMR for instructions corresponding to the trigger that was tripped. These instructions, if present, are sent to the logic unit 82 for translation into executable code.
  • the output of the logic unit 82 is sent to a rights matrix unit 83 that checks whether the instruction can be performed based on the user ID. If the instruction cannot be performed by the user, a disabled signal is sent through the object processor 85, and control returns to the script language processor 81. If, however, the rights matrix unit 83 sees that the user is allowed to perform the requested event, an enable signal is sent to memory unit 84, and the memory unit controls the read/write capabiUties to the object processor 85.
  • the object processor 85 may include controls to , , . - also direct the DMR to act as a menu, a folder, or a branch point to another gateway.
  • a trigger of requesting to read a particular DMR could direct the front end view system to present detailed order information (including addresses and account numbers) for a user who is employed to take those orders. If, however, the user is not employed to take orders, the view system may only present a summary of all the orders in the DMR and omit sensitive information such as addresses and account numbers.
  • two types of users may be looking at the same initial DMR. From that DMR, both users may trip the same trigger, but User A might take one path and see a submenu with certain options listed while User B might see a submenu with completely different options listed. This branching depends on the instructions programmed in the Chain-4.
  • the view and reporting preferences of each user can also be fused with the Chain-4 instructions programmed by the application owner and the data owner.
  • Each user may have a personalized set of views and preferences including screen color preferences and border styles. Therefore, identical events triggered by User A and User B create very different results partly determined by the data owner and partly determined by the preferences of the user.
  • the system may develop, integrate, and administer large and complex databases using hierarchical, network, and relational structures. This system may, of course, be carried out in specific ways other than those set forth here without departing from the spirit and essential characteristics of the invention. Therefore, the presented embodiments should be considered in all respects as illustrative and not restrictive and all modifications falling within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Abstract

The system and apparatus for loading and retrieving information relates to a computer-implemented database management system for multiple source databases. The system also has a variety of database management tools. The system uses hierarchical, network, and relational structures to establish and maintain relationships between disparate categories of information in multiple records or databases within the system. Data entered into the system are stored in a common data repository in disk memory, which categorizes each source field independent form the source record definition. Separating the source record definition from the fields within each source record definition allows data to remain independent from the original structure of the information. Yet, source record definitions are maintained to show the relationships between data from different fields. The system allows all data to be referenced by any number of methods without regard to how the data was entered into the system. The system also allows any data modeling record (DMR) in the system to act as a menu, filter, or gateway to other DMRs or applications and to provide a data security system which gives a database manager sophisticated control of access to all DMRs and applications within the system. The system also provides for continuous modification of the database without any system down-time.

Description

LOADING AND RETRIEVING INFORMATION
BACKGROUND OF THE INVENTION 1 Field of the Invention This invention relates to an information management system, particularly a system suitable for developing and administering large and complex centralized or distributed databases Unlike conventional database systems, the system and apparatus for loading and retrieving information does not store data records in static, structured tables or files Instead, the system stores all data in a common data repository The data stored in this repository are "independent" of the source records and the source fields used for data entry and display The system allows hierarchical, network, and relational dynamic record alignment, which provides multiple database managers with the flexibility to structure data according to each manager's needs.
2. Discussion of the Related Technology
Conventional database systems store records containing data in static tables. Each table has a number of predetermined fields that are often represented as columns, and each record, often represented as a row, contains information corresponding to each predetermined field. A manager using conventional database technology must initially determine how to structure information into fields and records The manager must decide the types of fields that will be used to store different categories of data and the collection of fields that will be used to construct tables of information. A drawback to this traditional approach to database technology is that a single table is unable to store multiple records that have some type of relationship yet do not contain identical fields. In order to cross-reference related information from one table to another, a manager must conduct multiple searches across a number of tables or even databases As the relationships between desired information becomes more and more complex, a manager must conduct many searches to obtain a complete set of cites or references. To avoid conducting multiple searches, a manager may simply store data in a raw text block and employ a full text query to search for relevant information. This solution, while avoiding the problem of multiple searches, prevents a manager from itemizing or categorizing data found using the query and also prevents a manager from using fields to further describe the information found.
Conventional database systems link tables either as a. hierarchical, a network, or a relational system. A hierarchical database structure uses one- way pointers to relate tables together in a fixed parent-to-child relationship.
A hierarchical database constructs a one-to-many relationship between tables that looks like a tree. This hierarchical structure aids in understanding the relationship of a particular table with respect to other tables in the hierarchy, yet this rigid relationship limits the types of information that can be available on any particular table in the hierarchy.
A network database structure is similar to a hierarchical structure in that tables are related in a fixed manner using pointers. A network structure, however, uses two-way pointers to create a many-to-many relationship between tables that looks more like a web than a tree. A network structure has duplexed relationships between tables, rather than the one-way parent- child relationships of a hierarchical structure. A network database system, however, can support a pure hierarchical structure as required.
Both the hierarchical and network database structures are based on a knowledge of the fixed location of tables. These structures are called navigational structures, which imply that a browsing user can understand the relationships between tables simply by traversing the structure. These navigationεd structures, however, sometimes suffer from the requirement of rigid pre-established relationships and the possibility of contamination of the one-way and two-way pointer chains. For the most part, hierarchical and network databases have been supplanted by relational databases, because relational databases do not require pre-planned relationships.
A relational database structure is not a navigational structure and does not have fixed pointers from one table to another. A relational structure consists of indices that are not limited to a hierarchical structure, but nevertheless relate records to each other. Relational databases operate using the principle of commonality between record formats to relate records to each other. For example, a "Name and Address" table might contain a "Customer Number." Associated tables, such as "Customer Orders," "Customers Handled," "Credit Profiles," and "Customer Complaints" might also include a ustomer um er e , w c wou e use o assoc a e recor s n e various tables
Processing in a relational database structure occurs at different times depending on the action that is taken by a user. For example, when a user performs a query against a table, the internal structures of a relational database are actioned to do things such as hold the table name, look into the system tables for any necessary contained or associated information (by key values or columns, etc ), point to the physical file location of the data, and place some of it (dependent on system global settings) into memory All of these differing types of system relational database actions then are stored or held as the last actions, so that the next action will be "short cut" if it is m the same vein or for the same kind of information. Generally speaking, the type, number, and content of the actions that the relational database takes to "process" any user request is based on the request type. Relational database indices can be either single-key or multiple-key.
A single-key index is one column, usually with entries in an ascending or descending order, that point to individual records. In the example above, a single-key index could be a list of customer numbers in ascending order. A multiple-key index uses more than one column and allows several columns to point to the same record. In the example above, a second index could be a list of customer surnames in alphabetical order.
Relational linkage structure enables records to be accessed and viewed from different perspectives, however, relational indices do not convey the relationship between individual records as well as hierarchical and network tables do. Also, hierarchical and network databases retrieve queries faster and use less computer processing power than relational databases, because the relationships in hierarchical and network databases are pre-established.
SUMMARY OF THE INVENTION The system and apparatus for loading and retrieving information is a computer-implemented superstructure over an existing relational database management system The system uses hierarchical, network, and relational structures to establish and maintain relationships between data, fields, and records in the system. Initially, the system uses hierarchical structures to order massive amounts of information possibly obtained from various disparate, distributed sources Next, the system uses a network structure to cross-reference related data residing in different hierarchical structures Finally, the system uses a relational structure to access the various hierarchical and network structures and report results of user queries The system establishes in memory a common data repository for disparate data with disparate record structures originating from different sources within an organization or many different organizations The common data repository is held on disk located in the server. The system holds some (the most recent) information in the physical memory of the server, but all data is held in permanent storage on disk. Depending on the hardware platform chosen, and the operating system used by that platform, the physical storage of the repository is limited only by the number of servers and drives of the linked system Almost all current hardware and operating system platforms allow for the connection and sharing of distributed information across multiple machines of the same type, therefore, the repository for all intents and purposes, can be unlimited.
When source data enters the system, the common data repository stores each source field independently from its source record definition. In order to define the storage parameters at the field level of the system, the basic storage unit, a "block," needs to be introduced. The system exploits a variable length character field structure to store the field definitions and other information in a computer's storage devices in a single, variable length, appendable flat file. These variable length character fields are formed into a base data storage unit called a block. Each block contains a Record Type ID, chain reference information, a unique Record ID, an Aspect string for referential integrity, several internal system IDs, and a data array that is a matrix of one hundred positions that can grow to 175 characters each. Then for each data modeling record (DMR) in the database, there is at least a root block and any number of additional blocks that identify that DMR as having multiple relationships to other DMRs and fields.
In this manner, the system can store each DMR and field independently and in relation to any number of other fields and DMRs. Thus, the source record definition does not determine the structure of the data storage, instead it merely provides a means for referencing data using relevant fields. In effect, the record definition resides "above" the common ata reposi ory an a ows a a o remain in epen en o e source recor structure The system unifies different DMR structures for purposes of uniform query reporting, and it allows individual application managers to manipulate and present data uniquely One information manager may even point or link to another manager's data to create a virtual information management environment
An advantage of this invention is that it facilitates multiple management of and multiple access to disparate data in computer memory without concern for the source field and source record structure of the data Another advantage of this invention is that it provides a system that supports hierarchical, network, and relational record alignment Other advantages of this invention are that it allows any record in the system to act as a menu, filter, or gateway to other records or applications and to provide a data security system that gives multiple information managers sophisticated control over access to data and applications within the system Another advantage of the system is that it allows continuous modification of the data without computer system down-time.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows a preferred embodiment using hierarchical, network, and relational structures.
Figure 2 shows a data modeling record (DMR) with three blocks incorporating data from Tables A and B.
Figure 3 shows a source field and source record structure for Table A.
Figure 4 shows a source field and source record structure for Table B. Figure 5 shows a schematic for a loader.
Figure 6 shows a schematic for a query engine.
Figure 7 shows query results.
Figure 8 shows a rights matrix.
Figure 9 shows a schematic for an intelligent DMR command executor.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The preferred embodiment is designed as a computer-implemented superstructure for use with existing relational database management systems (RDBMSs) such as Progress RDBMS, designed by PROGRESS Software Corp., Bedford, Massachusetts RDBMS structure is processor intensive, because the retrieval of related records forces heavy processing by the database management system to establish current relationships
In the preferred embodiment, however, heavy processing by the RDBMS is avoided because the RDBMS is used primarily to handle only single format blocks, several indices, and various user interaction interfaces, usually through a display screen. Using a computer, the system directs the creation of the common data repository, the hierarchical linking of data modeling records (DMRs), the network linking of blocks withm a DMR, the query engine, the intelligent DMR, and the rights matrix.
The system supports hierarchical, network, and the relational structures. Figure 1 shows related DMRs linked using hierarchical, network, and relational structures according to the preferred embodiment. Each hierarchy 11, 12 includes a single root DMR 111, 121 and multiple children DMRs linked using one-way pointers. Pointers, both one-way and two-way, are stored as references to the linked item within DMR blocks, specifically within each DMR's data array. For example, hierarchy 11 may represent a mail-order database for a mail-order company with one general division and two specialty divisions. Such a database may contain customer "Name and Address" DMR 111, customer "Credit Profiles" DMR 112, "Customer Orders -
- General" DMR 113, "Customer Complaints" DMR 114, "Customer Orders -- Furniture" DMR 115, and "Customer Orders - Automotive" DMR 116. Hierarchy 12 may be a human resources database for the employees of the mail order company with employee "Name and Address" DMR 121, "Customers Handled - General" DMR 122, employee "Timekeeping and
Salary" DMR 123, employee "Division Roster -- General" DMR 124, "Customers Handled - Automotive" DMR 125, "Customers Handled - Furniture" DMR 126, "Division Roster - Furniture" DMR 127, and employee "Division Roster - Automotive" DMR 128. Note that in these hierarchical structures a user may browse from one DMR to the next only in the direction of the one-way arrows.
Several two-way pointers 141, 142, 143, 144, 145 establish network links between the two hierarchies 11, 12. Like one-way pointers, two-way pointers are stored references with the blocks at each end of the linked reference - A points to B, and B to A. These two-way pointers provide further perspec ve to e var ous s. or examp e, e us omer r ers - Automotive" DMR 116 of hierarchy 11 may be linked to the "Customers Handled -- General" DMR 122 and to the "Customers Handled - Automotive" DMR 125 using, two-way pointers 143, 144 so that when a user views hierarchy 11, the user can also see whether a automotive division customer order was handled by an employee of the mail order company's automotive division, despite the fact that the "Customers Handled" DMRs are not children of hierarchy 11. Conversely, if a user is traversing hierarchy 12, the user can see related DMRs from hierarchy 11 through the network links even though those DMRs are not children of hierarchy 12. If desired, two-way pointers may also be established within a single hierarchy as well as between two hierarchies.
Figure 1 also shows relational structure 13 with a single-key alphabetical index. The preferred embodiment uses a unified single-key alphabetical index into which every common repository DMR is placed. This index is held in the traditional RDBMS that is incorporated "under" the system and stored on a server's storage devices. Each key in the relational structure 13 has a one-to-one relationship with every DMR in each hierarchy 11, 12. This relational structure can be used to access quickly the various hierarchical and network structures. Note that the various hierarchical structures may be products of not only different divisions within a single company, but they may also be products of completely different companies.
The preferred embodiment is based upon the use of DMRs, rather than tables, as basic building units for hierarchical structures. Instead of a table structure dictating exactly what fields may be used in a particular database or data structure, data structure rules developed by individual managers control the development of a hierarchy. Data structure rules may allow only certain types of Record Types to be hierarchical children of a certain DMR. Information may be entered in a number of different ways depending on the number of Record Types a manager has created. Part of the root block content is the Record Type ID. All associated DMR blocks must contain the same Record Type ID. All DMR block information is held within the flat file on the services storage devices.
Record Types define the basic fields used in a particular type of DMR. For example, an "article" Record Type may contain "author," "title," "date of
π pu cat on, an ourna e s, w ereas a c emica compounds" Recor Type may contain "name," "date of discovery," "description," "use, ' and "chemical symbol" fields. According to a preferred embodiment, up to 1000 Record Types, such as persons, locations, bibliographic, books, conference, notes, topics, or projects, may be defined by multiple managers of the system.
Despite the fact that Record Types may be diverse and contain no common fields, a manager's data structure rules may allow these different Record Types to reside in a single hierarchy. This allows for great flexibility in entering and listing data. Thus, more than one data structure can contain a particular Record Type, and a Record Type may have any number of fields in common with another Record Type.
Figure 2 shows a DMR with three blocks incorporating data from Table A of Figure 3 and Table B of Figure 4. In a preferred embodiment, a DMR contains at least one and at most 999 blocks. If more blocks are needed in a single DMR, however, blocks from two or more DMRs can be bound together to make a larger DMR. Blocks are bound together as required by storing the next block sequence number in one of the Internal System ID areas of the "owning" block, be this the root block or one of the subsequent blocks. In this manner, blocks can be bound together in unlimited fashion. A block may be created and maintained by a RDBMS such as Progress under the direction of the system. The block contents are stored as part of the contiguous single flat file on a server β storage devices. Each DMR contains at least a root block 50 as shown in Figure 2. A DMR may also have one or more non-root blocks 51, 52. Both the root block and non-root blocks contain system fields. All blocks include the following system fields: Term
(an alphanumeric general description of the DMR), Record Identifier (a real number unique for each DMR), Record Type, and Block Identifier (a real number unique for each block). Block types, either a root or a child, are differentiated in an internal system ID area of the block. The system has a global definitions methodology that defines the values to be stored for the different types. The system uses the underlying RDBMS to store the system global definitions. These are kept in separate flat files on the server machine.
In this example of DMR 116 from Figure 1, the Term of the DMR is
"Customer Orders -- Automotive." The Record Type is "153," which a manager may define as the numeric identifier for an "automobiles" Record Type. Record Type 153 may contain the fields "owner," "make," "model," "year," "dealer," "color," "license plate number," "date of purchase," and "warranty information" as defined by a manager.
In addition to the system fields listed above, a root block contains two unique additional system fields that relate each DMR to a hierarchy: Root
Record Identifier and Aspect. According to a preferred embodiment, each DMR has a place in one hierarchical database structure having a root DMR. The Root Record Identifier contains the Record Identifier of the root DMR in a DMR's hierarchical structure. The Aspect contains a string of Record Identifiers tracing the hierarchy of the DMR. The Root Record Identifier in this example is "111," which is the Record Identifier for the DMR with the Term "Name and Address" in the customer hierarchy 11 shown in Figure 1. The Aspect, "111:113," represents that the DMR with the Record Identifier "113" is the parent of the instant DMR, and that the DMR with the Record Identifier "111" is the grandparent of the instant DMR. Every Aspect lists all of the parents of the instant DMR, from the direct parent to the root DMR of the hierarchy. Thus, the system fields indicate that the DMR shown is in a hierarchical structure of data for mail-order customers related to each other through customer order classification. The Root Record Identifier and the Aspect are used mainly to maintain the hierarchical referential integrity of the system.
Each block also contains a first data array called Chain-1. As mentioned previously, all of the block content is stored contiguously in a flat file on the system server. The title of the Chain-1 data array maintains the order of the blocks within a DMR. In the example shown in Figure 2, the title of the Chain-1 array of the root block contains the Record Identifier plus the suffix ".0" while the title of the Chain- 1 array of non-root blocks contain non-zero suffixes. The convention of the system is to indicate root blocks with the suffix ".0" in the Chain- 1. Non-root blocks are usually assigned suffixes in ascending order.
A Chain- 1 data array contains a single-column with the look-up references to data entries. In a preferred embodiment, a data array may have up to 100 alphanumeric look-up references and 50 real number look-up references. A look-up reference can refer to almost any type of data, such as alphanumeric characters, integers, decimals, date/time, program applications, graphic pictures, digitized voice, spread sheet data, or word processing data A block may have an unlimited number of data entries, because two or more 150-field blocks may be bound together to compose a larger unitary block For example, Figure 2 shows the contents of the root block data array 50 including look-up references to owners, automobile make and model, automobile color, and automobile year A Mapper catalogues the source fields for each datum and notes that a "name" is in data array elements 0-25, an "automobile make" is in data array elements 26-45, an "automobile model" is in data array elements 46-70 and so forth As is shown in Figure 5, there are several processes or procedures such as the Mapper, preferably written in the RDBMS 4GL programming language, that control the necessary actions at the DMR level. These systems are all stored by the RDBMS under its file system structure for procedures, and stored in a system s server storage devices. In the root block situation, all of the fields in the Chain-1 data array are pre-defined by the Record Type "automobiles." Block 51, however, contains information pertaining to purchase orders. In block one 51, the Chain- 1 data array contains look-up references to shipping addresses, date of order, date order filled, item number, quantity, and color. In block two 52, the data array contains look-up references that describe payment methods, type of payment and subtotal, tax, shipping, and total. When used by another program, whether in a create record sequence or look-up record query sequence, the Mapper will use the block ID information held in the internal system area to negotiate to succeeding blocks. Each DMR also contains a unique Chaιn-2 data array that contains
Record Identifiers and specifies network linkages of certain fields across hierarchies. Chain-2 data arrays are contained per DMR; they are specific to each DMR, not just to any block, and they contain internal system fields to identify and associate the array to the DMR. For example, the "owners" elements in Chain- 1 of the root block in the DMR in Figure 2 have a Chain-2 network linkage to Record Identifier 550 to a DMR with the Term "U.S Telephone Directory." The Chain-2 also lists the Record Identifiers to the parents of the directly-lmked DMR, such as Record Identifier 547 to a DMR with the Term "North American Telephone Directory" and Record Identifier 593 to a DMR w th the Term "Global Telephone Directory " The Chaιn-2 data array a so contains a irect networ n age rom item num er oo -up references in the Chaιn-1 of block one 51 to a DMR with the Term "Catalog" and other direct network linkages from "color" look-up references in the Chain- 1 data array of the root block 50 and block one 51 to a DMR with the Record Identifier 647 and the Term "Color Chart "
Again, the list of direct linkages in the Chaιn-2 data array are augmented by the Record Identifiers of the parents of the directly-linked DMRs. Chain-2 data arrays may be used to link not only related DMRs, but Chain-2 linkages may also be used as a gateway to processes such as ordering a document, downloading a file, or starting an electronic mail subsystem. The contents of the data array would be made up of the particular commands required to perform the specific action. For example, to download a file, the data array would contain the specific commands to connect, open the file, and close the file. The Chain-2 data array, which is per DMR, is contained in the file structure of the preferred embodiment. For instance the "total" look-up references in block two 52 could be network linked to a "print receipt" process.
Figures 3 and 4 show examples of disparate source structures. Source table A represents manufacturer orders of automobile parts. The fields available in source Table A are: dealer number, date of order, customer name, year of car, model of car, item number, quantity, and warranty information. Source table B represents automobile replacement parts orders. The available fields in Source table B are: name, address, make, model, catalog number, description, color, quantity, price per item, subtotal, tax, shipping, total, payment type, and account number.
Figure 5 shows a schematic for a loader that can be implemented on a computer. A loader as shown in Figure 5 can load data from disparate data sources with disparate record structures into a single data repository. The loader can take the source tables shown in Figures 3 and 4 and integrate them into a single DMR as shown in Figure 2.
Note that the "customer name" field in source Table A contains the same type of information as the "name" field does in source Table B. Also, the "model of car" field in source Table A contains the same type of information as the "model" field of source Table B. Using this information, the loader can blend source Tables A and B into a cohesive whole for use in, for example, a "Customer Orders - Automotive" DMR, while allowing managers and users of the individual systems to operate on the individual systems as if the original systems were unchanged.
Source data 20 can be either derived from a pre-existing table transferred using magnetic tape or other machine structure or keyed into the loader using a computer keyboard. A typer 21, preferably implemented by a
4GL program on file, inspects the source data and segregates the source data according to source fields and source records using field delimiters (for example, a TAB character) and record delimiters (for example, a hard RETURN character). The segregated data is sent to a Block Creator 28, preferably implemented by a 4GL program on file. The typer also determines an applicable Record Type, such as persons, locations, documents, or projects, from the types available for this database. According to a preferred embodiment, there are 1,000 available Record Types, each having a unique programmable format.
The Record Type is sent to the DMR Creator 22, preferably implemented using a 4GL program on file, which initiates a call to a DMR Sequencer 23, which is preferable a 4GL program on file that maintains and generates a unique sequence for Record IDs. The DMR Sequencer 23 returns a unique identifier for each DMR to be created by the DMR Creator 22. The
DMR Creator 22 establishes the system fields for a DMR, such as Term, Record Identifier, Record Type, Root Record Identifier, and Aspect. These system fields are also sent to Block Creator 28.
The names of the source fields used in the source data 20 are sent from the typer 21 to the mapper 24. The mapper 24 places look-up references to data in the Chain- 1 data array based on Mapper rules and the source field names. Field names are stored inside the Root block of that field s DMR. A Chain- 1 data array element may be forcibly linked to a DMR using the Chain- 2 data array based on the name of the source field. For example, data from a source field "item number" in the Chain-1 data array of block one may be forcibly linked to a DMR with the Term "Catalog." Also, data from a source field named "colors" in the Chain-1 data array of block one may be forcibly linked to a DMR with the Term "Color Chart." As a final example, data from source fields named "make" and "model" in the Chain- 1 data array of block two may both be forci y lin e to a containing a taxonomy o automobile classifications
In addition to forced linkages between hierarchies, links between hierarchies may be made based on a set of linking rules 27 preferably stored as a 4GL program on file The linker 25 may survey the hierarchies already residing in the common data repository 29 The linker looks at the Chaιn-2 data arrays of all the associated hierarchy DMRs in the repository using the single key alphabetical index It scans the array for the current Record ID to see if any mention a link that applies to the current rules If they do, then these associated DMRs are entered into the current DMR s Cham-2 data array as having additional links to these other DMRs Depending on the results of this survey, the linking rules may direct the linker 25 to enter into a Chaιn-2 data array appropriate network pointers similar to pointers 141-45 shown in Figure 1. Once the Block Creator 28 receives data from typer 21, system fields from DMR Creator 22, Chain- 1 data array from mapper 24, and Cham-2 data array from linker 25, the Block Creator 28 can construct blocks to form a DMR The Block Creator 28 is preferably a 4GL program on file. When completely constructed in memory, blocks are stored in the RDBMS. The Block Sequencer 27 returns a unique block identifier for each block to be created by the Block Creator 28 Preferably, the Block Sequencer 27 is a 4GL program on file that maintains and generates a unique sequence for Record IDs The DMRs are hierarchically linked according to instructions found in each root block The data is then stored in a common data repository 29 The preferred embodiment may support large-scale multi-user information services that require real-time operational management and limited downtime. Prior database systems may require that the data be taken off-line before changes to field and record definitions can be made. This period of down-time is not only inconvenient for users, but it can also result in significant loss of revenues to the information provider
Because the source field and source record definitions do not define the storage of data m the common data repository, a manager may add data, add
Block Types, add Record Types, and assign new fields while the system is still on-line Essentially, a manager may make any modification that does not affect currently an open DMR. Interaction to the system can occur in three different manners: (1) through a new script processing language developed for the system, (2) through embedded ANSI standard SQL scripts executed from within the new script processing language; and (3) through the included RDBMS commands and features, which can only be performed against the RDBMS database, not the system as a whole. All three of these methods use script files written with any standard editor.
For example, if an information manager would like to add a field to a DMR, the system simply modifies the mapping rules to specify the new field. This does not affect any users of the DMR at the time. However, if a manager seeks to make modifications such as adding data that would affect an open DMR, the preferred embodiment would prevent the modification from occurring at that time. The preferred embodiment would delay the implementation of the modification until the DMR was not being accessed. Alternatively, the system could simply bar the manager from trying to make the modification at that time.
Although an RDBMS relates, searches, and finds data as it is in the database flat file, the return of the data is ordered by the contents of the index used to search it (or with an "order by" clause). The preferred embodiment uses both a horizontal and vertical "connecting" of the data through the horizontal and vertical structures, and it is this extra horizontal index based on the vertical index key that adds order to the resultant return set.
The system uses a "unified index structure." The preferred embodiment uses a "unified single key alphabetical index" into which every common repository DMR is placed. This index is held in the traditional
RDBMS that is incorporated "under" the system and stored on a server s storage devices. The unified index structure operates in at least two dimensions. Preferably, the first dimension, horizontal, allows single-key indexing all of the DMRs as one numeric index according to Record Identifier. The relational structure 3 (shown in Figure 1) is the structure used to establish and maintain the single-key index. Because the unified index structure is pre-established, associations between DMRs can be determined by working with only the single-key index. The actual data do not need to be retrieved from the common data repository 29 until the relational operations are completed. This unified index structure provides quick retrieval for even the most complex queries, minimum processing overhea for the database server, and the ability to segment the processing overhead on multiple processors in a multi-processor or client-server environment
In a second dimension of the unified index structure, vertical, the preferred embodiment uses matrix operations and filtering to refer to any block within a DMR as a subset of the first dimension of the unified index structure. The linker 25 (shown in Figure 5) associates field names with other DMR hierarchies to augment second-dimensional links between DMRs. This single-key index can be manipulated to establish sorts within sorts, relational structures, query results, and other operations.
Figure 6 shows a schematic for a database management system query engine that can be implemented using a computer. A user begins a query by constructing a request using boolean query language (AND, OR, NOT, <, >, = , etc.) and variables such as character strings, Record Types, and field names. This incoming request is sent to the Macro Constructor 61, preferably a 4GL program on file, which parses the incoming request into its constituent boolean operations and variables. This data output is sent to a Language Generator 62, preferably implemented using a 4GL program on file, which translates the boolean operations into an executable address. The translated query is sent to the Query Optimizer 63 preferably implemented using a 4GL program on file, which creates an optimized executable search and simultaneously checks the query for validity. The Query Optimizer returns an executable pointer address relating to the query, which is then sent to the Macro Constructor 61. The Macro Constructor 61 enables the Query Extractor 64 to survey the common data repository 29 for the requested variables.
The Query Extractor 64, preferably a 4GL program on file, matches found query variables against the single-key horizontal index, which means when a user queries the common data repository, the Query Extractor will find the results in reference to the Record Identifier. The Query Extractor
64 then performs any nested query operations resulting from Boolean operations If the Record Identifier references a DMR that satisfies the query, the Record Identifier is passed to the Display Manager 65. If the Record Identifier does not satisfy the query, the Record Identifier is not passed to the Display Manager 65 The Query Extractor continues to survey the common data repository 29 until no more Record Identifiers are returned The Display Manager 65, preferably implemented using a 4GL program on file, formats the query results according to the display selection preferred by the user (or the default display selection) The default display selection format preferably shows query results according to Record Identifier, Term, and Record Type. Other display selection formats could be either a listing by Record Type only, or a listing by Term only, or even a listing by source table The output of the Display Manager goes to a display such as a monitor The display selection may also control the display border, the margins, the font, and the colors used in the display.
In a sample query, a user may inquire who assisted Mark Daniels in purchasing automobile tires The Incoming Request may be: "Mark Daniels" AND "tire" AND "hierarchy (12)" Depending on the sophistication of the Language Generator 62, a query variable that is a name (e.g , "Mark Daniels") may result in a search for the surname alone (e.g., "Daniels"), or matching first and last names with or without a middle name or middle initial (e. , "Mark" within 2 of "Daniels").
After translating the Incoming Request into an optimal executable pointer using Macro Constructor 61, Language Generator 62, and Query
Optimizer 63, the query engine will traverse DMRs in hierarchy 12 for references to "Mark Daniels" and "tires" in the Chain- 1 and Chaιn-2 data arrays.
Next, the query engine will search the common data repository 29 for every entry of "Mark Daniels" to find every data array (Chaιn-1 or Chaιn-2) that contains a look-up reference to "Mark Daniels " Once a first DMR is found that corresponds to the variable "Mark Daniels," the Record Identifier of that DMR is returned to the Query Extractor 64. The Query Extractor 64 will inspect the Chain- 1 and Chain-2 arrays of that DMR for a reference to "tire " If the DMR contains a reference to "tire," the Query Extractor 64 inspects the DMR for a Chain- 1 or Chaιn-2 reference to "hierarchy (12) " If the DMR contains references to all three variables, the Record Identifier is sent to the Display Manager 65 for appropriate display If at any time the Query Extractor 64 finds that the DMR does not contain a query variable, the Query Extractor 4 oes not pass t e ecor Identi ier to t e isp ay Manager 65.
If the common data repository 29 responds that "Mark Daniels" is in a Chain-1 data array of a DMR, the query engine has found a look-up reference to "Mark Daniels," because look-up references are stored in Chain- 1 data arrays. Possibly, the Chain- 1 data array is associated with the customer "Names and Addresses" DMR 111 shown in Figure 1. Next, the Query Extractor 64 looks for query request variable "tire" in either the Chain-1 or Chain-2 data array of the found DMR. If "tire" is found in a Chain- 1 data array, the query engine has found a single DMR with look-up references to both "Mark Daniels" and "tire." Finally, the Query Extractor 64 looks for a reference to "hierarchy (12)" in the Chain- 1 and Chain-2 data arrays of the found DMR. If the Query Extractor 64 finds such a reference, the Record Identifier of that DMR is passed to the Display Manager 65. Finding a query variable in a Chain-2 data array signifies that the found DMR contains a network reference pointer to the variable, because only network references are stored in a Chain-2 data array. Perhaps a network reference pointer to "hierarchy (12)" is stored in the Chain-2 data array of the "Customer Orders - Automotive" DMR 116. At this point, DMR 116 containing two variables, "Mark Daniels" and "tires," in a Chain- 1 data array and the final variable, "hierarchy (12)," in a Chain-2 data array is also passed to the Display Manager 65.
In this example, the query engine may return many Record Identifiers, each containing a reference to "Mark Daniels" AND "tire" AND "hierarchy (12)." There may be multiple "Mark Daniels" entries in the common data repository 29. Also, the query engine may return DMR references to automobile tires, bicycle tires, or other types of tires, because the query does not specify a certain type of tire.
Figure 7 shows query results. The display will usually show the Term of the DMR containing the Chain- 1 result as shown in screen 72. The user, however, can instruct the system to display different information as the query result, such as the Record Type as shown in screen 73. A found DMR's Term in this case could be "Customer Orders - Automotive." The user could check that DMR to find the entry that the user was specifically looking for. However, there could be other DMRs which contain "Mark Daniels" and "tire" and "hierarchy ( 12)," and a user could enter those DMRs later Note that the preferred embodiment the query results are displayed in alphanumeric order
At this point, the user of the system could enter the "Customer Orders - Automotive" DMR 116 (from Figure 1) and look for Mark Daniels, which could be highlighted or otherwise indicated The user can also immediately link from "Customer Orders - Automotive" DMR 116 (from Figure 1) in another hierarchy and go to "tires", which may be highlighted The user of the system may or may not know that the entry "tires" is not in the same hierarchy or DMR from which the user is presently operating
After the query engine completes its report, a user can browse through a selected hierarchy with only minor processing. The user may see additional two-way pointer references to other DMRs containing a look-up reference for "Mark Daniels" in the Chain-1 data array. The user can immediately look at all the references and know that Mark Daniels is linked to DMRs with Terms such as "Universities" and "Companies." A user can also maintain the reference to "tire." By maintaining this reference, a user keeps a filter on while perusing down the "Customers" hierarchy 11 (from Figure 1) and network linkages. So, "tire" will always appear, and the user can look for types of tires such as radial tires, snow tires, or bicycle tires.
The Display Manager 65 (from Figure 6) may display an updated summary of query responses as the user travels through different hierarchies. As a user traverses hierarchies and perhaps enters a hierarchy that contains fewer and fewer query variables, the updated summary will show that fewer and fewer DMRs contain results of the query.
Figure 8 shows a rights matrix. The preferred embodiment rights matrix is a Progress RDBMS table used at the system level for subsystem control. Another aspect of the preferred embodiment is multiple control domains within the common data repository. Most databases offer two levels of basic security (user vs. nonuser & user vs. superuser). The preferred embodiment provides an additional level of security through individual subsystem operational control. A rights matrix controls access and use of the subsystems and the discrete functions encompassed in those subsystems. Figure 8 shows eight levels of security, with level 8 being analogous to a superuser The preferred embodiment can support any number of security levels with preferab y t e highest security level hav ng access to a subsystems. Within a subsystem, a manager at level 6 may use the functions for creating, deleting, and modifying DMRs as well as creating, deleting, and modifying fields. In the rights matrix, each subsystem as well as its underlying functions appears as a discrete element. This enables a manager to decide exactly which rights are assigned to certain user groups on a function-by-function basis. Every request to access a function is matched against the rights matrix before the function can be performed. User level and subsystem requested are looked up in the rights matrix table for permission.
The preferred embodiment also provides a second level of security which is DMR-specific -- controlling the security of data, the format of data, and the usage of data on the DMR level. This resident intelligence, located in a Chain-4 data array (shown in Figure 2) section of a DMR, is programmed by the application owner and the data owner and interacts with the rights matrix. A manager may determine which DMRs have read/write privileges for certain user groups. A manager may determine whether to allow others to modify a DMR or even reply to notes in a conference. This level of control enables a manager to have complete control in a shared system. For example, in Figure 2, case 1 shown in Chain-4 does not allow a user access to block two
52, having BLOCK_ID = 4314, which may contain sensitive financial information. Case 2 shown in Chain-4 of Figure 2 is applicable to a user having a color monitor.
By utilizing control properties of a DMR to trigger "events," the system can establish formats for a particular DMR, create associations (or pointers) to other data, implement security controls, and trigger applications for use with a particular DMR. For example, the control property could load an appropriate word processor and display a file in the word processor format when a manager retrieves a "word processing text file" from one of the variable length fields in a block. In the same manner, a document image contained in a DMR field could be automatically displayed by the appropriate graphic image display application. In another type of control property usage, accessing a DMR imported from an Oracle"" database could trigger a control event to check the remote database for the last time the DMR was updated. igure s ows a sc ema c or an in e igen comman executor Intelligent commands (triggers) are held in the system DMR Chaιn-4 data arrays If a user processes a DMR with Chaιn-4 array content that performs an action, then that action will "trigger." If a user trips a DMR trigger, the Record Identifier of the DMR is sent to the script language processor 81, preferably a 4GL program on file, which starts the operation of the resident intelligence in the DMR Chaιn-4 arrays. The various triggers include: requesting to read data in a DMR, traversing through a DMR to see hierarchical children DMRs, traversing back through a DMR to see hierarchical parent DMRs, using a DMR as a menu, requesting to trigger the
DMR directly, and editing the DMR.
These triggers are in the context of an event-driven model. When a trigger is tripped, the user starts an event that completes a particular action. On the other hand, there are data-driven models, where data can reprogram the user interface. For example, if the data value of the field matches a criteria held in the Chain-4 array, then the instructions to download and execute a new version of the user interface "xx.exe" file could be performed, which would result in a "reprogrammed" user interface. The system merges the event-driven model with the data-driven model by allowing an event to gather or rearrange information, and then allowing that information to dictate the user interface. The information returned by the event could allow a DMR to act as a menu, a filter, or a gateway to other DMRs. In this situation, the user interface responds to the data returned by the event.
Once a trigger is tripped, the Record Identifier is sent to the script language processor 81. The script language processor inspects the Chain-4 of the DMR for instructions corresponding to the trigger that was tripped. These instructions, if present, are sent to the logic unit 82 for translation into executable code. The output of the logic unit 82 is sent to a rights matrix unit 83 that checks whether the instruction can be performed based on the user ID. If the instruction cannot be performed by the user, a disabled signal is sent through the object processor 85, and control returns to the script language processor 81. If, however, the rights matrix unit 83 sees that the user is allowed to perform the requested event, an enable signal is sent to memory unit 84, and the memory unit controls the read/write capabiUties to the object processor 85. The object processor 85 may include controls to , , . - also direct the DMR to act as a menu, a folder, or a branch point to another gateway.
For example, a search for "Mark Daniels" AND "tire" AND "hierarchy (12)" finds 23 DMRs. In that context, a trigger of requesting to read a particular DMR could direct the front end view system to present detailed order information (including addresses and account numbers) for a user who is employed to take those orders. If, however, the user is not employed to take orders, the view system may only present a summary of all the orders in the DMR and omit sensitive information such as addresses and account numbers.
In another instance, two types of users, User A and User B, may be looking at the same initial DMR. From that DMR, both users may trip the same trigger, but User A might take one path and see a submenu with certain options listed while User B might see a submenu with completely different options listed. This branching depends on the instructions programmed in the Chain-4.
The view and reporting preferences of each user can also be fused with the Chain-4 instructions programmed by the application owner and the data owner. Each user may have a personalized set of views and preferences including screen color preferences and border styles. Therefore, identical events triggered by User A and User B create very different results partly determined by the data owner and partly determined by the preferences of the user. Thus, the system may develop, integrate, and administer large and complex databases using hierarchical, network, and relational structures. This system may, of course, be carried out in specific ways other than those set forth here without departing from the spirit and essential characteristics of the invention. Therefore, the presented embodiments should be considered in all respects as illustrative and not restrictive and all modifications falling within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Claims

LAIMS We claim:
A computer-implemented loader for loading source data into a database system comprising: a source data distinguisher software component for segregating the source data into at least one source field and for determining a record type; a data management record system field creator software component connected to the source data distinguisher software component for establishing a system field relating to the record type; a data mapper software component connected to the source data distinguisher software component for storing a source field name relating to the source field; a data management record linker software component connected to the source data distinguisher software component for establishing a pointer relating to the source field; a block creator software component connected to an output of the source data distinguisher software component, an output of the data management record system field creator software component, an output of the data mapper software component, and an output of the data management record linker software component for constructing a block; and a common data repository connected to an output of the block creator for storing data in a computer memory.
2. A computer-implemented loader for loading source data according to claim 1 further comprising: a counter connected to an input of the data management record system field creator for establishing a unique record identifier.
3. A computer-implemented loader for loading source data according to claim 1 further comprising: a counter connected to an input of the block creator for establishing a unique block identifier. . compu er-imp oa er r oa ing c r claim 1 wherein: the linker is connected to the common data repository
5. A data modeling record in a computer storage device comprising: a root block, wherein the root block has a Chaιn-1 data array for containing data look-up references; and a Chain-2 data array for containing two-way network linkages.
6 A data modeling record according to claim 5 further comprising: a non-root block, wherein the non-root block has a Chain-1 data array for containing data look-up references.
7. A data modeling record according to claim 5 further comprising: a Chain-4 data array for containing instructions regarding data access.
8. A computer-implemented data modeling record intelligent command executor comprising: a script language extraction software component for extracting an instruction from a data array; a translation software component connected to an output of the script language extraction software component for translating the instruction into computer-executable code; a rights matrix data unit connected to an output of the translator for determining if the code should be executed; a memory unit connected to an output of the rights matrix unit; and an object processor connected to an output of the rights matrix unit, connected to an input of the memory unit, connected to an output of the memory unit, and connected to an input of the script language extraction software component for executing the code.
9. A method for retrieval of information from a database system comprising: traversing throug an index of a relational structure containing data modeling records to find a hierarchical structure containing data modeling records; then traversing through the hierarchical structure containing data modeling records to find a network structure containing data modeling records; and then traversing through the network structure containing data modeling records.
10. A computer-implemented query engine comprising: a macro constructor for translating a request into a boolean operation or variable; a language generator connected to an output and an input of the macro constructor for translating the boolean operation or variable into an executable address; a query optimizer connected to an output and an input of the language generator for optimizing the executable address; a query extractor connected to an output of the macro constructor for obtaining a query result from a common data repository; and a display manager connected to an output of the query extractor for displaying the query result.
11. A rights matrix in a computer memory comprising: a plurality of security levels; and a plurality of functions; wherein each security level corresponds to the enabling of a unique subset of the plurality of functions.
12. A rights matrix according to claim 11 wherein: the plurality of security levels is more than three.
13. A memory for storing data for access by an application program comprising: a database management record data structure stored in the memory including: a , data array with look-up references to data stored in a common data repository; and a second data array stored in the memory, the second data array containing two-way pointers to other database management record data structures.
14. A memory for storing data for access by an application program according to claim 13 comprising: a third data array stored in the memory, the third data array containing additional look-up references to data stored in a common data repository.
15. A memory for storing data for access by an application program according to claim 13 comprising: a fourth data array stored in the memory, the fourth data array containing instructions regarding data access.
PCT/US1997/003615 1996-03-05 1997-03-05 System and apparatus for loading and retrieving information WO1997033241A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU20730/97A AU2073097A (en) 1996-03-05 1997-03-05 System and apparatus for loading and retrieving information

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/610,945 US5842212A (en) 1996-03-05 1996-03-05 Data modeling and computer access record memory
US08/610,945 1996-03-05

Publications (1)

Publication Number Publication Date
WO1997033241A1 true WO1997033241A1 (en) 1997-09-12

Family

ID=24447030

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/003615 WO1997033241A1 (en) 1996-03-05 1997-03-05 System and apparatus for loading and retrieving information

Country Status (3)

Country Link
US (1) US5842212A (en)
AU (1) AU2073097A (en)
WO (1) WO1997033241A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850901B1 (en) * 1999-12-17 2005-02-01 World Theatre, Inc. System and method permitting customers to order products from multiple participating merchants
US8099711B2 (en) 2008-01-08 2012-01-17 International Business Machines Corporation System and method for multi-level security filtering of model representations

Families Citing this family (130)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5740435A (en) * 1994-10-31 1998-04-14 Sony Corporation Data management apparatus and method for managing data of variable lengths recorded on a record medium
US7546277B1 (en) 1997-10-09 2009-06-09 Walker Digital, Llc Method and apparatus for dynamically managing vending machine inventory prices
US7233912B2 (en) 1997-08-26 2007-06-19 Walker Digital, Llc Method and apparatus for vending a combination of products
US20020161670A1 (en) * 1997-07-08 2002-10-31 Walker Jay S. Method and apparatus for facilitating purchase agreements with a retailer
US7894936B2 (en) 1997-10-09 2011-02-22 Walker Digital, Llc Products and processes for managing the prices of vending machine inventory
US7236942B1 (en) 1997-12-19 2007-06-26 Walker Digital, Llc Pre-sale data broadcast system and method
US6405174B1 (en) * 1998-10-05 2002-06-11 Walker Ditial, Llc Method and apparatus for defining routing of customers between merchants
US6148296A (en) * 1998-02-04 2000-11-14 Microsoft, Inc. Automatic generation of database queries
US6460043B1 (en) 1998-02-04 2002-10-01 Microsoft Corporation Method and apparatus for operating on data with a conceptual data manipulation language
AU3205199A (en) 1998-03-27 1999-10-18 Walker Asset Management Limited Partnership System and method for tracking and establishing a progressive discount based upon a customer's visits to retail establishment
US6192373B1 (en) * 1998-05-15 2001-02-20 International Business Machines Corp. Managing directory listings in a relational database
US6374240B1 (en) * 1998-10-05 2002-04-16 Walker Digital, Llc Method and apparatus for maintaining a customer database using license plate scanning
US7826923B2 (en) 1998-12-22 2010-11-02 Walker Digital, Llc Products and processes for vending a plurality of products
US6427123B1 (en) * 1999-02-18 2002-07-30 Oracle Corporation Hierarchical indexing for accessing hierarchically organized information in a relational system
US6772409B1 (en) * 1999-03-02 2004-08-03 Acta Technologies, Inc. Specification to ABAP code converter
US6223165B1 (en) 1999-03-22 2001-04-24 Keen.Com, Incorporated Method and apparatus to connect consumer to expert
AU5135400A (en) 1999-06-30 2001-01-22 Walker Digital, Llc Vending machine system and method for encouraging the purchase of profitable items
US6754666B1 (en) * 1999-08-19 2004-06-22 A2I, Inc. Efficient storage and access in a database management system
US7308422B1 (en) * 1999-10-08 2007-12-11 Utbk, Inc. System for recording and distributing recorded information over the internet
US20020010608A1 (en) 1999-10-08 2002-01-24 Scott Faber System for provding services in real-time overthe internet
US6912586B1 (en) * 1999-11-12 2005-06-28 International Business Machines Corporation Apparatus for journaling during software deployment and method therefor
US20050131729A1 (en) * 1999-11-16 2005-06-16 Melby John M. Apparatus and method for tracking and managing physical assets
US7062446B1 (en) * 1999-11-16 2006-06-13 Dana Corporation Apparatus and method for tracking and managing physical assets
US20020082966A1 (en) * 1999-11-16 2002-06-27 Dana Commercial Credit Corporation System and method for benchmarking asset characteristics
US6952680B1 (en) 1999-11-16 2005-10-04 Dana Corporation Apparatus and method for tracking and managing physical assets
US20020077944A1 (en) * 1999-11-16 2002-06-20 Bly J. Aaron System and method for disposing of assets
US6557008B1 (en) * 1999-12-07 2003-04-29 International Business Machines Corporation Method for managing a heterogeneous IT computer complex
US6615274B1 (en) 1999-12-09 2003-09-02 International Business Machines Corporation Computer network control systems and methods
US6704782B1 (en) 1999-12-09 2004-03-09 International Business Machines Corporation System and methods for real time progress monitoring in a computer network
US6772158B1 (en) 1999-12-14 2004-08-03 International Business Machines Corporation Apparatus for data depoting and method therefor
US6588011B1 (en) 1999-12-14 2003-07-01 International Business Machines Corporation Apparatus for automatically generating restore process during software depolyment and method therefor
US7191208B1 (en) 1999-12-14 2007-03-13 International Business Machines Corporation Methods of selectively distributing data in a computer network and systems using the same
US6574637B1 (en) * 2000-02-23 2003-06-03 Orillion International, Inc. Browser oriented method of viewing database structures
US20010044796A1 (en) * 2000-05-19 2001-11-22 Hiroyasu Fujiwara Totalization system and recording medium
WO2001090934A1 (en) * 2000-05-23 2001-11-29 Daniel Vinsonneau Automatic and secure data search method using a data transmission network
US7124203B2 (en) 2000-07-10 2006-10-17 Oracle International Corporation Selective cache flushing in identity and access management systems
US7194764B2 (en) 2000-07-10 2007-03-20 Oracle International Corporation User authentication
US7464162B2 (en) 2000-07-10 2008-12-09 Oracle International Corporation Systems and methods for testing whether access to a resource is authorized based on access information
US8204999B2 (en) 2000-07-10 2012-06-19 Oracle International Corporation Query string processing
US7249369B2 (en) 2000-07-10 2007-07-24 Oracle International Corporation Post data processing
US6865540B1 (en) 2000-08-09 2005-03-08 Ingenio, Inc. Method and apparatus for providing group calls via the internet
US7218991B2 (en) 2000-08-22 2007-05-15 Walker Digital, Llc System for vending physical and information items
US6636590B1 (en) 2000-10-30 2003-10-21 Ingenio, Inc. Apparatus and method for specifying and obtaining services through voice commands
US7542936B1 (en) 2000-11-02 2009-06-02 Utbk, Inc. Method, apparatus and system for marketing, delivering, and collecting payment for information
US7289623B2 (en) 2001-01-16 2007-10-30 Utbk, Inc. System and method for an online speaker patch-through
US7185364B2 (en) 2001-03-21 2007-02-27 Oracle International Corporation Access system interface
US20020129342A1 (en) * 2001-03-07 2002-09-12 David Kil Data mining apparatus and method with user interface based ground-truth tool and user algorithms
US20020133402A1 (en) 2001-03-13 2002-09-19 Scott Faber Apparatus and method for recruiting, communicating with, and paying participants of interactive advertising
US7340419B2 (en) 2001-03-15 2008-03-04 Walker Digital, Llc Method and apparatus for product display
US6996574B2 (en) * 2001-04-18 2006-02-07 Csg Systems, Inc. System and method for accessing database design information
US7231661B1 (en) 2001-06-21 2007-06-12 Oracle International Corporation Authorization services with external authentication
US7895173B1 (en) * 2001-06-27 2011-02-22 Microsoft Corporation System and method facilitating unified framework for structured/unstructured data
US7035859B2 (en) * 2001-08-08 2006-04-25 International Business Machines Corporation Method and system for intra-table referential integrity for relational database systems
US6704403B2 (en) 2001-09-05 2004-03-09 Ingenio, Inc. Apparatus and method for ensuring a real-time connection between users and selected service provider using voice mail
US20030061121A1 (en) * 2001-09-22 2003-03-27 Ouchi Norman Ken Catalog and item identifier for configurable items
US20030061226A1 (en) * 2001-09-25 2003-03-27 Bowman David M. Data loader for handling imperfect data and supporting multiple servers and data sources
US20030061225A1 (en) * 2001-09-25 2003-03-27 Bowman David M. Hierarchical hybrid OLAP scenario management system
US20060053075A1 (en) * 2001-11-26 2006-03-09 Aaron Roth System and method for tracking asset usage and performance
US7225256B2 (en) 2001-11-30 2007-05-29 Oracle International Corporation Impersonation in an access system
US7580850B2 (en) 2001-12-14 2009-08-25 Utbk, Inc. Apparatus and method for online advice customer relationship management
US7937439B2 (en) 2001-12-27 2011-05-03 Utbk, Inc. Apparatus and method for scheduling live advice communication with a selected service provider
US9031924B2 (en) * 2002-02-26 2015-05-12 International Business Machines Corporation Query conditions having filtered fields within a data abstraction environment
US7139769B2 (en) * 2002-03-11 2006-11-21 Norman Ken Ouchi Catalog, catalog query, and item identifier for configurable items
US20040199425A1 (en) * 2003-03-14 2004-10-07 Van Luchene Andrew S. Method and apparatus for motion-controlled communication of offers
US20040230571A1 (en) * 2003-04-22 2004-11-18 Gavin Robertson Index and query processor for data and information retrieval, integration and sharing from multiple disparate data sources
WO2004102323A2 (en) * 2003-05-06 2004-11-25 Dana Corporation System or method for analyzing information organized in a configurable manner
US7359498B2 (en) 2003-06-12 2008-04-15 Utbk, Inc. Systems and methods for arranging a call
US7698183B2 (en) 2003-06-18 2010-04-13 Utbk, Inc. Method and apparatus for prioritizing a listing of information providers
US7149657B2 (en) * 2003-06-23 2006-12-12 General Electric Company Method, system and computer product for estimating a remaining equipment life
US20050027622A1 (en) 2003-07-30 2005-02-03 Walker Jay S. Products and processes for vending a plurality of products via defined groups
US7886009B2 (en) 2003-08-22 2011-02-08 Utbk, Inc. Gate keeper
US8694510B2 (en) 2003-09-04 2014-04-08 Oracle International Corporation Indexing XML documents efficiently
US8229932B2 (en) 2003-09-04 2012-07-24 Oracle International Corporation Storing XML documents efficiently in an RDBMS
US7428497B2 (en) 2003-10-06 2008-09-23 Utbk, Inc. Methods and apparatuses for pay-per-call advertising in mobile/wireless applications
US8027878B2 (en) 2003-10-06 2011-09-27 Utbk, Inc. Method and apparatus to compensate demand partners in a pay-per-call performance based advertising system
US7120235B2 (en) 2003-10-06 2006-10-10 Ingenio, Inc. Method and apparatus to provide pay-per-call performance based advertising
US9984377B2 (en) 2003-10-06 2018-05-29 Yellowpages.Com Llc System and method for providing advertisement
US8121898B2 (en) 2003-10-06 2012-02-21 Utbk, Inc. Methods and apparatuses for geographic area selections in pay-per-call advertisement
US8024224B2 (en) 2004-03-10 2011-09-20 Utbk, Inc. Method and apparatus to provide pay-per-call advertising and billing
US7366683B2 (en) 2003-10-06 2008-04-29 Utbk, Inc. Methods and apparatuses for offline selection of pay-per-call advertisers
US7424442B2 (en) 2004-05-04 2008-09-09 Utbk, Inc. Method and apparatus to allocate and recycle telephone numbers in a call-tracking system
US7499915B2 (en) 2004-04-09 2009-03-03 Oracle International Corporation Index for accessing XML data
US7366735B2 (en) 2004-04-09 2008-04-29 Oracle International Corporation Efficient extraction of XML content stored in a LOB
US7493305B2 (en) 2004-04-09 2009-02-17 Oracle International Corporation Efficient queribility and manageability of an XML index with path subsetting
US7930277B2 (en) 2004-04-21 2011-04-19 Oracle International Corporation Cost-based optimizer for an XML data repository within a database
US7885980B2 (en) 2004-07-02 2011-02-08 Oracle International Corporation Mechanism for improving performance on XML over XML data using path subsetting
US8566300B2 (en) 2004-07-02 2013-10-22 Oracle International Corporation Mechanism for efficient maintenance of XML index structures in a database system
US7630974B2 (en) 2004-09-28 2009-12-08 Oracle International Corporation Multi-language support for enterprise identity and access management
US7627547B2 (en) 2004-11-29 2009-12-01 Oracle International Corporation Processing path-based database operations
US7921076B2 (en) 2004-12-15 2011-04-05 Oracle International Corporation Performing an action in response to a file system event
US8131766B2 (en) 2004-12-15 2012-03-06 Oracle International Corporation Comprehensive framework to integrate business logic into a repository
US9202219B2 (en) 2005-02-16 2015-12-01 Yellowpages.Com Llc System and method to merge pay-for-performance advertising models
US8538768B2 (en) 2005-02-16 2013-09-17 Ingenio Llc Methods and apparatuses for delivery of advice to mobile/wireless devices
US8095962B2 (en) * 2005-02-17 2012-01-10 At&T Intellectual Property I, L.P. Method and system of auditing databases for security compliance
US7979308B2 (en) 2005-03-03 2011-07-12 Utbk, Inc. Methods and apparatuses for sorting lists for presentation
US7681178B1 (en) * 2005-07-22 2010-03-16 Adobe Systems Incorporated Cascading style sheets (CSS) prototype pointer chaining in object-oriented environment
US8599832B2 (en) 2005-09-28 2013-12-03 Ingenio Llc Methods and apparatuses to connect people for real time communications via voice over internet protocol (VOIP)
US8761154B2 (en) 2005-09-28 2014-06-24 Ebbe Altberg Methods and apparatuses to access advertisements through voice over internet protocol (VoIP) applications
US8073841B2 (en) 2005-10-07 2011-12-06 Oracle International Corporation Optimizing correlated XML extracts
US8356053B2 (en) 2005-10-20 2013-01-15 Oracle International Corporation Managing relationships between resources stored within a repository
US8949455B2 (en) 2005-11-21 2015-02-03 Oracle International Corporation Path-caching mechanism to improve performance of path-related operations in a repository
US11093898B2 (en) * 2005-12-08 2021-08-17 International Business Machines Corporation Solution for adding context to a text exchange modality during interactions with a composite services application
US10332071B2 (en) * 2005-12-08 2019-06-25 International Business Machines Corporation Solution for adding context to a text exchange modality during interactions with a composite services application
US9197479B2 (en) 2006-01-10 2015-11-24 Yellowpages.Com Llc Systems and methods to manage a queue of people requesting real time communication connections
US8125931B2 (en) 2006-01-10 2012-02-28 Utbk, Inc. Systems and methods to provide availability indication
US7720091B2 (en) 2006-01-10 2010-05-18 Utbk, Inc. Systems and methods to arrange call back
US8688813B2 (en) 2006-01-11 2014-04-01 Oracle International Corporation Using identity/resource profile and directory enablers to support identity management
US20070239748A1 (en) * 2006-03-29 2007-10-11 Smith Ned M Management of reference data for platform verification
US8510292B2 (en) 2006-05-25 2013-08-13 Oracle International Coporation Isolation for applications working on shared XML data
US7499909B2 (en) 2006-07-03 2009-03-03 Oracle International Corporation Techniques of using a relational caching framework for efficiently handling XML queries in the mid-tier data caching
US7797310B2 (en) 2006-10-16 2010-09-14 Oracle International Corporation Technique to estimate the cost of streaming evaluation of XPaths
US9183321B2 (en) 2006-10-16 2015-11-10 Oracle International Corporation Managing compound XML documents in a repository
US7827177B2 (en) 2006-10-16 2010-11-02 Oracle International Corporation Managing compound XML documents in a repository
US9317855B2 (en) 2006-10-24 2016-04-19 Yellowpages.Com Llc Systems and methods to provide voice connections via local telephone numbers
US20080168042A1 (en) * 2007-01-09 2008-07-10 Dettinger Richard D Generating summaries for query results based on field definitions
US8451825B2 (en) 2007-02-22 2013-05-28 Utbk, Llc Systems and methods to confirm initiation of a callback
US9277019B2 (en) * 2007-06-18 2016-03-01 Yellowpages.Com Llc Systems and methods to provide communication references to connect people for real time communications
US7836098B2 (en) 2007-07-13 2010-11-16 Oracle International Corporation Accelerating value-based lookup of XML document in XQuery
US7840609B2 (en) 2007-07-31 2010-11-23 Oracle International Corporation Using sibling-count in XML indexes to optimize single-path queries
US7991768B2 (en) 2007-11-08 2011-08-02 Oracle International Corporation Global query normalization to improve XML index based rewrites for path subsetted index
US7958112B2 (en) 2008-08-08 2011-06-07 Oracle International Corporation Interleaving query transformations for XML indexes
US8126932B2 (en) * 2008-12-30 2012-02-28 Oracle International Corporation Indexing strategy with improved DML performance and space usage for node-aware full-text search over XML
US8219563B2 (en) * 2008-12-30 2012-07-10 Oracle International Corporation Indexing mechanism for efficient node-aware full-text search over XML
CN105518672B (en) 2014-07-15 2019-04-30 微软技术许可有限责任公司 Data retrieval across multiple models
WO2016008086A1 (en) 2014-07-15 2016-01-21 Microsoft Technology Licensing, Llc Data model indexing for model queries
WO2016008087A1 (en) 2014-07-15 2016-01-21 Microsoft Technology Licensing, Llc Managing multiple data models over data storage system
EP3170100A4 (en) 2014-07-15 2017-12-06 Microsoft Technology Licensing, LLC Data model change management
US10713654B2 (en) * 2016-01-21 2020-07-14 International Business Machines Corporation Enterprise blockchains and transactional systems
US10158611B2 (en) 2016-11-17 2018-12-18 Bank Of America Corporation System for multiplexing and demultiplexing blockchain ledgers via a cryptographic hash
CN110968432B (en) * 2018-09-29 2022-11-11 武汉斗鱼网络科技有限公司 Control event processing method and device and readable storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1990008360A1 (en) * 1989-01-12 1990-07-26 Telebase Systems, Inc. System and method for retrieving information from a plurality of databases
US5566333A (en) * 1992-11-05 1996-10-15 Trace Technologies, Inc. Relational database information management system for facilitating normalization of a relational database

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5257185A (en) * 1990-05-21 1993-10-26 Ann W. Farley Interactive, cross-referenced knowledge system
US5201046A (en) * 1990-06-22 1993-04-06 Xidak, Inc. Relational database management system and method for storing, retrieving and modifying directed graph data structures
US5311438A (en) * 1992-01-31 1994-05-10 Andersen Consulting Integrated manufacturing system
JPH06266813A (en) * 1992-10-19 1994-09-22 Internatl Business Mach Corp <Ibm> Data collecting device and method for collecting and inputting data and requirement from plurality of user for constructing process-model and data-model
US5710917A (en) * 1995-06-07 1998-01-20 International Business Machines Corporation Method for deriving data mappings and data aliases

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1990008360A1 (en) * 1989-01-12 1990-07-26 Telebase Systems, Inc. System and method for retrieving information from a plurality of databases
US5566333A (en) * 1992-11-05 1996-10-15 Trace Technologies, Inc. Relational database information management system for facilitating normalization of a relational database

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850901B1 (en) * 1999-12-17 2005-02-01 World Theatre, Inc. System and method permitting customers to order products from multiple participating merchants
US8099711B2 (en) 2008-01-08 2012-01-17 International Business Machines Corporation System and method for multi-level security filtering of model representations

Also Published As

Publication number Publication date
US5842212A (en) 1998-11-24
AU2073097A (en) 1997-09-22

Similar Documents

Publication Publication Date Title
US5842212A (en) Data modeling and computer access record memory
Elmasri et al. Fundamentals of Database Systems 7th ed.
US7664777B2 (en) Mapping of an RDBMS schema onto a multidimensional data model
US5701453A (en) Logical schema to allow access to a relational database without using knowledge of the database structure
US6356920B1 (en) Dynamic, hierarchical data exchange system
US6161103A (en) Method and apparatus for creating aggregates for use in a datamart
US6081814A (en) Document reference environment manager
US6212524B1 (en) Method and apparatus for creating and populating a datamart
US6662188B1 (en) Metadata model
US6732109B2 (en) Method and system for transferring information between a user interface and a database over a global information network
Elmasri Fundamentals of database systems seventh edition
US7747640B2 (en) Method for regenerating selected rows for an otherwise static result set
US7739224B1 (en) Method and system for creating a well-formed database using semantic definitions
US20030154197A1 (en) Flexible relational data storage method and apparatus
JPH06175906A (en) Information accumulation system and method
KR20010012305A (en) System and method for storing and manipulating data in an information handling system
US20020089551A1 (en) Method and apparatus for displaying a thought network from a thought&#39;s perspective
Clifton et al. Hyperfile: A data and query model for documents
WO2003042865A2 (en) Taxonomy management
Watson Beginning C# 2005 databases
Blakeley et al. Enabling component databases with OLE DB
Manelli et al. Databases
van Leuken et al. Standardization Concepts in the NELSIS CAD Framework
Willis beginning vb. net databases
CA2317166C (en) Metadata model

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN 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

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH 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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97531974

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA