MXPA97006023A - A method and apparatus for building a telecommunication network database - Google Patents
A method and apparatus for building a telecommunication network databaseInfo
- Publication number
- MXPA97006023A MXPA97006023A MXPA/A/1997/006023A MX9706023A MXPA97006023A MX PA97006023 A MXPA97006023 A MX PA97006023A MX 9706023 A MX9706023 A MX 9706023A MX PA97006023 A MXPA97006023 A MX PA97006023A
- Authority
- MX
- Mexico
- Prior art keywords
- database
- data
- rules
- objects
- network
- Prior art date
Links
- 230000000875 corresponding Effects 0.000 claims description 2
- 238000000034 method Methods 0.000 description 18
- 206010024855 Loss of consciousness Diseases 0.000 description 16
- 238000010276 construction Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 210000002356 Skeleton Anatomy 0.000 description 1
- 230000037113 Vdu Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000000135 prohibitive Effects 0.000 description 1
- 238000000547 structure data Methods 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
- 230000001702 transmitter Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Abstract
The present invention relates to a method and an apparatus for building a telecommunications network database (43) from an existing network database (34). In the method, the existing network database is processed to extract data that is then stored in an intermediate database (41). The intermediate database (41) has a structure that is different from the structure of the existing network database. The intermediate network database is then processed to produce a final database (43) that can be used in a network control system. Less processing efforts are required to produce an intermediate database (43) and then derive from it the final database (43), which for the case of the final database (43) derived directly from the database, exists
Description
A METHOD AND APPARATUS FOR BUILDING A TELECOMMUNICATIONS NETWORK DATABASE
DESCRIPTION OF THE INVENTION
This invention relates to a method and apparatus for building a telecommunications network database. Telecommunications networks are controlled by network control systems that decide the way in which the network is configured and monitor the performance of network components. The control function is carried out by reference to the information concerning the network stored in an associated network database. The information that is stored may include an identity of a particular item of equipment such as its serial number, model and manufacturer's information, and details of a person or organization responsible for repair failures on that equipment. Therefore, if a failure occurs with that piece of equipment, a network control will be available to quickly send a request for repair. Other information that is stored is the information about the performance of the equipment that will be used when making decisions about the configuration of the network.
When it is thought that it is desirable to replace the control system of the existing network, a problem occurs because a system that is compatible with the existing database has to be chosen. The reason for this is that the database can include information about a very large number of items on the team. Typically, information from thousands of circuits will be maintained. It has been perceived that to do otherwise would require building a new database from the beginning, which is compatible with the new network control system. The time to do so has been prohibitive, requiring about two hours for two typical telecommunication circuits to enter a database. The present invention arose from the inventors' perception that it was not necessary to build a new compatible database from the beginning, but that it is possible to use the existing database. In U.S. Patent 4,908,759, a process for transforming a hierarchical entry database to create a hierarchical output database is described. The process occurs in two stages. In the first stage, the intermediate data is produced. In the second stage, the intermediate data is projected to the required form by means of the output database.
According to a first aspect of the present invention, there is provided a method for constructing a final telecommunications network database in a memory of a computer system by storing the data arranged according to a first structure, such data being extracted from an existing database having the data arranged to a second structure different from the first structure, the method comprising the steps of: creating an intermediate database in which the data can be stored in a third structure different from the first and second structures; enter a first set of rules in memory, the first set of rules specifying a set of object classes to be used in the intermediate database and how to create and populate the objects of each class in the intermediate database from of the data stored in the existing database; create in the memory a model, through the use of such classes, of the object hierarchy to be used in the intermediate database; enter a second set of rules that specify how the objects in the final database are created and populated from the objects in the intermediate database;
use the first set of rules to create and populate the objects in the intermediate database from the data stored in the existing database; and use the second set of rules to create and populate the objects in the final database from the objects stored in the intermediate database. When creating and populating an intermediate database with data that is not arranged according to the first structure, less processing effort is required to build the telecommunications network database by selecting data from the intermediate database, that if attempts were made to directly restructure the existing database or assemble the data from another source. A further advantage of the invention is that most of the complexity in the construction of the final network database is involved when creating and populating the intermediate database from the existing database. Once the intermediate database is created and populated, it is relatively easy to populate the final network database later. If the required form of the final network database changes it is then relatively easy to change the rules to populate the final database to verify the change. This can be achieved without having to change the way in which the intermediate database is created and populated. Because the creation and population of the intermediate database is the most complex part of the method, a considerable amount of work is saved. The existing database can be a database of an existing network control system or a database different from a network control system, for example, a database maintained on a computer to which it is accessed by personnel who configures the network manually. By means of the structure, it means a logical structure rather than a physical one in which the data is organized in the database. In the preferred embodiment described, the first structure is arranged to support an object-oriented program used to control the network. The information about the objects is stored in the database in a structure that allows the objects to be concretely exemplified. The phrase exemplify concretely, means that the objects can be reconstructed from the stored information. A specific embodiment of the invention will now be described, by way of example only, with reference to the drawings in which: Figure 1 schematically shows the apparatus according to an embodiment of the invention; Figure 2 shows in schematic block diagram form part of the apparatus shown in Figure 1;
Figures 3 and 4 show in schematic block diagram form part of the databases used in the apparatus; Figure 5 is an explanatory flow chart; Figures 6 and 7 show models used in the preparation of an intermediate database of the invention; and Figures 8 and 9 show schematically data structures used in the invention; and Figures 10 to 14 are explanatory flow charts. Referring to Figure 1, an apparatus operating in accordance with the invention comprises two computer work stations 1, 2 conforming to the Sun Sparc architecture, for example, the workstations available from Sun Microsystems Corporation and a network 3 telecommunications. Workstations 1, 2 are based on Unix and are networked together with file servers to form a homogeneous network. It will be readily appreciated that in a Unix-based system that memory is distributed over the system. However, for the purposes of this description, the memory will be described with reference to the particular terminals. Actually the databases stored on the system can be stored on a number of terminals.
The telecommunications network 3 is of a known type comprising private branch exchanges (PBX), local area networks, wide area networks, transmission paths, bridges and guiadores. As shown in Figure 2, workstation 1 includes a central processor 21, memory 22 and input and output ports 23 joined by data transmitters in the normal manner. The memory 22 is in the form of a hard disk drive device (not shown) and stores the instructions 33 of the processor and a network database 34 as shown in FIG. 3. The instructions 33 of the processor comprise a plurality of machine code entries maintained in the memory locations on the disk. The central processor 21 operates in accordance with the instructions 33 of the processor and the network database 34 stores information about the elements forming the network 3. The work station 1 operates as a network control, monitoring and controlling the network 3. The information about the network 3 is received by the network control together with the communication path 4 and through the input-output ports 23. The instructions are sent by the network control to network 3 through the same route.
The network control receives information about the network 3 and also passes instructions to the network 3 along the communication path 4. The instructions will include, for example, network configuration instructions. Workstation 2 is nominally identical to work station 1, but it is programmed with a different network control program with respect to the first one. While the hardware components of the workstation 2 are identical to those shown in Figure 2, it has a memory 40 configured, as shown in Figure 4, to maintain an intermediate database 41, an instruction memory 42 processor and a memory 43 located for a final database. The memory 40 is also configured to maintain a rule database 44. The rule database 44 is initially empty, but is used to store rules stored by a user at a later stage. A network authority wants to transfer control of the network from workstation 1 to workstation 2. So that workstation 2 that controls network 3 will require access to the information database about the network . However, the database must be compatible with the control program of the operating network. In this specific modality, the network control program operated by workstation 2 is called "ServiceView" available from British Telecommunications foot of 81 Newgate Street, LONDON. The program is stored in the processor instruction memory 42. "ServiceView" is an object-oriented program and therefore requires a database that has a structure that supports an object-oriented program. In such a program the objects of real life, that is, the components of the network 3, are modeled by the software objects that have attribute. The database will contain data about the attributes of the corresponding real-life object. The data is structured in a compatible database in such a way that the objects can be specifically exemplified from the data. The database 34 of the existing network maintained in the memory of workstation 1 is not compatible with the program "ServiceView" and can not be used directly via workstation 2. However, the data maintained in the database Existing data 34 can be used to build a new compatible database in the following way. The processor instruction memory 42 stores a database construction tool in addition to the aforementioned "ServiceView" program. The database building tool is a program to build the new compatible database from the existing network database 34. An overview of the operation of the database construction tool will be given first with reference to Figure 5. A preliminary stage, stage 49, is for the network authority to enter between two sets of rules. The first set of rules will be applied to the existing network database 34, while the second set of rules will be applied to the intermediate database 42 once it has been generated. The first set of rules enters through the network authority relative to the classes of a model that will be entered later. You can consider that the rules enter the model classes, since they will specify how the objects are created from each class. The first and second sets of rules are entered by the central processor of workstation 2 in the rules database 44 of memory 40, step 49. The second set of rules will be changed relatively infrequently because the The relationship between the intermediate database 41 and the final database 43 is fairly constant and these rules can be used in subsequent database conversion operations. An option to redefine the rules can be offered to the user after the first set of rules has been entered into the classes of the model created in a subsequent stage.
The next step is to make the database building tool functional by the network authority that is entering an appropriate command to the work station 2. This stage is represented by step 50 in Figure 5. The user models after the hierarchy of the object to be used in the intermediate database, stage 50a. At this stage the user models a skeleton object hierarchy on the screen of workstation 2 using a modeling program. The program allows the user to draw on the screen a series of hierarchically interleaved nodes. The nodes represent classes in the model that they use to generate objects afterwards. The processor 21 of the second work station 2 then applies the first set of rules to the existing network database 34, box 53. This results in important items of data being copied and used to populate the database 41 intermediate, with objects, their attributes and values, step 54. The intermediate database is then stored on the disk as represented by step 54a. The processor 21 of the second workstation 2 then applies the second set of rules to the intermediate database 41, as represented by step 53. This structures the extracted data in the final compatible database in the memory 43. The final database is then downloaded onto the disk, as represented by step 56. The database construction tool program ends later, step 58 and the network authority operates stage 59"ServiceView" to control the network 3. Workstation 1 can be disconnected after network 3 or used for some other function. The modeling of the 50th stage of the object hierarchy will now be described in greater detail. The network authority will initiate the modeling program. This allows the network authority to draw on the workstation 2 screen a model of the network using the keyboard and mouse associated with the workstation. Figure 6 shows, schematically, the representation of data. The modeling program has options to allow a model node to be created and additional nodes to be created depending on this node. Therefore, a first node or root node 100 called NETWORK is created on which nodes 101, 102 and 103 depend. Each node represents a class of objects: node 101 represents objects that fall within class 1; node 102 represents objects that enter class 2; and node 103 represents objects that enter class 3. Each class can be drawn as a super-node that has one or more sub-nodes. As shown in Figure 6; class 1 is drawn having three sub-nodes 104, 105, 106; class 2 is drawn having these sub-nodes 107, 108, 109; class 3 is drawn having three sub-nodes 110, 111, 112. As the network is modeled, the network authority enters the rules of the first set of rules in each of the classes. The rules are extracted from the rules database 44. Therefore, when the node 101 has been drawn, the network authority enters a rule that will be used to select the data for inclusion in the objects of that class, that is, class 1. Similarly, they are provided the sub-nodes with rules to select the appropriate data. The rules are called ITEMSPEC1 to ITEMSPEC9. The rules can also have sub-rules. In this specific embodiment, the modeled hierarchy is shown in Figure 7. It can be seen that the root node 100 is called NETWORK which has two sub-nodes, a first node 101 called CIRCUIT and a second node 102 called EQUIPMENT. Therefore, there are three classes of objects that can be classified as NETWORK, CIRCUIT and EQUIPMENT. The sub-nodes 104, 107 of CIRCUIT 101 and EQUIPMENT 102 have entered in them the item specification rules ITEMSPEC1 = "EQ * M and ITEMSPEC4 =" EQ *. "These rules will match any string beginning with" EQ "., the character "*" means any text that can follow "EQ". It should be emphasized here that the model shows the nodes and sub-nodes that match the classes and sub-classes of objects that comprise network 3. Although only five nodes are shown in Figure 7, there will be many more than five objects that fall within of the classes, that is, the data maintained in the existing database 34 when subjected to the rules written in the classes will usually generate more than one object per class. The form of the first set of rules entered and stored in step 49 will be evident in the following description of the subsequent step 53 of application of rules to the network database and step 54, that of setting the objects on the base of 41 intermediate data. A more detailed explanation of stages 49 and 53 to 56 will now be given. The rules to be applied will depend on the nature of the existing network database and the configuration of the new database. The network authority will be aware of the way in which the existing network database is configured. In the specific mode the existing database 34 is configured to maintain the data as a series of records as shown in Figure 8. The records are arranged in the form of a card file, each record being a card in the file . In Figure 8 only four registers 61, 62, 63 and 64 are illustrated, although in practice there are many more than those shown. The database also includes a set of records 73, 74 of responsible person that will be described later. Each register 61, 62, 63 and 64 has the same format as nine data fields 65 to 72. The data field 65 contains data that the record marks. In the case of registration 61, this mark is "RECORD
1. "Other registers 62, 63 and 64 will be consecutively marked" RECORD 2"," RECORD 3"," RECORD 4"and so on.Data fields 66, 69, 71 and 72 contain data that are only relevant to the existing network database 34 and will not be used to construct the new final object-oriented database 43. The data is represented in the figure as "ZZZ", "PQRST", "XXX" and "YYY". 67 contains a mark for the particular component of the network 3 to which the register refers. For "RECORD 1" this is "CCT123" which is a circuit on the network 3. The data field 68 contains information about the location of the component In this case the entry is "LOC = GOWER" which means that the circuit is located in an establishment on Gower Street The data field 70 contains information about the type of equipment to which the register refers. case the equipment is of type "EQ1." Figure 9 shows "RECORD 2" and will be easily observed that is of the same format as "RECORD 1" and therefore the data fields are numbered in the same way as for "RECORD 1". The data fields differ, however, because in this case the equipment is of the "EQ2" type, the equipment brand is "CCT234" and the record is marked "RECORD 2". The location again is Gower Street for the data field 68 which has the entry "LOC = GOWER". The remaining data fields 66, 69, 71 and 72 have the same entries as "RECORD 1". The network database 34 also includes a set of records 73 and 74 of responsible person. These records store information about the equipment items, in particular, the name of an individual or organization responsible for the maintenance of the equipment. Each register 73, 74 has a data field 75 of the type of equipment containing a descriptor of the type of equipment. In the case of register 73, the descriptor is "EQ1" which means equipment of type 1. In the case of record 74 it is "EQ2" which means equipment of type 2.
A data field 76 of responsible person is also provided on each record 73, 74. This contains a name of a person responsible for the maintenance of that particular type of equipment. For the record 73 the data field 76 contains the name "F. JONES" and for the record 74 the data field 76 contains the name "S. SMITH". Therefore, for the maintenance of the equipment of type EQ1, F. JONES is going to be contacted while for the equipment of type EQ2, S. SMITH must be contacted. A screen warning is dised on a VDU visual dis unit of workstation 2 and the network authority then enters a first set of rules that will extract the relevant data from registers 61, 62, 63 and 64 and of records 73 and 74 of responsible person. The rules being entered in the model nodes as described in the above. In summary, this modality has two data files, one that contains the circuit records and another that contains the responsible persons. The data files are presented in tabular form below.
File 1 Field Camp Field Field 67 Work 68 Job 70
Record 61 CCT123 LOC = GOWER EQ1 Record 62 CCT234 LOC = GOWER EQ2 Record 63 CCT345 LOC = IPSWICH EQ1
Record 64 CCT456 LOC = GLASGOW EQ2 File 2 Field of Work Field 75 Work 76 Record 73 EQ1 F. JONES Record 74 EQ2 S. SMITH
With the knowledge of this structure, the authority of the network formulates two sets of rules. The rules modalize a method for treating the existing database to extract the required data and to order it as the intermediate database 41. Before describing the first set of rules in detail, a general overview will be given with reference to the exatory diagrams shown in figures 10 to 13. The first process modalized in the rules is a first step through the data in file 1 in order to create the objects. The first stage in this step is a correspondence stage, represented by box 110. The matching step involves examining a string in a data field of a record in the database against a pattern in the templates of the model object. In this case, the data field 70 is examined. The next step is to consider whether the comparison test and the object template are of the class equipment, as represented by box 111. If this is the case then the name of the object is fixed to that of the string stored in the field of data 70, as represented by box 112. If the comparison test and the object template is not of the class equipment then it is considered if they are from the class circuit, as represented by box 113. If the test by The comparison and the template of the object are of the class equipment, then the name of the object is fixed to the string maintained in the data field 67, as represented by the box 118. The next stage after those represented by the boxes 112, 113 is to consider if a new object is involved, that is, the object has not been created after processing a previous record. This stage is represented by box 114. If the object is a new object then it is created as represented by box 115. The next stage after the creation of an object or a decision that the object is not new is to populate the object with the data following a procedure represented by box 116. If there are more records then the process described above is repeated from the correspondence stage represented by box 110. The population process extracts some data from the records and stores them in the objects created in the previous stages. The first step in this process is to select a created object, as represented by box 120 in Figure 11. The object is then examined to discover if it is a class circuit, as represented by box 121. If the object is of the class circuit then the string in the data field 67 is extracted, as represented by box 122. The extracted string is then retrieved as the name of the circuit and the selected object, as represented by box 123. The following stage is to extract the string in the data field 68, as represented by box 124. The extracted string is then retrieved as the location in the selected object, as represented by the box
125. If the object is not a class circuit then the next stage after the stage represented by box 121 is a question to know if the object is class equipment. This step is represented by box 126. If the object is not class equipment, then the next step is to extract the string in data field 70, as represented by box 127. This string is then retrieved in the name of the location in the selected object, as represented by box 128. The process ends after the steps represented by boxes 125, 128 and 126 (if the object is not class equipment). After processing the records in file 1, it is necessary to process those in file 2 as shown in Figure 12. The first step in the records of the 2 processors file is to examine the string in the data field 75 of a first record for a comparison test against the object's templates, as represented by box 130. If the comparison test and the template is of the class team, this question is represented by box 131, then the name of the object is fixed to that of the chain, as represented by box 132. The next step is to consider whether the object of this name already exists, as represented by box 133. If the object does not exist then it is created, as represented by box 134
A second population process, as represented by box 136, is then implemented. The next record in file 2 is obtained afterwards, as represented by box 136. This stage is also the next stage for stage 131 if the comparison test is not of the class equipment. The next record is processed later as it was done in the above. The town procedure 2 is shown in Figure 13. The first significant step in the process is the consideration that if the object template is of the class team as represented by box 140. If the object template is from the team of class then the string in the data field 76 is extracted as represented by box 141. The extracted string is then stored as the name in the data field of the responsible party object, as represented by box 142. The procedure ends and step 136 continues. The first set of rules, set 1, is as follows: 1. START. { STEP 1 - CREATING OBJECTS AND EXTRACTING THE DATA LINE} 2. FOR EACH RECORD IN FILE 1 OF DATA. { CIRCUIT RECORDS} 3. START 4. CORRESPONDENCE CHAIN IN < DATAFIELD 70 > AGAINST < PATTERN > IN ALL THE TEMPLATES OF THE OBJECT IN THE MODEL. 5. IF THE TEST BY COMPARISON AND IF THE OBJECT TEMPLATE IS OF THE CLASS < EQUIPMENT > THE NAME OF THE OBJECT IS FIXED TO THE CHAIN IN < DATAFIELD 70 > 6. IF THE TEST BY COMPARISON AND IF THE OBJECT TEMPLATE IS CLASS < CIRCUIT > THE NAME OF THE OBJECT IS FIXED TO THE CHAIN IN < DATAFIELD 67 > 7. IF THE OBJECT THAT HAS THIS NAME DOES NOT EXIST FOR THIS TEMPLATE, THEN IT IS CREATED 8. THE EXISTING OR NEWLY CREATED OBJECT IS SELECTED
9. IF THE OBJECT TEMPLATE IS CLASS < CIRCUIT > THE CHAIN IS REMOVED IN < DATAFIELD 67 > AND RECOVER WITH THE NAME < CCT > ON THE SELECTED OBJECT. 10. IF THE OBJECT TEMPLATE IS CLASS < CIRCUIT > THE CHAIN IS REMOVED IN < DATAFIELD 68 > AND RECOVER WITH THE NAME < LOC > ON THE SELECTED OBJECT. 11. IF THE OBJECT TEMPLATE IS CLASS < EQUIPMENT > EXTRA CHAIN IN < DATAFIELD 70 > AND RECOVER WITH THE NAME < TYPE > ON THE SELECTED OBJECT. 12. END. { RECORDS IN THE DATA FILE 1} 13. FOR EACH RECORD IN THE DATA FILE 2. { PERSON IN CHARGE} 14. START 15. PROOF CHAIN BY COMPARISON IN < DATAFIELD 75 > AGAINST < PATTERN > IN ALL THE TEMPLATES OF THE OBJECT IN THE MODEL. 16. IF THE TEST BY COMPARISON AND IF THE OBJECT TEMPLATE IS CLASS < EQUIPMENT > THE NAME OF THE OBJECT IS FIXED TO THE CHAIN IN < DATAFIELD 75 > 17. IF THE OBJECT THAT HAS THIS NAME DOES NOT EXIST NOW FOR THIS TEMPLATE, THEN IT IS CREATED. 18. THE EXISTING OR NEWLY CREATED OBJECT IS SELECTED
19. IF THE OBJECT TEMPLATE IS CLASS < EQUIPMENT > THE CHAIN IS REMOVED IN < DATAFIELD 76 > AND RECOVER WITH THE NAME < RESPONSIBLE > ON THE SELECTED OBJECT. 20. END. { RECORDS IN THE DATA FILE 2.}. 21. END. { PASS l} 22. START. { STEP 2- CREATION OF ATTRIBUTE VALUES} 23. FOR EACH OBJECT CREATED IN STEP 1 24. FOR EVERYTHING < ATTRIBUTE RULE > THE ATTRIBUTE VALUE IS CREATED BY USING THE DATA NAMED RECOVERED IN STAGES 9 AND 10. 25. END. { STEP 2}
In the previous rules, < > it designates part of the rule that can be set by the network authority before the rules are applied to supply the different forms of the database. Each object template (class) in the model has a rule, which consists of a large number of parts (or sub-rules), associated with it. Line 1 of the rules begins a first step through the network database 34 to create objects in the intermediate database 41 to extract data to form values and attributes of those objects. Line 2 ensures that all records in file 1 are examined, that is, records 61 through 64. Line 3 starts the process of each of the registers 61 through 64, this procedure includes lines 3 through 12. The procedure it is repeated by virtue of line 2. Line 4 refers to the examination of the string in the data field 70 of each record against a pattern in all the templates object of the model. The pattern is that defined by the ITEMSPEC rules of the classes fixed in the model. In this way the rules can be considered as templates. In this mode the ITEMSPEC for both CIRCUIT and EQUIPMENT classes is "EQ" which will compare any string of the characters starting with "EQ". Lines 5 to 8 refer to the creation of new objects or the use of existing objects. The created object is named according to the fields examined in the record. The name is set according to the string in the particular data field set by the sub-rule. If the object is a new object, that is, the object that has the name of the data field set by the sub-rule did not already exist, then the object of that name is created in line 7. After creating the required objects , the next stage is to extract the data that will be stored in the objects. The data is retrieved with a "name" that allows you to reference the data later. The "named" data is called a parameter. Lines 9 and 10 perform this operation for the objects in the CIRCUIT class. Through line 9, the string found in data field 67 is extracted and retrieved with the name "CCT" in the object. selected. Through line 10, the string found in data field 68 is retrieved with the name "LOC" in the selected object. Line 11 performs the operation so that the objects in the EQUIPMENT class with the string extracted from the data field 70 are retrieved with the name "TYPE" in the selected object. After completing line 11, six objects have been created with the following parameters:
Obieto Class Parameter Values
CCT123 CIRCUIT CCT CCT123 LOC GOWER CCT234 CIRCUIT CCT CCT234 LOC GOWER
CCT345 CIRCUIT CCT CCT345 LOC IPSWICH
CCT456 CIRCUIT CCT CCT456 LOC GLASGOW
EQ1 EQUIPMENT TYPE EQ1 EQ2 EQUIPMENT TYPE EQ2
Line 12 is an end phrase that means the end of the processing of records in data file 1. Line 13 ensures that the following rules apply to all records in data file 2, that is, all the records of responsible person. Line 14 is a start phrase for applying the rules to the record in data file 2. Line 15 has the first rule to be applied. The string in the data field 75 of each of the records in the data file 2 is compared against the pattern in all the templates of the model object. If there is a comparison and the template of the object is of the EQUIPMENT class, then the name of the object is fixed to the string in the data field 75, line 16. If an object thus named is a new object, then the object is created, line 17. They are selected after the .objects and if the object template is of class EQUIPMENT, the string maintained in the data field 75 is retrieved with the responsible name in the selected object, lines 18 and 19. The processing of the data file 2 is then completed, line 20 as the step 1 through the database, line 21. In this particular example of an existing database, no objects will be created through the application of line 17 since they will have been created by the application of lines 5 and 7. objects of the CIRCUIT class will not result in any additional parameters since line 19 only sets a parameter where the object is of the EQUIPMENT class. The objects of the EQUIPMENT class will result in the values of the RESPONSIBLE parameter being F. JONES for object EQ1 and S.SMITH for object EQ2. At the end of step 1 the state of the objects will be:
Obieto Class Parameter Values
CCT123 CIRCUIT CCT CCT123 LOC GOWER
CCT234 CIRCUIT CCT CCT234 LOC GOWER CCT345 CIRCUIT CCT CCT345 LOC IPSWICH
CCT456 CIRCUIT CCT CCT456 LOC GLASGOW
EQ1 EQUIPMENT TYPE EQ1 RESPONSIBLE F. JONES
EQ2 EQUIPMENT TYPE EQ2 RESPONSIBLE S.SMITH
Lines 22 through 25 comprise the rules for step 2, creating the attribute values for the objects created in step 1 through the existing database. Line 22 is a start phrase for the second step. Line 23 is for the sentence that ensures that the following rules apply to each object created in step 1. Line 24 applies an "attribute rule" to create from the named data (parameter) retrieved after the lines 9 and 10 an attribute value. Each class or object template has its own list of attributes to make the object. There is an attribute sub-rule to generate each attribute value. The attribute sub-rule is considered and fixed by the network authority and allows the parameters to be manipulated and combined to form an attribute value.
When applying the attribute sub-rules the following objects are given:
Obieto Attribute Value CCT123 ID CCT123 / GOWER SERIAL 1 CCT234 ID CCT234 / GOWER SERIAL 2 CCT345 ID CCT345 / IPSWICH SERIAL 3 CCT456 ID CCT456 / GLASGOW SERIAL 4 EQ1 TYPE EQ1 PERSON F. JONES EQ2 TYPE EQ2 PERSON S.SMITH
Therefore, an intermediate database 41 is populated with object attributes. The next step is to apply an additional set of modalized rules as a piece of software or "backup end" to derive the final database 43 from the intermediate database. In this mode, the final database 43 is structured as a relational database with the data maintained in the form of two dimensional tables. The particular system employed is the ORACLE (TM) relational database control system available from Oracle Corporation. In a relational database only one type of data structure data exists which is the table. The system allows several processes to be applied to the tables, for example, by sub-setting or combining data tables. For more information on the types of operations that can be performed on the data tables, the reader is directed to "Introduction to SQL" by L. Ellison published by the Oracle Corporation. The network control system uses the tables to reconstruct (specifically exemplify) the original objects in a manner well known to those skilled in the art of network control. A general overview of the way in which the tables are produced from the intermediate database 41 will now be described with reference to Figure 14. A first step of the process is to select an object from the intermediate database 41, as represented by box 150. The next step is to extract the attributes of this object, as represented by box 151. Any required auxiliary data is generated then, as represented by box 152.
The tables are then set in the final database and the data is inserted there, as represented by box 153. The next object is selected from the intermediate database 41, box 154, and processed as before. In more detail the tables are produced from the intermediate database 41 in the following manner:
26. START . { MOVE THE OBJECTS TO THE DATABASE REPRESENTATION TABLE} 27. FOR EACH OBJECT IN THE INTERMEDIATE DATABASE 28. FOR EACH ATTRIBUTE IN OBJECT 29. EXTRACT OF THE ATTRIBUTE 30. USING THE RULES DECIDE ON WHICH TABLE OR TABLES IS THE VALUE TO BE INSERTED 32. USING THE RULES IS GENERATED ANY AUXILIARY DATA REQUIRED TO BE ENTERED IN THE TABLES FOR
REBUILD THE ATTRIBUTES OF THE OBJECT 33. GENERATE SQL COMMANDS TO INSERT THE VALUE AND AUXILIARY DATA IN THE TABLE OR APPROPRIATE TABLES 34. FIN. { ATTRIBUTES OF AN OBJECT} 35. USING THE RULES WILL GENERATE ANY AUXILIARY DATA REQUIRED TO BE ENTERED IN THE TABLES TO REBUILD THE OBJECT 33. GENERATE THE SQL COMMANDS TO INSERT THE AUXILIARY DATA IN THE TABLE OR APPROPRIATE TABLES 37. END. { OBJECTS IN THE INTERMEDIATE DATABASE} 38. END
The rules referenced in lines 30, 31 and 35 are rules maintained as a text file in the rules memory 44. These rules are applied to the objects in the intermediate database 41 to generate a set of SQL commands (Structured Question Language). The SQL commands are used by the ORACLE (TM) System to generate the appropriate values in the tables of the final database 43. These commands will depend on the desired shape of the data structure in the final database 43.
Claims (7)
1. A method for constructing a final telecommunications network database in a memory of a computer system by storing data arranged according to a first structure, such data being extracted from an existing database having data disposed to a second structure different from the first structure, the method is characterized in that it comprises the steps of: creating an intermediate database in which the data can be stored in a third structure different from the first and second structures; enter a first set of rules in memory, the first set of rules specifying a set of object classes to be used in the intermediate database and how to create and populate objects for each class in the intermediate database from the data stored in the existing database; create in the memory a model, through the use of such classes, of the object hierarchy to be used in the intermediate database; enter a second set of rules that specify how the objects in the final database are created and populated from the objects in the intermediate database; use the first set of rules to create and populate objects in the intermediate database from the data stored in the existing database; and use the second set of rules to create and populate the objects in the final database from the objects stored in the intermediate database.
2. A method, in accordance with the claim 1, the step of using the first set of rules to create and populate objects in the intermediate database, characterized in that it includes the steps of: searching the existing database for the occurrence of a particular item of data; and after finding such an occurrence, create a corresponding object in the intermediate database.
3. The method, in accordance with the claim 2, characterized in that the object is named according to a name associated with the data item.
4. The method, according to any of the preceding claims, characterized in that the final database is a relational database.
5. The method, according to claim 4, characterized in that the structured question language commands are used to insert data into the appropriate data structures in the relational database.
6. A telecommunications network database produced by a method according to any of claims 1 to 5.
7. A network control for a telecommunications network, characterized in that it includes a database in accordance with claim 6.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP95300878 | 1995-02-13 | ||
EP95300878.6 | 1995-02-13 | ||
PCT/GB1996/000333 WO1996025715A1 (en) | 1995-02-13 | 1996-02-13 | A method and apparatus for building a telecommunications network database |
Publications (2)
Publication Number | Publication Date |
---|---|
MX9706023A MX9706023A (en) | 1997-11-29 |
MXPA97006023A true MXPA97006023A (en) | 1998-07-03 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0809831B1 (en) | A method for building a telecommunications network database | |
US5315709A (en) | Method and apparatus for transforming objects in data models | |
JP2571660B2 (en) | Method and system for manipulating distributed heterogeneous data in a data processing system | |
US5481718A (en) | Object-oriented system having object models containing plural objects with instantiation following static classification by class relationships, dynamic classification by temporal instantiation, and causality restrictions | |
US7668888B2 (en) | Converting object structures for search engines | |
AU2002349765B2 (en) | Gateway and gateway setting tool | |
JP2001306372A (en) | Method for managing document and storage medium storing program for executing the method | |
JP4639082B2 (en) | Process processing configuration construction and management device in factory production process management system | |
CN112416936B (en) | DCS background multi-node cooperative configuration mark name verification method | |
US6333999B1 (en) | Systematic enumerating of strings using patterns and rules | |
MXPA97006023A (en) | A method and apparatus for building a telecommunication network database | |
US5848141A (en) | Method and apparatus for provisioning call processing records using logic and data templates | |
AU689701C (en) | A method and apparatus for building a telecommunications network database | |
US20020123811A1 (en) | Production management system and program | |
JPH0683693A (en) | Data processor for executing processing by combining objects | |
JPH11203363A (en) | Data management system | |
JP2003186670A (en) | Automatic generation device, automatic generation method and automatic generation program for database access component | |
JP3006311B2 (en) | Method and apparatus for changing network configuration | |
JPH0267629A (en) | Dispersed processing method for software reutilization | |
JPH0685835A (en) | Three-level communication processing system implementing inter-terminal-station high speed transmission | |
Li et al. | Automatic schema matching for data warehousing | |
JPH06243021A (en) | File transfer method | |
JPH05113924A (en) | Information managing model converting system | |
JPH0683605A (en) | Data processing system for execution of changed program | |
KR20050024762A (en) | apparatus and method of management for data base |