[go: up one dir, main page]

WO2002003245A1 - Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle - Google Patents

Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle Download PDF

Info

Publication number
WO2002003245A1
WO2002003245A1 PCT/FR2000/001902 FR0001902W WO0203245A1 WO 2002003245 A1 WO2002003245 A1 WO 2002003245A1 FR 0001902 W FR0001902 W FR 0001902W WO 0203245 A1 WO0203245 A1 WO 0203245A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
objects
stored
database
variable number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2000/001902
Other languages
English (en)
Inventor
Laurent Querel
Boubakar Saim Haddache
Laurent Fontvielle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OTOOBE
Original Assignee
OTOOBE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OTOOBE filed Critical OTOOBE
Priority to PCT/FR2000/001902 priority Critical patent/WO2002003245A1/fr
Priority to AU2000261656A priority patent/AU2000261656A1/en
Publication of WO2002003245A1 publication Critical patent/WO2002003245A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems
    • G06F16/94—Hypermedia

Definitions

  • the subject of the present invention is the methods of storing informational objects, or objects, in a computer system, and more particularly, a method of storing, in a traditional relational database, objects in eXtended Markup Language format, or XML, from the Internet consortium
  • Data storage systems are well known in information processing techniques, and more and more frequently, they implement relational database management systems.
  • each access to an object stored in the database will require access to the database for the main table plus as much access to the database as there are additional tables, i.e. -to say, of parts of objects in variable number in an object. If the object comprises, as is frequent, five or ten parts in variable number, the number of accesses to the base of domitées will be multiplied by five or ten compared to an object having no variable parts, this is results in performance degradation in the same report.
  • the object of the present invention is therefore to propose a method and a system which make it possible to limit to a main table and an annex table the number of tables necessary for storing simple data in fixed and variable number of a collection of present computer objects. in a data storage system.
  • the present invention therefore provides a method of storing information objects or objects in a relational database stored in a server computer, said relational database being made up of tables, each table being made up of an array of data sets. simple, said sets having the same data structure in the same table, each simple data item of a table being designated by a unique identifier in said table, an object consisting of one or more simple data items which can be stored in a table said database, and / or one or more objects nested in said object, said nesting being able to be carried out on any number of levels to produce an object, a nested object or a simple data item being said locally in fixed number s' he or she appears exactly once in the object immediately containing it or being said locally in variable number d otherwise, a simple datum appearing at any level of said object being said to be globally a fixed number if it is locally in a fixed number and if all the objects containing it are locally in a fixed number, simple datum appearing at any level of said object being said globally in variable number if
  • each of said one or more additional sets possibly stored in said single additional table may further comprise a set of Boolean indicators, each Boolean indicator being associated with a particular datum of said generally simple data in variable number stored in said supplementary set , said Boolean indicator indicating whether said simple data globally in associated variable number is defined or not in said annex set.
  • some of said Boolean indicators of said set of Boolean indicators may be common to several simple data globally in variable number when said simple data are locally in fixed number in the same object containing them immediately.
  • said main assembly associated with said object to be stored will include data making it possible to uniquely identify said main assembly in said main table.
  • said unique data can be unique in said server computer, and advantageously, said unique data stored in said main set associated with said object to be stored will be further stored in each of the additional sets associated with said object to be stored, to allow the linking of said main assembly and of said optional assembly or assemblies associated with said object to be stored.
  • said unique data item may consist of the logical name of the server computer on said network, the table number of said main table in said database and the data set number of said main set in said main table.
  • said logical name of the server computer being unique on said network
  • said database being unique on said server computer
  • said table number of said main table being unique in said database
  • said dataset number of said main assembly being unique in said main table.
  • two objects to be stored can be said to be of the same type if they consist of simple data and nested objects of the same type, two objects of the same type having in common the same identifier and the simple data and / or the nested objects corresponding to any level of said objects of the same type having in common the same identifier, unique in the object containing them immediately.
  • the process can create a global identifier for all objects of the same type and for all simple data corresponding to a level any of said objects of the same type, said global identifier being said common identifier for said objects of the same type, and said global identifier being obtained, for each of said corresponding simple data, by the concatenation of identifiers, in the objects containing them immediately, of all the objects containing said simple data, and of the identifier of said simple data in the object containing it immediately.
  • the number of characters of this global identifier may be truncated to the number of characters allowed by said database for the identifier of a data item stored in a table of said database. Also, an ambiguity that may appear due to said truncation can be resolved by performing the steps consisting in:
  • the objects stored in the database can be received or transmitted by the server computer via a computer network of the Internet type.
  • the simple data constituting said objects (6) stored in said database will be of text type, and advantageously, said simple data of text type will be data written in XML language.
  • said data written in XML language may conform to an XML Schema description.
  • a set of data in XML format can be obtained by an automatic translation of said description, said set of data and a complementary set of data being in turn automatically translated into SQL language to define and manage the structure of the database. data, and to control data exchanges with said database.
  • part of the simple data of the objects received by said Internet-type network can be deleted using a pattern, or model, of object written in XML language, to prohibit the modification of said simple data via said network.
  • part of the simple data of objects transmitted via said network can be deleted using an object pattern written in XML language to limit the transmission on said network to certain simple data of said objects.
  • the deletion of part of the simple data contained in the objects will also make it possible to optimize the requests to said database.
  • the invention further provides a system for storing information objects or objects, in a relational database stored by a server computer, which has the characteristic that it implements the method according to any one of the claims. preceding.
  • FIG. 1 is the block diagram of the preferred embodiment of the object storage method according to the present invention.
  • FIG. 2 is a diagram showing the use of a single annex table for sets in variable number in the preferred embodiment of the method of the invention in an example case
  • FIG. 3 is a diagram showing the use of a set of annex tables for the sets of variable numbers in the prior art, on the same example case as that of FIG. 2.
  • Directory entry
  • Informational objects, or objects, whose data structure is not fixed, make it possible to take into account this type of data in variable number ,. which makes all the power of the object approach compared to a traditional approach where the structure of the dominated is fixed, and in which it is therefore necessary to plan in advance a maximum number of occurrences for each data, at the risk on the one hand to block in an annoying way a particular case where a greater number of occurrences than that envisaged would be necessary, and on the other hand, to waste unnecessarily wasted storage space in the general case for some particular cases little common.
  • this processing consists in separating the data in fixed number "name”, “telephone”, “fax” and the data in variable number "street”, “city” by storing the data in fixed number in a first table main 3, and by storing the data, or sets of data, in variable number in as many other annex tables as there are data, or sets of data, in variable number in the object 6.
  • table 3 is the main table storing the sets 31 of dominated in fixed number made up of simple data "key” 11, "name” 12, "telephone” 13 and "facsimile”14;
  • Table 4 is a first annex table storing the sets 41 consisting of the simple "key” data item 11 and the variable number data "address", that is to say, simple "street” data 15 and " city "16;
  • table 5 is a second annex table storing the data sets made up of the "key" data 11 and of the variable number data "contact" 17.
  • the data "name” having the value "OTOOBE” will be stored in 12
  • the data "telephone” having the value "+33 (0) 1 44 34 85 03” will be stored in 13
  • the "fax” data having the value "+33 (0) 1 44 34 85 01” will be stored at 14
  • the "street” data of the first "address” sub-object, having the value "3bis, rue du Dondel” -Foucault " will be stored in 15 ls the" city “datum of the first" address "sub-object, having the value” 92000 NANTERRE ", will be stored in 16 ⁇
  • the" street “datum of the second" address "sub-object, having the value "34, bd Haussmann” will be stored in 15 2
  • the datum "city” of the second sub-object "address" having the value "75009 PARIS”
  • the first datum "contact” having the value "M.
  • the dom ée "key" 11 appearing in the three tables 3, 4 and 5 is the primary key of these tables, and its use will be described later.
  • tables 3, 4 and 5 must first be defined in database 2, as well as the various data stored in these tables 3, 4 and 5.
  • the section “EntreeAnnuairejtnain” indicates the name, freely chosen by the operator subject to uniqueness, of the main table 3, and a section “VARCHAR (n)” indicates a character string of variable length and maximum length n.
  • the "key” data 11 is the primary key mentioned above and which will be described later, and the "PRIMARY KEY” key tells the system precisely that this "key” data 11 is the primary key.
  • the operator also had to manually define the indexed data, that is to say the data, the content of which could make it possible to find an entry in the directory, by means of SQL statements of the type: CREATE INDEX "IndexName "ON” EntreeAnnuaire_main "(name) which tells the RDBMS to ensure that a directory entry can be found by the content of the" name "section of the main table 3" EntreeAnnuairejmain ".
  • the management of simple data in variable number is carried out using a single table 7, instead of tables 4 and 5.
  • the method of the invention stores the first occurrence of simple data in variable number in a first set of data 71] of table 7, the second occurrence of a simple data in variable number in a second set of data 71 in table 7, the third possible occurrence of a simple data in number variable in a third data set 71 3 , etc.
  • the method therefore stores the first occurrence data of the simple "street” data of object 6 in the location 15 ⁇ of the set 71 ! from table 7, it stores the first occurrence of the data "city” in location ⁇ 6 ⁇ of the set 71 ⁇ of table 7, it stores the second occurrence of the data "street” in location 15 of the set 71 2 , it stores the second occurrence of the data "city” 16 2 in the location 16 2 of the set 71 2 , it stores the first occurrence of the data "contact” ⁇ 7 ⁇ in the location ⁇ 7 ⁇ of set 71 15 it stores the second occurrence of data "contact” 17 2 in location 17 2 of set 71, and it stores the third occurrence of data "contact” 17 in l location 17 of the set 71 3 .
  • the method according to the invention will also reserve, in each set 71, data locations for storing this presence or absence information for each variable number of data in this set 71.
  • the method adds to the data structure of table 7, that is to say in each set 71, a Boolean data item for each set of data in variable number in object 6.
  • the simple data set 72 consisting of Boolean simple data 20 and 21 is thus added to each set 71, the Boolean data 20 indicating the presence, in the set 71 considered, of the set consisting of simple "street” 15 and "city” 16 data, and the Boolean data 21 indicating the presence, in the set 71 considered of the "contact" data 17.
  • the presence or absence information variable number of data or sets of data will be kept when writing an object 6, and the method may use this information during subsequent readings, to correctly reconstruct the object 6 as it was at the time of his recording nt.
  • the number of data sets present in the single annex table is equal to the maximum of the numbers of the data in variable number in object 6, while this number of sets of data in the annex tables is equal to the sum of the numbers of data in variable number of the object 6 in the prior art, that is to say an always higher number.
  • the method is used to store objects 6 written in XML language which conform to a description 92 of XML Schema type, which means in particular that this description is itself written in the XML language.
  • This description 92 called COSSchema in the preferred embodiment, describes the data structure of the objects 6.
  • the advantage of this description XML Schema 92 is to constitute a single reference definition for the structure of the objects 6, model which will be used whenever it is necessary to check the structure or the validity of the objects 6.
  • a certain number of definitions of objects used in the COSSchema 92 scheme are derived from definitions stored in another scheme XML Schema 91, called COSCoreSchema.
  • the interest of this approach is to allow the COS to standardize the definitions of certain objects by giving them a common basis, and to be able to possibly carry out a certain number of works, in particular of maintenance, in a homogeneous way on these objects. For example, if it proves necessary to introduce new simple data or to modify an existing simple data in a basic type defined in COSCoreSchema, it will not be necessary to. reproduce the new simple data or the modification in all objects based on this type, and the modification will be implicitly reproduced via the only reference to the base type. Thus, the risk of error in the structure of COS objects will be reduced by the same amount, and the maintenance of these objects will be facilitated.
  • the 'minOccurs' parameter of a single data item or a nested sub-object indicates the minimum number of times the data concerned appears in the immediately containing object
  • the 'maxOccurs' parameter of simple data or a nested sub-object indicates the maximum number of times the data concerned appears in the immediately containing object.
  • the method uses this description in XML format, in association with the method of storing objects in only two tables which has been described above, to automatically generate SQL statements for creating and manage the data in database 2 representing the stored objects.
  • the method of the invention starts from COSSchema and it applies a certain number of rules to obtain an extended XML Schema format, called XDB Schema, comparable to that of the example described above.
  • XDB Schema extended XML Schema format
  • the description of the data is made, in a structured way, by referring to other predefined types, such as the types defined in the COSCoreSchema or to intermediate types defined in the COSSchema itself.
  • the method of the invention therefore applies to this COS Schema schema a certain number of translation rules allowing it to pass from a representation comprising non-simple types to a representation comprising only simple types. The result of this translation constitutes the XDB Schema.
  • the method of the invention uses a additional XML 96 schema, called XDB Mapping, describing the data to be indexed in the tables storing the data of object 6.
  • This XDB Mapping 96 schema takes up the structure of the COSSchema schema by limiting it to the data to be indexed.
  • the method translates these XDB Schema and XDB Mapping schemas into SQL statements intended for the DBMS managing the database 2.
  • the method creates for each simple data a global identifier obtained by prefixing the identifier of the simple data, as it appears in the section 'name-' ... '"of the definition of the simple data in the XDB Schema, by the concatenation of identifiers, as they appear in the 'name-' ... '"headings of the corresponding definitions of the XDB Schema, of all the sub-objects containing, at one level or one other, the simple data considered.
  • This process removes the ambiguity that could appear, because because because the identifiers of simple data or sub-objects in their immediately containing objects are distinct, two global identifiers obtained in this way are necessarily globally distinct.
  • the global identifier of the data "name” will be "name” itself, since the simple data "name” is not contained in a sub-object; on the other hand, the global identifier of the "street” data contained in the "address” sub-object will be "excellentj ie".
  • the identifiers of the data created in tables 3 and 7 of database 2 were the concatenation of the identifiers of the data and of all the sub-objects containing it in object 6.
  • the method of the invention truncates the identifiers previously obtained to the length permitted by the RDBMS for the data identifiers of a table. At the end of this truncation, if the global identifier obtained is already present in the table where it was to be created, the method of the invention performs the following steps:
  • step 2 If a number entirely made up of digits "9" is reached in step 2, then the process returns to step 1.
  • the method described above makes it possible to remove the ambiguities, in the global identifiers assigned to the simple data stored in the database 2, which may appear due to the possibility of duplicating a data identifier or sub- object in separate sub-objects.
  • the method then re-reads in parallel the XDB Schema and XDB Mapping, and for each new type of object to be created 6 found in the XDB schema Diagram, it applies the following process: - the process then creates in the database a main table 3 bearing the name of the object 6, followed by the suffix "_main", comprising a "key” datum 11 used to uniquely identify in the database an object 6; thus, when it meets in the XDB Schema the definition:
  • the process explores the definitions " ⁇ element ...> ... ⁇ /element>" of the XDB Schema, XDB Schema and for each simple datum encountered, such as "name” or "contact", it determines whether this data is in fixed or variable number; a simple datum will be said to be a fixed number if its "maxOccurs” section is absent from the definition and if this simple datum is not contained at any level in a variable-number subobject, that is to say a sub-object whose "maxOccurs” section would be present and different from the "minOccurs" section of said sub-object; a datum will be said to be in variable number in the opposite case, that is to say if it is not in simple number with regard to the preceding definition;
  • the method creates an index for this data using an appropriate SQL statement such as: CREATE INDEX "IndexNom” ON “EntreeAnnuaire_main " (last name) in which the name of the index "IndexName” is that found in the "sqkindexname” section of the corresponding definition of the XDB Mapping scheme; - when the method encounters variable data such as the "contact” data in the above example, it performs the following operations: "if there is not already an annex table 7 associated with this main table 3 , it creates this annex table using an SQL statement such as: CREATE TABLE "EntreeAnnuaire_annex” (INTEGER key,
  • the above aspects of the method of the invention are implemented in a program 90 called XBD Engine, and, unlike the prior art, the method of the invention allows creation new type of object 6 in the database 2 without manual intervention by an operator, which results in a very appreciable time saving and a considerable reduction in the risk of error, both for creation and for modification , in the database, of the structure of an object 6.
  • the method of the invention has been described as transforming the COSSchema schema, comprising predefined types, into an XML schema, the XDB Schema schema , containing only simple data types as used by the RDBMS. This was done with a view to using a basic SQL language, which knows no types other than these simple types.
  • the method of the invention will naturally take advantage of the typing possibilities offered by this language by translating into simpler types than the types cannot be "understood" directly by the SQL language used.
  • the types used by the COS Schema and which can be translated directly into SQL types will be using an appropriate SQL statement, such as: CREATE TYPE ...
  • a system for storing simple data of an object 6, in the prior art as in the method of the invention consists of a computer 1 hosting a relational database 2.
  • the sets of simple dominates of a main table such as the main table 3, or those of an annex table such as tables 4, 5 or 7, are managed using the functions offered by the relational database management system or RDBMS, used for management from the database 2.
  • These functions include at least a function for writing or creating a set of simple data in a table, a function for reading a set of simple data from a table, a function for deleting a set of table, and a function for searching for a set by its content, the function for modifying a set being able to be assimilated, for the simplicity of the presentation, to a reading of the set followed by a writing of the whole modified. Therefore, this function will not be described further.
  • main table 3 storing the sets 31 of simple data in fixed number "name” 12, "telephone” 13 and “facsimile” 14, and this main table is in relation with two annex tables 4 and 5 containing the sets 41 and 51 of single domies in variable number, respectively the sets 41 made up of simple "street” 15 and "city” data 16 for the annex table 4, and the sets 51 made up of the "contact" data 17 for the annex table 5.
  • a unique "key" identification data item 11, present in the sets 31, 41 and 51 respectively stored in tables 3, 4 and 5, is used to relate, that is to say, to make refer to, the main table 3 and the annex tables 4 and 5.
  • RDBMS by initializing the data "key” 11 to the value 1234, that is to say, writing the three sets 51 l5 51 2 and 5I 3 consisting respectively of the simple data "key” 11 and “contact” 17 1 for the first, simple data "key” 11 and “contact” 17 2 for the second, and "key” 11 and “contact” 17 Î for the third; this can be done, for example, by SQL statements:
  • RDBMS by re-reading all the sets 51 of table 5 comprising the value given 1234 in their "key” data 11, that is to say, reading of the three sets 51 ls 51 2 and 51 3 respectively consisting of simple data "key” 11 and “contact” 17 ⁇ for the first, data simple "key” 11 and “contact” 17 2 for the second, and "key” 11 and “contact” 17 t for the third; this can be obtained, for example, using the SQL statement:
  • the database 2 comprises a main table 3 storing the sets 31 of simple data in fixed number "key” 11, "name” 12, "telephone” 13 and “facsimile” 14, and this main table is in relation to a single annex table 7 containing the sets 71 of simple data in variable number, consisting of the simple "contact” areas 17.
  • a unique identification datum "key” 11, present in sets 31 and 71 respectively stored in tables 3 and 7, is used to relate, that is to say to reference, the main table 3 and the annex table 7, and to uniquely identify an object 6 in database 2.
  • the method of the invention restores the fixed data of object 6; more precisely, the method initializes the data in fixed number "name” of the object 6 using the data 12 present in the set 31 read back, it initializes the data in fixed number "telephone” of the object 6 using the data item 13 of this same set, and it initializes the data in fixed number "facsimile” of the object 6 using the data item 14; - Reading, in table 7, of the sets 71 of this table comprising the value 1234 in their "key” data 11; this can be done using an SQL statement such as:
  • these three sets 71 1 , 71 2 , 71 3 of data each consist of the data "key” 11, simple data in variable number “street” 15, “city” 16 and “contact “17, and data 20 and 21 respectively indicating the presence or not of the variable number set” street "," city “and the variable number dom” contact "in the set 71 concerned;
  • the method examines the data 20 and 21 in each set 711, 71 2 , 71 3 re-read; "more precisely, if the content of the Boolean datum 20] contained in the set 71 1 is TRUE, this means that there originally existed a first set" street "," city "in the object 6 stored; in this case, the method according to the invention will then create a first sub-object in variable number "address” in object 6; it will fill in the variable number data "street” and "city” of this first sub-object with respectively the data 15] and 16] contained in the set 71]; likewise, if the content of the Boolean data 21 !
  • the method of the invention will create a first variable number of data "contact” in object 6; "using the same approach as above, the method of the invention will create a second and a third variable "address” sub-object "street", "city” if the contents of the Boolean data 20 2 and 20 3 contained respectively in the sets 71 2 and 71 3 are TRUE, and it will initialize the data "street” and "city” of these second and third subobjects in variable number "address” with the data respectively 15 2 and 16 2 on the one hand, and 15 3 and 16 3 on the other hand respectively contained in the set 71 2 and the set 71 3 ; "similarly, the method of the invention will create a second and a third datum in variable number” contact "if the contents of the Boolean domies 21 2 and 21 3 contained respectively in the sets 71 2 and 71 3 are TRUE, and it will initialize these second and third
  • the use of the method of the invention allows a reduction of one third of the number of operations of data sets in all cases.
  • the example presented above voluntarily simple for reasons of clarity of the description, does not necessarily give a good account of the very significant gains which the process can bring in a practical case comprising a number of tables in much larger relationship.
  • N a the number of additional tables T ;
  • N p the total number of main sets 31 in the main table 3, and by K ;
  • K the total number of data sets present in an annex table T ;
  • the average number of operations to perform an input-output relating to an object 6 in a given table Tj will, on average, be equal to K; / N a , and the grand total for an input -complete output comprising the main set 31 and the N a data sets present in the N a annex tables Tj will therefore be equal to:
  • the number of inputs-outputs necessary to obtain the data sets contained in the single annex table will therefore be equal on average to Max (Kj) / N p , because the single annex table comprises a number of sets equal to the maximum of the number of sets present in the sets of sets in relation; therefore, the grand total for a complete input-output comprising the main set 31 and the data sets contained in the single annex table will therefore be equal to:
  • the average number of input-outputs N proc with the method of the present invention will always be very much lower than the average number of input-outputs N ant without this method.
  • the method according to the invention allows a gain in performance reaching a factor equal to the ratio N pr0c / N ant , that is to say :
  • XML XML
  • XML object patterns to filter certain data from the 6 objects entering and leaving the database 2.
  • I / O Format patterns of objects XML 61, collectively referred to as I / O Format and conforming to an XML Schema description, are used to carry out such filtering.
  • these patterns of XML I / O Format 61 objects will delete certain sensitive data from incoming objects, such as data concerning the validity of the data contained in an object 6, so that these sensitive data cannot be, in all state of cause, modified from network 60, and so that their modification can only be carried out by an operator intervening directly on the server computer 1.
  • the patterns of XML I / O Format objects 61 will delete in the data of an object 6 transmitted on the network 60 the data which would not be used by said user. Taking into account that, in practice, the data transmitted for an object 6 usually only represent a small part of the set of data for this object, this process allows a substantial reduction in the volume of data transmitted by the server computer 1, which is particularly interesting in the case of a very busy server computer 1, such as those found on the Internet.
  • this method makes it possible to take into account different security levels attached to the users connecting via the network 60, by associating with each security level a pattern eliminating from the data transmitted to the user the data not authorized for the security level. of the user.
  • This method makes it possible to focus the request on the tables of the database 2 and the data in these tables 3 and 7 which are actually used in the request of a user.
  • the method will not access this table 7 for the request, which, once again, will make it possible to significantly improve the performance of the server computer 1 implementing the method of the invention.
  • the use of XML format and an object pattern in XML format makes it possible to impose security rules on incoming data, to limit the use of the network pass-through base 60 to the only necessary data and to correspondingly reduce the volume of data exchanged with the database 2.
  • the “key” datum 11, uniquely identifying an object 6, has been indicated, for reasons of simplicity of the description, as being managed explicitly by the method of the 'invention.
  • this explicit technique is in no way obligatory, and it can perfectly be replaced by any other equivalent technique that can be offered by the RDBMS used.
  • this “key” datum 11 has been described as being made up of a single whole number, but it can just as easily be made up of several parts.
  • a single “key” datum 11, called Object IDentifier or OID is obtained for each object 6 by concatenating a first part consisting of the logical name of the server 1 on which the database 2, a second part consisting of the number of the main table 3 in the database 2, and a third part consisting of the registration number of the main data set 31 in said table 3.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé de stockage d'objets informationnels ou objets (6), dans une base de données relationnelle (2) stockée dans un ordinateur serveur (1), la base de données relationnelle (2) étant constituée de tables, chacune constituée d'un tableau d'ensembles de données simples qui ont la même structure de données dans une même table, chaque donnée simple d'une table est désignée par un identifiant unique dans ladite table, un objet (6) étant constitué d'une ou plusieurs données simples pouvant être stockées dans une table de la base de données (2), et/ou d'un ou plusieurs objets emboîtés dans ledit objet. L'emboîtement peut être réalisé sur un nombre quelconque de niveaux pour réaliser un objet (6), un objet emboîté ou une donnée simple étant dit localement en nombre fixe s'il ou elle apparaît exactement une fois dans l'objet le ou la contenant immédiatement et étant dit localement en nombre variable dans le cas contraire. Une donnée simple apparaissant à un niveau quelconque dudit objet (6) est dite globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets la contenant sont localement en nombre fixe, une donnée simple apparaissant à un niveau quelconque dudit objet (6) est dite globalement en nombre variable si elle est localement en nombre variable ou si l'un quelconque des objets la contenant est localement en nombre variable. Les données globalement en nombre fixe d'un objet à stocker (6) sont stockées dans un ensemble de données principal (31) stocké dans une table principale (3) de la base de données (2). Les données simples globalement en nombre variable dudit objet à stocker (6) sont stockées dans une ou plusieurs tables annexes (4, 5, 7) de la base de données (2). Lorsqu'elles existent, les données simples globalement en nombre variable desdits objets (6) sont stockées dans une unique table annexe (7) de la base de données, le procédé crée un ou plusieurs ensembles de données annexes (71) pour stocker les données simples globalement en nombre variable dans l'unique table annexe (7).

