Discussion :

[rabDev]

Bonjour à toutes et à tous,

La version-test 0.5 (version Alpha) de JMerise est disponible à cette à adresse : http://www.jfreesoft.com/JMerise/nouvelleversion.html


Certaines fonctionnalités sont en cours de développement. Elle sont, donc, désactivées.

L'interface de la nouvelle version ressemble à ça :

Bonne journée et Bonne Année 2018 à toutes et à tous.

[CinePhil]

Bonjour et bonne année !

Quand prévois-tu la version définitive ?

Et sinon, as-tu envisagé :
- un renommage de JMerise en JMCD puisqu'il existe à côté JMCT ?
- une fusion des deux applications dans JMerise ?

Tes outils sont super et je constate dans le forum Schéma que JMerise est de plus en plus utilisé par ceux qui initient des discussions ou y répondent.

[rabDev]

Bonjour,

Pour la sortie définitive de cette version, je ne peux pas vous avancer une date exacte. peut être dans un mois ou deux. en tout cas mois de six mois. il reste encore un peu de développement à finir (Vérification MCD, transformation MCD, génération des script, ....).

Le jour où JMerise permettra de créer tous les modèles Merise, le module MCD sera nommé JMCD. autrement dis JMerise deviendra JMCD et JMerise sera le logiciel qui fera n'importe quel Modèle (MCD, MOT, MCT, ... ).

Oui, je l'ai remarqué. je remercie tous les utilisateurs de JMerise.

enfin, cette version sera (selon moi) plus professionnelle, elle sera la plus complète et la plus aboutie de toutes les versions JMerise. .... Promis !!

Bonne journée !!

[fsmrel]

Bonsoir rabDev,

A propos de l'ordre des colonnes dans la clé primaire d’une table SQL.

Il est impératif que les colonnes de la clé d’une table T2 identifiée relativement à une table T1 soient ordonnées en fonction de l’importance relative de ces deux tables : en tête, doivent figurer les colonnes de la clé de T1, celles de T2 venant seulement à la suite. En effet, au niveau conceptuel, T2 n’est jamais qu’une propriété multivaluée de T1. En conséquence, au stade SQL, les accès mettront fondamentalement en jeu les attributs composant la clé primaire de T1 (et la clé étrangère correspondante portée par T2, jointure oblige).


Exemple des factures (qu’on pourrait qualifier de canonique, tant il revient souvent) :




Lors du passage au MLD, JMerise (0.4.0.1) génère simultanément le code SQL suivant, lequel comporte ici une anomalie (présence d’une colonne sans nom dans l’en-tête de la table LIGNE_FACTURE...) :

#------------------------------------------------------------
# Table: FACTURE
#------------------------------------------------------------

CREATE TABLE FACTURE(
        id_facture   Int NOT NULL ,
        num_facture  Int NOT NULL ,
        date_facture Date NOT NULL ,
        PRIMARY KEY (id_facture ) ,
        UNIQUE (num_facture )
)ENGINE=InnoDB;

#------------------------------------------------------------
# Table: LIGNE_FACTURE
#------------------------------------------------------------

CREATE TABLE LIGNE_FACTURE(
        id_ligne_facture Int NOT NULL ,
        quantite         Int NOT NULL ,
                         Int ,
        id_facture       Int NOT NULL ,
        PRIMARY KEY (id_ligne_facture ,id_facture )
)ENGINE=InnoDB;

La clé primaire générée est la suivante :

{id_ligne_facture, id_facture}

Le point important concerne la performance des requêtes SQL : pour accéder aux lignes d’une facture, il va falloir un index supplémentaire de clé {id facture} pour la table LIGNE_FACTURE. Qui plus est, le regroupement des données en mémoire (clustering) sera par défaut sur id_ligne_facture ce qui fait qu’il faudra un I/O par ligne de facture (à moins que juste après la génération du code, le DBA arrive à temps pour rendre cluster l’index supplémentaire à la place du 1er (manip qui est SGBD dépendante...)).

Par contre, si JMerise générait la clé primaire suivante :

