WO1998057272A1 - Dispositif d'analyse et d'organisation de donnees - Google Patents

Dispositif d'analyse et d'organisation de donnees Download PDF

Info

Publication number
WO1998057272A1
WO1998057272A1 PCT/FR1998/001015 FR9801015W WO9857272A1 WO 1998057272 A1 WO1998057272 A1 WO 1998057272A1 FR 9801015 W FR9801015 W FR 9801015W WO 9857272 A1 WO9857272 A1 WO 9857272A1
Authority
WO
WIPO (PCT)
Prior art keywords
columns
data
column
coll
database
Prior art date
Application number
PCT/FR1998/001015
Other languages
English (en)
Inventor
Guillaume Martin
Original Assignee
Guillaume Martin
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 Guillaume Martin filed Critical Guillaume Martin
Priority to EP98928350A priority Critical patent/EP0988607A1/fr
Priority to US09/445,751 priority patent/US6553383B1/en
Publication of WO1998057272A1 publication Critical patent/WO1998057272A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface

Definitions

  • the present invention relates to information processing and storage systems of the database type.
  • Such systems can be made accessible to uninitiated users, using appropriate development tools. These tools are very often used by professionals (those skilled in the art), because they considerably reduce the development costs of articulated applications in database form.
  • the present invention aims in particular to provide a solution to this problem.
  • the data processing device proposed for this purpose is of the type comprising at least one computer, provided with a unit control unit with a processor, at least one user device, and a memory, animated by an operating system, as well as a database management system, stored in this computer, and suitable for cooperating with the operating system to allow the user to create / enter and / or use a database comprising for example at least one data table, decomposable into rows and columns.
  • database management system is meant here to cover any computer file system making it possible to manage tables, whatever the physical storage mode thereof.
  • the invention includes in this device means that can be called a development and assistance tool.
  • the assistance function is carried out by the fact that, in a means forming an autonomous meta-dictionary, dynamically stores selected information relating to the structure of the database, typically the tables and the links between tables, or equivalent information .
  • the analysis function can involve a statistical tool, capable of determining interdependencies, and preferably also dependencies, between data sets, by counting distinct occurrences, and an analysis module (pilot). capable of cooperating with the etak Dictionary and with this statistical tool, to obtain and store said representation of groups of linked columns.
  • the statistical tool is based on a counting means, which preferably operates directly on the columns of each table, in a manner which will be described later.
  • the analysis module can be arranged to reiterate the presentation of sub-groups of at least two columns, until finding at least one sub-group whose columns are linked, or until all possibilities are exhausted. Preferably, it systematically performs the presentation of all the different possible subgroups of columns for said table, preferably also for all the tables of the database.
  • the re-structuring module begins by selecting a starting table to be processed, columns to be treated from at least one group of linked columns, and a primary link key for this group of columns.
  • Restructuring can be done by building a new table with data from a group of linked columns, as well as with a link key with the table in question.
  • the analysis means and its storage means can operate in different ways, in particular: at the request and / or on satisfaction of certain criteria (which may include a partial analysis), or, conversely, permanently, dynamically (possibly for partial analysis only).
  • the invention can also be expressed in the form of a process applied to a computer, or else in the form of the new industrial product that constitutes the development tool.
  • FIGS. 1 and 2 illustrate two examples of architecture of information processing systems usable according to the invention
  • FIG. 3 illustrates the combination of means in which the invention manifests itself
  • FIG. 4 graphically illustrates a link between two tables
  • FIG. 7 illustrates a single table corresponding to the two tables of Figures 5 and 5A
  • Figure 7A illustrates the same single table, but with input anomalies
  • - Figure 8 shows the appearance on the screen of a form for entering information, relating to components and products, managed on a single table
  • FIG. 9 represents the result of an interrogation request from the monotable structure of FIG. 7
  • FIG. 10 is the detailed block diagram of the analysis means according to the invention.
  • FIG. 11 illustrates the meaning of the block graphics used here in the flowcharts
  • FIG. 12 (divided into 12A and 12B) illustrates the flowchart of operation of the query builder
  • Figure 13 illustrates the flowchart of operation of the analysis module
  • Figure 13A illustrates a flowchart optional additional operation of the analysis module
  • FIG. 14 represents the result of a search request for false dependence from the monotable structure of FIG. 7A
  • FIG. 15 shows the selection screen for reorganization
  • FIG. 16 (divided into 16A and 16B) illustrates the operating flowchart of the selection and reorganization modules
  • Figure 17 represents the joins of the structure with three Components, Products and Categories tables
  • Figure 18 represents the input form of the components after the reorganization of the information relating to the products
  • Figure 18A represents a simplified form of input of the components after the reorganization of the information relating to the products
  • FIG. 19 represents the result of the interrogation request after the reorganization of the information relating to the products
  • FIG. 19A represents the result of the interrogation request after a new reorganization of the information relating to the product category
  • FIG. 20 illustrates the operating flowchart of the virtual reorganization variant.
  • the computer system of Figure 1 includes:
  • - at least one computer 100 known as a client, with a central unit 110 (CPU, random access memory, etc.), a screen 120, a keyboard 130, a mass memory 140 (hard disk for example), a pointing device 150 ( mouse for example), a printer 160, and a peripheral 170 allowing access to a network (local or remote) as well as the corresponding software, and
  • a central unit 110 CPU, random access memory, etc.
  • a screen 120 a keyboard 130, a mass memory 140 (hard disk for example), a pointing device 150 ( mouse for example), a printer 160, and a peripheral 170 allowing access to a network (local or remote) as well as the corresponding software, and
  • a computer 200 called a server, comprising a central unit 210 (CPU, random access memory, etc.), a screen 220, a keyboard 230, a file storage system 240 (hard disk for example), possibly a pointing system 250 , a peripheral 260 allowing access to the network (local or remote) as well as the corresponding software.
  • a central unit 210 CPU, random access memory, etc.
  • a screen 220 a keyboard 230
  • a file storage system 240 hard disk for example
  • possibly a pointing system 250 possibly a pointing system 250
  • peripheral 260 allowing access to the network (local or remote) as well as the corresponding software.
  • the mass memory (or other memory) of the two computers houses an operating system.
  • an operating system For the "client”, we will take for example an operating system with a graphical interface, such as Windows, OS / 2 or MOTIF for example (Trademarks).
  • the graphical interface is less useful in certain cases, and one can take Windows NT, OS / 2, Unix, or Novell for example (Trademarks).
  • the operating system is launched, in a known manner, generally when the computer starts.
  • a database is installed on the server's storage system.
  • Each piece of data (“item” of data) is materialized by an ordered series of fingerprints (magnetic, optical, magneto-optical or other) on the storage medium (disk or other), accessible for example via a SQL type language, and using a database engine installed on the storage system.
  • fingerprints magnetic, optical, magneto-optical or other
  • disk or other accessible for example via a SQL type language
  • database engine installed on the storage system.
  • clients On the side of the "client" computer (s), it suffices to provide programs, recorded on the storage system, allowing access to the database via an appropriate language, for example SQL.
  • Figure 2 illustrates a "single user" configuration integrating some of these elements on a single computer. There is then only one storage device (140 + 240), and the device allowing access to the network (170) is useless.
  • a processing unit for example at least one of the units 110 and 210 ( Figures 1 and / or 2);
  • the mass memory for example at least one of the hard disks 140 and 240; - in 450, the operating system which allows access to physical information from the mass memory, in the form of a 460 file system.
  • the physical links are in solid lines, while the logical links are in dashed line. The rest of FIG. 3 essentially depends on the file system, therefore on the mass memory 440 and the processing unit 410, through the operating system 450.
  • an "internal dictionary” (this is the name generally given, in relational databases, to information on the structure of the database, which are stored in a way accessible to the database engine, but inaccessible by direct modification by the user - read only).
  • the development tool (general part) which accesses the database 475 (tables, forms, reports, in particular).
  • the development tool 500 works with a generator of tables, forms and reports 505, a meta-dictionary 510, an analysis module 530, a selection module 570, as well as a physical reorganization 580, and / or a virtual reorganization module 590.
  • Each table is a set of rows; each row is organized into one or more columns; and every column corresponds to a data type. Each row includes one and only one value (the "data") for each column of the table. Physically, data storage can correspond to this table structure, or be different.
  • Each table generally comprises at least one column which contains only unique values (is "unique” a value which is found only once in the column of the table considered), or else an equivalent means, number of row for example, arranged or not in column of the table.
  • This column (or one of them) is then called the primary key.
  • the value of the primary key makes it possible to uniquely find the corresponding line, hence its interest. Any column that contains only unique values can be used as the primary key.
  • the set of joins to link two tables together is called a path.
  • Some database structures are such that there can be several paths between two of the tables they contain. For example, two Customers and Suppliers tables can be linked by a path passing through an Orders table or by a path passing through a Country table. Conversely, there may not be a path between two tables. For example, two tables "Production” and "History_of_production” although having the same structure and containing data of the same essence have no link (in the sense of the structure of the data) between them.
  • joins or links makes it possible to reduce redundancy of information.
  • specific relevant information is stored only once (except the primary key - foreign key pairs required for links). This saves space. In addition, updates are made easier.
  • P_NAME the modification of the name of the product having a serial number P_SN equal to US1 only implies the modification of a single line (in the table Products) while it consists of three components.
  • a form displayed on the screen Access to the data of a table is made by a form displayed on the screen.
  • a form is made up of fields, each of which corresponds to a column in a table. It allows to insert new lines in the table (creation), to modify the existing lines, to delete lines.
  • a form which allows access to several tables must then respect the integrity constraints of the structure concerned.
  • a report presents selected columns of a table, for rows selected by a query (sometimes for the whole table). The result is displayed on the screen and / or printed.
  • a report can query and present data from several tables, but it must then know the corresponding structure (foreign keys, primary keys and joins). In addition to reports, it is possible to define graphics displayed on the screen and / or printed.
  • Reports and charts are commonly called reports.
  • Forms and reports are commonly called programs. And programs access data via queries.
  • the reports are accompanied by interrogation requests.
  • interrogation request is included in the report and / or separated from the report.
  • insertion requests, update requests and deletion requests which are in principle reserved for forms.
  • SQL query language Structured Query Language
  • the SQL language has been the subject of several standardizations, the latest of which is the SQL-92 ANSI / ISO standard.
  • the keywords of SQL orders are presumed to be understood by the reader. If necessary, they can be found in the above-mentioned standard.
  • the SQL language allows access to relational databases while respecting an independence between the way in which the data is physically stored and the way of logically handling this data.
  • the SQL language makes it possible to express complex processes simply, including in particular nested loops (by means of joins): see examples A-13-1 and A-13-2.
  • the use of the SQL language is in no way limiting, and the present invention can just as easily be applied using a lower level language, which would directly attack the file system of the storage device, for example .
  • an application brings together a set of programs revolving around a given structure (tables and integrity constraints).
  • a menu allows you to select, within an application, the program with which you want to work.
  • a development tool is software that provides the programmer with a library of program generators. These program generators make it possible to significantly reduce development times: when using a program generator, the programmer enters parameters rather than writing source code; these parameters are then interpreted to generate a source code program that the programmer can modify or enrich manually, insofar as he masters the source code.
  • the development of applications based on database engines follows in principle the following methodological approach: the programmer performs a needs analysis. He can use a design method for this (Merise for example) whose ordered set of operating rules guides him by systematizing the thinking process and avoiding design errors.
  • the analysis makes it possible to define a "data model" which expresses the semantics of the data in a relevant manner. (A data model can be represented graphically by an Entity-Relation diagram.).
  • the needs analysis phase requires the programmer to have a good knowledge of relational algebra and standardization of the structure of a database.
  • the physical structure of the data must be implemented in the database starting from the "data model”.
  • the development tool allows you to define forms and reports based on the structure (using the internal dictionary) as well as menus. The user can then enrich these forms, reports and menus.
  • the meta-dictionary is subject to possible consistency checks by the development tool and can even integrate certain operating rules of an analysis method (CASE type tools). From this meta-dictionary, generator 505 (figure 3) of the development tool takes care of the following tasks:
  • the report generator composes several query queries (usually one per set of tables), and builds a standard report for each query.
  • the user can then enrich them.
  • the complexity of access to the database is more or less hidden from the user, depending on the quality (level of complexity) of the development tool.
  • a specific modification of the data structure is variously well accepted by the development tools: Being a "rustic" tool, the user must manually modify the data structure, as well as the queries in the forms and reports concerned. - On the other hand, with a high performance tool, more complex, it is enough to update the meta-dictionary of the development tool, and this is automatically reflected on the physical structure of the data as well as on the requests of the forms and states.
  • a more substantial modification of the data structure is very heavy, if one wishes to keep the data already entered. And the user will come up against several difficulties: a) the new structure, even if it respects relational integrity, may no longer be in line with the needs of the application. The data may become unusable. b) the syntax of the languages (procedural or not) for data access is complex and many modifications not taken into account by the development tool have to be done manually. c) the modifications to be made to requests for forms and reports are complex. d) the modification of the structure is itself delicate and complex if one wishes to keep the existing data (a very simple example: having an article number column, we want to change it from the numeric type to the character type ).
  • the invention makes it possible in all cases to start from a single-table structure. It then allows the user himself to modify the data structure, once production has started, according to his new needs. It does not require any particular knowledge of the data access technique (SQL language for example), nor of the principles governing relational data structures. It thus saves analysis time, development time and subsequent modification time. It is suitable for all relational databases on the market, as well as for other data management systems.
  • the invention provides an improved development means or tool, which can also be considered as a user environment interface.
  • This tool is based on a particular meta-dictionary 510 (FIG. 10), the minimum content of which (for the preferred embodiment) is given in A-21.
  • the meta-dictionary repeats certain information already contained in the internal dictionary, such as the name and type of each column in each table. There are many more.
  • This meta-dictionary 510 is maintained by a memory automaton, which monitors any event relating to the conditions given in A-21. This monitoring can be limited to the times when the development tool is running (insofar as it has the exclusive right to modify these conditions). It can be wider. It is preferably permanent.
  • the invention is also based on a request constructor 520 (FIG. 10).
  • the built queries obey a well defined general format, called here canonical form, whose currently preferred version is indicated in A-22, while examples of canonical queries are given in A-23.
  • step 910 presents the user with different (available) possibilities for selecting columns, simple and calculated, as well as set functions.
  • set function we mean a function covering several lines, such as SUM (), COUNTING (), AVERAGE (), for example.
  • the user can construct expressions from columns, and / or set functions. From there, he can: - in 912, create and link restrictive conditions,
  • steps 910 to 913 constitute the initialization of the query builder. They are described as made by the user. But the query builder can just as easily operate automatically, receiving this initialization when it is launched, in the form of parameters, which respectively define the elements entered in 911, 912, 913. It is important to note that this query designer can memorize, in the form of character strings, the definition of the queries it has enabled to write.
  • Step 920 determines the set of tables to which the columns and expressions defined in 911 to 913 belong. This is done selectively for each of the expressions involved in the canonical request A-22. If a column belongs to two tables, it is the primary key of one and a foreign key of the other. The query generator can associate this column with one or the other of the two tables (the result of the query will be the same). We preferably take the table where the column is the primary key.
  • Steps 921 to 925 and 929 determine the path connecting these tables (if there are several).
  • step 923 adds one or more tables so that such a path exists, starting from the meta-dictionary. It will be noted however that, as soon as the implementation of the invention starts from a single table, all the tables then created are necessarily linked by one and only one path.
  • the first two lines of the query A-22 are therefore constructed (and the optional third line, if the following lines call columns whose tables do not appear in the second line).
  • step 940 the “following” of the path (if any) and the satisfaction of the restrictive conditions are treated in a similar manner. This is used to decide (941) to write the WHERE clause, with a list of joins (943) and / or a list of restrictive conditions (949).
  • the ORDER BY clause is written in 971, if test 970 indicates so (the sorting criteria may include set functions).
  • this query builder takes care of all the checks itself. Just give it, by input, or by passing parameters, the selective list of expressions to be processed.
  • the invention also provides for automatically (dynamically) creating one or more forms.
  • the value of a column must always correspond to its type (for example, what is entered in a column of date type must be a datum recognized as a date).
  • an external key column must have a set of values included in the set of values of the corresponding primary key.
  • the invention provides for the automatic generation of reports and graphics, by the module 505.
  • a report is established on the basis of an interrogation request. It is possible in a report to define:
  • the breaks are proposed according to the structure of the application: either a column COL 2 which belongs to a set of tables ⁇ TAB2- L ... TAB2 p ⁇ , and the previous column COL j which belongs to a set of tables ⁇ TABl lf ... TABl n ⁇ ; these two columns are presented in the same break level, if, for any value of i, from 1 to n, and for any value of j, from 1 to p, the path to go from TABl j ⁇ to TAB2 j does not include no master-detail sense join.
  • These breaks correspond to the breakdown into levels of the structure and therefore offer the user a default presentation which is meaningful. The user can however modify them at his discretion and define certain group calculations only for certain levels of rupture as well as insert or delete ruptures.
  • Figure 6 illustrates a report showing the name of the product, the serial number of the component, the cost with:
  • a graph corresponds to a query and a graphical presentation of column values for certain rows.
  • a graph is determined by parameters like:
  • a graph is established on the basis of an interrogation request comprising from zero to several columns of the label type and one or more columns of the numeric type. It includes: - The format of the label type column.
  • the pie chart only supports a label type column and a numeric type column.
  • the XY graph (commonly called curve) does not support a column of the label type and only supports two columns of the numeric type (possibly three-dimensional graphics).
  • the module 505 If in the query query, there are more columns of the label type than the graph format supports, the module 505 generates as many exploded graphs as necessary using a mechanism similar to that of breaks.
  • the invention makes it possible to ensure that the relationship between the request and the report (report or graph) remains consistent after any reorganization.
  • FIGS. 5 and 5A gives an already fitted version of the table structure.
  • a layman will generally put everything in one table.
  • the user can always start with a single table, which we will name here "Components_and_Products" ( Figure 7). To do this, it simply defines the name and type of the data it wants to enter.
  • the development tool updated the meta-dictionary, created a monotable data structure in accordance with the name and type of the columns indicated by the user, and created a default form allowing access to the table, and states.
  • FIG. 9 represents the result of an interrogation request from the monotable structure (without filtering).
  • the invention can also apply to the case where an experienced developer will make initial choices for the structure of the tables which are guided by his formal analysis and practical considerations, since these choices should be reconsidered during subsequent exploitation (with more and more data).
  • the current structure of the database is no longer suitable when certain data is redundant within the table.
  • the user is confronted with anomalies because the data model does not or no longer respect the different normal forms of the relational model.
  • the present invention provides for this purpose means which can be broken down into three parts (FIG. 3):
  • phases ii) and especially iii) are optional. It will indeed be seen that it is also possible, as a variant, or in addition, to implement the invention without physically reorganizing the database (590).
  • the analysis phase includes all or part of the operations which will now be described, with reference to Annex III. It is controlled by a 530 module ( Figure 10).
  • the method first comprises an analysis (preferably exhaustive) of the repetitions of the values of the columns of the data tables. This analysis will be described with reference to Figure 13 and Annex III.
  • the tables of the database are determined, or better those used in the application (1010).
  • the analysis consists in determining: - in 1012, the number of rows, N.
  • the number of rows in a table (step 1012) is obtained by the request A-31-1, where TABl is the name of the table considered.
  • the number of distinct values of a column in a table is obtained by the SQL query A-31-2, where COL1 is the name of the column.
  • Ni and Nj be the respective number of distinct values of the two columns C _ and C j (calculated in 1024-1026).
  • P the number of distinct pairs of values of C. ⁇ and C j , by the query A- 31-3, where COL1 and COL2 are the names of columns C and C j , while:
  • C ⁇ determines C j .
  • the column ⁇ is said to be the mother of C j .
  • Column C is said to be the daughter of C.
  • C j determines C- ⁇ .
  • Column C j is said to be the mother of C ⁇
  • Column C j _ is said to be a daughter of C j .
  • the steps 1050 and 1052 ensure respectively the looping over all the pairs of columns and all the tables until the End 1059.
  • the queries mentioned can be developed using the SQL query builder already mentioned (A-22, and 520, figure 10). However, it will often be easier to prepare them individually in advance, in the form of character strings, some elements of which are variable.
  • the variable elements are TAB1, COL1, "xyz" (or, which is equivalent to 'xyz'), and COL2.
  • step 1024 (for example) of FIG. 13 will recompose the request A-31-2, by replacing there the names COL1 and TAB1 by the name of the column and that of the table , respectively.
  • the writing of programs capable of implementing the loops described in FIG. 13 is considered to be accessible to those skilled in the art from the present description, and of a procedural language such as the C language and its variants (C ++ for example ), or SMALLTALK.
  • the number of pairs of values, B, which block the mother-daughter dependence between two columns C ⁇ and C j is obtained (step 1210, FIG. 13A) by the query A-32-1, where a and b are aliases defined on the table TABl, and the other variables are defined as above, (a table alias gives access to it under a name other than its own; several aliases on the same table allow access to it in two independent ways).
  • Query A-32-2 includes a nested SELECT statement, which counts the number of occurrences (greater than 1) of the pair of values within the table.
  • COLl which block dependence. These are COLl values such as the number of distinct COLl values! ! 'xyz'
  • C0L2 is greater than 1.
  • the query A-32-2 builds on it a main SELECT order, which returns the pairs of values found, given in figure 14, for the example considered. For each element of the set of values of COLl which block the dependence (according to the nested query), we now search for the corresponding values of COL2 as well as their frequency. Likewise for the NULL value of COLl (NULL is the case where nothing has been entered).
  • step 1230 it is possible to go directly to step 1230, without doing the preliminary counting of step 1210.
  • step 1250 The forcing itself (step 1250, FIG. 13A) is carried out by the SQL order given in A-32-3, where:
  • - COLl and COL2 are two columns of the table whose dependence is sought to force in the sense that COLl will determine COL2, - VALUE2 is the new value assigned to COL2,
  • - VALUE1 is the value of COLl for the lines to be modified
  • - VALUE2__1, VALUES2_2, ... VALUES2_n are the values of COL2 for the lines to be modified.
  • the forcing can also include the SQL order given in A-32-5, where: - TAB1 is the name of the table,
  • - COLl and COL2 are two columns of the table which one seeks to force the dependence in the sense where COLl will determine COL2,
  • - VALUE1B is the new value assigned to COLl
  • - VALUE1 is the value of COLl for the lines to be modified
  • - VALUE2_1, VALUES2_2, ... VALUES2_n are the values of C0L2 for the lines to be modified.
  • Any candidate keys for a group of columns must respect the constraint: Each candidate key must be, opposite all the other columns of the group, either mother or sister. In order for a column to become a candidate key for a group of columns, it is necessary to force the dependency with all the pseudo-daughters of the group (in the event of near-dependence).
  • the result of the analysis is expressed and stored in the form of a group of columns, comprising:
  • One of the implementations of the invention then consists in physically reorganizing the structure of the tables.
  • this function of reorganizing the structure consists in splitting a table into two tables, which will be in master-detail relationship.
  • This phase is carried out for example using a windowed user interface like that of FIG. 15, with a window 91 for selecting the tables (here only one), then window 95 for selecting the columns to be isolated from the chosen table, then selection in 96 of a candidate key for the new table (optional).
  • the name of this new table is entered in 92, which will be noted TAB2 below.
  • the selection-reorganization phases are illustrated in the form of steps in FIG. 16, in the case of interaction with the user, with the screen in FIG. 15.
  • step 2010 uses the meta-dictionary to find out the list of tables used by the application, which list is displayed in 2012.
  • the user chooses the table TAB1 to be reorganized.
  • the system provides in 2020 the list of columns for TAB1.
  • these columns are displayed, with the exception of the primary key of TAB1, and the user chooses in 2030 the columns Sj to be isolated.
  • steps 2042 to 2046 If, in steps 2042 to 2046, the user has selected a candidate key, which is assumed to be (SI), the reorganization proper is carried out by steps 2048, 2049 and 2060, in accordance with SQL orders A-33;
  • the creation of the master table is done by executing the order A-33-1.
  • This SQL statement creates a table named TAB2, with the result of a SELECT statement, nested in the CREATE statement.
  • TAB1 The modification of the original table TAB1 is done by chaining the 3 orders given in A-33-2.
  • TEMPO is a name available at the database level: there is no other table or view with this name). Then we delete TAB1, and we rename TEMPO to TAB1.
  • the creation of the details table follows the sequence of steps A-34-1, where CODE_TAB2 is the name of the primary key of the table TAB2.
  • CODE_TAB2 and TEMPO are names that must be available at the database level.
  • the first line is very similar to query A-33-1, except that instead of directly creating the table TAB2, we go through a TEMPO view. It is the second line which creates TAB2, by adding to the view TEMPO a calculated column CODE_TAB2, whose value is ROWNUM, ie the row rank in the table, after which TEMPO is erased.
  • the layout of the original table TAB1 is carried out as indicated in A-34-2.
  • the meta-dictionary is updated (step 2065): a) the new master table TAB2 formed by the columns SI, S2, ... Sn is taken into account. b) in the case of the creation of a primary key for TAB2, the creation of the column CODE_TAB2 in TABl is noted; the creation of the column CODE_TAB2 in TAB2 is noted.
  • the forms allowing to attack the table TABl are enriched by the column CODE_TAB2, and do not allow any more to attack (seized) the columns SI, S2, ... Sn.
  • FIG. 18 represents the form for entering the components used in production after the reorganization of the information relating to the products.
  • the P_NAME, P_ID and CATEG fields are no longer directly accessible because they do not belong to the Components table whereas they belonged to the Components_and_Products table; they are determined by the value of the product serial number field (P_SN) which is the external key of the Components table which is linked to the primary key of the Products table.
  • P_SN product serial number field
  • FIG. 18A represents a simplified form for entering the components used.
  • the fields P_ID and CATEG which were automatically filled in the form in figure 18 have been deleted from the form. Only the Product name field (P_NAME) has been kept to verify that the serial number of the product entered is the one desired. Concretely, the process is the same as above, except that instead of matching the fields of the "non-modifiable" property, they are simply removed from the definition of the form concerned.
  • Figure 19 shows the result of the query after the reorganization of the information relating to the Products.
  • a break (this is a way of illustrating the new structure) was automatically provided by the report generator, in response to the presence of a new table. Like forms, such a break can be simply determined by the "Break" property associated with the column under consideration, in the definition of the report under consideration. Other illustrations than rupture are possible.
  • the selection / reorganization cycle (or the analysis / selection / reorganization cycle) can be repeated as many times as necessary, at least as long as there remains a group of linked columns to be processed.
  • FIG. 17 shows the join relationships of the structure with the three Components, Products and Categories tables.
  • FIG. 19A represents the result of the interrogation request on these three tables. A second break was made automatically.
  • the physical reorganization of the tables has the following effect: - in data entry mode (form), access for entry (modification, creation, deletion) is restricted to only part of the columns of a group of linked columns, the others being simply accessible in reading, or inaccessible; - to access these other columns in writing, you must use a different form, processing the new table created.
  • This other form can be made accessible from the first, in particular under the following conditions:
  • the analysis carried out can only be used to modify the operation of the input forms, by acting as if the database structure had been reorganized ("virtual reorganization" of the database of data).
  • the layout of the forms is then carried out from the dependencies (and keys) memory 550.
  • the layout takes into account the levels of kinship between the linked columns of each group.
  • a link key which is one of the candidate keys, selected by the user, or chosen automatically.
  • the field P_ID (COL2) is automatically filled in by the result of the request A-36 searching for "US1" in the column P_SN (COLl) of the already existing rows.
  • the keyword DISTINCT is optional in request A-36, since any line found contains the result sought for COL2 (P_ID).
  • the user can overwrite the values entered by default. It can thus break the dependence between two columns and the operation of the virtual reorganization mode is then interrupted for this pair of columns.
  • step 2270 the same is done for the direct daughter columns, which are also placed in the container.
  • A is the direct daughter of B if there is no column C, other than A and B, such that B is the mother of C and C is the mother of A).
  • B is the mother of C and C is the mother of A.
  • the process ends in 2290 when the container is empty. This makes it possible to treat the sisters of the field targeted in 2200, as well as to completely browse the tree of his daughters, granddaughters (and their sisters), and so on.
  • a modification is equivalent to a deletion followed by a creation.
  • the present invention profoundly modifies the usual development cycle: The functional dependencies are deduced from the dependencies between the data. This minimizes the analysis phase. This also makes it possible to reveal dependencies not envisaged or not present at the origins.
  • the present invention can therefore also be used as a tool for finding correlations between data and as a tool for partitioning data into domains.
  • the invention thus provides a means allowing in particular to reorganize a database, after a certain operating time.
  • This means can be implemented on the sole initiative of the user. It can be offered at regular intervals, over time, or depending on the growth of the database.
  • the analysis part can be implemented automatically, at least partially, in order to determine if there is indeed something to do.
  • this analysis part is kept up to date in the background. More generally, the analysis means and its storage means then operate permanently, dynamically (rather than from time to time, at the request of the user, or at the request of the development tool).
  • the station (or one of them) can be equipped with an automaton ("trigger"), which triggers the update of the analysis as soon as an event occurs likely to influence this analysis. To do this, it may be necessary to keep a permanent record (directly or indirectly) of all the variables processed during the analysis phase.
  • an automaton which triggers the update of the analysis as soon as an event occurs likely to influence this analysis.
  • the analysis phase is not necessarily followed by such a reorganization.
  • the user can indeed refuse the reorganization for various reasons, such as the time it will take, or the fact that he is not convinced of the usefulness of dividing his table into two parts, for example.
  • the present invention applies in general to any type of data, any type of relationship between data, any type of database (not necessarily relational), any type of language for accessing databases, any type of database architecture, all types of operating systems, all types of storage media and storage systems.
  • the invention therefore extends its effects to any file management system, accessible by a programming language which would make it possible to write the detailed equivalent of the SQL orders mentioned in the description.
  • the power of the SQL query builder described means that it can generate (in particular) all the desired statistical queries. With other languages, it may be necessary to create a module (procedure) for each of these statistical queries. In this case, the structure of figure 10 can be found modified: the statistical tool 520 would only receive data to be processed, while the tables to access the columns would be queried directly by the analysis module 530.
  • each statistical operation is carried out on all the rows, for one or two columns chosen.
  • a variant of the SELECT COUNT of appendices A-31 would consist in browsing the values of the column considered, by making a detection of new value: if the value has already been encountered, we go to the next; otherwise we reference this value as being one of the values taken by the column, we increment a counter and we pass to the next value. At the end, the value of the counter gives the number of distinct occurrences taken by the column.
  • each set for a first column is equal to one set for the second column, or if several sets for the second column are combined, then the first column is the daughter of the second.
  • a comparison operation between meetings and / or intersections of row lists (of a predefined format) is accessible to the person skilled in the art. From there, the realization of an automaton performing the above functions to perform the analysis is also. This automaton is more efficient than the aforementioned SELECT orders, at least for certain applications.
  • storage in the form of a line is not compulsory.
  • index the list of line numbers
  • the reconstruction of a line is then done dynamically by finding the different values of the columns of this line by searching for the line number in the lists assigned to each column.
  • TABl (COLl, COL2)
  • TAB2 (COL2, COL3)
  • COL2 will become an external key of TABl and the primary key of TAB2.
  • the indexes of the lines which block the dependence are easily obtained by considering the empty intersections of the sets of indexes which are neither empty, nor equal to the set of indexes of the almost child column.
  • appendix A-27-3 shows that the dependency is blocked by the set of two sets of index following:
  • the dependency When deleting a row, the dependency is only restored if the set of index sets blocking the dependency contains only one element.
  • deleting line 1 gives ⁇ 2 ⁇ , ⁇ 6 ⁇ . There is more than one set, so dependency is not restored. But deleting line 2 gives ⁇ 6 ⁇ . Addiction is restored.
  • the modification of a line can be treated for example as the sequence of a deletion and a creation in any order.
  • the invention could also be expressed in the form of a process. It also results in a significantly improved development tool.
  • the simplest version of this development tool includes the means to perform the following functions:
  • said tool will include the means allowing the following operations to be carried out, in order to accommodate (import) an already existing file:
  • each line is divided into an identical number of columns.
  • the data can only be in numeric, alphanumeric or date format: For a column to be in numeric format, all the values of this column must be in numeric format. For a column to be in date format, all the values in that column must be in date format. If not, the column is in alphanumeric format.
  • the width and the precision of the column are determined: The width is equal to the sum of the maximum number of digits located in front of the decimal separator and the maximum number of digits located behind the decimal separator. The precision is equal to the maximum number of digits behind the decimal separator.
  • the width of the column is determined. The width is equal to the maximum number of characters in the column.
  • the SQL order is of the form given in A-35, where TABl is the name of the table to be created, COLl ... COLn the name of the columns of the table and FORMAT1 ... FORMATn the corresponding formats; FORMATi is one of the following forms:
  • VARCHAR2 (L) for the alphanumeric format where L is the width of the column.
  • the tool can also include the means making it possible to carry out the following operations: - creating forms allowing access to the data contained in the tables, while validating the insertion, deletion or modification of a line can only be done if the following constraints are respected:.
  • the value of a column must always match its format.
  • a primary key column should have only unique values.
  • An external key column must have a set of values included in the set of values for the corresponding primary key.
  • the development tool advantageously includes means for generating states, with:
  • - a graphics generator to present the results of query requests where the user simply specifies the query query comprising from zero to several columns of the label type and one or more columns of the numeric type, the format of the column of the label type (possibly), the format of the graph.
  • the analysis module could stop based on selected criteria, including the fact that it has already found a group of linked columns (without false dependencies). We could also follow directly on the re-structuring, without selection by the user, as soon as the analysis gives a group of linked columns.
  • the link key could then be chosen from among the candidate keys, such as:
  • a calculated column is a formula made up:
  • PRIX_HT * 1.206 where * is the symbol of the multiplication and PRIX_HT a column of a table corresponding to a price without tax.
  • TAUX_TVA is a column of a table corresponding to a rate of VAT.
  • NO_FACTURE Counting
  • Sum (PRICE_UNITARY * QUANTITYJZOMMANDED) where Sum () is a summation operator, PRICE_UNITARY is the unit price column of an item table and QUANTITY_COMMANDED, the ordered quantity column of an order table.
  • a restrictive condition is composed:
  • an interrogation request consists of:
  • SELECT * FROM STUDENTS UNIVERSITES returns a Cartesian product of the two tables (n times p rows), which can be considered as a new table reviewing all the universities for each student.
  • UNIVERSITY CODE UNIVERSITY. CODEUNIVERSITE returns n lines only (1 per student). The SQL engine created a loop to arrive at this result: we loop on the STUDENTS table and for each student we search for information from his university thanks to the CODEUNIVERSITE.
  • the meta-dictionary (of the development tool), which is stored in the database, contains, as a minimum:
  • This SELECT SQL order is broken down into several lines (Here, with the exceptions mentioned or obvious, indented lines are in principle part of the same SQL order as the previous line).
  • the first line of the query indicates in "Col- ⁇ , Col 2 , ... Col n " the list of columns (simple or calculated) that will be extracted by the query.
  • the second line determines in TAB-L, TAB 2 , ... TAB p ⁇ the set of tables to which the simple columns and the components of the calculated columns belong, first for the list of columns, but also for the rest of the SQL order, essentially the restrictive conditions.
  • VAL i a value, a set of values or nothing according to the choice of the operator OP ⁇
  • the fourth line of the query concerns the restrictive conditions for columns (simple or calculated) which do not contain, directly or indirectly, a set function; it is of the form:
  • the third and fourth lines are preceded by the keyword 'WHERE' and are linked, if both exist by the keyword 'AND'.
  • the fifth line of the query concerns columns (simple or calculated) which do not contain, directly or indirectly, a set function; Let COL_NON_ENS 1 , ... COL_NON_ENS u these columns. Then come in the sixth line the restrictive conditions on the calculated columns which all contain at least one set function denoted COL_ENS i .
  • a sort order has a column (simple or calculated) and an ASC (ascending) or DESC (descending) direction.
  • the third part is present as soon as two tables (at least) are involved in the list of columns or conditions.
  • the rest is optional.
  • Sort order Product name, ascending.
  • the Product Serial Number and Product Name columns belong to the same PRODUCTS table.
  • SQL asks to remove the ambiguity by specifying in front of the name of columns which could cause confusion the name of the table to which they relate (followed by an expected separator, in SQL one point).
  • Line D3 or lines D4 block dependence, because D cannot determine both 3 and 4, whether there is dependence.
  • El and E2 are the names of these tables for COLl and C0L2, we will write for example:

