Method and system for object-based relational distributed databases

Abstract

An object-based relational distributed database system and associated methods of operation that transforms data stored in a plurality of remote, heterogeneous user databases into a homogeneous data model is disclosed. Data stored in distributed, heterogeneous user database structures is homogenized by mapping into object attributes of predetermined instances of objects forming to a conceptual model that relates the various heterogeneous databases. The object attributes are stored in remote databases at client sites, which can be separate computer systems from the heterogeneous user databases or separate processes running on a computer system that maintains the heterogeneous user databases. The system stores location information and status information relating to the homogenized data in a centralized object broker for object management, thereby facilitating location and retrieval of data items from one or more of the remote, heterogeneous user databases.

Claims

What is claimed is:

1. A method of operating a distributed data processing system including a plurality of remotely located user computers that process user data in user databases and at least one object broker computer,

the user computers being interconnected with the object broker computer via a data communication network,

the user computers being operative to perform data processing operations upon user data in response to user commands, comprising the steps of:

(a) creating an object instance by assigning a unique object identifier to data items associated with a particular subject;

(b) storing the data items associated with the subject at the user computer in association with the object identifier;

(c) at the object broker computer, storing the locations of the user computers in a mapping table in association with object identifiers;

(d) associating a selected object identifier with data items stored in each of a plurality of user computers, some of the data items associated with the selected object identifier at a first one of the plurality of user computers being different from corresponding data items associated with the selected object identifier at a second one of the plurality of user computers;

(e) in response to a query to the object broker computer for data relating to the particular subject, retrieving the selected object identifier;

(f) in response to retrieval of an object identifier for the subject in the preceding step, retrieving the location of a selected one of the plurality of user computers associated with the selected object identifier; and

(g) retrieving data stored at the selected one of the plurality of user computers associated with the selected object identifier via the data communication network.

2. The method of claim 1, wherein each of the remotely located user computers comprises a heterogeneous data structure, and further comprising the steps of:

at the user computers, mapping predetermined data items stored in the user computers to corresponding object attributes associated with a predetermined instance of an object;

storing the object attributes in an object attribute table in the remote user computers in association with object identifiers.

3. The method of claim 1, wherein the query to the object broker originates at a first user computer, and the data associated with the selected object identifier is stored at a second user computer, and further comprising the step of communicating data retrieved, associated with the selected object identifier, to the object broker and then to the first user computer via the data communication network.

4. The method of claim 1, wherein the data items associated with the subject stored at the user computer in association with the object identifier are stored in an object attribute table.

5. The method of claim 4, wherein the remotely located user computers include at least one customer database and at least one remote database associated therewith, and wherein the object attribute table is stored in the remote database.

6. The method of claim 1, wherein the step of assigning a unique object identifier to data items associated with a subject comprises the steps of:

providing a global object identification address space corresponding to a range of object identifiers for association with a plurality of subjects;

allocating a predetermined range of object identifiers within the global object identification address space to each remotely located user computer.

7. The method of claim 6, wherein the step of allocating a predetermined range of object identifiers is carried out at the object broker computer, and wherein a new object instance is created by assigning a unique object identifier from a predetermined range of object identifiers is carried out at the user computers.

8. The method of claim 1, further comprising the step of maintaining an object index table at the object broker computer for relating at least one predetermined search term to at least one object identifier.

9. The method of claim 8, wherein the object index table for relating at least one predetermined search term to at least one object identifier is a relational base table, and further comprising the step of maintaining a junction index table relating object identifiers corresponding to a first class of objects to object identifiers corresponding to a second class of objects.

10. The method of claim 1, wherein the mapping table stores information relating object identifiers, status information, and location information.

11. The method of claim 10, wherein the step of retrieving the location of a selected one of the plurality of user computers associated with the selected object identifier comprises determining from the status information which one of the plurality of user computers contains the most current data items associated with the selected object identifier; and

wherein the step of retrieving data stored at the selected one of the user computers associated with the selected object identifier via the data communication network comprises retrieving data stored at the user computer containing the most current data items associated with the selected object identifier.

12. The method of claim 10, wherein the user computers are located at a user computer site including at least one customer database and at least one remote database associated therewith, and wherein the location information relates to a data communications location for a remote database that stores data items in association with object identifiers.

13. The method of claim 12, wherein data items comprise at least one object attribute stored in at least one object attribute table maintained in the at least one remote database, and wherein the location information comprises information identifying at least one object attribute table in at least one remote database.

14. The method of claim 13, wherein the status information comprises date information identifying which one of a possible pluralities of occurrences of a selected object identifier is the most current.

15. The method of claim 1, wherein the user computers are located at a user computer site including at least one customer database and at least one remote database associated therewith, the at least one remote database storing an object attribute table for relating data items comprising object attributes to object identifiers, and wherein the object broker computer stores an object index table for relating at least one predetermined search term to at least one object identifier.

16. The method of claim 15, further comprising the steps of:

in response to an add request at one of the user computers to add a subject to the system, providing selected data items associated with the subject to be added from the customer database to the remote database;

at the remote database, carrying out the step of creating new object instance by assigning a new object identifier to data items associated with the subject;

communicating information relating the new object identifier to at least one corresponding search term to the object broker computer;

at the object broker computer, updating the object index table to reflect the association of the new object identifier with the corresponding search term;

at the object broker computer, updating the mapping table to reflect the location of the user computer that added the new object instance identified by the new object identifier.

17. The method of claim 15, further comprising the steps of:

in response to a search request at a querying one of the user computers to determine whether an object exists corresponding to a selected search term, communicating the selected search term to the object broker computer;

at the object broker computer, consulting the object index table to determine whether there is an object identifier associated with the selected search term;

in response to a determination that there is an object identifier associated with the selected search term, retrieving the corresponding object identifier;

providing a message to the querying user computer via the data communication network including the corresponding object identifier.

18. The method of claim 15, further comprising the steps of:

in response to a get request at a requesting one of the user computers based on a particular object identifier, communicating the particular object identifier to the object broker computer;

at the object broker computer, consulting the mapping table based on the particular object identifier to identify a particular remote database at a particular user computer site;

communicating a get message to the particular remote database at the particular user computer site including the particular object identifier;

at the particular remote database, consulting an object attribute table index to obtain retrieval information corresponding to the particular object identifier in the particular object attribute table;

retrieving object attributes associated with the particular object identifier from the particular object attribute table; and

communicating retrieved object attributes to the object broker computer and thence to the requesting user computer.

19. The method of claim 15, further comprising the steps of:

in response to a get all request at a requesting one of the user computers based on a particular object identifier that is related to one or more related object identifiers, communicating the particular object identifier to the object broker computer;

at the object broker computer, consulting an object index table that relates object identifiers of a first type to object identifiers of a second type to retrieve one or more related object identifiers associated with the particular object identifier;

at the object broker computer, consulting the mapping table based on retrieved related object identifiers to identify a one or more object attribute tables at one or more particular remote databases at one or more user computer sites containing data on the related object identifiers;

communicating a get message to the one or more remote databases including the related object identifiers;

at the one or more particular remote databases, consulting one or more object attribute table indexes to obtain retrieval information corresponding to the related object identifiers in the one or more object attribute tables;

retrieving object attributes associated with the related object identifiers from the one or more object attribute tables; and

communicating retrieved object attributes to the object broker computer and thence to the requesting user computer.

20. The method of claim 15, further comprising the steps of:

in response to an update request at an updating one of the user computers based on a particular object identifier for which one or more object attributes are to be updated, communicating the particular object identifier to the object broker computer together with the one or more object attributes to be updated;

at the object broker computer, consulting the mapping table based the particular object identifier to identify an object attribute table at a particular remote database at a user computer site containing the most current data corresponding to the particular object identifier;

communicating a get message to the particular remote database including the particular object identifier;

at the particular remote database, consulting an object attribute table index to obtain retrieval information corresponding to the particular object identifier in the object attribute table;

retrieving object attributes associated with the particular object identifier from the object attribute table;

communicating retrieved object attributes to the object broker computer;

at the object broker computer, updating the retrieved object attributes with the one or more object attributes to be updated, to obtain updated object attributes associated with the particular object attribute;

communicating the updated object attributes to the updating user computer for storage in the associated remote database.

21. The method of claim 20, further comprising the step of updating the mapping table and object index tables at the object broker computer to reflect that the updating user computer now has the most current information associated with the particular object identifier.

22. The method of claim 20, wherein the updating user computer is the same as the particular remote database containing the most current data corresponding to the particular object identifier.

23. The method of claim 20, wherein the remote database at the updating user computer did previously contain object attributes associated with the particular object identifier in an object attribute table, and further comprising the step of updating selected updated object attributes in the object attribute table associated with the particular object identifier.

24. The method of claim 20, wherein the updating user computer is at a different user site as the particular remote database containing the most current data corresponding to the particular object identifier.

25. The method of claim 24, wherein the remote database at the updating user computer did not previously contain any object attributes associated with the particular object identifier, and further comprising the step of adding the updated object attributes to an object attribute table associated with the updating user computer in association with the particular object identifier.

26. The method of claim 1, wherein each of the user computers are located at a user computer site including at least one customer database and at least one remote database associated therewith.

27. The method of claim 26, wherein at least one customer database is a heterogeneous database structure relative to at least one other computer system in the distributed system, and wherein the at least one remote database is homogeneous relative to the object broker computer.

28. The method of claim 26, wherein the at least one customer database runs on a different computer system than a computer system that runs the at least one remote database.

29. The method of claim 26, wherein the at least one customer database runs on the same computer system as the at least one remote database.

30. The method of claim 26, wherein at least one user computer in the distributed data processing system includes a customer database of a first database structure, and at least one other user computer in the distributed data processing system includes a customer database of a second database structure different from the first database structure so that such database structures are heterogeneous.

31. The method of claim 26, wherein the remote database associated with each user computer site is operative for performing the steps of creating a new object instance, storing data items in association with the object identifier, and retrieving data stored at the remote user computer associated with an object identifier provided by the object broker computer.

32. The method of claim 31, wherein the remote database is further operative for communicating location information and related object identifiers to the object broker computer via the data communications network.

33. The method of claim 26, wherein the step of storing the data items associated with the subject at the user computer in association with the object identifier comprises the steps of:

importing data items from a customer database into an associated remote database as selected data attributes associated with a particular object identifier, and

