WO1984002023A1 - Time-ordered data base - Google Patents

Time-ordered data base Download PDF

Info

Publication number
WO1984002023A1
WO1984002023A1 PCT/US1983/001697 US8301697W WO8402023A1 WO 1984002023 A1 WO1984002023 A1 WO 1984002023A1 US 8301697 W US8301697 W US 8301697W WO 8402023 A1 WO8402023 A1 WO 8402023A1
Authority
WO
WIPO (PCT)
Prior art keywords
data base
data
facilities
version
record
Prior art date
Application number
PCT/US1983/001697
Other languages
French (fr)
Inventor
Gerald Carroll Boyle
Original Assignee
Western Electric Co
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 Western Electric Co filed Critical Western Electric Co
Priority to JP50365283A priority Critical patent/JPS59502039A/en
Publication of WO1984002023A1 publication Critical patent/WO1984002023A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/42Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker
    • H04Q3/47Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker using translators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists
    • 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/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users
    • Y10S707/99954Version management

Definitions

  • This invention relates to data bases and, more particularly, to a data base with information having significant time dependencies.
  • methods and apparatus are provided to create, maintain, and use a data base structure and data base management tools for time-ordered or time-dependent data items. More specifically, all of the information required to represent the data base contents at desired future points in time is maintained in the data base.
  • Queries into the data base are time-stamped to limit the access to the proper time-dependent version of the data base.
  • a particular advantage of the present invention is the ability to deal with the state of the data base as it will be at some future time, rather than simply as the data base is at the present time. Assigning facilities, for example, can be optimized for the resources available in the future when the need arises, rather than at the present time.
  • FIG. 1 is a generalized schematic representation of a time-dependent data base system in accordance with the present invention
  • FIG. 2 is a block diagram of one application of a data base for the assignment of facilities to users of those facilities;
  • FIG. 3 is a generalized block diagram of the telephone outside plant facilities used in providing telephone service
  • FIG. 4 is a graphical representation of typical outside plant facilities used to provide service to a particular telephone subscriber
  • FIG. 5 is a directed graph representation of an inventory of the facilities shown in FIG. 4;
  • FIG. 6 is a hypergraph representation of the connectivity of the facilities shown in FIG. 4;
  • FIG. 7 is a complete graphical representation of one node of the hypergraph of FIG. 6.
  • FIG. 8 is a typical data base record for the node of FIG. 7, illustrating the hyperedge representation
  • FIG. 9 is a flow chart of the service order processing procedures which utilize the pending versions of a data base
  • FIG. 10 is a general block diagram of an illustrative portion of the pending data base using delta nodes to record various versions of the data base;
  • FIG. 11 illustrates the e-ontents of one of the delta nodes of FIG. 10.
  • FIG. 12 is a general block diagram of the pending data base showing the use of history trees and transaction sets.
  • Box 10 represents a data base at a present time, T Q , containing all of the data items and all of the data interrelationships necessary to represent the current state of the physical entities represented in the data base.
  • T Q a data base at a present time
  • transaction 12 operates on data base 10 to produce data base 13.
  • Data base 13 represents the physical world as it is expected to exist at time T- j _, but the data base itself can be created at any time after time T Q (up to time T- j _) to permit sound planning of the actual changes in the physical world.
  • a “transaction” is merely a set of operations which take the data base from one self-consistent state to another self-consistent state.
  • a data base for assigning physical facilities to particular users can be used to plan a future assignment by locating available facilities through the then current data base version and creating a new version of the data base representing the physical facilities after they have been assigned, but available before the physical assignment actually takes place.
  • this data base representation of future physical events lies in permitting yet further change requests 14 . . . 15, to be similarly planned currently, using respective transactions 16 . . . 17, to operate on data bases 13 . . . 18 which accurately represent the data base at the time the physical facilities must be changed.
  • the facilities available for reassignment i.e., the idle facilities, are those facilities idle and available at the time the future assignment is to be made, and not those idle and available at the present time.
  • requests for data from the data base must be accompanied by a time stamp (T ⁇ ) to indicate which version of the data base is to be read.
  • a data base selector 21 uses this time stamp to provide access only to the data base version bearing the appropriate time stamp. It is not, of course, necessary to replicate the entire data base for each of versions 10, 13, 18, . . . 19 of the data base. In the preferred embodiment, it is only necessary to provide updated versions of those portions of the data base which are changed by the change orders 11, 14 . . . 15, respectively. Selector 21 then merely has to ascertain if a query is directed toward an unchanged record or toward one of the changed records, and which version of the changed record.
  • FIG. 2 there is shown a general block diagram of a particular data base application.
  • the information processing system of FIG. 2 is shown.
  • O P W ⁇ P comprises a data base 30, illustrated as being contained on a magnetic disc-pack, a data base manager 31> a group of application programs 32, an input device 33 and an output device 34.
  • the data base manager 31 and the application programs 32 are both computer programs, written in source code by programmers, compiled into object code by a compiler program (not shown) and loaded into the internal memory of a general purpose data processor 35.
  • the input device 33 provides a request to the application programs 32 for service requiring information in the data base 30.
  • Application programs 32 decide what information is required to fill the service request, format a request for specific records and then forward that request to the data base manager 31.
  • the data base manager 31 retrieves and stores records without regard to the overall data base architecture.
  • the record access routines of data base manager 31 retrieve the desired information from data base 30 and pass the information as values back to application programs 32. These values will then be reformatted by application programs 32 to provide the particular service requested by input device 33. The result will be forwarded to output device 34.
  • While device 33 may be a keyboard and device 34 a display screen in an integral terminal operated by a human user, device 33 may just as well by an automatic electronic or mechanical device (e.g., a parts counter in an assembly line) and device 34 may likewise be an automatic device (e.g., a purchase order generator to reorder inventory parts when levels fall too low) .
  • the system of FIG. 2 is a service-providing system rather than simply an information-providing system.
  • the service inventory control, facilities assignments, ticket preparation, etc.
  • the data base 30 is created and maintained by data base maintenance facility 36. Facility 36 also uses the data base manager 31 to access data base 30, but in this case to create and update the records in data base 30. This activity is necessary to the present invention where a plurality of time-dependent versions of the data base must be stored simultaneously.
  • FIG. 3 there is shown a schematic diagram of typical facilities used to connect a telephone subscriber to the local central office. Since these facilities are all outside of the central office 40, they have been termed "outside plant" facilities. Such outside plant facilities consist of multiconductor cables such as cables 41 through 45, each of which includes a large number of twisted pairs of copper wires. In general, one such pair is used to provide telephone service to one customer. Cables are identified as to their proximity to the central office 40, e.g., fl cables 41 and 42 and f2 cables 43, 44 and 45, separated by cross-connect terminals 46 and 47. Some areas require three or more levels of cable (f3, f4, etc.) in the outside plant interconnection system.
  • Cross-connect terminals 44 and 47 are devices for connecting electrical wire pairs to each other. They have one set of binding posts for connecting wire pairs from the central office side (the IN side) and another set for connecting wire pairs from the other (field) side (the OUT side) . In addition, cross-connect terminals have jumper wires selectively interconnecting selected IN pairs with selected OUT pairs, thereby effectuating the physical interconnection between distribution cable pairs and feeder cable pairs. Cables and pairs have central office ends and field ends.
  • Distribution terminals 48 At selected points along cables 41 through 45 are distribution terminals 48. These distribution terminals also have binding posts for connecting cable pairs to customer service wires such as drop wires 49 and 50 connected to customer living units 51 and 52, respectively. Distribution terminals are typically located at concentrations of subscriber living units and can be located on telephone poles, in pedestals or on customers' premises.
  • the assignment problem in providing telephone service to the living unit of a telephone subscriber is to assign, in the data base, the necessary wires, terminals, binding posts and customer service wires to create a complete and continuous electrical circuit (a local loop) between the customers' telephone set and the central office.
  • the assignment is made in the data base, the corresponding physical connections have to be made out in the field at the time service is to be initiated.
  • the data base must reflect both pending service orders and completed service orders. All facilities are either working or idle and assignments for new customers are generally selected from idle facilities. Since rearranging the physical facilities is a very expensive activity, most of the assignment algorithms attempt to minimize the physical
  • FIG. 4 there is shown the specific facilities assigned to provide telephone service to living unit 52 in FIG. 3.
  • cable 41 connecting central office 40 with cross-connect terminal 46 is identified as cable "01.”
  • the specific pair in cable 01 assigned to living unit 52 is pair “21", best represented by the cable-pair dyad "01:21.”
  • the field end of pair 01:21 is connected to binding posts 52 on the IN side of terminal 46.
  • the IN binding posts 52 are cross-connected by wire jumpers to OUT binding posts 302.
  • the central office end of the 121st pair of cable 44 (pair 0101:121) is connected to binding posts 302 in terminal 46.
  • the pair 0101:121 is connected through distribution terminal 48 to drop wire 50 and thence to living unit 52.
  • each facility used for this loop has both a type (pair, cable, terminal, etc.) and an identification (pair 01:21, terminal 46, binding posts 302, etc.).
  • the general problem is to create a data base which serves as an inventory of the facilities and simultaneously facilitates the assignment and reassignment of those facilities into service-providing loops between customers and the central office.
  • FIG. 5 there is shown a standard prior art directed graph representing the inventory of facilities making up the outside plant facilities illustrated graphically in FIG. 4.
  • Each box in FIG. 5 is a vertex of the graph and one vertex is provided for each physical entity in the inventory.
  • box 60 is a graph vertex representing cable 41
  • vertex 61 represents cross-connect terminal 46
  • vertex 62 represents pair 01:21
  • vertex 63 represents cable 44
  • vertex 64 represents pair 0101:121
  • vertex 65 represents distribution terminal 48
  • vertex 66 represents living unit 52.
  • These vertices are the entities in an entity-relationship data base.
  • the arrow 69 represents the relationship "connected to” and carries further information identifying the binding posts ("CO BP 52"), i.e., binding posts 52 on the central office (IN) side of terminal 46.
  • the other directed arrows in FIG. 5 have analogous meanings and will not be further discussed here, except to note that the distribution terminal 48 and the living unit 52 have “served by” and “serves” interrelationships and the customer service wire 50 has been left out for simplicity.
  • the inventory information contained in FIG. 5 is necessary to keep track of the physical facilities used in the loop plant. It is not particularly convenient, however, in assigning an electrical circuit (a loop) to a customer.
  • FIG. 6 there is shown another set of arrows (edges) between these same vertices that better serve the loop assignment need.
  • FIG. 6 the same vertices shown in FIG. 5 are repeated (except for the cable vertices) and a circuit vertex 80 has been added.
  • the graph of FIG. 6 can be said to represent the connectivity of the communication circuit as distinguished from the inventory of the parts (FIG. 5) .
  • the circuit (named with a telephone number in vertex 80) is composed of three parts: pair 01:21, pair 0101:121 and living unit 52 (along with drop wire 50) . These three parts are connected to each other through terminals. For efficiency of assignment processing, it is desirable to
  • the hypergraph of FIG. 6 serves to maintain an inventory of assigned electrical circuits while that of FIG. 5 maintains an inventory of physical parts. Both are necessary to adequately service the telephone subscribers.
  • FIG. 7 there is shown a graphical representation of one record of the hypergraph data base used to represent both the physical facilities and the circuit assignment illustrated in FIG. 3.
  • the record represented in FIG. 7 is that representing pair 101:121.
  • the record includes a body portion (box 62) and a plurality of edge portions 82,83,86,87,88 and 89, some of which (82 and 83) are hyperedges.
  • the record illustrated in FIG. 7 contains all of the information about pair 0101:121 that is in the data base.
  • the "name" of this pair by which it is known in the outside world (pair 101:121) is a separate entity 91 pointed to by edge 90.
  • the internal identification of each record is by way of an internal number which permits direct access to the associated record. Moreover, the external name of an entity can change without changing all of the internal references thereto.
  • FIG. 8 there is shown an alphanumeric representation of the record in the data base for pair 0101:121.
  • the body portion of the record appears first, but the edges are ordered haphazardly. A specific edge must be searched for in this arrangement. Alternatively, the edges could be ordered in a preselected sequence and accessed directly.
  • the contents of the data record of FIG. 8 will now be discussed. It will be first noted that each physical facility is identified with an internal identification number different from the name by which it is known in the external world. These internal identification numbers are unique to the identified record, thus simplifying the computer record-keeping, and permitting arbitrary and changeable names in the outside world.
  • a special edge 90 points to the external identification 91 ("pair 0101:121,") as shown in FIG. 7, and at lines gl-g3 in FIG. 8.
  • Edges at lines cl-c5 and fl-f5 are hyperedges, each including two record identifications.
  • Each body or edge has one or more lines of so-called "application data," i.e., information useful in applying the data base information to a problem in the outside world.
  • application data i.e., information useful in applying the data base information to a problem in the outside world.
  • the edge is identified as pointing to binding posts on the centra.1 office side of the terminal (as distinguished from the "field” side of the terminal) .
  • the pair is indicated as being connected to the "blue-green" stub wires on the "IN” side of the distribution terminal (as distinguished from "OUT” side) .
  • the edge hl-h2 identifies the loop circuit of which this pair is a part.
  • FIG. 9 there is shown a flow chart for the process of making time-dependent changes in a data base such as that illustrated in FIGS. 1 through 8. It is assumed that most changes are initiated by a "customer"
  • the service order may merely be a manually filled out paper slip or an electronic record in a separate data base. In either event, the service order contains all of the necessary information to provide the new, altered or deleted service to the customer. This includes customer identification, the date the change is to be made (T i ) , and the precise nature of the changes in service.
  • the change in service requires changes in the assignment of physical facilities to the customer. For example, new services require the assignment of an entire local loop to the customer, enhanced service may require more or better facilities and termination of service requires the deassignment (idling) of services previously assigned to that customer.
  • the version of the data base at time ⁇ — - j . corresponds precisely to the actual assignments of the physical facilities which is expected to exist at the future time ⁇ . This is vitally important since physical facilities currently available for assignment may not be available for assignment at time ⁇ due to previous assignment (after the present time T Q , but before time T ⁇ ) . Similarly, facilities not currently available may well be available at time ⁇ due to deassignment in that interval. A simple case illustrating this is the deassignment at a future time of a local loop to a customer moving out of a living unit and the reassignment of that same loop to a new customer moving into the living unit after the old customer moves out.
  • box 103 It is entirely possible (indeed, likely) that other transactions have already been run against the data base due to previously received service orders with due dates after time T j _. Since the ⁇ transactions in box 102 have changed the data base against which these post-T ⁇ transactions must be run, it is necessary to reexecute post-T ⁇ transactions against new data base versions. This is accomplished in box 103. It will be noted that all transactions which have been executed against some version of the data base, but have not yet physically taken place in the outside plant facilities, are called "pending" transactions and the data base versions after time T Q are called pending versions. In FIG. 9, box 103 reexecutes all transactions still pending at time T ⁇ and which affect data base records which have changed because of the ⁇ transaction. This, of course, changes the data base versions after time ⁇ to accommodate the changes wrought by the ⁇ transaction.
  • a work order is prepared in box 105.
  • This work order actually directs and schedules the physical changes necessary to carry out the change in facilities (transaction ⁇ required to make the physical connections of facilities correspond with the T ⁇ data base.
  • These physical changes are executed in box 106 at time j , either manually by an outside plant crew, or automatically for facilities that can be reassigned electronically from a telephone central office location, for example, by changes in the memory of an electronics switching system or a pair gain transmission system.
  • OMPI IPO immediately in the current or root version of the data base since the physical facilities themselves have actually changed. While these changes are preferably planned and hence pending in the data base, emergency changes which are unplanned must nevertheless be reflected in the data base. These are essentially transactions, take precedence over all pending transactions, and require the reexecution of all pending transactions to reflect the new configuration of available physical facilities. It will be appreciated that, while it is possible to create a large number of different versions of the entire data base, as suggested in FIG. 1, it is neither efficient nor necessary to replicate the entire data base for each version. It will be noted that the transaction which transforms each version of the data base into the next successive version affects a very limited number of the data base records.
  • FIGS. 10 and 12 two alternative techniques for handling the numerous pending versions of the data base will be described. These two techniques are equally efficacious in handling the pending problem, but rely on somewhat different data representations.
  • delta nodes In FIG. 10 there is shown a particular implementation of pending data bases using so-called "delta nodes".
  • a delta node is nothing more than a summary of the changes needed to move from one version of the affected data base nodes to the next succeeding version of the affected data base nodes and enough information to permit reexecution of the transaction if that becomes necessary.
  • the affected nodes are replicated, one reflecting the state of the node before execution of the T ⁇ transaction and the other representing the state of the node after the execution of the TJ transaction.
  • the delta nodes include pointers (hyperedges) to both the "before" and "after” versions.
  • D i delta node 120 In FIG. 10, for example, D i delta node 120
  • D- delta node 120 (illustrated in FIG. 11) , includes an edge 127 pointing to a list of all of the T- changes.
  • D- delta node 120 also includes hyperedges 121 . . . 124 pointing to the "before" nodes 125 . . . 126 and the "after" nodes 129 . . . 130.
  • node 129 is a replication of node 125 but including the changes wrought by the ⁇ transaction.
  • node 130 is a replication of node 126 but including the ⁇ transaction changes.
  • the node pairs 125-129 and 126-130 also have hyperedges 131 through 134, respectively, pointing directly to each other and to the delta node 120.
  • D ⁇ + - j _ delta node 135 Similar to D- delta node 120.
  • the delta nodes 120 and 135 may have an edge 138 pointing to each other to facilitate the identification and reworking of the various versions of the data base.
  • delta nodes and further versions of the nodes 136 . . . 137 may also be created to accommodate yet further pending versions of the data base linked together by edges 122, 138 and 123. Indeed, the entire multiversion data base represented in FIG. 1 is contained in the sum total of all of the delta nodes and all of the replicated physical facility nodes such as those shown in FIG. 10.
  • a delta node is created for the proper time T ⁇ _ and, by simply changing pointers, pushing the T _ ⁇ nodes and T-£ +1 nodes apart to make room for the new T ⁇ nodes.
  • the new T transaction may cause changes requiring the reexecution of many of the post-T ⁇ transactions referenced in the post-Tj delta nodes.
  • the edges such as edges 122, 138 and 123 facilitate this type of reexecution.
  • the delta node approach illustrated in FIGS. 10 and 11 has the advantage of representing all pending versions of the data base in nodes structured exactly like all other data base nodes.
  • One edge of the delta node points to the transaction list while other edges identify all of the affected nodes, both before and after the transaction. Since the delta nodes are in the same form as the physical facility nodes, the same data base primitive procedures can be used to locate, access, change, create and delete the delta nodes. This capability simplifies the data base manager since many of the same software facilities used for the rest of the data base can be used for the delta nodes.
  • edges pointing to such independent delta nodes can be included in the current delta node whenever the current transaction forces access to such an independent delta node.
  • This "excluded delta" list greatly facilitates reworking because these nodes need not be accessed during reexecution of post-T ⁇ transactions.
  • the edges 122, 138 and 123 assist in maintaining the predecessor-successor relationships. This information is useful, for example, when a transaction is canceled.
  • a "version" of the data base which is useful for carrying out a transaction need only include those nodes of the data base that are affected by the transaction. Such a version can be generated at any time by looking for the affected nodes and, if subject to previous transactions, locating the proper delta node.
  • the delta nodes provide all of the information necessary to identify a self- consistent set of equipment node versions.
  • FIG. 12 there is shown an alternative approach to the implementation of a pending data base, using so-called history trees and transaction sets.
  • the root nodes 150, 151, . . . 152 represent the current versions of all of the physical facilities represented in the data base. In total, these nodes 150, . . . 152 represent the root or time T_ version of the data base.
  • the transactions representing the service orders are grouped into transaction sets 153, 154, . . . 155, which are that set of changes necessary to carry out the corresponding ( ] _, 2 • . . T ⁇ ) date-dependent service orders.
  • node 150 is replicated as node 156 for transaction 153 and is replicated as node 157 for transaction set 155.
  • node 151 is replicated as nodes 158 and 159 for transaction sets 153 and 154, respectively
  • node 152 is replicated as nodes 160 and 161 for transaction sets 154 and 155, respectively.
  • the number of replications of each of root nodes 150 . . . 152 is exactly equal to the number of transactions 153 . . . 155 which affect that node.
  • the number and identity of those nodes affected by any particular transaction set can be entirely arbitrary and, indeed, is fully determined by the physical changes which will be necessary to execute the work order associated with that transaction.
  • FIG. 12 corresponds exactly to the representation of FIG. 10.
  • Each physical entity node is replicated for each service order having transactions affecting that node. Numerous versions of each node can exist simultaneously, differentiated by the transactions associated therewith.
  • the complete set for any version o.f the data base comprises the set of replicated nodes for the corresponding transaction (the rows in FIG. 12) plus the most immediately above nodes for those nodes not replicated at the transaction set row level. Since the transactions correspond to time-stamped pending conditions, this set of nodes is the time stamped pending version of the data base. Accesses can be made to this set as a consistent set which accurately represents what the physical facilities will look like at the time identified by the appropriate transaction.
  • transaction set list identifies (points to) nodes 156 and 158; transaction set 154 identifies nodes 159
  • OMP and 160; and transaction set 155 identifies nodes 157 and 158.
  • the transaction set list is no more than a sequence of pointers to those replicated nodes affected by that particular set of transactions.
  • the history tree lists are merely directed pointer lists linking each of the root nodes 150 . . . 152 with all of the existing pending replications of that same node.
  • a history tree links node 150 with nodes 156 and 157; a history tree links node 151 with nodes 158 and 159; and a history tree links node 152 with nodes 160 and 161. It can be seen that these history trees can also be nothing more than a list of pointers to the actual node versions, arranged in historical order.
  • T ⁇ _ ⁇ a new transaction (new pending service order) merely involves using the T ⁇ _ ⁇ transaction to identify the proper version of the affected nodes. If the node to be replicated is not on the transaction list for the next preceding (T ⁇ _ ⁇ .) transaction, the history tree for that node can be -entered and traced to find the then appropriate node version, i.e., the next higher node version on the history tree list. This next higher version might well be the root version (if no transaction affecting that node has as yet been specified) , in which case the root version is used in carrying out the new transaction.
  • a new transaction ( ⁇ ) is created and inserted in the list between the portions of the list. Since linked list processing is well-known, these techniques can be readily applied to rapidly access the required nodes.