Abstract

L'invention concerne un dispositif de traitement de données comprenant un système de gestion de bases de données (470). Le système de gestion (470) peut coopérer avec un système d'exploitation pour permettre à l'utilisateur la création/saisie et/ou l'usage d'une base de données comprenant au moins une table de données (475), décomposable en lignes et colonnes. Selon l'invention le dispositif comporte en outre: un méta-dictionnaire autonome (510), pour mémoriser dynamiquement des informations choisies relatives à la structure de chaque table de la base de données, et aux liens entre tables, un moyen d'analyse (530) capable de déterminer et de mémoriser au moins temporairement une représentation de groupes de colonnes liées entre elles, et un module de re-structuration (580, 590) coopérant avec le moyen d'analyse et le méta-dictionnaire en vue d'établir pour l'utilisateur une présentation de la base de données qui tienne compte d'au moins un groupe de colonnes ainsi liées.

Description

Dispositif d'analyse et d'organisation de données
La présente invention concerne les systèmes de traitement et de stockage de l'information du type bases de données.
De tels systèmes peuvent être rendus accessibles à des utilisateurs non initiés, à l'aide d'outils de développement appropriés. Ces outils sont très souvent utilisés par les professionnels (les hommes du métier), car ils allègent considérablement les coûts de développement des applications articulées sous la forme base de données.
Par ailleurs, on sait que la qualité d'une application est fortement tributaire de la qualité de l'étude initiale des besoins à satisfaire, et par conséquent du budget qui y a été consacré. Or, du fait de leur élaboration "mécanique", les modules obtenus à l'aide des outils précités sont généralement peu souples. En fait, leur souplesse est orientée davantage sur l'aménagement de l'interface utilisateur, que sur d'éventuelles variations des besoins plus fondamentaux.
Pour ces raisons, et aussi en fonction de l'évolution natu- relie des besoins, il est fréquemment nécessaire de modifier par la suite une telle application. Une telle modification ultérieure est une tâche très lourde, dont le poids croit beaucoup plus vite que la complexité de l'application considérée. Actuellement, elle est pratiquement inaccessible aux non-spécialistes, tandis que, faite par les spécialistes, elle entraîne des coûts qui croissent très vite, au point qu'il est souvent moins onéreux de tout refaire à chaque fois.
Cette situation, qui sera illustrée plus loin sur un exemple très simple, n'est évidemment pas satisfaisante.
La présente invention a notamment pour but d'apporter une solution à ce problème.
Le dispositif de traitement de données proposé à cet effet est du type comprenant au moins un ordinateur, muni d'une unité centrale avec un processeur, au moins un périphérique utilisateur, et une mémoire, animés par un système d'exploitation, ainsi qu'un système de gestion de bases de données, stocké dans cet ordinateur, et propre à coopérer avec le système d'exploitation pour permettre à l'utilisateur la création/saisie et/ou l'usage d'une base de données comprenant par exemple au moins une table de données, décomposable en lignes et colonnes.
Par "système de gestion de bases de données", on entend ici couvrir tout système de fichiers informatiques permettant de gérer des tables, quel que soit le mode de stockage physique de celles-ci.
L'invention inclut dans ce dispositif des moyens que l'on peut appeler un outil de développement et d'assistance.
La fonction d'assistance est réalisée par le fait que, dans un moyen formant méta-dictionnaire autonome, on mémorise dynamiquement des informations choisies relatives à la structure de la base de données, typiquement les tables et les liens entre tables, ou des informations équivalentes.
Il s'y ajoute une fonction d'analyse, qui détermine et mémorise (au moins temporairement) une représentation de groupes de colonnes dont les contenus sont liés (des colonnes liées sont des colonnes interdépendantes, ou, plus généralement, dépendantes les unes des autres).
En pratique, la fonction d'analyse peut faire intervenir un outil statistique, propre à déterminer des interdépendances, et de préférence également des dépendances, entre des jeux de données, par dénombrement d'occurrences distinctes, et un module (pilote) d'analyse capable de coopérer avec le éta- dictionnaire et avec cet outil statistique, pour obtenir et mémoriser ladite représentation de groupes de colonnes liées. Avantageusement, l'outil statistique est fondé sur un moyen de comptage, lequel opère de préférence directement sur les colonnes de chaque table, d'une manière que l'on décrira plus loin.
Le module d'analyse peut être agencé pour réitérer la présentation de sous-groupes d'au moins deux colonnes, jusqu'à trouver au moins un sous-groupe dont les colonnes soient liées, ou jusqu'à épuisement des possibilités. De préférence, il réalise systématiquement la présentation de tous les sous- groupes de colonnes différents possibles pour ladite table, de préférence aussi pour toutes les tables de la base de données .
A partir de l'analyse, on peut procéder à une restructuration, afin d'établir pour l'utilisateur, au moins en création/saisie, une présentation (ou "vue") de la base de données qui tienne compte d'au moins un groupe de colonnes liées .
Le module de re-structuration, avantageusement associé à un module d'interface utilisateur, commence par sélectionner une table de départ à traiter, des colonnes à traiter parmi au moins un groupe de colonnes liées, et une clé primaire de lien pour ce groupe de colonnes.
La restructuration peut s'effectuer par construction d'une nouvelle table avec les données d'un groupe de colonnes liées, ainsi qu'avec une clé de lien avec la table considérée.
Elle peut aussi s'effectuer par le fait qu'en mode saisie de données (formulaire), on restreint par défaut l'accès en modification à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement accessibles en lecture, voire inaccessibles.
Le moyen d'analyse et ses moyens de mémorisation peuvent opérer de différentes manières, notamment: à la demande et/ou sur satisfaction de certains critères (qui peuvent comprendre une analyse partielle), ou bien, à l'opposé, en permanence, de façon dynamique (éventuellement pour l'analyse partielle, seulement ) .
L'invention peut aussi s'exprimer sous la forme d'un procédé appliqué à un ordinateur, ou bien sous la forme du produit industriel nouveau que constitue l'outil de développement.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, de ses annexes, et des dessins annexés, sur lesquels:
- les figures 1 et 2 illustrent deux exemples d'architecture de systèmes de traitement d'information utilisables selon 1' invention,
- la figure 3 illustre la combinaison de moyens dans laquelle se manifeste l'invention,
- la figure 4 illustre graphiquement un lien entre deux tables,
- les figures 5 et 5A illustrent le contenu de deux tables, Composants et Produits, - la figure 6 illustre un rapport relatif aux deux tables des figures 5 et 5A,
- la figure 7 illustre une table unique correspondant aux deux tables des figures 5 et 5A, et la figure 7A illustre la même table unique, mais avec des anomalies de saisie, - la figure 8 représente l'allure à l'écran d'un formulaire de saisie d'informations, relatives aux composants et aux produits, gérées sur une seule et même table,
- la figure 9 représente le résultat d'une requête d'interrogation à partir de la structure monotable de la figure 7, - la figure 10 est le schéma bloc détaillé des moyens d'analyse selon l'invention,
- la figure 11 illustre la signification des graphismes de blocs utilisés ici dans les organigrammes, la figure 12 (découpée en 12A et 12B) illustre l'organigramme de fonctionnement du constructeur de requêtes,
- la figure 13 illustre l'organigramme de fonctionnement du module d'analyse, et la figure 13A illustre un organigramme complémentaire optionnel de fonctionnement du module d' analyse,
- la figure 14 représente le résultat d'une requête de recherche de fausse dépendance à partir de la structure monotable de la figure 7A,
- la figure 15 montre l'écran de sélection en vue de la réorganisation, la figure 16 (découpée en 16A et 16B) illustre l'organigramme de fonctionnement des modules de sélection et de réorganisation,
- la figure 17 représente les jointures de la structure avec trois tables Composants, Produits et Catégories, la figure 18 représente le formulaire de saisie des composants après la réorganisation des informations relatives aux produits, et la figure 18A représente un formulaire simplifié de saisie des composants après la réorganisation des informations relatives aux produits,
- la figure 19 représente le résultat de la requête d'interrogation après la réorganisation des informations relatives aux produits, et la figure 19A représente le résultat de la requête d'interrogation après une nouvelle réorganisation des informations relatives à la catégorie de produit, et
- la figure 20 illustre l'organigramme de fonctionnement de la variante de réorganisation virtuelle.
En fin de description:
- l'annexe I rappelle certaines notions connues, utiles à la compréhension de la description,
- l'annexe II détaille sous forme de texte certains éléments de l'invention, et
- l'annexe III est essentiellement constituée d'ordres SQL intervenant dans un exemple de mise en oeuvre de l'invention.
Les dessins et annexes à la description sont, pour l'essentiel, de caractère certain. En conséquence, ils pourront non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.
Le système informatique de la Figure 1 comporte:
- au moins un ordinateur 100, dit client, avec une unité centrale 110 (CPU, mémoire vive etc.), un écran 120, un clavier 130, une mémoire de masse 140 (disque dur par exemple), un périphérique de pointage 150 (souris par exemple), une imprimante 160, et un périphérique 170 permettant d'accéder à un réseau (local ou distant) ainsi que le logiciel correspondant, et
- un ordinateur 200, dit serveur, comportant une unité centrale 210 (CPU, mémoire vive etc.), un écran 220, un clavier 230, un système de stockage de fichiers 240 (disque dur par exemple), éventuellement un système de pointage 250, un périphérique 260 permettant d'accéder au réseau (local ou distant) ainsi que le logiciel correspondant.
La mémoire de masse (ou une autre mémoire) des deux ordinateurs loge un système d'exploitation. Pour le "client", on prendra par exemple un système d'exploitation à interface graphique, tel que Windows, OS/2 ou MOTIF par exemple (Marques déposées). Pour le serveur, l'interface graphique est moins utile dans certains cas, et l'on peut prendre Windows NT, OS/2, Unix, ou Novell par exemple (Marques déposées). Le système d'exploitation est lancé, de façon connue, en général au démarrage de l'ordinateur.
Une base de données est installée sur le système de stockage du serveur. Chaque donnée ("item" de données) est matérialisée par une suite ordonnée d'empreintes (magnétiques, optiques, magnéto-optiques ou autres) sur le support de stockage (disque ou autre), accessible par exemple via un langage de type SQL, et à l'aide d'un moteur de base de données, installé sur le système de stockage. Du côté du ou des ordinateurs "client", il suffit de prévoir des programmes, enregistrés sur le système de stockage, permettant d'accéder à la base de données via un langage approprié, par exemple le langage SQL.
La figure 2 illustre une configuration "monoposte" intégrant certains de ces éléments sur un seul ordinateur. Il n'y a alors qu'un périphérique de stockage (140+240), et le périphérique permettant d'accéder au réseau (170) est inutile.
Bien que l'invention puisse s'appliquer à de nombreux systèmes de gestion de bases de données, ou s'appuyer sur un simple système de fichiers, on admettra dans un premier temps de la description que le système informatique est muni d'un moteur de bases de données relationnelles. Sur ce plan, il est fait mention à toutes fins utiles des ouvrages suivants, qui sont incorporés aux présentes à titre de référence:
- "Les bases de données relationnelles", par André FLORY et Frédérique LAFOREST, édité chez ECONOMICA, 1996, notamment en son chapitre 2, pour ce qui concerne les fondements et les objectifs du modèle relationnel pour les bases de données, et en son chapitre 4 pour la théorie de la normalisation des bases de données relationnelles,
- "Relational Databases and Knowledge Bases", par Georges GARDARIN et Patrick VALDURIEZ , édité chez ADDISON WESLEY, 1989, notamment en son chapitre 4, pour ce qui concerne les fondements et les objectifs du modèle relationnel pour les bases de données, et en son chapitre 5 pour la théorie de la normalisation des bases de données relationnelles,
- "Concevoir et développer avec Oracle et Case", par Hatem SMINE édité chez Eyrolles, 1994, notamment en ses chapitres
9 et 10, pour les techniques et outils de développement d'applications s 'articulant sur une base de données relationnelles, dans le cas exemplaire de la base de données Oracle et de ses outils de développement. - "Using the Oracle toolset", par Mike KROHN édité chez Addison-Wesley, 1993, notamment en ses chapitres 6, 7 et 11, pour les techniques et outils de développement d'applications s 'articulant sur une base de données relationnelles, dans le cas exemplaire de la base de données Oracle et de ses outils de développement.
La chaîne de traitement de l'information est illustrée sur la figure 3, avec:
- en 410, une unité de traitement, par exemple l'une au moins des unités 110 et 210 (Figures 1 et/ou 2) ;
- en 440, la mémoire de masse, par exemple l'un au moins des disques durs 140 et 240 ; - en 450, le système d'exploitation qui permet d'accéder aux informations physiques de la mémoire de masse, sous la forme d'un système de fichiers 460. On notera que les liens physiques sont en trait plein, tandis que les liens logiques sont en trait tireté. Le reste de la figure 3 dépend essentiellement du système de fichiers, par conséquent de la mémoire de masse 440 et de l'unité de traitement 410, à travers le système d'exploitation 450.
- en 470, le moteur de la base de données, qui accède aux données logiques 475. - en 471, un "dictionnaire interne" (c'est le nom généralement donné, dans les bases de données relationnelles, aux informations sur la structure de la base de données, qui sont stockées de façon accessible au moteur de bases de données, mais inaccessible en modification directe par l'usager - lecture seulement).
- en 500, l'outil de développement (partie générale) qui accède à la base de données 475 (tables, formulaires, états, notamment) .
Comme on le verra plus loin, l'outil de développement 500 travaille avec un générateur de tables, formulaires et états 505, un méta-dictionnaire 510, un module d'analyse 530, un module de sélection 570, ainsi qu'un module de réorganisation physique 580, et/ou un module de réorganisation virtuelle 590.
Les éléments fondamentaux d'une base de données sont les "tables". Chaque table est un ensemble de lignes ; chaque ligne est organisée en une ou plusieurs colonnes ; et chaque colonne correspond à un type de données. Chaque ligne comprend une et une seule valeur (la "donnée") pour chaque colonne de la table. Physiquement, le stockage des données peut correspondre à cette structure en table, ou bien être différent.
Chaque table comprend généralement au moins une colonne qui ne contient que des valeurs uniques (est "unique" une valeur que l'on ne trouve qu'une seule fois dans la colonne de la table considérée), ou bien un moyen équivalent, numéro de ligne par exemple, agencé ou non en colonne de la table. Cette colonne (ou l'une d'entre elles) est alors appelée clé primaire. La valeur de la clé primaire permet de retrouver de façon univoque la ligne correspondante, d'où son intérêt. Toutes les colonnes qui ne contiennent que des valeurs uniques peuvent servir de clé primaire.
Il est très fréquent qu'une table "de détails" doive référencer les informations d'une autre table ("maître"). A cet effet, on peut prévoir dans la table de détails une colonne dite "clé externe", qui contient la clé primaire de la table maître. Lors d'un accès conjoint aux données de deux tables, ces deux tables sont liées par une "jointure" (relation maître-détails): lors d'un accès à la table maître, on utilise la clé externe pour faire apparaître en même temps tous les détails correspondants contenus dans la table de détails; inversement, lors d'un accès à la table de détails, on peut utiliser la clé primaire de la table maître pour faire apparaître en même temps des données complémentaires contenues dans la table maître. Cette notion de jointure ou lien entre tables est illustrée par le diagramme de la figure 4, avec une table de Clients, et une table de Factures, dans le cas d'une gestion de facturation.
La présente description détaillée s'appuiera sur un autre exemple concernant une chaîne de production d'ordinateurs (les produits), fabriqués par assemblage de composants. On verra qu'on peut élaborer deux tables "Produits" et "Composants", ayant par exemple les contenus illustrés aux figures 5 et 5A. Ici, la clé primaire de la table "Composants" est la colonne C_SN (le numéro de série du composant); c'est également la clé externe de la table "Produits". Par le biais de la liaison entre les deux tables, on peut déterminer, par exemple, que les composants dont les C_SN sont "11", "13" et "14" font partie du produit dont le numéro de série du produit P_SN est "US1" .
Le couple de tables Produits-Composants est du type maître- détails car :
- à un produit, il correspond de zéro à n composants (le cas zéro correspondrait à un produit dont les composants ne sont pas encore définis ou pas encore présents dans la table des composants), et
- à un composant, il correspond un et un seul produit.
Une telle jointure entre deux tables implique certaines contraintes d'intégrité quant aux valeurs de la clé primaire et de la clé externe correspondante : à chaque valeur de la clé externe, il doit correspondre une et une seule valeur de la clé primaire.
L'ensemble des jointures pour lier deux tables entre elles est appelé chemin. Certaines structures de bases de données sont telles qu'il peut exister plusieurs chemins entre deux des tables qu'elles contiennent. Par exemple deux tables Clients et Fournisseurs peuvent être liées par un chemin passant par une table Commandes ou par un chemin passant par une table Pays. Inversement, il peut ne pas exister de chemin entre deux tables. Par exemple, deux tables "Production" et "Historique_de_production" bien qu'ayant la même structure et contenant des données de même essence n'ont aucun lien (au sens de la structure des données) entre elles.
L'usage de jointures ou liens permet de réduire les redondances d'informations. Dans une base de données idéalement conçue, une information pertinente particulière n'est stockée qu'une seule fois (sauf les couples clé primaire - clé externe nécessaires aux liens). Cela offre un gain de place. En outre, les mises à jour sont facilitées. Ainsi (figures 5 et 5A) , la modification du nom du produit (P_NAME) ayant un numéro de série P_SN égal à US1 n'implique la modification que d'une seule ligne (dans la table Produits) alors qu'il est constitué de trois composants.
L'accès aux données d'une table s'effectue par un formulaire affiché à l'écran. Un formulaire est composé de champs, dont chacun correspond à une colonne d'une table. Il permet d'insérer des nouvelles lignes dans la table (création), de modifier les lignes existantes, de supprimer des lignes. Un formulaire qui permet d'accéder à plusieurs tables doit alors respecter les contraintes d'intégrité de la structure concernée.
Un rapport (voir exemple en figure 6) présente des colonnes choisies d'une table, pour des lignes sélectionnées par une requête (parfois pour toute la table). Le résultat est affiché à l'écran et/ou imprimé. Un rapport peut interroger et présenter les données de plusieurs tables, mais il doit alors connaître la structure correspondante (clés externes, clés primaires et jointures). En plus des rapports, il est possible de définir des graphiques affichés à l'écran et/ou imprimés.
Les rapports et les graphiques sont communément appelés états. Les formulaires et les états sont communément appelés programmes . Et les programmes accèdent aux données via des requêtes.
Les états sont accompagnés de requêtes d'interrogation. Suivant la manière dont sont conçus les outils générateurs d'états, on peut considérer que la requête d'interrogation est incluse dans l'état et/ou séparée de l'état. On connaît aussi les requêtes d'insertion, les requêtes de mise à jour et les requêtes de suppression, qui sont en principe réservées aux formulaires . Dans cette description détaillée, on utilisera le langage de requêtes dit SQL (Structured Query Langage). Le langage SQL a fait l'objet de plusieurs normalisations, dont la dernière est la norme SQL-92 ANSI/ISO. Les mots-clés des ordres SQL sont présumés compris du lecteur. Le cas échéant, ils pourront être trouvés dans la norme susvisée. Pour une chaîne de caractères, on utilise comme délimiteur soit les guillemets ("), soit l'apostrophe ('). L'Annexe I de la description illustre les principales autres notions dont il faut disposer pour comprendre la présente description, à savoir:
- en A-ll, les colonnes calculées,
- en A-12, les conditions restrictives,
- en A-13, le principe général d'une requête (ordre SELECT de SQL).
Le langage SQL permet d'accéder aux bases de données relationnelles en respectant une indépendance entre la façon dont les données sont physiquement stockées et la façon de manipuler logiquement ces données. Par sa puissance, le langage SQL permet d'exprimer simplement des traitements complexes, incluant notamment des boucles imbriquées (par le biais de jointures): voir les exemples A-13-1 et A-13-2. Mais le recours au langage SQL n'est nullement limitatif, et la présente invention peut tout aussi bien s'appliquer à l'aide d'un langage de plus bas niveau, qui attaquerait directement le système de fichiers du périphérique de stockage, par exemple .
De façon générale, une application regroupe un ensemble de programmes s 'articulant autour d'une structure donnée (tables et contraintes d'intégrité). Un menu permet de sélectionner, au sein d'une application, le programme avec lequel on veut travailler.
Le développement d'applications s 'articulant autour de moteurs de base de données a été plus ou moins automatisé par les outils de développement. Un outil de développement est un logiciel qui offre au programmeur une bibliothèque de générateurs de programmes. Ces générateurs de programmes permettent de diminuer notablement les temps de développement : lors de l'utilisation d'un générateur de programmes, le programmeur saisit des paramètres plutôt que d'écrire du code source ; ces paramètres sont ensuite interprétés pour engendrer un programme en code source que le programmeur peut modifier ou enrichir manuellement, dans la mesure où il maîtrise le code source.
Le développement d'applications s 'articulant autour de moteurs de base de données suit en principe la démarche méthodologique suivante : le programmeur effectue une analyse des besoins. Il peut utiliser pour cela une méthode de conception (Merise par exemple) dont l'ensemble ordonné des règles opératoires le guide en systématisant le processus de réflexion et en évitant les erreurs de conception. L'analyse permet de définir un "modèle de données" qui exprime de façon pertinente la sémantique des données. (Un modèle de données peut être représenté graphiquement par un diagramme Entité- Relation.). La phase d'analyse des besoins demande au programmeur une bonne connaissance de l'algèbre relationnelle et de la normalisation de la structure d'une base de données.
Avec un outil de développement élémentaire, la structure physique des données doit être implantée dans la base de données à partir du "modèle de données". Après cela, l'outil de développement permet de définir des formulaires et des états s 'articulant sur la structure (en s 'appuyant sur le dictionnaire interne) ainsi que des menus. L'utilisateur peut alors enrichir ces formulaires, états et menus.
Avec un outil de développement évolué (plus complexe), la structure des données est saisie et stockée dans un autre dictionnaire, propre à l'outil de développement. Les données que l'on saisit à ce stade, et celles des traitements correspondants s'appellent "méta-données" . Cet autre dictionnaire, ou "méta-dictionnaire" (510, figure 3), est distinct du dictionnaire interne. Il s'articule sur un système de fichiers indépendants ou sur des tables de la base de données elle-même (accessibles en modification, seulement via l'outil de développement).
Le méta-dictionnaire fait l'objet d'éventuels contrôles de cohérence par l'outil de développement et peut même intégrer certaines règles opératoires d'une méthode d'analyse (Outils du type CASE). A partir de ce méta-dictionnaire, le générateur 505 (figure 3) de l'outil de développement prend en charge les tâches suivantes:
- la structure physique de la base de données est créée, à l'aide du méta-dictionnaire (le dictionnaire interne est mis à jour en conséquence);
- les programmes et les menus (éventuels) sont générés par l'outil de développement. le générateur de rapports compose plusieurs requêtes d'interrogation (généralement une par ensemble de tables), et construit un rapport-type pour chaque requête.
L'utilisateur peut alors les enrichir.
Ainsi, la complexité de l'accès à la base de données est plus ou moins masquée à l'utilisateur, en fonction de la qualité (niveau de complexité) de l'outil de développement.
Tout ceci permet d'exploiter une base de données. Une fois l'exploitation démarrée, il peut être nécessaire de modifier le modèle de données et donc la structure de données, et ce pour différentes raisons, par exemple : - le besoin applicatif peut avoir évolué (évolution du métier par exemple) ,
- le besoin initial était mal défini (cahier des charges inadéquat), ou traité par un non initié.
Une modification ponctuelle de la structure des données (ajout d'une colonne dans une table par exemple) est diversement bien acceptée par les outils de développement : s 'agissant d'un outil "rustique", l'utilisateur doit modifier manuellement la structure des données, ainsi que les requêtes dans les formulaires et états concernés. - Par contre, avec un outil de haute performance, plus complexe, il suffit de mettre à jour le méta-dictionnaire de l'outil de développement, et cela est répercuté automatiquement sur la structure physique des données ainsi que sur les requêtes des formulaires et états.
Une modification plus conséquente de la structure des données (ajout de tables, séparation d'une table en plusieurs tables par exemple) est très lourde, si l'on désire conserver les données déjà saisies. Et l'utilisateur va se heurter à plusieurs difficultés : a) la nouvelle structure, même si elle respecte l'intégrité relationnelle, n'est peut-être plus en adéquation avec les besoins de l'application. Les données peuvent devenir inexploitables . b) la syntaxe des langages (procéduraux ou non) d'accès aux données est complexe et beaucoup de modifications non prises en compte par l'outil de développement sont à faire manuellement. c) les modifications à effectuer aux requêtes des formulaires et états sont complexes. d) la modification de la structure est elle-même délicate et complexe si l'on désire conserver les données existantes (un exemple très simple: ayant une colonne numéro d'article, on veut faire passer celle-ci du type numérique au type caractère) .
La génération par l'outil de développement d'une nouvelle version (basée sur la nouvelle structure) redonne les versions de départ des formulaires , états et menus . On perd donc tout l'enrichissement apporté par la suite à ceux-ci. Dans tous les cas, il n'est pas facile, sous l'action d'un outil de développement, de modifier physiquement la structure de données, et de modifier l'application pour satisfaire un besoin non envisagé aux origines. Ce qui précède montre 1 ' importance du problème posé . On procédera maintenant à la description de l'invention, qui se propose de résoudre ce problème technique d'une manière élégante et fiable.
L'invention permet de partir dans tous les cas d'une structure mono-table. Elle permet ensuite à l'utilisateur lui-même de modifier la structure des données, une fois la production démarrée, en fonction de ses nouveaux besoins. Elle ne nécessite en effet aucune connaissance particulière de la technique d'accès aux données (langage SQL par exemple), ni des principes régissant les structures de données relationnelles. Elle permet ainsi des économies de temps d'analyse, de temps de développement et de temps de modification ultérieure. Elle est adaptée à toutes les bases de données relationnelles du marché, de même qu'à d'autres systèmes de gestion de données .
L'invention fournit un moyen ou outil de développement perfectionné, que l'on peut aussi considérer comme un interface d'environnement utilisateur.
Cet outil s'appuie sur un méta-dictionnaire particulier 510 (figure 10), dont le contenu minimal (pour le mode de réalisation préférentiel) est donné en A-21.
Le méta-dictionnaire répète certaines informations déjà contenues dans le dictionnaire interne, comme le nom et le type de chaque colonne de chaque table. Il en contient beaucoup plus. Ce méta-dictionnaire 510 est entretenu par un automate de mémorisation, qui surveille tout événement relatif aux conditions données en A-21. Cette surveillance peut être limitée aux moments où l'outil de développement fonctionne (dans la mesure où il a l'exclusivité des modifications desdites conditions). Elle peut être plus large. Elle est de préférence permanente. L'invention s'appuie aussi sur un constructeur de requêtes 520 (figure 10). Les requêtes construites obéissent à un format général bien défini, nommé ici forme canonique, dont la version actuellement préférée est indiquée en A-22, tandis que des exemples de requêtes canoniques sont donnés en A-23.
La manière dont le constructeur de requêtes travaille, en liaison avec le méta-dictionnaire, est illustrée sur la figure 12. On trouvera sur la figure 11 la signification des graphismes de blocs utilisés dans les organigrammes.
Après le début 900, l'étape 910 présente à l'usager différentes possibilités (disponibles) de sélection de colonnes, simples et calculées, ainsi que de fonctions ensemblistes . Par fonction ensembliste, on entend une fonction portant sur plusieurs lignes, comme SOMME(), COMPTAGE(), MOYENNE(), par exemple. En 911, l'usager peut construire des expressions à partir des colonnes, et/ou fonctions ensemblistes. A partir de là, il peut: - en 912, créer et lier des conditions restrictives,
- en 913, définir un ou des critères de tri (ordonnés).
Ces étapes 910 à 913 constituent l'initialisation du constructeur de requêtes. Elles sont décrites comme faites par l'usager. Mais le constructeur de requêtes peut tout aussi bien opérer automatiquement, en recevant cette initialisation à son lancement, sous la forme de paramètres, qui définissent respectivement les éléments saisis en 911, 912, 913. Il est important de noter que ce concepteur de requêtes peut mémoriser, sous forme de chaînes de caractères, la définition des requêtes qu'il a permis d'écrire.
L'étape 920 détermine l'ensemble des tables auxquelles appartiennent les colonnes et expressions définies en 911 à 913. Ceci est effectué sélectivement pour chacune des expressions intervenant dans la requête canonique A-22. Si une colonne appartient à deux tables, elle est la clé primaire de l'une et une clé externe de l'autre. Le générateur de requêtes peut associer cette colonne à l'une ou l'autre des deux tables (le résultat de la requête sera le même). On prend de préférence la table où la colonne est clé primaire.
Les étapes 921 à 925 et 929 déterminent le chemin reliant ces tables (s'il y en a plusieurs). Eventuellement, l'étape 923 rajoute une ou des tables pour qu'un tel chemin existe, en partant du méta-dictionnaire. On notera cependant que, dès lors que la mise en oeuvre de l'invention part d'une table unique, toutes les tables créées ensuite sont forcément reliées par un et un seul chemin.
En 930 et 931, on construit donc les deux premières lignes de la requête A-22 (et la troisième ligne optionnelle, si les lignes suivantes appellent des colonnes dont les tables n'apparaissent pas dans la seconde ligne).
A l'étape 940, on traite de manière similaire le "suivi" du chemin (éventuel), et la satisfaction des conditions restrictives. Ceci sert à décider (941) d'écrire la clause WHERE, avec une liste de jointures (943) et/ou une liste de conditions restrictives (949).
Ensuite, la clause GROUP BY est écrite en 961, si le test 960 l'indique: existence de fonctions ensemblistes dans les expressions et/ou conditions restrictives.
La clause ORDER BY est écrite en 971, si le test 970 l'indique (les critères de tri peuvent comporter des fonctions ensemblistes).
La clause HAVING est écrite en 981, si le test 980 l'indique: existence de fonctions ensemblistes dans les conditions restrictives.
On observera que ce constructeur de requêtes se charge lui- même de tous les contrôles. Il suffit de lui donner, par saisie, ou bien par passation de paramètres, la liste sélective des expressions à traiter.
A partir de la définition du formulaire stockée dans le méta- dictionnaire, l'invention prévoit aussi de créer automatiquement (dynamiquement) un ou des formulaires.
Ce formulaire est donc adapté à la structure des données. Il permet la consultation, l'insertion, la modification et la suppression de lignes dans la ou les tables concernées. Il respecte l'intégrité des données en imposant les contraintes suivantes :
- la valeur d'une colonne doit toujours être en adéquation avec son type (par exemple, ce qui est saisi dans une colonne de type date doit être une donnée reconnue comme une date).
- une colonne clé primaire ne doit comporter que des valeurs uniques .
- une colonne clé externe doit avoir un ensemble de valeurs incluses dans l'ensemble des valeurs de la clé primaire correspondante.
Toujours à partir du méta-dictionnaire, l'invention prévoit la génération automatique de rapports et de graphiques, par le module 505.
Un rapport est établi à partir d'une requête d'interrogation. Il est possible dans un rapport de définir:
- des formats de présentation ou "enrichissement" (comme: gras, italique, gros caractères), - des calculs de groupe effectués sur les données de la table (comme : totaux, dénombrement ) ,
- des ruptures qui conditionnent la remise à zéro des calculs de groupe. Ces ruptures sont organisées en niveaux. Le niveau le plus haut dit niveau zéro est celui du rapport tout entier. Le niveau 1 correspond à la première rupture (la plus générale) et le dernier niveau correspond aux informations de la rupture de dernier rang. - des conditions restrictives ou "filtres", comme: nom du produit (P_NAME) = "COMPl" , coût (COST) > 1500.
- certains critères de tri.
Selon un aspect de l'invention, les ruptures sont proposées en fonction de la structure de l'application: soient une colonne COL2 qui appartient à un ensemble de tables {TAB2-L ... TAB2p} , et la colonne précédente COLj qui appartient un ensemble de tables {TABllf ... TABln}; ces deux colonnes sont présentées dans le même niveau de rupture, si, pour toute valeur de i, de 1 à n, et pour toute valeur de j, de 1 à p, le chemin pour aller de TABlj^ à TAB2j ne comporte aucune jointure de sens maître-détails. Ces ruptures correspondent à la décomposition en niveaux de la structure et proposent donc à l'utilisateur une présentation par défaut qui est parlante. L'utilisateur peut cependant les modifier à son gré et ne définir certains calculs de groupe que pour certains niveaux de rupture de même qu'insérer ou supprimer des ruptures .
La figure 6 illustre un rapport présentant le nom du produit, le numéro série du composant, le coût avec :
- comme condition restrictive : le nom du produit (P_NAME) doit être différent de "COMPl", - une rupture sur le nom du produit,
- un total des coûts (COST) des composants,
- un comptage du nombre de composants.
Un graphique correspond à une interrogation et à une présentation graphique de valeurs de colonnes pour certaines lignes. De façon générale, un graphique est déterminé par des paramètres comme:
- le type de présentation (histogramme, camembert ...)
- le format de présentation (couleur ...) - un ou des critères de tri
- des calculs ( somme ... ) Selon un autre aspect de l'invention, un graphique est établi à partir d'une requête d'interrogation comportant de zéro à plusieurs colonnes de type libellé et une ou plusieurs colonnes de type numérique. Il comprend: - Le format de la colonne de type libellé.
- Le format du graphique. Certains formats de graphique n'acceptent qu'un nombre précis de colonnes de type libellé et de colonnes de type numérique. Par exemple:
. Le camembert ne supporte qu'une colonne de type libellé et qu'une colonne de type numérique.
Le graphique en XY (communément appelé courbe) ne supporte pas de colonne de type libellé et ne supporte que deux colonnes de type numérique (éventuellement des graphiques tri-dimensionnels ) .
Si dans la requête d'interrogation, il y a plus de colonnes de type libellé que ne le supporte le format du graphique, le module 505 génère autant de graphiques éclatés que nécessaire en utilisant un mécanisme similaire à celui des ruptures.
Exemple: soit une requête d'interrogation qui renvoie le chiffre d'affaires (égal à la somme des montants des commandes) par produit et par région (le chemin entre les tables Produits et Régions comporte une jointure de sens maître- détails). Si le format du graphique choisi est le camembert, on va générer un camembert produit / chiffre d'affaires pour chaque région, et un camembert produit / chiffre d'affaires pour toutes les régions confondues.
A l'aide du méta-dictionnaire, l'invention permet d'assurer que la relation entre la requête et l'état (rapport ou graphique) demeure cohérente après toute réorganisation.
L'exemple des figures 5 et 5A donne une version déjà aménagée de la structure de tables. En réalité, s'il cherche à développer une base de données pour ce même exemple, un non- initié va généralement tout mettre dans une seule table . Avec l'invention, l'utilisateur peut toujours commencer avec une seule table, que l'on dénommera ici "Composants_et_Produits" (Figure 7). Pour ce faire, il définit simplement le nom et le type des données qu'il veut saisir. L'outil de développement a mis le méta-dictionnaire à jour, créé une structure de données monotable en accord avec le nom et le type des colonnes indiqués par l'utilisateur, et créé un formulaire par défaut permettant d'accéder à la table, et des états.
Ainsi, l'utilisateur peut démarrer quasi instantanément, sans devoir réfléchir à la structure d'interaction entre ses données: il va, de suite, saisir des données via le formulaire, et éditer des états. La figure 8 représente le formulaire de saisie des informations dans la table "Composants_et_Produits" . La figure 9 représente le résultat d'une requête d'interrogation à partir de la structure monotable (sans filtrage).
Même si elle permet de commencer avec une seule table, l'invention peut aussi s'appliquer au cas où un développeur expérimenté va faire des choix initiaux de structure des tables qui sont guidés par son analyse formelle et des considérations pratiques, dès lors que ces choix doivent être reconsidérés au cours de l'exploitation ultérieure (avec de plus en plus de données ) .
On note en effet que les données d'une table ayant aussi peu de lignes que celle de la figure 7 sont déjà redondantes. L'observateur averti remarque immédiatement des dépendances entre colonnes: CATEG dépend de C_SN, P SN, P NAME.
Mais, au niveau des données, CATEG semble aussi dépendre de C_ID et de C_DESC, d'après les critères précités; en effet:
- les composants SCR17, P166, HD1.2 et SCR15 ne rentrent que dans la fabrication de produits de la catégorie USER, et
- les composants SCR14, P200 et HD2 ne rentrent que dans la fabrication de produits de la catégorie SERVER. Cette dépendance (fausse, car illogique) est due au fait que l'échantillon de données est trop étroit pour être représentatif. Si on fabrique par exemple un produit de catégorie USER avec un disque dur de référence HD2 , la dépendance disparaîtra.
De façon générale, la structure courante de la base de données ne convient plus lorsque certaines données sont redondantes au sein de la table. Autrement dit l'utilisateur est confronté à des anomalies car le modèle de données ne respecte pas ou plus les différentes formes normales du modèle relationnel.
Dans le cas de la figure 7, l'utilisateur pourrait se trouver confronté aux anomalies suivantes : - Suppression : la suppression de l'unique composant d'un produit supprime aussi les informations relatives au produit.
- Mise à jour : la mise à jour des informations d'un produit (son nom par exemple) doit se faire sur toutes les lignes de la table correspondant à ses composants. Il y a donc autant de modification à faire que le produits est constitué de composants .
- Insertion : on ne peut pas créer de produit sans lui affecter immédiatement au moins un composant.
Devant la nécessité de réorganiser la structure de la base de données, l'utilisateur serait normalement astreint à opérer à la main. La présente invention lui fournit à cet effet des moyens que l'on peut décomposer en trois parties (figure 3):
i) l'analyse des données (530),
ii) la sélection par l'utilisateur (570) des colonnes d'une table qui vont être isolées ; durant cette phase, l'utilisateur est encadré par des contrôles de cohérences.
iii) l'exécution (580) de la réorganisation de la structure des données. Les phases ii) et surtout iii) sont optionnelles. On verra en effet qu'il est également possible, en variante, ou en complément, de mettre en oeuvre l'invention sans réorganiser physiquement la base de données (590).
L'aspect de l'invention considéré actuellement comme essentiel est l'analyse. Elle s'appuie ici sur le méta-dictionnaire donné en A-21 (510, figure 10), ou sur un moyen équivalent.
Elle s'appuie aussi sur un outil statistique (520, figure 10), qui, dans une forme de réalisation, consiste en un jeu de requêtes SQL données en Annexe III, et adaptées à différentes opérations de dénombrement systématique, en fonction de la structure courante de la base de données, telle qu'elle figure dans le méta-dictionnaire. Ces dénombrements ne portent pour la plupart que sur des "valeurs distinctes". Les requêtes SQL interrogent directement la ou les tables concernées.
La phase d'analyse, comprend tout ou partie des opérations que l'on va maintenant décrire, en référence à l'annexe III. Elle est pilotée par un module 530 (figure 10).
De façon générale, les colonnes "courantes" notées C et Cj dans la description sont notées COLl et COL2 dans l'annexe III, conformément à la pratique habituelle des hommes du métier.
Le procédé comprend d'abord une analyse (de préférence exhaustive) des répétitions des valeurs des colonnes des tables de données. On décrira cette analyse, en référence à la figure 13, et à l'annexe III.
A partir du début (1000), on détermine les tables de la base de données, ou mieux celles utilisées dans l'application (1010).
Pour chaque table, l'analyse consiste à déterminer : - en 1012, le nombre de lignes, N. En langage SQL, le nombre de lignes d'une table (étape 1012) s'obtient par la requête A-31-1, où TABl est le nom de la table considérée.
- en 1020, les noms des colonnes de la table, Cela s'obtient par lecture du méta-dictionnaire (en variante, du dictionnaire interne).
- Pour chaque colonne C±, le nombre de valeurs distinctes N^ en 1024-1026.
Le nombre de valeurs distinctes d'une colonne d'une table (étape 1024) s'obtient par la requête SQL A-31-2, où COL1 est le nom de la colonne.
- puis déterminer et parcourir les couples de deux colonnes différentes que l'on peut former pour la table (1030)
Cela s'obtient par lecture du méta-dictionnaire (en variante, du dictionnaire interne), sous la forme d'une boucle simple à concevoir.
- Pour chaque couple de colonnes (C^ Cj ) , faire des opérations (détaillées plus bas) permettant de calculer :
. le rapport de dépendance entre elles. . le nombre de couples de valeurs qui bloquent la dépendance.
- Pour chaque groupe de colonnes d'une table (Ci7 Cj ... Cn), les éventuelles clés candidates (de jointure ou lien) pour le groupe.
On revient maintenant sur le calcul du rapport de dépendance de deux colonnes d'une même table. Soient Ni et Nj le nombre respectif de valeurs distinctes des deux colonnes C _ et Cj (calculés en 1024-1026). En 1034, on obtient P, le nombre de couples distincts de valeurs de C.^ et Cj, par la requête A- 31-3, où COL1 et COL2 sont les noms des colonnes C et Cj , tandis que:
"xyz" est une chaîne de caractère inexistante dans la colonne COL1. Le mieux est de prendre une chaîne de caractères a priori invraisemblable. L'absence de la chaîne
"xyz" dans COL1 peut être vérifiée par la réponse zéro à la requête A-31-4. ! ! est le symbole de concaténation des valeurs de deux colonnes, supporté par le moteur de base de données.
Selon la valeur de P par rapport à Nj_ et j , les situations possibles sont:
- cas 1042, avec P > Max(N±, Nj ) il n'y a pas de dépendance entre les deux colonnes (1043). C et Cj sont dites indépendantes. On calculera alors éventuellement le nombre de couples de valeurs qui bloquent la dépendance (cas d'une presque dépendance).
- cas 1046+1047, avec P = N± et P > Nj alors C^ détermine Cj . La colonne ^ est dite mère de Cj . La colonne C est dite fille de C .
- cas 1046+1049, avec P = Nj et P > , alors Cj détermine C-^. La colonne Cj est dite mère de C^ La colonne Cj_ est dite fille de Cj .
- cas 1044+1045, avec P = N± et P = N alors Cj^ et Cj sont dites équivalentes du point de vue des dépendances, ou interdépendantes. C-^ et Cj sont dites soeurs.
- le cas P < Min (Nif Nj ) est impossible.
Les étapes 1050 et 1052 assurent respectivement le bouclage sur toutes les paires de colonnes et toutes les tables jusqu'à la Fin 1059.
Les requêtes mentionnées peuvent être élaborées à l'aide du constructeur de requêtes SQL déjà cité (A-22, et 520, figure 10). Cependant, il sera souvent plus simple de les préparer individuellement à l'avance, sous la forme de chaînes de caractères, dont certains éléments sont variables. Dans les requêtes A-31, les éléments variables sont TAB1, COL1, "xyz" (ou, ce qui est équivalent 'xyz'), et COL2. En liaison avec le méta-dictionnaire, l'étape 1024 (par exemple) de la figure 13, va recomposer la requête A-31-2, en y remplaçant les noms COL1 et TAB1 par le nom de la colonne et celui de la table, respectivement. L'écriture de programmes susceptibles d' implémenter les boucles décrites sur la figure 13 est considérée comme accessible à l'homme du métier à partir de la présente description, et d'un langage procédural comme le langage C et ses variantes (C++ par exemple), ou encore SMALLTALK.
On examine maintenant le cas d'une "presque dépendance", en référence à la figure 13A. Il s'agit d'un couple de colonnes C0L1, C0L2 d'une même table, pour lequel chaque valeur de C0L1 permet de déterminer de façon univoque la valeur de C0L2 "à quelques exceptions près". Un exemple est donné en A-24.
De façon générale, le nombre de couples de valeurs, B, qui bloquent la dépendance mère-fille entre deux colonnes C^ et Cj s'obtient (étape 1210, figure 13A) par la requête A-32-1, où a et b sont des alias définis sur la table TABl, et les autres variables sont définies comme précédemment, (un alias de table permet d'accéder à celle-ci sous un autre nom que le sien; plusieurs alias sur la même table permettent d'accéder à celle-ci de deux manières indépendantes).
Si B est faible, il pourra être intéressant de forcer la dépendance ; l'utilisateur devra alors normaliser les deux colonnes. Les colonnes C et Cj sont dites respectivement pseudo-mère et pseudo-fille. On parle aussi de "pseudo-soeurs" dans le cas particulier où chacune des deux colonnes joue vis à vis de l'autre le rôle de pseudo-mère et de pseudo-fille. Cette normalisation de deux colonnes pour forcer la dépendance sera maintenant décrite.
Il faut d'abord identifier les couples de valeurs, qui bloquent la dépendance mère-fille entre deux colonnes C et Cj . Ceci est fait à l'étape 1230 (figure 13A) , à laquelle correspond la requête A-32-2. Cela permet d'apprécier, pour une valeur de la colonne pseudo-mère, les fréquences des différentes valeurs de la colonne pseudo-fille correspondante. La requête A-32-2 comprend un ordre SELECT imbriqué, qui compte le nombre d'occurrences (supérieur à 1 ) du couple de valeurs au sein de la table. On recherche d'abord les valeurs de COLl qui bloquent la dépendance. Il s'agit des valeurs de COLl telles que le nombre de valeurs distinctes de COLl! ! 'xyz' | |C0L2 soit supérieur à 1.
La requête A-32-2 construit là-dessus un ordre SELECT principal, qui renvoie les couples de valeurs trouvés, donnés en figure 14, pour l'exemple considéré. Pour chaque élément de l'ensemble des valeurs de COLl qui bloquent la dépendance (selon la requête imbriquée), on recherche maintenant les valeurs de COL2 correspondantes ainsi que leur fréquence. De même pour la valeur NULL de COLl (NULL est le cas où l'on n'a rien saisi) .
On notera qu'il est possible de passer directement à l'étape 1230, sans faire le comptage préliminaire de l'étape 1210.
Le forçage proprement dit (étape 1250, figure 13A) s'effectue par l'ordre SQL donné en A-32-3, où:
- TAB1 est le nom de la table,
- COLl et COL2 sont deux colonnes de la table dont on cherche à forcer la dépendance dans le sens où COLl déterminera COL2 , - VALEUR2 est la nouvelle valeur attribuée à COL2 ,
- VALEUR1 est la valeur de COLl pour les lignes à modifier,
- VALEUR2__1 , VALEURS2_2 , ... VALEURS2_n sont les valeurs de COL2 pour les lignes à modifier.
Toutefois, en cas de valeurs non saisies en COLl, le forçage s'effectue par l'ordre SQL donné en A-32-4.
Le forçage peut comporter aussi l'ordre SQL donné en A-32-5, où: - TAB1 est le nom de la table,
- COLl et COL2 sont deux colonnes de la table dont on cherche à forcer la dépendance dans le sens où COLl déterminera COL2 ,
- VALEUR1B est la nouvelle valeur attribuée à COLl, - VALEUR1 est la valeur de COLl pour les lignes à modifier,
- VALEUR2_1 , VALEURS2_2 , ... VALEURS2_n sont les valeurs de C0L2 pour les lignes à modifier.
On reprend maintenant la structure monotable, mais selon la figure 7A (avec un contenu un peu différent, pour l'illustration). La relation de dépendance entre le numéro de produit et le nom du produit peut être cassée (erreur de saisie par exemple). Le résultat de la requête permettant de déterminer les couples qui bloquent la dépendance pourrait être (figure 14), exprimé en clair:
"Il y a deux composants pour le produit COMPl-USER COMPUTER et un composant pour le produit COMP1-USER COMPUTER BIS ; un même numéro de produit a été utilisé pour deux produits différents. "
Pour forcer la dépendance, il faut au choix :
. Attribuer un autre numéro de produit à l'un des deux (A- 32-5). Dans ce cas l'analyse des fréquences indique que c'est plus probablement la ligne USER COMPUTER BIS qui n'a pas le bon numéro de produit. . Remplacer "USER COMPUTER BIS" par "USER COMPUTER" (A-32-
3).
. De plus, il faut saisir un numéro de produit pour le produit de numéro de série SRV1 (A-32-4).
Les éventuelles clés candidates pour un groupe de colonnes doivent respecter la contrainte : Chaque clé candidate doit être, vis à vis de toutes les autres colonnes du groupe, soit mère, soit soeur. Pour qu'une colonne devienne clé candidate d'un groupe de colonnes, il est nécessaire de forcer la dépendance avec toutes les pseudo-filles du groupe (en cas de presque-dépendance) .
De préférence, on exprime et mémorise le résultat de l'analyse sous la forme d'un groupe de colonnes, comprenant:
- le sous-groupe des clés candidates, et - les sous-groupes de leurs colonnes-filles, rangés par niveau de parenté (filles des filles, et ainsi de suite), d'une manière arborescente.
Les contrôles de cohérence se font conformément aux principes régissant les structures relationnelles; ils dépendent surtout du résultat de l'analyse des données déjà saisies, niveaux de parenté notamment. Ils garantissent l'utilisateur contre des données inexploitables et lui permettent de s'affranchir de toute connaissance et compréhension de l'accès aux données, et des principes régissant les structures de données (relationnelles par exemple).
Le résultat de l'analyse permet de: - suggérer quelles colonnes vont pouvoir être isolées d'une table,
- déterminer les éventuelles clés candidates d'un groupe de colonnes,
- permettre de bénéficier d'un mode de saisie assisté utilisant les dépendances (éventuellement virtuel).
L'une des mises en oeuvre de l'invention consiste alors à réorganiser physiquement la structure des tables. Elémentairement , cette fonction de réorganisation de la structure consiste à éclater une table en deux tables, qui seront en relation maître-détails.
Bien que l'on puisse procéder autrement, il est aujourd'hui jugé préférable de laisser à l'utilisateur le choix parmi les différentes possibilités éventuellement issues de l'analyse. Ce choix va porter à chaque fois sur une table (TAB1), et sur un groupe de colonnes SI, S2 ...Sn de cette table (qui va former la nouvelle table, tandis qu'on note Ri, R2 ... Rp les colonnes qui vont rester dans la table TAB1 ) , en respectant les contraintes suivantes:
- le groupe de colonnes sélectionné SI, S2 ...Sn ne doit pas inclure la clé primaire de la table (de départ), - les dépendances entre les colonnes sélectionnées permettent de déterminer les clés candidates ; l'utilisateur en sélectionne éventuellement une.
Cette phase s'effectue par exemple à l'aide d'une interface utilisateur à fenêtres comme celle de la figure 15, avec une fenêtre 91 de sélection des tables (ici une seule), puis fenêtre 95 de sélection des colonnes à isoler de la table choisie, puis sélection en 96 d'une clé candidate pour la nouvelle table (en option). On saisit en 92 le nom de cette nouvelle table, qui sera noté TAB2 ci-après. Les phases de sélection-réorganisation sont illustrées sous forme d'étapes à la figure 16, dans le cas d'une interaction avec l'utilisateur, avec l'écran de la figure 15.
A partir du début 2000, l'étape 2010 utilise le méta- dictionnaire pour connaître la liste des tables utilisées par l'application, liste qui est affichée en 2012. L'utilisateur choisit en 2014 la table TAB1 à réorganiser. A partir du méta- dictionnaire, le système fournit en 2020 la liste des colonnes de TAB1. En 2022, ces colonnes sont affichées, à l'exception de la clé primaire de TAB1, et l'usager choisit en 2030 les colonnes Sj à isoler.
Ces choix s'effectuent par une boucle sur les étapes 2032 à 2036. A chaque sélection d'une colonne, on détermine si cette colonne peut servir de clé candidate (2034), en mémorisant cette information.
Ensuite, on passe à la réorganisation proprement dite, qui est un peu différente, suivant que l'utilisateur a, ou n'a pas, choisi une clé candidate. On admet que les formulaires définis au départ attaquaient tous les champs de la table unique dont on est parti.
i) Si, aux étapes 2042 à 2046, l'utilisateur a sélectionné une clé candidate, que l'on suppose être (SI), la réorganisation proprement dite s'effectue par les étapes 2048, 2049 et 2060, conformément aux ordres SQL A-33 ;
La création de la table maître se fait en exécutant l'ordre A-33-1. Cet ordre SQL crée une table nommée TAB2 , avec le résultat d'un ordre SELECT, imbriqué dans l'ordre CREATE .
La modification de la table d'origine TAB1 se fait par l'enchaînement des 3 ordres donnés en A-33-2. On crée une table temporaire TEMPO avec les colonnes non transférées, plus la clé primaire choisie SI (TEMPO est un nom disponible au niveau de la base de données : il n'y a pas d'autre table ou vue ayant ce nom). Ensuite on efface TAB1, et l'on renomme TEMPO en TAB1.
ii) sinon, dans le deuxième cas, où l'utilisateur n'a pas sélectionné de clé candidate (et il n'y a peut-être aucune clé candidate pour le groupe de colonnes sélectionnées ) , la réorganisation proprement dite s'effectue par les étapes 2056, 2058 et 2060, conformément aux ordres A-34. II faut alors introduire ou créer une colonne qui sera la clé primaire dans la table maître.
La création de la table de détails suit l'enchaînement des étapes A-34-1, où CODE_TAB2 est le nom de la clé primaire de la table TAB2. CODE_TAB2 et TEMPO sont des noms qui doivent être disponibles au niveau de la base de données. La première ligne est très semblable à la requête A-33-1, sauf qu'au lieu de créer directement la table TAB2 , on passe par une vue TEMPO. C'est la seconde ligne qui crée TAB2, en ajoutant à la vue TEMPO une colonne calculée CODE_TAB2, dont la valeur est ROWNUM, c'est à dire le rang de ligne dans la table, après quoi TEMPO est effacé. L'aménagement de la table d'origine TAB1 s'effectue comme indiqué en A-34-2. Comme la clé primaire n'existe pour le moment qu'en TAB2 , il faut partir d'une jointure entre TAB1 (ancienne) et TAB2, qui vient d'être créée. D'où le premier ordre CREATE plus élaboré. Par l'enchaînement des 3 ordres donnés en A-34-2, on crée une table temporaire TEMPO avec les colonnes non transférées, plus la clé primaire choisie SI (TEMPO est un nom disponible au niveau de la base de données : il n'y a pas d'autre table ou vue ayant ce nom). Ensuite on efface TABl, et l'on renomme TEMPO en TABl.
Dans les deux cas, le méta-dictionnaire est mis à jour (étape 2065) : a) la table maître nouvelle TAB2 formée des colonnes SI, S2, ... Sn est prise en compte. b) dans le cas de la création d'une clé primaire pour TAB2 , la création de la colonne CODE_TAB2 dans TABl est notée; la création de la colonne CODE_TAB2 dans TAB2 est notée. Les formulaires permettant d'attaquer la table TABl sont enrichis de la colonne CODE_TAB2 , et ne permettent plus d'attaquer (saisie) les colonnes SI, S2, ... Sn. c) dans le cas où la colonne S a été choisie comme clé primaire de la table TAB2 , les formulaires permettant d'attaquer la table TABl ne permettent plus d'attaquer les colonnes SI, S2, ... Sn, sauf S-^ qui demeure attaquée (mais doit respecter les contraintes d'intégrité dues à son nouveau rôle) . d) la clé primaire de TAB2 est référencée comme telle. e) la clé externe de TABl est référencée comme telle. f) les informations du lien maître-détails entre les tables sont insérées. En outre, il peut être nécessaire de mettre à jour les jointures préexistantes concernant des colonnes de la table nouvellement créée.
Le processus qui vient d'être décrit de façon élémentaire permet de garantir que le méta-dictionnaire de données demeure cohérent et synchronisé avec la structure physique des données ; ainsi la génération dynamique des formulaires, requêtes d'interrogation et états est assurée sans intervention de l'utilisateur, et ceux-ci sont adaptés automatiquement à la nouvelle structure, comme on le verra ci-après. L'utilisateur peut alors continuer son travail sur la base de la nouvelle structure.
A côté de cela, il est connu de conférer à un champ d'un formulaire des propriétés comme : "saisie", "modification autorisée", "modification interdite", ou encore "modifiable seulement si", avec une condition qui peut être notamment une restriction relative à certaines contraintes, voire l'action de l'utilisateur sur une touche définie du clavier, ou sur une icône définie avec la souris. Dans un outil de développement, ceci peut se faire au niveau de la partie générateur de formulaire, travaillant par exemple avec un fichier de définition de formulaire.
A partir du moment où, selon l'invention, la table unique a été découpée pour définir une table maître séparée, le formulaire qui attaquait cette table unique va être modifié, ou remplacé par un nouveau formulaire, en respectant la règle suivante: dès lors qu'un formulaire comprend des champs appartenant à une table maître et des champs appartenant à une table de détails, on ne peut modifier que les champs appartenant à la table de détails; et les valeurs prises par la colonne clé externe doivent appartenir à l'ensemble des valeurs prises par la clé primaire de la table maître. Un formulaire séparé est engendré pour attaquer la table maître.
Ainsi, la figure 18 représente le formulaire de saisie des composants utilisés dans la production après la réorganisation des informations relatives aux produits . On note que les champs P_NAME, P_ID et CATEG ne sont plus accessibles directement car ils n'appartiennent pas à la table Composants alors qu'ils appartenaient à la table Composants_et_Produits ; ils sont déterminés par la valeur du champ numéro de série du produit (P_SN) qui est la clé externe de la table Composants qui est liée à la clé primaire de la table Produits.
Pour obtenir ce formulaire à partir du précédent, on fait passer en "non modifiable" tous les champs (colonnes) qui ont été transférés dans la table maître, sauf la clé externe. Concrètement, on peut utiliser un automate qui va:
- recueillir la liste des colonnes du groupe qui a servi à définir la table maître (tirée de la mémoire 550, ou du méta- dictionnaire 510, dans la mise à jour qui en découle);
- retirer de cette liste la clé de lien,
- rechercher chaque nom de colonne de cette liste dans la définition du formulaire, pour assortir le champ concerné de la propriété "non modifiable", et - assortir le champ relatif à la clé de lien d'une propriété "modifiable si et seulement si la nouvelle valeur existe dans la table maître" . La liste des valeurs existantes est donnée par la requête de recherche A-37 dans la table maître TAB2 , dont COLl est la clé primaire (Le mot-clé DISTINCT est optionnel) .
En variante, ou en complément, la figure 18A représente un formulaire simplifié de saisie des composants utilisés. Les champs P_ID et CATEG qui étaient renseignés automatiquement dans le formulaire de la figure 18 ont été supprimés du formulaire. Seul le champ Nom du produit (P_NAME ) a été conservé pour vérifier que le numéro de série du produit saisi est bien celui souhaité. Concrètement, le processus est le même que ci-dessus, sauf qu'au lieu d'assortir les champs de la propriété "non modifiable", on les supprime purement et simplement de la définition du formulaire concerné.
On trouvera en A-23 quelques exemples de requêtes écrites pour la structure réorganisée en deux tables (Composants et Produits).
La figure 19 représente le résultat de la requête d'interrogation après la réorganisation des informations relatives aux Produits. Une rupture (c'est une façon d'illustrer la nouvelle structure) a été prévue automatiquement par le générateur de rapport, en réponse à la présence d'une nouvelle table. A l'instar des formulaires, une telle rupture peut être simplement déterminée par la propriété "Rupture" associée à la colonne considérée, dans la définition du rapport considéré. D'autres illustrations que la rupture sont envisageables .
En pratique, le cycle sélection/réorganisation (ou bien le cycle analyse/sélection/réorganisation) peut être répété autant de fois que nécessaire, tout du moins tant qu'il reste un groupe de colonnes liées à traiter.
Dans l'exemple considéré, on peut procéder ensuite à une nouvelle réorganisation des informations relatives à la catégorie. La figure 17 représente les relations de jointure de la structure avec les trois tables Composants, Produits et Catégories. La figure 19A représente le résultat de la requête d'interrogation sur ces trois tables. Une deuxième rupture a été effectuée automatiquement.
Dans le mode de réalisation décrit ci-dessus, la réorganisation physique des tables a l'effet suivant: - en mode saisie de données (formulaire), on restreint l'accès en saisie (modification, création, suppression) à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement accessibles en lecture, ou inaccessibles ; - pour accéder à ces autres colonnes en écriture, il faut utiliser un formulaire différent, traitant la nouvelle table créée.
Cet autre formulaire peut être rendu accessible à partir du premier, notamment dans les conditions suivantes:
- en cas de saisie d'une clé externe qui n'existe pas dans la table maître,
- lorsque l'utilisateur souhaite modifier l'enregistrement de la table maître qui correspond à la valeur de la clé externe, actionnant par exemple une touche de fonction au clavier.
Toutefois, on pourrait envisager, après réorganisation physique des tables, des solutions différentes pour l'aménagement des formulaires, en particulier si l'on accepte (en s 'affranchissant de la règle précitée) que, dans un formulaire qui comprend des champs appartenant à une table maître et des champs appartenant à une table de détails, on peut modifier des champs appartenant à la table de détails et des champs appartenant à la table maître.
Selon une variante intéressante, au lieu de restructurer physiquement les tables, l'analyse effectuée peut servir seulement à modifier le fonctionnement des formulaires de saisie, en faisant comme si la structure de base de données avait été réorganisée ("réorganisation virtuelle" de la base de données). Comme le ou les groupes de colonnes liées ne sont pas reflétés par une modification de la structure des tables dans le méta-dictionnaire, l'aménagement des formulaires s'effectue alors à partir de la mémoire de dépendances (et de clés) 550.
L'aménagement tient compte des niveaux de parenté entre les colonnes liées de chaque groupe. On part d'une clé de lien, qui est l'une des clés candidates, sélectionnée par l'utilisateur, ou choisie automatiquement.
Dans un outil de développement (partie générateur de formulaire, travaillant par exemple avec un fichier de définition de formulaire), il est également connu de conférer à un champ d'un formulaire une propriété "valeur si vide", assortie d'une expression, ou d'une fonction, dont le résultat sera pris comme valeur du champ s'il est vide (un peu comme une "valeur par défaut"). De même, on connaît aussi la propriété "la valeur a été modifiée par l'usager".
On va alors prendre comme expression une requête recherchant, dans la même table, au moins une ligne préexistante ayant la même valeur pour la clé de lien. Cette requête peut se fonder sur le constructeur de requêtes, ou bien être reconstruite à chaque fois, sur une base préparée à l'avance par morceaux, et mémorisée. Dans ce mode de réorganisation virtuelle, un formulaire peut travailler comme suit:
- Lors de la saisie dans le champ de la clé de lien, les champs vides dépendants de cette clé (soeurs et filles) sont automatiquement renseignés par défaut.
Ainsi dans le formulaire de la figure 8 (structure monotable) la saisie de "US1" comme numéro de série du produit (P_SN) provoque la saisie automatique du champ Référence du produit (P_ID) qui est une colonne soeur et des champs Nom du Produit (P_NAME) et catégorie (CATEG) qui sont des colonnes filles.
Le champ P_ID (COL2) est renseigné automatiquement par le résultat de la requête A-36 cherchant "US1" dans la colonne P_SN (COLl) des lignes déjà existantes. Le mot-clé DISTINCT est optionnel dans la requête A-36, dès lors que toute ligne trouvée contient le résultat recherché pour COL2 (P_ID).
- L'utilisateur peut à loisir écraser les valeurs renseignées par défaut. Il peut ainsi casser la dépendance entre deux colonnes et le fonctionnement du mode réorganisation virtuelle s'interrompt alors pour ce couple de colonnes.
Par exemple dans la structure monotable, il y a une dépendance entre les colonnes Coût (COST) et catégorie (CATEG) : La saisie d'un coût renseigne automatiquement le champ catégorie. Si l'utilisateur change la valeur (automatique) du champ Catégorie, la dépendance entre Coût et Catégorie est cassée : la saisie du champ Coût ne renseignera plus automatiquement le champ Catégorie. La mémoire de dépendances 550 est mise à jour en conséquence, et le fonctionnement du formulaire est modifiée.
C'est en quelque sorte un couplage dynamique entre l'analyse et les formulaires de saisie. Alors que la structure des tables n'est pas modifiée, par contre, demeurent physiquement modifiées les données relatives au fonctionnement du ou des formulaires de saisie, d'une manière qui simule la restructuration des tables . Ceci peut être effectué systématiquement, selon les étapes de la figure 20. A la validation 2200 d'un champ, et si celui-ci a été saisi manuellement (2210), on place la valeur saisie dans une zone mémoire du type liste, ou conteneur, à l'étape 2220. Tant que ce conteneur contient au moins un élément (2230), on extrait en 2240 son premier élément (qui disparaît du conteneur), pour déterminer en 2250 ses colonnes dépendantes (soeurs et filles directes du champ considéré en 2200). Les champs relatifs aux colonnes soeurs sont remplis automatiquement, s'ils sont vides, en 2260. A l'étape 2270, on fait de même pour les colonnes filles directes, que l'on va en outre placer dans le conteneur. (A est fille directe de B s'il n'existe pas de colonne C, autre que A et B, telle que B soit mère de C et C soit mère de A). Et l'on retourne alors en 2230. Le processus se termine en 2290 lorsque le conteneur est vide. Ceci permet de traiter les soeurs du champ visé en 2200, ainsi que de parcourir complètement l'arborescence de ses filles, petites-filles (et leurs soeurs), et ainsi de suite.
En mode saisie de données (formulaire), on pourra astreindre (par défaut ou fermement) les données présentes dans des colonnes liées d'une ligne à rester cohérentes avec des données au moins partiellement identiques déjà existantes dans d'autres lignes, à l'aide d'une requête du même type que ci- dessus. L'astreinte par défaut vise à simplifier la saisie par suggestion des valeurs dépendantes de valeurs déjà saisies. L'astreinte ferme correspond au cas où l'on souhaite verrouiller la dépendance ou l'interdépendance entre les colonnes d'un groupe.
On peut rendre l'analyse dynamique, avec mise à jour en temps réel ou presque, de la manière suivante:
- s'il s'agit d'une ligne créée, on peut se servir de la requête A-32-1, effectuée pour toutes les paires de colonnes, pour déterminer s'il y a quelque chose de changé dans les groupes de colonnes liées. Si oui, on refait l'analyse. En variante, on peut aussi décider directement de refaire toujours l'analyse sur une création de ligne. En pratique, cette analyse pourra être simplifiée, puisqu'il n'y a qu'une ligne nouvelle à comparer à toutes les autres.
- s'il s'agit d'une ligne supprimée, il suffit de rechercher si sa disparition rétablit la dépendance.
- enfin, une modification équivaut à une suppression suivie d'une création.
En pratique, ce qui précède pourra être simplifié, puisqu'il n'y a qu'une ligne nouvelle à comparer à toutes les autres.
Avant la phase d'analyse, il peut être utile de procéder à une étape préalable de pré-normalisation des données de chaque colonne, ou de certaines au moins des colonnes (en particulier de type caractère). En effet l'utilisateur peut avoir saisi deux valeurs différentes ayant des sémantiques identiques (par exemple les villes 'Paris' et 'PARIS' sont sémantiquement identiques bien que différentes du point de vue de leur chaîne de caractères) .
La présente invention modifie en profondeur le cycle habituel de développement: Les dépendances fonctionnelles sont déduites d'après les dépendances entre les données. Cela réduit au minimum la phase d'analyse. Cela permet aussi de faire apparaître des dépendances non envisagées ou non présentes aux origines. La présente invention peut donc aussi être utilisée comme outil de recherche de corrélations entre les données et comme outil de partition des données en domaines.
L'invention propose ainsi un moyen permettant notamment de réorganiser une base de données, au bout d'un certain temps d'exploitation. Ce moyen peut être mis en oeuvre à la seule initiative de l'usager. Il peut être proposé à des intervalles réguliers, dans le temps, ou bien en fonction de la croissance de la base de données. Avant une telle proposition, ou bien de façon générale, la partie analyse peut être mise en oeuvre automatiquement, au moins partiellement, afin de déterminer s'il y a effectivement quelque chose à faire. On pourrait aussi concevoir que cette partie analyse soit tenue à jour en arrière plan. Plus généralement, le moyen d'analyse et ses moyens de mémorisation opèrent alors en permanence, de façon dynamique (plutôt que de temps à autre, à la demande de l'utilisateur, ou sur incitation de l'outil de développement). Ainsi, le poste (ou l'un d'entre eux) peut être muni d'un automate ("trigger"), qui enclenche la mise à jour de l'analyse dès que se produit un événement susceptible d'influencer cette analyse. Pour ce faire, il peut être nécessaire de garder trace en permanence (directement ou indirectement) de toutes les variables traitées durant la phase d'analyse.
On notera que, même si elle indique qu'une réorganisation physique est souhaitable, la phase d'analyse n'est pas forcément suivie d'une telle réorganisation. L'utilisateur peut en effet refuser la réorganisation pour différentes raisons, comme le temps qu'elle prendra, ou le fait qu'il n'est pas convaincu de l'utilité de découper sa table en deux parties, par exemple.
La présente invention s ' applique de façon générale à tout type de donnée, tout type de relation entre les données, tout type de base de données (non nécessairement relationnelles), tout type de langage d'accès aux bases de données, tout type d'architecture de base de données, tout type de système d'exploitation, tout type de support de stockage et de système de stockage.
L'invention étendre donc ses effets à tout système de gestion de fichiers, accessible par un langage de programmation qui permettrait d'écrire l'équivalent détaillé des ordres SQL mentionnés dans la description. La puissance du constructeur de requêtes SQL décrit fait que celui-ci peut engendrer (notamment) toutes les requêtes statistiques voulues. Avec d'autres langages, il peut être nécessaire de créer un module (procédure) pour chacune de ces requêtes statistiques. En pareil cas, la structure de la figure 10 peut se trouver modifiée: l'outil statistique 520 recevrait uniquement des données à traiter, tandis que l'interrogation des tables pour accéder aux colonnes serait faite directement par le module d'analyse 530.
Sur un autre plan, avec l'outil statistique décrit, chaque opération statistique est menée sur toutes les lignes, pour une ou deux colonnes choisies. Une variante des SELECT COUNT des annexes A-31 (éventuellement A-32) consisterait à parcourir les valeurs de la colonne considérée, en faisant une détection de nouvelle valeur : si la valeur a déjà été rencontrée, on passe à la suivante; sinon on référence cette valeur comme étant une des valeurs prises par la colonne, on incrémente un compteur et on passe à la valeur suivante. A la fin, la valeur du compteur donne le nombre d'occurrences distinctes prises par la colonne. Pour COLl \ \ "xyz" ] J COL2 on fait la même chose en considérant la concaténation de COLl, "xyz" et COL2 comme une simple colonne (en considérant comme précédemment que "xyz" est choisi de façon à ne pas créer de confusion possible). En traitant cela dans une procédure, il serait concevable de traiter en même temps plusieurs variables sur une ligne (par exemple, considérer COLl, COL2 et leurs concaténations telles que COLl j |"xyz" ] | COL2 ) , puis de balayer ensuite toutes les lignes en traitant sélectivement ces variables. On peut même traiter d'un seul coup toutes les variables (du genre COLl, COL2 et COLl j ] "xyz" ] j COL2 ) que l'on peut définir à partir de toutes les colonnes de la table.
Selon une autre variante intéressante, on peut utiliser des ensembles ou "listes", rangés, dans chacun desquels on recense, pour chaque valeur d'une donnée d'une colonne, les lignes (désignées par exemple par un numéro) utilisant cette valeur.
On décrira ceci en référence à deux colonnes notées COLl et COL2 (Annexe A-25). Pour chaque valeur de chaque colonne on détermine les lignes utilisant cette valeur. On compare les ensembles obtenus pour les deux colonnes: - s'ils sont rigoureusement identiques, les deux colonnes sont soeurs .
- si chaque ensemble pour une première colonne est égal à la un ensemble pour la seconde colonne, ou bien à la réunion de plusieurs ensembles pour la seconde colonne, alors la première colonne est fille de la seconde.
- s'il n'existe pas de combinaison d'ensembles pour une colonne telle que leur réunion donne un ensemble identique à un des ensembles pour l'autre colonne, les colonnes sont indépendantes.
Dans l'annexe A-25-1, on remarque que
E21 = Eli U E13 et que E22 = El2 donc COL2 est fille de COLl.
Dans l'exemple de l'annexe A-25-2 (une ligne ajoutée), on remarque qu'il n'existe aucune combinaison de Eli, E12 et E13 dont la réunion soit E21; COL2 n'est donc pas fille de COLl.
De même, il n'existe aucune combinaison de E21 et E22 dont la réunion soit E12; donc COLl n'est pas fille de COL2. COLl et
COL2 sont par conséquent indépendantes .
Une opération de comparaison entre des réunions et/ou intersections de listes rangées (d'un format prédéfini) est accessible à l'homme du métier. A partir de là, la réalisation d'un automate effectuant les fonctions ci-dessus pour réaliser l'analyse l'est également. Cet automate est plus efficace que les ordres SELECT précités, au moins pour certaines applications.
De même le stockage sous forme de ligne n'est pas obligatoire. On peut par exemple imaginer, pour chaque colonne, de ne stocker une valeur qu'une seule fois physiquement et de stocker parallèlement la liste des numéros de lignes ("index") où cette valeur apparaît (ou une mémorisation équivalente). La reconstitution d'une ligne se fait alors dynamiquement en retrouvant les différentes valeurs des colonnes de cette ligne par recherche du numéro de ligne dans les listes affectées à chaque colonne.
Soit la table constituée de trois colonnes COLl, C0L2 et C0L3 illustrées en A-26-1. Pour cette table, on peut construire les ensembles d'index (numéro de lignes) pour chaque valeur, comme indiqué en A-26-2. On note maintenant X l'ensemble des numéros de lignes de la valeur "X".
Les relations A-26-3 montrent que COLl détermine COL2. De la même manière, on déduit que COL2 détermine COL3 et que COLl détermine COL3 (ne serait-ce que par transitivité) . Mais COL2 ne détermine pas COLl car
A fi a ≠ a.
Il est souhaité de réorganiser cette table pour aboutir à la structure suivante : TABl (COLl,COL2) TAB2 (COL2 , COL3 ) COL2 va devenir une clé externe de TABl et la clé primaire de TAB2.
Pour réorganiser, on définit une autre série d'ensembles d'index pour la clé primaire de la nouvelle table (COL2) et on met à jour les ensembles d'index des autres colonnes de la nouvelle table. La nouvelle structure est donc celle donnée en A-26-4, où les numéros de ligne dans la table TAB2 sont distingués par "bis".
La jointure se fait en établissant la correspondance entre les deux ensembles d'index pour la colonne charnière (qui est une clé externe d'une table et la clé externe de l'autre table). Par exemple si l'on cherche la valeur de COL3 correspondant à COLl = "C", le cheminement est le suivant: valeur C pour COLl => index 4 de TABl => valeur b pour COL2 => index 2bis de TAB2 => valeur a pour COL3. De même, si l'on cherche à connaître les valeurs de COLl pour C0L3 = a, le cheminement est le suivant : valeur α pour C0L3 = index Ibis et 2bis de TAB2 => valeurs a et b pour C0L2 = index 1, 2, 3 et 4 de TABl→valeurs A, B, C pour C0L3.
On revient maintenant à la table de départ pour montrer le fonctionnement du suivi d'une dépendance lors de la saisie/- modification/suppression d'une ligne. Par ajout d'une ligne, la table devient celle illustrée en A-27-1. Les ensembles d'index d'appartenance pour chaque valeur deviennent ceux données en A-27-2.
Pour vérifier si la relation de dépendance entre COLl et COL2 n'a pas été cassée, il suffit de vérifier si l'ensemble des index correspondant à la valeur de COLl nouvellement saisie est toujours inclus (au sens large) dans l'ensemble des index correspondant à la valeur de COL2 nouvellement saisie: Il faut donc vérifier si {1,2,6} D {5,6} = {1,2,6}. Ce n'est pas le cas, donc la dépendance a été cassée.
Les index des lignes qui bloquent la dépendance sont obtenus facilement en considérant les intersections vides des ensembles d'index qui ne sont ni vides, ni égaux à l'ensemble des index de la colonne presque fille.
Ainsi, l'annexe A-27-3 montre que la dépendance est bloquée par l'ensemble de deux ensembles d'index suivant:
{{1,2}, {6}}.
Lors de la suppression d'une ligne, la dépendance n'est rétablie que si l'ensemble des ensembles des index qui bloque la dépendance ne contient qu'un élément.
Ainsi la suppression de la ligne 1 donne {{2}, {6}}. Il y a plus d'un ensemble, la dépendance n'est donc pas rétablie. Mais la suppression de la ligne 2 donne {{6}}. La dépendance est rétablie. Comme déjà indiqué, la modification d'une ligne peut être traitée par exemple comme l'enchaînement d'une suppression et d'une création dans un ordre quelconque.
Etant articulée sur des moyens matériels qui réalisent des opérations, l'invention pourrait aussi être exprimée sous forme de procédé. Elle aboutit aussi à un outil de développement nettement amélioré.
La version la plus simple de cet outil de développement comporte les moyens permettant de réaliser les fonctions suivantes :
- création d'une application à structure monotable.
- création des formulaires de saisie en fonction de la structure courante.
- génération de requêtes d'interrogation et d'états adaptés à la structure courante.
à quoi s'ajoute, selon l'invention:
- en option, la pré-normalisation des données (analyse).
- l'analyse des redondances et des dépendances des données entre elles (analyse), et
- la réorganisation physique de la structure des données en fonction du résultat de l'analyse ainsi que les formulaires, états et rapports (réorganisation), ou bien la réorganisation "virtuelle" décrite plus haut.
Dans une version plus évoluée, ledit outil va comporter les moyens permettant de réaliser les opérations suivantes, afin d'accueillir (importation) un fichier déjà existant:
- création d'une structure monotable permettant d'accueillir les données d'un fichier au format tabulaire.
- détermination pour le fichier du délimiteur de colonnes: On compte sur chaque ligne le nombre d'occurrences de chaque caractère. Le délimiteur appartient à l'ensemble des caractères ayant la même fréquence, non nulle, sur chaque ligne du fichier. Si l'ensemble est vide, le fichier n'est pas acceptable. Si l'ensemble comporte plus d'un élément, un choix de délimiteur est demandé à l'utilisateur. Une fois le délimiteur déterminé, éventuellement après avoir accepter des signaux de l'utilisateur via l'interface utilisateur, chaque ligne est divisée en un nombre identique de colonnes.
- détermination du format de chaque colonne du fichier:
Pour simplifier, on admet que les données ne peuvent être qu'au format numérique, alphanumérique ou date: Pour qu'une colonne soit au format numérique, il faut que toutes les valeurs de cette colonne soient au format numériques. Pour qu'une colonne soit au format date, il faut que toutes les valeurs de cette colonne soient au format date. Si ce n'est pas le cas, la colonne est au format alphanumérique. Pour le format numérique, on détermine la largeur et la précision de la colonne: La largeur est égale à la somme du nombre maximal de chiffres situé devant le séparateur décimal et du nombre maximal de chiffres situé derrière le séparateur décimal. La précision est égale au nombre maximal de chiffres situé derrière le séparateur décimal. Pour le format alphanumérique, on détermine la largeur de la colonne. La largeur est égale à au nombre de caractères maximal de la colonne.
- création d'une table aux formats déterminés précédemment. L'ordre SQL est de la forme donnée en A-35, où TABl est le nom de la table à créer, COLl ... COLn le nom des colonnes de la table et FORMAT1 ... FORMATn les formats correspondants; FORMATi est d'une des formes suivantes:
. VARCHAR2 (L) pour le format alphanumérique où L est la largeur de la colonne. Certaines bases de données ne supportent pas le format VARCHAR2 de la norme SQL92, on utilise alors le format CHAR.
. NUMBER(L, P) pour le format numérique où L est la largeur de la colonne et P sa précision. . DATE pour le format date.
L'outil peut aussi comporter les moyens permettant de réaliser les opérations suivantes: - la création de formulaires permettant d'accéder aux données contenues dans les tables, tandis que la validation de l'insertion, de la suppression ou de la modification d'une ligne ne pouvant se faire que si les contraintes suivantes sont respectées: . La valeur d'une colonne doit toujours être en adéquation avec son format.
. Une colonne clé primaire ne doit comporter que des valeurs uniques.
. Une colonne clé externe doit avoir un ensemble de valeurs inclus dans l'ensemble des valeurs de la clé primaire correspondante .
Il peut encore comporter les moyens permettant de réaliser la création de requêtes d'interrogation où l'utilisateur précise simplement la liste ordonnée de colonnes simples ou de colonnes calculées, la liste de conditions restrictives, et la liste d'ordres de tri.
Ceci correspond au constructeur de requêtes, dont on notera qu'il présente un intérêt intrinsèque, indépendamment de l'usage qui en est fait ici. Cette remarque s'applique à d'autres des éléments de la présente invention.
En plus, l'outil de développement comporte avantageusement des moyens générateurs d'états, avec :
- un générateur de rapports pour présenter le résultat des requêtes d'interrogation, où l'utilisateur précise simplement la requête d'interrogation, la définition de ruptures, les éventuels calculs de groupe, les formats de présentations des colonnes et des éventuels calculs de groupe, et/ou
- un générateur de graphiques pour présenter le résultat des requêtes d'interrogation où l'utilisateur précise simplement la requête d'interrogation comportant de zéro à plusieurs colonnes de type libellé et une ou plusieurs colonnes de type numérique, le format de la colonne de type libellé (éventuellement ) , le format du graphique .
Dans ce qui précède, on a défini un outil de développement, destiné à travailler avec un système de gestion de bases de données pré-existant. Une variante intéressante, en particulier avec la gestion de listes (annexes A-25 et suivantes, et leur description), consiste en un système intégré qui comprend la gestion des tables et les outils d'analyse et/ou réorganisation décrits.
Dans tous les modes de réalisation décrits ou envisagés, il est possible de remplacer ou de compléter la réorganisation physique des tables par le mode de structure de base de données virtuellement réorganisée, pour la saisie sur formulaires.
Au lieu d'opérer de façon exhaustive, le module d'analyse pourrait s'arrêter en fonction de critères choisis, incluant le fait qu'il a déjà trouvé un groupe de colonnes liées (sans fausses dépendances). On pourrait également enchaîner directement sur la re-structuration, sans sélection par l'usager, dès lors que l'analyse donne un groupe de colonnes liées. La clé de lien pourrait alors être choisie, parmi les clés candidates, comme:
- la colonne la plus courte de ce groupe, ou
- une colonne numérique, ou - on pourrait créer systématiquement une clé nouvelle.
Avec des précautions adéquates, on pourrait également automatiser le forçage de dépendance, au moins dans les cas flagrants, ou bien faire une proposition par défaut corres- pondante à l'usager.
Enfin, bien que l'on préfère actuellement que le traitement et le stockage des données soient proches l'un de l'autre, il est possible d'envisager un stockage déporté, par exemple à la manière des ordinateurs de réseau ("Network Computers").
ANNEXE I
A-ll - Colonnes calculées
Une colonne calculée est une formule constituée :
- de colonnes simples ou de colonnes calculées.
- d'opérateurs et de fonctions mathématiques.
- d'opérateurs ensemblistes (somme, moyenne, comptage par exemple).
Exemples :
PRIX_HT * 1.206 où * est le symbole de la multiplication et PRIX_HT une colonne d'une table correspondant à un prix hors taxe.
PRIX_HT * TAUX_TVA où TAUX_TVA est une colonne d'une table correspondant à un taux de TVA.
Comptage(NO_FACTURE) où comptage () est un opérateur de dénombrement, et NO_FACTURE est la colonne clé primaire d'une table comportant des données relatives à des factures.
Somme (PRIX_UNITAIRE * QUANTITÉJZOMMANDÉE ) où Somme () est un opérateur de sommation, PRIX_UNITAIRE est la colonne de prix unitaire d'une table d'articles et QUANTITÉ_COMMANDÉE , la colonne de quantité commandée d'une table de commandes.
A-12 - Conditions restrictives
Une condition restrictive est composée:
- d'une colonne simple ou d'une colonne calculée.
- d'un opérateur de comparaison.
- éventuellement, d'une valeur ou d'un ensemble de valeurs de comparaison
Exemples :
VILLE = "Paris" La colonne correspondant à une ville doit être égale à la valeur "Paris" .
VILLE parmi ( "Paris" , "Londres" , "Washington" ) où parmi () est un opérateur d'appartenance
PRIX_HT * TAUX_TVA < 1000
Comptage (FACTURE) > 3.
A-13 - Requêtes - principe
De son côté, une requête d'interrogation consiste en :
- une liste ordonnée de colonnes simples ou de colonnes calculées.
- une liste de conditions restrictives.
- une liste d'ordres de tri. La liste des colonnes simples et calculées vérifie les contraintes suivantes : elle ne contient pas de clé externe ni directement (cas de la colonne simple) ni indirectement (dans la définition d'une colonne calculée).
Les conditions restrictives sont liées par les opérateurs booléens 'AND' et 'OR', ainsi qu'éventuellement l'opérateur de négation noté 'NOT' .
Exemples
Les deux exemples ci-après sont fondés sur deux tables "ETUDIANTS" (n lignes) et "UNIVERSITES" (p lignes). Elles sont liées par une jointure sur un identifiant de l'université concernée à chaque fois, CODEUNI- VERSITE, qui est clé externe dans "ETUDIANTS" et clé primaire dans "UNIVERSITES".
A-13-1
SELECT * FROM ETUDIANTS, UNIVERSITES renvoie un produit cartésien des deux tables (n fois p lignes), que l'on peut considérer comme une table nouvelle passant en revue toutes les universités pour chaque étudiant.
A-13-2
SELECT * FROM ETUDIANTS, UNIVERSITES
WHERE ETUDIANTS. CODEUNIVERSITE = UNIVERSITE . CODEUNIVERSITE renvoie n lignes seulement (1 par étudiant). Le moteur SQL a créé une boucle pour arriver à ce résultat: on boucle sur la table ETUDIANTS et pour chaque étudiant on recherche les informations de son université grâce au CODEUNIVERSITE.
ANNEXE I I
A-21 - Méta-Dictionnaire
Le méta-dictionnaire (de l'outil de développement), qui est stocké dans la base de données, contient, au minimum :
- les informations relatives à la structure de données :
. les noms des tables.
. les noms des colonnes de chaque table. le type de chaque colonne (caractère, numérique, date par exemple) .
. pour chaque table, l'indication de la colonne qui est la clé primaire.
. pour chaque table, les colonnes qui sont des clés externes (éventuellement aucune).
- les liens entre les tables avec leur lien de cardinalité (sens du lien maître-détail).
- les définitions des formulaires :
. la référence de la table (ou des tables) à modifier grâce au formulaire.
. les références des colonnes appartenant à d'autres tables liées à la table.
- les définitions des rapports :
. la référence des colonnes incluses dans le rapport.
. les calculs éventuels à effectuer sur ces colonnes.
. les conditions restrictives sur certaines colonnes.
. les formats d'affichage de chaque colonne.
. d'autres paramètres (ordres de tri, ruptures, titre du rapport
- les définitions des graphiques:
. la référence des colonnes incluses dans le graphique.
. les calculs éventuels à effectuer sur ces colonnes.
. les conditions restrictives sur certaines colonnes.
. le type du graphique (histogramme par exemple).
. d'autres paramètres (titre du graphique ...).
A-22 - Requête : Forme canonique
Elle est:
(N° ligne)
SELECT Col!, Cθl2, ... Coln (1)
FROM TABlf TAB2, ... (2)
TAB2lf TAB22, • . T.A.BTEAB2 (3)
WHERE COLa = COLb AND COLc = COLd ... LND COLr = COLs (4)
AND COND_NON_ENS1 AND COND_NON_ENS2 ... COND NON ENSt (5) GROUP BY COL_NON_ENS1, ... COL_NON ENS Su (6) HAVING COND_ENS1, ... COND_ENSv (V) ORDER BY ORD1, ... ORDw. (8)
Cet ordre SELECT de SQL est décomposé sur plusieurs lignes (Ici, sauf exceptions mentionnées ou manifestes, des lignes en indentation font en principe partie du même ordre SQL que la ligne précédente). La première ligne de la requête indique en "Col-^, Col2, ... Coln" la liste de colonnes (simples ou calculées) qui vont être extraites par la requête.
La seconde ligne détermine en TAB-L, TAB2, ... TABp} l'ensemble des tables auxquelles appartiennent les colonnes simples et les composants des colonnes calculées, d'abord pour la liste des colonnes, mais aussi pour la suite de l'ordre SQL, essentiellement les conditions restrictives .
Il faut remarquer qu'il s'agit d'un ensemble : une table n'y figure qu'une seule fois quand bien même plusieurs colonnes de cette table font partie de la liste des colonnes (par exemple).
Viennent en troisième ligne les conditions restrictives dont les colonnes (simples ou calculées) ne comportent pas, directement ou indirectement, de fonctions ensemblistes (somme, moyenne...); ces conditions CONDi sont de la forme:
COL± OPi VALL où COLi est une colonne (simple ou calculée),
OPi est un opérateur du langage SQL (Par exemple = égalité, 1 : différence, < inférieur à, IN parmi, IS NULL n'est pas renseigné).
VALi une valeur, un ensemble de valeurs ou rien selon le choix de l'opérateur OP^
Les conditions sont liées par les opérateurs booléens.
Elles peuvent être encadrées de parenthèses pour lever toute ambiguïté sur la priorité des opérateurs: par exemple COND-]^ ET (COND2 OU COND3 ) .
Grâce à la connaissance de la structure des tables, on fabrique les jointures entre les tables: COLa = COLb où COLa est la clé primaire d'une table et COLb la clé externe correspondante d'une autre table, de telle sorte que l'ensemble des jointures constitue le chemin minimal mais complet passant par toutes les tables de l'ensemble {TAB-L, TAB2, ... TAB }. D'autres tables {TAB2!, TAB22, ... TAB2g} que celles appartenant a {TABX, TAB2 , ... TABp} peuvent être impliquées dans la constitution du chemin. Plusieurs colonnes d'une même table peuvent être impliquée dans les jointures constituant le chemin. Un tel chemin existe toujours.
La quatrième ligne de la requête concerne les conditions restrictives pour les colonnes (simples ou calculées) qui ne contiennent pas, directement ou indirectement, de fonction ensembliste; elle est de la forme :
COND_NON_ENS1 AND COND_NON_ENS2 • .. COND_NON_ENSt
Les troisièmes et quatrièmes lignes (si l'une au moins existe) sont précédées du mot clé 'WHERE' et sont liées, si les deux existent par le mot clé 'AND' .
La cinquième ligne de la requête concerne les colonnes (simples ou calculées) qui ne contiennent pas, directement ou indirectement, de fonction ensembliste; Soient COL_NON_ENS1, ... COL_NON_ENSu ces colonnes. Viennent ensuite en sixième ligne les conditions restrictives sur les colonnes calculées qui contiennent toutes au moins une fonction ensembliste notées COL_ENSi.
Viennent enfin en septième ligne les ordres de tris notés ORD.^. Un ordre de tri comporte une colonne (simple ou calculée) et un sens ASC (ascendant) ou DESC (descendant).
Seules les parties 1 et 2 sont toujours présentes.
La troisième partie est présente dès que deux tables (au moins) sont impliquées dans la liste des colonnes ou des conditions.
Le reste est optionnel.
A-23 - Exemples de Requêtes canoniques
A-23-1:
SELECT P_SN, P_NAME FROM PRODUITS
Donne la liste des colonnes {Numéro de série du Produit, Nom du Produit}. Les colonnes P_SN et P_NAME appartiennent à la même table PRODUITS. Il n'y a donc qu'une seule table impliquée et donc pas de troisième partie (voir A-22, plus haut).
Il n'y a ni condition restrictive sur des colonnes calculées ne comportant aucune fonction ensembliste, ni colonnes calculées comportant des fonctions ensemblistes, ni condition restrictive sur des colonnes calculées comportant des fonctions ensemblistes, et enfin, ni tri.
A-23-2:
SELECT P_SN, P_NAME FROM PRODUITS WHERE P_SN <> 'US1' ORDER BY P_NAME ASC
Liste des colonnes {Numéro de série du Produit, Nom du Produit}.
Condition restrictive: Le Numéro de série du Produit est différent de
'US1'
Ordre de tri: Nom du Produit, ascendant.
A-23-3:
SELECT PRODUITS. P_SN, P_NAME , SUM(COST) FROM PRODUITS, COMPOSANTS WHERE PRODUITS . P_SN = COMPOSANTS . P_SN
AND PRODUITS. P_SN <> 'US1' GROUP BY PRODUITS. P_SN, P_NAME HAVING SUM(COST) > 1000 ORDER BY P NAME ASC Liste des colonnes {Numéro de série du Produit, Nom du Produit, Somme(Coût) }
Conditions restrictives:
Le Numéro de série du Produit est différent de 'US1'
Somme (Coût) > 1000
Ordre de tris: P_NAME ascendant.
Les colonnes Numéro de série du produit et Nom du produit appartiennent à la même table PRODUITS. La colonne Coût appartient à la table COMPOSANTS. Il y a donc deux tables impliquées et la troisième partie de la requête est 'PRODUITS .P_SN = COMPOSANTS . P_SN '.
Lorsqu'il y a ambiguïté sur le nom d'une colonne, SQL demande de lever l'ambiguïté en précisant devant le nom de colonnes qui pourraient porter à confusion le nom de la table auxquelles elles se rapportent (suivi d'un séparatif prévu, en SQL un point).
Il y a une colonne calculée comportant une fonction ensembliste (somme) donc la cinquième partie de la requête est: 'GROUP BY PRODUITS.P_SN, P_NAME '.
Il y a une condition restrictive sur une colonne calculée comportant une fonction ensembliste donc la sixième partie de la requête est: 'HAVING SUM(COST) > 1000'.
A-24 - "Presque-dépendance"
On considère une table à deux colonnes et sept lignes:
COLl COL2
A 1
B 2
A 1
C 2
D 3
D 4
D 4
La ligne D3 ou les lignes D4 bloquent la dépendance, car D ne peut déterminer à la fois 3 et 4, s'il y a dépendance.
A-25 - Dépendance par listes
A-25-1 - Exemple 1
COLl COL2
A a
B b
C a
A a les ensembles sont pour COLl : pour "A", Eli = {ligne 1, ligne 4} pour "B", E12 = {ligne 2}, pour "C", E13 = {ligne 3}. les ensembles sont pour C0L2 : pour "a", E21 = {ligne 1, ligne 3, ligne 4}, pour "b", E22 = {ligne 2}
Ces ensembles peuvent être manipulés par exemple comme des variables tableau (ARRAY) à deux dimensions, la première pour la valeur concernée, et la seconde pour la liste des lignes, une chaîne de caractères sans espace, où les lignes sont désignées par leur simple numéro , séparées par une virgule, et triées par ordre croissant). Si
El et E2 sont les noms de ces tableaux pour COLl et C0L2 , on écrira par exemple:
El[l,l] = "A" et El [1,2] ≈ "1,4"
El [2,1] = "B" et El [2, 2] = "2"
El[3,l] = "C" et El[3,2] = "3"
E2[l,l] = "a" et E2[l,2] = "1,3,4"
E2[2,l] = "b" et E2[2,2] = "2"
Une notation encore plus simple (non informatique) consistera ici à désigner chaque ensemble par la valeur qu'il concerne, soit:
A = "1,4"
B = "2"
C = "3" a = "1,3,4" b = "2"
A-25-2 - Exemple 2
COLl C0L2
A a
B b
C a
A a
C b
Les ensembles sont maintenant pour COLl
Eli = {ligne 1, ligne 4},
E12 = {ligne 2},
E13 = {ligne 3, ligne 5}. les ensembles sont maintenant pour C0L2
E21 = {ligne 1, ligne 3, ligne 4},
E22 = {ligne 2, ligne 5}
A-26
A-26-1
COLl C0L2 C0L3
Ligne 1 A a a
Ligne 3 A a a.
Ligne 3 B a a
Ligne 4 C b a
Ligne 5 D c β A-26-2
A:{1,2} a: :{1,2,3} :{l,2,3,4} B:{3} b: :{4} β:{5} C:{4} c: :{5} D:{5}
A-26-3
A D a ≈ A B H a ≈ B c n a = 0 D n a = 0
A n b = 0 B n b = 0 c n b = C D n b = 0 A n c = 0 ε n c = 0 c n c = 0 D n c = D
A-26-4
TABl TAB2
A {1,2} a {1,2,3} {Ibis} a: {lbis,2bis} B {3} b {4} . {2bis} β:{3bis} C {4} c {5} {3bis}
D {5}
A-27
A-27-1
COLl COL2 COL3
Ligne 1 A a α Ligne 3 A a a Ligne 3 B a a Ligne 4 C b a Ligne 5 D c β Ligne 6 A c β
A-27-2
A {1,2,6} a {1,2,3} :{l,2,3,4} B {3} b {4} β:{5} C {4} c {5,6} D {5}
A-27-3
A n a = {1,2} ≠ A B D a = B c n a = 0 D n a = 0
A n b = 0 B n b = 0 c n b = c D n b = 0
A n c = {6} ≠ A B n c = 0 c n c = 0 D n c = D ANNEXE III
A-31
A-31-1:
SELECT COUNT (*) FROM TABl
A-31-2:
SELECT COUNT (DISTINCT COLl) FROM TABl
A-31-3:
SELECT COUNT (DISTINCT COLl ]] 'xyz' || COL2 ) FROM TABl
A-31-4:
SELECT COUNT (DISTINCT COLl) FROM TABl WHERE COLl LIKE "%xyz"
A-32
A-32-1:
SELECT COUNT (DISTINCT a.COLl i i 'xyz ' i i
I I a.COL2) FROM TABl a WHERE a. COLl IN
(SELECT b.COLl FROM TABl b GROUP BY b.COLl
HAVING COUNT(DISTINCT b.COLl ι i
I I 'xyz ' b.COL2) > 1 ) OR COLl IS NULL'
A-32-2:
SELECT a. COLl, a.COL2, COUNT (a. COLl j j 'xyz' | | a.COL2) FROM TABl a
WHERE a. COLl IN
(SELECT b.COLl FROM TABl b GROUP BY b.COLl
HAVING COUNT (DISTINCT b.COLl | | 'xyz' | | b.COL2) > 1) OR a. COLl IS NULL GROUP BY a. COLl , a.COL2 ORDER BY a. COLl, COUNT ( a. COLl || 'xyz' j| a.COL2) DESC
A-32-3:
UPDATE TABl SET COL2 = 'VALEUR2' WHERE COL2 IN ( 'VALEUR2_1', 'VALEUR2_2', ... 'VALEUR2_n') AND COLl = 'VALEUR1'
A-32-4:
UPDATE TABl SET COLl = 'VALEUR1' WHERE COL2 IN ( 'VALEUR2_1', 'VALEUR2_2', ... 'VALEUR2_n') AND COLl IS NULL
A-32-5:
UPDATE TABl SET COLl = 'VALEUR1A' WHERE COL2 IN ( 'VALEUR2_1', 'VALEUR_2', ... 'VALEUR2_n') AND COLl = 'VALEURl'
A-33
A-33-1:
CREATE TABLE TAB2 AS SELECT DISTINCT SI, S2 , ... Sn FROM TABl
A-33-2:
CREATE TABLE TEMPO AS SELECT Ri, R2 , ... Rp, SI FROM TABl DROP TABLE TABl RENAME TEMPO TO TABl
A-34
A-34-1:
CREATE VIEW TEMPO AS SELECT DISTINCT SI, S2 , ... Sn FROM TABl
CREATE TABLE TAB2
AS SELECT SI, S2, ... Sn, ROWNUM CODE_TAB2 FROM TEMPO
DROP VIEW TEMPO
A-34-2:
CREATE TABLE TEMPO RI , R2 , ... Rp , CODE_TAB2
AS SELECT RI, R2 , ... Rp, CODE_TAB2 FROM TABl, TAB2 WHERE TABl. SI = TAB2.S1
AND TAB1.S2 = TAB2.S2
AND TABl.Sn = TAB2. Sn DROP TABLE TABl RENAME TEMPO TO TABl
A-35
CREATE TABLE TABl (COLl FORMATl COL2 FORMAT2 ... COLn FORMATn )
A-36
SELECT [DISTINCT] COL2 FROM TABl WHERE COLl = "US1"
A-37
SELECT [DISTINCT] COLl FROM TAB2

