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)

Applications Claiming Priority (3)

Publications (1)

Family

ID=43901601

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (4)

• 2010
  • 2010-07-23 FR FR1056075A patent/FR2963124A1/fr not_active Withdrawn
• 2011
  • 2011-04-12 WO PCT/EP2011/055657 patent/WO2011128311A2/fr active Application Filing
  • 2011-04-12 US US13/641,428 patent/US20130097581A1/en not_active Abandoned
  • 2011-04-12 EP EP11713797A patent/EP2558932A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events