communicating the particular object identifier to the object broker computer.

34. The method of claim 33, wherein the step of communicating the particular object identifier to the object broker computer includes communicating predetermined search terms associated with the selected data attributes to the object broker computer.

35. The method of claim 34, further comprising the step of storing the predetermined search terms in an object attribute index stored at the object broker computer, the object attribute index relating object identifiers and search terms, and storing location information and status information indicative of the source and status of the object attributes and the object identifier in the mapping table.

36. The method of claim 33, wherein the step of importing data items from the customer database comprises the steps of:

importing a first set of data items from the customer database as object attributes associated with a first object identifier;

determining that the first object identifier is related to at least one additional second object identifier; and

importing a second set of data items from the customer database as object attributes associated with the second object identifier.

37. The method of claim 36, wherein the steps of importing comprise importing object attributes associated with the second object identifier that are in a dependent relationship to object attributes associated with the first object identifier in a predetermined order so as to preserve dependency relationships.

38. The method of claim 36, further comprising the steps of:

storing object attributes associated with the first object identifier in a first object attribute table;

storing the first object identifier and the second object identifier in a junction table relating object identifiers to each other;

storing object attributes associated with the second object identifier in a second object attribute table;

in response to a determination that the storing of object attributes for the second object identifier calls for information corresponding to the first object identifier, storing the first object identifier in a corresponding field in the second object attribute table,

whereby reference to the second object identifier causes referral to the first object identifier for selected object attributes.

39. The method of claim 26, wherein each remote database at each user computer site comprises a homogeneous data structure, and further comprising the step of importing selected data items from an associated customer database into the remote database.

40. The method of claim 39, wherein the step of importing selected data items from an associated customer database into the remote database comprises the step of mapping data items in a heterogeneous data structure on a customer database into predetermined object attributes stored in the associated remote database.

41. The method of claim 40, wherein the step of importing occurs in response to a put request message provided by a user at a user computer site.

42. The method of claim 40, wherein the step of importing comprises entering data items from the heterogeneous data structure into an object attribute table maintained at the associated remote database.

43. The method of claim 42, further comprising the step of maintaining an object attribute table index at the remote database to allow rapid searching for particular object attributes stored in an object attribute table in the respective remote database.

44. The method of claim 43, wherein the object attribute table index comprises a table relating an object identifier to one or more data items associated with the object identifier.

45. A method of operating a distributed data processing system including a plurality of independent remotely located user computers that process user data in user databases and at least one central computer,

the user computers being interconnected with the central computer via a data communication network,

the user computers being operative to perform data processing operations upon user data items in response to user commands, comprising the steps of:

(a) determining a set of objects, each object comprising a predetermined collection of attributes relating to a subject, each of the attributes comprising a data item;

(b) for a subject at one of the user computers for which data is to be processed in the system, creating an object instance by assigning a unique object identifier to data items associated with the subject;

(c) for the object, storing the attributes associated with the subject at the user computer in association with the object identifier in an object attribute table, the object attribute table being identified by an object attribute table identifier;

(d) transmitting a data message from the user computer that created the object to the central computer comprising the object identifier and the object attribute table identifier associated with the object;

(e) at the central computer, storing the locations of the user computers in a mapping table in association with object identifiers and the object attribute table identifiers;

(f) at the central computer, providing an index table relating the object identifiers to at least one predetermined search term, each search term comprising at least one data item associated with objects;

(g) in response to a query to the central computer for data relating to a particular subject in question, consulting the index table to retrieve an object identifier for the subject in question;

(h) in response to retrieval of an object identifier for the subject in question in the preceding step, retrieving the location of a remote user computer associated with the retrieved object identifier from the mapping table; and

(i) retrieving data stored at the remote user computer associated with the object identifier.

46. The method of claim 45, wherein the step of retrieving the location of a remote user computer associated with the retrieved object identifier from the mapping table comprises retrieving an object attribute table identifier that identifies a particular object attribute table in a particular user computer containing data items associated with the retrieved object identifier.

47. The method of claim 46, wherein the step of retrieving data stored at the remote user computer associated with the object identifier comprises retrieving data items associated with the retrieved object identifier stored in the particular object attribute table in the particular user computer.

48. A method of operating a distributed data processing system including a plurality of remotely located user computers that process user data and at least one central computer,

the user computers being interconnected with the central computer via a data communication network,

the user computers being operative to perform data processing operations in response to user commands, comprising the steps of:

(a) maintaining a mapping table in the central computer, the mapping table comprising a plurality of map table entries, each map table entry comprising object identifiers, location information, and status information associated with at least one data item stored in at least one of the user computers;

(b) in response to a query for information relating to a queried data item from a user at a querying one of the user computers, transmitting a query message from the querying user computer to the central computer via the data communication network, the query message including an object identifier associated with the queried data item;

(c) receiving the query message at the central computer;

(d) at the central computer, retrieving any stored map table entries from the mapping table corresponding to the object identifier associated with the queried data item;

(e) evaluating in accordance with predetermined status criteria the status information for the retrieved map table entries and determining the location of a selected one of a plurality of user computers having selected information stored therein concerning the queried data item;

(f) using the determined location, transmitting a get message including the object identifier associated with the queried data item from the central computer to the selected user computer via the data communication network;

(g) in response to the get message at the selected user computer, retrieving the selected information associated with the object identifier associated with the queried data item;

(h) transmitting the retrieved selected information to the central computer from the selected user computer via the data communications network; and

(i) upon receipt of the retrieved selected information at the central computer from the selected user computer, transmitting the retrieved selected information to the querying user computer via the data communications network.

49. The method of claim 48, wherein the predetermined status criteria is that of the most current information associated with the object identifier.

50. A method of operating a distributed data processing system including a plurality of remotely located user computers and at least one central computer,

the user computers being interconnected with the central computer via a data communication network,

comprising the steps of:

(a) at a first user computer, associating a particular object identifier with selected data items;

(b) transmitting the particular object identifier from the first user computer to the central computer via the data communication network;

(c) at a second user computer, associating the particular object identifier with different selected data items;

(d) transmitting the particular object identifier from the second user computer to the central computer via the data communication network; and

(e) at the central computer, storing the particular object identifiers from the first user computer and from the second user computer as plural map table entries in a mapping table, each of the map table entries including location information corresponding to the location of the first user computer and of the second user computer, and status information relating to the selected data items.

51. The method of claim 50, wherein a query from one of the user computers to the central computer results in retrieval of the plural map table entries, and retrieval of selected data items corresponding to the particular object identifier results in retrieval of a plurality of selected data items that differ by virtue of the status information.

52. The method of claim 50, further comprising the step of providing an application program interface (API) between the user databases and the central computer, for associating the object identifiers with the selected data items at the user databases, and transmitting the object identifiers and status information to the central computer for storage in the map table.

53. The method of claim 52, wherein the user computers are heterogeneous databases.

54. The method of claim 52, wherein the API is a computer program that runs on the user computer and is operative to interface with the user database.

55. The method of claim 54, wherein the API is a separate, second computer system that is located proximate to and communicates with the user computer, and includes the data communication hardware to the central computer.

56. A method of operating a distributed data processing system including a plurality of remotely located user computers that process user data in user databases,

the user computers being interconnected via a data communication network,

comprising the steps of:

(a) maintaining an object location service for associating object identifiers with search terms, object attribute table identifiers corresponding to object attribute tables located at user computers, and locations of user computers storing object attribute tables corresponding to object attribute table identifiers;

(b) at a selected user computer, associating a particular object identifier with a selected set of user data items;

(c) storing the selected set of user data items in a selected object attribute table at the selected user computer, the selected object attribute table being identified by a selected object attribute table identifier;

(d) transmitting the particular object identifier, a selected search term associated with the object identifier, and the object attribute table identifier to the location service via the data communication network; and

(e) at the location service, storing the particular object identifier, the selected search term, the selected object attribute table identifier, and location information.

57. The method of claim 56, wherein the location service comprises a map table for storing location information, status information, in association with object identifiers, and an object index for storing search terms in association with object identifiers.

58. The method of claim 56, wherein the location service is maintained at a central computer remotely located from the user computers.

59. The method of claim 56, wherein the user computers comprise a customer database and a remote database, and wherein the customer database comprises a heterogeneous data structure from other computers in the distributed system, and wherein the remote data base carries out operations for transforming data items in the heterogeneous data structure into a homogeneous data structure.

60. The method of claim 59, further comprising the step of importing data items from the heterogeneous data structure into the remote database.

61. The method of claim 59, wherein the customer database operates on the same computer system as the remote database.

62. The method of claim 59, wherein the customer database operates on a computer system different than a computer system on which the remote database operates, and further including the step of communicating data items between the customer database and the remote database.

63. A method of operating a distributed data processing system including a plurality of remotely located user computers that process user data in user databases and at least one central computer,

the user computers being interconnected with the central computer via a data communication network,

comprising the steps of:

(a) maintaining at the central computer an object index associating object identifiers with search terms;

(b) maintaining at the central computer a map table associating object identifiers with object attribute table identifiers corresponding to object attribute tables located at user computers, and locations of user computers storing object attribute tables corresponding to object attribute table identifiers;

(c) at a computer associated with a selected user computer, associating a particular object identifier with a selected set of user data items in the selected user computer;

(d) storing the selected set of user data items in a selected object attribute table at the selected user computer, the selected object attribute table being identified by a selected object attribute table identifier;

(e) transmitting the particular object identifier, a selected search term associated with the object identifier, and the object attribute table identifier to the central computer via the data communication network; and

(f) at the central computer, storing the particular object identifier and the selected search term in the object index, and the selected object attribute table identifier and location information in the map table.

64. The method of claim 63, further comprising the step of maintaining at the central computer a map table relating entry in a mapping table, the map table entry including location information corresponding to the location of the indexed selected user computer and status information relating to the indexed selected user data item.

65. The method of claim 63, wherein the user computers comprise a customer database and a remote database, and wherein the customer database comprises a heterogeneous data structure from other computers in the distributed system, and wherein the remote data base carries out operations for transforming data items in the heterogeneous data structure into a homogeneous data structure.

66. The method of claim 65, further comprising the step of importing data items from the heterogeneous data structure into the remote database.

67. The method of claim 65, wherein the customer database operates on the same computer system as the remote database.

68. The method of claim 65, wherein the customer database operates on a computer system different than a computer system on which the remote database operates, and further including the step of communicating data items between the customer database and the remote database.

