MXPA96002918A - Database system distribu - Google Patents

Abstract

In a distributed database system, different parts of a database are handled by each number of interconnected processors (54, 74). The different database parts contain a number of data entities (58, 66, 66 ', 93), providing for each of these data entities the global information (82) related to the processor in which the entity is located. data, and local information (79, 80, 84) related to the location of the data entity in the processor itself. The global information (82) is placed in each processor in the system in the form of global information common to and specific to each of the sets of data entities that have been previously predefined. More particularly, these sets of data entities comprise distribution entities of which each includes the information related to a number of cases of a certain type of data entities placed in a certain processor, and the information by means of which find the address towards that process

Description

"DISTRIBUTED DATABASE SYSTEM" TECHNICAL AREA The present invention relates generally to a distributed database system in which the different parts of a database are handled by each of a number of interconnected processors, the different parts of the database containing a number of data entities. data. More particularly, the invention relates to the distribution of the database by means of which it is meant, in relation to the present, the manner in which the data entities are directed and distributed in the database system. By means of data entities it is intended to convey, eg, the entities of the type object in an object-oriented system.

SITUATION OF THE TECHNIQUE In an object-oriented distributed database system, each of the included processors may need access to objects in the database itself, as well as in the database parts of other processors. For each object there is therefore information related to the subnetwork and the processor where the object exists, information about an agent in another processor that performs a desired service, eg, obtain the object, and information about it. where the object in question is placed in the memory of the processor. If all this information is available in all the processors this will result in very large address boxes, and mass updates of the address of the objects through the entire database system, when an object is created, removed or moved. EP 405,829 relates to a communication system in which the software is implemented by means of independent software components in the form of objects. A function of "runtime linker" in a "runtime system" records the objects and stores a data pointer to the data of the objects. To communicate with another object, a source object transmits a message to the runtime system. The message includes the name and identity of the method of the target object. The runtime system serves only a single processor or a group of objects and calls the target object by means of the method identity and the data indicator if the target object belongs to a group of objects served by the object. runtime system. In case a destination object is placed in another processor, the runtime system broadcasts the message to other processors. In each of the receiving processors, the runtime system searches for its "link table" for the symbolic name of the destination object of the message and, if found, calls the destination object based on the identification of the method in question. the message and information of the data indicator in the runtime linker. The interprocessor messages include a designation of the source processor of the routine system of each of the processors stores the name of the source processor and the symbolic name of the source object when a message is received on the interprocessor. A "fictitious name box" contains all the "fictitious names" of the registered local processor. If a name is not listed in the fictitious names box, an investigation is conducted with respect to the target object being placed in the linker box. If the answer is no, an investigation is carried out in a destination box and if the name of the target processor is known, a message is sent to the target processor.

In the North American Patent Number 4,901,231 a multiprocessor system is described that works through a plurality of processors. A user process in a processor can access system resources in other processors. When a user process gives access to a local file, access is made, that is, by means of a box in the user's file. When the user process gives access to a distant file, access is made through a port box, through a virtual channel identified by means of the port box to a partial process and then through the file box of the port. user and the file box of the partial process system. U.S. Patent No. 5,187,790 relates to a computer system with a plurality of processes operating simultaneously, including at least one server process and a plurality of client processes. Each process has a list of identities that represents the access rights to the object. Each object has an access checklist with identities that will be used to determine the processors that can give access to the object.

SUMMARY OF THE INVENTION A general object of the present invention is to provide a system of the kind that is defined by way of introduction, which can work with a small amount of address information to be stored, maintained and distributed. Another object of the invention is to provide a system of the class defined by way of introduction that supports simple manual configuration in an application (ie, writing and reading the program in the database (as well as in the database, and that in case of the creation of a data entity it makes an unnecessary statement as to which processor it belongs to, that is, this will be predefined Other objects of the invention are to provide a system of the kind defined by way of introduction, which supports a flexible distribution, and a change of redundancy, which guarantees the maintenance and availability of the service, that is, it must not be too many address information that must be updated in case of redundancy change In accordance with a first aspect of the invention, the The aforementioned objects have been achieved in a distributed database system where different parts of the database are handled by one of each one of interconnected processors. The different database parts include a number of data entities. For each data entity, there is global information related to which processor the data entity is placed in, and the related local information where the data entity is placed in the processor itself. The global information is placed in each processor in the system in the form of common global information specific to each of the predefined sets of data entities. According to a preferred embodiment, these sets of data entities consist of distribution entities, each containing information related to a number of cases of a specific type of data entities placed in a certain processor and the information by means of the which address can be found towards that processor. The data entities can be addressed either by means of key values or by means of identities of the data entity, the identities of the data entity containing the information related to the distribution entity to which the data entity belongs, as well as as the information that identifies the data entity. The data entity identities may include local and global data entity identities that each have two information fields. For the local identity, one of these fields identifies the processor itself and the other identifies the data entity. For the global identity, one of the fields identifies a distribution entity and the second identifies the data entity. Local information can be included in at least three tables. A first of these contains local data entity identities, a second includes identities of the global data entity, and at least one third contains key values. The global information is included in a fourth table that contains the distribution entity number, and for each distribution entity a number points to another processor. According to a second aspect, the manifested objects of the invention have been achieved with a method to provide access, in a distributed database system, belonging to a data entity to a specific class by means of a singular key value to the data entity and an identification number for the class in question. In this database system different parts of a database are handled by each of a number of interconnected processors. The different database parts contain a number of data entities of the class to which reference has been justly made above, and for each of these data entities there is overall information related to which processor is placed the data entity, and the local information related to which data entity is placed in its own processor. The search for the data entity starts in the processor itself by means of a key value. If this investigation reveals that the data entity does not exist in the same processor, the method includes the following additional steps. A logical distribution entity number is created that identifies the information related to a number of cases of the class of the data entity to which it is going to be accessed, is placed in a certain processor, and the address information related to this processor. A corresponding physical distribution entity number is created by combining the information related to the data entity class and the logical distribution identity number. The processor in the database where the searched data entity is located is identified by means of the physical distribution entity number. A message is sent to the processor in question that contains the information related to the searched data entity, and the searched data entity is searched by local search by means of the key value in the found processor. A copy of the found data entity is returned to the processor that has requested access. According to a third aspect, objects manifested in accordance with the invention are achieved, by means of a method for providing access, in a distributed database system, to a data entity corresponding to a specific class of data entities. In this database system, different parts of a database are handled by each of a number of interconnected processors. The different database parts contain a number of data entities of the class referred to above, and for each of these data entities there is overall information related to which processor the entity is placed on. of data, and the local information related to where the data entity is placed in the processor itself. An identity of the local data entity is created, which contains information related to a distribution entity which in turn includes information of the first part related to a number of cases of the class of the data entity that are placed in the own processor, as well as the information that identifies the data entity. The search on the local processor is first started in order to try to find the data entity in it by means of the local data entity.

If this search reveals that the data entity is not placed in the processor itself, the method includes the following additional steps. The identity of the local data entity becomes a global data entity identity that contains the first information related to a distribution entity. This in turn includes the information related to a number of cases of a specific class of data entities placed in a certain processor, to which the class of the data entity belongs the information related to the address to that processor. The identity of the global data entity also contains a second information identifying the data entity. A search is carried out for the processor in which the searched data entity is located by means of the distribution entity included in the identity of the global data entity. A message is sent to the processor in question where the identity of the global data entity is included, and a search is performed on the found processor by means of the identity of the global data entity. A copy of the identity of the data entity found is returned to the processor that initiated the access. According to a fourth aspect, the manifested objects are achieved, in accordance with the invention, by means of a distribution entity in a distributed database system, where the different parts of a database are handled by each one of a database. number of interconnected processors. These different database parts contain in a number of data entities. The distribution entity includes the information related to a number of cases of a specific type of data entities placed in a certain processor, and the address information with respect to this processor. According to a fifth aspect, the manifested objects are achieved, according to the invention, by means of a distribution entity in a distributed database system, where the different parts of a database are handled by each of a database. number of interconnected processors. The different database parts contain a number of data entities.

This distribution entity includes the common and specific information for a predefined set of data entities. The distribution entity in accordance with the fourth and fifth aspects may be part of an identity of the data entity that contains information related to the distribution entity and the identification of the information of the data entity. According to a sixth aspect, the invention relates to an identity entity for a data entity in a distributed database system, wherein the different parts of the database are handled by each of a number of processors interconnected. The different database parts contain a number of data entities. The identity entity includes the first information related to a distribution entity, which in turn contains information related to a number of cases of a specific type of data entities placed in a certain processor, to which the entity type belongs of data and information related to the address to that processor. The identity entity also includes a second information that identifies the data entity.

BRIEF DESCRIPTION OF THE DRAWINGS The invention and the various embodiments thereof will now be described more closely with reference to the accompanying drawings in which Figure 1 schematically shows a distributed database system, Figure 2 is intended to illustrate the principles of management in a conventional system of the kind shown in Figure 1. Figure 3 is intended to illustrate the general management principles in accordance with the invention in a database system of the kind shown in Figure 1.Figures 4 and 5 schematically illustrate the direction according to the invention in the event that a searched object is placed in the same processor or in another processor, respectively. Figures 6a ac show the content in entities of objects that are coupled in the processes shown in Figures 4 and 5, respectively. Figure 7 shows the address boxes used in relation to the processes according to Figures 4 and 5, Figure 8 shows a file in which the allocation of sequences of the distribution entities to different processors is specified, Figure 9 shows a file that shows the distribution of the distribution entities for each object class, Figure 10 illustrates the principles for loading the distribution entities into several processors by means of the information in Figures 8 and 9, Figure 11 illustrates the access of an object by means of a key in the case where the object does not exist locally in the same processor as the process to which access has been given, Figure 12 is a view of a physical identity of a distribution entity, Figure 13 schematically shows a table used in connection with and illustrating the transfer of a number from a distribution entity to a network address, Figure 14 illustrates two cases of search processes directed to a master object in another processor and oriented so as to transparently transfer a copy object of this master object to the processor itself, Figure 15 is a schematic table used to illustrate the search process in one of the cases in accordance with Figure 14. Figure 16 illustrates the transmission of the copy object after the search process according to Figure 14 which has resulted in the detection of the master object, Figure 17 shows a flow diagram that summarizes one of the cases of the search processes described with reference to Figures 11 to 16, Figure 18 shows a flow chart summarizing the second case of the search processes described with reference to Figures 11 to 16.

PREFERRED MODALITIES In Figure 1, a distributed database system is illustrated schematically, which is supposed to be the object oriented, that is, its data is organized as objects. An object, in this respect, is the retention of a quantity of data that can be read either directly or by means of call methods in the object. The concepts used below in this regard, are the object class or type, attribute, and class. An example of an object class can be objects that represent the information of telephone subscriptions. This object can then contain attributes such as the telephone number and the line circuit number. The cases of the object form different subscriptions. The system includes three subnets designated 2, 4 and 6, respectively. Sub-networks 2, 4 and 6 include four, six and eight processors, respectively, of which one in each subnet is designated 8, 10 and 12, respectively. The processors in each subnet are interconnected by means of links indicated in 14, 16 and 18, respectively, for the respective sub-networks 2, 4 and 6. The sub-networks 2, 4 and 6 are interconnected via links 20 and 22.

Each of the processors included in the distributed database system may contain, in the respective related part not shown in Figure 1, of the total database, a number of objects, which may need to be accessed by other processors. In relation to each object conventionally there is also part of the information related to the subnet and the processor where the object is placed, and part of the information related to an agent in another processor that performs a desired service, also a part of the information related to exactly where the object in question is placed in the memory of the processor. The part of information just mentioned related to the agent in another processor and in some cases will be called "communication process". The services that may be of interest in the present case are, as will be described in more detail below, obtain the object in the memory of the processor and handle the communication between the processor itself and another processor. If the total information consists of this partial information would remain available in all the processors this would result in very large address boxes and would require mass updates of the address of the objects throughout the database system. This is illustrated in Figure 2, where a part of the database system is shown, for example, the subnet 2. Each of the four processors 8 is shown schematically as containing an address box 24, which is the same for all the processors. Each address box 24 has pointers to all objects in the processor itself and in all other processors included in the database system. This is illustrated by means of some arrows 26, oriented towards some objects 28. For reasons of clarity, these arrows have been deleted for the processors placed to the right in Figure 1. Each time a new object is created, its address has to be distributed to all other processors or alternatively to register in a central catalog from where the address information can be obtained during access. This provides great flexibility with respect to the distribution of objects, but very large address frames. In Figure 2 there is also an arrow 30 oriented towards one of the address boxes 24 to indicate the introduction of a key value that identifies the object in the frame in question, destined to result in access to any of the objects included in it. the database system.

In short, the invention is based on the belief that global information, which indicates in which processor an object is placed, is common to a greater number of objects. As will be described in more detail below, this overall information is identical for all processors. For reasons of clarity it is illustrated in Figure 3, in the form of an address box, which is shown only for one of the processors at 32. The global information 32 includes the information related to a number of distribution entities of which each contains the information related to a number of cases of a certain kind of object. Figure 3 some of these distribution entities have been designated 34. For each of these distribution entities 34 is also shown in table 32 to which processor it belongs. The key value mentioned in relation to Figure 2 is transformed, indicated at 36 in an index corresponding to a certain distribution entity 34. In Table 32, therefore, for each distribution entity 34, an address indicator will be included that points or directs towards a certain processor to which the distribution entity in question belongs. A number of these direction indicators have been shown in Figure 3 at 38, 40, 42 and 44, respectively. More specifically, these indicators are oriented towards an additional frame 46 placed in each processor, from which the address indicators 48 are oriented towards objects placed in the distribution entities 34 in the corresponding sub-database base. Some of these objects are indicated as the points 50. The embodiments of the steering principle according to the invention will now be described in greater detail with reference to the following Figures. As seen from an application level, a record of the database object can be addressed in two ways, for example by means of a key or by means of an identity of the data object. In Figure 4, a user process is designated 52 and a processor is designated 54. Process 52 provides access by means of a key value of an attribute 56 of an object 58 included in the memory of processor 54. Access, indicated by an arrow 60, is carried out by a method in an object 62 of the agent created for this purpose in the process 52 of the user. In response, the object 58 returns, arrow 64, an entity of the local object stored in the attribute 56 and referencing another object 66 in the memory of the processor 54. The reference is indicated by an arrow 68. The process 22 now it opens the object 66 by means of the identity of the local object and creates a second object 70 of the agent containing a method by means of which the attributes in the object 66 can be read. In Figure 4, an identity of the object is used of This way to direct an object in the same processor. The deviation through the object 58 to reach the object 66 in Figure 4, presupposes that it is known from the beginning that a reference in the object 58 to the object 66 will be searched, and this is only an example. In data oriented to the object, the base data is usually modeled in such a way that the access requires "navigation" in the database, that is, to follow the references from object to object. The situation in Figure 5 differs from that in Figure 4 since the object to be addressed is placed in another processor 74, which is designated 66 '. In this case, a copy 66"of the object 66 'is created in the memory of the processor 54, the process 52 of the user accessing the attributes in the copy 66' ', indicated by an arrow 72', by means of of agent object 70. This will be described in more detail below. As it appeared from the foregoing, the identity of the object can be used by the application to direct objects locally or in another processor. If the object does not exist locally in the processor itself, as in Figure 5, the distributed access to the other processor will be handled transparently for the application, the so-called hidden distribution. The identity of the object will then become, by means of a logic of distribution of the database, in an identity of the global object. The identity of the object, however, can also be used by the application in its own distribution protocol, the so-called open distribution but then it will be converted first for external use by the application, more particularly towards the identity of the global object. With reference to Figure 6a, an identity of the object of the class discussed above may contain two fields, e.g., each for 32 bits. The first field identifies the distribution entity to which the object belongs, and the other field indicates a serial number that identifies the object. The identity of the distribution entity is generated by a support system outside the database system, and the serial number is assigned by object instance in an application system, that is, the programs that read and write in the database. The relationship between the externally visible name of the object and the distribution entity is determined in a design phase and then will not be changed through the duration of the application system.

In the example according to Figure 4, the identity of the object has a value, eg, of 0, in the first field to indicate that the object, that is, 66, is placed in the processor itself, and hence the denomination "identity of the local object" is used for this, see for example Figure 6b. In the case according to Figure 5, and with reference to Figure 6c, the identity of the object is transformed to a global object identity, as mentioned. As will be described in more detail, this is then accomplished by providing the first field in the object identity with a distribution entity value that can be used to find the processor to which the object belongs. Referring to Figure 7, and that described above, in relation to Figures 3 to 5, each processor includes four frames 79, 80, 82 and 84, respectively. Table 79 is the table for the key values of the identification of the object. Table 79 is used in the case in accordance with Figure 4 by process 52 to find object 58 by means of an indicator placed in the table in association with the current key value. Even though it is not shown, in fact, there may be this key table 109 for each object class in each processor.

Table 80 includes the identities of the local object pointing to the objects in the same processor, called therefore "the processor itself". In the case according to Figure 4, the database handler sees the zero in the first field and enters table 80 so that object 66 is found. Table 82 contains two columns 86 and 88, the first column 86 for a distribution entity number, and second column 88 indicating or indicating generally another processor or logically, a database handler in this other processor. In the present example, it is assumed that the second column points towards a communication port of the kind described in US Patent Application Number 08 / 193,844, which corresponds to Swedish patent application number 9300431-5, and which is associated with an activity that takes place in the second processor. U.S. Patent Application Number 08 / 193,844 is incorporated herein by reference. More particularly, and abbreviating, a communication port in accordance with the North American patent application that is hereby referred to simply as a port for reasons of simplification, is intended to imply a type of resource belonging to the communication mechanisms of a operating system and which an activity is used to establish a connection. The concept of the activity is used in the same North American Patent Application Number 08 / 193,844, in order to define a chain of works created in an operating system as a result of an external or internal independent event plus the sum of the resources used the chain during its execution. By means of a work it is still meant to imply in the application of the North American Patent in question, a phenomenon directed to a process so that a method is carried out in an object pertaining to the process, a work in this respect being able to create new works directed to other processes or to the process itself. Table 84, which corresponds to table 46 in Figure 3, contains two columns 84 'and 84' ', of which the first is for identity of the global object and the other for indicators towards a corresponding object in the memory of the processor. In the description that follows the case in accordance with Figure 5 the concept "port" for reasons of clarity, will be replaced by the associated concept of "processor" or "database manager" according to the previous explanation . In the case of accordance with Figure 5, the database handler in the processor 54 itself, speaking in general terms, in frame 82 of this processor and finds the processor 74 in accordance with the arrow 89. A message to the database handler in the other processor 74, the message, that is, containing an indicator indicating the object will be searched by means of global object identity or a key. If the identity of the global object is known, which is presupposed in Figure 5, the database handler in the processor 74 continues the search process in accordance with the arrow 90 entering with the identity of the global object in column 84 ' for global object identities in frame 84 of processor 74. In the same line where the identity of the global object is found in frame 84, but in another column 84 '', the pointer to object 66 'is found , in accordance with arrow 92. Alternatively, if the indicator indicates that the search can be done by means of a key, such as in the case where there is no identity of the overall object, the database handler in the processor 74 directs the search process according to arrow 94 to frame 79 of processor 74. By means of the key value of object 93 searched for, the address of this object is found therein, according to arrow 95. If, in a case of conformity d with Figure 5, there are additional objects in the processor memory 74 that belong to the same distribution entity, ie, objects with the same number of the distribution entity, but with a different serial number, the process is transferred to the processor 74. Referring to Figures 8 to 18, two practical embodiments will now be described where the use of tables 79, 80, 82, 84 will also appear in greater detail. In the description of the object class that is given then a persistent object class is specified in a language used to describe other object classes, eg, DÉLOS, which is mentioned in the Tele journal, number 4/93, in an article called "Development of software" by Gote Andersson. More particularly, there is the question of an object of the Subscriber class that contains 2 attributes, of which one is a primary key, that is, a distribution attribute. TYPE OF OBJECT the Subscriber IS PRIMARY KEY PERSISTENT PROPERTIES subscrNu; -MDP - sequence 0..logicalMDPhigh ATTRIBUTES subscrNum: Subscriber Number; iAge: Integer FIN; TYPE Subscriber-the Number ES SARTA (IS08859) FIN; In this representation, the first line defines the object class, that is, the Subscriber. The next line indicates the storage properties. Then follows a manifestation of the attribute name KEY PRIMARY, that is, subscrum. In the definition -MDP-sequence 0 - logicalMDPelevated MDP (Division of Master Data) represents distribution entity. The definition is information related to the maximum distribution capacity of the object class, that is, the maximum number of distribution entities of the object class in question. The information in question is used to generate an input data to the configuration step described more closely below, and to allow the system to be able to verify at runtime that the keyToMDP function, which is also described more closely below , do not return to values outside the declared scale. In the first line under ATRIBUTOS it is shown that subscrNum is of the type of the Subscriber Number, and in the second line that the subscrNum method with the name iAge is of the Integer type. In both cases, there is the question of predefined types.

In the last line in the representation is defined more closely with "IS STRING" a property of the attribute type Subscriber Number, for example, that the attribute is indicated as a string of digits. From the aforementioned object class description, as well as from the following similar description of the methods in association with the object class, a code is generated in a specific data definition language by a compiler for this language. The following description, as well as the foregoing description, is based as an example on the use of agent objects of the kind described in US Patent Application Number 08 / 264,059, which corresponds to Swedish Patent Application Number 9302175-6 for achieve data access in case of using the address method according to the invention. The aforementioned North American patent application number 08 / 264,059 is hereby incorporated by reference. In this North American patent application the generation of the code is also described in the manner indicated herein, and therefore, a more detailed description is not required. The object of the agent in question is called DOA in the same North American patent application that represents "Agent of the Data Object" and will sometimes be used in the same name herein.

In a method to transform the key value to the distribution entity, the framework of the method is generated by LETTERS but the application designer must write the way in which the key will be translated into a number of the distribution entity, the algorithm is part of the DOA class and depends on the class of the directed object. In the present case it is assumed that the primary key = the telephone number 1111122. The method in s * - question is carried out by: 10 DisksDbMDP Subscriber: keyToMdp (key) where KeyToMdp is a so-called transformation function to be described more thoroughly below. 15 In the present example it is assumed that the last two significant figures 22 are masked with a value scale of 00 - > 99. The value masked, therefore becomes a number 22 of the distribution entity. 20 The method is used by both creating (case) and opening (case), that is, creating and opening cases respectively. For access, that is, reading or writing on an object, a local copy of the object is installed, for example, 66 '' in Figure 5 and the execution processor as it has appeared from the foregoing description with reference to Figure 5. In this regard reference is made to two types of copies, eg "lazy" copies and copies "agile" The fault, which can always be used is "lazy" implying that the object is obtained in relation to access. The "agile" copies are configured in advance and the agile duplication unit is a complete distribution entity. To assign the installation configuration, the assignment of master data and agile copies will be made to a desired processor. This is carried out for each distribution entity stating that a sequence of master or agile distribution entities will be assigned to a processor and a group of processors respectively, that is, a system of more processors in a distributed database system. This is specified in a file that has the appearance shown in Figure 8. In Figure 8, the first column indicates in master- or agile- MDP. The second column indicates a physical MDP sequence, the two subcolumns in the second column indicate the object class and MDP-No. v.gr., in the first line, 9914 is a number of the object class that identifies the class of the object and 0 and 49 indicate the distribution entity number, that is, it indicates that there is the question of fifty entities of distribution of an object class that has the class number 9914. The last column indicates the processor in which the master or agile distribution entity in question will be installed. In addition, information is required about the distribution entity distribution for each object class as the input data to a load module that will be loaded into the system. By the concept of loading module it is intended here to be the same as the aforementioned North American patent application number 08 / 264,059. The distribution of the distribution entity in question is specified in a file that has the appearance shown in Figure 9, the file obtaining its values from Figure 8. In Figure 9, the first column indicates the name of the object class (objectType) and the second column indicates the number of the object class (dbClassId). From the third column, the number of distribution entities for the object class (logicalMDPhigh) appears, beginning with the numbering of the distribution entities with 0. Both object classes are not limited with respect to the number of objects that can be created but the The table shows that the number of distribution entities, that is, the maximum number of processors to which the objects can be distributed, is 100 for the Subscriber and 10 for Lie. Figures 8 and 9 include the configuration data with the allocation information of the distribution entity for all object classes. This information will be uploaded to all the processors in the local databases. More particularly, the allocation information of the distribution entity will be loaded by means of the base data to the class object by means of an initiation function in the database during the base load phase. Therefore, this is included in the basic functionality. Figure 10 is intended to illustrate the manner in which this charge physically appears. For reasons of simplification, there are only two processors included in Figure 8 shown, for example, processors 4 and 2, that is, lines 1 and 3 in Figure 8. More particularly, the manner in which the entities of distribution 100 for the subscriber object class are loaded into processors # 4 and # 2, which are included in each sub-database base 102 and 104, respectively. In the processor memory # 4, the master distribution entities 106 within the sequence 0 - >; 49 are loaded, while in the processor memory # 2, the agile distribution entities 108 within the sequence 0 - > 33 are loaded. The object class defined above is installed in a database via Null Subscriber: install ("1111122") Object Class, eg, is created by subx = Subscriber:: create ("1111122") . The class of object that will therefore remain to the distribution entity 22 as it appears from the foregoing is initiated in the memory of the processor # 4 according to the allocation of the distribution entity to the processors. The key is transformed according to the aforementioned to a distribution entity er in accordance with an algorithm. The algorithm is a function that takes the primary key data type as an input parameter and returns to an integer between 0 and logicalMDPhigh. The function must distribute the possible key values uniformly towards the distribution entities that have been identified, but it remains for the designer of the object class to select an appropriate algorithm taking into consideration the design itself. The object is opened to be updated by subx = Subscriber :: openUpdate ("1111122") The database will handle the transparently distributed access for the application through the database managers, the so-called hidden distribution as mentioned above . The search for an object in a distributed database system starts first in the local processor in order to try to find the current master object by means of frame 79 or 80 in Figure 7 depending on whether the search is carried out by means of of a key or the identity of the local object. Figure 11 illustrates in greater detail the way in which the object is accessed by means of a key if the object is not present locally in the same processor as the access process. More particularly, the process indicated at 110 which is carried out in another processor searches, arrows 112, in a local key box 114 corresponding to the key box 79 in Figure 7, in a database 116 of sub-data with a processor 118 The database database manager 116 calls the transformation function keyToMdp (key) using the above-mentioned DOA method Subscriber:: keyToMDP (key), arrow 120, using the key as the parameter provided by an MDP Not logical Then, an MDP-No is created. physical by combining the class er of the class and the non-logical MDP according to Figure 12. This non-physical MDP forms the first field of the identity of the global object, for example, Figure 6c. Then, the processor to which the distribution entity belongs is searched in box 82, for example, in Figure 7. Then, a message is sent to the processor where the object is present or actually to the port that has been published by the process of the database manager in this processor. The message includes the object class and the primary key since the distribution entity er is not sufficient to uniquely identify. It also appears through the message that is intended to be carried out with the object in order to be able to establish a read or write closure if necessary. In the present case, a writing closing is established. The identity of the distribution entity is used to find a network address by means of internal database tables that are distributed on all processors in a distributed database system. The principle of these tables is shown schematically in Figure 13 without claiming that there is a coincidence with reality. In a real embodiment, the frames are more compressed. In accordance with Figure 13, these frames in each processor consist of a search box 130 and a second box corresponding to box 82 in Figure 7. The search box 130 includes a line for each object class where it is displayed the er of the object class. Table 82 includes a line for each distribution entity installed, extending the line through three columns. Each line indicates in the first column a er of the object class, in the second column a distribution entity number and in the third column a port name to an object. More particularly, it appears from the second table that for the object class number myClass id there are 102 distribution entities with associated identification of the port name to an object. Having knowledge of the class number of the object sought for the distribution handler in the process itself, start, arrow 132, a search in frame 130 until the object class number myClass id in question has been found after a process of search indicated by arrows 134. This in turn leads, according to an indicator 136, to the set of object class numbers myClass id in table 82, where it is assumed that a search indicated by an arrow 138 leads to the Distribution entity Number 100. According to the arrow 140, this finally results in the address of the current processor where the object being searched is present. Figures 14 and 16 illustrate in more detail the transparent distribution of the class that has been briefly described with reference to Figures 7, 11 and 13. The situation in Figure 14, begins with the assumption that the distribution handler in the processor from which the distribution has been initiated has carried out a search process of either the class using a global object identity or the class using a key, and where it has been described above with reference to Figure 13, this having been indicated with MDP100 + myKey on the arrow 142. In the processor, designated 150, an interface agent 152 is created by the distribution handler designated 154 in the data base 156 including the processor 150. The message it is packed in an export format that is then sent, arrow 158, to the other processor, designated 160, which in a base 162 of corresponding sub-data contains a master object which has been searched. When the message arrives at the data base 162 it is received by the interface agent 168 created by its distribution handler 166. When the communication process that will handle the distributed communication between the processors has been activated, the message will be unpacked if a local search for the object is carried out. If the message contains the identity of the global object, the search is carried out according to arrows 170 and 172 through frame 174 of database 162. Table 174 corresponds to box 84 in Figure 7, the arrows 170, 172 indicating the same process as arrow 90 in Figure 7. The found object is shown in 175. The alternative search process in processor 160 with the object class number and the primary key in the case in the which the global identity of the object sought is not known, is illustrated by the tables in Figure 15. As in the case with Figure 13 only the principle is shown schematically in Figure 15 for the use of these tables without claiming that there is a coincidence with reality. In a real implementation the tables here are also more compressed. The tables according to Figure 15 are included in each processor and consist in accordance with the Figure of a search box 180 and a second box corresponding to the box 79 in Figure 7. The table 180 includes a line for each class of object, the number of the object class indicated in this line. Table 79 includes a line for each key that is installed, extending to the lines through three columns. Each line indicates in the first column, the number of the object class, in the second key column in the third column includes an indicator towards the database object. As illustrated in Figure 15, the database handler in processor number 4 carries an average search process of the class number of the object through myClass Id of the object being searched., which starts according to arrow 182 in frame 180, through arrows 184 leads to the number of object class myClass Id in question, and through an arrow 186 leads to the object set with class number myClass Finally it is found, searching in accordance with the arrows 188, a key the Primary Key with an indicator 190 associated with the object sought. The frames according to Figure 15 are also shown schematically in Figure 14 as a block 79. The situation in Figure 14 starts with the assumption that the distribution handler in the sub-database base 156 from where the distribution was started , by means of tables 130, 82, has carried out a search process of a class similar to that previously described with reference to Figure 13. As previously has been created in the own processor 150, an interface agent 152 through the distribution handler 154 in the subdata base 156 of the processor 150. The message is packaged in an export format which then according to the arrow 158 is sent to the other processor 160, the data base 162 of which contains the object searched master is designated 192. When the message arrives at the subdata base 162, it is received by the interface agent 168. When the communication process has been activated which will handle the distributed communication between the processors, the message will be unpacked and a local search for the object, in accordance with the search process described above with reference to Figure 15, will be carried out by means of tables 182 and 79 of the database 162. When the master object 175 or 192, respectively, has been found, a write lock is placed therein. The write closure must be obtained from the database manager in the processor 160 that contains the master object, since the allocation of the closure in another processor is carried out automatically by the distribution manager in the database. Simultaneously, with reference to Figure 16, a lazy copy object 200, arrow 202 will be returned to the database 156 containing the processor 150 where the search transaction was started, see also 66"in Figure 5 At 204 on processor 150, the process is shown, which started access. The processes described above with reference to Figures 11 to 16 for the transparent distribution now, for reasons of clarity will be summarized by means of the flow charts shown in Figures 17 and 18. In Figure 17 the search for the object is initiated by means of the most key class number, step 250. The search is first carried out in the local processor to try to find in it the current master object. This is carried out in the local key table 79, for example, Figure 7, by means of the key. If it is found in step 252 that the object is placed in the same processor, the process continues according to arrow 253 to the final step in Figure 17 which will be described more thoroughly below. If it is found in step 252 that the object can not be found in the same processor, in accordance with what is described with reference to Figure 11, in step 254, a logical distribution entity is created by means of the function of transformation keyToMDP (key) and in step 256 a physical distribution entity by combining the number of the object class and the logical distribution entity according to Figure 12. Then, in step 258, a search for the identity of the port towards the database process, in the processor, in the database of sub-data in which the searched object is placed. More particularly, this is carried out by searching through the frames in accordance with Figure 13. In step 260 a message was sent to the port in question. In the message, the class and key number are included since the entity number of the distribution is sufficient to identify the object in a unique way. The message also appears what will be done with the object in order to be able to place a reading or writing closure as necessary. After the searched object was found by local search in box 79 in Figure 14 of the found processor, an object of the copy is returned in step 262 to the processor that access has been initiated, for example, that described with reference to Figure 16, and installed therein. In step 264, finally, the database agent DOA is created in accordance with what is described in the North American Patent Application Number 08 / 264,059 and is returned to the application process. In Figure 18, the search for the object is started by means of the identity of the object, step 266. The search is carried out first in the local processor to try to find in it the current master object by means of the identity of the local object and the local box 80, for example in Figure 7. If it is found in step 268, that the object is present locally, the process continues directly to the last step in Figure 18 according to arrow 269. If it is found in step 268 that the object is not in the same processor, the identity of the local object through the application becomes an identity of the global object in step 270 in accordance with what is described above in connection with Figure 5. Then, a port identity is searched in step 272 for the database process in the processor, in the sub-bed base from which the searched object is placed. More particularly, this is carried out by searching by means of the number of the distribution entity in Table 82 in Figure 7, which includes the identity of the overall object. In step 274 a message is sent to the port in question. The identity of the global object is included in the message. It also seems to be from the message what must be done with the object in order to be able to place a reading or writing closure as necessary. After the searched object has been found by local search in frame 174 in Figure 14 of the found processor, an object of the copy is returned in step 276 to the processor that initiated the access, for example, that described with reference to the Figure 16, and installed in it. In step 278 finally, a DOA agent of the database object is created and returned to the application process.

Claims (12)

CLAIMS:

1. A distributed database system, which includes a database, and a number of interconnected processors to handle different parts of the database, the parts of the database include a number of data entities, each entity data has in association with it the global information related to which processor is placed the data entity, and local information about where the data entity is placed in the processor itself, the global information is placed on each processor in the system in the form of common and specific global information for each of the predefined games of the data entities.

A system according to claim 1, characterized in that the data entity sets consist of distribution entities, each containing information related to a number of cases of a specific type of data entities placed in a certain processor , and the information by means of which the address of that processor can be found.

3. A system according to claim 2, characterized in that the data entities are dirigible either by means of key values or by means of data entity entities that contain the information related to the distribution entity, which belongs the data entity, as well as the information that identifies the data entity.

4. A system according to claim 3, characterized in that the identities of the data entity include identities of the local and global data identity, each identity of the local data entity includes a first information field identifying the processor itself and a second information field identifying the data entity, and each global data entity identity includes a first information field that identifies a distribution entity and a second information field that identifies the data entity.

5. A system according to claim 4, characterized in that the local information is contained in at least three tables, of which a first table contains the identities of the local data entity, a second table includes the identities of the entity of global data, and at least a third table contains the key values, the global information is contained in a fourth table that contains the numbers of the distribution entity and for each distribution entity the numbers point to another processor.

6. In a distributed database system, including a database and a number of interconnected processors to handle different parts of the database, the database shares include a number of data entities, each data entity it has in association with it the global information related to which processor the data entity is placed in, and the related local information where the data entity is placed in the processor itself, a method to give access to a data entity that belongs to a specific class, by means of a singular key value to the data entity and an identification number for the class in question, which comprises starting the search for the data entity first in the processor itself by means of the key value, if this search reveals that the data entity does not exist in the same processor, create a number of logical distribution entities that identify the information related to a number of cases of the class of the data entity, which are placed in a certain processor and direct the information related to this processor, create a corresponding physical distribution entity number combining the information related to the class of the data entity and the logical distribution entity number, identify the processor in the database where it is located placed the searched data entity, by means of the physical distribution entity number, send a message to the processor in question that contains the information related to the searched data entity, search locally on the processor found by means of the key value, the data entity to which it is will give access, return a copy of the data entity found to the processor that has requested access.

7. In a distributed database system, which includes a database, and a number of interconnected processors to handle the different parts of the database, the parts of the database include a number of data entities, each data entity has in association with it the global information related to which processor the data entity is placed in, and the local information regarding which data entity is placed in the processor itself, a method to give access to the entity data belonging to a specific class of data entities, comprising, creating an identity of the local data entity containing the information regarding a distribution entity which in turn includes the information with respect to a number of cases of the kind of data entity that are placed in the processor itself, as well as the information that identifies the data entity, start the search in the loc processor in order to try to find the data entity in it by means of the local data identity, and if this search reveals that the data entity is not placed in its own processor, convert the identity of the local data entity in a global data entity identity that contains information related to a distribution entity that in turn includes information related to a number of cases of a specific class of data entities placed in a certain processor, the data entity to which Access will be given belongs to the aforementioned class, and information related to the address to the certain processor, the information that identifies the data entity to which access will be given, the search of the processor in which the access will be given. data entity is placed by means of the distribution entity included in the identity of the global data entity, send a message to the processor in question where i ncludes the identity of the global data entity, find the identity of the data entity in the found processor by means of the identity of the global data entity, return a copy of the identity of the data entity found in the processor that has started the access.

8. A distribution entity in a distributed database system, where the different parts of the database are handled by each of a number of interconnected processors, the different database parts contain a number of entities of data, the distribution entity includes the information related to a number of cases of a specific type of data entities placed in a certain processor, and the address information related to the processor.

9. A distribution entity according to claim 8, characterized in that it forms part of an identity of the data entity that contains the information related to the distribution entity as well as the information that identifies the data entity. lÜ.

A distribution entity in a distributed database system in which different parts of a database are handled by each of a number of interconnected processors, the different database parts include a number of data identities, the Distribution entity contains the common and specific information for a predefined set of data entities.

11. A distribution entity according to claim 10, characterized in that it forms part of an identity of the data entity that contains information related to the distribution entity and the information that identifies the data entity.

12. The identity entity for a data entity in a distributed database system, where the different parts of the database are handled by each of a number of interconnected processors, the different database parts contains a number of data entities, including the identity entity: information related to a distribution entity, which in turn contains information related to a number of cases of a specific type of data entities placed in a certain processor to which the entity belongs. type of data entity, and information related to the address to that processor. the information identifies the data entity.