Abstract

A data base system in which future versions of the data base are maintained currently in response to orders for future execution. All transactions against the data base are time stamped to assure access to the proper version of the data base. Information concerning the various versions are stored as delta nodes or lists. The application of this data base system to the assignment of outside plant telephone facilities to telephone subscribers is also described.

Description

TIME-ORDERED DATA BASE
Technical Field
This invention relates to data bases and, more particularly, to a data base with information having significant time dependencies. Background of the Invention
It is well-known to use digital storage facilities and a programmed computer to provide, respectively, a data base storage medium and a data base manager. The storage facilities serve to store large amounts of information in digital form while the data base manager is a computer program facility for accessing, searching and changing the information in the data base. Such data base systems are often used to provide an inventory of physical facilities available to a community of users. The facilities may, for example, from time to time be assigned for exclusive use by one of the users to the exclusion of others. A system for airline seat reservations, automobile rental reservations or computer center resource allocation are illustrative of the types of data base systems involving the temporary assignment of facilities to users.
When facilities are temporarily assigned to one user and later are reassigned to another user, the assignment and reassignment of those facilities can react to the instantaneous demand of users for facilities, or can be scheduled out into the future by assignment algorithms which optimize the use of the facilities in some way. In the latter case, it is necessary not only to keep track of the current assignments of facilities to users, but also to keep track of future reassignments of those same facilities to different users.
The general problem of representing future versions of a data base as well as the current version is a complicated problem. Complexity is compounded when processing must be done with such future versions as well as with the current version. Summary of the Invention
In accordance with the illustrative embodiment of the present invention, methods and apparatus are provided to create, maintain, and use a data base structure and data base management tools for time-ordered or time-dependent data items. More specifically, all of the information required to represent the data base contents at desired future points in time is maintained in the data base.
Queries into the data base are time-stamped to limit the access to the proper time-dependent version of the data base.
A particular advantage of the present invention is the ability to deal with the state of the data base as it will be at some future time, rather than simply as the data base is at the present time. Assigning facilities, for example, can be optimized for the resources available in the future when the need arises, rather than at the present time.
Brief Description of the Drawings
FIG. 1 is a generalized schematic representation of a time-dependent data base system in accordance with the present invention; FIG. 2 is a block diagram of one application of a data base for the assignment of facilities to users of those facilities;
FIG. 3 is a generalized block diagram of the telephone outside plant facilities used in providing telephone service;
FIG. 4 is a graphical representation of typical outside plant facilities used to provide service to a particular telephone subscriber;
FIG. 5 is a directed graph representation of an inventory of the facilities shown in FIG. 4;
FIG. 6 is a hypergraph representation of the connectivity of the facilities shown in FIG. 4;
O PI FIG. 7 is a complete graphical representation of one node of the hypergraph of FIG. 6; and
FIG. 8 is a typical data base record for the node of FIG. 7, illustrating the hyperedge representation; FIG. 9 is a flow chart of the service order processing procedures which utilize the pending versions of a data base;
FIG. 10 is a general block diagram of an illustrative portion of the pending data base using delta nodes to record various versions of the data base;
FIG. 11 illustrates the e-ontents of one of the delta nodes of FIG. 10; and
FIG. 12 is a general block diagram of the pending data base showing the use of history trees and transaction sets.
Detailed Description
Referring more particularly to FIG. 1, there is shown a generalized schematic representation of a data base which is time-dependent. Box 10, for example, represents a data base at a present time, TQ, containing all of the data items and all of the data interrelationships necessary to represent the current state of the physical entities represented in the data base. As a result of a change request 11, to take place at a future time, T^, transaction 12 operates on data base 10 to produce data base 13. Data base 13 represents the physical world as it is expected to exist at time T-j_, but the data base itself can be created at any time after time TQ (up to time T-j_) to permit sound planning of the actual changes in the physical world. A "transaction" is merely a set of operations which take the data base from one self-consistent state to another self-consistent state. A data base for assigning physical facilities to particular users, for example, can be used to plan a future assignment by locating available facilities through the then current data base version and creating a new version of the data base representing the physical facilities after they have been assigned, but available before the physical assignment actually takes place.
The value of this data base representation of future physical events lies in permitting yet further change requests 14 . . . 15, to be similarly planned currently, using respective transactions 16 . . . 17, to operate on data bases 13 . . . 18 which accurately represent the data base at the time the physical facilities must be changed. In facility assignment systems, for example, the facilities available for reassignment, i.e., the idle facilities, are those facilities idle and available at the time the future assignment is to be made, and not those idle and available at the present time.
Similarly, requests for data from the data base, schematically represented by line 20, must be accompanied by a time stamp (T^) to indicate which version of the data base is to be read. A data base selector 21 uses this time stamp to provide access only to the data base version bearing the appropriate time stamp. It is not, of course, necessary to replicate the entire data base for each of versions 10, 13, 18, . . . 19 of the data base. In the preferred embodiment, it is only necessary to provide updated versions of those portions of the data base which are changed by the change orders 11, 14 . . . 15, respectively. Selector 21 then merely has to ascertain if a query is directed toward an unchanged record or toward one of the changed records, and which version of the changed record.
In order to better understand the use of time- dependent data bases, a particular application of these principles will be discussed. More specifically, a particular data base and particular data base application will be described in detail so that the time-dependent data base representation can be more readily understood. Referring more particularly to FIG. 2, there is shown a general block diagram of a particular data base application. The information processing system of FIG. 2
O P WΪP comprises a data base 30, illustrated as being contained on a magnetic disc-pack, a data base manager 31> a group of application programs 32, an input device 33 and an output device 34. The data base manager 31 and the application programs 32 are both computer programs, written in source code by programmers, compiled into object code by a compiler program (not shown) and loaded into the internal memory of a general purpose data processor 35.
The input device 33 provides a request to the application programs 32 for service requiring information in the data base 30. Application programs 32 decide what information is required to fill the service request, format a request for specific records and then forward that request to the data base manager 31. The data base manager 31 retrieves and stores records without regard to the overall data base architecture.
The record access routines of data base manager 31 retrieve the desired information from data base 30 and pass the information as values back to application programs 32. These values will then be reformatted by application programs 32 to provide the particular service requested by input device 33. The result will be forwarded to output device 34.
While device 33 may be a keyboard and device 34 a display screen in an integral terminal operated by a human user, device 33 may just as well by an automatic electronic or mechanical device (e.g., a parts counter in an assembly line) and device 34 may likewise be an automatic device (e.g., a purchase order generator to reorder inventory parts when levels fall too low) . Thus the system of FIG. 2 is a service-providing system rather than simply an information-providing system. The service (inventory control, facilities assignments, ticket preparation, etc.) requires the availability of the information in data base 30, but goes beyond that information to provide a basis for service of some type in the outside world. The data base 30 is created and maintained by data base maintenance facility 36. Facility 36 also uses the data base manager 31 to access data base 30, but in this case to create and update the records in data base 30. This activity is necessary to the present invention where a plurality of time-dependent versions of the data base must be stored simultaneously.
Having explained the present invention in a generalized way in connection with FIG. 1 and a generalized data base in connection with FIG. 2, the balance of the figures will be used to explain in detail a particular application of the data base representation and the use of the present invention in connection therewith. This application is the assignment of physical facilities (wires, cables, terminal boxes, etc.) to a telephone subscriber in order to connect that subscriber's telephone to the local telephone central office. While such assignments are maintained for a relatively long period of time, customers do move and facilities must be reassigned. In central offices serving tens of thousands of customers, such reassignments of facilities constitute a major, labor-intensive activity. Maximizing the efficiency and minimizing the cost of such reassignments has therefore become an important telephone company activity. Referring then to FIG. 3, there is shown a schematic diagram of typical facilities used to connect a telephone subscriber to the local central office. Since these facilities are all outside of the central office 40, they have been termed "outside plant" facilities. Such outside plant facilities consist of multiconductor cables such as cables 41 through 45, each of which includes a large number of twisted pairs of copper wires. In general, one such pair is used to provide telephone service to one customer. Cables are identified as to their proximity to the central office 40, e.g., fl cables 41 and 42 and f2 cables 43, 44 and 45, separated by cross-connect terminals 46 and 47. Some areas require three or more levels of cable (f3, f4, etc.) in the outside plant interconnection system.
Cross-connect terminals 44 and 47 are devices for connecting electrical wire pairs to each other. They have one set of binding posts for connecting wire pairs from the central office side (the IN side) and another set for connecting wire pairs from the other (field) side (the OUT side) . In addition, cross-connect terminals have jumper wires selectively interconnecting selected IN pairs with selected OUT pairs, thereby effectuating the physical interconnection between distribution cable pairs and feeder cable pairs. Cables and pairs have central office ends and field ends.
At selected points along cables 41 through 45 are distribution terminals 48. These distribution terminals also have binding posts for connecting cable pairs to customer service wires such as drop wires 49 and 50 connected to customer living units 51 and 52, respectively. Distribution terminals are typically located at concentrations of subscriber living units and can be located on telephone poles, in pedestals or on customers' premises.
The assignment problem in providing telephone service to the living unit of a telephone subscriber is to assign, in the data base, the necessary wires, terminals, binding posts and customer service wires to create a complete and continuous electrical circuit (a local loop) between the customers' telephone set and the central office. Once the assignment is made in the data base, the corresponding physical connections have to be made out in the field at the time service is to be initiated. The data base must reflect both pending service orders and completed service orders. All facilities are either working or idle and assignments for new customers are generally selected from idle facilities. Since rearranging the physical facilities is a very expensive activity, most of the assignment algorithms attempt to minimize the physical
O P rearrangement of plant facilities. For example, facilities assigned to a living unit continue to be so assigned even after a customer has moved. The assumption is that a new customer will soon move in and request service. On the other hand, after some empirically determined time (a few months) , the likelihood of the living unit being reoccupied becomes very small and releasing the facilities for use elsewhere becomes the best tactic.
In FIG. 4 there is shown the specific facilities assigned to provide telephone service to living unit 52 in FIG. 3. Thus, cable 41 connecting central office 40 with cross-connect terminal 46 is identified as cable "01." The specific pair in cable 01 assigned to living unit 52 is pair "21", best represented by the cable-pair dyad "01:21." The field end of pair 01:21 is connected to binding posts 52 on the IN side of terminal 46. The IN binding posts 52 are cross-connected by wire jumpers to OUT binding posts 302. The central office end of the 121st pair of cable 44 (pair 0101:121) is connected to binding posts 302 in terminal 46. At the other (field) end, the pair 0101:121 is connected through distribution terminal 48 to drop wire 50 and thence to living unit 52.
It will be noted that each facility used for this loop has both a type (pair, cable, terminal, etc.) and an identification (pair 01:21, terminal 46, binding posts 302, etc.). The general problem is to create a data base which serves as an inventory of the facilities and simultaneously facilitates the assignment and reassignment of those facilities into service-providing loops between customers and the central office.
In FIG. 5 there is shown a standard prior art directed graph representing the inventory of facilities making up the outside plant facilities illustrated graphically in FIG. 4. Each box in FIG. 5 is a vertex of the graph and one vertex is provided for each physical entity in the inventory. Thus box 60 is a graph vertex representing cable 41, vertex 61 represents cross-connect terminal 46, vertex 62 represents pair 01:21, vertex 63 represents cable 44, vertex 64 represents pair 0101:121, vertex 65 represents distribution terminal 48 and vertex 66 represents living unit 52. These vertices are the entities in an entity-relationship data base.
The relationships between these entities are represented in FIG. 5 by the directed arrows (edges) between the vertices. Thus, arrow 67 represents the relationship "connected to" since cable 41 is connected to terminal 46. Arrow 68 represents the relationship
"included in" since pair 01:21 is included in cable 41. Finally, the arrow 69 represents the relationship "connected to" and carries further information identifying the binding posts ("CO BP 52"), i.e., binding posts 52 on the central office (IN) side of terminal 46. The other directed arrows in FIG. 5 have analogous meanings and will not be further discussed here, except to note that the distribution terminal 48 and the living unit 52 have "served by" and "serves" interrelationships and the customer service wire 50 has been left out for simplicity. The inventory information contained in FIG. 5 is necessary to keep track of the physical facilities used in the loop plant. It is not particularly convenient, however, in assigning an electrical circuit (a loop) to a customer. In FIG. 6 there is shown another set of arrows (edges) between these same vertices that better serve the loop assignment need.
In FIG. 6, the same vertices shown in FIG. 5 are repeated (except for the cable vertices) and a circuit vertex 80 has been added. The graph of FIG. 6 can be said to represent the connectivity of the communication circuit as distinguished from the inventory of the parts (FIG. 5) . The circuit (named with a telephone number in vertex 80) is composed of three parts: pair 01:21, pair 0101:121 and living unit 52 (along with drop wire 50) . These three parts are connected to each other through terminals. For efficiency of assignment processing, it is desirable to
O P 1P know directly that pair 01:21 is connected to pair 0101:121. At the same time, it is necessary to know that these interconnections take place in terminals and at specific binding posts. The hyperedges 81 and 82 are used to simultaneously point to the connected pair and to the terminal through which this connection is effected. The representation of FIG. 5 in which the pair-to-pair connection could be discovered by further searching in the data base is very inefficient for assigning facilities. The interconnections of pair 0101:121 (box 64) and living unit 52 (box 66) is likewise represented by two hyperedges 83 and 84, serving the same function for this part of the circuit. It should be noted that a rearrangement of the jumper wires could be used to reassign the physical facilities to other circuits without changing the inventory. That is, the connectivity of FIG. 6 could change without changing the inventory of FIG. 5.
The hypergraph of FIG. 6 serves to maintain an inventory of assigned electrical circuits while that of FIG. 5 maintains an inventory of physical parts. Both are necessary to adequately service the telephone subscribers.
In FIG. 7 there is shown a graphical representation of one record of the hypergraph data base used to represent both the physical facilities and the circuit assignment illustrated in FIG. 3. The record represented in FIG. 7 is that representing pair 101:121. The record includes a body portion (box 62) and a plurality of edge portions 82,83,86,87,88 and 89, some of which (82 and 83) are hyperedges. The record illustrated in FIG. 7 contains all of the information about pair 0101:121 that is in the data base. It will be noted that the "name" of this pair by which it is known in the outside world (pair 101:121) is a separate entity 91 pointed to by edge 90. The internal identification of each record is by way of an internal number which permits direct access to the associated record. Moreover, the external name of an entity can change without changing all of the internal references thereto.
In FIG. 8 there is shown an alphanumeric representation of the record in the data base for pair 0101:121. The body portion of the record appears first, but the edges are ordered haphazardly. A specific edge must be searched for in this arrangement. Alternatively, the edges could be ordered in a preselected sequence and accessed directly. The contents of the data record of FIG. 8 will now be discussed. It will be first noted that each physical facility is identified with an internal identification number different from the name by which it is known in the external world. These internal identification numbers are unique to the identified record, thus simplifying the computer record-keeping, and permitting arbitrary and changeable names in the outside world. A special edge 90 points to the external identification 91 ("pair 0101:121,") as shown in FIG. 7, and at lines gl-g3 in FIG. 8.
Edges at lines cl-c5 and fl-f5 are hyperedges, each including two record identifications. Each body or edge has one or more lines of so-called "application data," i.e., information useful in applying the data base information to a problem in the outside world. For example, at line c-5, the edge is identified as pointing to binding posts on the centra.1 office side of the terminal (as distinguished from the "field" side of the terminal) . At line e-3, the pair is indicated as being connected to the "blue-green" stub wires on the "IN" side of the distribution terminal (as distinguished from "OUT" side) . The edge hl-h2 identifies the loop circuit of which this pair is a part.
In FIG. 9, there is shown a flow chart for the process of making time-dependent changes in a data base such as that illustrated in FIGS. 1 through 8. It is assumed that most changes are initiated by a "customer"
(i.e., user of the facilities) request 100. This customer request is formalized in a service order in box 101
f OMPI t λ WH associated with a due date ^. The service order may merely be a manually filled out paper slip or an electronic record in a separate data base. In either event, the service order contains all of the necessary information to provide the new, altered or deleted service to the customer. This includes customer identification, the date the change is to be made (Ti) , and the precise nature of the changes in service. The change in service requires changes in the assignment of physical facilities to the customer. For example, new services require the assignment of an entire local loop to the customer, enhanced service may require more or better facilities and termination of service requires the deassignment (idling) of services previously assigned to that customer. These changes in data base assignments are summarized as a transaction against the data base, deleting, adding or substituting specific assignments of elements of the physical facilities to particular circuits and to particular customers (usually represented as a telephone number) . As can be seen in FIG. 1, the present invention contemplates the availability of a plurality of data base representations identified as to the time in the future at which the actual changes in the interconnection and assignment of the physical facilities is to take place. In box 102 of FIG. 9, the time stamp ^ is used to select the version of the data base which corresponds to the state of the physical assignments at the time ^. This, of course, is the version of the data base created by the transaction which took place at time Ti i, i.e., the data base version created to correspond to the next earlier point of time. In box 102, the transaction necessary to carry out the reassignment of facilities is executed. It will be noted that the data base version operated on (version T: i) does not represent the current physical assignments of the facilities, but some future state of these assignments resulting from the successive execution of transactions corresponding to time ^ 2 . . . '-■ ι__ - It will also be
-gTRE OMPI noted that the version of the data base at time ^-j. corresponds precisely to the actual assignments of the physical facilities which is expected to exist at the future time ^. This is vitally important since physical facilities currently available for assignment may not be available for assignment at time ^ due to previous assignment (after the present time TQ, but before time T^) . Similarly, facilities not currently available may well be available at time ^ due to deassignment in that interval. A simple case illustrating this is the deassignment at a future time of a local loop to a customer moving out of a living unit and the reassignment of that same loop to a new customer moving into the living unit after the old customer moves out. It is entirely possible (indeed, likely) that other transactions have already been run against the
Figure imgf000015_0001
data base due to previously received service orders with due dates after time Tj_. Since the ^ transactions in box 102 have changed the data base against which these post-T^ transactions must be run, it is necessary to reexecute post-T^ transactions against new data base versions. This is accomplished in box 103. It will be noted that all transactions which have been executed against some version of the data base, but have not yet physically taken place in the outside plant facilities, are called "pending" transactions and the data base versions after time TQ are called pending versions. In FIG. 9, box 103 reexecutes all transactions still pending at time T^ and which affect data base records which have changed because of the ^ transaction. This, of course, changes the data base versions after time ^ to accommodate the changes wrought by the ^ transaction.
After the post-T^ transactions are reexecuted in box 103, time is allowed to pass until the time j_ is imminent. During this interval, it is entirely possible that the j_ version of the data base is again changed due to the reexecution of the T^ transaction resulting from
OMPI some new service order with a due data preceding time T^.
When the time ^ is imminent, a work order is prepared in box 105. This work order actually directs and schedules the physical changes necessary to carry out the change in facilities (transaction ^ required to make the physical connections of facilities correspond with the T^ data base. These physical changes are executed in box 106 at time j, either manually by an outside plant crew, or automatically for facilities that can be reassigned electronically from a telephone central office location, for example, by changes in the memory of an electronics switching system or a pair gain transmission system.
When the work order has been completed, this fact is reported back to the data base maintenance facility and the T_ version of the data base is substituted for the T^_-j_ version of the data base in box 107. It will be noted that, by this time, the T: i data base will have become the or root version of the data base due to the execution of all previous pre-T^ work orders. Therefore, the ^ version of the data has become the TQ or root version of the data base. The T; i version (the previous version) is then discarded since it it no longer needed. It can thus be seen that the root version is continually being updated as calendar time advances to overtake the sequential pending versions of the data base. The process for a particular customer request terminates in box 108 when the resulting work order is executed, but it will be appreciated that multitudes of other work orders are simultaneously in various stages of the process illustrated in FIG. 9. The use of the time stamps (due dates) permits orderly updates and reassignments of both physical facilities and creation of new pending versions of the data base.
It should be noted that some changes in the data base do not necessarily participate in the pending process illustrated in FIG. 9. Inventory changes reflecting the addition of new or substituted physical facilities, or deletions of old or nonoperative facilities, must be made
OMPI IPO immediately in the current or root version of the data base since the physical facilities themselves have actually changed. While these changes are preferably planned and hence pending in the data base, emergency changes which are unplanned must nevertheless be reflected in the data base. These are essentially transactions, take precedence over all pending transactions, and require the reexecution of all pending transactions to reflect the new configuration of available physical facilities. It will be appreciated that, while it is possible to create a large number of different versions of the entire data base, as suggested in FIG. 1, it is neither efficient nor necessary to replicate the entire data base for each version. It will be noted that the transaction which transforms each version of the data base into the next successive version affects a very limited number of the data base records. It is, therefore, possible to identify all of the data base records (nodes) affected by each T- transaction, and to specify the states of these nodes before and after the changes. If this is done systematically for all pending transactions, it is possible to use these "before" and "after" versions of the specific node data to represent the various pending versions of the data base. Those portions (nodes) of the data base which are not affected by pending transactions simply reside unaffected in the root version of the data base and are accessed as T; versions whenever a request for data or a request for reassignment occurs.
In FIGS. 10 and 12, two alternative techniques for handling the numerous pending versions of the data base will be described. These two techniques are equally efficacious in handling the pending problem, but rely on somewhat different data representations.
In FIG. 10 there is shown a particular implementation of pending data bases using so-called "delta nodes". A delta node is nothing more than a summary of the changes needed to move from one version of the affected data base nodes to the next succeeding version of the affected data base nodes and enough information to permit reexecution of the transaction if that becomes necessary. The affected nodes are replicated, one reflecting the state of the node before execution of the T^ transaction and the other representing the state of the node after the execution of the TJ transaction. The delta nodes include pointers (hyperedges) to both the "before" and "after" versions. In FIG. 10, for example, Di delta node 120
(illustrated in FIG. 11) , includes an edge 127 pointing to a list of all of the T- changes. D- delta node 120 also includes hyperedges 121 . . . 124 pointing to the "before" nodes 125 . . . 126 and the "after" nodes 129 . . . 130. Thus node 129 is a replication of node 125 but including the changes wrought by the ^ transaction. Similarly, node 130 is a replication of node 126 but including the ^ transaction changes. For convenience, the node pairs 125-129 and 126-130, also have hyperedges 131 through 134, respectively, pointing directly to each other and to the delta node 120.
A new service order affecting these same nodes would then be represented by D^+-j_ delta node 135 similar to D- delta node 120. Delta node 135, however, points to nodes 129 . . . 130 as the "before" nodes and to new further replicated and changed nodes 136 . . . 137 as the "after" nodes. The delta nodes 120 and 135 may have an edge 138 pointing to each other to facilitate the identification and reworking of the various versions of the data base.
Further delta nodes and further versions of the nodes 136 . . . 137 may also be created to accommodate yet further pending versions of the data base linked together by edges 122, 138 and 123. Indeed, the entire multiversion data base represented in FIG. 1 is contained in the sum total of all of the delta nodes and all of the replicated physical facility nodes such as those shown in FIG. 10. In order to create a new pending version, a delta node is created for the proper time T^_ and, by simply changing pointers, pushing the T _^ nodes and T-£+1 nodes apart to make room for the new T^ nodes. As previously noted, the new T transaction may cause changes requiring the reexecution of many of the post-T^ transactions referenced in the post-Tj delta nodes. The edges such as edges 122, 138 and 123 facilitate this type of reexecution.
The delta node approach illustrated in FIGS. 10 and 11 has the advantage of representing all pending versions of the data base in nodes structured exactly like all other data base nodes. One edge of the delta node points to the transaction list while other edges identify all of the affected nodes, both before and after the transaction. Since the delta nodes are in the same form as the physical facility nodes, the same data base primitive procedures can be used to locate, access, change, create and delete the delta nodes. This capability simplifies the data base manager since many of the same software facilities used for the rest of the data base can be used for the delta nodes.
It will be noted that many pre-T^ nodes are not affected by the T^ transaction. Transactions are said to be independent if the completion or cancellation of either one can take place without affecting the other. Thus, independent transactions need not be reworked even if they are due after the current transaction has been introduced into the data base. For convenience, edges pointing to such independent delta nodes can be included in the current delta node whenever the current transaction forces access to such an independent delta node. This "excluded delta" list greatly facilitates reworking because these nodes need not be accessed during reexecution of post-T^ transactions. The edges 122, 138 and 123 assist in maintaining the predecessor-successor relationships. This information is useful, for example, when a transaction is canceled. If that transaction has no successors, it can be canceled without any rework. On the other hand, a transaction can be completed (a work order issued) only if there are no predecessors and no conflicts due to other pending completions. Conflicts arise because alternate future views are possible due to some uncertainity as to the actual time of work completion. This happens for large changes which take a substantial amount of time to install in the field. Other alternate futures arise due to the minor reordering of work execution to accommodate convenient field crew deployment. When such conflicts are noted, they are marked as conflicts in each of the affected delta nodes and the alternative actually chosen is used to update the data base.
A "version" of the data base which is useful for carrying out a transaction need only include those nodes of the data base that are affected by the transaction. Such a version can be generated at any time by looking for the affected nodes and, if subject to previous transactions, locating the proper delta node. The delta nodes provide all of the information necessary to identify a self- consistent set of equipment node versions.
In FIG. 12, there is shown an alternative approach to the implementation of a pending data base, using so-called history trees and transaction sets. As in the delta node approach, several time-dependent versions of each node of the data base are simultaneously present. The root nodes 150, 151, . . . 152 represent the current versions of all of the physical facilities represented in the data base. In total, these nodes 150, . . . 152 represent the root or time T_ version of the data base. The transactions representing the service orders are grouped into transaction sets 153, 154, . . . 155, which are that set of changes necessary to carry out the corresponding ( ]_, 2 • . . T^) date-dependent service orders. As before, a replication is created for each node affected by each transaction set. Thus node 150 is replicated as node 156 for transaction 153 and is replicated as node 157 for transaction set 155. Similarly, node 151 is replicated as nodes 158 and 159 for transaction sets 153 and 154, respectively, and node 152 is replicated as nodes 160 and 161 for transaction sets 154 and 155, respectively. The number of replications of each of root nodes 150 . . . 152 is exactly equal to the number of transactions 153 . . . 155 which affect that node. The number and identity of those nodes affected by any particular transaction set can be entirely arbitrary and, indeed, is fully determined by the physical changes which will be necessary to execute the work order associated with that transaction.
Up to this point, the representation of FIG. 12 corresponds exactly to the representation of FIG. 10. Each physical entity node is replicated for each service order having transactions affecting that node. Numerous versions of each node can exist simultaneously, differentiated by the transactions associated therewith. The complete set for any version o.f the data base comprises the set of replicated nodes for the corresponding transaction (the rows in FIG. 12) plus the most immediately above nodes for those nodes not replicated at the transaction set row level. Since the transactions correspond to time-stamped pending conditions, this set of nodes is the time stamped pending version of the data base. Accesses can be made to this set as a consistent set which accurately represents what the physical facilities will look like at the time identified by the appropriate transaction.
Rather than creating delta nodes, however, all of the information necessary to unambiguously identify any particular pending version of the data base is contained in two lists which can be called the transaction set list and the history tree list for each node. The transaction sets, of course, correspond to boxes 153 . . . 155 of FIG. 12. They each identify that set of nodes affected by each transaction. Thus, transaction 153 identifies (points to) nodes 156 and 158; transaction set 154 identifies nodes 159
OMP and 160; and transaction set 155 identifies nodes 157 and 158. It can be seen that the transaction set list is no more than a sequence of pointers to those replicated nodes affected by that particular set of transactions. The history tree lists, on the other hand, are merely directed pointer lists linking each of the root nodes 150 . . . 152 with all of the existing pending replications of that same node. Thus, a history tree links node 150 with nodes 156 and 157; a history tree links node 151 with nodes 158 and 159; and a history tree links node 152 with nodes 160 and 161. It can be seen that these history trees can also be nothing more than a list of pointers to the actual node versions, arranged in historical order. Introducing a new transaction (new pending service order) merely involves using the T^_^ transaction to identify the proper version of the affected nodes. If the node to be replicated is not on the transaction list for the next preceding (T^_^.) transaction, the history tree for that node can be -entered and traced to find the then appropriate node version, i.e., the next higher node version on the history tree list. This next higher version might well be the root version (if no transaction affecting that node has as yet been specified) , in which case the root version is used in carrying out the new transaction. A new transaction ( ^) is created and inserted in the list between the
Figure imgf000022_0001
portions of the list. Since linked list processing is well-known, these techniques can be readily applied to rapidly access the required nodes. It is to be understood that the present invention has been illustrated in connection with assignments of telephone outside plant facilities for purposes of example only. This same technique could also be applied to almost any other facility inventory and assignment system by defining the appropriate node structures and transaction sets. Computer center facilities assignments, uses of raw materials, elements or subassemblies in varied manufacturing processes, chemical process planning, economic planning, and a myriad of other applications are readily apparent.

