WO2011128311A2 - Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant - Google Patents

Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant Download PDF

Info

Publication number
WO2011128311A2
WO2011128311A2 PCT/EP2011/055657 EP2011055657W WO2011128311A2 WO 2011128311 A2 WO2011128311 A2 WO 2011128311A2 EP 2011055657 W EP2011055657 W EP 2011055657W WO 2011128311 A2 WO2011128311 A2 WO 2011128311A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
relationship
definition
recording
creating
Prior art date
Application number
PCT/EP2011/055657
Other languages
English (en)
Inventor
Dominique Pere
Original Assignee
Pod Programming
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
Priority claimed from FR1052893A external-priority patent/FR2963123A1/fr
Application filed by Pod Programming filed Critical Pod Programming
Priority to EP11713797A priority Critical patent/EP2558932A1/fr
Priority to US13/641,428 priority patent/US20130097581A1/en
Publication of WO2011128311A2 publication Critical patent/WO2011128311A2/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented

Definitions

  • the present invention relates to the field of data management.
  • the present invention relates more particularly to the management of data by software applications.
  • a framework comprises a set of structural software components, which define the foundations as well as the outline of the organization of all or part of a software (architecture).
  • a framework In object-oriented programming, a framework more particularly includes a set of parent classes that will be derived and extended by inheritance according to the specific needs of each software that uses the framework.
  • frameworks have become key pieces for the development of software applications.
  • Many frameworks are created daily by groups of developers according to the needs they encounter.
  • a framework corresponds to a particular vision of how a resulting software application must be architected and to a particular vision of which a development of a software application must be conducted.
  • object-relational impedance mismatch due to the fact that the storage layers of the current frameworks mimic the data model, when the DBMS used (Oracle, MySQL for example) does not allow to express the constraints of integrity of the object layer (public / private accessibility of the attributes, notion of interface, inheritance, polymorphism, the granularity of the modifications of data, relations elaborated between data - with 3 ends, with some mandatory and some optional -, navigability of a data relationship, etc.);
  • the invention solves these problems associated with the prior art by providing a data recording method that does not have these disadvantages of the prior art.
  • the invention does not have these disadvantages of the prior art. More particularly, the invention relates to a method of recording data for use in the development and maintenance of software applications. According to the invention, this method comprises on the one hand a phase of definition of the data - and of the relations which connect them - and on the other hand a phase of management of these data separately.
  • each data item is identified and independent in the manner of an entity (table or class) and can therefore be linked to any other data.
  • entity table or class
  • data decapsulation allows the developer to create a business class from each object model data.
  • the invention introduces a new paradigm of description of the data model which, by being shared across the different layers of the application (storage, object model, view, etc.) makes it possible to overcome problems of inadequacies of impedance.
  • the invention results in a destructuring of the recording of the data in order to process them and to make their organization evolve more easily.
  • the invention makes it possible:
  • the invention is counter-current of the prior art since instead of grouping the data so as to make them more accessible more quickly, the invention organizes the data independently.
  • the recording of the data is independent of any database: the recording can be made in a so-called "flat" file, in an XML document or in a conventional relational database.
  • the storage structure of the recorded data does not depend on the structure of the data. For example, the data constituting a contact (surname, first name, address), will not be placed in a single record, in a tabular form, but can be recorded for example in independent tables.
  • the invention relates to a method of recording a plurality of data constituting at least one entity
  • such a method comprises:
  • a step of creating a data definition for each data item of said plurality of data a step of creating a relationship definition of at least one relationship between at least two previously created data definitions;
  • a phase of creating each data and relationship of said plurality of data a step of recording each of said plurality of data so that a recorded data is associated with a corresponding data definition; a recording phase of at least one relation so that a recorded relation corresponds to a relationship definition and is associated with at least one previously recorded data.
  • said phase of creating a relationship definition comprises, for a relationship:
  • a step of creating a first relationship end including a first relationship cardinality and associated with a first data definition.
  • a data definition comprises:
  • a definition of relation comprises:
  • the invention relates to a device for recording a plurality of data constituting at least one entity.
  • a device for recording a plurality of data constituting at least one entity comprises:
  • means for creating each data and relationship of said plurality of data means for recording each of said plurality of data so that a recorded data is associated with a corresponding data definition; means for recording at least one relationship so that a relationship recorded corresponds to a relationship definition and is associated with at least one previously recorded data.
  • the invention relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises code instructions program for the execution of the recording method as previously described.
  • FIG. 1 illustrates the principle of data management according to the invention
  • FIG. 2 illustrates the heart of data management according to the invention
  • FIG. 3 is a diagram of the classes handling the data model in one embodiment of the invention.
  • Figure 4 is a UML diagram of the classes handling the content in one embodiment of the invention.
  • Figure 5 depicts a simplified version of the interfaces declared for managing the abstraction layer to the database in one embodiment of the invention
  • Figure 6 is a physical model of the storage tables resulting from an example for the implementation of the invention.
  • Figure 7 shows examples of models constructed with the modeler of the invention.
  • data represents an atomic element of information (ex-property or field).
  • Data is identified by a code name and a value.
  • relation binds one or more data (a data that can be linked to itself).
  • a datum according to the invention is monovalued and non-decomposable (FIG. 1).
  • Data can be isolated or connected to an indefinite number of data by relationships.
  • a relationship links at least two data to each other.
  • the description of the relation is simplified in the diagram of figure 1, but it could be qualified as a semantic type in the sense UML (reference, aggregation, composition, inheritance), but also by the designer of the application by: a relationship code name, the role played by each end of the relationship.
  • the data set may be composed of different data of the contact code name, each associated with their respective first and last name data, the associations being concretized by relationships.
  • data definition declares data with a code name (for the application) and an optional label (for the user display), specifying its type (string, numeric, boolean, etc.), its maximum size, etc. .
  • - relationship definition declares a possible relationship between at least two definitions of data with a code name, an optional label, the type and cardinality of the relationship (in the UML sense) for each of the data definitions.
  • Figure 2 illustrates in a simple way the strong couplings between the model and the dataset.
  • relationship ends each of the two linked data definitions
  • the storage engine of the invention manipulates only the four previously defined notions (data definition). , definition of relation, data and relation).
  • data definition data definition
  • definition of relation data and relation
  • the structure of this storage engine therefore has no need to evolve to keep pace with changes in the data model.
  • the modification of the data model according to the invention involves a modification of data definition and relationship records, whereas the modification of the data set involves the modification of data and relationship records.
  • Each data is identified and independent in the manner of an entity (table or class) and can be linked to any other data:
  • modeler view and manipulation of the model
  • HTTP server apache
  • Database MySQL, InnoDB Engine.
  • a definition is identified by an id (auto number incremented, allocated and used by the storage module)
  • the namespace is a code string indicating the business domain of the definition. Examples: “crm”, “real estate”, “financial”, “math”. It is forced into lowercase, with no space and must imperatively begin with a letter.
  • the code name unique in a namespace, identifies the definition. Examples: “contact” (for crm), “house” (for real estate), “debit” (for financial), “digit” (for Math).
  • the code name is routinely used in the program to manipulate definitions and instances corresponding to these definitions (data, relationships, and relationship ends). It is forced into lowercase, without space and must begin imerately with a letter. label and comment are only present for self-documentation of the model, in the designer's language.
  • the multilingual display is managed at the "view” layer.
  • a data definition can be compared to an entry in a data dictionary, as long as it does not belong to any entity (or table in a database).
  • the definition of data provides a framework for the content, that is, the values of the data that are admitted into an information system.
  • the multilingual display is managed at the "view" layer.
  • This data represents the turnover of a company.
  • a relationship definition relates two data definitions. It frames the possible relations in an information system.
  • the choice has been made to limit oneself to binary relations in order to impose on the designer the creation of a entity (here a Data Definition) at the confluence of the relation.
  • This is seen as a best practice because a Data Definition is more scalable than a Relationship Definition.
  • the system can handle n-ary relationships with the same ease (including storage).
  • a definition of relation thus has two ends denoted A and B. Each end points on a definition of data.
  • the relationship definition is typed by reusing the UML terms:
  • association simple relationship between two data definitions, without interdependence
  • aggregation non-symmetric association, which expresses a strong coupling and a subordination relation (set / element).
  • A is the aggregate and B is the aggregate.
  • composition strong aggregation where the life cycle of the components are related to the compound, a compound can have only one component.
  • A is the component and B is the compound.
  • inheritance Allows a data B to inherit relations defined at the level of an A data.
  • B specializes A and must have a data definition of the same type as A.
  • A is a Complex type (class)
  • the complex type of B must be a class inheriting from the complex type of A.
  • the code name is especially useful for qualifying the end of the relationship, in the sense of the "role” in UML. This is useful for navigating from one data to another without necessarily naming the relationship.
  • the cardinality indicates the minimum and maximum number of data instances of this end that can be related to a data of the opposite end.
  • code name (defines the role): employee (because from the point of view of the company, the contact is an employee);
  • cardinality min 0 (A company does not necessarily have employees);
  • code name (defines the role): employer (because from the point of view of the employee, the company is his employer);
  • Company Instance of the corresponding DefinitionDefinition class
  • the template must be declared as a script creating the data and relationship definitions. At the end of the script, these definitions are saved in the database. This script is only to be executed when you want to modify the model.
  • the definitions are read from the database and stored in memory.
  • the model is not only used to generate code but is really the heart of the application.
  • a data can simply be expressed by a data definition (which gives the context) and a value (which gives the content).
  • the characteristic of a datum is to contain a value: this one is of variable type, depending on the type of the data definition. When a value is changed, the data is noted as unverified and unrecorded.
  • the deletion of the relationships has the effect of cascading the data in the frame of relation of composition or inheritance (cf deletion of a relation).
  • Company Instance of the corresponding Definition class, of type string
  • a two-data meeting relationship as part of a relationship definition has two ends of relation denoted by A and B. Note that a relation is not necessarily limited to two ends and that it is quite possible to implement relations n -aires.
  • Each relationship end is connected to the corresponding relation and to a data item. Data can only be assigned to an end if its data definition matches that declared in the definition of the corresponding relationship end. This ensures the integrity of relationships.
  • the "given d" property is useful for handling late instantiation, that is, not systematically instantiating data at both ends of a relationship. The corresponding data is thus instantiated only during its first call.
  • the chosen database is MySQL with the InnoDB storage engine for its relational and transactional capabilities.
  • the storage layer can be implemented totally differently by implementing the dedicated interfaces.
  • the core of the framework of the invention only uses interfaces.
  • a simple configuration of the application (storage engine and connection string) makes it possible to switch from one storage layer to another.
  • a single storage layer implemented with PDO objects (“Php Data Objects") makes it possible to abstract the database actually used.
  • This class Represents a connection to a database. This class declares methods for opening and closing a connection. It also makes it possible to execute a query in PodQL (derived from the SQL language adapted to the framework of the invention). All objects accessing the storage use it to get the connection or run PodQL.
  • PodQL derived from the SQL language adapted to the framework of the invention. All objects accessing the storage use it to get the connection or run PodQL.
  • a PodQL query returns an object implementing the IStockageGreResults interface, which can be browsed like a fetch to explore the result.
  • Each line of result expresses the returned values by indexing by name of the relationship end data definition code based on the query (see PodQL section for details on how it works).
  • the IStockageAdapter and inheritance interfaces define the adapters to be implemented in order to read and save the objects of the frame work of the invention: "DefinitionDonnee”, “DefinitionRelation”, “Data” and “Relation”. They allow you to create an adapter on a given connection and to read, write and delete any object from the database.
  • Interfaces handling data and relationships also need to specify which data definition or relationship is involved.
  • This adapter is the most important because it handles all the instantiations (reads) of the data. Reading by id obviously can not suffice. It is at this level that one can specify which data to read according to their value or the value of other directly related data (read method according to value). For the more complex cases, one writes the where clause of a request in PodQL (method to read according to request).
  • Each data table is named with the id of the data definition and has an id and a value.
  • the id is an auto-incremented integer, the primary key of the table.
  • id is an auto-incremented integer, the primary key of the table.
  • the fields given to id and given b id are indexed on two distinct indexes, making it possible to optimize the joins with the relation tables.
  • referential integrity is enabled between each foreign relationship key and each data id, ensuring that both ends of a relationship refer to existing data, with cascading update and deletion.
  • the names of the data tables are prefixed with "data” followed by the id of the corresponding data definition.
  • the data corresponding to the data definitions (noted after DD) contact, surname and first name are respectively stored in data l, data_2 and data_3. Note that data does not have a "value” field because the data definition "contact” specifies an empty type. Conversely, data_2 and data_3 have a "value” field of type varchar (50) corresponding to the type of the data definition.
  • the PodQL detects here that, regarding the given table, only the id is requested. It thus avoids the joining of relations_3 to data l providing no useful additional information.
  • the PodQL can reassemble values and data identifiers by automating joins. Another of his interests is to be able to instantiate "data" corresponding to different data definitions, avoiding to make a query on the database with each traverses of relation.
  • MySQLAdapterDonnee.lire_selon_requete () method which implements IStockageAdonseDonnee.lire according to requeteQ, makes it possible to interpret a PodQL query specifying the data to be returned (SELECT) by managing the instantiation of all the data and relation concerned.
  • the returned columns are therefore not only the values but also the id and data and relations to instantiate from the result of the query.
  • the MySQLAdapterDonnee.lire method according to request () will generate, line for line, the following SQL code
  • Figure 7 shows examples of models built with the modeler.
  • the modeler proposes the following functions:
  • relationship ' is married to'; between two 'person' data definitions; which becomes a given 'marriage', then allowing to qualify by date, place, etc.
  • the invention proposes to be able to interface with an existing application, as long as it is programmed as an object. To do this, we declare a "given" definition corresponding to each class to interface by declaring it as a complex type and giving it the existing class name.
  • Each class to link to the framework of the invention must encapsulate a "given” property and implement the interface IConteneurDonnee which defines the following methods: get donnee: returns the object Data corresponding to data set given: assign to the property "given” a Data
  • get id returns a unique identifier of this instance. This id is stored in bdd in the value field of the corresponding data table
  • save saves the current instance and the encapsulated data delete: delete the current instance and the encapsulated data
  • Instantiate (id) (static method): allows to instantiate an instance of this class from an id, and to instantiate and assign the corresponding data to the encapsulated "data" property.
  • the user can generate with the modeler a series of accessors in this class in order to be able to access the values, data (and objects) directly related to the data, without having to query the relations encapsulated data.
  • This code is generated at the end of the class in a reserved zone, and re-generated if necessary in this same zone.
  • the model used by the interface is the previously described data model:

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant.
1 DOMAINE DE L'INVENTION
La présente invention se rapporte au domaine de la gestion de données.
La présente invention se rapporte plus particulièrement à la gestion de données par des applications logicielles.
Le domaine de l'invention est inclus dans celui de la mise en œuvre de cadres de développement adaptés à la création d'applications logicielles. De tels cadres de développement sont généralement appelés « framework ». En programmation informatique, un framework comprend un ensemble de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel (architecture). En programmation orientée objet un framework comprend plus particulièrement un ensemble de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le framework.
Avec l'augmentation des fonctionnalités offertes par les langages de programmation, les frameworks sont devenus des pièces maîtresses pour le développement des applications logicielles. Parmi les nombreux framework existants, on peut citer 'Qt'™ pour le langage C++, Spring™ pour le langage Java et Symfony™ pour le langage PHP. Cette liste est loin d'être exhaustive. De nombreux frameworks sont créés tous les jours par des groupes de développeurs en fonction des besoins qu'ils rencontrent.
De manière synthétique, on peut affirmer qu'en règle générale un framework correspond à une vision particulière de la manière dont une application logicielle résultante doit être architecturée et à une vision particulière dont un développement d'une application logicielle doit être conduit.
2 SOLUTIONS DE L'ART ANTERIEUR
Les projets de développements d'applications informatiques ont bénéficié à partir des années 70 de la méthode Merise qui fournissait un cadre intégré d'analyse de conception et de réalisation des systèmes d'informations, permettant notamment de formaliser la structure des données. Puis, dans les années 90, la méthode UML a fourni un cadre pour la modélisation des classes pour la conception d'applications orientées obj et. Les frameworks de développement d'applications développés et utilisés aujourd'hui s'appuient sur ces méthodes et suivent donc une ingénierie logicielle orientée modèle (MDE : model-driven engineering). Malgré la profusion actuelle de frameworks MDE, la gestion des données au sens large est une peine pour le développement logiciel. La structure, l'intégrité, la persistance, la saisie, l'affichage, l'import, l'export, l'interfaçage, la synchronisation des données sont autant de problématiques communes à tous les logiciels qui manipulent des données.
L'état de l'art des outils d'aide au développement montre qu'il existe différentes solutions de frameworks MDE qui offrent la possibilité de générer les données. Certains d'entre eux offrent la possibilité de générer, à partir d'un unique fichier de description, une base de données et des classes permettant de manipuler ces données, éventuellement en se basant sur une approche dite « métier », quand le fichier de description est capable de prendre en compte ces aspects. Bien que de telles méthode de génération de code source d'application soient intéressantes, il n'est reste pas moins qu'ils ne permettent pas de gérer les données de manière optimale.
En effet, les structures des données sont trop rigides et déconnectées des couches applicatives hautes (couches manipulant les objets métier). Ceci implique :
l'apparition d'anomalies d'impédance (« object-relational impédance mismatch »), dues au fait que les couches de stockage des frameworks actuels miment le modèle de données, lorsque le SGBD utilisé (Oracle, MySQL par exemple) ne permet pas d'exprimer des contraintes d'intégrité de la couche objet (accessibilité publique/privée des attributs, notion d'interface, d'héritage, de polymorphisme, la granularité des modifications de données, relations élaborées entre des données - à 3 extrémités, avec certains obligatoires et d'autres facultatifs -, navigabilité d'une relation entre données, etc.) ;
la nécessité de « casser » l'application lorsque le modèle de données évolue, par exemple lorsque il est nécessaire de créer une nouvelle donnée ou une nouvelle entité représentative d'une ensemble de données existant ou non ;
la ré-expression du nouveau modèle de données qui ont évoluées dans toutes les couches applicatives.
Ainsi, en définitive, les bénéfices initialement apportés par l'utilisation d'un cadre de développement sont perdus lorsqu'il est nécessaire de modifier le modèle de données et la structure de la base de données correspondante. En d'autres termes, les méthodes actuelles ne tiennent pas compte de l'évolution naturelle des structures de données dans le temps et il est toujours nécessaire de modifier en profondeur les couches applicatives de l'application lorsque le modèle de données évolue. Ceci est principalement du à la manière dont les données sont enregistrées au sein de la structure d'enregistrement des données.
L'invention permet de résoudre ces problèmes associés à l'art antérieur en proposant une méthode d'enregistrement des données qui ne présente pas ces inconvénients de l'art antérieur. 3 RESUME DE L'INVENTION
L'invention ne présente pas ces inconvénients de l'art antérieur. Plus particulièrement, l'invention concerne un procédé d'enregistrement de données destinées à être utilisé dans le cadre du développement et de la maintenance d'applications logicielles. Selon l'invention, ce procédé comprend d'une part une phase de définition des données - et des relations qui les relient - et d'autre part une phase de gestion de ces données de manière séparée. Selon l'invention, chaque donnée est identifiée et indépendante à la manière d'une entité (table ou classe) et peut donc être liée à n'importe quelle autre donnée. Par comparaison avec l'approche classique « entité » où les données sont des valeurs finales, la décapsulation des données permet au développeur de créer une classe métier à partir de chaque donnée du modèle objet. L'invention amène un nouveau paradigme de description du modèle de donnée qui, en étant mutualisé à travers les différentes couches de l'application (stockage, modèle objet, vue, etc.) permet de s'affranchir des problèmes d'inadéquations d'impédance.
En d'autres termes, l'invention aboutit à une déstructuration de l'enregistrement des données afin de les traiter et de faire évoluer leur organisation plus facilement. Ainsi, l'invention permet de :
limiter les cas de mises à jour dites "cassantes" du modèle de données ;
automatiser le stockage, la génération de vues et d'autres fonctionnalité qui reposent sur le modèle de données (statistiques, import-export, etc.)
L'invention se positionne à contre courant des techniques antérieures puisque au lieu de regrouper les données de manière à les rendre plus accessibles plus rapidement, l'invention organise les données de manière indépendante. L'enregistrement des données, en tant que tel, est indépendant d'une quelconque base de données : l'enregistrement peut être réalisé dans un fichier dit « plat », dans un document XML ou dans une base de données relationnelle classique. L'important, du point de vue de l'invention, est que la structure du stockage des données enregistrées ne dépend pas de la structure des données. Par exemple, les données constitutives d'un contact (nom, prénom, adresse), ne seront pas placées dans un unique enregistrement, sous une forme tabulaire, mais peuvent être enregistrées par exemple dans des tables indépendantes.
Plus particulièrement, l'invention concerne un procédé d'enregistrement d'une pluralité de données constituant au moins une entité,
Selon l'invention, un tel procédé comprend :
une phase de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ; une phase de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées ;
une phase de création de chaque donnée et relation de ladite pluralité de données ; une phase d'enregistrement de chaque donnée de ladite pluralité de données de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; une phase d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée.
Selon un mode de réalisation particulier de l'invention, ladite phase de créationd'une définition de relation comprend, pour une relation :
une étape de création d'une première extrémité de relation comprenant une première cardinalité de relation et associée à une première définition de données.
une étape de création d' une deuxième extrémité de relation comprenant chacune une cardinalité de relation associée à une définition de données.
Selon une caractéristique particulière de l'invention, une définition de données comprend :
un nom de code ;
un type.
Selon une caractéristique particulière de l'invention une définition de relation comprend :
un nom de code ;
un type ;
au moins une extrémité.
Selon un autre aspect, l'invention concerne un dispositif d'enregistrement d'une pluralité de données constituant au moins une entité. Selon l'invention, un tel dispositif comprend :
des moyens de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ;
des moyens de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées.
des moyens de création de chaque donnée et relation de ladite pluralité de données ; des moyens d'enregistrement de chaque donnée de ladite pluralité de données de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; des moyens d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée.
Selon un autre aspect, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du Procédé d'enregistrement tel que décrit préalablement.
4 LISTE DES FIGURES
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 illustre le principe de la gestion de données selon l'invention ;
la figure 2 illustre le cœur de la gestion de données selon l'invention ;
- la figure 3 est un diagramme des classes manipulant le modèle de données dans un mode de réalisation de l'invention ;
la figure 4 est un diagramme UML des classes manipulant le contenu dans un mode de réalisation de l'invention ;
la figure 5 décrit une version simplifiée des interfaces déclarées pour gérer la couche d'abstraction à la base de données dans un mode de réalisation de l'invention ;
la figure 6 est un modèle physique des tables de stockage résultant d'un exemple pour la mise en œuvre de l'invention ;
la figure 7 présente des exemples de modèles construits avec le modeleur de l'invention.
5 DESCRIPTION DETAILLEE DE L'INVENTION
5.1 Rappel du principe de l'invention
Le constat dressé par l'état de l'art de la technique antérieure est que les entités (tables de bases de données et classes métier) sont des "boîtes" qui induisent une rigidité quant à l'évolution de l'application. L'idée à la base de l'invention est de casser le principe d'entité pour rendre indépendant chaque élément (champ de données ou attribut de classe métier), de les lier à l'aide de relations pour constituer un modèle de données qui est par ailleurs défini de façon mutualisée pour toutes les couches de l'application.
5.2 Moyens mis en œuyre dans le cadre de l'invention
L'implémentation du principe présenté nécessite de mettre en œuvre plusieurs procédés techniques :
- l'atomisation des données ; l'appropriation du modèle de données par l'application ;
une structuration de stockage indépendante du modèle de données ;
5.2.1 Atomisation des données
Qu'elles soient structurées de façon hiérarchique, tabulaire ou relationnelle, les informations manipulées par tout système peuvent être décrites avec des données et des relations. Dans le cadre de l'invention, ces deux concepts ont été définis de la façon suivante : donnée : représente un élément atomique d'information (ex-propriété ou champ). Une donnée est identifiée par un nom de code et une valeur.
relation : lie une ou plusieurs données (une donnée pouvant être liée à elle- même).
Du fait de leur caractère atomique, une donnée selon l'invention est monovaluée et non décomposable (figure 1).
Une donnée peut être isolée ou être connectée à un nombre indéfini de données par des relations. Une relation lie au moins deux données entre elles. La description de la relation est simplifiée dans le schéma de la figure l, mais elle pourrait être qualifiée d'un type sémantique au sens UML (référence, agrégation, composition, héritage), mais également par le concepteur de l'application par : un nom de code de relation, le rôle joué par chaque extrémité de la relation.
Ainsi le jeu de données peut être composé de différentes données du nom de code contact, chacune associée à leurs données prénom et nom respectives, les associations étant concrétisées par des relations.
5.2.2 Appropriation du modèle de données par l'application
Puisque les données et les relations permettent de construire le jeu de données manipulées par l'application et de le modifier à loisir, il est nécessaire pour une application de gestion de données de lui définir le modèle de données afin que l'application "sache" ce qu'elle manipule.
Le fonctionnement induit par la mise en œuvre de l'invention permet de décrire le modèle de données à l'aide de définitions de données et de définitions de relations. Le modèle est décrit une seule fois dans le cœur de l'application, ce qui évite la réexpression de sa structure et de ses contraintes dans toutes les couches applicatives.
Ainsi, l'inventeur a eu l'idée d'ajouter deux notions correspondant respectivement aux notions précédentes (figure 2) :
définition de donnée : déclare une donnée avec un nom de code (pour l'application) et un libellé facultatif (destiné à l'affichage utilisateur) en spécifiant son type (chaîne, numérique, booléen, etc.), sa taille maximale, etc.
- définition de relation : déclare une relation possible entre au moins deux définitions de données avec un nom de code, un libellé facultatif, le type et la cardinalité de la relation (au sens UML) pour chacune des définitions de donnée.
Les définitions décrivent le modèle de données manipulé par l'application mais elles n'ont pas connaissance des données existantes en cours d'utilisation de l'application. Par contre, chaque donnée connaît :
ses relations aux autres données du jeu de données manipulées ;
sa définition de donnée, et de fil en aiguille les types de relation possibles aux autres données (via les définitions de relations).
La figure 2 illustre de manière simple les couplages forts entre le modèle et le jeu de données. Nous montrerons dans l'implémentation préférée de l'invention que les extrémités de relation (chacune des deux définitions de donnée liées) peuvent être caractérisés plus finement selon :
sa navigabilité (oui, non) : une donnée connaît-elle celles à laquelle elle est liée ? sa visibilité : dans le cas d'une relation de composition (1<->0..1), la donnée liée peut correspondre à un attribut « public », « protégé » ou « privé ».
5.2.3 Structure du stockage indépendant du modèle
A la différence des moteurs de persistance MDE (approche ORM c'est-à-dire utilisation du mappage objet relationnel objet-entité de données), le moteur de stockage de l'invention ne manipule que les quatre notions préalablement définies (définition de donnée, définition de relation, donnée et relation). La structure de ce moteur de stockage n'a donc aucun besoin d'évoluer pour suivre les évolutions du modèle de données. La modification du modèle de données selon l'invention implique une modification d'enregistrements de définitions de donnée et de relation, alors que la modification du jeu de données implique la modification d'enregistrements de données et de relations.
5.3 Avantages de la mise en œuyre de l'invention
Chaque donnée est identifiée et indépendante à la manière d'une entité (table ou classe) et peut donc être liée à n'importe quelle autre donnée :
ceci limite drastiquement les cas de mise à jour "cassantes" du modèle de données ; le sto ckage et les autres fonctionnalités reposant sur le modèle de données sont automatisables (statistiques, import-export, etc.).
Par la suite, on présente un mode de réalisation de l'invention. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en œuvre dans de nombreux autres domaines.
5.4 Description d'un mode de réalisation
On présente dans ce mode de réalisation, une implémentation possible : du cœur de l'architecture ;
du module de stockage du contenu (données et relations) et du modèle (définitions) ; du module d'interfaçage avec des classes métier ;
du module de génération de statistiques ;
du module d'import/export ;
du module de synchronisation ;
du modeleur (vue et manipulation du modèle) ;
de l'explorateur de données (vue et manipulation des données) ;
La plateforme choisie pour cette implémentation est la suivante :
Langage : php (côté serveur), html/javascript (IHM côté client) ;
Serveur HTTP : apache ;
Base de données : MySQL, Moteur InnoDB.
Bien entendu, toute autre implémentation dans un autre langage orienté objet est possible, l'invention pouvant s'appliquer à toute application de gestion de données, qu'elle soit dans un contexte web ou non.
5.5 Le cœur de l'architecture
5.5.1 Le modèle de données
On présente, en relation avec la figure 3, le diagramme des classes manipulant le modèle de données dans ce mode de réalisation de l'invention : les définitions de données et de relations.
5.5.1.1 Définition
La notion de Définition est mutualisée entre une Définition de donnée, une Définition de relation et une définition de l'extrémité de relation :
une définition est identifiée par un id (numéro auto incrémenté, alloué et utilisé par le module de stockage)
l'espace de nom est une chaîne code indiquant le domaine métier de la définition. Exemples : "crm", "real estate", "financial", "math". Il est forcé en minuscule, sans espace et doit commencer impérativement par une lettre.
le nom de code, unique dans un espace de nom, identifie la définition. Exemples : "contact" (pour crm), "house" (pour real estate), "débit" (pour financial), "digit" (pour Math). Le nom de code est systématiquement utilisé dans le programme pour manipuler les définitions et les instances correspondant à ces définitions (données, relations et extrémités de relations). Il est forcé en minuscule, sans espace et doit commencer im érativement par une lettre. libellé et commentaire ne sont présents qu'à des fin d'auto documentation du modèle, dans la langue du concepteur. L'affichage multilingue est géré au niveau de la couche « vue ».
5.5.1.2 Définition de donnée
Une définition de donnée peut être comparée à une entrée dans un dictionnaire de données à ceci prêt qu'elle n'appartient à aucune entité (ou table dans une base de données). La définition de donnée donne un cadre au contenu, c'est-à-dire aux valeurs des données qui sont admises dans un système d'information..
Elle hérite de la notion de Définition et se concrétise avec :
un type de donnée qui peut être simple (chaîne, booléen, etc.) ou Complexe (représenté par une classe dédiée). L'énumération des types simples présentée dans le schéma n'est pas exhaustive (ex: entier long, entier court, double, etc.). Le type vide permet de gérer des données que ne peuvent s'exprimer en une valeur simple (ex : un contact ne peut se décrire une seule donnée, il se concrétisera donc en composant d'autres données comme nom et prénom, dans la mesure où l'on souhaite manipuler ces deux information séparément).
une longueur (pour borner le type chaîne).
un nom de classe (précise la classe à employer pour les types complexes),
une unité (pour les types numériques). Utilisé à des fins d'auto documentation du modèle dans la langue du concepteur. L'affichage multilingue est géré au niveau de la couche « vue ».
5.5.1.2.1 Exemple d'une définition de données
Cette donnée représente le chiffre d'affaire d'une société.
espace de nom : crm ;
nom de code : ca ;
libelle : chiffre d'affaires ;
commentaire : chiffre d'affaires annuel en euros ;
type : entier ;
unité :€.
5.5.1.3 Définition de relation
Une définition de relation met en relation deux Définitions de données. Elle encadre les relations possibles dans un système d'information. Le choix a été fait, dans ce mode de réalisation, de se limiter aux relations binaires pour imposer au concepteur la création d'une entité (ici une Définition de donnée) au confluent de la relation. Ceci est perçu comme une meilleure pratique car une Définition de donnée est plus évolutive qu'une Définition de relation. Cependant le système peut gérer les relations n-aires avec la même facilité (y compris au niveau du stockage).
Une définition de relation possède donc deux extrémités notés A et B. Chaque extrémité pointe sur une définition de donnée. La définition de relation est typée en réutilisant les termes UML :
association : relation simple entre deux définitions de données, sans interdépendance, agrégation : association non symétrique, qui exprime un couplage fort et une relation de subordination (ensemble / élément). Dans ce type de relation, A est l'agrégat et B est l'agrégé.
composition : agrégation forte où le cycle de vie des composants sont liés au composé, un composé ne peut avoir qu'un seul composant. Dans ce type de relation, A est le composant et B est le composé.
héritage : Permet à une donnée B d'hériter des relations définies au niveau d'une donnée A. Dans ce type de relation, B spécialise A et doit avoir une définition de données du même type que A. Dans le cas ou A est un type Complexe (classe), le type complexe de B doit être une classe héritant du type complexe de A.
On note que contrairement à la subjectivité purement sémantique qu'induit UML au niveau des relations de types agrégation et composition, l'invention les emploie dans ses différents modules pour en déduire les comportements adéquats au niveau du stockage, de la persistance, de la génération des objets métier, des IHM, etc.
Les extrémités de relation achèvent la définition de la relation en donnant :
la notion de navigabilité, qui répond à la question : "Est-ce que A connaît B" et vice- versa. Par défaut, une relation est navigable dans les deux sens. Exemple : si "navigable" vaut "false" du côté A, alors une donnée correspondant à la définition de donnée côté B ne peut pas parcourir les relations menant aux données correspondant à la définition de donnée côté A. Autrement dit : toute donnée du côté B ne peut pas connaître les données du côté A (les B ignoreront simplement les relations existantes), la visibilité de données correspondant à l'extrémité : privé, protégé, public. Ceci est utile dans les modules de génération des objets métier (visibilité des accesseurs), d'IHM (données qui peuvent être affichées), de statistiques, etc.
le nom de code est ici spécialement utile pour qualifier l'extrémité de la relation, au sens du "rôle" en UML. Ceci est utile pour naviguer d'une donnée à d'autres sans nécessairement nommer la relation. la cardinalité indique le nombre minimum et maximum d'instances de données de cette extrémité qui peuvent être mise en relation avec une donnée de l'extrémité opposée.
5.5.1.3.1 Exemple de définition de relation
Soient deux définitions de données "Société" et "Contact", on déclare la définition de relation suivante :
espace de nom : crm ;
nom de code : contact travaille societe ;
libellé : travaille ;
commentaire : relation indiquant les contacts qui travaillent dans une société ;
type : association ;
Définition de l'extrémité A
espace de nom : crm ;
nom de code (définit le rôle) : employé (car du point du vue de la société, le contact est un employé) ;
libellé : employé ;
commentaire : indique les contacts employés par cette société (facultatif) ;
extrémité : 'A' ;
définition de donnée : Contact (Instance de la classe DefinitionDefinition correspondante) ;
navigable : oui (une société peut en effet accéder à ses employés) ;
visibilité : public ;
cardinalité min : 0 (Une société n'a pas nécessairement d'employés) ;
cardinalité max : null (pas de limite maximum sur le nombre d'employés) ;
Définition de l'extrémité B
espace de nom : crm ;
nom de code (définit le rôle) : employeur (car du point du vue du salarié, la société est son employeur) ;
libellé : employeur ;
commentaire : indique la société qui emploie ce contact (facultatif) ;
extrémité : 'B' ;
définition de donnée : Société (Instance de la classe DefinitionDefinition correspondante) ;
navigable : oui (un contact peut en effet accéder à la société dans laquelle il travaille) ; visibilité : public ; cardinalité min : 0 (si un contact ne travaille pas systématiquement dans une société) ; cardinalité max : 1 (si un contact ne peut travailler que dans une société au maximium) ;
5.5.1.4 Déclaration du modèle
Dans ce mode de réalisation de l'invention, le modèle doit être déclaré sous la forme d'un script créant les définitions de données et de relations. A l'issu du script, ces définitions sont enregistrées en base de données. Ce script n'est à exécuter que lorsque l'on souhaite modifier le modèle.
Il est toutefois possible de créer un schéma XML pour la déclaration du modèle, dérivé du XMI pour être adapté à au paradigme de l'invention.
En fin de compte, l'outil le plus facile pour déclarer et manipuler le modèle avec une interface graphique sera le modeleur.
Quoiqu'il en soit, lors de l'initialisation du programme, les définitions sont lues en base de données et gardées en mémoire. Contrairement aux approches MDA, le modèle n'est donc pas utilisé uniquement pour générer du code mais il constitue véritablement le cœur de l'application.
5.5.2 Les données (contenu)
On présente, en relation avec la figure 4, le diagramme UML des classes manipulant le contenu : Données et relations. On y place pour rappel les objets de définition auxquels sont connecté les objets accueillant le contenu. 5.5.2.1 Donnée
Une donnée peut simplement s'exprimer par une définition de donnée (qui donne le contexte) et une valeur (qui donne le contenu).
5.5.2.1.1 id
C'est un numéro auto incrémenté, alloué et utilisé par le module de stockage. Chaque donnée possède un numéro unique pour sa définition de donnée. Ceci lui fournit son indépendance et sa capacité d'évolution, lui permettant d'être liée à n'importe quelle autre donnée par l'entremise des relations. Cet attribut est vide si la donnée n'a pas encore été enregistrée.
5.5.2.1.2 définition de donnée
Une donnée est connectée à une et une seule Définition. Cette dernière lui confère son contexte d'existence et de validation. 5.5.2.1.3 valeur
Le propre d'une donnée est de contenir une valeur : celle-ci est de type variable, dépendant du type de la définition de donnée. Lorsqu'une valeur est modifiée, la donnée est notée comme non validée et non enregistrée.
5.5.2.1.4 valider()
Utilise la définition de donnée pour vérifier si la valeur correspond au type défini. Demande à chaque relation de se valider puis vérifie que les cardinalités déclarée dans les définitions des extrémités de relations sont respectées (min et max). La donnée est dès lors notée comme validée (pour éviter sa revalidation lors d'un appel ultérieur)
Exemple : Soient A et B respectivement deux définitions de donnée "Contact" et "Nom" ayant en commun une définition de relation avec, du côté B, la cardinalité "min=l" et "max=l". Dans ces conditions, une donnée de la définition "Contact" qui n'est pas reliée à exactement une donnée de la définition "Nom" sera déclarée non valide.
5.5.2.1.5 enregistrer()
Valide la donnée et, en cas de succès, délègue à la couche de stockage son enregistrement. Si la valeur est vide alors que sa définition précise un type non vide, la donnée est supprimée. Ceci garantit de ne gérer que des données consistantes, c'est-à-dire nanties d'une valeur. La donnée est alors notée comme enregistrée pour éviter son réenregistrement en cas d'appel ultérieur.
5.5.2.1.6 supprimer ()
Supprime les relations liées à la donnée puis supprime la donnée. La suppression des relations a pour effet de supprimer en cascade les données dans le cadre de relation de composition ou d'héritage (cf suppression d'une relation).
5.5.2.1.7 Exemple de donnée
Soit "Pod programming" une société. Elle est déclarée comme suit :
définition de donnée : Société (Instance de la classe Définition correspondante, de type chaîne)
id = 1 (cette société a été la première enregistrée dans le système d'information) valeur = "Pod programming" 5.5.2.2 Relation
Une relation réunion deux données dans le cadre d'une définition de relation. A l'instar de cette dernière, elle possède deux extrémités de relation notés A et B. On note qu'une relation n'est pas forcément limitée à deux extrémités et qu'il est tout à fait possible de mettre en œuvre des relations n-aires.
5.5.2.2.1 valider()
Appelle la méthode valider() sur chacun des extrémités puis marque la relation comme validée.
5.5.2.2.2 enregistrer()
Appelle la méthode validerQ puis, en cas de succès, enregistre la relation. Si une donnée à une extrémité n'a pas d'id, son enregistrement est demandé au préalable. Si cette relation est de type composition, appel de enregistrer() sur la donnée côté B. La relation est alors notée comme enregistrée pour éviter son ré- enregistrement en cas d'appel ultérieur.
5.5.2.2.3 supprimer()
Supprime la relation. Si cette relation est une relation de composition, supprime en cascade la donnée du côté B. Si cette relation est de type héritage, supprime les données aux extrémités de la relation.
5.5.2.2.4 ExtremiteRelation (extremite a et extremite b)
Chaque extrémité de relation est connectée à la relation correspondante et à une donnée. Une donnée ne peut être affectée à une extrémité que si sa définition de donnée correspond à celle déclarée dans la définition de l'extrémité de relation correspondante. Ceci garantit l'intégrité des relations.
Lorsqu'une extrémité de relation est modifiée, la relation correspondante est notée comme non validée et non enregistrée.
La propriété « donnée d » est utile pour gérer l'instanciation tardive, c'est-à-dire de ne pas systématiquement instancier les données aux deux extrémités d'une relation. La donnée correspondante n'est donc instanciée que lors de son premier appel.
5.5.2.2.5 Exemple de relation
Soient deux données "Pod programming" et "Dominique Péré" correspondant respectivement aux définitions de données "Société" et "Contact", on déclare la relation suivante : définition de relation : travaille (instance de la classe « DefinitionRelation » correspondante, définie ci-avant)
extrémité A :
o donnée : Instance de la classe « Donnée » correspondant à "Dominique Péré", d'id 1 , avec la définition de donnée "Contact" o donnee id : 1
extrémité B :
o donnée : Instance de la classe Donnée correspondant à "Pod programming", d'id 1, avec la définition de donnée "Société" o donnee id : 1
5.6 Module de stockage
5.6.1 Stockage
La base de données choisie est MySQL avec le moteur de stockage InnoDB pour ses capacités relationnelles et transactionnelles. On distingue le stockage des données et relations (contenu) du stockage des définitions (modèle).
Il est à noter que la couche de stockage peut être implémentée totalement différemment en implémentant les interfaces dédiées. Le cœur du framework de l'invention ne fait appel qu'à des interfaces. Un simple paramétrage de l'application (moteur de stockage et chaîne de connexion) permet de passer d'une couche de stockage à une autre. D'autre part, une unique couche de stockage implémentée avec les objets PDO (« Php Data Objects ») permet de faire abstraction de la base de données effectivement employée.
5.6.1.1 interfaces déclarées
Une version simplifiée des interfaces déclarées pour gérer la couche d'abstraction à la base de données est ci-après présentée en relation avec la figure 5. 5.6.1.1.1 IStockageConnexion
Représente une connexion à une base de donnée. Cette classe déclare les méthodes permettant d'ouvrir et fermer une connexion. Elle permet également d'exécuter une requête en PodQL (dérivé du langage SQL adapté au framework de l'invention). Tous les objets accédant au stockage l'utilisent pour obtenir la connexion ou exécuter du PodQL.
Une requête PodQL retourne un objet implémentant l'interface IStockageJeuResultats, que l'on peut parcourir à la manière d'un « fetch » pour explorer le résultat. Chaque ligne de résultat (IStorageLigneResultat) exprime les valeurs retournées en indexant par nom de code de définition de donnée de d'extrémité de relation en fonction de la requête posée (cf. section PodQL pour plus de détails sur son fonctionnement).
5.6.1.1.2 IStockageAdaptateur
Les interfaces IStockageAdaptateur et héritantes définissent les adaptateurs à implémenter pour pouvoir lire et enregistrer les objets du frame work de l'invention : « DefinitionDonnee », « DefinitionRelation », « Donnée » et « Relation ». Elles permettent de créer un adaptateur sur une connexion donnée et de lire, écrire et supprimer n'importe quel objet depuis la base de données.
Les interfaces manipulant les données et relations nécessitent en sus de préciser quelle définition de donnée ou de relation est concernée.
5.6.1.1.3 IStockageAdaptateurDonnee
Cet adaptateur est le plus important car il gère toutes les instanciations (lectures) des données. La lecture par id ne peut évidemment suffire. C'est à ce niveau que l'on peut préciser quelles données lire en fonction de leur valeur ou de la valeur d'autres données directement liées (méthode lire selon valeur). Pour les cas plus complexes, on écrit la clause where d'une requête en PodQL (méthode lire selon requête).
5.6.1.2 Structure de la BDD pour MySQL
Pour l'implémentation en MySQL/InnoDB dans ce mode de réalisation, on propose une structure de BDD avec une table par définition de donnée et une table par définition de relation, chacune stockant les valeur des données et relations.
Chaque table de données et nommée avec l'id de la définition de donnée et nantie d'un id et d'une valeur. L'id est un entier auto incrémenté, clé primaire de la table.
Chaque table de relations et nommée avec l'id de la définition de relation et nantie d'un id, de l'id de la donnée de l'extrémité A et de l'id de la donnée de l'extrémité B. L'id est un entier auto-incrémenté, clé primaire de la table. Les champs donnee a id et donnee b id sont indexés sur deux index distincts, permettant d'optimiser les jointures avec les tables de relation. Enfin, une l'intégrité référentielle est activée entre chaque clef étrangère de relation et chaque id de donnée, garantissant que les deux extrémités d'une relation font référence à des données existantes, avec mise à jour et suppression en cascade.
A titre d'exemple, soient les définitions de données suivantes :
1. contact : id="l", nom de code- 'contact", type="vide" 2. nom : id="2", nom_de_code="nom", type- 'chaîne", longueur="50"
3. prénom : id="3", nom_de_code="prenom", type="chaine", longueur="50"
4. société: id="4", nom de code- 'societe", type="chaine", longueur="50"
Soient les définitions de relations suivantes :
5. Nom du contact : id="l", nom de code- 'contact nom", type="composition", extremite_a="l", extremite_b="2"
6. Prénom du contact : id="2", nom_de_code="contact_prenom", type="composition", extremite a- Ί", extremite_b="3"
7. Société du contact : id="4", nom de code- 'contact societe", type="association", extremite_a="l", extremite_b="4", role extremite a = "employé", role_extremite_b="societe"
Voici le modèle physique des tables de stockage qui en découlent est présenté en relation avec la figure 6.
Les noms des tables de données sont préfixés de "données " suivi de l'id de la définition de donnée correspondante. Les données correspondant aux définitions de données (notées après DD) contact, nom et prénom sont donc respectivement stockées dans donnees l, donnees_2 et donnees_3. On remarque que donnees l ne possède pas de champ "valeur", car la définition de donnée "contact" précise un type vide. À l'inverse, donnees_2 et donnees_3 ont un champ "valeur" de type varchar(50) correspondant au type de la définition de données.
À l'identique, les noms des tables de données sont préfixés de "relations " suivi de l'id de la définition de relation correspondante. La table « relations 1 » relie un contact à son nom et « relations_2 » relie un contact à son prénom.
Il est à noter que ces tables sont créées automatiquement, si nécessaire, lors de l'initialisation de l'application, au regard des définitions de données existantes.
5.6.2 PODQL
Suite à l'exposé du de la structure physique de la BDD, on voit que les requêtes sur cette structure de données s'avère particulièrement laborieuse à exploiter en SQL, du fait de l'explosion des données, du nommage des tables et du nombre important de jointures à effectuer (parcourt des relations). 5.6.2.1 Jointures automatisées
On décrit donc un langage de requête dérivé du SQL, permettant de faire abstraction de la structure physique de la base de données. L'intérêt principal du PodQL est d'automatiser les jointures. Les données valeurs à atteindre sont exprimées à partir du nom de code de la donnée ou du nom de rôle par rapport une donnée centrale. Grâce à cette traduction de requête et au fait que le framework de l'invention "connaisse" le modèle de données, on économise purement et simplement l'expression de la clause "FROM" ainsi que les jointures traditionnelles.
On introduit la notion la notion d'opérateur de parcourt de relation, noté "→" (un tiret suivi du signe supérieur, représentant une flèche).
On présente deux explications par l'exemple d'utilisation du PodQL tel qu'il est interprété par la méthode « MySQLConnexion.executer_requete_pod() » qui implémente « IStockageConnexion.executer_requete_pod() ».
5.6.2.1.1 Exemple de select avec valeurs
En reprenant les définitions de données et de relations définies lors de l'exposé de la Structure de la BDD pour MySQL, admettons que l'on souhaite exécuter une requête qui donne les contacts de la société 'Pod programming'. La requête en PodQL sera la suivante :
SELECT contact->nom, contact->prenom WHERE contact->employeur = 'Pod programming' ORDER BY contact->nom
Ici, "contact" est vu comme la donnée centrale, les autres données sont exprimées comme relation à partir de cette dernière.
La requête précédente se traduit en SQL, sur notre implémentation physique décrite plus haut, comme suit :
SELECT donnees_2. valeur AS ' contact->nom ' , donnees_3. valeur AS ' contact->prenom '
FROM donnees_l, donnees_2, donnees_3, donnees_4, relations_l, relations 2, relations 3
WHERE donnees_l . id = relations_l . donnee_a_id AND
relations 1. donnée b id = données 2.id
AND donnees_l.id = relations_2. donnee_a_id AND
relations_2. donnee_b_id = donnees_3.id
AND données l.id = relations 3. donnée a id AND
relations_3. donnee_b_id = donnees_4.id
AND données 4. aleur = 'Pod programming'
ORDER BY donnees_2.valeur
Remarque : On ne se soucie pas de l'ordre des éléments dans la clause « where » car MySQL planifie automatiquement la requête et détermine l'ordre d'exécution optimal. 5.6.2.1.2 Exemple de select avec id et regroupement
Voici un autre exemple qui permet de comptabiliser le nombre d'employés par société :
SELECT société, count ( societe->employé . id) AS nb_employes
GROUP BY société
On constate ici l'utilisation de l'opérateur "." (dans societe→employé.id), indiquant un champ d'une table comme en SQL traditionnel. Par défaut, c'est la valeur qui est retournée mais ici la valeur d'une donnée contact n'existe pas. L'application du ".id" permet de préciser que l'on souhaite obtenir l'id dans cette colonne.
La requête précédente se traduit en SQL, sur notre implémentation physique décrite plus haut, comme suit :
SELECT donnees_4.valeur AS 'société',
count ( relations_3. data_a_id) AS nb_employes
FROM données 4, relations 3
HERE donnees_4. id = relations_3. data_b_id
GROUP BY donnees_4.valeur
Le PodQL détecte ici que, concernant la table donnee l, seul l'id est demandé. Il évite donc la jointure de relations_3 vers donnees l n'apportant aucune information supplémentaire utile.
5.6.2.2 Instanciation en série
On a vu que le PodQL pouvait remonter des valeurs et des identifiants de donnée en automatisant les jointures. Une autre de ses intérêts est de pouvoir instancier "en chaîne" des données correspondant à différentes définitions de données, évitant d'effectuer une requête sur la base de données à chaque parcourt de relation.
Par défaut, on utilise les types de relations définis précédemment. A l'instanciation de toute donnée ayant des relations de type agrégation ou composition dont elle est l'agrégat, entraîne l'instanciation "en chaîne" des données.
Cependant ce comportement par défaut peut amener à lire trop de données ou pas assez selon les contextes d'utilisation. En conséquence, la méthode MySQLAdaptateurDonnee.lire_selon_requete(), qui implémente IStockageAdaptateurDonnee.lire selon requeteQ, permet d'interpréter une requête PodQL précisant les données à retourner (SELECT) en gérant l'instanciation de toutes les données et relation concernées. Le colonnes retournées ne sont donc non plus seulement les valeurs mais également les id et données et des relations à instancier à partir résultat de la requête.
Reprenons l'exemple de la recherche des employés de la société "pod programming.". SELECT contact->nom, contact->prenom
WHERE contact->employeur = ' Pod programming '
ORDER BY contact->nom
La méthode MySQLAdaptateurDonnee.lire selon requete() va générer, ligne pour ligne, le code SQL suivant
SELECT données l.id AS données 1 id, relations l.id AS
relations_l_id, donnees_2.id AS donnees_2_id, donnees_2.valeur AS données 2 valeur,
relations_2. id AS relations_2_id, donnees_3. id AS
données 3 id, données 3. valeur AS données 3 valeur
FROM donnees_l, donnees_2, donnees_3, donnees_4, relations_l, relations 2, relations 3
WHERE donnees_l.id = relations_l . donnee_a_id AND
relations_l . donnee_b_id = donnees_2.id
AND données l.id = relations 2. donnée a id AND
relations_2. donnee_b_id = donnees_3.id
AND données l.id = relations 3. donnée a id AND
relations_3. donnee_b_id = donnees_4.id
AND données 4. valeur = 'Pod programming'
ORDER BY donnees_2.valeur
Seule la clause SELECT a été modifiée par rapport à l'exemple précédent. Son interprétation par « MySQLAdaptateurDonnee » permet d'instancier pour chaque contact correspondant :
les données de définition 'contact'
les relations de définition 'contact nom' liées au contact
les données de définition 'nom' liées au relations 'contact nom'
les relations de définition 'contact_prenom' liées au contact
les données de définition 'prénom' liées au relations 'contact_prenom'
Grâce à ce procédé, une seule requête a été posée à la base de données, permettant d'instancier l'ensemble des données et relations concernées.
5.6.2.2.1 opérateur
Pour simplifier encore le processus de création des données en série, on introduit l'opérateur "*" dans la clause SELECT, déjà présent en SQL, pour le traduire en son équivalent en PodQL de la manière suivante : "A— est équivalent toutes les données B liée à une donnée A par une relation de composition, dont A est le composé. Ainsi, étant donné que "contact nom" et "contact_prenom" sont des relations de compositions les deux requêtes PodQL suivantes sont similaires et produiront le même code SQL :
SELECT contact->*;
SELECT contact->nom, contact->prenom;
5.7 Modeleur
Basée sur UML, la modélisation avec le framework selon l'invention est très similaire aux diagrammes de classes à quelques différences près. Les différences sont les suivantes :
1. On ne représente pas des classes mais des définitions de données, représentée par des bulles.
2. les définitions de données contiennent une propriété unique : la valeur (à typer)
3. les définitions de données ne contiennent pas de méthodes (ou opérations)
En revanche les relations UML sont en tout point similaires aux définitions de relations du framework de l'invention.
Comme la notion de propriété n'existe plus, on doit tout modéliser en définitions de données et de relations, comme si on modélisait un modèle objet en s'astreignant à ce que chaque propriété soit un objet métier.
La figure 7 présente des exemples de modèles construits avec le modeleur.
Un fois le modèle validé, le modeleur propose les fonctions suivantes :
la génération du fichier XMI représentant le modèle
la génération des instructions PodQL nécessaires à du dé-doublonnage (cas du passage d'une cardinalité de relation de 0..1 à 0..N)
la génération des instructions PodQL nécessaires à faire migrer une relation vers une donnée. Ex : relation 'est marie a'; entre deux définitions de données 'personne'; qui devient une donnée 'mariage', permettant ensuite de le qualifier par la date, le lieu, etc.
5.8 Module d'interfaçage avec des classes métier
L'invention propose de pouvoir s'interfacer avec une application existante, du moment que celle-ci est programmée en objet. Pour ce faire, on déclare une définition « donnée » correspondant à chaque classe à interfacer en la déclarant en type complexe et en lui donnant le nom de classe existante.
Chaque classe à relier au framework de l'invention doit encapsuler une propriété "donnée" et implémenter l'interface IConteneurDonnee qui définit les méthodes suivantes : get donnee : retourne l'objet Donnée correspondant à donnée set donnee : affecter à la propriété "donnée" une Donnée
get id : retourne un identifiant unique de cette instance. Cet id est stocké en bdd dans le champ valeur de la table de données correspondante
enregistrer : permet d'enregistrer à fois l'instance en cours et la donnée encapsulée supprimer : supprimer l'instance en cours et la donnée encapsulée
Instancier(id) (méthode statique) : permet d'instancier une instance de cette classe à partir d'un id, ainsi de d'instancier et affecter la donnée correspondante à la propriété "donnée" encapsulée.
A l'instar des classes générées, l'utilisateur peut générer avec le modeleur une série d' accesseurs dans cette classe afin de pouvoir accéder aux valeurs, données (et objets) directement liés à la données, sans avoir besoin d'interroger les relations de la donnée encapsulée. Ce code est généré en fin de classe dans une zone réservée, et ré-générée le cas échéant dans cette même zone.
5.9 Module IHM
Le modèle utilisé par l'interface est le modèle de données préalablement décrit :
connaissance du modèle de données + définitions : contrôle de saisie
génération dynamique (possible aussi à l'exécution) d'écrans d'affichage/saisie adaptés au modèle
contrôle de saisie automatisé : expliquer comment ça marche
Options de génération (pour chaque écran) :
déclaration de la DD centrale (affichée ou non)
déclarations explicites des relations et données à afficher, ou par exclusion
templates
définition des données et relations affichables (de celles dédiées à l'application)

Claims

REVENDICATIONS
Procédé d'enregistrement d'une pluralité de données constituant au moins une entité, caractérisé en ce qu'il comprend :
une phase de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ;
une phase de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées ;
une phase de création de chaque donnée et relation de ladite pluralité de données ; une phase d'enregistrement de chaque donnée de ladite pluralité de données de sorte qu'une donnée enregistrée soit associée une définition de donnée correspondante ; une phase d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée.
Procédé d'enregistrement d'une pluralité de données selon la revendication 1, caractérisé en ce que ladite phase de créationd'une définition de relation comprend, pour une relation :
une étape de création d' une première extrémité de relation comprenant une première cardinalité de relation et associée à une première définition de données.
une étape de création d' une deuxième extrémité de relation comprenant chacune une cardinalité de relation et associée à une définition de données.
Procédé d'enregistrement selon la revendication 1 , caractérisé en ce qu'une définition de données comprend :
un nom de code ;
un type.
Procédé d'enregistrement selon la revendication 1, caractérisé en ce qu'une définition de relation comprend :
un nom de code ;
un type ;
au moins une extrémité.
5. Dispositif d'enregistrement d'une pluralité de données constituant au moins une entité, caractérisé en ce qu'il comprend :
des moyens de création d'une définition de donnée pour chaque donnée de ladite pluralité de données ;
des moyens de création d'une définition de relation d'au moins une relation entre au moins deux définitions de données préalablement créées.
des moyens de création de chaque donnée et relation de ladite pluralité de données ; des moyens d'enregistrement de chaque donnée de ladite pluralité de données de sorte qu'une donnée enregistrée soit associée à une définition de donnée correspondante ; des moyens d'enregistrement d'au moins une relation de sorte qu'une relation enregistrée corresponde à une définition de relation et soit associée à au moins une donnée préalablement enregistrée.
6. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé d'enregistrement selon l'une au moins des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.
PCT/EP2011/055657 2010-04-15 2011-04-12 Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant WO2011128311A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP11713797A EP2558932A1 (fr) 2010-04-15 2011-04-12 Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant
US13/641,428 US20130097581A1 (en) 2010-04-15 2011-04-12 Method for recording data, device, and corresponding computer program product

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR1052893 2010-04-15
FR1052893A FR2963123A1 (fr) 2010-04-15 2010-04-15 Procede de gestion de donnees, dispositif, et produit programme d'ordinateur correspondant
FR1056075A FR2963124A1 (fr) 2010-04-15 2010-07-23 Procede de gestion de donnees, dispositif, et produit programme d'ordinateur correspondant.
FR1056075 2010-07-23

Publications (1)

Publication Number Publication Date
WO2011128311A2 true WO2011128311A2 (fr) 2011-10-20

Family

ID=43901601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/055657 WO2011128311A2 (fr) 2010-04-15 2011-04-12 Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant

Country Status (4)

Country Link
US (1) US20130097581A1 (fr)
EP (1) EP2558932A1 (fr)
FR (1) FR2963124A1 (fr)
WO (1) WO2011128311A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160132297A1 (en) * 2013-06-11 2016-05-12 Smart Research Limited Method and computer program for generating or manipulating source code

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6539388B1 (en) * 1997-10-22 2003-03-25 Kabushika Kaisha Toshiba Object-oriented data storage and retrieval system using index table
JP3175692B2 (ja) * 1998-04-28 2001-06-11 日本電気株式会社 コンピュータと携帯端末間のデータ連携システム及びそのデータ連携方法
US7293254B2 (en) * 2003-09-18 2007-11-06 Microsoft Corporation Extensibility application programming interface and framework for meta-model objects
US7962497B2 (en) * 2005-02-18 2011-06-14 Microsoft Corporation Relationship modeling

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No further relevant documents disclosed

Also Published As

Publication number Publication date
EP2558932A1 (fr) 2013-02-20
US20130097581A1 (en) 2013-04-18
FR2963124A1 (fr) 2012-01-27

Similar Documents

Publication Publication Date Title
Richardson Microservices patterns: with examples in Java
Lerman Programming Entity Framework: Building Data Centric Apps with the ADO. NET Entity Framework
Gregory et al. Java Persistence with Hibernate
Paterson et al. db4o
Sanderson Pro Asp. net MVC 2 Framework
US20150293947A1 (en) Validating relationships between entities in a data model
Freeman et al. Pro asp. net MVC 3 Framework
US20120166977A1 (en) User programming access to data model in user interface design
Saternos Client-Server Web Apps with JavaScript and Java: Rich, Scalable, and RESTful
WO2009147310A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
Barrasa et al. Building Knowledge Graphs
Klein Pro Entity Framework 4.0
Ravindran Django Design Patterns and Best Practices: Industry-standard web development techniques and solutions using Python
WO2009147311A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
FR2813132A1 (fr) Systeme d&#39;interface d&#39;acces aux donnees d&#39;une base de donnees
Feldman et al. Developing Business Intelligence Apps for SharePoint: Combine the Power of SharePoint, LightSwitch, Power View, and SQL Server 2012
King et al. NHibernate in Action
WO2011128311A2 (fr) Procédé d&#39;enregistrement de données, dispositif, et produit programme d&#39;ordinateur correspondant
Soni et al. Spring: Developing Java Applications for the Enterprise
FR2963123A1 (fr) Procede de gestion de donnees, dispositif, et produit programme d&#39;ordinateur correspondant
Ledbrook et al. Grails in Action
Kanjilal Entity Framework Tutorial
FR2999314A1 (fr) Procede de creation de simulateur de configuration client
Hecksel et al. Getting Started with Oracle Data Integrator 11g: A Hands-On Tutorial
Chernetskyi Web application for organizing and administrating of language courses

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11713797

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011713797

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13641428

Country of ref document: US