Description

PROCEDE DE STOCKAGE D'OBJETS INFORMATIONNELS AU FORMAT XML DANS UNE BASE DE DONNEES RELATIONNELLE
La présente invention a pour objet les procédés de stockage d'objets informationnels, ou objets, dans un système informatique, et plus particulièrement, un procédé de stockage, dans une base de données relationnelle traditionnelle, d'objets au format eXtended Markup Language, ou XML, du consortium Internet
World Wide Web, ou W3C.
Les systèmes de stockage de données sont bien connus dans les techniques de traitement de l'information, et de plus en plus fréquemment, ils mettent en œuvre des systèmes de gestion de bases de données relationnelles.
Ces systèmes sont bien adaptés au stockage de données comportant des parties en nombre fixe et des parties en nombre variable, les parties en nombre fixe étant stockées dans une table principale et les parties en nombre variable étant chacune stockées dans une table annexe de la base de données. En général, ces systèmes permettent en outre de cascader les données en nombre variable, c'est-à-dire que chaque ensemble ou enregistrement de données en nombre variable peut être à son tour associé à d'autres données en nombre variable. En outre, ces systèmes de gestion de base de données offrent habituellement des possibilités d'interrogation sophistiquée, et de bonnes performances, même sous forte charge. En l'absence de systèmes efficaces de gestion de bases de données orientés objets, il est tentant d'utiliser les systèmes de gestion de bases de données relationnelles du commerce pour la gestion et le stockage ou la gestion d'objets. Toutefois, ces systèmes sont mal adaptés à la gestion d'objets. En effet, dans ces systèmes traditionnels, les données sont stockées dans des tables d'ensembles de données ayant une structure fixe, ces ensembles de données étant constitués de données simples. Cela signifie en particulier qu'il n'est pas possible d'imbriquer ou d'emboîter des ensembles de données à l'intérieur d'un autre, même si les ensembles de données sont en nombre fixe.
Ce dernier point pose problème pour la gestion d'objets en ce que l'emboîtement d'objets les uns à l'intérieur des autres est le fondement même de la gestion de données orientée objets. Il est théoriquement possible de résoudre ce problème automatiquement en mettant "à plat" la structure de l'objet, c'est-à-dire, en considérant que tous les éléments de sous-objets inclus dans un objet principal sont en fait des éléments de l'objet principal. Cela introduit un nouveau problème en ce que les noms d'éléments contenus dans des sous-objets distincts d'un même objet peuvent parfaitement être identiques et que les noms d'éléments dans un même objet doivent nécessairement être distincts, pour d'évidentes raisons de non-ambiguïté. Ce nouveau problème peut à son tour être résolu automatiquement en incluant le nom du sous-objet contenant dans le nouveau nom "à plat" d'un élément d'un sous-objet. En pratique, cela revient à ajouter les noms de tous les objets contenants à l'élément contenu pour obtenir un nom "à plat" non ambigu.
Malheureusement, cette technique conduit rapidement à des noms "à plat" ayant une longueur de nom dépassant les limites autorisées par les systèmes de gestion de bases de données, même pour des éléments peu imbriqués, du fait que ces systèmes imposent des limites de l'ordre de quelques dizaines de caractères sur la longueur des noms des données simples stockées dans une table. Cette nouvelle difficulté est habituellement résolue en tronquant le nom "à plat" obtenu à la longueur permise par le système. Toutefois, ce procédé conduit usuellement à des noms "à plat" dupliqués. La résolution définitive de ce problème implique habituellement une intervention manuelle d'un opérateur humain, qui définit lui-même les noms à utiliser dans le système de gestion de base de données, pour chaque élément d'objet imbriqué. De façon évidente, cette intervention manuelle est sujette à erreur et elle est coûteuse en temps humain. Par ailleurs, la technique consistant à utiliser une table annexe pour chaque partie en nombre variable d'un objet conduit rapidement à des performances déplorables lorsqu'un objet comporte de nombreuses parties en nombre variable, comme c'est souvent le cas en pratique. En effet, chaque accès à un objet stocké dans la base de données requerra un accès à la base de données pour la table principale plus autant d'accès à la base de données qu'il y a de tables annexes, c'est-à-dire, de parties d'objets en nombre variable dans un objet. Si l'objet comporte, comme il est fréquent, cinq ou dix parties en nombre variable, le nombre d'accès à la base de domiées sera multiplié par cinq ou dix par rapport à un objet n'ayant pas de parties variables, ce se traduit par une dégradation des performances dans un même rapport. Cette dégradation peut devenir critique dans les systèmes de stockage de données très sollicités, tels que les serveurs Internet, car il n'est pas toujours possible de dupliquer les serveurs pour répartir la charge, en particulier lorsque les données présentes sur un serveur peuvent être modifiées. En outre, cela augmente dans les mêmes proportions la fragilité du système de stockage vis-à-vis d'une panne de courant ou de tout autre problème système entraînant un arrêt inopiné du système informatique hébergeant la base de données. Il existe donc un besoin pour un procédé qui permette d'adapter les systèmes de gestion de base de données relationnelles existants aux spécificités du stockage d'objets, en gérant automatiquement les limites imposées sur la longueur des noms des données simples stockées dans les tables et limitant le nombre de tables annexes utilisées pour conserver de bonnes performances au système de stockage d'objets dans son ensemble.
La présente invention a donc pour objet de proposer un procédé et un système qui permettent de limiter à une table principale et une table annexe le nombre de tables nécessaire pour stocker les données simples en nombre fixe et variable d'une collection d'objets informatiques présents dans un système de stockage de données.
La présente invention propose donc un procédé de stockage d'objets informationnels ou objets dans une base de données relationnelle stockée dans un ordinateur serveur, ladite base de données relationnelle étant constituée de tables, chaque table étant constituée d'un tableau d'ensembles de données simples, lesdits ensembles ayant la même structure de données dans une même table, chaque donnée simple d'une table étant désignée par un identifiant unique dans ladite table, un objet étant constitué d'une ou plusieurs données simples pouvant être stockées dans une table de ladite base de données, et/ou d'un ou plusieurs objets emboîtés dans ledit objet, ledit emboîtement pouvant être réalisé sur un nombre quelconque de niveaux pour réaliser un objet, un objet emboîté ou une donnée simple étant dit localement en nombre fixe s'il ou elle apparaît exactement une fois dans l'objet le ou la contenant immédiatement et étant dit localement en nombre variable dans le cas contraire, une donnée simple apparaissant à un niveau quelconque dudit objet étant dite globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets la contenant sont localement en nombre fixe, une donnée simple apparaissant à un niveau quelconque dudit objet étant dite globalement en nombre variable si elle est localement en nombre variable ou si l'un quelconque des objets la contenant est localement en nombre variable, lesdites données globalement en nombre fixe d'un objet à stocker étant stockées dans un ensemble de données principal stocké dans une table principale de ladite base de données, lesdites données simples globalement en nombre variable dudit objet à stocker étant stockées dans une ou plusieurs tables annexes de ladite base de données, qui a pour caractéristique le fait que, lorsqu'elles existent, les données simples globalement en nombre variable desdits objets sont stockées dans une unique table annexe de ladite base de données, le procédé créant un ou plusieurs ensembles de données annexes pour stocker lesdites données simples globalement en nombre variable dans ladite unique table annexe.
Dans ce procédé, chacun desdits un ou plusieurs ensembles annexes éventuellement stockés dans ladite unique table annexe peut comporter en outre un ensemble d'indicateurs booléens, chaque indicateur booléen étant associé à une donnée particulière desdites données simples globalement en nombre variable stockées dans ledit ensemble annexe, ledit indicateur booléen indiquant si ladite donnée simple globalement en nombre variable associée est définie ou non dans ledit ensemble annexe. Dans ce cas, certains desdits indicateurs booléens dudit ensemble d'indicateurs booléens pourront être communs à plusieurs données simples globalement en nombre variable lorsque lesdites données simples sont localement en nombre fixe dans un même objet les contenant immédiatement.
De préférence, ledit ensemble principal associé au dit objet à stocker comportera une donnée permettant d'identifier de façon unique ledit ensemble principal dans ladite table principale. De plus, ladite donnée unique pourra être unique dans ledit ordinateur serveur, et avantageusement, ladite donnée unique stockée dans ledit ensemble principal associé au dit objet à stocker sera en outre stockée dans chacun des ensembles annexes associés au dit objet à stocker, pour permettre la mise en relation dudit ensemble principal et du ou desdits ensembles annexes éventuels associés au dit objet à stocker.
De façon avantageuse, ladite donnée unique pourra être constituée du nom logique de l'ordinateur serveur sur ledit réseau, du numéro de table de ladite table principale dans ladite base de données et du numéro d'ensemble de données dudit ensemble principal dans ladite table principale, ledit nom logique de l'ordinateur serveur étant unique sur ledit réseau, ladite base de données étant unique sur ledit ordinateur serveur, ledit numéro de table de ladite table principale étant unique dans ladite base de données et ledit numéro d'ensemble de données dudit ensemble principal étant unique dans ladite table principale.
Dans le procédé, deux objets à stocker pourront être dits de même type s'ils sont constitués de données simples et d'objets emboîtés de même type, deux objets de même type ayant en commun un même identifiant et les données simples et/ou les objets emboîtés se correspondant à un niveau quelconque desdits objets de même type ayant en commun un même identifiant, unique dans l'objet les contenant immédiatement. Dans ce cas, le procédé pourra créer un identifiant global pour tous les objets de même type et pour toutes les données simples se correspondant à un niveau quelconque desdits objets de même type, ledit identifiant global étant ledit identifiant commun pour lesdits objets de même type, et ledit identifiant global étant obtenu, pour chacune desdites données simples se correspondant, par la concaténation des identifiants, dans les objets les contenant immédiatement, de tous les objets contenant ladite donnée simple, et de l'identifiant de ladite donnée simple dans l'objet la contenant immédiatement.
En outre, le nombre de caractères de cet identifiant global pourra être tronqué au nombre de caractères permis par ladite base de données pour l'identifiant d'une donnée stockée dans une table de ladite base de données. Egalement, une ambiguïté pouvant apparaître du fait de ladite troncature pourra être résolue en effectuant les étapes consistant à :
- remplacer le dernier caractère alphabétique de l'identifiant global par le chiffre zéro, ainsi que les éventuels chiffres le suivant ;
- augmenter d'une unité le nombre constitué par l'ensemble des chiffres apparaissant à la fin dudit identifiant global jusqu'à ce que l'ambiguïté disparaisse ou que les chiffres à la fin dudit identifiant global soient entièrement constitués de chiffres neuf ;
- répéter les étapes précédentes depuis le début lorsque les chiffres apparaissant à la fin dudit identifiant global sont entièrement constitués de chiffres neuf à l'issue de l'étape précédente.
Dans le procédé de l'invention, les objets stockés dans la base de données pourront être reçus ou transmis par l'ordinateur serveur via un réseau informatique de type Internet.
De préférence, les données simples constituant lesdits objets (6) stockés dans ladite base de données seront de type texte, et avantageusement, lesdites données simples de type texte seront des données écrites en langage XML. De plus, lesdites données écrites en langage XML pourront être conformes à une description de type XML Schéma.
En outre, un ensemble de données au format XML pourra être obtenu par une traduction automatique de ladite description, ledit ensemble de données et un ensemble de données complémentaire étant à leur tour traduits automatiquement en langage SQL pour définir et gérer la structure de la base de données, et pour contrôler les échanges de données avec ladite base de données.
Par ailleurs, dans le procédé de l'invention, une partie des données simples des objets reçus par ledit réseau de type Internet pourra être supprimée à l'aide d'un patron, ou modèle, d'objet écrit en langage XML, pour interdire la modification desdites données simples via ledit réseau.
Egalement, une partie des données simples des objets transmis via ledit réseau pourra être supprimée à l'aide d'un patron d'objet écrit en langage XML pour limiter la transmission sur ledit réseau à certaines données simples desdits objets. De plus, la suppression d'une partie des données simples contenues dans les objets permettra en outre d'optimiser les requêtes à ladite base de données.
L'invention propose en outre un système de stockage d'objets informationnels ou objets, dans une base de données relationnelle stockée par un ordinateur serveur, qui a pour caractéristique le fait qu'il met en œuvre le procédé selon l'une quelconques des revendications précédentes.
Un mode de réalisation préférentiel de l'invention va maintenant être décrit, à titre d'exemple seulement, en se référant aux dessins amiexés, dans lesquels :
- la figure 1 est le schéma fonctionnel du mode de réalisation préféré du procédé de stockage d'objets selon la présente invention ;
- la figure 2 est un schéma montant l'utilisation d'une table annexe unique pour les ensembles en nombre variable dans le mode de réalisation préféré du procédé de l'invention sur un cas d'exemple ; la figure 3 est un schéma montant l'utilisation d'un ensemble de tables annexes pour les ensembles en nombre variables dans la technique antérieure, sur le même cas d'exemple que celui de la figure 2.
Pour permettre la comparaison, un exemple de stockage d'objet de la technique antérieure sera également décrit. Dans les deux cas, on supposera, de façon non restrictive, que le système de gestion de base de données relationnelle, ou SGBDR, utilisé est mis en œuvre à l'aide du langage standard Structured Query
Language, ou SQL.
Par ailleurs, pour faciliter la compréhension, on décrira les opérations de stockage concernant un objet 6 d'exemple, tel qu'une entrée dans un annuaire comportant les informations suivantes : Entrée annuaire :
Nom, sur 40 caractères : OTOOBE Téléphone, sur 15 caractères : +33(0)1 44 34 85 03 Télécopie, sur 15 caractères : +33(0)1 44 34 85 01 Adresse : Rue, sur 40 caractères : 3bis, rue du Docteur-Foucault
Ville, sur 40 caractères : 92000 NANTERRE Adresse :
Rue, sur 40 caractères : 34, bd Haussmann Ville, sur 40 caractères : 75009 PARIS Contact, sur 40 caractères : M. Laurent QUEREL Contact, sur 40 caractères : M. Jean-François QUENTIN
Contact, sur 40 caractères : M. Gilles ANDRE
Dans cette entrée, les données "Adresse" et "Contact" sont supposées pouvoir figurer en nombre variable dans ledit objet 6 "Entrée annuaire", pour prendre en compte le fait qu'une entreprise peut comporter plusieurs établissement et plusieurs personnes à contacter. Pour la clarté de l'exposé, le nombre des domiées en nombre variable a été limité à deux dans cet exemple, mais ce nombre ne limite en rien la portée du procédé de la présente invention.
Les objets informationnels, ou objets, dont la structure de données n'est pas fixe, permettent de prendre en compte ce type de données en nombre variable,. ce qui fait toute la puissance de l'approche objet par rapport à une approche traditionnelle où la structure des domiées est fixe, et dans laquelle il est donc nécessaire de prévoir à l'avance un nombre maximal d'occurrences pour chaque donnée, au risque d'un coté de bloquer de façon gênante un cas particulier où un nombre d'occurrences plus important que celui prévu serait nécessaire, et d'un autre coté, de gaspiller inutilement de la place de stockage dans le cas général pour quelques cas particuliers peu fréquents.
Malheureusement, les systèmes de gestion de base de données classiques actuels ne permettent pas directement le stockage d'objets, c'est-à-dire de structures de domiées permettant l'emboîtement de sous-structures de données et des occurrences multiples pour les éléments de ces structures, ce qui nécessite un traitement particulier des données de l'objet 6 "Entrée annuaire" pour pouvoir le stocker dans la base de données 2.
Dans la technique antérieure, ce traitement consiste à séparer les données en nombre fixe "nom", "téléphone", "télécopie" et les données en nombre variable "rue", "ville" en stockant les données en nombre fixe dans une première table principale 3, et en stockant les données, ou ensembles de données, en nombre variable dans autant d'autres tables annexes qu'il existe de données, ou d'ensembles de données, en nombre variable dans l'objet 6.
Dans la technique antérieure, l'objet 6 de l'exemple précédent est alors stocké sous la forme indiqué à la figure 3, dans laquelle : la table 3 est la table principale stockant les ensembles 31 de domiées en nombre fixe constitués des données simples "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14 ;
- la table 4 est une première table annexe stockant les ensembles 41 constitués de la donnée simple "cle" 11 et de la donnée en nombre variable "adresse", c'est-à-dire, des données simples "rue" 15 et "ville" 16 ;
- la table 5 est une seconde table annexe stockant les ensembles de données constitués de la donnée "cle" 11 et de la donnée en nombre variable "contact" 17.
Plus précisément, dans l'exemple ci-dessus, la donnée "nom" ayant pour valeur "OTOOBE" sera stockée en 12, la donnée "téléphone" ayant pour valeur "+33(0)1 44 34 85 03" sera stockée en 13, la donnée "télécopie" ayant pour valeur "+33(0)1 44 34 85 01" sera stockée en 14, la donnée "rue" du premier sous-objet "adresse", ayant pour valeur "3bis, rue du Docteur-Foucault", sera stockée en 15ls la donnée "ville" du premier sous-objet "adresse", ayant pour valeur "92000 NANTERRE", sera stockée en 16ι, la donnée "rue" du second sous-objet "adresse", ayant pour valeur "34, bd Haussmann", sera stockée en 152, la donnée "ville" du second sous-objet "adresse", ayant pour valeur "75009 PARIS", sera stockée en 162, la première donnée "contact", ayant pour valeur "M. Laurent QUEREL", sera stockée en 17ι, la seconde donnée "contact", ayant pour valeur "M. Jean-François QUENTIN", sera stockée en 172 et la troisième donnée "contact", ayant pour valeur "M. Gilles ANDRE", sera stockée en 173.
La dom ée "cle" 11 apparaissant dans les trois tables 3, 4 et 5 est la clé primaire de ces tables, et son utilisation sera décrite plus loin.
Pour pouvoir utiliser ces données, il faut au préalable définir les tables 3, 4 et 5 dans la base de données 2, ainsi que les diverses données stockées dans ces tables 3, 4 et 5.
Dans la technique antérieure, pour créer la table 3, un opérateur devait typiquement indiquer manuellement au SGBDR une instruction SQL du type : CREATE TABLE "EntreeAnnuaire_main" ( cle INTEGER, nom VARCHAR(40), téléphone VARCHAR(15), télécopie VARCHAR(15),
PRIMARY KEY (cle)) Dans cette instruction, la rubrique "EntreeAnnuairejtnain" indique le nom, librement choisi par l'opérateur sous réserve d'unicité, de la table principale 3, et une rubrique "VARCHAR(n)" indique une chaîne de caractères de longueur variable et de longueur maximale n. La donnée "cle" 11 est la clé primaire évoquée ci-dessus et qui sera décrite plus loin, et la rubrique "PRIMARY KEY(cle)" indique précisément au système que cette donnée "cle" 11 est la clé primaire.
De même, dans la technique antérieure, pour créer les tables 4 et 5, un opérateur devait typiquement indiquer manuellement au SGBDR des instructions SQL du type : CREATE TABLE "EntreeAnnuaire " ( cle INTEGER, rue VARCHAR(40), ville VARCHAR(15), PRIMARY KEY (cle)) et :
CREATE TABLE "EntreeAnnuaire_2" ( cle INTEGER, contact VARCHAR(40), PRIMARY KEY (cle)) dans lesquelles les rubriques "EntreeAnnuaire_l " et "EntreeAnnuaire_2" sont les noms respectifs, librement choisis, des tables annexes 4 et 5.
En outre, l'opérateur devait définir également manuellement les données indexées, c'est-à-dire les données dont le contenu pourra permettre de retrouver une entrée de l'annuaire, au moyen d'instructions SQL du type : CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) qui indique au SGBDR de faire en sorte qu'une entrée d'annuaire puisse être retrouvée par le contenu de la rubrique "nom" de la table principale 3 "EntreeAnnuairejmain" .
De plus, dans le cas d'objets 6 comportant de nombreux niveaux d'emboîtement et de nombreuses données en nombre variable comme c'est souvent le cas en pratique, le nombre de tables annexes était élevé, et la numérotation ou la dénomination des tables annexes était beaucoup plus complexe que celle présentée dans l'exemple précédent. A nouveau, cette numérotation ou cette dénomination nécessitait une intervention manuelle d'un opérateur, avec les risques d'erreur inhérents à toute opération manuelle. En se référant aux figures 1 et 2, on va maintenant décrire le procédé de stockage selon le mode de réalisation préféré de l'invention, qui est mis en œuvre par divers modules de programmes globalement dénommés Collective Operating System ou COS dans ce document. En revenant à l'exemple précédent, le procédé de l'invention gère l'ensemble
31 de données simples en nombre fixe "cle" 11, "nom" 12, "téléphone" 13, et "télécopie" 14 dans la table principale 3 de la même manière que dans la technique antérieure, c'est-à-dire en utilisant directement les primitives adéquates du SGBDR utilisé. Par contre, la gestion des données simple en nombre variable est effectuée à l'aide d'une unique table 7, au lieu des tables 4 et 5. Pour cela, le procédé de l'invention stocke la première occurrence d'une donnée simple en nombre variable dans un premier ensemble de données 71] de la table 7, la seconde occurrence d'une donnée simple en nombre variable dans un second ensemble de données 71 de la table 7, la troisième occurrence éventuelle d'une donnée simple en nombre variable dans un troisième ensemble de données 713, etc.. On voit alors que la structure de données de la table 7, c'est-à-dire la structure des ensembles de données 71, doit nécessairement comporter au moins l'union des données simples en nombre variable dans un objet 6. Comme dans la technique antérieure, la donnée "de" 11 apparaissant dans les deux tables 3 et 7 est la clé primaire de ces tables, et son utilisation sera décrite plus loin.
En revenant à l'exemple précédent, le procédé stocke donc la donnée première occurrence de la donnée simple "rue" de l'objet 6 dans l'emplacement 15χ de l'ensemble 71 ! de la table 7, il stocke la première occurrence de la donnée "ville" dans l'emplacement \6\ de l'ensemble 71 \ de la table 7, il stocke la seconde occurrence de la donnée "rue" dans l'emplacement 15 de l'ensemble 712, il stocke la seconde occurrence de la donnée "ville" 162 dans l'emplacement 162 de l'ensemble 712, il stocke la première occurrence de la donnée "contact" \7\ dans l'emplacement \7\ de l'ensemble 7115 il stocke la seconde occurrence de la donnée "contact" 172 dans l'emplacement 172 de l'ensemble 71 , et il stocke la troisième occurrence de la donnée "contact" 17 dans l'emplacement 17 de l'ensemble 713.
Toutefois, on voit dans ce qui précède que les emplacements correspondants aux données simples "rue" et "ville" aux emplacements 153 et 163 dans l'ensemble de données simples 713 ne sont pas remplis, ce qui est dû au fait qu'il n'y a que deux ensembles de données en nombre variable "me" et "ville", et qu'il y a trois données en nombre variable "contact". Cela pose un problème en ce sens que si les ensembles de données simples 71 ls 712, 713 étaient stockés en l'état dans la base de données, l'information concernant quels emplacements sont remplis et quels emplacements sont vides serait longue et difficile à déterminer. Il serait en effet nécessaire de tester la nullité des colonnes de l'ensemble de ces données simples nombre variable pour déterminer l'absence ou la présence de ces données en nombre variable.
Pour résoudre ce problème, le procédé selon l'invention réservera en outre, dans chaque ensemble 71, des emplacements de données pour stocker cette information de présence ou d'absence pour chaque donnée en nombre variable dans cet ensemble 71.
En pratique, dans le cas de données simples en nombre fixe, telles que "rue" et "ville" associées dans un même sous-objet contenant tel que "adresse", les données simples en nombre fixe associées seront toujours présentes ou absentes simultanément, ce qui signifie que le procédé pourra optimiser le nombre d'indicateurs en ne stockant qu'un seul indicateur par ensemble de données en nombre fixe associées.
Dans ces conditions, lors de la création de la table 7, le procédé ajoute dans la structure de données de la table 7, c'est-à-dire dans chaque ensemble 71, une donnée booléenne pour chaque ensemble de données en nombre variable dans l'objet 6. Dans l'exemple décrit, l'ensemble de données simples 72 constitué des données simples booléennes 20 et 21 est ainsi ajouté à chaque ensemble 71, la donnée booléenne 20 indiquant la présence, dans l'ensemble 71 considéré, de l'ensemble constitué des données simples "rue" 15 et "ville" 16, et la donnée booléenne 21 indiquant la présence, dans l'ensemble 71 considéré de la donnée "contact" 17. Ainsi, les informations de présence ou d'absence des données ou des ensembles de données en nombre variable seront conservées lors de l'écriture d'un objet 6, et le procédé pourra utiliser ces informations lors des relectures ultérieures, pour reconstituer correctement l'objet 6 tel qu'il était au moment de son enregistrement. On notera qu'avec le procédé de l'invention, le nombre d'ensembles de donnée présents dans l'unique table annexe est égal au maximum des nombres des données en nombre variable dans l'objet 6, alors que ce nombre d'ensembles de données dans les tables annexes est égal à la somme des nombres de données en nombre variable de l'objet 6 dans la technique antérieure, c'est-à-dire un nombre touj ours plus élevé . Par ailleurs, dans le mode de réalisation préférentiel, le procédé est utilisé pour stocker des objets 6 écrits en langage XML qui sont conformes à une description 92 de type XML Schéma, ce qui signifie en particulier que cette description est elle-même écrite dans le langage XML. Cette description 92, dénommée COSSchema dans le mode de réalisation préférentiel, décrit la structure de données des objets 6. L'intérêt de cette description XML Schéma 92 est de constituer une définition de référence unique pour la structure des objets 6, modèle qui sera utilisé chaque fois qu'il sera nécessaire de vérifier la structure ou la validité des objets 6. Dans le mode de réalisation préférentiel, un certain nombre de définitions d'objets utilisées dans le schéma COSSchema 92 sont dérivées à partir de définitions stockées dans un autre schéma XML Schéma 91, dénommé COSCoreSchema.
L'intérêt de cette approche est de permettre au COS d'uniformiser les définitions de certains objets en leur donnant une base commune, et de pouvoir éventuellement effectuer un certain nombre de travaux, en particulier de maintenance, de façon homogène sur ces objets. Par exemple, s'il s'avère nécessaire d'introduire une nouvelle donnée simple ou de modifier une donnée simple existante dans un type de base défini dans le COSCoreSchema, il ne sera pas nécessaire de. reproduire la nouvelle donnée simple ou la modification dans tous les objets basés sur ce type, et la modification sera implicitement reproduite via la seule référence au type de base. Ainsi, les risques d'erreur au niveau de la structure des objets COS seront réduits d'autant, et la maintenance de ces objets s'en trouvera facilitée.
En revenant à l'exemple d'entrée d'annuaire vue précédemment, dans le mode de réalisation préféré de l'invention, celle-ci sera constituée d'un objet 6, se présentant en langage XML sous la forme suivante : <entree_annuaire>
<nom>OTOOBE</nom> <telephone>+33(0)l 44 34 85 03</telephone> <telecopie>+33(0)l 44 34 85 01</telecopie> <adresse>
<rue>3bis, rue du Docteur-Foucault</rue> <ville>92000 NANTERRE</ville> </adresse> <adresse> <rue>34, bd Haussmann</rue>
<ville>75009 PARIS</ville> </adresse>
<contact>M. Laurent QUEREL</contact> <contact>M. Jean-François QUENTIN</contact> <contact>M. Gilles ANDRE</contact> </entree_annuaire>
Cet objet sera typiquement conforme à un fragment du COSSchema, qui est de type XML Schéma, se présentant sous la forme suivante : <type name="entree_annuaire">
<element name- 'nom" minOccurs="l"> <datatype source="string">
<length value="40"/> </datatype> </element>
<element name- 'telephone" minOccurs=" 1 "> <datatype source="string">
<length value="15"/> </datatype> </element>
<element name="telecopie" minOccurs="l"> <datatype source="string">
<length value="15"/> </datatype> </element>
<type name="adresse" minOccurs=" 1 " maxOccurs="*"> <element name- 'rue" minOccurs=" 1 ">
<datatype source- ' string"> <length value="40"/> </datatype> </element> <element name- 'ville" minOccurs- ' 1 ">
<datatype source="string"> <length value="407> </datatype> </element> </type>
<element name- 'contact" minOccurs="0" maxOccurs="*"> <datatype source- 'string"> <length value≈"40"/> </datatype> </element> </type>
Dans cette définition XML Schéma, le paramètre 'minOccurs' d'une donnée simple ou d'un sous-objet emboîté indique le nombre minimum de fois où la donnée concernée apparaît dans l'objet immédiatement contenant, et le paramètre 'maxOccurs' d'une donnée simple ou d'un sous-objet emboîté indique le nombre maximum de fois où la donnée concernée apparaît dans l'objet immédiatement contenant. Par défaut, c'est-à-dire lorsque 'maxOccurs' n'apparaît pas, il est supposé être égal à 1.
La signification de 'maxOccurs- '*'" est que la donnée ou le sous-objet concerné peut apparaître un nombre quelconque de fois dans l'objet immédiatement contenant.
Dans le mode de réalisation préféré de l'invention, le procédé utilise cette description au format XML, en association avec le procédé de stockage d'objets dans seulement deux tables qui a été décrit plus haut, pour générer automatiquement des instructions SQL pour créer et gérer les données de la base de données 2 représentant les objets stockés.
Pour cela, le procédé de l'invention part du COSSchema et il applique un certain nombre de règles pour obtenir un format XML Schéma étendu, dénommé XDB Schéma, comparable à celui de l'exemple décrit ci-dessus. En effet, dans le COSSchema, la description des données est faite, de façon structurée, en se référant à d'autres types prédéfinis, tels que les types définis dans le COSCoreSchema ou à des types intermédiaires définis dans le COSSchema lui-même. Pour rendre utilisables dans le langage SQL utilisé les informations présentes dans le COS Schéma, le procédé de l'invention, applique donc à ce schéma COS Schéma un certain nombre de règles de traduction lui permettant de passer d'une représentation comportant des types non simples à une représentation ne comportant plus que des types simples. Le résultat de cette traduction constitue le schéma XDB Schéma.
Toutefois, le schéma XDB Schéma obtenu précédemment n'est pas suffisant à lui seul pour définir complètement la structure de l'objet 6 dans la base de données
2 : en effet, il manque les informations permettant de définir les domiées de l'objet 6 qui seront indexées. Pour résoudre ce problème, le procédé de l'invention utilise un schéma XML 96 complémentaire, dénommé XDB Mapping, décrivant les données à indexer dans les tables stockant les données de l'objet 6.
Ce schéma XDB Mapping 96 reprend la structure du schéma COSSchema en la limitant aux données devant faire l'objet d'une indexation. Ainsi, dans l'exemple précédent où la donnée "nom" devait être indexée, le fragment correspondant dans le XDB Mapping sera du type suivant : <type name="entree_amιuaire">
<element name- 'nom" sql:indexname="IndexNom" sql:indexType="...'7> </type> où la rubrique "sqhindexname" indique le nom de l'index à créer, ici "IndexNom", et où la rubrique "sqlrindexType" sert à indiquer, sous une syntaxe adéquate, des paramètres pour l'index à créer, tels que "ordre de tri croissant", "pas de distinction minuscules/majuscules", etc.. Ainsi, avec ce schéma XDB Schéma, le procédé de l'invention possède toutes les informations utiles pour créer automatiquement dans la base de données 2 toutes les données nécessaires pour l'objet 6 à créer.
Ensuite, le procédé traduit ces schémas XDB Schéma et XDB Mapping en instructions SQL à destination du SGBD gérant la base de données 2.
Toutefois, avant de pouvoir mener à bien cette opération, un autre problème, lié aux possibilités offertes par les objets, doit être résolu. En effet, l'approche orientée objet permet à des données simples, ou à des sous-objets, contenus dans des sous-objets distincts d'avoir le même identifiant, pourvu que cet identifiant soit unique dans le sous-objet, ou l'objet 6, les contenant immédiatement. Cette possibilité de noms dupliqués dans des sous-objets différents interdit d'utiliser directement ces identifiants comme identifiants globaux de données dans la base de données 2, car deux données distinctes d'une même table pourraient alors recevoir le même identifiant, ce qui est interdit par tous les SGBDR existants.
Pour résoudre ce problème, le procédé crée pour chaque donnée simple un identifiant global obtenu en préfixant l'identifiant de la donnée simple, tel qu'il apparaît dans la rubrique 'name- '...'" de la définition de la donnée simple dans le schéma XDB Schéma, par la concaténation des identifiants, tels qu'il apparaissent dans les rubriques 'name- '...'" des définitions correspondantes du schéma XDB Schéma, de tous les sous-objets contenant, à une niveau ou un autre, la donnée simple considérée. Ce procédé lève l'ambiguïté qui pourrait apparaître, car du fait que les identifiants des données simples ou des sous-objets dans leurs objets immédiatement contenant sont distincts, deux identifiants globaux obtenus de cette façon sont nécessairement distincts globalement. Ainsi, dans l'exemple ci-dessus, l'identifiant global de la donnée "nom" sera "nom" lui-même, puisque la donnée simple "nom" n'est pas contenue dans un sous- objet ; par contre, l'identifiant global de la donnée "rue" contenue dans le sous-objet "adresse" sera "adressej ie". Dans ce qui précède, on a indiqué que les identifiants des données créées dans les tables 3 et 7 de la base de données 2 était la concaténation des identifiants de la donnée et de tous les sous-objets la contenant dans l'objet 6. Toutefois, cela pose problème en ce que la longueur de ces identifiants est habituellement limitée par les SGBDR classiques à une valeur assez basse, de l'ordre de quelques dizaines de caractères, et que, pour des objets comportant un niveau d'emboîtement même modéré, cette limite est très vite atteinte.
Pour résoudre ce problème, le procédé de l'invention tronque les identifiants précédemment obtenus à la longueur permise par le SGBDR pour les identifiants de données d'une table. A l'issue de cette troncature, si l'identifiant global obtenu est déjà présent dans la table où il devait être créé, le procédé de l'invention réalise les étapes suivantes :
1°/ le dernier caractère alphabétique de l'identifiant global précédemment obtenu est remplacé par le chiffre "0", ainsi que tous les chiffres le suivant éventuellement ; 2°/ si l'identifiant global ainsi obtenu est encore présent dans la table, le nombre constitué par l'ensemble des chiffres apparaissant à la fin de l'identifiant global est augmenté d'une unité et l'étape 2 est répétée tant qu'un nombre entièrement constitué de chiffres "9" n'a pas été atteint ;
3°/ si un nombre entièrement constitué de chiffres "9" est atteint à l'étape 2, alors le procédé retourne à l'étape 1.
Les étapes 1°/ à 3°/ précédentes sont répétées jusqu'à ce qu'un identifiant global, nouveau dans la table considérée, soit trouvé.
Ainsi, le procédé ci-dessus décrit permet de lever les ambiguïtés, dans les identifiants globaux attribués aux données simples stockées dans la base de données 2, qui peuvent apparaître du fait de la possibilité de duplication d'un identifiant de donnée ou de sous-objet dans des sous-objets distincts.
En utilisant ce procédé de génération d'identifiants globaux pour les données simples d'un objet 6, le procédé relit alors en parallèle le schéma XDB Schéma et XDB Mapping, et pour chaque nouveau type d'objet à créer 6 trouvé dans le schéma XDB Schéma, il applique le procédé suivant : - le procédé crée alors dans la base de données une table principale 3 portant le nom de l'objet 6, suivi du suffixe "_main", comportant une donnée "cle" 11 servant à identifier de façon unique dans la base de données un objet 6 ; ainsi, lorsqu'il rencontre dans le schéma XDB Schéma la définition :
<type name- 'entree_annuaire">
</type> le procédé crée la table principale 3 "EntreeAnnuaire_main" correspondante par l'instruction SQL :
CREATE TABLE "EntreeAnnuaire_main" (cle INTEGER,
PRIMARY KEY (cle))
- ensuite, le procédé explore les définitions "<element ...>... </element>" du schéma XDB Schéma, XDB Schéma et pour chaque donnée simple rencontrée, telles que "nom" ou "contact", il détermine si cette donnée est en nombre fixe ou variable ; une donnée simple sera dite en nombre fixe si sa rubrique "maxOccurs" est absente de la définition et si cette donnée simple n'est pas contenue à un niveau quelconque dans un sous-objet en nombre variable, c'est-à-dire un sous-objet dont la rubrique "maxOccurs" serait présente et différente de la rubrique "minOccurs" dudit sous-objet ; une donnée sera dite en nombre variable dans le cas contraire, c'est-à-dire si elle n'est pas en nombre simple au regard de la définition précédente ;
- lorsque le procédé rencontre une donnée en nombre fixe telle que la donnée "nom" dans l'exemple ci-dessus, il ajoute cette donnée en nombre fixe dans la table principale 3 à l'aide d'une instruction SQL telle que :
ALTER TABLE "EntreeAnnuaire_main" ADD nom VARCHAR(40) dans laquelle l'identifiant global "nom" est obtenu par le procédé décrit plus haut, et dans laquelle la longueur "40" apparaissant dans la rubrique "VARCHAR" est reprise de la '<length value- '...">' de la définition correspondante ; en outre, si le procédé trouve dans le schéma XDB
Mapping une définition d'index portant sur la donnée qu'il vient de créer dans la table principale, le procédé crée un index pour cette donnée à l'aide d'une instruction SQL adéquate telle que : CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) dans laquelle le nom de l'index "IndexNom" est celui retrouvé dans la rubrique "sqkindexname" de la définition correspondante du schéma XDB Mapping ; - lorsque le procédé rencontre une donnée en nombre variable telle que la donnée "contact" dans l'exemple ci-dessus, il effectue les opérations suivantes : " s'il n'existe pas déjà une table annexe 7 associée à cette table principale 3, il crée cette table annexe à l'aide d'une instruction SQL telle que : CREATE TABLE "EntreeAnnuaire_annex" (cle INTEGER,
PRIMARY KEY (cle)) " dans laquelle la donnée "cle" est la donnée servant à identifier de façon unique un objet 6 dans la base de données 2 ; " ensuite, le procédé crée la domiée correspondante dans la seconde table, en lui associant, de la façon décrite précédemment, une donnée booléenne "présence", permettant de savoir si la donnée correspondante est présente ou non dans l'ensemble de données 71 considéré ; par exemple, pour la donnée en nombre variable "contact" 17, cette création sera réalisée à l'aide d'une instruction SQL telle que :
ALTER TABLE "EntreeAnnuaire_annex" ADD contact VARCHAR(40), ADD presence_contact BOOLEAN " dans laquelle l'identifiant global est obtenu par le procédé décrit plus haut, et dans laquelle longueur "40" apparaissant dans la rubrique "VARCHAR" est reprise de la rubrique '<length value- '... ">' de la définition correspondante dans le schéma XDB
Schéma ;
" dans le cas d'une donnée incluse dans un sous-objet comme la donnée "rue", l'identifiant global sera obtenu comme indiqué précédemment, et l'instruction SQL correspondante sera, par exemple :
ALTER TABLE "EntreeAnnuaire_annex" ADD adresse_rue VARCHAR(40), ADD presence_adresse_rue BOOLEAN. Le procédé répète les opérations précédentes jusqu'à ce que toutes les définitions présentes dans le schéma XDB Schéma 61 aient été traitées. A l'issue de ce traitement, le procédé aura donc créé automatiquement la structure d'objets 6 dans la base de données 2, telle qu'elle était décrite dans le schéma COS Schéma.
Dans le mode de réalisation de la présente invention, les aspects ci-dessus du procédé de l'invention sont implémentés dans un programme 90 dénommé XBD Engine, et, contrairement à la technique antérieure, le procédé de l'invention permet de réaliser la création de nouveau type d'objet 6 dans la base de données 2 sans intervention manuelle d'un opérateur, ce qui se traduit par un gain de temps très appréciable et une diminution considérable du risque d'erreur, tant pour la création que pour la modification, dans la base de données, de la structure d'un objet 6. Dans ce qui précède, on a décrit le procédé de l'invention comme transformant le schéma COSSchema, comportant des types prédéfinis, en un schéma XML, le schéma XDB Schéma, ne comportant plus que des types de données simples tels qu'utilisés par le SGBDR. Cela a été fait dans l'optique de l'utilisation d'un langage SQL de base, qui ne connaît pas de types autres que ces types simples. Toutefois, dans le cas de l'utilisation d'un langage SQL évolué, tel que le langage SQL 3, le procédé de l'invention tirera naturellement parti des possibilités de typage offertes par ce langage en ne traduisant en types plus simples que les types ne pouvant pas être "compris" directement par le langage SQL utilisé. Les types utilisés par le COS Schéma et pouvant être traduits directement en types SQL, le seront à l'aide d'une instruction SQL adéquate, telle que : CREATE TYPE ...
Dans ce qui précède, on a décrit sur un exemple les étapes de création d'un nouveau type d'objet 6 à stocker dans la base de données 2, tant dans la technique antérieure que dans le procédé de l'invention. Les informations contenues dans COSSchema et XDBSchema seront bien évidemment réutilisées pour modifier la structure d'un objet 6 déjà existant dans la base de données 2, après que les modifications voulues y aient été apportées. Cette modification de la structure d'un type d'objet 6 déjà existant est en tout point similaire à la création précédemment décrite. Ainsi, par exemple, pour modifier une table 3' existante et y ajouter un nouveau champ, l'instruction SQL utilisée, tant dans la technique antérieure que dans le procédé de l'invention :
CREATE TABLE ... sera remplacée, par exemple, par l'instruction SQL :
ALTER TABLE "EntreeAnnuaire_main" ADD télex VARCHAR(15), DROP télécopie qui indique qu'une donnée "télex" sur quinze caractères doit être ajoutée et que la donnée "télécopie" doit être supprimée.
De même, la suppression de l'index sur la donnée "nom" dans la table 3 se ferait, tant dans la technique antérieure que dans le procédé de l'invention, par l'instruction SQL :
DROP INDEX Entrée Annuaire. IndexNom
Dans le cas du procédé de l'invention, à nouveau ces modifications sont effectuées de façon automatique par le programme XDB Engine.
Compte-tenu de ces similitudes, la modification de la structure d'un objet 6 stocké dans la base de données 2 par le procédé de l'invention ne sera pas décrite plus en détail.
Dans ce qui suit, on va maintenant décrire le fonctionnement du procédé selon la présente invention en comparaison avec la technique antérieure pour le stockage et la gestion des données en nombre variable d'un objet 6. En se référant aux figures 2 et 3, un système de stockage des données simples d'un objet 6, dans la technique antérieure comme dans le procédé de l'invention, est constitué d'un ordinateur 1 hébergeant une base de données relationnelle 2. Les ensembles de domiées simples d'une table principale telle que la table principale 3, ou ceux d'une table annexe telles que les tables 4, 5 ou 7, sont gérés à l'aide des fonctions offertes par le système de gestion de base de données relationnelle ou SGBDR, utilisé pour la gestion de la base de données 2.
Ces fonctions comprennent au minimum une fonction d'écriture ou de création d'un ensemble de domiées simples dans une table, une fonction de lecture d'un ensemble de données simples depuis une table, une fonction de suppression d'un ensemble d'une table, et une fonction de recherche d'un ensemble par son contenu, la fonction de modification d'un ensemble pouvant être assimilée, pour la simplicité de l'exposé, à une lecture de l'ensemble suivie d'une écriture de l'ensemble modifié. Par conséquent, cette fonction ne sera pas décrite davantage.
Dans ce qui suit, on va comparer les performances, en termes de nombres d'ensembles de données échangés avec la base de données 2, respectivement pour la technique antérieure et le procédé de l'invention.
En se référant à la figure 3, dans la technique antérieure, la base de données
2 comporte une table principale 3 stockant les ensembles 31 de données simples en nombre fixe "nom" 12, "téléphone" 13 et "télécopie" 14, et cette table principale est en relation avec deux tables annexes 4 et 5 contenant les ensembles 41 et 51 de domiées simples en nombre variable, respectivement les ensembles 41 constitués des données simples "rue" 15 et "ville" 16 pour la table annexe 4, et les ensembles 51 constitués de la donnée "contact" 17 pour la table annexe 5.
De façon classique, une donnée d'identification unique "cle" 11, présente dans les ensembles 31, 41 et 51 respectivement stockés dans les tables 3, 4 et 5, est utilisée pour mettre en relation, c'est-à-dire faire se référencer, la table principale 3 et les tables annexes 4 et 5.
1°/ Ecriture d'un objet 6 dans la base de données 2
L'écriture, ou création, d'un objet identifié par une valeur unique telle que 1234 et comportant les domiées simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14, associées aux données simples "rue" 15, "ville" 16 et "contact" 17 en nombre variable, comportera classiquement les étapes suivantes :
- écriture de l'ensemble principal 31 constitué des données simples "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14 dans la table 3 à l'aide de la fonction correspondante du SGBDR, en initialisant la donnée "cle" 11 à la valeur 1234 ; cela pourra être réalisé, par exemple, à l'aide d'une instruction SQL telle que :
INSERT INTO "EntreeAnnuairejtnain" (cle, nom, téléphone, télécopie) VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 01") - écriture de deux ensembles 41 constitués des données simples en nombre variable 15 et 16 à l'aide de la fonction correspondante du SGBDR, en initialisant dans chacun la donnée "cle" 11 à la valeur 1234, c'est-à-dire, écriture des deux ensembles 4L et 41 constitués respectivement des données simples "cle" 11, "rue" 15ι, "ville" 16ι d'une part, et des données simples "cle" 11, "rue" 15 , "ville" 162 d'autre part ; cela pourra être réalisé, par exemple, par les instructions SQL :
INSERT INTO "EntreeAnnuaire " (cle, rue, ville) VALUES (1234, "3bis, rue du Docteur-Foucault", "92000 NANTERRE") et : INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, "34, bd Haussmann", "75009 PARIS")
- écriture de trois ensembles 51 à l'aide de la fonction correspondante du
SGBDR, en initialisant la donnée "cle" 11 à la valeur 1234, c'est-à-dire, écriture des trois ensembles 51l5 512 et 5I3 constitués respectivement des données simples "cle" 11 et "contact" 171 pour le premier, des données simples "cle" 11 et "contact" 172 pour le second, et "cle" 11 et "contact" 17Î pour le troisième ; cela pourra être réalisé, par exemple, par les instructions SQL :
INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. Laurent QUEREL") INSERT INTO "EntreeAnnuairej2" (cle, contact) VALUES (1234, "M.
Jean-François QUENTIN") et :
INSERT INTO "Entrée Annuaire_2" (cle, contact) VALUES (1234, "M. Gilles ANDRE") On constate que, dans la technique antérieure, on effectue donc une opération d'écriture pour stocker l'ensemble 31, deux opérations d'écriture pour stocker les ensembles 41, et trois écritures pour stocker les ensembles 51, soit un total de six écritures pour stocker l'ensemble des données correspondant à l'objet à stocker 6. 2°/ Lecture d'un objet 6 dans la base de données 2
La lecture d'un objet 6, ayant pour donnée unique "cle" 11 une valeur donnée telle que 1234, et comportant les données simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14, associées aux données simples "rue" 15, "ville" 16 et "contact" 17 en nombre variable, se fera classiquement par les étapes suivantes : - lecture, à l'aide de la fonction correspondante du SGBDR, de l'ensemble principal 31, constitué des données simples "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14, dont la donnée "cle" 11 a la valeur donnée 1234 ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234
- lecture, l'aide de la fonction correspondante du SGBDR, de tous les ensembles 41 de la table 4 comportant la valeur 1234 dans leur donnée "cle" 11, c'est-à-dire, lecture des deux ensembles 4L et 412 constitués respectivement des données simples "cle" 11, "rue" 15ι, "ville" 16ι d'une part, et des données simples "cle" 11, "rue" 152, "ville" 162 d'autre part ; cela pourra être obtenu, par exemple, à l'aide de l'instruction SQL : SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 cette instruction retrouvera alors les deux ensembles de données 41] et 412 ; - lecture des ensembles 51 à l'aide de la fonction correspondante du
SGBDR, en relisant tous les ensembles 51 de la table 5 comportant la valeur donnée 1234 dans leur donnée "cle" 11, c'est-à-dire, lecture des trois ensembles 51ls 512 et 513 constitués respectivement des données simples "cle" 11 et "contact" 17ι pour le premier, des données simples "cle" 11 et "contact" 172 pour le second, et "cle" 11 et "contact" 17t pour le troisième ; cela pourra être obtenu, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire_2" WHERE cle=1234 cette instruction retrouvera alors les trois ensembles de données 51ι, 512 et 513. De même que pour l'opération d'écriture, on constate que, dans la technique antérieure, on effectue donc au total de six opérations de lecture d'ensemble de données dans les tables 3, 4 et 5 pour relire l'ensemble des données correspondant à l'objet 6 à relire.
3 Suppression d'un objet 6 dans la base de données 2 La suppression d'un objet, constitué des données simples "cle" 11, "nom"
12, "téléphone" 13 et "télécopie" 14, ayant pour donnée "cle" 11 une valeur donnée, par exemple 1234, et comportant les données simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14, associées aux données simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, se composera classiquement des étapes suivantes :
- suppression de l'ensemble principal 31 ayant pour donnée "cle" 11 la valeur donnée 1234 à l'aide de la fonction correspondante du SGBDR ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : DELETE FROM "EntreeAnnuaire_main" WHERE cle=1234 - suppression des ensembles 41 ayant comme donnée "cle" 11 la valeur donnée 1234 à l'aide de la fonction correspondante du SGBDR, c'est-à- dire, suppression des deux ensembles 4L et 412 constitués respectivement des données simples "cle" 11, "rue" 15la "ville" 16] d'une part, et des données simples "cle" 11, "rue" 15 , "ville" 16 d'autre part ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL :
DELETE FROM "EntreeAnnuaire " WHERE cle=1234
- suppression des ensembles 51 ayant comme donnée "cle" 11 la valeur donnée 1234 à l'aide de la fonction correspondante du SGBDR, c'est-à- dire, suppression des trois ensembles 51ls 51 et 513 constitués respectivement des données simples "cle" 11 et "contact" 17] pour le premier, des données simples "cle" 11 et "contact" 172 pour le second, et "cle" 11 et "contact" 173 pour le troisième ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : DELETE FROM "EntreeAnnuaire_2" WHERE cle=1234 De même que pour les opérations d'écriture ou de lecture, on constate que, dans la technique antérieure, on effectue au total de six opérations de suppression d'ensemble de données dans les tables 3, 4, et 5 pour supprimer l'ensemble des données correspondant à l'objet 6 à supprimer.
47 Recherche d'un objet 6 dans la base de données 2
Toujours dans la technique antérieure, la recherche d'un objet ayant, par exemple, pour donnée 12 "nom" la valeur "OTOOBE", et comportant un ensemble
31 de données simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14 associées aux données simples "rue" 15, "ville" 16 et "contact" 17 présentes dans les ensembles 41 et 51, sera constituée classiquement des étapes suivantes :
- recherche, à l'aide de la fonction correspondante du SGBDR, de l'ensemble principal 31, constitué des domiées simples "cle" 11, "nom"
12, "téléphone" 13 et "télécopie" 14, dont la donnée 12 "nom" possède la valeur "OTOOBE" donnée ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" - lecture, à l'aide de la fonction correspondante du SGBDR, de tous les ensembles 41 de la table 4 ayant, dans leur donnée "cle" 11, la valeur contenue dans la donnée "cle" 11 de l'ensemble 31 venant d'être retrouvé dans la table 3, c'est-à-dire, lecture des deux ensembles 4L et 412 constitués respectivement des données simples "cle" 11, "rue" 15l3 "ville" 16ι d'une part, et des données simples "cle" 11, "rue" 152, "ville" 162 d'autre part ; en supposant que la valeur contenue dans la donnée "cle" 11 de l'ensemble 31 retrouvé précédemment soit égale à 1234, cela pourra être obtenu, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 - lecture, à l'aide de la fonction correspondante du SGBDR, de tous les ensembles 51 de la table 5 ayant dans leur donnée "cle" 11, la valeur contenue dans la donnée "cle" 11 de l'ensemble 31 venant d'être retrouvé dans la table 3, c'est-à-dire, lecture des trois ensembles 5L, 51 et 513 constitués respectivement des données simples "cle" 11 et "contact" 17] pour le premier, des données simples "cle" 11 et "contact" 172 pour le second, et "cle" 11 et "contact" 17] pour le troisième ; en supposant toujours que la valeur contenue dans la donnée 1 "cle" de l'ensemble 31 retrouvé soit égale à 1234, cela pourra être obtenu, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire__2" WHERE cle=1234 De même que pour les opérations d'écriture, de lecture ou de suppression, on constate que, dans la technique antérieure, on relit au total de six ensembles de données depuis les tables 3, 4 et 5 pour retrouver l'ensemble des données correspondant à l'objet 6 recherché.
En se référant maintenant à la figure 2, dans le procédé de l'invention, la base de données 2 comporte une table principale 3 stockant les ensembles 31 de données simples en nombre fixe "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14, et cette table principale est en relation avec une unique table annexe 7 contenant les ensembles 71 de données simples en nombre variable, constitués des domiées simples "contact" 17. De façon classique, une donnée d'identification unique "cle" 11, présente dans les ensembles 31 et 71 respectivement stockés dans les tables 3 et 7, est utilisée pour mettre en relation, c'est-à-dire faire se référencer, la table principale 3 et la table annexe 7, et pour identifier de façon unique un objet 6 dans la base de données 2.
1°/ Ecriture d'un objet 6 dans la base de données 2 L'écriture, ou création, d'un objet identifié par une valeur unique telle que
1234 et comportant les données simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14, associées aux données simples "rue" 15, "ville" 16 et "contact" 17 en nombre variable, comportera, dans le procédé de l'invention, les étapes suivantes : écriture de l'ensemble d'informations principal 31, constitué des domiées simples "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14, à l'aide de la primitive adéquate du SGBDR, ce qui conduit à une opération d'écriture pour cet ensemble 31 ; en supposant toujours que la valeur pour la donnée "cle" 11 soit 1234, cela pourra être réalisé à l'aide d'une instruction SQL telle que : INSERT INTO "EntreeAnnuaire_main" (cle, nom, téléphone, télécopie)
VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85
01")
- stockage de la valeur 1234 dans les données "cle" 11 des trois ensembles de données simples 71], 712, 713, stockage de la première donnée "rue" dans la donnée 15] de l'ensemble 71] de la table 7, stockage de la première donnée "ville" dans la donnée \6\ de l'ensemble 71], stockage de seconde donnée "rue" dans la donnée 15 de l'ensemble 71 , stockage de la seconde donnée "ville" dans la donnée 16 de l'ensemble 712, stockage de la première donnée "contact" dans la donnée 17] de l'ensemble 71], stockage de la seconde donnée "contact" dans la donnée 172 de l'ensemble 71 , et stockage de la troisième donnée "contact" dans la donnée 173 de l'ensemble 713 ;
- initialisation de la donnée 20] à la valeur booléenne VRAI puisque les données simples "rue" 15] et "ville" 16] correspondantes sont présentes dans l'ensemble 71 ls initialisation de la dom ée 21] à la valeur VRAI puisque la donnée "contact" 17χ correspondante est présente dans l'ensemble 71], initialisation de la donnée 202 à la valeur VRAI puisque les données simples "rue" 152 et "ville" 16 correspondantes sont présentes dans l'ensemble 712, et initialisation de la donnée 212 à la valeur VRAI puisque la donnée "contact" 17 correspondante est présente dans l'ensemble 712; par contre, initialisation de la donnée 203 à la valeur FAUX puisque les données simples "rue" 153 et "ville" 16 correspondantes sont absentes de l'ensemble 713 ; enfin, initialisation de la donnée 213 à la valeur VRAI puisque la donnée "contact" 173 correspondante est bien présente dans l'ensemble 713 ; - écriture les trois ensembles 711, 712, 713 dans la base de données 2 à l'aide d'instructions SQL telles que :
INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, presence_contact, rue, ville, contact) VALUES (1234, TRUE, TRUE, "3bis, rue du Docteur-Foucault", "92000 NANTERRE", "M. Laurent QUEREL")
INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, presence_contact, rue, ville, contact) VALUES (1234, TRUE, TRUE, "34, bd Haussmann", "75009 PARIS", "M. Jean-François QUENTIN") et :
INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, presence_contact, rue, ville, contact) VALUES (1234, FALSE, TRUE, "", "M. Gilles ANDRE") Ainsi, dans le procédé selon l'invention, le nombre d'écritures dans la base de données 2 est égal à quatre, au lieu de six dans la technique antérieure. 27 Relecture d'un objet 6 dans la base de données 2 La lecture d'un objet 6, ayant pour donnée unique "cle" 11 une valeur donnée telle que 1234, et comportant les données simples en nombre fixe "nom" 12,
"téléphone" 13, "télécopie" 14, associées aux domiées simples "rue" 15, "ville" 16 et
"contact" 17 en nombre variable, se fera, dans le procédé de l'invention, par les étapes suivantes :
- lecture, à l'aide de la fonction correspondante du SGBDR, de l'ensemble principal 31, constitué des données simples "cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14, dont la donnée "cle" 11 a la valeur donnée 1234, ce qui conduit à une opération de lecture pour cet ensemble ; cette opération de lecture pourra être réalisée, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 à l'aide des données présentes dans l'ensemble 31, le procédé de l'invention restitue les données fixes de l'objet 6 ; plus précisément, le procédé initialise la donnée en nombre fixe "nom" de l'objet 6 à l'aide de la donnée 12 présente dans l'ensemble 31 relu, il initialise la donnée en nombre fixe "téléphone" de l'objet 6 à l'aide de la donnée 13 de ce même ensemble, et il initialise la donnée en nombre fixe "télécopie" de l'objet 6 à l'aide de la donnée 14 ; - lecture, dans la table 7, des ensembles 71 de cette table comportant la valeur 1234 dans leur donnée "cle" 11 ; cela pourra être réalisé à l'aide d'un instruction SQL telle que :
SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 les trois ensembles de données 71], 71 , 713 sont ainsi relus, moyennant trois opérations de lecture d'ensemble de données dans la base de données
2 ; ainsi que cela a été décrit précédemment, ces trois ensembles 711, 712, 713 de données sont chacun constitués de la donnée "cle" 11, des données simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, et des données 20 et 21 indiquant respectivement la présence ou non de l'ensemble en nombre variable "rue", "ville" et de la dom ée en nombre variable "contact" dans l'ensemble 71 concerné ;
- reconstitution des données variables de l'objet 6 à l'aide des données présentes dans les ensembles de données 711, 71 , 713 précédemment relus ; pour cela, le procédé examine les données 20 et 21 dans chaque ensemble 711, 712, 713 relu ; " plus précisément, si le contenu de la donnée booléenne 20] contenue dans l'ensemble 711 est VRAI, cela signifie qu'il existait à l'origine un premier ensemble "rue", "ville" dans l'objet 6 stocké ; dans ce cas, le procédé selon l'invention créera alors un premier sous-objet en nombre variable "adresse" dans l'objet 6 ; il remplira les données en nombre variable "rue" et "ville" de ce premier sous- objet avec respectivement les données 15] et 16] contenues dans l'ensemble 71] ; de même, si le contenu de la donnée booléenne 21 ! est vrai, cela signifie qu'il existait à l'origine une première donnée en nombre variable "contact" dans l'objet 6 ; dans ce cas, le procédé de l'invention créera une première donnée en nombre variable "contact" dans l'objet 6 ; " en utilisant la même démarche que ci-dessus, le procédé de l'invention créera un second et un troisième sous-objet "adresse" en nombre variable "rue", "ville" si les contenus des données booléennes 202 et 203 contenues respectivement dans les ensembles 712 et 713 sont VRAI, et il initialisera les données "rue" et "ville" de ces second et troisième sous-objets en nombre variable "adresse" avec les données respectivement 152 et 162 d'une part, et 153 et 163 d'autre part respectivement contenues dans l'ensemble 712 et l'ensemble 713 ; " de même, le procédé de l'invention créera une seconde et une troisième donnée en nombre variable "contact" si les contenus des domiées booléennes 212 et 213 contenues respectivement dans les ensembles 712 et 713 sont VRAI, et il initialisera ces seconde et troisièmes domiées en nombre variable "contact" avec les données 172 et 173 respectivement contenues dans l'ensemble 71 et l'ensemble 713 ; " en supposant que les données relues proviennent de l'exemple d'écriture d'objet 6 précédemment décrit, les données simples 20],
20 , 2L, 21 et 21 seront à la valeur VRAI, tandis que la donnée 203 sera à la valeur FAUX ; dans ces conditions, le procédé de l'invention reconstituera exactement deux ensembles de données "adresse" en nombre variable dans l'objet 6 relu, ainsi que trois données en nombre variable "contact" ; l'objet 6 d'origine sera donc parfaitement reconstitué. Pour relire l'objet 6, le procédé effectue donc au total trois opérations de lecture d'ensembles de données dans la base de données 2, contre six pour la technique antérieure.
37 Suppression d'objet 6 dans la base de données 2 La suppression d'un objet ayant pour donnée "cle" 11 une valeur donnée, par exemple 1234, et comportant les données simples en nombre fixe "nom" 12, "téléphone" 13, "télécopie" 14, associées aux données simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, se composera, dans le procédé de l'invention, des étapes suivantes : - suppression de l'ensemble principal 31, constitué des données simples
"cle" 11, "nom" 12, "téléphone" 13 et "télécopie" 14, ayant pour donnée "cle" 11 la valeur donnée 1234, à l'aide de la fonction correspondante du SGBDR ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : DELETE FROM "EntreeAnnuairejmain" WHERE cle=1234
- suppression de l'ensemble annexe 71, ayant pour donnée "cle" 11 la valeur donnée 1234, à l'aide de la fonction correspondante du SGBDR ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : DELETE FROM "EntreeAnnuaire_annex" WHERE cle=1234 A nouveau, le nombre d'opérations de suppression d'ensembles de données par le SGBDR s'élève à un total de quatre dans le procédé de l'invention, contre six dans la technique antérieure.
47 Recherche d'un objet 6 dans la base de données 2
- recherche, à l'aide de la fonction correspondante du SGBDR, de l'ensemble principal 31, constitué des données simples "cle" 11, "nom"
12, "téléphone" 13 et "télécopie" 14, dont la donnée 12 "nom" possède la valeur "OTOOBE" donnée ; cela pourra être réalisé, par exemple, à l'aide de l'instruction SQL : SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" - lecture, à l'aide de la fonction correspondante du SGBDR, de tous les ensembles 71 de la table 7 ayant, dans leur donnée "cle" 11, la valeur contenue dans la donnée "cle" 11 de l'ensemble 31 venant d'être retrouvé dans la table 3, c'est-à-dire, lecture des trois ensembles 71], 712 et 713 ayant la structure de données précédemment décrite ; en supposant que la valeur contenue dans la donnée "cle" 11 de l'ensemble 31 retrouvé précédemment soit égale à 1234, cela pourra être obtenu, par exemple, à l'aide de l'instruction SQL :
SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 - reconstitution des données ou des sous-objets en nombre variable de l'objet 6 à relire à l'aide des données contenues dans les trois sous- ensembles relecture ; cette reconstitution est identique à celle décrite au paragraphe 27 ci-dessus ; en conséquence, elle ne sera pas décrite plus en détail. A nouveau, le nombre d'opérations de recherche d'ensembles de données par le SGBDR s'élève à un total de quatre dans le procédé de l'invention, contre six dans la technique antérieure.
Ainsi, dans les quatre opérations de base effectuées par un SGBDR, l'utilisation du procédé de l'invention permet une réduction d'un tiers du nombre d'opérations d'ensembles de données dans tous les cas. L'exemple présenté ci-dessus, volontairement simple pour des raisons de clarté de l'exposé, ne rend pas nécessairement bien compte des gains très importants que peut apporter le procédé dans un cas pratique comportant un nombre tables en relation beaucoup plus important.
Dans un cadre plus général, on désigne, dans ce qui suit, par Na le nombre de tables annexes T;, par Np le nombre total d'ensembles principaux 31 dans la table principale 3, et par K;, pour i variant de 1 à Na, le nombre total d'ensembles de données présents dans une table annexe T;.
Avec ces conventions, dans la technique antérieure, le nombre moyen d'opérations pour effectuer une entrée-sortie concernant un objet 6 dans une table Tj donnée sera, en moyenne, égal à K;/Na, et le total général pour une entrée-sortie complète comprenant l'ensemble principal 31 et les Na ensembles de données présents dans les Na tables annexes Tj sera donc égal à :
Figure imgf000032_0001
Dans le cas du procédé de la présente invention, le nombre d'entrées-sorties nécessaire pour obtenir les ensembles de données contenus dans l'unique table annexe sera donc égal en moyenne à Max (Kj)/Np, du fait que l'unique table annexe comporte un nombre d'ensembles égal au maximum des nombres d'ensembles présents dans les ensembles d'ensembles en relation ; par conséquent, le total général pour une entrée-sortie complète comprenant l'ensemble principal 31 et les ensembles de données contenus dans l'unique table annexe sera donc égal à :
Na
Nproc = l + Max (Kι) Np
1=1
On voit que sauf circonstance très exceptionnelle, le nombre moyen d'entrées-sorties Nproc avec le procédé de la présente invention sera toujours très inférieur au nombre moyen d'entrées-sorties Nant sans ce procédé. Dans le cas favorable, mais relativement fréquent, où le nombre d'ensembles de données est sensiblement le même dans les diverses tables annexes, le procédé selon l'invention permet un gain en performances atteignant un facteur égal au rapport Npr0c/Nant, c'est- à-dire :
Figure imgf000033_0001
soit en utilisant l'hypothèse que les divers K[ sont sensiblement égaux entre eux, et donc au maximum d'entre eux :
Figure imgf000033_0002
Na soit en négligeant 1 devant Max (K,) Np, un rapport de valeur 1/Na, ce constitue une
1=1 diminution très importante du nombre d'entrées-sorties dès que le nombre de tables annexes augmente. Ce procédé est donc particulièrement souhaitable dans toutes les applications de bases de données relationnelles dans lesquelles les performances constituent un facteur critique, telles que les applications temps réel ou celles utilisant des serveurs de bases de données très sollicités, comme ceux qui se rencontrent dans les réservations centralisées par un réseau, ou dans la consultation de bases de données via le réseau mondial Internet.
En outre, l'utilisation du langage XML pour représenter les objets stockés dans la base de données 2 permet l'utilisation de patrons d'objets XML pour filtrer certaines données des objets 6 entrants et sortants de la base de données 2. Ainsi, dans le mode de réalisation préféré de la présente invention, des patrons d'objets XML 61, collectivement dénommés I/O Format et conformes à une description XML Schéma, sont utilisés pour réaliser un tel filtrage.
Plus précisément, ces patrons d'objets XML I/O Format 61 supprimeront certaines données sensibles des objets entrants, comme des données concernant la validité des données contenues dans un objet 6, de façon à ce que ces données sensibles ne puissent être, en tout état de cause, modifiées depuis le réseau 60, et à ce que leur modification ne puisse être effectuée que par un opérateur intervenant directement sur l'ordinateur serveur 1.
De même, les patrons d'objets XML I/O Format 61, en fonction des données effectivement utilisées par un utilisateur sur le réseau 60, supprimeront dans les données d'un objet 6 transmises sur le réseau 60 les données qui ne seraient pas utilisées par ledit utilisateur. Compte-tenu de ce que, dans la pratique, les données transmises pour un objet 6 ne représentent habituellement qu'une faible partie de l'ensemble des domiées de cet objet, ce procédé permet une réduction substantielle du volume des données transmises par l'ordinateur serveur 1, ce qui est particulièrement intéressant dans le cas d'ordinateur serveur 1 très chargé, tels que ceux qui se rencontrent dans l'Internet.
En outre, ce procédé permet de prendre en compte différents niveaux de sécurité attachés aux utilisateurs se connectant via le réseau 60, en associant à chaque niveau de sécurité un patron éliminant des données transmises à l'utilisateur les données non autorisées pour le niveau de sécurité de l'utilisateur.
En outre, du fait que ce procédé garantit que seules les données conformes au patron d'objet I/O Format 61 utilisé seront transmises, il n'y aura pas lieu de demander la restitution par la base de données 2, des données éliminées par le patron d'objet I/O Format 61 utilisé, et ainsi les données apparaissant dans les requêtes SQL "SELECT" effectuées par le moteur COS Engine pourront être limitées aux seules données transmises, ce qui diminuera de façon toute aussi sensible la charge d'entrées-sorties dans la base de données 2 dans l'ordinateur serveur 1.
Ce procédé permet de focaliser la requête sur les tables de la base de données 2 et les données dans ces tables 3 et 7 qui sont effectivement utilisées dans la requête d'un utilisateur. Ainsi, dans le cas où aucune donnée de la table annexe 7 n'est utilisée dans la requête, le procédé n'accédera pas à cette table 7 pour la requête, ce qui, à nouveau, permettra d'améliorer sensiblement les performances de l'ordinateur serveur 1 mettant en œuvre le procédé de l'invention. Ainsi, l'utilisation du format XML et d'un patron d'objet au format XML permet d'imposer des règles de sécurité sur les données entrantes, de limiter l'utilisation de la base passante du réseau 60 aux seules données nécessaires et de diminuer en due proportion le volume des données échangées avec la base de données 2.
Dans le mode de réalisation décrit ci-dessus, la donnée "cle" 11, identifiant de façon unique un objet 6, a été indiquée, pour des raisons de simplicité de l'exposé, comme étant gérée de façon explicite par le procédé de l'invention. Toutefois, cette technique explicite n'est en aucune manière obligatoire, et elle peut parfaitement être remplacée par toute autre technique équivalente pouvant être offerte par le SGBDR utilisé. De même, cette donnée "cle" 11 a été décrite comme étant constituée d'un seul nombre entier, mais elle peut tout aussi bien être constituée de plusieurs parties. Par exemple, dans le mode de réalisation préféré de l'invention, une donnée "cle" 11 unique, appelée Object IDentifier ou OID, est obtenue pour chaque objet 6 en concaténant une première partie constituée du nom logique du serveur 1 sur lequel réside la base de donnée 2, une seconde partie constituée du numéro de la table principale 3 dans la base de donnée 2, et une troisième partie constituée du numéro d'enregistrement de l'ensemble de données principal 31 dans ladite table 3.
Le nom logique du serveur 1 étant unique sur le réseau 60, la base de données 2 étant unique sur le serveur 1 où elle est stockée, le numéro de la table 3 étant unique dans la base de données et le numéro d'enregistrement de l'ensemble de données principal 31 étant unique dans la table 3, l'OID 11 ainsi obtenu pour un objet 6 sera donc unique parmi l'ensemble des OID identifiant les objets 6 accessibles via le réseau 60. En outre, ce type de donnée "cle" 11 présentera l'intérêt de permettre de localiser précisément le lieu de stockage d'un objet 6 quelconque sur la seule base de son OID 11 associé.
Par ailleurs, dans l'exemple décrit ci-dessus, il a été fait référence à une application de type annuaire, mais le procédé de l'invention est également utilisé dans des application de type conférences ou publications.
D'une façon générale, la description ci-dessus ne doit pas être comprise comme réduisant en quoi que ce soit la portée de la présente invention telle que revendiquée dans les revendications annexées.