Claims

1. A data base system comprising - a plurality of data records, means for selectively accessing each of said data records, means for representing a plurality of time- dependent versions of each of said data records, and means, utilizing said accessing means and responsive to said time-dependent record versions, for making transactions against a consistent, time-dependent version of said data base representing the state of physical entities at some future time.
2. The data base system according to claim 1 wherein said representing means further includes means for generating at least one delta record for representing the relationship between a prior unchanged version of one of said data records and a subsequent changed version of the same data record.
3. The data base system according to claim 1 further comprising means for maintaining a list of identifications of those data records affected by said transactions, means for maintaining a list of data record versions of the same transaction, and means, utilizing said lists to identify said consistent, time-dependent versions of said data base.
4. The data base system according to claim 1 wherein said data records represent physical facilities to be assigned over time to a plurality of users, and said transactions comprises the creation, modification or deletion of assignments of said physical facilities.
5. The data base system according to claim 4 wherein said physical facilities comprise equipment utilized to provide telephone service to telephone subscribers.
6. The data base system according to claim 1 wherein each said data record comprises a body portion identifying the nature and attributes of the physical entity represented by that data recor , and a plurality of edge portions identifying other data records and their specific relationship to the said data record.
7. The method of assigning physical facilities to a plurality of users for future use comprising the steps of (1) creating a current version of a data base including a record to represent each of said physical facilities and the current assignments of each of said physical facilities to said users,
(2) for each new request for future assignment of facilities to one of said users,
(a) generating a future version of those records in said data base affected by the future assignment of the represented facility to said one user,
(b) maintaining a record of each fully consistent set of said data records corresponding to each of a plurality of future times, (c) making future assignments of said facilities by utilizing the appropriate one of said fully consistent sets, and (3) repeating step (2) for all requests received prior to but due for execution subsequent to said new request.
8. The method of claim 7 wherein said step of maintaining fully consistent sets of data records further comprises the step of
(4) creating separate records in said data base identifying the data record version before each said future assignment and the data record version after each said future assignment.
9. The method of claim 7 wherein said step of maintaining fully consistent sets of data records further comprises the steps of
(4) creating separate lists of identifications of all versions of each data record, and
(5) creating a list of all data records affected by each said future assignment.
10. The method according to claim 7 wherein said steps of creating a current version or generating a future version further comprises the steps of
(4) creating a head portion of said data record including the identification and attributes of the physical facility therein represented, and
(5) creating a plurality of edge portions of said data record including the identification of related records and the attributes of the relationships with said related record.
PCT/US1983/001697 1982-11-15 1983-11-02 Time-ordered data base WO1984002023A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP50365283A JPS59502039A (en) 1982-11-15 1983-11-02 time order database

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US06/441,731 US4646229A (en) 1982-11-15 1982-11-15 Time-ordered data base