Claims

Revendications
1. Dispositif de traitement de données, du type comprenant:
- au moins un ordinateur (100,200), muni d'une unité centrale (410) avec un processeur, au moins un périphérique utilisateur, et une mémoire (440), animés par un système d'exploitation (450),
- un système de gestion de bases de données (470), stocké dans cet ordinateur, et propre à coopérer avec le système d'exploitation pour permettre à l'utilisateur la création/saisie et/ou l'usage d'une base de données comprenant au moins une table de données (475), décomposable en lignes et colonnes,
caractérisé en ce qu'il comporte en outre (500):
- un moyen formant méta-dictionnaire autonome (510), pour mémoriser dynamiquement, en référence à une base de données, des informations choisies relatives à la structure de chaque table de la base de données, et aux liens entre tables,
- un moyen d'analyse (520,530,550) capable de déterminer et de mémoriser au moins temporairement une représentation de groupes de colonnes liées entre elles, et
- un module de re-structuration (580,590) capable de coopérer avec le moyen d'analyse et le méta-dictionnaire en vue d'établir pour l'utilisateur, au moins en création/saisie, une présentation ou vue de la base de données qui tienne compte d'au moins un groupe de colonnes ainsi liées.
2. Dispositif selon la revendication 1, caractérisé en ce que les moyens d'analyse comprennent:
- un outil statistique (520), propre à recevoir au moins deux jeux rangés de données qui lui sont présentés, afin de déterminer des liens entre ces jeux de données, par dénombrement d'occurrences distinctes, et - un module pilote d'analyse (530) capable de coopérer avec le méta-dictionnaire pour présenter les données d'au moins deux colonnes différentes de ladite table à cet outil statistique, afin de déterminer leur éventuel lien, avec des moyens (550) pour mémoriser au moins temporairement une représentation de groupes de colonnes liées, ce module d'analyse (530) étant agencé pour réitérer la présentation de paires de colonnes, jusqu'à en trouver au moins une dont les deux colonnes soient liées, ou jusqu'à épuisement des possibilités.
3. Dispositif selon la revendication 2, caractérisé en ce que le module d'analyse (530) réalise systématiquement la présentation de toutes les paires de colonnes différentes possibles pour ladite table.
4. Dispositif selon l'une des revendications 1 à 2, caractérisé en ce que le module d'analyse (530) opère pour toutes les tables de la base de données.
5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que l'outil statistique (520) est apte à définir:
- un moyen (1024) pour compter le nombre de valeurs distinctes (N£,Nj) de chacun des deux jeux de données, - un moyen (1034) pour compter le nombre de valeurs distinctes (P) des couples formés par les données de même rang de l'un et l'autre jeu, et
- un moyen (1042-1049) pour retourner une information à au moins deux états, représentative d'une comparaison entre les comptages Nif Nj et P.
6. Dispositif selon la revendication 5, caractérisé en ce que l'outil statistique (520) est apte à définir aussi un moyen (1012) pour compter le nombre total de valeurs distinctes (N) sur un groupe de colonnes considéré, et en ce que le module d'analyse (530) mémorise (550) les colonnes pour lesquelles N = j_, en tant que clés candidates d'un lien partant de la table en cours .
7. Dispositif selon l'une des revendications 5 et 6, caractérisé en ce que l'outil statistique (520) est agencé pour retourner des états différents (1043,1045,1047,1049), relatifs à des comparaisons portant sur Nj_, Nj et P, et en ce que le module d'analyse (530), quand il présente les données d'une paire de colonnes (COLl et COL2 ) d'une table à l'outil statistique, est agencé pour réagir auxdits états, en mémorisant (550) que
Si N± = P et Nj = P alors COLl et COL2 se déterminent mutuellement (interdépendance).
Si Ni = Nj et N± > P alors COLl détermine COL2.
Si Ni > Nj et N± = P alors COL2 détermine COLl.
Sinon COLl et COL2 n'ont pas de relation de dépendance.
8. Dispositif selon l'une des revendications 5 à 7, caractérisé en ce que l'outil statistique (520) est également apte à fournir un moyen (1210) pour compter le nombre total de couples de valeurs distinctes de deux jeux de données qui bloquent la relation de dépendance entre ces deux jeux, et, le cas échéant, un moyen (1230) pour compter le nombre d'occurrences de chacun de ces couples "bloquants" de valeurs distinctes, et pour les identifier, tandis que le moyen d'analyse (530) est agencé pour proposer ou effectuer (1250) des modifications propres à forcer la dépendance entre les colonnes.
9. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les moyens de re-structuration (580) sont associés à un module d'interface utilisateur (570), permettant à ce dernier de sélectionner une table de départ à traiter, des colonnes à traiter parmi au moins un groupe de colonnes liées, et une clé primaire de nouvelle table à choisir parmi lesdites colonnes interdépendantes et une clé nouvelle créée à cet effet.
10. Dispositif selon la revendication 9, caractérisé en ce que les moyens de re-structuration (580) sont agencés pour exclure la clé primaire de la table de départ desdites sélections.
11. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les moyens de re-structuration (580) sont aptes à construire une nouvelle table avec les données d'un groupe de colonnes liées, ainsi qu'une clé de lien avec la table considérée.
12. Dispositif selon la revendication 11, caractérisé en ce que la clé de lien est une colonne qui demeure dans la table considérée, laquelle est réduite pour ne conserver que cette clé de lien, parmi lesdites colonnes liées.
13. Dispositif selon la revendication 11, caractérisé en ce que la clé de lien est une colonne créée à la fois dans la nouvelle table et dans la table considérée, laquelle est réduite pour ne conserver aucune desdites colonnes liées.
14. Dispositif selon l'une des revendications 9 à 13, caractérisé en ce que les moyens de re-structuration (580) sont agencés pour opérer la construction d'une nouvelle table en réponse au fait qu'un groupe d'au moins deux colonnes liées (COLl,COL2) a été identifié par le module d'analyse.
15. Dispositif selon l'une des revendications précédentes, caractérisé en ce qu'il comprend, en mode saisie de données (formulaire), des moyens actifs pour restreindre par défaut l'accès en modification à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement accessibles en lecture.
16. Dispositif selon l'une des revendications précédentes, caractérisé en ce qu'il comprend, en mode saisie de données (formulaire), des moyens actifs pour astreindre par défaut les données présentes dans des colonnes liées d'une ligne à rester cohérentes avec des données au moins partiellement identiques déjà existantes dans d'autres lignes.
17. Dispositif selon l'un des revendications précédentes, caractérisé en ce que le moyen d'analyse et ses moyens de mémorisation opèrent en permanence, de façon dynamique.
18. Dispositif selon l'une des revendications précédentes, caractérisé en ce qu'il comprend deux ordinateurs, dont un serveur et au moins un "client" reliés en réseau.
19. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le moteur de gestion de bases de données est un moteur relationnel, pilotable en langage SQL.
PCT/FR1998/001015 1997-06-12 1998-05-20 Dispositif d'analyse et d'organisation de donnees WO1998057272A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP98928350A EP0988607A1 (fr) 1997-06-12 1998-05-20 Dispositif d'analyse et d'organisation de donnees
US09/445,751 US6553383B1 (en) 1997-06-12 1998-05-20 Device for data analysis and organization

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9707305A FR2764719B1 (fr) 1997-06-12 1997-06-12 Dispositif d'analyse et d'organisation de donnees
FR97/07305 1997-06-12