Claims

REVENDICATIONS
1. Procédé de stockage d'objets informationnels ou objets (6), dans une base de données relationnelle (2) stockée dans un ordinateur serveur (1), ladite base de données relationnelle (2) étant constituée de tables, chaque table étant constituée d'un tableau d'ensembles de données simples, lesdits ensembles ayant la même structure de données dans une même table, chaque donnée simple d'une table étant désignée par un identifiant unique dans ladite table, un objet (6) étant constitué d'une ou plusieurs données simples pouvant être stockées dans une table de ladite base de données (2), et/ou d'un ou plusieurs objets emboîtés dans ledit objet, ledit emboîtement pouvant être réalisé sur un nombre quelconque de niveaux pour réaliser un objet (6), un objet emboîté ou une donnée simple étant dit localement en nombre fixe s'il ou elle apparaît exactement une fois dans l'objet le ou la contenant immédiatement et étant dit localement en nombre variable dans le cas contraire, une donnée simple apparaissant à un niveau quelconque dudit objet (6) étant dite globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets la contenant sont localement en nombre fixe, une donnée simple apparaissant à un niveau quelconque dudit objet (6) étant dite globalement en nombre variable si elle est localement en nombre variable ou si l'un quelconque des objets la contenant est localement en nombre variable, lesdites données globalement en nombre fixe d'un objet à stocker (6) étant stockées dans un ensemble de données principal (31) stocké dans une table principale (3) de ladite base de données (2), lesdites données simples globalement en nombre variable dudit objet à stocker (6) étant stockées dans une ou une ou plusieurs tables annexes (4, 5, 7) de ladite base de données (2), caractérisé par le fait que, lorsqu'elles existent, les données simples globalement en nombre variable desdits objets (6) sont stockées dans une unique table annexe (7) de ladite base de données, le procédé créant un ou plusieurs ensembles de données annexes (71) pour stocker lesdites données simples globalement en nombre variable dans ladite unique table annexe (7).
2. Procédé selon la revendication 1, dans lequel chacun desdits un ou plusieurs ensembles annexes (71) éventuellement stockés dans ladite unique table annexe (7) comporte en outre un ensemble (72) d'indicateurs booléens, chaque indicateur booléen étant associé à une donnée particulière desdites domiées simples globalement en nombre variable stockées dans ledit ensemble annexe (71), ledit indicateur booléen indiquant si ladite donnée simple globalement en nombre variable associée est définie ou non dans ledit ensemble annexe (71).
3. Procédé selon la revendication 2, dans lequel certains desdits indicateurs booléens dudit ensemble (72) d'indicateurs booléens sont communs à plusieurs données simples globalement en nombre variable lorsque lesdites données simples sont localement en nombre fixe dans un même objet les contenant immédiatement.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit ensemble principal (31) associé au dit objet (6) à stocker comporte une donnée (11) permettant d'identifier de façon unique ledit ensemble principal (31) dans ladite table principale (3).
5. Procédé selon la revendication 4, dans lequel ladite donnée unique (11) est unique dans ledit ordinateur serveur (1).
6. Procédé selon l'une des revendications 4 ou 5, dans lequel ladite donnée unique (11) stockée dans ledit ensemble principal (31) associé au dit objet (6) à stocker est en outre stockée dans chacun des ensembles annexes (71) associés au dit objet (6) à stocker, pour permettre la mise en relation dudit ensemble principal (3) et du ou desdits ensembles annexes (71) éventuels associés au dit objet (6) à stocker.
7. Procédé selon l'une quelconque des revendications 4 à 6, dans lequel ladite donnée unique (11) est constituée du nom logique de l'ordinateur serveur (1) sur ledit réseau (60), du numéro de table de ladite table principale (3) dans ladite base de données (2) et du numéro d'ensemble de données dudit ensemble principal (31) dans ladite table principale (3), ledit nom logique de l'ordinateur serveur (1) étant unique sur ledit réseau (60), ladite base de données (2) étant unique sur ledit ordinateur serveur (1), ledit numéro de table de ladite table principale (3) étant unique dans ladite base de données (2) et ledit numéro d'ensemble de données dudit ensemble principal (31) étant unique dans ladite table principale (3). ]
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel deux objets (6) à stocker sont dits de même type s'ils sont constitués de données simples et d'objet emboîtés de même type, deux objets (6) de même type ayant en commun un même identifiant et les données simples et/ou les objets emboîtés se correspondant à un niveau quelconque desdits objets (6) de même type ayant en commun un même identifiant, unique dans l'objet les contenant immédiatement.
9. Procédé selon la revendication 8, dans lequel le procédé crée un identifiant global pour tous les objets (6) de même type et pour toutes les données simples se correspondant à un niveau quelconque desdits objets (6) de même type, ledit identifiant global étant ledit identifiant commun pour lesdits objets de même type, et ledit identifiant global étant obtenu, pour chacune desdites données simples se correspondant, par la concaténation des identifiants, dans les objets les contenant immédiatement, de tous les objets contenant ladite donnée simple, et de l'identifiant de ladite donnée simple dans l'objet la contenant immédiatement.
10. Procédé selon la revendication 9, dans lequel le nombre de caractères de l'identifiant global est tronqué au nombre de caractères permis par ladite base de domiées (2) pour l'identifiant d'une donnée stockée dans une table de ladite base de données (2).
11. Procédé selon la revendication 10, dans lequel une ambiguïté pouvant apparaître du fait de ladite troncature est résolue en effectuant les étapes consistant à :
- remplacer le dernier caractère alphabétique de l'identifiant global par le chiffre zéro, ainsi que les éventuels chiffres le suivant ; augmenter d'une unité le nombre constitué par l'ensemble des chiffres apparaissant à la fin dudit identifiant global jusqu'à ce que l'ambiguïté disparaisse ou que les chiffres à la fin dudit identifiant global soient entièrement constitués de chiffres neuf ; - répéter les étapes précédentes depuis le début lorsque les chiffres apparaissant à la fin dudit identifiant global sont entièrement constitués de chiffres neuf à l'issue de l'étape précédente.
12. Procédé selon l'un quelconques des revendications précédentes, dans lequel les objets (6) stockés dans la base de données (2) sont reçus ou transmis par l'ordinateur serveur (1) via un réseau informatique (60) de type Internet.
13. Procédé selon l'une des quelconques des revendications précédentes, dans lequel les données simples constituant lesdits objets (6) stockés dans ladite base de données (2) sont de type texte.
14. Procédé selon la revendication 13, dans lequel lesdites données simples de type texte sont des données écrites en langage XML.
15. Procédé selon la revendication 14, dans lequel lesdites données écrites en langage XML sont conformes à une description (92) de type XML Schéma.
16. Procédé selon la revendication 15, dans lequel un ensemble de données (95) au format XML est obtenu par une traduction automatique de ladite description (92), ledit ensemble de données (95) et un ensemble de données complémentaire (96) étant à leur tour traduits automatiquement en langage SQL pour définir et gérer la structure de la base de données (2), et pour contrôler les échanges de données avec ladite base de données (2).
17. Procédé selon l'une quelconque des revendications 14 à 16, dans lequel une partie des données simples des objets (6) reçus par ledit réseau (60) de type
Internet est supprimée à l'aide d'un patron, ou modèle, d'objet (61) écrit en langage XML, pour interdire la modification desdites données simples via ledit réseau (60).
18. Procédé selon l'une quelconque des revendications 14 à 17, dans lequel une partie des données simples des objets transmis via ledit réseau est supprimée à l'aide d'un patron d'objet (61) écrit en langage XML pour limiter la transmission sur ledit réseau (60) à certaines données simples desdits objets
(6).
19. Procédé selon la revendication 18, dans lequel la suppression de d'une partie des données simples contenues dans les objets (6) permet en outre d'optimiser les requêtes à ladite base de données (2).
20. Système de stockage d'objets informationnels ou objets (6), dans une base de données relationnelle (2) stockée par un ordinateur serveur (1), caractérisé par le fait qu'il met en œuvre le procédé selon l'une quelconques des revendications précédentes.
PCT/FR2000/001902 2000-07-04 2000-07-04 Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle Ceased WO2002003245A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/FR2000/001902 WO2002003245A1 (fr) 2000-07-04 2000-07-04 Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle
AU2000261656A AU2000261656A1 (en) 2000-07-04 2000-07-04 Method for storing xml-format information objects in a relational database

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2000/001902 WO2002003245A1 (fr) 2000-07-04 2000-07-04 Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle

Publications (1)

Publication Number Publication Date
WO2002003245A1 true WO2002003245A1 (fr) 2002-01-10

Family

ID=8847047

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/001902 Ceased WO2002003245A1 (fr) 2000-07-04 2000-07-04 Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle

Country Status (2)

Country Link
AU (1) AU2000261656A1 (fr)
WO (1) WO2002003245A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004019231A3 (fr) * 2002-08-26 2005-02-03 Computer Ass Think Inc Appareil et procedes de fourniture de services sur la toile
US7016915B2 (en) 2002-12-28 2006-03-21 International Business Machines Corporation Method for processing XML queries over relational data and meta-data using a relational database system
US7529726B2 (en) 2005-08-22 2009-05-05 International Business Machines Corporation XML sub-document versioning method in XML databases using record storages
US7937413B2 (en) 2004-05-04 2011-05-03 International Business Machines Corporation Self-adaptive prefix encoding for stable node identifiers
US8543614B2 (en) 2005-08-22 2013-09-24 International Business Machines Corporation Packing nodes into records to store XML XQuery data model and other hierarchically structured data
US8572125B2 (en) 2005-08-22 2013-10-29 International Business Machines Corporation Scalable storage schemes for native XML column data of relational tables

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594898A (en) * 1994-03-25 1997-01-14 Microsoft Corporation Method and system for joining database tables using compact row mapping structures
US5983215A (en) * 1997-05-08 1999-11-09 The Trustees Of Columbia University In The City Of New York System and method for performing joins and self-joins in a database system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594898A (en) * 1994-03-25 1997-01-14 Microsoft Corporation Method and system for joining database tables using compact row mapping structures
US5983215A (en) * 1997-05-08 1999-11-09 The Trustees Of Columbia University In The City Of New York System and method for performing joins and self-joins in a database system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BOURRET R ET AL: "A generic load/extract utility for data transfer between XML documents and relational databases", PROCEEDINGS SECOND INTERNATIONAL WORKSHOP ON ADVANCED ISSUES OF E-COMMERCE AND WEB-BASED INFORMATION SYSTEMS. WECWIS 2000, PROCEEDINGS SECOND INTERNATIONAL WORKSHOP ON ADVANCED ISSUES OF E-COMMERCE AND WEB-BASED INFORMATION SYSTEMS. WECWIS 2000, MILP, 2000, Los Alamitos, CA, USA, IEEE Comput. Soc, USA, pages 134 - 143, XP002169780, ISBN: 0-7695-0610-0 *
GUIDO N: "XML data processing and relational database systems", XML EUROPE '99 CONFERENCE PROCEEDINGS, PROCEEDINGS OF XML EUROPE '99, GRANADA, SPAIN, 26-30 APRIL 1999, 1999, Alexandria, VA, USA, Graphic Commun. Assoc, USA, pages 713 - 719, XP001006043 *
SHIMURA T ET AL: "Storage and retrieval of XML documents using object-relational databases", DATABASE AND EXPERT SYSTEMS APPLICATIONS. 10TH INTERNATIONAL CONFERENCE, DEXA'99 (LECTURE NOTES IN COMPUTER SCIENCE VOL.1677), PROCEEDINGS OF DEXA'99: 10TH INTERNATIONAL CONFERENCE AND WORKSHOP ON DATABASE AND EXPERT SYSTEMS APPLICATIONS, FLORENCE, I, 1999, Berlin, Germany, Springer-Verlag, Germany, pages 206 - 217, XP001005987, ISBN: 3-540-66448-3 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004019231A3 (fr) * 2002-08-26 2005-02-03 Computer Ass Think Inc Appareil et procedes de fourniture de services sur la toile
US7861251B2 (en) 2002-08-26 2010-12-28 Computer Associates Think, Inc. Generating keys for objects in a web services arrangement
US7016915B2 (en) 2002-12-28 2006-03-21 International Business Machines Corporation Method for processing XML queries over relational data and meta-data using a relational database system
US7937413B2 (en) 2004-05-04 2011-05-03 International Business Machines Corporation Self-adaptive prefix encoding for stable node identifiers
US7529726B2 (en) 2005-08-22 2009-05-05 International Business Machines Corporation XML sub-document versioning method in XML databases using record storages
US8161004B2 (en) 2005-08-22 2012-04-17 International Business Machines Corporation XML sub-document versioning method in XML databases using record storages
US8543614B2 (en) 2005-08-22 2013-09-24 International Business Machines Corporation Packing nodes into records to store XML XQuery data model and other hierarchically structured data
US8572125B2 (en) 2005-08-22 2013-10-29 International Business Machines Corporation Scalable storage schemes for native XML column data of relational tables