{id_facture, id_ligne_facture}

Alors tout rentrerait dans l’ordre, la recherche des lignes d’une facture ne nécessiterait qu’une I/O, et en plus, il serait inutile de créer un index supplémentaire. Sémantique, coût et performance se rejoignent... A noter que DB-MAIN, PowerAMC, même MySQL Workbench ordonnent les colonnes ainsi. Pour ma part je suis très vigilant sur ce point et en plus de 30 ans de baroud (concepteur ou DBA) dans les grandes entreprises, à m’engager sur la validité et la performance de leurs bases de données SQL, je n’ai jamais eu à changer d’approche (sauf dans de rares cas de problèmes de contention, mais je ne voudrais pas sortir du sujet, qui concerne plus le réglage des accès aux données, tout au fond de la soute).

[fsmrel]

Bonsoir à nouveau RabDev,

Je fais référence à la discussion qui vous a fait réagir : Création BDD et MCD pour base de données botanique.

Dans une base de données relationnelle, si une table T2 fait référence à une table T1 par le jeu d’une une clé étrangère composée des attributs F1, F2, ..., Fn, alors ceux-ci doivent correspondre respectivement aux attributs K1, K2, ..., Kn qui composent la clé primaire (ou une clé alternative) de T1.

Pour illustrer, prenons le cas de la table PASSAGE_POINT (cf. la discussion en cause). Elle fait référence à la table POINT et à la table PASSAGE.

La table POINT a pour clé primaire la paire {id_transect, id_point}

La table PASSAGE a pour clé primaire la paire {id_transect, id_passage}

La table PASSAGE_POINT doit donc être dotée des clés étrangères :

{id_transect, id_point} faisant référence à la clé primaire {id_transect, id_point} de la table POINT

{id_transect, id_passage} faisant référence à la clé primaire {id_transect, id_passage} de la table PASSAGE

Et non pas

{id_point} faisant référence à une partie seulement de la clé primaire {id_point} de la table POINT

{id_transect_POINT} faisant référence à une partie seulement de la clé primaire {id_transect} de la table POINT

{id_passage} faisant référence à une partie seulement de la clé primaire {id_passage} de la table PASSAGE

{id_transect_PASSAGE} faisant référence à une partie seulement de la clé primaire {id_transect} de la table PASSAGE

En effet, supposons que la table POINT contienne 4 lignes et considérons la projection de cette table sur les attributs id_transect et id_point :

id_transect    id_point 
1              1
1              2
1              3
2              1

Au vu des clés étrangères ci-dessus, rien n’interdit que la projection de la table PASSAGE_POINT sur ces attributs contienne la ligne illégale :

id_transect_POINT    id_point 
2                    3

En effet, la paire <2, 3> n’existe pas dans la table POINT. Cette paire doit y être lue :

id_transect = 2 ET id_point = 3

Alors que selon la génération faite par JMerise la paire doit être lue :

id_transect = 2 OU id_point = 3

Ce qui du point de vue de la logique n’est quand même pas la même chose.

Je répète : les attributs qui composent une clé étrangère doivent correspondre un pour un à la clé primaire (ou à une clé alternative) de la table cible ; à défaut, ça revient au fond à ne pas définir de clés étrangères, c’est aux risques et périls de l’application.

Et PostgreSQL (utilisé par Alex, cf. la discussion en cause) n’en disconvient pas, puisqu’il rejette les clés étrangères partielles :

SET SCHEMA 'alex' ; 
SET default_with_oids = false;

DROP TABLE IF EXISTS POINT ;
DROP TABLE IF EXISTS TRANSECT ;

-- -------------------------
-- Déclaration des tables 
-- -------------------------

CREATE TABLE POINT
(
        id_transect       int                NOT NULL
      , id_point          int                NOT NULL
  , CONSTRAINT POINT_PK PRIMARY KEY (id_transect, id_point)
) ;