Publications (1)

Publication Number Publication Date
WO1984002023A1 true WO1984002023A1 (en) 1984-05-24

Family

ID=23754069

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1983/001697 WO1984002023A1 (en) 1982-11-15 1983-11-02 Time-ordered data base

Country Status (3)

Country Link
US (1) US4646229A (en)
EP (1) EP0125289A1 (en)
WO (1) WO1984002023A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0219727A1 (en) * 1985-09-30 1987-04-29 Siemens Aktiengesellschaft Method for testing the logic consistency in data base systems
EP0270360A2 (en) * 1986-12-02 1988-06-08 Tektronix Inc. Data management system
EP0702496A3 (en) * 1994-09-13 1998-04-08 AT&T Corp. A method and system for updating replicated databases in a telecommunication network system
CN116029734A (en) * 2023-03-23 2023-04-28 华侨大学 Bank transaction fraud detection method, system and electronic equipment

Families Citing this family (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5230073A (en) * 1986-07-21 1993-07-20 Bell Communications Research, Inc. System and method for accessing and updating a continuously broadcasted stored database
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5043876A (en) * 1988-05-27 1991-08-27 International Business Machines Corporation N-level file shadowing and recovery in a shared file system
US5146439A (en) * 1989-01-04 1992-09-08 Pitney Bowes Inc. Records management system having dictation/transcription capability
WO1991001530A2 (en) * 1989-07-11 1991-02-07 Bell Communications Research, Inc. Methods and apparatus for checking the integrity of data base data entries
US5301319A (en) * 1989-09-15 1994-04-05 Emtek Health Care Systems, Inc. Data storage audit trail
US5212789A (en) * 1989-10-12 1993-05-18 Bell Communications Research, Inc. Method and apparatus for updating application databases used in a distributed transaction processing environment
US5233533A (en) * 1989-12-19 1993-08-03 Symmetrix, Inc. Scheduling method and apparatus
US5412801A (en) * 1990-01-17 1995-05-02 E-Net Gap recovery for off-site data storage and recovery systems
US5317733A (en) * 1990-01-26 1994-05-31 Cisgem Technologies, Inc. Office automation system for data base management and forms generation
EP0463251A1 (en) * 1990-06-28 1992-01-02 International Business Machines Corporation Software installation
US5440730A (en) * 1990-08-09 1995-08-08 Bell Communications Research, Inc. Time index access structure for temporal databases having concurrent multiple versions
US5893117A (en) * 1990-08-17 1999-04-06 Texas Instruments Incorporated Time-stamped database transaction and version management system
WO1992004679A1 (en) * 1990-08-31 1992-03-19 Seer Technologies, Inc. Transaction processor
US5317729A (en) * 1990-10-24 1994-05-31 International Business Machines Corporation Method for the storage of multi-versioned data with retrieval based on searched query
US5263156A (en) * 1990-12-20 1993-11-16 Bell Communications Research, Inc. Parallel, distributed optimistic concurrency control certification using hardware filtering
US5274802A (en) * 1991-02-22 1993-12-28 Gte Mobilnet Incorporated Method for restoring lost databases by comparing existing database and generic database, and generating cellular switch commands to update the generic database
US5287496A (en) * 1991-02-25 1994-02-15 International Business Machines Corporation Dynamic, finite versioning for concurrent transaction and query processing
US5257368A (en) * 1991-03-28 1993-10-26 International Business Machines Corp. System for dynamically changing a system I/O configuration by determining differences between current and future configurations and describing differences to software and hardware control blocks
US5347653A (en) * 1991-06-28 1994-09-13 Digital Equipment Corporation System for reconstructing prior versions of indexes using records indicating changes between successive versions of the indexes
US5251316A (en) * 1991-06-28 1993-10-05 Digital Equipment Corporation Method and apparatus for integrating a dynamic lexicon into a full-text information retrieval system
US5333316A (en) * 1991-08-16 1994-07-26 International Business Machines Corporation Locking and row by row modification of a database stored in a single master table and multiple virtual tables of a plurality of concurrent users
US5426780A (en) * 1992-02-28 1995-06-20 Intergraph Corporation System for dynamic segmentation analysis using conversion of relational data into object-oriented data
US5495600A (en) * 1992-06-03 1996-02-27 Xerox Corporation Conversion of queries to monotonically increasing incremental form to continuously query a append only database
US5504879A (en) * 1992-07-16 1996-04-02 International Business Machines Corporation Resolution of relationship source and target in a versioned database management system
US5815656A (en) * 1992-09-23 1998-09-29 International Business Machines Corporation Method of validating memory structures in data processing systems
US5455775A (en) * 1993-01-25 1995-10-03 International Business Machines Corporation Computer design system for mapping a logical hierarchy into a physical hierarchy
US5896531A (en) * 1993-02-26 1999-04-20 International Business Machines Corporation Method and system for managing environments with a data processing system
US5787444A (en) * 1993-03-15 1998-07-28 International Business Machines Corp. Method and apparatus for maintaining revision contol of a set of objects within a data processing system
US5381405A (en) * 1993-03-18 1995-01-10 At&T Corp. Communications access network routing
US5386417A (en) * 1993-03-18 1995-01-31 At&T Corp. Method and apparatus for establishing connections in a communications access network
US5706508A (en) * 1993-04-05 1998-01-06 International Business Machines Corporation System and method for monitoring SNMP tables
US6662307B1 (en) * 1993-06-14 2003-12-09 Unisys Corporation Disk recovery/reconstruction
DE4497149T1 (en) * 1993-09-24 1996-10-17 Oracle Corp Method and device for replicating data
ATE180070T1 (en) * 1993-12-10 1999-05-15 Cheyenne Advanced Tech Ltd INCREMENTAL DATA BACKUP SYSTEM
WO1995016969A1 (en) * 1993-12-15 1995-06-22 Supercomm, Inc. Database versioning with output only of data changed from the previous version
US6769009B1 (en) 1994-05-31 2004-07-27 Richard R. Reisman Method and system for selecting a personalized set of information channels
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
US5574906A (en) * 1994-10-24 1996-11-12 International Business Machines Corporation System and method for reducing storage requirement in backup subsystems utilizing segmented compression and differencing
US5794242A (en) * 1995-02-07 1998-08-11 Digital Equipment Corporation Temporally and spatially organized database
US5689705A (en) * 1995-02-13 1997-11-18 Pulte Home Corporation System for facilitating home construction and sales
US5729742A (en) * 1995-02-27 1998-03-17 International Business Machines Corporation System and method for enabling multiple computer systems to share a single sequential log
US5511164A (en) * 1995-03-01 1996-04-23 Unisys Corporation Method and apparatus for determining the source and nature of an error within a computer system
US5784382A (en) * 1995-03-01 1998-07-21 Unisys Corporation Method and apparatus for dynamically testing a memory within a computer system
US5784393A (en) * 1995-03-01 1998-07-21 Unisys Corporation Method and apparatus for providing fault detection to a bus within a computer system
US5828823A (en) * 1995-03-01 1998-10-27 Unisys Corporation Method and apparatus for storing computer data after a power failure
US5784712A (en) * 1995-03-01 1998-07-21 Unisys Corporation Method and apparatus for locally generating addressing information for a memory access
US5680537A (en) * 1995-03-01 1997-10-21 Unisys Corporation Method and apparatus for isolating an error within a computer system that transfers data via an interface device
US6151643A (en) * 1996-06-07 2000-11-21 Networks Associates, Inc. Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer
US5970503A (en) * 1996-06-12 1999-10-19 Base Ten Systems, Inc. Method for online revision control
US5696864A (en) * 1996-09-18 1997-12-09 Communications Technology Corporation Aerial enclosure for coupling data signals to a customer site
US5943678A (en) * 1996-12-03 1999-08-24 International Business Machines Corporation Temporal displacement icon in a graphical user interface
US5949970A (en) * 1997-01-07 1999-09-07 Unisys Corporation Dual XPCS for disaster recovery
US5940826A (en) * 1997-01-07 1999-08-17 Unisys Corporation Dual XPCS for disaster recovery in multi-host computer complexes
JPH10260876A (en) * 1997-03-19 1998-09-29 Hitachi Ltd Data structure of database, and data processing method for database
US6084590A (en) * 1997-04-07 2000-07-04 Synapix, Inc. Media production with correlation of image stream and abstract objects in a three-dimensional virtual stage
US6160907A (en) * 1997-04-07 2000-12-12 Synapix, Inc. Iterative three-dimensional process for creating finished media content
US6124864A (en) * 1997-04-07 2000-09-26 Synapix, Inc. Adaptive modeling and segmentation of visual image streams
US5873098A (en) * 1997-04-23 1999-02-16 Oracle Corporation Dynamic snapshot set adjustment
US5983242A (en) * 1997-07-01 1999-11-09 Microsoft Corporation Method and system for preserving document integrity
US6266053B1 (en) 1998-04-03 2001-07-24 Synapix, Inc. Time inheritance scene graph for representation of media content
US6249285B1 (en) 1998-04-06 2001-06-19 Synapix, Inc. Computer assisted mark-up and parameterization for scene analysis
US6297825B1 (en) 1998-04-06 2001-10-02 Synapix, Inc. Temporal smoothing of scene analysis data for image sequence generation
US6415298B1 (en) * 1999-07-15 2002-07-02 American Management Systems, Inc. Effective dated tree control in a component based-object oriented convergent customer care and billing system
US20060271577A1 (en) * 2002-02-22 2006-11-30 Bo-In Lin Automatic link generation for linking to relevant data records circumstantial to document processes
WO2004027650A1 (en) 2002-09-18 2004-04-01 Netezza Corporation Disk mirror architecture for database appliance
US7337351B2 (en) * 2002-09-18 2008-02-26 Netezza Corporation Disk mirror architecture for database appliance with locally balanced regeneration
US8688634B2 (en) * 2004-02-27 2014-04-01 International Business Machines Corporation Asynchronous peer-to-peer data replication
US7490083B2 (en) 2004-02-27 2009-02-10 International Business Machines Corporation Parallel apply processing in data replication with preservation of transaction integrity and source ordering of dependent updates
US7444197B2 (en) 2004-05-06 2008-10-28 Smp Logic Systems Llc Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes
US7799273B2 (en) 2004-05-06 2010-09-21 Smp Logic Systems Llc Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes
US7953749B2 (en) * 2004-05-11 2011-05-31 Oracel International Corporation Providing the timing of the last committed change to a row in a database table
US20070244921A1 (en) * 2006-04-14 2007-10-18 Roger Blair Method, apparatus and computer-readable medium to provide customized classification of documents in a file management system
US9063932B2 (en) * 2009-12-18 2015-06-23 Vertafore, Inc. Apparatus, method and article to manage electronic or digital documents in a networked environment
US8700682B2 (en) * 2009-12-24 2014-04-15 Vertafore, Inc. Systems, methods and articles for template based generation of markup documents to access back office systems
US9384198B2 (en) 2010-12-10 2016-07-05 Vertafore, Inc. Agency management system and content management system integration
US8341134B2 (en) 2010-12-10 2012-12-25 International Business Machines Corporation Asynchronous deletion of a range of messages processed by a parallel database replication apply process
US8731973B2 (en) 2011-04-19 2014-05-20 Vertafore, Inc. Overlaying images in automated insurance policy form generation
US20130274369A1 (en) 2012-04-13 2013-10-17 Basf Se New cationic polymers
US9507814B2 (en) 2013-12-10 2016-11-29 Vertafore, Inc. Bit level comparator systems and methods
US9367435B2 (en) 2013-12-12 2016-06-14 Vertafore, Inc. Integration testing method and system for web services
US9727625B2 (en) 2014-01-16 2017-08-08 International Business Machines Corporation Parallel transaction messages for database replication
US9747556B2 (en) 2014-08-20 2017-08-29 Vertafore, Inc. Automated customized web portal template generation systems and methods
US10229128B2 (en) * 2014-11-19 2019-03-12 Rubrik, Inc. Method and apparatus for the generation, organization, storage and retrieval of time stamped blocks of data
US9600400B1 (en) 2015-10-29 2017-03-21 Vertafore, Inc. Performance testing of web application components using image differentiation
JP6690207B2 (en) * 2015-11-30 2020-04-28 ブラザー工業株式会社 Relay device and control program
JP2018067174A (en) * 2016-10-20 2018-04-26 富士通株式会社 Information processing device, relation analysis method, and program

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2542890A (en) * 1947-11-06 1951-02-20 Deba P Basu Space reservation system
US4320451A (en) * 1974-04-19 1982-03-16 Honeywell Information Systems Inc. Extended semaphore architecture
US4007450A (en) * 1975-06-30 1977-02-08 International Business Machines Corporation Data sharing computer network
US4468732A (en) * 1975-12-31 1984-08-28 International Business Machines Corporation Automated logical file design system with reduced data base redundancy
US4121196A (en) * 1977-05-02 1978-10-17 The United States Of America As Represented By The Secretary Of The Army Data base update scheme
GB2023314B (en) * 1978-06-15 1982-10-06 Ibm Digital data processing systems
US4344134A (en) * 1980-06-30 1982-08-10 Burroughs Corporation Partitionable parallel processor
US4435753A (en) * 1980-10-31 1984-03-06 International Business Machines Corporation Register allocation system using recursive queuing during source code compilation
US4412285A (en) * 1981-04-01 1983-10-25 Teradata Corporation Multiprocessor intercommunication system and method
US4432057A (en) * 1981-11-27 1984-02-14 International Business Machines Corporation Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system
US4479196A (en) * 1982-11-15 1984-10-23 At&T Bell Laboratories Hyperedge entity-relationship data base systems

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ACM Transactions on Database Systems, Vol. 4, No. 1, March 1979 (Baltimore, US) R.H. THOMAS: "A Majority Consensus Approach to Concurrent Control for Multiple Copy Databases", pages 180-209 *
NTC '77 Conference Record, Vol. 2, 5-7 December 1977 (Los Angeles, US) N.A. WILLIAMS et al.: "Automated Application Engineering of a Large Tall Telephone Switching System", pages 24:5-1 - 24:5-5, see page 24:5-2, paragraph 5 - page 24:5-3, paragraph 3 *
The Bell System Technical Journal, Vol. 61, No. 9, November 1982 (New York, US) A.J. GOLDSTEIN: "A Directed Hypergraph Database: A Model for the Local Loop Telephone Plant", pages 2529-2555, see page 2537, paragraph IV and pages 2544-2549, paragraphs 9.2.2 and X *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0219727A1 (en) * 1985-09-30 1987-04-29 Siemens Aktiengesellschaft Method for testing the logic consistency in data base systems
EP0270360A2 (en) * 1986-12-02 1988-06-08 Tektronix Inc. Data management system
EP0270360A3 (en) * 1986-12-02 1990-09-19 Tektronix Inc. Data management system
EP0702496A3 (en) * 1994-09-13 1998-04-08 AT&T Corp. A method and system for updating replicated databases in a telecommunication network system
US5937343A (en) * 1994-09-13 1999-08-10 At&T Corp. Method and system for updating replicated databases in a telecommunication network system
CN116029734A (en) * 2023-03-23 2023-04-28 华侨大学 Bank transaction fraud detection method, system and electronic equipment

Also Published As

Publication number Publication date
EP0125289A1 (en) 1984-11-21
US4646229A (en) 1987-02-24

Similar Documents

Publication Publication Date Title
US4646229A (en) Time-ordered data base
US4698752A (en) Data base locking
US4479196A (en) Hyperedge entity-relationship data base systems
US5970501A (en) Automatic external data synchronization method
US5357631A (en) Method and system for creating and maintaining multiple document versions in a data processing system library
US5495610A (en) Software distribution system to build and distribute a software release
CA2275399C (en) Computer executable workflow control system
CA2207867C (en) Method and apparatus for providing an efficient use of telecommunication network resources
US5893906A (en) Managing work in a computing application
WO1991008542A1 (en) Software distribution system
CN100454824C (en) Telecommunications network resource handling arrangmenet and method
US4792921A (en) Network event identifiers
US6898790B1 (en) Mapping actions to tasks within customer service processing systems
WO2007109471A2 (en) Method for modeling and documenting a network
Cheng et al. A constraint-based nurse rostering system using a redundant modeling approach
EP0457707A2 (en) Method for hierarchical grouping of documents in a data processing system
EP0126122B1 (en) Data base locking
US7257587B2 (en) Method and system for intra-table referential integrity for relational database systems
CN110515611B (en) Document number generation method
CN100498685C (en) Mobile data and software update system and method
US6973652B1 (en) Sequencing of tasks within customer service processing systems
JPS59502039A (en) time order database
JPH09282153A (en) Picture/slip, data base and protocol preparation system
Ahamed et al. Interoperability of multiple databases for the design and simulation of high-speed digital subscriber lines
Hall et al. Total Network Data System: System Plan

Legal Events

Date Code Title Description
AK Designated states

Designated state(s): JP

AL Designated countries for regional patents

Designated state(s): AT BE CH DE FR GB LU NL SE

WWE Wipo information: entry into national phase

Ref document number: 1983903747

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1983903747

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 1983903747

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1983903747

Country of ref document: EP