69. A method of operating a distributed data processing system including a plurality of remotely located user computers that process user data in user databases,

the user computers being interconnected via a data communication network,

comprising the steps of:

(a) associating the same predetermined object identifier with a selected subset of data items stored in each of a plurality of user computers, the selected subset of data items in each of the plurality of user computers corresponding to the same logical object,

a selected subset of data items associated with a selected object identifier stored at a first user computer being more current than a corresponding subset of data items associated with the same object identifier at a second user computer as indicated by status information;

(b) providing a location service storing information relating object identifiers, location information, and status information associated with subsets of data items stored in the plurality of user computers;

(c) in response to a request for information relating to a particular logical object from a user at a requesting one of the user computers, searching an object index based on a selected search term to obtain at least one selected object identifier;

(d) consulting the location service based on the selected object identifier to obtain status information;

(e) examining the status information and the location information to determine a selected location of a selected user computer storing the most current data items associated with the selected object identifier;

(f) retrieving selected data items from the selected user computer; and

(g) transmitting the retrieved selected data items from the selected user computer to the requesting one of the user computers.

70. The method of claim 69, wherein the location service comprises a map table maintained a central computer connected for data communications with each of the plurality of remote user computers.

71. The method of claim 70, wherein the step of examining the status information and the location information occurs at the central computer, and further comprising the steps of:

communicating a get message from the central computer to the selected user computer via the data communication network;

at the selected user computer, retrieving the selected data items associated with the selected object identifier;

transmitting the retrieved selected data items to the central computer from the selected user computer via the data communications network;

upon receipt of the retrieved selected data items by the central computer from the selected user computer, transmitting the retrieved selected data items to the requesting user computer via the data communications network.

72. The method of claim 69, wherein the user computers comprise a customer database and a remote database, and wherein the customer database comprises a heterogeneous data structure from other computers in the distributed system, and wherein the remote data base carries out operations for transforming data items in the heterogeneous data structure into a homogeneous data structure.

73. The method of claim 72, further comprising the step of importing data items from the heterogeneous data structure into the remote database.

74. The method of claim 72, wherein the customer database operates on the same computer system as the remote database.

75. The method of claim 72, wherein the customer database operates on a computer system different than a computer system on which the remote database operates, and further including the step of communicating data items between the customer database and the remote database.

76. A method of operating a distributed data processing system including a plurality of remotely located user computers that store user data in heterogeneous user databases,

the user computers being interconnected via a data communication network,

comprising the steps of:

(a) determining a selected subset of heterogeneous user data items at one of the user computers corresponding to a predetermined logical object;

(b) homogenizing the selected subset of heterogeneous user data items to obtain homogenized data items by associating at least portions of the user data items with a predetermined object identifier related to the predetermined logical object;

(c) maintaining an index relating search terms to object identifiers associated with logical objects with; and

(d) maintaining a map table relating object identifiers with location information indicative of the location of each user computer that stores homogenized data items in association with object identifiers.

77. The method of claim 76, wherein the steps of maintaining the search index and the map table are carried out at a central computer that is connected to each of the user computers via the data communications network.

78. The method of claim 76, wherein the step of homogenizing the selected subset of heterogeneous user data items to obtain homogenized data items is carried out at the user computer site.

79. The method of claim 78, wherein the step of homogenizing is carried out in a computer system independent of the user computer but located at the user computer site.

80. A method of operating a distributed computing system including a plurality of remotely located user computers that store user data items, comprising the steps of:

providing a location service storing information relating to object identifiers, location information relating to locations of remotely located user computers where attributes of objects associated with object identifiers are stored, and status information relating to the currency of object attributes, where object attributes comprise user data items;

providing at least one object index relating predetermined search terms to object identifiers;

at a requesting computer, providing a selected search term for locating an object;

searching the object index based on the selected search term to determine whether an object identifier is associated with the selected search term;

in response to a determination in the preceding step that an object identifier is associated with the selected search term, retrieving a selected object identifier associated with the selected search term from the location service;

retrieving status information from the location service based on the selected object identifier;

utilizing the status information, determining selected location information from the location service indicative of the most current information for selected object attributes associated with the selected object identifier;

initiating a communication to a user computer associated with the selected location information to retrieve the selected object attributes associated with the selected object identifier; and

transmitting the selected object attributes to the requesting computer.

81. The method of claim 80, wherein the requesting computer comprises one of the remotely located user computers.

82. The method of claim 80, wherein the requesting computer comprises a stand alone personal computer system connected for data communications with the location service.

83. The method of claim 80, wherein the location service comprises a map table for storing location information, status information, in association with object identifiers, and an object index for storing search terms in association with object identifiers.

84. The method of claim 83, wherein the map table is maintained in a central object broker computer.

85. The method of claim 84, wherein the object broker computer is operative to maintain the object index.

86. A method of operating a distributed data processing system including a plurality of remotely located user computers,

the user computers being interconnected for data communications via a data communication network, comprising the steps of:

(a) providing a location service storing information relating object identifiers and location information associated with data items stored in a plurality of user computers;

(b) providing a first object identifier in association with data items relating to a first logical object;

(c) providing at least one second object identifier in association with data items relating to at least one second logical object;

(d) providing an object index table for associating the first logical object with at least one second logical object by storing the first object identifier in association with at least one second object identifier;

(e) in response to a request for information relating to the first logical object originating at one of the user computer, searching the object index table based on the first object identifier to obtain at least one selected second object identifier associated with at least one second logical object;

(f) consulting the location service based on the at least one selected second object identifier to obtain the location of a selected user computer storing data items associated with the at least one selected second object identifier; and

(g) retrieving data items associated with the at least one second object identifier from the selected user computer.

87. The method of claim 86, wherein the distributed data processing system includes at least one central computer operative for providing the location service, the object index table, and issuing requests to user computers to retrieve data items corresponding to object identifiers.

88. The method of claim 86, wherein the object index table comprises a junction table comprising a plurality of entries associating the first object identifier with a plurality of second object identifiers.

89. The method of claim 86, wherein the object index table is searchable by any object identifier.

90. A method of operating a distributed data processing system including a plurality of remotely located user computers,

the user computers being interconnected for data communications via a data communication network, comprising the steps of:

(a) providing a location service storing information relating object identifiers and location information associated with data items stored in a plurality of user computers;

(b) providing a plurality of types of object identifiers, each object identifier being associated with data items relating to a logical object of a predetermined type;

(c) providing an object index table for associating logical objects by storing object identifiers of one type in association with object identifiers of a different type;

(d) in response to a request for information relating to a particular logical object of a first type originating at one of the user computers, searching the object index table based on the object identifier of the particular logical object to obtain one or more selected object identifiers of a second type associated with one or more second logical objects;

(e) consulting the location service based on the one or more selected object identifiers of the second type to obtain the location of one or more selected user computers storing data items associated with the one or more selected object identifiers of the second type; and

(f) retrieving data items associated with the one or more selected object identifiers of the second type from the one or more selected user computers.

91. The method of claim 90, wherein the object index table comprises data relating at least one object identifier of a first type to multiple object identifers of a second type, and data relating at least one object identifier of the second type to multiple object identifers of the first type.

92. The method of claim 90, wherein the distributed data processing system includes at least one central computer operative for providing the location service, the object index table, and issuing requests to user computers to retrieve data items corresponding to object identifiers.

93. The method of claim 90, wherein the object index table comprises a junction table comprising a plurality of entries associating the first object identifier with a plurality of second object identifiers.

94. The method of claim 90, wherein the object index table is searchable by any object identifier.

95. A method of operating a distributed data processing system including a plurality of remotely located user computers and at least one central computer,

the user computers being interconnected with the central computer via a data communication network, comprising the steps of:

(a) providing an object attribute table in at least one of the user computers for storing data items in association with object identifiers;

(b) providing an object index table at the central computer for associating predetermined search information to object identifiers;

(c) providing a mapping table at the central computer for storing locations of the user computers and object attribute tables at the user computers in association with object identifiers;

(d) assigning a selected object identifier to data items associated with a particular subject;

(e) storing the data items associated with the particular subject in association with the selected object identifier at a particular user computer;

(f) in response to a query to the central computer for data relating to the particular subject, utilizing the predetermined search information in the object index table to retrieve the selected object identifier associated with the subject;

(g) utilizing the selected object identifier, determining from the mapping table the location of the particular user computer and an object attribute table at the particular user computer;

(h) retrieving data items associated with the selected object identifier that are stored in the object attribute table at the particular user computer via the data communication network.

96. A distributed computer system, comprising:

a plurality of remotely located user computers, each of the user computers being operative to perform data processing operations in response to user commands;

at least one central computer;

a data communication network connecting the user computers with the central computer;

each of the user computers being operative for:

storing data items in association with an object identifier; and

transmitting said object identifier to said central computer;

the central computer being operative for storing object identifiers received from the user computers in association with information indicating the location of the user computers; and

the central computer being operative for storing plural instances of a particular object identifier associated with data items stored in each of a plurality of user computers, some of the data items associated with the particular object identifier at a first one of the plurality of user computers being different from corresponding data items associated with the particular object identifier at a second one of the plurality of user computers.

97. The distributed computer system of claim 96, further comprising an object attribute index stored at said central computer, said object attribute index relating object identifiers and search terms, and a mapping table stored at said central computer, said mapping table storing location information and status information indicative of the source and status of the object attributes, and said object identifiers.

98. The distributed computer system of claim 96, wherein said central computer is operative in response to a request for information relating to a particular subject, for determining, from said plural instances of said particular object identifier, which data items at which of said plurality of user computers is most current.

99. The distributed computer system of claim 96, further comprising a mapping table stored at said central computer for storing object identifiers received from said user computers in association with information indicating the location of said user computers, and for storing status information.

100. The distributed computer system of claim 99, wherein said status information indicates which of said plural instances of a particular object identifier associated with data items stored in each of said plurality of user computers is most current.

101. The distributed computer system of claim 96, wherein said central computer is operative in response to a request for information relating to a particular subject from a requesting one of said user computers via said data communication network for:

determining a selected object identifier associated with said particular subject;

determining a selected one of said user computers in which data associated with said selected object identifier is stored;

transmitting via said data communication network a request for information to said selected one of said user computers, said request including said selected object identifier.