CREATE TABLE PASSAGE_POINT
(
        id_transect       int                NOT NULL       
      , id_point          int                NOT NULL
      , id_passage        int                NOT NULL
      , heure             int                NOT NULL
  , CONSTRAINT PASSAGE_POINT_PK PRIMARY KEY (id_transect, id_point, id_passage)
  , CONSTRAINT PASSAGE_POINT_FK1 FOREIGN KEY (id_transect) REFERENCES POINT  (id_transect)
) ;

Lors de la déclaration de la table PASSAGE_POINT, PostgreSQL dit qu’il n’a pas trouvé la clé {id_transect} dans la table POINT, et effectivement il n’y a que la clé {id_transect, id_point}...



Il y a quelques clés étrangères à corriger pour la base d'Alex.

[fsmrel]

Bonsoir (ou bonjour...),

A propos des CIF :

Pour le moment, on ne peut pas réaliser la liaison entre CIF et RELATION avec la version actuelle de JMerise... c'était un oubli (désolé).
ce problème est résolu dans la prochaine version.

Soit.
Cela dit, dans le MCD que je propose ci-dessous, il n’y a qu’une seule association entre les entités-types impliquées dans la CIF. Cette association joue le rôle de la portée de la CIF, donc il y a moindre mal.

Plus important : en ce qui concerne le MLD, je fais observer que du fait de la CIF, la clé primaire de la table PARTICIPER n’est pas le triplet {CourseId, JockeyId, ChevalId}, mais la paire {CourseId, ChevalId}.

Ce qui est généré par JMerise (0.4.0.1) :

Ce qui est attendu :

Qu’en sera-t-il avec la version 0.5 ?

En complément, je vous invite à examiner ce qui est écrit ici, où l’on voit qu’avec DB-MAIN (Hainaut), il y a des façons plus simples de traiter de la CIF que ce que proposèrent Tardieu, Rochfeld, Nanci et Cie et fut entériné, normalisé par l’Afcet. Si cela peut vous inspirer...

[rabDev]

Bonjour François,

Merci pour ce précieux conseil. votre message je l'ai lu 5 minutes après sa publication et j'ai fait le nécessaire 2 minutes après.

Bonsoir rabDev,

A propos de l'ordre des colonnes dans la clé primaire d’une table SQL.

Il est impératif que les colonnes de la clé d’une table T2 identifiée relativement à une table T1 soient ordonnées en fonction de l’importance relative de ces deux tables : en tête, doivent figurer les colonnes de la clé de T1, celles de T2 venant seulement à la suite. En effet, au niveau conceptuel, T2 n’est jamais qu’une propriété multivaluée de T1. En conséquence, au stade SQL, les accès mettront fondamentalement en jeu les attributs composant la clé primaire de T1 (et la clé étrangère correspondante portée par T2, jointure oblige).


Exemple des factures (qu’on pourrait qualifier de canonique, tant il revient souvent) :




Lors du passage au MLD, JMerise (0.4.0.1) génère simultanément le code SQL suivant, lequel comporte ici une anomalie (présence d’une colonne sans nom dans l’en-tête de la table LIGNE_FACTURE...) :

#------------------------------------------------------------
# Table: FACTURE
#------------------------------------------------------------

CREATE TABLE FACTURE(
        id_facture   Int NOT NULL ,
        num_facture  Int NOT NULL ,
        date_facture Date NOT NULL ,
        PRIMARY KEY (id_facture ) ,
        UNIQUE (num_facture )
)ENGINE=InnoDB;

#------------------------------------------------------------
# Table: LIGNE_FACTURE
#------------------------------------------------------------

CREATE TABLE LIGNE_FACTURE(
        id_ligne_facture Int NOT NULL ,
        quantite         Int NOT NULL ,
                         Int ,
        id_facture       Int NOT NULL ,
        PRIMARY KEY (id_ligne_facture ,id_facture )
)ENGINE=InnoDB;

La clé primaire générée est la suivante :

{id_ligne_facture, id_facture}

