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 »).

[rabDev]

Bonjour François et bonjour à toutes et à tous,


Je vais essayer de répondre et vous faire un petit aperçu de ce que j'ai développé jusqu'à présent.

Dans la version 0.5 de JMerise j'ai pris en compte toutes les règles de passage (Conversion) du MCD. Même dans le cas des relations (associations) 0,1 - 0,1 où on peut avoir plusieurs cas possibles. JMerise les convertit par défaut ou laisse le concepteur choisir une solution.

exemple :

dans ce cas l'utilisateur peut choisir

Pour les liens relatifs j'ai repris votre exemple et je l'ai testé directement dans JMerise.
MCD

MLD

Script MySQL :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
 
#------------------------------------------------------------
#        Script MySQL.
#------------------------------------------------------------
 
 
#------------------------------------------------------------
# Table: ASTRE
#------------------------------------------------------------
 
CREATE TABLE ASTRE(
        id_astre Int  Auto_increment  NOT NULL ,
        PRIMARY KEY (id_astre )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: SPECTRE
#------------------------------------------------------------
 
CREATE TABLE SPECTRE(
        id_astre   Int NOT NULL ,
        id_spectre Int  Auto_increment  NOT NULL ,
        crval1     Varchar (50) NOT NULL ,
        PRIMARY KEY (id_astre ,id_spectre )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: SPECTRE_ECHELLE
#------------------------------------------------------------
 
CREATE TABLE SPECTRE_ECHELLE(
        id_spectre Int NOT NULL ,
        id_astre   Int NOT NULL ,
        bss_ord    Varchar (50) NOT NULL ,
        PRIMARY KEY (id_spectre ,id_astre )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: BSS_ESRP
#------------------------------------------------------------
 
CREATE TABLE BSS_ESRP(
        id_astre   Int NOT NULL ,
        id_spectre Int NOT NULL ,
        bss_esrp   Varchar (50) NOT NULL ,
        PRIMARY KEY (id_astre ,id_spectre )
)ENGINE=InnoDB;
 
 
#------------------------------------------------------------
# Table: BSS_BINN
#------------------------------------------------------------
 
CREATE TABLE BSS_BINN(
        id_astre   Int NOT NULL ,
        id_spectre Int NOT NULL ,
        bss_binn   Int  Auto_increment  NOT NULL ,
        PRIMARY KEY (id_astre ,id_spectre )
)ENGINE=InnoDB;
 
 
 
 
ALTER TABLE SPECTRE
	 ADD CONSTRAINT FK_SPECTRE_ASTRE
	 FOREIGN KEY (id_astre)
	 REFERENCES ASTRE(id_astre);
 
ALTER TABLE SPECTRE_ECHELLE
	 ADD CONSTRAINT FK_SPECTRE_ECHELLE_SPECTRE
	 FOREIGN KEY (id_spectre,id_astre)
	 REFERENCES SPECTRE(id_spectre,id_astre);
 
ALTER TABLE BSS_ESRP
	 ADD CONSTRAINT FK_BSS_ESRP_SPECTRE
	 FOREIGN KEY (id_spectre,id_astre)
	 REFERENCES SPECTRE(id_spectre,id_astre);
 
ALTER TABLE BSS_BINN
	 ADD CONSTRAINT FK_BSS_BINN_SPECTRE
	 FOREIGN KEY (id_spectre,id_astre)
	 REFERENCES SPECTRE(id_spectre,id_astre);

Vous m'avez souligné l'intégrité référentielle, je l'ai commencé (comme vous le voyez dans le script ci-dessus). je n'ai pas encore fini de tester tout pour le moment.
vous m'avez suggéré aussi les CIF (c'est noté. ).

Merci encore une fois pour toutes ces remarques.

Bonne soirée (journée ) à toutes et à tous.

[fsmrel]

Bonsoir rabDev,

Bonne brise ces jours-ci, vous filez à 30 noeuds, gardez le cap !


MCD : c’est bon.


MLD : les colonnes de la clé primaire de la table SPECTRE_ECHELLE ne sont pas dans le bon ordre (effet Dagobert...)


Script SQL :

CREATE TABLE SPECTRE_ECHELLE : idem MLD, colonnes de la clé primaire à réordonner.

ALTER TABLE SPECTRE_ECHELLE : colonnes de la clé étrangère à réordonner ; même chose pour les tables BSS_ESRP et BSS_BINN.

Du nom des contraintes

Il s’agit ici de quelque chose de secondaire, mais pour éviter au SGBD de patiner lors de ses propres requêtes portant sur le catalogue relationnel (la métabase pour faire chic), nommer systématiquement chaque contrainte. Exemple de la table SPECTRE :

CONSTRAINT SPECTRE_PK PRIMARY KEY (id_astre) ;

Même principe pour les clés alternatives et contraintes en général. Notez en passant la présence du mot-clé « CONSTRAINT », et même s’il est facultatif, mieux vaut le faire figurer.


Par défaut, ne pas préfixer mais suffixer les noms des contraintes (par « PK », « FK », « AK », etc.) Exemple :

« SPECTRE_ECHELLE_SPECTRE_FK » plutôt que « FK_SPECTRE_ECHELLE_SPECTRE ».

En effet, quand un moteur s’occupe d’une table, par exemple SPECTRE, pour des raisons d’efficacité, il est préférable qu’il procède dans l’esprit LIKE 'SPECTRE%' plutôt que LIKE '%SPECTRE%'.

Maintenant, si telle ou telle entreprise a ses propres normes ès matière, elle doit pouvoir les proposer à l’outil (c’est ce que permet A*, le phagocyté, ou encore MySQL Workbench, voyez la figure 10.12, au paragraphe 10.4.5 « Nom par défaut des clés étrangères » de l’article que lui ai consacré). Toutefois, l’urgence n’est pas là aujourd’hui.


Bon vent !

[rabDev]

Bonjour François, Bonjour à toutes et à tous,

Merci pour ces remarques. j'ai eu un peu de temps libre et j'ai réalisé des corrections sur la nouvelle version.
Voilà ce que ça donne :

MLD : j'ai fait attention à l'ordre des attributs clés.

Dans le code SQL, concernant le nommage des contraintes, j'ai créé une option permettant de choisir l'une ou autre :
et ça donne :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
   ALTER TABLE SPECTRE
	 ADD CONSTRAINT SPECTRE_ASTRE_FK
	 FOREIGN KEY (id_astre)
	 REFERENCES ASTRE(id_astre);

ALTER TABLE SPECTRE
	 ADD CONSTRAINT FK_SPECTRE_ASTRE
	 FOREIGN KEY (id_astre)
	 REFERENCES ASTRE(id_astre);

j'essayerai de finir la version 0.5 le plus tôt possible afin de remplacer la 0.4.0.1. donc si vous avez d'autres remarques, des suggestions, des erreurs de fonctionnement ou autres à me signaler, n'hésitez surtout pas à me les envoyer.


Bonne journée à toutes et à tous

PS : Merci encore une fois François (fsmrel). j'ai vu aussi comment aborder le cas des cardinalités 1,1 ---- 1,1 . je vais essayer de faire le nécessaire.

[CinePhil]

Comme je n'ai pas tout suivi, je ne sais pas si ça a été évoqué mais, au sujet du nommage des objets (index, fk...), est-il prévu une zone permettant de nommer (ou modifier le nommage par défaut) soi-même avant la génération du SQL ?

Dans l'idéal, définir un modèle de nommage qui serait pris en compte lors de la génération du SQL serait top.

Personnellement, je m'inspire de la norme de nommage de SQLPro.

Exemples :
- te_personne_prs : table issue d'une entité type (te) qui enregistre les personnes et dont le préfixe des objets s'y rapportant est "prs" ;
- th_personne_physique_pph : table issue d'un héritage (th) qui enregistre les personnes physiques et dont le préfixe des objets s'y rapportant est "pph" ;
- tj_pph_diriger_prj_pdp : table issue d'une jointure (tj, d'une association type, en fait) entre la table de préfixe pph et la table de préfixe prj, associées par le verbe diriger, dont le préfixe est pdp ;
- prs_id : colonne portant l'identifiant, de la table te_personne_prs ;
- pph_id_personne : colonne portant l'identifiant de la personne dans la table th_personne_physique_pph ;
- x_prs_nom : index (x) sur la colonne prs_nom (qui est dans la table prs donc te_personne_prs) ;
- xu_pph_id_personne : "index unique" (xu) sur la colonne pph_id_personne ;
- fk_pph_id_personne : clé étrangère (fk, foreign key) sur la colonne pph_id_personne ;
- v_personne_physique : vue (v) donnant les informations sur les personnes physiques (qui fera au moins une jointure entre te_personne_prs et th_personne_physique_pph)...

Donc si je pouvais avoir :
- une zone "préfixe" lors de la création d'une table, toutes les colonnes de la table commenceraient par ce préfixe ;
- une zone généraliste pour le préfixage des tables, index, index uniques, vues, voire fonctions, triggers, procédures, domaines, schémas...
ce serait top !

[fsmrel]

Salve,

ce serait top !

A condition que ça puisse rester complètement optionnel...

Certes, un minimum de possibilités de préfixer ou suffixer soi-même en amont de la génération du code SQL est souhaitable, voire nécessaire, et je l’ai évoqué dans mon message précédent en ce qui concerne les contraintes, mais là, tu vas beaucoup plus loin...

Sans doute devrais-je limiter mon intervention à ce que je viens de dire, mais bon, on est tous concernés... Quel objectif poursuis-tu ? celui du DBA ?

S’il s’agit de savoir si l’objet 'X' est une table ou une vue, tu peux effectuer une requête SQL sur les tables du catalogue relationnel.

Pour changer un peu, prenons le cas de DB2 for z/OS :

 
SELECT TYPE
FROM   SYSIBM.SYSTABLES
WHERE  DBNAME = 'ma base de données'
  AND  CREATOR = 'mon schéma'
  AND  NAME = 'X' ;

Pour connaître les index de type UNIQUE de la table X :

 
SELECT b.NAME, b.UNIQUERULE
FROM   SYSIBM.SYSTABLES AS a JOIN SYSIBM.SYSINDEXES AS b ON a.NAME = b.TBNAME AND a.CREATOR = b.CREATOR
WHERE  a.DBNAME = 'ma base de données'
  AND  a.CREATOR = 'mon schéma'
  AND  a.NAME = 'X' 
  AND  b.UNIQUERULE <> 'D' ;

Pour connaître chaque contrainte référentielle portée par la table X :

 
SELECT b.RELNAME, b.REFTABNAME
FROM   SYSIBM.SYSTABLES AS a JOIN SYSIBM.SYSRELS AS b ON a.NAME = b.TBNAME AND a.CREATOR = b.CREATOR
WHERE  a.DBNAME = 'ma base de données'
  AND  a.CREATOR = 'mon schéma'
  AND  a.NAME = 'X' ;

Etc.

Le temps passant, il est plus sûr d’interroger le catalogue que de se fier à des noms d’objets dont la nature aura pu changer au fil des maintenances (vue (de jointure, tant qu’à faire) devenant table par exemple) et dont on a oublié de changer le nom en conséquence...

Tu évoques les triggers, fonctions, etc., mais il faudrait prendre en compte d’autres types d’objets (logiques, purement relationnels cette fois-ci), par exemple les assertions (même si les éditeurs renâclent, elles font partie de la norme SQL depuis 26 ans), les vues d’union, de différence, d’intersection, les vues d’un mix de tout ça (avec jointures internes, externes par-dessus le marché), les identifiants multi-attributs, et j’en passe : un travail de romain et de bénédictin...

Je le redis, un minimum de possibilité pour nous de préfixer ou suffixer est nécessaire, mais au delà...

Mais bien entendu, c’est rabDev qui décide, à lui d’estimer la charge que cela représenterait si d’aventure il s’y engageait à fond, auquel cas, par reconnaissance, tu pourras approvisionner le nourrain...

[CinePhil]

Bonjour François,

A condition que ça puisse rester complètement optionnel...

Oui, bien sûr !

Quel objectif poursuis-tu ?

Au début, j'étais sceptique sur la norme de nommage de SQLPro puis je m'y suis fait et j'y trouve certains côtés pratiques.
Notamment, lorsque j'affiche la liste des tables dans mon outil de gestion de la BDD (phpMyAdmin, MySQL Workbench, SQL Developer, PGAdmin...) il m'est plus facile de trouver le nom d'une table parce que je connais son type, vu que toutes les tables sont préfixées selon leur type.
Le suffixe du nom des tables me permet de savoir très facilement de quelle table est issue la colonne que je trouve dans une requête.

Quelques extraits de la norme de nommage de SQLPro...

Le but de cette standardisation est :
• d’une part, de fournir un cadre commun afin que tous les acteurs de la modélisation et du développement parlent le même « langage »,
• mais aussi, par la simple conception des noms d’objets, introduire des méthodes de gestion et de manipulation globales et génériques afin de faciliter
l’administration comme le développement et donc économiser à terme du temps et de l’argent.

1.3.4 – Noms des entités
Un nom d’entité est composé comme suit :
• la lettre T ;
• un blanc souligné (underscore) ;
• une lettre parmi :
o E pour entité,
o R pour référence,
o S pour système,
o X pour référence externe,
o H pour héritée,
o G pour générique,
o A pour administrative,
o H pour historique ;

• un blanc souligné (underscore) ;
• un nom explicite jamais pluralisé, comprenant éventuellement des blancs soulignés ;
• un blanc souligné (underscore) ;
• le trigramme de l’entité.

Exemples :
T_E_CLIENT_CLI : entité clients
T_R_SEXE_SEX : entité de référence sexe
T_X_CODE_POSTAL_CPL : entité de référence externe code postal
T_H_VOITURE_VTR entité héritée voiture
T_S_UTILISATEUR_USR entité système utilisateurs

Ceci dit, je ne respecte pas à la lettre cette norme et je n'oblige personne à la suivre ou à suivre la mienne (cette dernière n'est d'ailleurs pas écrite mais seulement issue de ma pratique, améliorée et améliorable depuis que je me suis astreint à standardiser nom nommage).

Et depuis que je procède ainsi, je n'ai quasiment plus besoin de regarder mon MCD ou mon "entity/relatioship diagram" (MySQL Workbench) pour chercher les noms des objets que j'utilise dans l'écriture de mes requêtes.

Mais bien entendu, c’est rabDev qui décide

Évidemment ! J'ai fait ma lettre au Père Noël !

[fsmrel]

Ave,

Je reprends ici l’échange posté dans la discussion Création BDD et MCD pour base de données botanique.


Côté MCD

Pièce jointe 367156

Association EST_AFFECTE : il manque l’attribut permettant de connaître la date d’affectation d’un technicien à une structure.

Vous symbolisez les associations de 1 à plusieurs par des pointes de flèche, façon Nanci (donc WinDesign) ou Moréjon, voire à l’occasion Afcet : pourquoi pas, ça permet de repérer très vite ce type d’association. Je note que l’association EST_SUR n’est pas fléchée : ce symbolisme est-il optionnel (ça serait une bonne chose, car tout le monde n’est pas forcément d’accord avec ce symbolisme, en fait très chargé et qui mime les dépendances fonctionnelles du modèle relationnel de données (mais sans l’axiomatique qui caractérise celles-ci...))

Que prévoyez-vous pour les associations à plus de deux pattes et dont au moins l’une d’elles est porteuse d’une cardinalité 1,1 ? En passant, les entités-types cibles devraient en l’occurrence pouvoir être fléchées... Je développerai ce point dès que je pourrai car, mine de rien, Armstrong est partie prenante dans cette affaire.

Entité-type REF_DEPARTEMENT :

Comme dans le MCD d’Alex, il y a une ambiguïté. On ne sait pas a priori si c’est le singleton {cd_departement} ou bien la paire {cd_departement, libelle_dpt} qui est identifiant candidat. En tout cas, à supposer que ce soit la paire (si l’on se réfère au MLD), on sait ainsi qu’un tel identifiant peut comporter plus d’un attribut (good news). Il faudrait quand même un moyen, façon PowerAMC ou DB-MAIN de lever l’ambiguïté dans le MCD.

Entité-typePASSAGE_POINT

Je souhaiterai voir une version du MCD sans l’attribut id_a_supprimer puisqu’on sait qu’il s’agit d’une scorie palliant une déficience de la version 0.4.0.1 de JMerise.


Association ESPECE_TAXEREF

La patte connectant l’entité-type ESPECE et l’association ESPECE_TAXREF est porteuse d’une cardinalité 0,1 : il faudrait que l’on puisse choisir la génération soit d’un attribut cd_nom dans l’en-tête de la future table ESPECE, soit d’une table ESPECE_TAXREF. En effet, il n’y a rien de plus horripilant que d’avoir des tables avec des dizaines de millions de lignes dont 99,9 % sont marquées NULL, et devoir entreprendre la mise en oeuvre d’une table hébergeant le 0,1 % pertinent. Même si ça n’est pas prioritaire, ça serait un plus pour JMerise par rapport aux autres...


Côté MLD

Pièce jointe 367159

Table PASSAGE_POINT

C’est évidemment le cas intéressant. La clé primaire est la même que celle qui est générée par DB-MAIN et PowerAMC. Mais essayons de faire mieux (un plus pour JMerise...). En effet, dès qu’un cycle a lieu en toute certitude (en l’occurrence TRANSECT, POINT, PASSAGE_POINT, PASSAGE, TRANSECT), c'est-à-dire quand il n’y pas rupture manifeste du cycle (cf. la discussion avec ammar.dev où le cycle est rompu), une contrainte de chemin est le plus souvent à mettre en oeuvre, exprimant ici la contrainte {id_transect_PASSAGE} = {id_transect_POINT}, et consistant à supprimer l’un des deux attributs et modifier l’une des deux clés étrangères en conséquence. L’idéal étant de poser la question au stade MCD : « Un cycle <TRANSECT, POINT, PASSAGE_POINT, PASSAGE, TRANSECT> a été détecté, faut-il le rompre ? » Bien entendu, il ne s’agit pas ici d’une tâche prioritaire, dans la mesure où l’on pourra intervenir sur le MLD et supprimer manuellement l’attribut redondant (à l’instar des autres, il faudra que JMerise répercute en cascade sur les tables dépendant directement ou indirectement de PASSAGE_POINT (ELEMENT, TYPER), sinon c’est la galère...).

Clés étrangères :

Le terme « clé étrangère » (inventé par Codd, fin des années soixante-dix) n’est pas des plus pertinents, mais il est chargé d’histoire. Il s’agit en réalité d’un cas particulier de la contrainte d’inclusion (au sens relationnel, cf. The New Relational Database Dictionary de Date). Bref, le mickey utilisé pour les clés étrangères peut être trompeur, on a l’impression (à l’instar de MySQL Workbench) qu’il peut servir pour une clé étrangère simultanément clé primaire (candidate plus généralement). Je reste sur ma réserve quant à ce mickey (comme je le suis du reste dans le cas de MySQL Workbench).


Script SQL

Ça prend cette fois-ci une bonne tournure !

les ALTER TABLE pour les clés étrangères ont disparu : c’est très bien, et même si ça n’est pas indispensable, on rejoint PowerAMC (tandis que DB-MAIN ne l’a pas fait). En tout cas j’achète.


On en arrive aux points de détail. Par exemple, histoire de pinailler, le dernier attribut figurant dans une clé étrangère est séparé de la parenthèse fermante par un espace, et à chaque fois ça me fait loucher...

La voie est la bonne, sans doute transpirez-vous abondamment, mais en tout cas, encore courage !

[rabDev]

Bonjour François et Bonjour à toutes et à tous,

Certaines erreurs ou manques dans le MCD sont corrigés et aussi j'ai supprimé l'attribut id_supprimer (n'est plus un identifiant).

je vous ferai le point de ce qui a été développé jusqu'à présent et ce qui reste à développer.

je commence par le MCD


MLD


1. Pour les flèches dans le MCD, elles ne sont pas automatisées. elles sont rajoutées manuellement dans la fenêtre des propriétés des liens :

Je pourrai dans les prochaines versions proposer une option permettant de les rajouter automatiquement ou manuellement.

2. Dans "Entité-typePASSAGE_POINT" : l'identifiant id_supprimer peut être supprimé sans crainte (ici je l'ai laissé comme attribut simple :voir le MCD).


3. Association ESPECE_TAXEREF : est un cas (0,1) - (x,n) ==> donne lieu à deux possibilités :

A noter que JMerise traite tous les autres cas : exemple (1,1) - (1,1), (0,1) - (0,1), etc...

4. Entité-type REF_DEPARTEMENT : définition des identifiants alternatifs.

Comme dans le MCD d’Alex, il y a une ambiguïté. On ne sait pas a priori si c’est le singleton {cd_departement} ou bien la paire {cd_departement, libelle_dpt} qui est identifiant candidat. En tout cas, à supposer que ce soit la paire (si l’on se réfère au MLD), on sait ainsi qu’un tel identifiant peut comporter plus d’un attribut (good news). Il faudrait quand même un moyen, façon PowerAMC ou DB-MAIN de lever l’ambiguïté dans le MCD.

Pour le moment, JMerise les déclare, dans le MCD, séparément mais dans le MLD, {cd_departement, libelle_dpt} forment une seule clé candidate.
Conscient de ce problème, j'ai même commencé à développer cette partie mais elle ne sera prête que dans les prochaines versions. ()

En effet, ce qui ne sera pas inclus dans la version 0.5 mais il sera développé dans les prochaines versions:
- La redéfinition des identifiants alternatifs au choix (simple, couple, ....)
- Toutes les contraintes (CIF, sur les associations, historisation, ... ) seront traitées dans les prochaines versions.

J'ai programmé la livraison de la version 0.5 pour la fin du mois d'Avril ou pour le début du mois de Mai au plus tard, c'est pour cette raison que j'ai pris la décision de repousser le développement des points précédents.


MLD :

1. Table PASSAGE_POINT

Dans les discussions précédentes (#7) j'ai évoqué la possibilité de renommer les attributs, de les ordonner,.... dans le MLD,. J'ai pas pensé à la possibilité de supprimer .... mais ça sera noté, Aussi ordonner les attributs sera développé dans la prochaine version.


2. Clés étrangères : le mickey,
c'est ma première proposition, elle n'est pas définitive. j'ai voulu quelque chose de sombre sans couleur et j'ai utilisé ces légendes.... si je trouve mieux je les changerai.

Script SQL

les ALTER TABLE pour les clés étrangères ont disparu : c’est très bien, et même si ça n’est pas indispensable, on rejoint PowerAMC (tandis que DB-MAIN ne l’a pas fait). En tout cas j’achète.

Je l'ai appliqué à MySQL, il me reste à le généraliser pour les autres SGBD (.... faisable).

.... dernier attribut figurant dans une clé étrangère est séparé de la parenthèse fermante par un espace, et à chaque fois ça me fait loucher...

. (c'est fait )

Avant de finir, je tiens à vous informer (et en particulier : CinePhil) que j'ai lu et noté tout ce qui m'a proposé en terme de norme de nommage utilisé. et je tiens à m'excuse aussi si je ne réponds pas à temps mais sachez que je suis et je lis la plupart des discussions.


Bonne journée à toutes et à tous

PS : si vous avez des remarques, des suggestions ou des erreurs à me signaler, surtout n'hésitez pas à me les envoyer par mail : jmerise@jfreesoft.com

[fsmrel]

Bonsoir rabDev,


Le MLD paraît correct, à ceci près que dans certaines tables, des clés étrangères ne sont pas nommées (EST_AFFECTE, INVENTORIE, PASSAGE, POINT, PASSAGE_POINT, ELEMENT, TYPER).

A suivre...

[fsmrel]

Bonsoir rabDev,

A propos de JMerise V0.5.

Je reprends les échanges que nous avons eus. Je ne mets pas tout en vrac, mais reprends plutôt sujet par sujet.

Posts #4 et #7 (Identification relative et ordre des colonnes dans la clé primaire d’une table SQL), voir ici.

C’est bon pour le MLD produit, à ceci près que la colonne sans nom est toujours présente dans l’en-tête de la table LIGNE_FACTURE :

Cette colonne est aussi présente dans le script SQL :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE LIGNE_FACTURE(
        id_facture       Int NOT NULL ,
        id_ligne_facture Int NOT NULL ,
        quantite         Int NOT NULL ,
                         Int
      , CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY (id_facture,id_ligne_facture)
      , CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY (id_facture) REFERENCES FACTURE(id_facture)
)ENGINE=InnoDB;

Au passage, corrections orthographiques à apporter :

– Remplacer « séléction » par « sélection ».

– Fenêtre « Propriété de Entité MLD » : corriger « Autres prorpiétés ».

[fsmrel]

Clés étrangères :

Il manque dans JMerise une fenêtre donnant accès aux clés étrangères. Par exemple, dans la table PASSAGE_POINT, après avoir renommé id_transect_point en id_transect (en passant, le code SQL ne suit pas) il faut qu’on puisse supprimer l’attribut id_transect_passage et modifier la clé étrangère {id_transect_passage} en {id_transect}, comme on le fait avec un autre AGL :

La génération du script SQL ne devrait être possible qu’une fois le MLD lui-même généré et réaménagé quand c’est nécessaire, comme ci-dessus.

En corollaire, le cas des entités-types identifiées relativement, et pour revenir sur PASSAGE_POINT...

Voir les diagrammes ici (post #50).

post #52 : Alexandre avait réussi à progresser :

Du coup, j'ai testé JMerise Beta, et voici ci-dessous ce que ça donne. [...]
J'ai pu supprimer la clé primaire que j'avais ajouté dans la relation PASSAGE_POINT qui était demandée avec la version précédente.

Alexandre a donc produit un MCD sans attribut identifiant parasite pour l’entité-type PASSAGE_POINT, et le MLD dérivé n’est pas pollué. Mais aujourd’hui, on régresse : certes, quand on demande à JMerise de vérifier le MCD, il répond : « le MCD est correct », conformément à ce que vous aviez précisé dans le post # 16 :

Dans "Entité-typePASSAGE_POINT" : l'identifiant id_supprimer peut être supprimé sans crainte (ici je l'ai laissé comme attribut simple :voir le MCD).

Mais quand on demande maintenant à JMerise de convertir le MCD, ça se passe autrement :

Lien relatif : l'entite "PASSAGE_POINT" ne contient pas de clé primaire
ERREUR : Le MCD est incorrect

Je rappelle qu’il s’agit d’une erreur pénalisante de la part de JMerise. En effet, si l’on injecte un identifiant parasite, il faudra par la suite le supprimer manuellement dans les tables faisant référence directement ou indirectement à PASSAGE_POINT (clés primaires et étrangères).

A suivre.

[rabDev]

Bonjour François,

Avant tout, Merci pour toutes ces remarques.

1. l'attribut vide dans l'entité type Ligne_facture.

Après l'analyse du MCD que vous m'avez envoyé, effectivement, il y a un attribut vide déclaré dans la relation "Contenir" . cet attribut a échappé à la vérification de JMerise 05 (car le MCD à été réalisé avec l'ancienne version 0.4.0.1) et donc, on le retrouve dans l'entité Ligne_facture lors du passage MCD--> MLD. J'ai refait et accentué les vérifications sur les attributs des anciens modèles.

MCD

MLD

2. Re-générer le code SQL une fois le MLD et le Script SQL sont générés.

Comme vous le savez, on peut renommer les noms et les codes des attributs dans le MLD. Ensuite, il faut appuyer sur le bouton "Regénérer le script SQL" (voir l'image ci-dessous) pour générer le script correspondant aux modifications.

2.1. Dans les prochaines versions :
En plus de renommer les attributs dans le MLD, on pourra aussi :
a. Supprimer / réordonner les attributs
b. gérer (renommer/réordonner ..) les déclarations des clés composées.
c. gérer les clés alternatives.

3. Pour le MCD avec des identifiants relatifs (exemple d'AlexandreR31) je suis en train de le refaire ..... une fois fini je vérifierai ce qui ne va pas. je vous tiendrai au courant.

encore Merci pour toutes ces remarques

Bonne journée et bon Dimanche