102. The distributed computer system of claim 101, wherein said selected one of said user computers is operative, in response to receipt of said request for information, for:

retrieving a data item associated with said selected object identifier; and

transmitting said retrieved data item to said central computer via said data communication network.

103. The distributed computer system of claim 102, wherein said central computer is operative, in response to a receipt of said retrieved data item, for transmitting said retrieved data item to said requesting one of said user computers via said data communication network.

104. The distributed computer system of claim 96, wherein each of said user computers is operative for:

storing said data items in association with said object identifier in an object attribute table identified by an object attribute table identifier, and

communicating said object attribute table identifier and object identifier to said central computer.

105. The distributed computer system of claim 104, further comprising an object attribute table index stored at a user computer to allow rapid searching for particular object attributes stored in an object attribute table in said user computer.

106. The distributed computer system of claim 105, wherein said object attribute table index comprises a table relating an object identifier to one or more data items associated with said object identifier.

107. The distributed computer system of claim 106, wherein said user computer site is operative for creating a new object instance, storing data items in association with the object identifier, and retrieving data stored at user associated with an object identifier provided by central computer.

108. The distributed computer system of claim 96, wherein each of said user computers is located at a user computer site including at least one customer database and at least one remote database associated therewith, wherein at least one customer database comprises a database structure that is heterogeneous relative to at least one other computer system in the distributed computer system, and wherein said at least one remote database comprises a database structure that is homogeneous relative to the central computer.

109. The distributed computer system of claim 108, wherein the at least one customer database runs on a different computer system than a computer system that runs the at least one remote database.

110. The distributed computer system of claim 108, wherein the at least one customer database runs on the same computer system as the at least one remote database.

111. The distributed computer system of claim 108, wherein at least one user computer in said distributed computer system includes a customer database comprising a first database structure, and at least one other user computer in said distributed computer system includes a customer database comprising a second database structure different from said first database structure so that such database structures are heterogeneous.

112. The distributed computer system of claim 108, wherein said remote database is further operative for communicating location information and related object identifiers to said central computer via said data communications network.

113. The distributed computer system of claim 108, wherein said user computers are operative for:

importing data items from a customer database into an associated remote database as selected data attributes associated with a particular object identifier, and

communicating said particular object identifier to said central computer.

114. The distributed computer system of claim 113, wherein the step of importing data items from the customer database comprises the steps of:

importing a first set of data items from the customer database as object attributes associated with a first object identifier;

determining that the first object identifier is related to at least one additional second object identifier; and

importing a second set of data items from the customer database as object attributes associated with the second object identifier.

115. The distributed computer system of claim 108, wherein each remote database at each user computer site comprises a homogeneous data structure, and further comprising the step of importing selected data items from an associated customer database into the remote database.

116. The distributed computer system of claim 115, wherein the step of importing selected data items from an associated customer database into the remote database comprises the step of mapping data items in a heterogeneous data structure on a customer database into predetermined object attributes stored in the associated remote database.

117. The distributed computer system of claim 116, wherein the step of importing comprises entering data items from the heterogeneous data structure into an object attribute table maintained at the associated remote database.

118. A distributed data processing system, comprising:

a plurality of remotely located user computers;

at least one central computer;

a data communication network connecting the user computers with the central computer;

an object attribute table stored in at least one of the user computers for storing data items in association with object identifiers;

an object index table at the central computer for associating predetermined search information to object identifiers;

a mapping table at the central computer for storing locations of the user computers and object attribute tables at the user computers in association with object identifiers;

a user computer being operative for:

assigning a selected object identifier to data items associated with a particular subject; and

storing the data items associated with the particular subject in association with the selected object identifier;

the central computer being operative in response to a query for data relating to the particular subject for:

utilizing the predetermined search information in the object index table to retrieve the selected object identifier associated with the subject;

utilizing the selected object identifier, determining from the mapping table the location of a particular user computer storing data items associated with the particular subject and the identity of a particular object attribute table at the particular user computer in which said data items are stored; and

retrieving data items associated with the selected object identifier that are stored in the particular object attribute table at the particular user computer via the data communication network.

Description

TECHNICAL FIELD

The present invention relates generally to distributed computing systems, and relates more particularly to an object-oriented distributed database system that transforms data stored in a plurality of remote, possibly heterogeneous user database structures into a homogeneous data model, stores location information and status information relating to the heterogeneous data via a centralized object broker for object management, thereby facilitating location and retrieval of data items from one or more of the remote, heterogeneous user databases.

BACKGROUND OF THE INVENTION

In a complex technological society, there is an ever-increasing need to store and retrieve information "globally", i.e., so as to allow access and use by a number of different societal entities. Because information is often accumulated in various, geographically dispersed sites, however, it is extremely difficult to synchronize and coordinate the information stored in dispersed sites. Therefore, traditional information processing systems rarely make information available on a global basis, without first centralizing it.

In response to the growing demand for a more efficient means to globally share information that is geographically dispersed, distributed computing systems have become a much more attractive means of information processing. A "distributed computing system" can be defined as a collection of multiple autonomous processors, usually with data stored in associated databases, typically located in geographically remote sites, that are inter-connected by data communications links.

Because of technological advances in communications and microelectronics, as well as a decline in hardware costs, distributed computing systems have experienced prolific growth in the last decade. Distributed computing systems are now being utilized in complex system design and application-oriented issues, including such well known examples as automated teller machine networks, airline reservation systems, and on-line validation of credit card transactions.

While substantial research has been devoted recently to distributed computing systems, much work remains to facilitate efficient data storage and retrieval, especially in view of the problems resultant from storage in geographically dispersed databases. One of the most difficult problems associated with distributed computing systems is the heterogeneous nature of the multiple processors or databases.

The autonomous processors in a distributed computing system can be homogeneous or heterogeneous. "Homogeneous" processors or databases are of the same kind, with the same data structures, and utilize the same data communications protocols. On the other hand, "heterogeneous" processors or databases are of different kinds, with different data models or structures, and they generally do not share information. Therefore, problems associated with intercommunication between heterogeneous processors and databases are much more complex and difficult than with homogeneous processors or databases.

Because the application programs for various known data processing systems are usually developed to meet the specific needs of different groups of users and without regard to compatibility with other data processing systems, most existing database systems are heterogeneous. Therefore, there is a general lack of coordination between heterogeneous databases, often leading to the duplication of data as well as a lack of data consistency among the files of different users.

Application of Distributed Database to Health Care Industry