Publications (1)

Publication Number Publication Date
WO1998057272A1 true WO1998057272A1 (fr) 1998-12-17

Family

ID=9507905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1998/001015 WO1998057272A1 (fr) 1997-06-12 1998-05-20 Dispositif d'analyse et d'organisation de donnees

Country Status (4)

Country Link
US (1) US6553383B1 (fr)
EP (1) EP0988607A1 (fr)
FR (1) FR2764719B1 (fr)
WO (1) WO1998057272A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2395587A (en) * 2002-11-25 2004-05-26 Sun Microsystems Inc Method for restructuring data which may be in a relational database
DE10208959B4 (de) * 2002-02-28 2006-10-12 Equero Future Net Technologies Ag Verfahren und Vorrichtung zur Erfassung und Auswertung von in einem Rechnernetzwerk abgelegten Informationen

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7174340B1 (en) * 2000-08-17 2007-02-06 Oracle International Corporation Interval-based adjustment data includes computing an adjustment value from the data for a pending adjustment in response to retrieval of an adjusted data value from a database
US7213013B1 (en) * 2001-06-18 2007-05-01 Siebel Systems, Inc. Method, apparatus, and system for remote client search indexing
US7546287B2 (en) * 2001-06-18 2009-06-09 Siebel Systems, Inc. System and method to search a database for records matching user-selected search criteria and to maintain persistency of the matched records
US7464072B1 (en) 2001-06-18 2008-12-09 Siebel Systems, Inc. Method, apparatus, and system for searching based on search visibility rules
US7406455B1 (en) * 2002-01-17 2008-07-29 International Business Machines Corporation Automatic recognition and flagging of anomalous items within sets of automatically classified items
EP1485871A2 (fr) * 2002-02-27 2004-12-15 Michael Rik Frans Brands Solution d'integration de donnees et de gestion de connaissances
JP3861044B2 (ja) * 2002-10-24 2006-12-20 株式会社ターボデータラボラトリー 連鎖したジョインテーブルのツリー構造への変換方法、および、変換プログラム
US7203694B2 (en) * 2002-12-20 2007-04-10 International Business Machines Corporation System and method for multicolumn sorting in a single column
TWI245514B (en) * 2002-12-20 2005-12-11 Hon Hai Prec Ind Co Ltd System and method for displaying relevant events of networking devices
US7373354B2 (en) * 2004-02-26 2008-05-13 Sap Ag Automatic elimination of functional dependencies between columns
GB2420192A (en) * 2004-11-12 2006-05-17 Quadstone Ltd Formulating and refining queries on structured data
US7739290B2 (en) * 2004-12-17 2010-06-15 Sap (Ag) System and method for object persistence
WO2006096939A1 (fr) * 2005-03-18 2006-09-21 Kwok Kay Wong Acces a distance a des donnees heterogenes
US7454449B2 (en) * 2005-12-20 2008-11-18 International Business Machines Corporation Method for reorganizing a set of database partitions
US8346725B2 (en) * 2006-09-15 2013-01-01 Oracle International Corporation Evolution of XML schemas involving partial data copy
US7870163B2 (en) * 2006-09-28 2011-01-11 Oracle International Corporation Implementation of backward compatible XML schema evolution in a relational database system
US9235846B2 (en) 2013-03-13 2016-01-12 Salesforce.Com, Inc. Systems, methods, and apparatuses for populating a table having null values using a predictive query interface
US10311364B2 (en) 2013-11-19 2019-06-04 Salesforce.Com, Inc. Predictive intelligence for service and support
US9483545B2 (en) * 2014-05-30 2016-11-01 International Business Machines Corporation Grouping data in a database
US10331947B2 (en) * 2017-04-26 2019-06-25 International Business Machines Corporation Automatic detection on string and column delimiters in tabular data files

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481703A (en) * 1992-09-30 1996-01-02 Kabushiki Kaisha Toshiba Database restructuring system for detecting functionally dependent relations and converting them into third normal form

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061515A (en) * 1994-07-18 2000-05-09 International Business Machines Corporation System and method for providing a high level language for mapping and accessing objects in data stores
US5627979A (en) * 1994-07-18 1997-05-06 International Business Machines Corporation System and method for providing a graphical user interface for mapping and accessing objects in data stores
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5832496A (en) * 1995-10-12 1998-11-03 Ncr Corporation System and method for performing intelligent analysis of a computer database
US6076088A (en) * 1996-02-09 2000-06-13 Paik; Woojin Information extraction system and method using concept relation concept (CRC) triples
US6026398A (en) * 1997-10-16 2000-02-15 Imarket, Incorporated System and methods for searching and matching databases
US5918232A (en) * 1997-11-26 1999-06-29 Whitelight Systems, Inc. Multidimensional domain modeling method and system
US6076091A (en) * 1997-12-09 2000-06-13 International Business Machines Corporation Method and system for providing a flexible and extensible database interactive on-line electronic catalog
US6138121A (en) * 1998-05-29 2000-10-24 Hewlett-Packard Company Network management event storage and manipulation using relational database technology in a data warehouse
US6243713B1 (en) * 1998-08-24 2001-06-05 Excalibur Technologies Corp. Multimedia document retrieval by application of multimedia queries to a unified index of multimedia data for a plurality of multimedia data types

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481703A (en) * 1992-09-30 1996-01-02 Kabushiki Kaisha Toshiba Database restructuring system for detecting functionally dependent relations and converting them into third normal form

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SOUTOU C ET AL: "Automatic generation of SQL queries to improve knowledge discovery in relational databases", PADD97 PROCEEDINGS OF THE FIRST INTERNATIONAL CONFERENCE ON THE PRACTICAL APPLICATION OF KNOWLEDGE DISCOVERY AND DATA MINING, PROCEEDINGS OF THE FIRST INTERNATIONAL CONFERENCE ON THE PRACTICAL APPLICATION OF KNOWLEDGE DISCOVERY AND DATA MINING PADD 9, ISBN 0-9525554-7-6, 1997, BLACKPOOL, UK, PRACTICAL APPLICATION CO, UK, pages 227 - 242, XP002057126 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10208959B4 (de) * 2002-02-28 2006-10-12 Equero Future Net Technologies Ag Verfahren und Vorrichtung zur Erfassung und Auswertung von in einem Rechnernetzwerk abgelegten Informationen
GB2395587A (en) * 2002-11-25 2004-05-26 Sun Microsystems Inc Method for restructuring data which may be in a relational database