Also Published As

Publication number Publication date
AU2000261656A1 (en) 2002-01-14

Similar Documents

Publication Publication Date Title
CA2699644C (fr) Installation de gestion d&#39;une base de donnees
EP0593354B1 (fr) Procédé d&#39;aide à l&#39;optimisation d&#39;une requête d&#39;un système de gestion de base de données relationnel
US20190362052A1 (en) Satellite and central asset registry systems and methods and rights management systems
US10452714B2 (en) Central asset registry system and method
US20250131067A1 (en) Systems and methods for federated searches of assets in disparate dam repositories
FR2832236A1 (fr) Interface graphique de portail web semantique
EP1096394A1 (fr) Système et procédé de gestion de la persistance des composants EJB dans un annuaire accédé par LDAP
EP1515239A1 (fr) Procédé et systéme de manipulation de données issues de bases de données multidimensionnelles à l&#39;aide d&#39;un tableur
EP0593341A1 (fr) Procédé d&#39;aide à l&#39;optimisation d&#39;une requête d&#39;un système de gestion de base de données relationnel et procédé d&#39;analyse syntaxique en résultant
FR2724471A1 (fr) Dispositif de generation d&#39;interfaces orientees objet pour des bases de donnees relationnelles et procede mis en oeuvre par ledit dispositif
CA2320891A1 (fr) Procede de traitement d&#39;une requete
FR2824160A1 (fr) Conteneur generique configurable de facon dynamique
CN101645092B (zh) 用于将x500数据模型映射到关系数据库上的方法
EP1272944A1 (fr) Systeme de recherche et d&#39;aide au choix
WO2002003245A1 (fr) Procede de stockage d&#39;objets informationnels au format xml dans une base de donnees relationnelle
EP3991059A1 (fr) Systèmes et procédés de recherches fédérées d&#39;actifs dans des référentiels de dam disparates
WO2018144536A1 (fr) Systèmes et procédés de registres de ressources satellites et de registre central et systèmes de gestion de droits
EP1700233B1 (fr) Procede d&#39;organisation d&#39;une base de donnees
WO1994012942A1 (fr) Methode d&#39;extraction de profils de statistiques, utilisation des statistiques creees par la methode
FR2896602A1 (fr) Procede de gestion de documents electroniques
EP1763790A1 (fr) Procede et dispositif de recherche avec conservation personnalisee des resultats
FR2828308A1 (fr) Systeme de gestion d&#39;une base de donnees topologique
FR2911200A1 (fr) Procede et dispositif de traitement de documents a partir de schemas enrichis et procede et dispositif de decodage correspondants
FR2917518A1 (fr) Procede de tri d&#39;informations
WO2002042934A1 (fr) Procede et systeme de gestion d&#39;informations modelisees sous la forme d&#39;objets, et procede et systeme de construction et gestion dynamique de pages mettant en oeuvre ce procede

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT A LA REGLE 69(1) CBE (OEB FORM 1205A DATEE 29.07.03)

NENP Non-entry into the national phase

Ref country code: JP

122 Ep: pct application non-entry in european phase