Le point important concerne la performance des requêtes SQL : pour accéder aux lignes d’une facture, il va falloir un index supplémentaire de clé {id facture} pour la table LIGNE_FACTURE. Qui plus est, le regroupement des données en mémoire (clustering) sera par défaut sur id_ligne_facture ce qui fait qu’il faudra un I/O par ligne de facture (à moins que juste après la génération du code, le DBA arrive à temps pour rendre cluster l’index supplémentaire à la place du 1er (manip qui est SGBD dépendante...)).

Par contre, si JMerise générait la clé primaire suivante :

{id_facture, id_ligne_facture}

Alors tout rentrerait dans l’ordre, la recherche des lignes d’une facture ne nécessiterait qu’une I/O, et en plus, il serait inutile de créer un index supplémentaire. Sémantique, coût et performance se rejoignent... A noter que DB-MAIN, PowerAMC, même MySQL Workbench ordonnent les colonnes ainsi. Pour ma part je suis très vigilant sur ce point et en plus de 30 ans de baroud (concepteur ou DBA) dans les grandes entreprises, à m’engager sur la validité et la performance de leurs bases de données SQL, je n’ai jamais eu à changer d’approche (sauf dans de rares cas de problèmes de contention, mais je ne voudrais pas sortir du sujet, qui concerne plus le réglage des accès aux données, tout au fond de la soute).

voilà ce que ça donne avec la version 0.5 :
Cette clé (id_facture, ou toutes les clés issues des liens relatifs) sera mise en première position (automatiquement). exemple :

MCD :



MLD :


Script SQL

#------------------------------------------------------------
# Table: FACTURE
#------------------------------------------------------------

CREATE TABLE FACTURE(
        id_facture   Int NOT NULL ,
        date_facture Date NOT NULL ,
        num_facture  Int NOT NULL ,
        PRIMARY KEY (id_facture ) ,
        UNIQUE (num_facture )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: LIGNE_FACTURE
#------------------------------------------------------------

CREATE TABLE LIGNE_FACTURE(
        id_facture       Int NOT NULL ,
        id_ligne_facture Int NOT NULL ,
        quantite         Int NOT NULL ,
        PRIMARY KEY (id_facture ,id_ligne_facture )
)ENGINE=InnoDB;

ou elles seront ordonnées manuellement par les concepteurs dans la propriété des attributs : voir ci-dessous




pour l'attribut vide, normalement il n'apparaitra plus dans cette version [ j'espère ]

Merci et bonne journée

[fsmrel]

Bonsoir rabDev,

votre message je l'ai lu 5 minutes après sa publication et j'ai fait le nécessaire 2 minutes après.

Pourvu que vous conserviez la cadence ! Comme vous êtes sur votre lancée, j’en remets une louche... J’en viens à un besoin qui est exprimé dans certaines discussions chez DVP, et qui ressortit à l’injection :

[A]----0,1--------(R)--------1,1----[B]

Sans oublier le cas où intervient l’identification relative :

[A]----0,1--------(R)--------(1,1)----[B]

Et qui répond au besoin d’évacuer d’une entité-type les attributs qui pour lesquels les valeurs peuvent ne pas avoir de sens (missing and inapplicable chez Codd, cf. The Relational Model for Database Management, Version 2).

J’illustre cela avec l’exemple des spectres des astres, voyez la discussion ici.

L’entité-type SPECTRE comportent des attributs « obligatoires » (NOT NULL au stade SQL) et d’autres qui ne sont pas. Les premiers (CRVAL1, CDELT1, etc.) font partie de l’en-tête de l’entité-type SPECTRE et les autres donnent lieu aux entités-types faibles BSS_ESRP et BSS_BINN :

MCD (PowerAMC)

Le MLD (PowerAMC encore à la manœuvre) :

Dans le post auquel je renvoie, je rappelle que JMerise ne permet pas aujourd’hui de produire le MCD ci-dessus (et a fortiori ni le MLD ni le code SQL). Vous vous doutez de la question que je me dois de formuler, et je vous laisse le soin d’y répondre...

Concomitamment, j’ai rédigé un billet qui traite du sujet (« Join, le tueur des dinosaures »).