Also Published As

Publication number Publication date
FR2764719A1 (fr) 1998-12-18
FR2764719B1 (fr) 2001-07-27
US6553383B1 (en) 2003-04-22
EP0988607A1 (fr) 2000-03-29

Similar Documents

Publication Publication Date Title
EP0988607A1 (fr) Dispositif d&#39;analyse et d&#39;organisation de donnees
US20040267823A1 (en) Reconcilable and undoable file system
WO1995012855A1 (fr) Systeme de controle d&#39;une base de donnees relationnelle selon une logique d&#39;acces orientee objet limitant le nombre des acces a ladite base de donnees, et procede correspondant
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
WO2008107338A1 (fr) Procedes d&#39;extraction, de combinaison, de synthese et de visualisation de donnees multidimensionnelles provenant de differentes sources
WO2002027566A1 (fr) Moteur de recherche
FR2668271A1 (fr) Interface de modelisation dynamique des performances des systemes informatiques.
EP2188744B1 (fr) Installation de gestion d&#39;une base de données
EP0969391A1 (fr) Procédé pour l&#39;optimisation des accès à une base de données
FR2715486A1 (fr) Procédé de comparaison de fichiers informatiques.
FR2859801A1 (fr) Procede de traitement de donnees sur la base de structures dynamiques d&#39;elements simples
FR2844372A1 (fr) Procede d&#39;organisation d&#39;une base de donnees numeriques sous une forme tracable
EP1774441A1 (fr) Procede de traitement de donnees logiciel associe
Gunderloy et al. SQL Server's Developer's Guide to OLAP with Analysis Services
Watson Beginning C# 2005 databases
EP1700233B1 (fr) Procede d&#39;organisation d&#39;une base de donnees
EP0685802A1 (fr) Système d&#39;information pour la consultation d&#39;informations centralisées en provenance d&#39;applications opérationnelles
FR2917518A1 (fr) Procede de tri d&#39;informations
FR3102594A1 (fr) Ensemble de génération d’application, méthode et programme associés
WO2003012682A1 (fr) Systeme de gestion d&#39;une base de donnees topologique
WO2007088254A1 (fr) Systeme d&#39;information structure, relationnel et incremental
FR3096157A1 (fr) procédé d’indexation multidimensionnelle de contenus textuels
Saltin Interactive visualization of financial data: development of a visual data mining tool
Intelligence et al. Beginning DAX with Power BI
WO2010086523A1 (fr) Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1998928350

Country of ref document: EP

Ref document number: 09445751

Country of ref document: US

NENP Non-entry into the national phase

Ref document number: 1999501699

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 1998928350

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: CA

WWW Wipo information: withdrawn in national office

Ref document number: 1998928350

Country of ref document: EP