A good example of a heterogeneous database environment is found in the health care industry. The health care industry is comprised of a wide variety of interrelated organizations, such as hospitals, insurance companies, health maintenance organizations (HMO's), testing labs, utilization review firms, and insurance payors and administrators. Many hospitals and hospital-management companies manage and run their own data processing systems, which often do not communicate between systems within the same company, let alone with systems of unrelated organizations. Some health care organizations run the same type of computer system at different geographical sites, and are therefore homogeneous in this respect, but cannot communicate the data between different sites. This lack of distributed homogeneity results in isolated homogeneous "islands" of information.

Even among organizations with homogeneous systems, it is possible that different entities (e.g. different hospitals that treat the same patient at different times) will store different information about the same person, or may store the same information using a different key identifier. Such occurrences introduce a degree of heterogeneity into a generally homogeneous computing environment.

A heterogeneous database environment is even more problematic than a homogeneous environment, and also does not provide optimum information processing to the health care community. For example, a given person may be a patient at more than one hospital during a given period of time. The identity of that person is a global fact--it is the same person that visits the hospital, although at different times, perhaps, and with different maladies. Because information about that person is entered and stored in more than one data processing system, there is duplication of information, and there is the undesirable possibility that inconsistent data will be accumulated about a particular person.

It is desirable that remotely located autonomous databases interact with others to share information. For instance, an insurance company may want to access patient records found in a hospital database. The hospital may likewise want to access information found in the insurance company database, such as whether and to what extent a particular patient has insurance coverage. Furthermore, it may be useful, or even life-critical, for information acquired at one hospital to be provided to the other, for example, the fact that a person is known to be allergic to certain medications.

Currently, such information is typically exchanged manually, e.g., a hospital administrator may telephone a patient's insurance carrier to determine information relating to the patient's insurance benefits. Alternatively, an insurance company may maintain a dedicated terminal at the hospital for remote access to the insurance company's database. Both of these methods, however, lack the level of automation necessary to support the global exchange of medical information across multiple heterogeneous databases. In addition, these known methods are error-prone since they do not provide a system for tracking the success or failure of information processing, such as adding and updating information in the global system.

As alluded to above, under conventional systems of information processing in the health care industry, it is often the case that information about a given patient is stored in multiple locations. For example, both a hospital and an insurance company may have the same information stored in their computer databases for the same patient, such as his or her address, telephone number, birthdate and other demographic information. The duplicative storage of information in autonomous databases is inefficient because it requires the expenditure of extra resources (in terms of human effort) to enter the information twice. There is also an increased probability of error because of the potential for inconsistent updating of information. Thus the risk that a user may access and rely on old information is greater, a situation that could be particularly dangerous or even life-threatening in the health care industry.

Accordingly, there is a need for methods and systems that provide for the global exchange of medical information within a health care community or other similar environment. The systems should provide a seamless interface between a plurality of remotely located, heterogeneous databases and a corresponding homogeneous data model so as to allow the retrieval and storage of information on a global basis. Such a system should also provide a mechanism for monitoring the status of the data within the system to ensure that users have access to the most current information available on the network.

Prior Art--The Galaxy Distributed Operating System

One approach to certain problems with distributed database systems is that in the Galaxy distributed operating system, which employs an object-oriented database model. See Sinha et at., "The Architectural Overview of the Galaxy Distributed Operating System", READINGS IN DISTRIBUTED COMPUTING SYSTEMS, IEEE Computer Society Press (edited by Casarant & Singhal, 1994), p. 327. (There is more discussion about object-oriented programming methodologies hereinbelow.) In the Galaxy system, a mapping table, also called an "ID table", is utilized for object locating, where each entry in the mapping table consists of locating information for an object. An ID table entry (IDTE) contains information about the type of the object, an access control list for the object, locations of the object's replicas, and locations where the copies of this IDTE exist (called a copy list). The replica list helps in returning all the locations of the desired object as a result of an object-locating operation. The Galaxy system uses the copy list to link together all IDTE's of the same object so that any modification can be made consistently to all copies. Given an object's ID, the Galaxy system can know that object's physical locations by searching the given ID in the ID table, and extracting the physical locations of its replicas from the ID table. However, choosing the method of maintaining the mapping table has proven to be a difficult task.

Specifically, object-locating mechanisms that were proposed and rejected in the Galaxy system include broadcasting, hint cache and broadcasting, chaining, centralized server (in which the entire ID table is kept on a single node), and replication (in which the entire ID table is replicated on all nodes). However, the Galaxy system designers apparently decided that all these mechanisms suffer from one or more common limitations of poor reliability, poor scalability, and poor efficiency. Thus, the Galaxy system uses a mechanism unlike any of those mentioned above. Rather, the Galaxy system keeps on a particular node only the locating information for those objects that have some possibility of being accessed from the concerned node.

It is clear from the literature that the Galaxy operating system is optimized for a homogeneous data model, since the architecture chosen for maintaining ID's in a directory located in each particular node can only operate for objects that can be accessed from the concerned node, which implies homogeneity.

Object-oriented database models incur other difficulties as a result of global object identity and object sharing. Global object identity is believed by those skilled in the art to be expensive because of lack of global virtual address space. The article by Ozsu and Valduriez, "Distributed Data Management--Unsolved Problems and New Issues", READINGS IN DISTRIBUTED COMPUTING SYSTEMS, supra, mentions this on page 531. The literature suggests that managing distributed shared objects is difficult, since inconsistencies can occur when a shared object is moved and updated at another site. Solutions suggested in the literature include the use of an indirection table or the avoidance of problems at compile time.

According to the literature, with the indirection table approach, the problem of distributed "garbage collection" is purportedly an open problem. However, the notion of garbage collection implies that a given object only exists in a single instance, and if outmoded (as when updated) the object is transformed into a different conceptual entity, with a different object ID. Thus, one would discard an outdated object in favor of a newer, updated object, necessarily having a different object ID. But this approach suffers from the disadvantage of excessive use of object identifiers. Excessive use of object identifiers is inefficient and costly, and is conceptually flawed since there is generally no need to discard an object merely because its data is outdated. It would be more efficient from a resources standpoint to maintain an object's identifier for so long as the need for any information whatsoever about the object exists.

It is therefore apparent that the literature teaches away from the use of a centralized server for purposes of object management. It also apparent that there is a need for cross-platform, distributed database systems and methods that operate to transform data from heterogeneous data structures into a homogeneous dam structure efficiently.

Other Approaches to Distributed Database Systems

Certain prior approaches to data storage and retrieval in distributed systems are concerned with optimization of read latency and dam availability associated with objects resident on the distributed system. Some approaches concentrate on how to distribute updates or transaction activity to all of the copies of an object resident in the network. Usually, many copies are kept to enhance data availability should certain nodes on network or communication links fail. The more copies that are made, the more likely it is that a given object will be available for reading and will require less latency to obtain data associated with the object. Significant effort is thus required to keep copies of objects equal at the distributed locations.

One approach to maintenance of dam in a distributed system is found in the SYBASE REPLICATION SERVER, a software database product made by Sybase, Inc., Emeryville, Calif. This system envisions maintaining multiple copies of a set of data on multiple servers, perhaps at multiple sites. Each copy at a remote site "subscribes" to a subset of data maintained at another site. The replication service keeps the multiple copies updated by replicating transactions initiated at a particular site directed against tables or data of interest, copying those transactions, and forwarding the copy of the transactions to remote destinations that apply these transactions to local copies of the dam maintained at the remote sites. Thus, this system is essentially a "transaction store and forward" system based on subscription information.

Yet another approach to heterogeneous distributed database systems is the Thor object-oriented database management system being developed at Massachusetts Institute of Technology (MIT). See Liskov, et al., "Distributed Object Management in Thor", Programming Methodology Group Memo 77, to appear in "Distributed Object Management" by Ozsu, et al. (June 1993). (Some of the "object oriented" terms used here are defined later in this application.) The Thor system is a distributed system in which objects are stored at server nodes. Object repositories are provided for storing and managing persistent objects, and, ostensibly, indexes to find objects. Users interact with the distributed system at a front end computer system such as a terminal or personal computer (PC) that communicates with an object repository.

It appears that the Thor system requires significant processing overhead for object maintenance. The Thor authors specifically rejected use of a name service, and thus rejected use of logical references or pointers. Instead, Thor uses physical references or pointers to optimize read operations. Any object that is referred to by another related object appears to have some type of physical reference or link to other objects that have need of the dam in the first object. If this is the case, then moving an object requires that all physical links or references from the referencing objects be updated so that such referencing objects can always "find" the object containing the data of interest. Although such a scheme may conceptually eliminate object replication and optimize read operations, it is complicated to maintain all of the physical pointers or links between related objects. Moreover, it appears that there is no client ownership of objects-all servers are equal and any client can update any object it can find, which creates complications of data security at distributed sites.

SUMMARY OF THE INVENTION

Briefly described, the present invention provides methods for operating a distributed data processing system including a plurality of independent remotely located user computers that process user data in user databases and at least one object broker computer. The user computers are interconnected with the object broker computer by data communication hardware over a data communication network. The user computers are operative to perform data operations of storing, updating, and retrieving user data items in response to user commands. The method comprising the steps of:

(a) for a subject at one of the user computers for which data is to be processed in the system, creating a new object instance by assigning a unique object identifier to data items associated with the subject;

(b) storing the data items associated with the subject at the user computer site in association with the object identifier;

(c) at the object broker computer, storing the locations of the user computers in a map table in association with object identifiers;

(d) in response to a query to the object broker computer for data relating to a particular subject in question, retrieving an object identifier for the subject in question;

(e) in response to retrieval of an object identifier for the subject in question in the preceding step, retrieving the location of a remote user computer associated with the retrieved object identifier; and

(f) retrieving data stored at the remote user computer associated with the object identifier via the data communication network.

More particularly described, each of the remotely located user computers comprises a heterogeneous data structure, and data is "homogenized" by mapping predetermined data fields items stored in the heterogeneous user computers to corresponding object attributes associated with a predetermined instance of an object, where the object is determined by an object model that relates to all of the heterogeneous user computers connected to the system. The object attributes are stored in an object attribute table in the remote user computers in association with object identifiers.

Preferably, the data items associated with the subject are stored in a separate, homogenized object-based remote database physically located at the customer's site, in association with the object identifier stored in the object attribute table. The object attribute tables are indexed at the remote databases for rapid searching and access by object identifier.

The object broker computer is preferably located in a central location. Functions carried out by the object broker computer include maintenance of a map table, one or more object index tables, and a global address space manager. Other functions include redirection of requests to the remote sites, and combining results from multiple remotes sites into a single response to a request from a remote site. The map table relates object identifiers to object attribute tables, locations of remote databases that contain the object attribute tables, and status information indicative of the currency of object attributes at each location. Since attributes of an object can exist in one or more remote locations, consultation to the map table by object identifier permits assembly or joining of data to construct a current complete set of object attributes associated with any given object. The object index tables relate predetermined search terms to object identifiers, to permit rapid searching to find an object identifier associated with the predetermined search terms. The global address space manager is responsible for providing a global object identification address space corresponding to a range of object identifiers for association with a plurality of subjects, and allocating a predetermined range of object identifiers within the global object identification address space to each remotely located user computer, for object control.

The remote databases, which can be separate computers from the customer database computers or a process within a customer database computer, maintain object attribute tables containing data items associated with each object class. The data items comprise attributes of object instances in association with object identifiers. These object attributes are obtained as a result of a homogenization operation, which occurs when data in the heterogeneous user databases is imported into the object model and thence into the remote databases. The homogenization operation involves mapping fields or data items in the heterogeneous data structures into object attributes in the object attribute tables, and then performing an "add" operation. Object attribute table indexes are also maintained at the remote databases to allow rapid searching, by object identifier, for the particular object attributes stored in the respective remote database.

Accordingly, it is an objective of the present invention to provide a distributed database computer system that overlays a homogeneous data model upon a plurality of possibly remotely located and possibly heterogeneous database systems or structures, so as to facilitate the retrieval and synchronization of information in a global fashion.

It is another objective of the present invention to provide a centralized server-based distributed database system that effects the retrieval of current data from one or more distributed heterogeneous databases that may store data in varying degrees of currency.

It is another objective of the present invention to reduce the expense of administration of various interrelated entities or organizations that need to communicate data, through process automation, information flow, personnel utilization and integrated systems use.

It is another objective of the present invention to increase the quality of medical care by providing the health care industry with shared clinical diagnosis and report information, thus reducing duplication efforts that result from maintenance of plural, heterogeneous databases associated with health care providers.

It is another objective of the present invention to provide a distributed database system that allows system users to have access to new data sources as they come on-line, without requiring the users or their systems to know the routing address or other identifying information about the new data source.

It is another objective of the present invention to provide object-oriented distributed database systems and methods that assign a persistent object identifier to a conceptual object in an object model used to impose homogeneity to heterogeneous data structures, where the object identifier is global throughout the entire system and persists so long as any information about that object must be retained.

It is another objective of the present invention to provide an object-based distributed relational database system and methods for use in the health care industry, that is operative to maintain information about particular patients, insurance carriers, hospitals, medical records, etc. that is accumulated from a plurality of distributed, heterogeneous, remotely located computer systems, in a homogeneous manner, thereby allowing information to be efficiently communicated, shared, and updated amongst the various heterogeneous users participating in the system.

These and other objectives, features, and advantages of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the appended drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block process diagram of the preferred embodiment of an object-based relational distributed computer system constructed in accordance with the present invention.

FIG. 2 is a block schematic diagram illustrating the physical hardware of an object-based relational distributed database system constructed in accordance with the preferred embodiment of the present invention.

FIG. 3 illustrates various concepts relating to object-oriented data modeling, as compared with relational data modeling.

FIG. 4 is an exemplary object model showing the abstract class of objects SERVICE PROVIDER with exemplary base subclasses and subjunction classes.

FIG. 5 is an exemplary object model relating to the health care industry utilized in the disclosed embodiment of the present invention, showing various objects employed in the object model and the relationships therebetween.

FIG. 6 illustrates various types of tables provided in the object broker and in the remote databases according to the preferred embodiment of the present invention.

FIG. 7 illustrates the map table in provided in the object broker constructed in accordance with the preferred embodiment of the present invention.

FIG. 8 shows exemplary object index tables provided in the object broker constructed in accordance with the preferred embodiment of the present invention.

FIG. 9 shows an exemplary Object Attribute Table (OAT) and Object Attribute Table Index (OATIDX) provided in a remote site in accordance with the preferred embodiment of the present invention.

FIG. 10 is a request message flow diagram illustrating the operation of the ADD message as utilized in the preferred embodiment of the present invention.

FIG. 11 is a request message flow diagram illustrating the operation of the SEARCH message as utilized in the preferred embodiment of the present invention.

FIG. 12 is a request message flow diagram illustrating the operation of the GET message as utilized in the preferred embodiment of the present invention.

FIG. 13 is a request message flow diagram illustrating the operation of the GET.sub.-- ALL message as utilized in the preferred embodiment of the present invention.

FIG. 14 is a request message flow diagram illustrating the operation of the UPDATE message as utilized in the preferred embodiment of the present invention, involving data in the same remote as the updating remote.

FIG. 15 is a request message flow diagram illustrating the operation of the UPDATE message as utilized in the preferred embodiment of the present invention, involving data in a different remote as the updating remote.

FIG. 16 is a request message flow diagram illustrating the operation of the UPDATE message as utilized in the preferred embodiment of the present invention, involving data stored in both the updating remote and in a different remote, with the most current information stored in the different remote.

FIG. 17 illustrates selected specific field names utilized in an exemplary remote, heterogeneous database structure and their corresponding field names in a homogeneous data model at the remote database as utilized in conjunction with the present invention.

FIGS. 18A-18C illustrate portions of the file structure used by an applications program interface (API) to transform data from an exemplary remote heterogeneous database structure to a homogeneous data structure in the remote database.

FIGS. 19A and 19B, joined at a match line to create a single figure, illustrate a PERSON Put Specification Table provided at the applications program interface (API) constructed in accordance with the present invention.

FIG. 20 is the Main Menu display screen generated by the preferred embodiment of the Patient Information Application software module constructed in accordance with the present invention.

FIG. 21 is the Person Information Query display screen generated by the Patient Information Application software.

FIG. 22 shows the Search Window on the Person Information Query display screen generated by the Patient Information Application software.

FIG. 23 is the Add Person display screen generated by the Patient Information Application software.

FIG. 24 is the Update Person display screen generated by the Patient Information Application software.

FIG. 25 is the Certification Type window on the Person Information Query display screen generated by the Patient Information Application software.

FIG. 26 is the Certification-Patient Demographics display screen generated by the Patient Information Application software.

FIG. 27 is the Certifications for Selected Patient display screen generated by the Patient Information Application software.

FIG. 28 illustrates the state of various data tables in the object broker and in the remote databases in conjunction with exemplary SEARCH and GET messages.

FIG. 29 illustrates the state of various data tables in the object broker and in the remote databases in conjunction with an exemplary UPDATE message.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to the drawings, in which like numerals indicate like elements throughout the several views and drawing figures, the preferred embodiment of an object-based relational distributed database system 10 constructed in accordance with the present invention will be described in connection with FIG. 1.

Overview of Preferred System

FIG. 1 shows the preferred system 10 comprising a plurality of remotely located client sites 12a-12d, identified as client site 1--client site 4, respectively, that are interconnected for data communications with an object broker 20. The object broker 20 preferably comprises a separate central stand-alone computer system that operates in the manner to be described. The user computers 12 communicate with the object broker 20 via separate data communications links 22a-22d. Further details of the preferred object broker computer 20 and communications links 22 are described in greater detail below.

In the preferred embodiment, the object broker computer 20 communicates with one or more remotely located client sites 12a-12d, thereby forming the distributed computing system. Each client site 12 comprises a user's local computer system or database 26 associated with the remote site, typically proprietary to and operated by the user, and a distinct remote database (RDB) 28 that serves as the interface between the user's computer system 26 and the object broker 20. Certain functions are effected at the object broker 20, while others are effected at the client's computer sites 12.

Each of the user computers or databases 26 may be homogeneous or heterogeneous. One of the principal advantages of the present invention is that various different or "heterogeneous" types of user computers may be connected and operated as nodes in a distributed computer system constructed in accordance with the present invention. It will be understood that heterogeneity in aspects of hardware architecture (e.g. IBM RS/6000, Hewlett-Packard, DEC VAX, Data General, etc.), operating system (e.g. UNIX, VMS, WINDOWS NT.TM., etc.), database engine (e.g. SYBASE.RTM., INGRES.RTM., INFORMIX.RTM., ORACLE.RTM., etc.), and data communications local or wide area networks and protocols (e.g. TCP/IP, X.25, token ring, ETHERNET, etc.) do not necessarily imply heterogeneity in data structure. The term "heterogeneous" as used herein refers to differences in the data models and/or data structures of the various computer systems or databases, which is distinct from differences in computer hardware and operating systems. The present invention provides means and methods for connecting and operating remotely located, possibly heterogeneous databases and user computers for operation and communication with one another, in the manner to be described.

Nevertheless, it will be understood and appreciated by those skilled in the art that the present invention is not limited to any one hardware architecture or operating system. The object-based relational distributed database system constructed in accordance with the present invention may be compatible with computer systems that differ in one or more aspects of hardware architecture, operating system, database engine, data communications local or wide area networks and protocols, and application software running on such systems.

For a given user computer site such as that shown at 12a, a customer's computer system or database, identified as CUST DB1 26a, is functionally and logically connected to a remote database (RDB 1) 28a, which may be (but is not necessarily) implemented as a separate computing entity. In order that communications can occur between the systems or processes serving as the customer database 26 and the remote database 28, a process called the "interface open server" 30, also denominated an "interface client" is provided to bridge the processes 26, 28 either logically or physically. The interface open server 30, as will be more fully described elsewhere herein, operates to transform the heterogeneous data models or structures of the customer database 26 into a homogeneous data model at the remote database 28.

FIG. 1 illustrates a preferred embodiment of the physical locations of the various components of the distributed database system, with the remote databases 28, the interface open servers 30, and the user computers or customer databases 26 physically located at a client site 12. However, those skilled in the art will understand and appreciate that the physical locations of the processes at the remote databases 28 and the interface open servers 30 are site non-specific, as indicated by the dotted line at 37. That is, a client's site 12 can comprise physically distinct computer systems to serve as the customer database 26 and as the remote database 28, but the two computing entities are logically and functionally connected. Thus, those skilled in the art will understand and appreciate that a single computing entity at a client site 12 may run different processes to effect the customer database 26 and the remote database 28. On the other hand, the customer database 26 and the remote database 28 can comprise physically distinct computer systems connected via a data communications network. (FIG. 2 illustrates such an embodiment, which is the preferred and disclosed embodiment herein.)

If physically distinct computer systems are used for the customer database 26 and remote database 28, a data communications link such as a local area network (LAN), wide area network (WAN), serial data communications link, or other computer-to-computer communications link well known in the art is provided. For systems wherein the customer database 26 and the remote database 28 are different processes within the same physical computer, the interface open server 30 comprises a series of commands and responses between the processes, with data shared in a buffer, or through any other known interprocess communication methods utilized in conjunction with known operating systems such as UNIX.

The exemplary system shown in FIG. 1 is modeled to illustrate a particular application of the present invention, namely, that in connection with the health care services industry. Such an application is the best mode currently contemplated by the inventors for the present invention, since there is a long-felt need for systems and methods for allowing computer communications between remote distributed heterogeneous databases such as those maintained by health insurance companies, employers, hospitals, physicians, and other health care industry participants. The present invention fills the need for the rapid and efficient exchange of information between the various entities in the industry to allow for increased efficiencies in patient admission, patient handling, payment transaction handling, insurance claim processing, and the like.

Accordingly, FIG. 1 illustrates that the client sites 12a-12d are associated with different entities in the health care industry, namely, an insurance company associated with a first client site (client site 1) 12a, an employer associated with a second client site (client site 2) 12b, a hospital associated with a third client site (client site 3) 12c, and a preferred provider organization, health maintenance organization, or other third party administrator (PPO/HMO/TPA) associated with fourth client site (client site 4) 12d, respectively. Further details of the relationship between these entities will be described in connection with the remaining figures.

Still referring to FIG. 1, in either the case of physically distinct computer systems for the customer database 26 and the remote databases 28, or wherein the customer database and the remote databases are in the same physical computing entity, the present invention involves implementation of two "application program interfaces" ("API"). A first API is that denominated the "customer specific API" 32, and a second API is that denominated the "object broker API" 36.

The customer specific API 32 serves as the interface between a customer database 26 and the remote database 28. As will be described in greater detail below, a customer specific API 32 is operative for mapping predetermined fields (i.e., data items) stored in a customer database system 26 to specific objects and object attributes (i.e., data items) in an object-based relational model provided in the present invention, regardless of whether the computer system that originated the data is homogeneous or heterogeneous relative to other computers in the system. The customer specific API 32, then, serves the function of transforming possibly heterogeneous data items into a uniform, consistent format system-wide, so as to facilitate the exchange of data items in a consistent data model. The data model described in connection with the preferred embodiment is that of the health care industry, after which it will be understood how to construct and implement object models for other applications.

In addition to a customer specific API 32, the present invention also provides an object broker API 36 at the logical boundary between a customer database 26 and a remote database 28. The object broker API 36 is operative to transform or map commands that originate with a requesting computer system into appropriate commands at the remote database 28, which can then be communicated over the communication links 22 to the object broker 20. The object broker 20 responds by formulating appropriate commands to one or more selected remote databases 28 within the system so as to retrieve selected data items appropriate for the data model and to ultimately provide the requested information back to a requesting computer system. Thus, the object broker API 36 serves as the logical connection between a customer database 26, which can be of varying types and is therefore heterogeneous, to a uniform system-wide convention so that data can be exchanged between the heterogeneous user computers in a transparent and efficient manner.

Physical Components or Hardware of the Preferred Object Broker

Referring next to FIG. 2, the physical structure of the preferred embodiment of the object-based relational distributed database system 10 comprises a plurality of remotely located, physically distinct user computer system sites 12 that communicate with an object broker computer 20 by various data communication links 22, utilizing application program interfaces (API) defining various request messages and responses between the various computing entities. The preferred object broker computer 20 comprises a pair of parallel IBM RS/6000 RISC-based computer systems 20a, 20b each including at least 128 megabytes of RAM, with at least 6 gigabyte hard disks serving as primary data storage, and integral ETHERNET network data communications. Preferably, each separate computer system 20a, 20b includes mirroring software so that the hard disks are duplicates of one another for redundancy and to minimize down time. Preferably, the object broker computers 20a, 20b are powered by uninterruptable power supplies (UPS) to further minimize the likelihood of down time.

Each object broker computer 20a, 20b is connected for data communications via an ETHERNET link 42 to a network router 43, preferably comprising a Telebit NETBLAZER 40.TM., a Token Ring MAU manufactured by Thomas & Conrad Corp., and a Telebit TRAILBLAZER.TM.. The network router 43 is connected to a modem bank 44 comprising a plurality of high-speed data modems 45, preferably a Hayes.RTM. Optima 9600 or the like. Each modem 45 in the modem bank 44 is connected by a conventional telephone-grade communication line to modems 46 associated with each of the remotely located user computer sites 12a-12d, thereby forming the data communication links 22.

It will be understood that each of the client sites 12 may operate computer systems of different types, running different types of hardware, different types of operating systems, different network architectures, and different types of user application programs, and therefore are heterogeneous both in physical architecture and in data structure. However, it is the heterogeneity in data structure that presents the greatest technical challenge and to which the present invention is particularly directed. In the exemplary embodiment of FIG. 2, the computer system of each client site 12 comprises at least one main CPU 40, such as the main CPU 40a associated with the user computer site 12a. The main CPU 40a serves as a node on a local area network (LAN) 47 that is interconnected with a plurality of other CPU's 40b, 40c which also serve as nodes on the network 47 associated with the site 12a. The LAN may be ETHERNET, token ring, or any of a number of different data communications network standards. A network router 48 connected to the LAN 47 directs incoming data communication packets from a modem 46 onto the LAN 47 and then to a target destination or node.

In the preferred embodiment, a separate UNIX-based server computer 40d runs code to execute the functions of the remote databases (RDB) such as RDB 1 28a. Communications between the server computer 40d (comprising the RDB 28a) and the customer databases that are maintained by one or more of the CPU's 40a-40c (comprising the customer database 26a) are communicated on the LAN 47. Accordingly, the API between the customer's database equipment 26 and the RDB's 28 are passed as data communication packets on the LAN 47.

Before leaving FIG. 2, it should be noted that access to system 10 is not necessarily limited to communications via the modem bank 44, nor necessarily requires a local area network for communications between the RDB functions 28 and the customer database functions 26. A s previously described, the remote database functions in the RDB computers 28 can be carried out as a separate process on a user computer that normally executes the customer database functions 26. Similarly, in the preferred embodiment, access to the system can be made by a stand-alone computer and modem.

One example of alternative access to the system is shown in FIG. 2, which illustrates a stand-alone personal computer (PC) 49, for example a physician's office computer, that connects via a modem 46 to a corresponding network router 48, in this case associated with the user computer site 3 12c. Alternatively, there could be a direct connection between a modem 45 and the modem bank 44, or a separate ETHERNET-based modem such as that shown connected to the modem 46 associated with the client site 4 12d, or a LAN connection by the PC 49 directly to the network 47d associated with the site. Those skilled in the art will understand and appreciate that other hardware and data communications facilities can be utilized in conjunction with the present invention so as to carry out the objectives and features of the invention. In particular, it will be appreciated that a PC such as the one 49 is used to run the Patient Information Application software described in greater detail below.

Object-based Relational Modeling

The following discussion introduces the concepts required for object based relational modeling. It is assumed here that the reader is familiar with the notion that an "object", for purposes of computer modeling, comprises a plurality of data items with an associated object identifier or object ID. The object identifier or object ID is often referred to herein as "OBJID".

Very generally, most people perceive the world as being organized into things or objects. Most computer filing systems, however, do not treat things in the real world as objects, but instead as tables of related data items. In an "object-oriented" representation, a computer system represents an entity or item such as a number, a person, a city, etc. as an object. "Objects" in the real world directly correspond to "objects" in the data model. Accordingly, it is expected that an object-based model representing information and processes in a computer will be more intuitive, and will more readily facilitate the mapping of information from the real world to a computer model.

There is some diversity of opinion in the computer industry as to what is meant by an "object" and the degree to which a computer program or database system is considered "object-oriented". Various terms have emerged in the art to capture various aspects of "object-oriented" approaches. These terms include the words encapsulation, classes, inheritance, message-passing, polymorphism, and persistence.

The term "encapsulation" means that information associated with an object is to some degree hidden and not directly accessible. Encapsulated data often must be accessed and changed via indirect methods.

The term "classes" relates to objects of similar types. Objects of the same class are grouped together and have certain properties, attributes, or behaviors in common. Classes may be organized into hierarchies of subclasses in which the procedures and attributes of the class are inherited by its subclasses. Thus, a "subclass" is a group of objects that have some properties, attributes, behaviors, or procedures with other groups of objects, but could have other properties, attributes, behaviors, or procedures that are different.

The term "attribute" relates to data items or information or behavior that relate to a particular object.

The term "inheritance" means the sharing of properties, and in some cases attributes and behaviors, that characterize a class by its subclasses. The notion of inheritance purportedly allows for easier maintenance and extension of computer programs since creation of subclasses purportedly allows the program code used to created the parent class to be readily modified and reused for subclasses.

The term "messages" means the basic mechanism of communication and computation for objects; messages are passed between objects, and these messages invoke an object's procedures.

An object's "procedures" are operations upon data items or data attributes so as to cause a computing result and provide a response. The data operated upon may or may not be hidden (encapsulated) in the object.

The term "persistence" refers to the idea of a long-lived or persistent entity. In other words, an object (that is, a computer-based object) may continue to exist after the application that created it completes its function. In the present invention, objects have an infinite persistence--once an object is assigned an object identifier, that object identifier remains forever and is never mused. Thus, an object may have an infinite persistence, even if the corresponding real world entity dies or is destroyed.

The term "polymorphism" means that different objects may respond differently to the same message. The term relates to a system's ability to invoke one of a set of identically named procedures depending on the class (or type) of the target object on which the procedure is intended to operate. For example, a set of "print" procedures could be prepared for each of a set of classes (or object types). When an arbitrary instance of one of these classes is then sent the "print" message, the system invokes the appropriate "print" procedure by referencing the target object's type identifier, which is usually stored somewhere inside the target object. This causes the object to "print" itself with the "print" procedure that was written to handle any special aspects associated with the object's type (class). The sender of the "print" message need not maintain an awareness of the type (class) of the object it is "printing" in order to invoke the appropriate "print" procedure.

An "instance" of a class is a particular object, and generally corresponds to a particular identifiable real world entity. Since a class is a grouping of similar objects or instances of the class, all objects of the class use the same procedures and respond to the same messages.

Certain aspects of object-oriented programming techniques are utilized in the present invention so as to provide the transformation of heterogeneous data models stored in distributed user's computer systems at client sites 12 into a homogeneous data model based on a predetermined object system. In other words, the present invention provides means for transforming different, heterogeneous types of information stored in different computers, all of which can relate to the same conceptual framework, into a uniform format for exchange. The present invention utilizes an object-oriented methodology to create the distributed system, and to model the information exchanged between system users.

This approach, while generally object-oriented, borrows from certain relational database methodologies. Relational database technology is a relatively mature computer technology for business oriented data processing. Relational databases, however, utilize a "record-based" data model which is more difficult to utilize in a heterogeneous environment. In a relational database model, data is organized into tables comprising columns and rows of data items. Columns represent individual topics of information, while rows represent the information for a single entity across all columns. Therefore, each data item in a row roughly corresponds to a "record" in a conventional file system. The fact that many different computer systems may store the same information in different tables and in different formats gives rise to the heterogeneity of the data model or structure. For example, one computer system may store a row of information about an individual in the format of NAME, ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY, while another system may store information about the same individual as FIRST.sub.-- NAME, LAST.sub.-- NAME, MIDDLE.sub.-- INITIAL, ADDRESS, CITY/STATE, ZIPCODE. Each of these characteristics constitutes a separate field or attribute of a row in a relational or table-based data model.

The present invention utilizes aspects of both object-oriented data modeling and relational data modeling, yielding an object-based relational model. Viewed from a system and programming perspective, an object-based conceptual framework is utilized to model real world entities, the data for which is to be accumulated and processed. The object model allows a system-wide perspective to be imposed on distributed, heterogeneous data. From the user's perspective, however, the data is accumulated and processed in a relational model--data is captured in generally tabular format, usually by means of a relational database operated in conjunction with the user's proprietary computer system at the client sites 12. The present invention introduces an object-oriented framework from a distributed system-wide perspective, but allows the data at each, possibly heterogeneous, user's computer to be captured and stored locally.

With particular reference now to FIG. 3, a conceptual framework for an object based relational model will be described. Consider a situation involving a transaction processing system. The present invention is especially suitable for use in a transaction processing system. By "transaction processing system", we mean any type of computer system that is operative to update databases or flies as a function of an event-related exchange or transaction. A "transaction" is a collection or grouping of related actions associated with a particular event, such as admission of a patient to a hospital, or a visit by a patient to a doctor, or the payment by a guarantor such as a health insurance company of a claim, or the like.

While a transaction processing system is one particularly advantageous application of the present invention, a transaction processing system per se is not necessarily distributed. A true distributed database system provides many functions and applications that simple transaction processing systems cannot necessarily provide. Many transaction processing systems merely operate to exchange information related to a given transaction, e.g., the withdrawal of cash from an automated teller machine (ATM). A transaction processing system usually involves creation of a data item (e.g. amount of cash withdrawn from which account), and does not necessarily provide functions such as querying or structured organization of the data. For example, a user of an ATM cannot obtain a report from the ATM as to the amounts of cash drawn against his or her account from other ATMs in the network. The user also cannot access all banks at which he or she have an account, even if all of the banks are connected to the ATM network.

The present invention finds particular utility in a transaction processing system that involves distributed data collection in a heterogeneous environment. To illustrate the invention's utility in this regard, we will next consider a transaction processing system involving the health care services industry, and how to create an object model of such a transaction processing system. After creation of the object model in this example, those skilled in the art will more readily understand how to make and use the present invention in connection with other applications.

FIG. 3 illustrates a transaction such as might be found in the health care services industry, as where a patient with an illness visits a physician's office. The real transaction, therefore, involves two subjects, a patient (subject 1) and a physician's office (subject two), engaged in an exchange of some type. Typically, in exchange for money, health services are rendered by the physician's office. Although this is an over-simplification, for the present it is sufficient to note that a transaction typically involves one or more subjects, involving one or more items of exchange (IOE). The information that is generated in such a real transaction is transformed into data items, particularly if third party guarantors such as insurance companies that pay benefits are involved. Typically, the data items relate to the items of exchange.

In order to model the transaction in a computer system with an object-oriented model, one type of object may be a PATIENT, a second type of object may be a PHYSICIAN, while a third type of object may be a VISIT relating the physician to that patient. In the object-oriented model, information pertaining to the patient is often of varying types, which correspond to varying data items such as data item 1, data item 2, . . . data item n. For example, data items typically associated with a PATIENT include the patient's name, address, social security number, health insurance company carrier, etc.

Data items associated with a PHYSICIAN usually include the physician's name, social security number, Medicaid identification number, etc. Viewed as an object, a physician also includes data items data item 1, data item 2, . . . data item

A VISIT object is effectively a junction record between PATIENT and PHYSICIAN. A "junction" record or table is described below. The junction record contains data items associated with the VISIT, which typically include patient name, attending physician, dates of admission and discharge, description of the malady, fees paid, etc. Viewed as an object, a visit also includes data items data item 1, data item 2, . . . data item n. It will be noted that both the PATIENT object and the PHYSICIAN object are different from a VISIT object, yet the objects in this example contain certain information that is in common, such as the physician's name, yet other information may be different.

In a purely relational model, each of the various data items relating to the patient and the physician would be accumulated in tables as shown in FIG. 3. The tables include "base" tables and "junction" tables. Base tables relate to primary, often tangible conceptual entities in the object model and serve as anchors for other data to be connected to. The data items relating to the visit would be accumulated in a subordinate table (called a "junction" table), where junction tables relate to lower level, sometimes intangible conceptual entities that must be connected to a higher level object. For example, a "visit" by a patient to a physician is an intangible event or entity that cannot be touched or felt, while both the patient and physician are actual, tangible real-world entities. Nonetheless, a visit has data (information) associated with it, e.g., a date, and association between a particular patient and a particular doctor, and a particular malady.

Therefore, junction tables, often involving intangible entities or events or transactions, must point to one or more base tables, but they also include data. For example, the junction table VISIT would include an admission date, which would not have any meaning unless it pointed to both PATIENT and PHYSICIAN.

Relational databases are often characterized by the use of value based, or logical, pointers (i.e., not physical pointers) in the tables that point to data items in other tables, so that data in common to two tables is not duplicated. The pointers are logical because they do not give an actual physical location of the object. Physical pointers, on the other hand, are employed within the database engine utilized in the preferred embodiment of the invention (e.g., in a SYBASE.RTM. database system) for directly accessing data from particular storage locations on a disk or other mass data storage medium associated with the system.

In relational database terminology, a "primary key" uniquely identifies every row in a table. A primary key is used as a logical pointer in the examples which follow. Primary keys are usually significant, distinguishing information such as a person's full name, social security number, or other unique information. A "foreign key", on the other hand, comprises information in a subordinate or junction table that corresponds to the primary key information in a dominant or base table in order to logically join the two tables. For example, in a relational database, a VISIT table might contain a logical pointer to patient demographic information (name, address, telephone number, etc.) associated with a person stored in a different table. The data in two different tables, e.g. PATIENT and VISIT, are thus "related" by use of the logical pointers, thus giving rise to the "relational" label. Foreign keys used in the description are also logical, not physical pointers.

For example, in the example of FIG. 3, in the PATIENT table (which is a base table) primary keys include full name, social security number, and birthdate, while other data of interest might include a person's telephone number or zip code. In the VISIT table (a subordinate or junction table), attributes such as an admit date, or discharge date would be information of interest, but patient name and/or attending physician would be "foreign keys" since this information is used to obtain information contained in a base table elsewhere.

Those skilled in the art will understand that database indexes are typically constructed utilizing primary and foreign keys, while other data of interest in a table is not necessarily indexed.

For purposes of the present discussion, it should be understood that in a relational model, the data is arranged in one or more tables, while in an object-oriented model, the data is organized as objects which communicate in the form of request and/or response messages. Each object, or instance of an object, is a relatively self-contained entity, with the data items associated therewith encapsulated or isolated to some degree from data items associated with other types of objects. Thus, a PATIENT object is an instance of a PERSON class of objects and would include the data items associated with persons who are patients, while a VISIT object would contain data items associated with a visit by a particular patient (with information derived from the PATIENT object) to a particular physician (with information derived from the PHYSICIAN object).

It should be apparent that there is a need to coordinate or make consistent the information contained between PATIENT objects and VISIT objects, since certain data items may be in common between the two. For example, a particular instance of a PATIENT object contains the name of a particular patient, and a particular instance of a VISIT object contains the name of a particular patient who made a visit to a particular physician. The strength of the relational approach is that it obviates duplication of data, e.g., a VISIT junction record pulls the patient's name from the PATIENT base table; there is no need to duplicate the patient's name in another table. One weakness of the relational model is that it is difficult to implement across heterogeneous system boundaries, after the fact.

Object based modeling offers certain advantages over relational modeling. Object based modeling enables more reuse of particular database columns and tables, by modeling more abstract entities than is possible with typical relational modeling techniques. The use of more abstract modeling yields fewer tables and columns than relational modeling. Furthermore, the use of more complex data structures allows some problems to be solved using less code than would otherwise be possible or practical.

The present invention utilizes favorable aspects of both object-based modeling and relational modeling by allowing creation of a system-wide data model for institutions such as the health care services industry. An object-based relational data model allows data accumulated at remote, heterogeneous computer systems, often in a relational, tabular format associated with proprietary database engines, to be exchanged utilizing an object-based model for communications between the disparate facilities. In the present invention, objects are created on a global (system-wide) basis, invisibly to the remote, heterogeneous computers, thereby allowing superposition of a uniform object-oriented data model upon a plurality of remotely located, distributed relational database systems maintained by different entities at different locations, thereby accomplishing the objectives of the present invention.

Simplified Object Model--Service Provider

Referring next to FIG. 4, further object-oriented concepts will be introduced in the context of the preferred health care information system. FIG. 4 illustrates an abstract class of objects 50 denominated SERVICE PROVIDER. An "abstract class" in object oriented terminology means a class for which no actual instances occur. Instances of abstract classes are not allowed because an abstract base class is not complete. The abstract class SERVICE PROVIDER 50 is a class of objects that conceptually encompasses a common subset of attributes and/or behaviors shared by several different subclasses that can have actual instances. In FIG. 4, there are derived based classes of HOSPITAL 51, PHYSICIAN 52, and PRACTICE 53. Conceptually, all of these derived base classes 51-53 are a SERVICE PROVIDER which can have actual instances because behavior, attributes, data, etc. specific to each derived class complete the abstract base class. However, the base class SERVICE PROVIDER is abstract, in that it has no actual instances. The figure illustrates that the derived base class of HOSPITAL 51 is a SERVICE PROVIDER 50 (with the nomenclature "›is a!"), as indicated by the half circle on the diagram. Likewise, a PHYSICIAN 52 ›is a! SERVICE PROVIDER 50.

The derived base classes 51-53 in FIG. 4 each contain subordinate classes, or junction classes, 58-59. For example, the junction class HOSPITAL.sub.-- PHYSICIAN 58 points to the base table HOSPITAL 51 and the base table PHYSICIAN 52, while the junction class PRACTICE.sub.-- PHYSICIAN 59 points to the base table PHYSICIAN 52 and the base table PRACTICE 53. In this example, the HOSPITAL.sub.-- PHYSICIAN 58 draws related information from both the HOSPITAL 51 and a PHYSICIAN 52. The HOSPITAL.sub.-- PHYSICIAN 58 can, and does, contain other information, e.g. a particular physician's privileges at the particular hospital, not illustrated in this limited example. Likewise, a PRACTICE.sub.-- PHYSICIAN 59 draws information from a PHYSICIAN object 52 (e.g. the name of particular physician) and a particular PRACTICE 53 (e.g. a particular practice specialty for a physician such as internal medicine, radiology, etc.) to relate the two.

More Complex Object Model--Health Care System

Obviously, the example given in FIG. 4 only introduces certain basic concepts. FIG. 5 extends the object model introduced in FIG. 4 to a more complex situation relating to the health care services industry, which is associated with the preferred embodiment of the present invention. It will be understood that the object model shown in FIG. 5 is a simplification of that actually utilized in the preferred embodiment. Nonetheless, certain objects referred to in later discussions are introduced here so as to provide a framework for understanding the present invention.

As described above, the abstract class of SERVICE PROVIDER 50 can have varying subclasses (derived base classes) of objects such as HOSPITAL 51, PHYSICIAN 52, and PRACTICE 53, with each of the subclasses having actual instances.

FIG. 5 illustrates concepts useful in the object-oriented methodology. A line extending from one object to another, terminated by an arrowhead, whether single or double, indicates that data in the object from which the line extends is drawn from the object pointed to by the arrowhead. A line with double arrowhead indicates a "one-to-many" relationship to a "junction record". A "junction record", defined earlier in a purely relational context, in an object oriented context is considered a relationship comprising a plurality of instances associated with a particular entity. For example, a PERSON 56 can contain or point to many instances of VISIT 54, indicating that a person can have multiple visits to a medical care provider.

Accordingly, an INSURED 57 can contain or point to a number of PERSONS 56, in a one-to-many relationship. For example, if a particular person is the nominal insured party in a health insurance plan, that person can be the responsible party for a number of other persons, such as members of his or her family, as actual instances of the subclass PERSON. This indicates that there can be multiple instances of PERSON for any one given instance of INSURED. On the other hand, there may be multiple instances of INSURED for any one given instance of PERSON, for example, if a person has insurance coverage from multiple sources, e.g. through an employer-based plan and through a privately purchased insurance plan. Therefore, the double arrow notation between PERSON 56 and INSURED 57 in FIG. 5 indicates the presence of ode or more junction records or tables (not shown) that represents or corresponds to a "many-to-many" relationship between certain classes or subclasses of objects.

Typically, a m