|
|
|
Distributed or remote access |
Methods and systems for object-based relational distributed databases5560005
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 independent 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 by data communication hardware over a data communication network,
the user computers being operative to perform data operations of storing, updating, and retrieving user data items in response to user commands, 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 an object instance by assigning a unique object identifier to data items associated with the subject by:
(a1) providing a global object identification address space corresponding to a range of object identifiers for association with a plurality of subjects; and
(a2) allocating a predetermined range of object identifiers within the global object identification address space to each remotely located user computer;
(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) in response to a query to the object broker computer for data relating to a particular subject in question, retrieving a selected 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 selected object identifier; and
(f) retrieving data stored at the remote user computer 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 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.
4. 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.
5. 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.
6. The method of claim 5, 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.
7. 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.
8. The method of claim 7, 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.
9. 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 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.
10. The method of claim 9, 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, 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.
11. The method of claim 9, 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.
12. The method of claim 9, 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.
13. The method of claim 9, 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.
14. The method of claim 9, 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.
15. The method of claim 14, 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.
16. The method of claim 14, wherein the updating user computer is the same as the particular remote database containing the most current data corresponding to the particular object identifier.
17. The method of claim 14, 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.
18. The method of claim 14, 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.
19. The method of claim 18, 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.
20. The method of claim 1, wherein the mapping table stores information relating object identifiers, status information, and location information.
21. The method of claim 20, 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.
22. The method of claim 21, 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.
23. The method of claim 22, 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.
24. 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.
25. The method of claim 24, 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.
26. The method of claim 24, 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.
27. The method of claim 24, wherein the at least one customer database runs on the same computer system as the at least one remote database.
28. The method of claim 24, 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.
29. The method of claim 24, 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.
30. The method of claim 29, 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.
31. The method of claim 24, 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.
32. The method of claim 31, 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.
33. The method of claim 32, 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.
34. The method of claim 31, 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.
35. The method of claim 34, 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.
36. The method of claim 34, 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.
37. The method of claim 24, 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.
38. The method of claim 37, 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.
39. The method of claim 38, wherein the step of importing occurs in response to a put request message provided by a user at a user computer site.
40. The method of claim 38, 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.
41. The method of claim 40, 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.
42. The method of claim 41, wherein the object attribute table index comprises a table relating an object identifier to one or more data items associated with the object identifier.
43. 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,
the user computers being interconnected for data communications by data communication hardware over a data communication network,
the user computers being operative to perform data operations of storing, updating, and retrieving user data items in response to user commands, comprising the steps of:
(a) providing a location service storing information relating object identifiers and location information associated with subsets of data items stored in the plurality of user computers;
(b) associating a first object identifier with a selected first set of user data items relating to a first logical object;
(c) associating a second object identifier with a selected second set of user data items relating to a second logical object;
(d) associating a third object identifier with a third set of user data items relating to a third logical object, the third set of user data items including particular data items corresponding to the first logical object and the second logical object;
(e) in response to a selected search term relating to the third logical object originating at one of the user computers, searching an object index relating search terms to the object identifiers to obtain the third object identifier;
(f) consulting the location service based on the third object identifier to obtain the related first object identifier and second object identifier;
(g) determining selected locations of a user computer storing data items associated with the first object identifier and a user computer storing data items associated with the second object identifier;
(h) retrieving data items associated with the first object identifier and the second object identifier from the selected user computers; and
(i) joining the retrieved selected data items associated with the first object identifier and the second object identifier to obtain a complete set of data items associated with the third object identifier.
44. The method of claim 43, wherein the distributed data processing system includes at least one central computer operative for providing the location service, the object index, and issuing requests to user computers to retrieve data items corresponding to object identifiers.
45. The method of claim 43, wherein each of the remotely located user computers comprises a heterogeneous data structure.
46. The method of claim 43, wherein each of the remotely located user computers are located at a user site including at least one customer database and at least one remote database associated therewith, wherein said at least one customer database is a heterogeneous database structure relative to at least one other computer system in the distributed system.
47. 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 object broker computer,
the user computers being interconnected with the object broker computer by data communication hardware over a data communication network,
the user computers being located at a user computer site including at least one customer database and at least one remote database associated therewith,
the user computers being operative to perform data operations of storing, updating, and retrieving user data items in response to user commands, 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 an 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 in association with the object identifier by:
(b1) importing data items from a customer database into an associated remote database as selected data attributes associated with a particular object identifier by:
(b1a) importing a first set of data items from the customer database as object attributes associated with a first object identifier;
(b1b) determining that the first object identifier is related to at least one additional second object identifier; and
(b1c) importing a second set of data items from the customer database as object attributes associated with the second object identifier; and
(b2) communicating the particular object identifier to the object broker computer;
(c) at the object broker computer, storing the locations of the user computers in a mapping 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 a selected 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 selected object identifier;
(f) retrieving data stored at the remote user computer associated with the selected object identifier via the data communication network;
(g) storing object attributes associated with the first object identifier in a first object attribute table;
(h) storing the first object identifier and the second object identifier in a junction table relating object identifiers to each other;
(i) storing object attributes associated with the second object identifier in a second object attribute table;
(j) 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.
48. The method of claim 47, 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.
49. The method of claim 47, 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.
50. The method of claim 47, 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.
51. The method of claim 47, wherein the at least one customer database runs on the same computer system as the at least one remote database.
52. The method of claim 47, 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 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.
53. The method of claim 52, 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, 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.
54. The method of claim 52, 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.
55. The method of claim 52, 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.
56. The method of claim 52, 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.
57. 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 object broker computer,
the user computers being interconnected with the object broker computer by data communication hardware over a data communication network,
the user computers being operative to perform data operations of storing, updating, and retrieving user data items in response to user commands, 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 an 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 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) in response to a query to the object broker computer for data relating to a particular subject in question, retrieving a selected 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 selected object identifier;
(f) retrieving data stored at the remote user computer associated with the selected object identifier via the data communication network;
(g) maintaining an object index table at the object broker computer for relating at least one predetermined search term to at least one object identifier, wherein the object index table for relating at least one predetermined search term to at least one object identifier is a relational data base table; and
(h) 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.
58. The method of claim 57, 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.
59. The method of claim 57, wherein the mapping table stores information relating object identifiers, status information, and location information.
60. The method of claim 57, 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.
61. The method of claim 57, 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.
62. The method of claim 61, 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.
63. The method of claim 57, 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.
64. The method of claim 63, 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.
65. The method of claim 57, 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 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.
66. The method of claim 65, 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, 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.
67. The method of claim 65, 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.
68. The method of claim 65, 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.
69. The method of claim 65, 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.
70. The method of claim 65, 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.
71. The method of claim 57, 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.
72. The method of claim 71, 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.
73. The method of claim 71, 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.
74. The method of claim 71, wherein the at least one customer database runs on the same computer system as the at least one remote database.
75. The method of claim 71, 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.
76. The method of claim 71, 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.
77. The method of claim 76, 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.
78. The method of claim 77, 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.
79. The method of claim 76, 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.
80. The method of claim 79, 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.
81. The method of claim 71, 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.
82. The method of claim 81, 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.
83. The method of claim 82, 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.
84. The method of claim 83, wherein the step of importing occurs in response to a put request message provided by a user at a user computer site.
85. The method of claim 83, 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.
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 al., "The Architectural Overview of the Galaxy Distributed Operating System", READINGS IN DISTRIBUTED COMPUTING SYSTEMS, IEEE Computer Society Press (edited by Casavant & 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 data 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 data 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 data 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 data 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 data 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 laser 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 databases as utilized in conjunction with the present invention.
FIG. 18, consisting of FIGS. 18A, 18B, and 18C illustrates 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.
FIG. 19, consisting of 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. I 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. As 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 reused. 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 flamework 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 files 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 n,
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 function 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 one 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 many-to-many relationship is implemented in the present invention as one or more junction records, comprising one or more tables that relate one object, such as a PERSON, to multiple instances of related objects, such as INSUREDs, and conversely that relate the other object, INSURED, to multiple instances of related PERSON objects.
Note in FIG. 5 that there is a one-to-many relationship between a PERSON object 56 and a VISIT object 54, indicating that any given person can have a number of visits, perhaps by the same health care supplier or from different health care suppliers.
Consider next the abstract base class SERVICE PROVIDER 50, which has a many-to-many relationship to VISITS 54. Thus, any given service provider many need to track a number of visits. Examples or subclasses of service providers include a HOSPITAL class 51, PHYSICIAN 52, and physician's PRACTICE 53. These examples relate also to the discussion of FIG. 4. Note the relationship between a physician's PRACTICE class 53 and PHYSICIAN 52, since a physician may be a member of a group of physicians forming a practice, and may have a particular primary practice reflected in a PRACTICE.sub.-- PHYSICIAN 59 object instance.
It should be noted in conjunction with FIG. 5 that the relationship between various computer systems that typically create specific instances of objects is illustrated. For example, and referring between FIG. 1 and FIG. 5, the client site 3 12d corresponds to a hospital, where the hospital is shown as an object 51. Likewise, the insurance company or carrier 60 corresponds to the user computer site 1 12a, and the PPO/HMO/TPA 61 corresponds to the user computer site 4 12c. Similarly, the employer 63 in FIG. 5 corresponds to the user computer site 2, shown at 12b in FIG. 1.
Note in FIG. 5 the preadmission certification object, identified at 67. In the preferred embodiment, a preadmission certification object instance is an associative entity-type object, utilized to signify that a particular person is certified to receive a particular procedure by a particular physician. These objects, and the relationship therebetween, are discussed in greater detail below in connection with the Patient Information Application software. For the present, it is sufficient to note that the preadmission certification object 67 has lines directed to, and therefore draws data from, a person object 56, a physician object 52, and a UR (utilization review) firm 65. In a typical health care information system, for particular sets of benefits a particular UR firm 65 may be designated as qualified to determine the appropriateness of treatments for a given diagnosis. The object UR firm 65 is therefore related to a BENEFITS object 68, which collects and stores health care benefit information derived from, for example, a person's insurance carrier 60, employer 63, or a group plan 69.
To summarize the foregoing--in accordance with the present invention, objects based on real world entities or transactions involved in an institution to be modeled (such as the health care services industry) are determined, and the relationships between the objects are determined. A determination is made whether a relationship between objects is one-to-one, one-to-many, or many-to-many (corresponding to inverse one-to-many). After determination of the object model and relationships there between, the object model is applied to the various, possibly heterogeneous computer systems that comprise unconnected, distributed computer systems associated with the institution. Then, a system can be constructed in accordance with the invention that allows communication between the disparate, separate, heterogeneous computer systems with heterogeneous data structures.
After the conceptual framework for any given system is established, such as has been described in connection with the health care industry, then the method can proceed to the establishment of creation of actual instances of the varying types of objects, maintained by the object broker 20 on a global system-wide basis, so that information relating to the varying types of objects can be tracked and maintained on a uniform, consistent, efficient system-wide basis.
Central Computer or "Object Broker"
In the present invention, the object broker computer 20 is the entity primarily responsible for imposing organization upon the various types of objects and instances of objects that are created in modeling a given institution. The object broker 20 is responsible for (1) managing object identifiers or "object IDs", also called "OBJID", (2) assigning ranges of object identifiers to the various remote databases associated with the user computers 12, (3) maintaining a map table relating the location of various objects and the status of the objects, and (4) maintaining search indexes (object index tables) that allow rapid finding of particular objects in response to search queries from users connected to the remote computers.
In the preferred embodiment, the object broker computer 20 runs the SYBASE.RTM. relational database system or engine, manufactured by Sybase, Inc., Emeryville, Calif., so as to carry out its functions as described herein. Those skilled in the art will understand that the preferred SYBASE relational database system facilitates creation and maintenance of data tables, as well as indexes to such tables for rapid searching, arid provides for programming of stored procedures for creating tables, adding data items to pre-existing tables, updating and sorting indexes, etc. As will also be known, indexes, which facilitate search operations by use of search trees maintained internally to the relational database engine, are created and maintained automatically in the SYBASE relational database system. Details concerning the features and operation of the preferred SYBASE relational database software are available in the literature supplied by the manufacturer.
It will be understood that the functions carried out by the SYBASE database engine could be implemented with other types of database engines (e.g., INFORMIX.RTM., ORACLE.RTM., etc.), and could also be implemented with custom programming. The known SYBASE system is utilized in the preferred embodiment because of its known robustness, relative ease of use, and features such as clustered indexes and data communications capabilities.
In following discussion of the functions of the object broker computer 20, it will therefore be understood that the functions described, tables, indexes, etc. are implemented in the SYBASE relational database programming environment, running on the object broker computer(s).
Relationship Between Object Broker and Remote Databases
Turn next to FIG. 6 for a discussion on the relationship between the object broker 20 and the remote databases 28 maintained at the client sites 12, as well as a discussion on the method employed in the present invention for creation of objects and managing the same. As discussed in connection with FIG. 1, the object broker 20 is the central computing entity that is responsible for managing objects within the preferred embodiment of the present invention, and imposing (by virtue of its existence and limitations) a homogeneous data model upon the varying heterogeneous systems at the remote user computer sites 12. After an appropriate object model has been created for a real world system, then it falls upon the object broker to control the instances of objects within the system and the coordination of information that allows storage, retrieval, and updating of information pertaining to the objects in the system.
In order to accomplish these tasks, the object broker 20 carries out two principal functions: First, to manage a global object identifier address space and allocate ranges of address space to the various remote user computers, and second to maintain various tables that relate the location and status of information pertaining to various objects. The object broker computer 20 is programmed to carry out these two basic functions. These computing functions are not necessarily programmed in object-oriented form, but it should be understood that the programming is transparent (i.e., invisible) to the users. In other words, the users at the remote client sites 12 are not directly involved with creation of object identifiers, with global object address space allocation, or maintenance of any tables relating location or status pertaining to the various objects.
The object broker 20 includes a global address space manager module 100 whose function is to allocate object identifiers or "object ID's" from a global or galactic address space. These object identifiers are variously termed herein "global identifiers" or "GID" or "OBJID". Every instance of an object in the system is assigned a unique identifier that persists indefinitely. There is no reuse of object identifiers. Therefore, the maximum global address space allocated by the global address space manager 100 must be a sufficiently large number to accommodate the creation of millions of instances of objects over an extended period of time. In the preferred embodiment, a twelve digit (decimal) numbering system is utilized, which allows for billions of distinct objects.
The global address space manager 100 is further operative to allocate ranges of global identifiers (GID) to the various remote databases 28 at the user computer sites 12, so that each object or instance of an object created at any user computer possesses a unique object identifier. These ranges of global object identifiers are selected to be a sufficiently large range to handle the immediate computing needs of a given user computer for a predetermined period of time, say, monthly or quarterly.
The object broker 20 further maintains a global identifier range table 110 in its memory. The global identifier range table 110 manages the preassigned range of global identifiers such as GID LOW to GID HIGH, where GID LOW and GID HIGH are twelve digit numbers. Each remote database RDB 28 associated with a user computer site 12 has a range of global identifiers assigned to it, and is responsible for assigning one of the global identifiers or object ID's to an instance of an object as it is created. When a remote database exhausts its supply of GIDs, or approaches the end of the range GID HIGH, in the preferred embodiment the object broker 20 is operative to assign a new range of identifiers to the remote database 28 and communicate a message containing the new range of identifiers. |
