Discussion :

[pierrot10]

Bonjour à tous

J'utilise depuis peu MySQL Workbench pour faire un schàma.

J'ai du mal a comprendre exactement ces termes

one-to-one non-identifying relationship
one-to-many non-identifying relationship
one-to-one identifying relationship
one-to-many identifying relationship
many-to-many identifying relationship

En ce qui me concerne, j'ai 4 tables:
Categories
Projects
Experiences
Documents

Des documents peuvent appartenir à plusieurs Experiences (Many-to-many) (et peut-être à des Projects, je ne sais pas encore...)
Des Experiences ne peuvent apparteneir qu'à un Projects (one-to-many)
Des Projects ne peuvent appartenir qu'à une Catégories (one-to-many)

Mais quelle est la difference entre 'one-to-many non-identifying relationship' et 'one-to-many identifying relationship' ??

Merci pour vos lumières

[escartefigue]

C'est la même chose que l'identification relative

Exemple :
- table factures : identifiant = N° de facture
- table lignes de factures : identifiant = N° de facture + n° de ligne
La ligne de facture est identifiée relativement à une facture, le n° de ligne seul ne suffit pas, le n° de ligne seul peut provoquer des doublons

Contre exemple :
- table factures : identifiant = N° de facture, FK = n° de client
- table client : identifiant = n° de client
La facture n'est pas identifiée relativement au client, elle dispose d'un identifiant propre et unique

[pier.antoine]

Merci Escartefigue pour cet éclaircissement.

Je crois que j'ai enfin compris l'intérêt de l'identification relative.

pierrot10 :
ce type d'interrogation concerne la partie conception de base de données. Il vaut mieux la poser dans le forum Merise, par exemple.

Pierre

[Artemus24]

Salut à tous.

Merci Escartefigue pour ton exemple mais ce n'est pas exactement ça, car tu ne définies pas assez ce qui fait la distinction entre les deux cas.

Qui dit relation, dit obligatoirement un lien unifiant une entité père à son entité fils.
J'ai pris volontairement une relation de type hiérarchique pour caractérisé la relation 'one-many', c'est-à-dire 1-N.

Comment se définit la relation entre l'entité père et l'entité fils ?
Elle se définit par l'identifiant de l'entité père qui est aussi sa clef primaire.

On nomme une relation identifiante (ou identifié relativement) quand il y a une dépendance entre ces deux entités.
Autrement dit, une ligne de l'entité fils est toujours en relation avec une ligne de l'entité père.
C'est-à-dire que l'on peut atteindre la ligne fils en passant par l'identifiant de la ligne père.

On nomme une relation non identifiante dans le cas contraire.
Autrement dit, la ligne de l'entité fils n'est pas systématiquement en relation avec une ligne de l'entité père.
Ou si vous préférez, on doit utiliser une autre identifiant pour atteindre la ligne de l'entité fils.

Comment cela se caractérise dans une base de données ?

Et bien tout simplement en faisant une 'foreign key' ou pas !

Dans la relation identifiante, cela se traduit obligatoirement par une 'foreign key'. Pourquoi ?
Car l'identifiant est toujours connu et ne peut pas prendre la valeur nulle.

Dans la relation non identifiante, la valeur nulle peut apparaître et de ce fait, on ne peut pas mettre une 'foreign key' car cette valeur est interdite.

Pour simplifier cette définition, il suffit de se poser la question si la relation existe toujours entre les entités père et fils.
Si l'on introduit un identifiant nul dans l'entité fils, alors la relation n'existe pas et de ce fait, la relation père - fils ne peut être identifiante.

Deux exemples pour illustrer ce concept dans la théorie des ensembles.

1) la relation 'lignes de facture' (je reprends l'exemple de Escartefigue).
Comme on le constate, le détail de la facture, que l'on nomme 'ligne facture', appartient obligatoirement à une facture.
Il ne peut pas en être autrement ! Donc la relation existe dans tous les cas, et c'est bien une relation identifiante.

2) la relation 'appartient à'.
Deux cas peuvent arriver, soit elle existe, soit elle n'existe pas.
Si elle existe alors on renseigne l'identifiant, si elle n'existe pas, l'identifiant prend la valeur nulle.
C'est à cause d'un identifiant nul que la relation est dite non identifiante.

Indépendamment de cette définition, chaque entité à sa clef primaire, ce qui fait que chaque ligne sera identifiée d'une manière unique.

Inversement, ton contre-exemple Escartefigue n'en est pas un, car l'identifiant de l'entité client permet d'atteindre l'entité facture, puisqu'il y a une clef étrangère entre ces deux entités.

@+

[escartefigue]

Inversement, ton contre-exemple Escartefigue n'en est pas un, car l'identifiant de l'entité client permet d'atteindre l'entité facture, puisqu'il y a une clef étrangère entre ces deux entités.

Justement si ! dans mon exemple, le client est FK de la table facture, mais les 2 identifiants n'ont absolument aucun lien (contrairement au n° de ligne facture qui lui est un identifiant relatif au n° de facture)

On a donc bien dans un cas une identification relative : ligne de facture vers facture
Dans l'autre cas une identification non relative : client d'une part et facture d'autre part

De plus, on pourrait très bien avoir également dans la table des lignes de facture, une ou plusieurs FK non relatives
Exemples :
- code unité de mesure de la qté facturée vers la table des unités de mesure
- code devise de facturation vers la table des devises
etc...

[Artemus24]

Salut Escatrtefigue.

Peut-on savoir pourquoi tu m'as mis '-1' ?

Faire usage des factures et des clients pour donner un exemple illustrant ce qu'est une "relation identifiante" est excellent. Nous sommes d'accord sur cela !
Encore faut-il donner le bon exemple pour illustrer la définition d'une relation identifiantes.
Tes deux exemples ne sont pas des relations identifiantes car il existe un contre exemple à chaque fois.

Je vais devoir argumenter pourquoi elles ne le sont pas.

Exemple :
- table factures : identifiant = N° de facture
- table lignes de factures : identifiant = N° de facture + n° de ligne
La ligne de facture est identifiée relativement à une facture, le n° de ligne seul ne suffit pas, le n° de ligne seul peut provoquer des doublons

Si je dois paraphraser une expression mathématique bien connu, je dirais que "la condition est nécessaire mais pas suffisante".

L'idée est bonne mais tu as oublié l'essentielle qui fait que ton exemple n'est pas une relation identifiante (identifié relativement, peu importe la traduction).
Le principale problème est l'intégrité de tes données.
Qu'est-ce qui prouve, dans ton exemple, que le N° de facture présent dans la table "lignes de factures" est aussi présent dans la table "factures" ?
Pour résoudre ce problème, il faut faire l'usage de la clef étrangère, qui n'est pas explicitement donné dans ton exemple.

Sinon un contre exemple suffit pour infirmer la relation identifiante. Un numéro de facture présent dans la table "ligne de facture" mais absente de la table "facture".
Ta structure peut autoriser cela.

Contre exemple :
- table factures : identifiant = N° de facture, FK = n° de client
- table client : identifiant = n° de client
La facture n'est pas identifiée relativement au client, elle dispose d'un identifiant propre et unique

Il y a déjà un mieux car cette fois-ci tu fais usage de la clef étrangère Donc, on n'a pas de problème d'intégrité sur les valeurs du N° de client

Je n'ai fait que survoler ton exemple la première fois et en y regardant de plus près, il y a une ambiguïté concernant la notion de facture.
En général, on admet qu'une facture donnée permet d'identifier d'une manière unique un client.

Or telle que la table a été définie, on a l'impression qu'une facture peut se partager entre plusieurs clients, d'où l'ambiguïté.

Pourquoi ai-je dis que je ne suis pas d'accord avec toi ?
Parce que le fait d'utiliser une clef étrangère est une condition nécessaire pour l'obtention d'une relation identifiante et je me suis arrêté là.
Mais la condition n'est pas suffisante. Pourquoi ? Car cette relation à deux pères d'où l'ambiguïté et donc n'est pas une relation identifiante.
Car on ne sait rien de la nature exacte du N° de la facture.

Le bon exemple est de définir les tables de la façon suivante :

--> table client : identifiant = N° de client
--> table facture : identifiant = N° de client + N° de ligne, FK = N° de client

C'est presque pareil que ton exemple, sauf que j'ai ajouté la clef étrangère.

Voici mes arguments :
--> La demande formulée par Pierrot10 est la suivante :

Mais quelle est la difference entre 'one-to-many non-identifying relationship' et 'one-to-many identifying relationship' ??

--> donc il n'y a qu'un seul père, la table "client". Nous sommes dans une relation dite hiérarchique père vers fils, où encore 1-n.
--> Intégrité des données car on fait l'usage d'une clef étrangère. Donc pas de valeurs absentes ou de valeur nulle.
--> la clef primaire de la table fils "facture" traduit l'unicité d'une ligne dans la table.

En tenant compte de ces points, la relation est dite identifiante. Dans les autre cas, elle ne le sera pas.

Remarque : je reconnais que je ne suis pas un expert de la méthode merise, mais que ceci est un souvenir qui commence à dater.
Je ne connais pas la définition officielle de "identifying relationship" que j'ai traduit par "relation identifiante".
Mais d'après l'expérience que j'ai des bases de données, pour rendre une relation identifiante, il faut d'une part intégrité des données (FK) et d'autre part unicité de l'identification de la ligne (donc la clef primaire) dans la table fils.

Si vous avez des arguments me montrant que je suis dans l'erreur, je suis preneur de toutes leçons enrichissantes.

@+

[escartefigue]

Qu'est-ce qui prouve, dans ton exemple, que le N° de facture présent dans la table "lignes de factures" est aussi présent dans la table "factures" ?
Pour résoudre ce problème, il faut faire l'usage de la clef étrangère, qui n'est pas explicitement donné dans ton exemple.

C'est justement le principe d'une relation identifiante que d'hériter d'une clef étrangère comme composante de sa clef principale !
Ceux qui connaissent les outils de modélisations tels que AMC designor, rational Rose et consorts le savent bien
il n'y a donc aucun doute la dessus !

Par contre dire qu'il y a un doute sur le fait qu'une facture ne concerne qu'un et un seul client
A partir du moment où la facture qui bien évidement possède un n° unique (c'est d'ailleurs réglementaire) possède en clef étrangère comme je l'ai mentionné, le n° de client, il est impossible, et fort heureusement, d'avoir une facture multi-client.
La seule façon d'avoir une facture multi-client, serait soit d'avoir plusieurs fois le même n° de facture dans la table facture ce qui est interdit et n'a aucun sens, soit d'avoir plusieurs colonne n° de client dans la table facture, ce qui est une hérésie d'un point de vue modélisation, et ne correspond à rien fonctionnellement.

[Artemus24]

Salut Escartefigue.

Merci pour ta réponse.

Ceux qui connaissent les outils de modélisations tels que AMC designor, rational Rose et consorts le savent bien
il n'y a donc aucun doute la dessus !

Désolé, mais je ne connais pas ces outils. Je viens du gros système et à mon époque, on faisait beaucoup de bricolage et pas trop de Merise
Ce qui est évident pour toi ne l'est pas forcément pour d'autres.

C'est justement le principe d'une relation identifiante que d'hériter d'une clef étrangère comme composante de sa clef principale !

Pourquoi ne l'as-tu pas dit dès le départ ? Je suis totalement d'accord avec cette définition ! Tu as fait du concis avec cette définition et cela corrobore mes explications.
(je sais que je suis très prolixe. Je dis en un bouquin ce que d'autres disent en une ligne).

Par contre dire qu'il y a un doute sur le fait qu'une facture ne concerne qu'un et un seul client

Il faut se mettre à la place de quelqu'un qui lit la description de ta base de données sans connaitre les sous-entendus. Le fait de mettre ceci :

- table factures : identifiant = N° de facture, FK = n° de client

suggère que la table "factures" à deux pères et est constituée de la concaténation des clef primaires de ces deux tables parentes.
Sauf que dans le cas du N° de facture, ce n'est pas une clef étrangère, d'où l'ambiguïté sur les valeurs de ces numéros.
Rien n'empêche de mettre un nul ou une valeur n'existant pas dans la table père des N° de factures.

La déclarative suivante est un peu plus juste dans ce que j'énonce sur l'intégrité des données.

- table factures : identifiant = FK N° de facture, FK = n° de client

J'espère que ta virgule est juste pour indiquer la séparation des colonnes dans l'identifiant et non une clef étrangère indépendante de la clef primaire. J'aurai plutôt mis un "+".
Autrement dit, la composante de la clef primaire est la concaténation des deux clefs étrangères. Ce qui implique qu'il y a une table père des "factures" ???
Je trouve cela bizarre d'avoir une table des "factures". Je ne confonds pas avec la table des "lignes détails" de la facture.

La seule façon d'avoir une facture multi-client, serait soit d'avoir plusieurs fois le même n° de facture dans la table facture ce qui est interdit et n'a aucun sens, soit d'avoir plusieurs colonne n° de client dans la table facture, ce qui est une hérésie d'un point de vue modélisation, et ne correspond à rien fonctionnellement.

La déclarative de la table "factures" laisse supposé que cela soit possible.
Il faut pour cela mettre en tant que clef primaire, le N° factures. Et mettre une FK vers la table clients. Oui, mais alors on n'a plus une relation identifiante.

A partir du moment où la facture qui bien évidement possède un n° unique (c'est d'ailleurs réglementaire) possède en clef étrangère comme je l'ai mentionné, le n° de client, il est impossible, et fort heureusement, d'avoir une facture multi-client.

La question qui est posée est de définir une "relation identifiante". C'est dans ce cas là que je me trouve.

Comment déclarer les identifiants des tables ?

D'une part, nous avons la table des "clients" :
--> table des "clients" : identifiant = N° client

et d'autre part, la table des "factures" :
--> table des "factures" : identifiant = N° facture

Ce descriptif n'est pas bon. Il n'y a aucune relation avec la table des "clients".

Mettre une clef étrangère ailleurs que dans la clef primaire, ne rend pas la relation identifiante.
--> table des "factures" : identifiant = N° facture ; FK = N° client.
(ici le point-virgule sert à indiqué que le N° client ne fait pas partie de l'identifiant).
Donc cette solution n'est pas bonne.

Mettre une clef étrangère dans la clef primaire rend la "relation identifiante" est correcte et c'est ce que l'on veut.
--> table des "factures" : identifiant = FK N° client + un numéro séquentielle ou une date.
Mais en même temps, je trouve cela absurde. Pourquoi ?

Car on accède à la facture, soit pas le N° facture qui est unique, soit par le N° du client qui n'est pas unique dans la table (plusieurs factures pour un même client).

Donc je mettrais plutôt comme clef primaire, le numéro de la facture qui est unique.
Et en tant qu'index unique, le couple (FK N° client ; numéro séquentielle ou date d'émission de la facture). Mais on n'a plus une relation identifiante.
En fait, c'est plus un problème Merise, qu'un problème de déclarative des bases de données.

Je sais que je sors du cadre de la définition demandée par Pierrot10 où nous sommes d'accord), mais j'aimerai savoir ce qui est le plus logique pour déclarer dans une base ce genre de problème ?

@+

[escartefigue]

Attention : il ne faut pas utiliser le mode citation tout en modifiant les propos, ça n'est pas correct

Je n'ai jamais écrit :



J'ai écrit la même phrase sans le FK et ça change tout !

Le n° de facture n'est pas une FK dans la table facture, mais la PK bien sur
FK c'est Foreign Key, clef étrangère donc, le n° de facture est bien évidemment l'identifiant de la table facture et donc la clef primaire (PK Primary Key)

Quand à cet extrait :

Car on accède à la facture, soit pas le N° facture qui est unique, soit par le N° du client qui n'est pas unique dans la table (plusieurs factures pour un même client).
Donc je mettrais plutôt comme clef primaire, le numéro de la facture qui est unique.

C'est exactement ce que j'ai écrit, et à plusieurs reprises

[Artemus24]

Salut Escartefigue.

Pris dans mon élan, j'ai modifié ta citation en te la réattribuant. Désolé.

Le n° de facture n'est pas une FK dans la table facture, mais la PK bien sur

Nous sommes d'accord sur ce point.

FK c'est Foreign Key, clef étrangère donc, le n° de facture est bien évidemment l'identifiant de la table facture et donc la clef primaire (PK Primary Key)

Cet clef primaire est un identifiant de la table facture, mais ne peut pas être une relation identifiante. Pourquoi ? Car il n'y a pas de relations et cela a son importance.

C'est exactement ce que j'ai écrit, et à plusieurs reprises

Oui, je le sais mais tu n'as pas réagit comme je le voulais.

A la question posée par Pierrot10, il demande ce qu'est une relation identifiante. Nous sommes d'accord sur la définition que tu as donnée :

C'est justement le principe d'une relation identifiante que d'hériter d'une clef étrangère comme composante de sa clef principale !

Or dans l'exemple donné sur la table des "factures", je considère que c'est une hérésie de créer comme clef primaire, une relation identifiante.
Cela n'apporte rien à la compréhension de ce modèle de représentation.
La bonne façon de faire est de créer :
--> une clef primaire ayant comme identifiant le N° de la facture.
--> une clef étrangère ayant comme identifiant le N° du client.
Enfin, dans ce cas-ci, c'est mon opinion.

Ainsi on peut accéder à la table des "factures", soit directement par le numéro de la facture, soit en faisant un balayage sur le numéro du client.
Ces deux modes d'accès répondent à un besoin fonctionnel.

Le balayage par le numéro du client doit se faire dans l'ordre inversée des factures émises, à savoir du plus récent au plus ancien.
Cela peut se traduire, soit par un numéro séquentiel (pas très parlant), soit par la date d'émission de cette facture (mieux adapté).

Dans 99% des cas, l'accès de fera par le numéro de la facture, à la demande du client qui possède déjà cette facture.
Dans le 1% des cas restant, c'est pour faire une recherche dans les archives.
Je ne voie pas trop l'intérêt dans ce cas précis de faire une relation identifiante.

Inversement, dans le cas du détail de la facture, alors là, oui, la relation identifiante à son utilité.
La clef primaire sera constitué d'une part de la FK N° facture et d'autre part, d'un numéro séquentiel désignant le rang du détail dans la facture.
D'où l'unicité de l'identifiant dans la table "détail facture".

C'est sur ces deux points dont j'aimerai avoir ton opinion.

@+

[escartefigue]

Or dans l'exemple donné sur la table des "factures", je considère que c'est une hérésie de créer comme clef primaire, une relation identifiante.
Cela n'apporte rien à la compréhension de ce modèle de représentation.
La bonne façon de faire est de créer :
--> une clef primaire ayant comme identifiant le N° de la facture.
--> une clef étrangère ayant comme identifiant le N° du client.

Mais lol c'est exactement ce que je dis depuis ma première réponse !
l'identification relative ne concerne pas dans mon exemple la table facture, mais la table lignes de factures !
J'ai l'impression que les vapeurs du réveillon de noel nuisent à la lecture de mes post Artemus

[Artemus24]

Salut Escartefigue.

Je ne dois pas être en phase !
J'ai dû un peu trop abuser de la dinde de Noël.
Ne te formalise pas trop, j'ai toujours eu des problèmes de compréhensions, et cela m'arrive assez souvent.

@+

[fsmrel]

Bonsoir,

J'ai du mal a comprendre exactement ces termes

one-to-one non-identifying relationship
one-to-many non-identifying relationship
one-to-one identifying relationship
one-to-many identifying relationship
many-to-many identifying relationship

Il faudrait que vous commenciez par éplucher le paragraphe 1 « Rappels généraux à propos de la modélisation des données » de l’article Modéliser les données avec MySQL Workbench , puis les paragraphes 5 et suivants.

Suite à cela, on voit bien que les concepts sont d’abord de niveau sémantique : dans le contexte Merise, on parle explicitement d’identification relative au stade du MCD (modèle conceptuel des données).

Je cite un des pères de Merise, Dominique Nanci (auteur de WinDesign), qui écrit dans Ingénierie des systèmes d'information, Merise Deuxième Génération :

« Toute entité type doit être dotée d’un identifiant [...] Certaines entités types ont par ailleurs une existence totalement dépendante d’autres entités types. On peut alors avoir recours à un identifiant relatif. »

L’exemple donné par escartefigue est caractéristique (disons canonique) de ce qui se passe lors du passage du MCD au MLDR (modèle logique des données relationnel) :

- table factures : identifiant = N° de facture
- table lignes de factures : identifiant = N° de facture + n° de ligne

La ligne de facture est identifiée relativement à une facture, le n° de ligne seul ne suffit pas, le n° de ligne seul peut provoquer des doublons

Pour sa part, notamment à cause du qualificatif « identifying » MySQL Workbench se dit relever des modèles EER (Extended Entity Relationship), ce qui est vrai en partie (car par exemple est passé sous silence le concept de généralisation/spécialisation, techniquement toutefois réalisable en SQL du fait de la possibilité « one-to-one identifying relationship » qui n’est du reste qu’un cas particulier de « one-to-many identifying relationship »).

la relation 'appartient à'.
Deux cas peuvent arriver, soit elle existe, soit elle n'existe pas.
Si elle existe alors on renseigne l'identifiant, si elle n'existe pas, l'identifiant prend la valeur nulle.

(1) La notion de « valeur nulle » est un non-sens. Null est seulement un moyen SQL, une marque, pour justement exprimer l’absence de valeur pour une colonne (reportez-vous à l’ouvrage The Relational Database Dictionary). En passant, tout le monde s’est gaussé à juste titre de l’erreur commise par ceux qui font la norme SQL quand ils ont écrit :

« The data type boolean comprises the distinct truth values True and False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value Unknown as the null value. This specification does not make a distinction between the null value of the boolean data type and the truth value Unknown that is the result of an SQL <predicate>, <search condition>, or <boolean value expression>; they may be used interchangeably to mean exactly the same thing. »

Comme le note malicieusement Peter Gulutzan (SQL-99 Complete, Really), selon la norme il revient au même de dire : « Je ne sais pas » et « Je sais que l’information est absente » !

(2) La notion d’« identifiant nul » est un contresens : du fait de leur définition les termes « identifiant » et « nul » sont contradictoires.

C'est à cause d'un identifiant nul que la relation est dite non identifiante.

En vertu de ce qui précède, ceci est un non-sens absolu. Une relation R entre une entité-type A (référençante) et une entité-type B (référencée) est non identifiante quand l’identifiant de B ne participe pas à l’identification de A.

[Artemus24]

Salut fsmrel.

Tu te fais rare dans ce forum. J'ai un grand plaisir à te lire. Merci pour la précision de tes remarques.

Je ne sais pas si j'ai mal cherché dans mes vieux bouquins consacrés à Merise, mais je n'ai rien trouvé sur la "relation identifiante".

Je cite un des pères de Merise, Dominique Nanci

Non, les pères de Merise sont René Coletti, Arnold Rochfeld et Hubert Tardieu.
Pour le tome 1 (Principes et outils) on retrouve bien ces trois auteurs.
Pour le tome 2 (démarche et pratiques), il y a en plus Georges Panet et Gérard Vahée.
Pour le tome 3 (gamme opératoire), il n'y a plus que Arnold Rochfeld et José Moréjon.

Ouvrages édités chez "les éditions d'organisations", en 1989 (tome 1), 1985 (tome 2) et 1989 (tome 3).
Seul Hubert Tardieu travaillait chez "sema metra" devenu par la suite "sema group".

Ce Dominique Nanci doit être un fils spirituel.

Comme le note malicieusement Peter Gulutzan (SQL-99 Complete, Really), selon la norme il revient au même de dire : « Je ne sais pas » et « Je sais que l’information est absente » !

Si nous nous trouvons dans une logique binaire, les seules réponses admissibles sont :
--> je sais et la réponse est VRAI (true).
--> je sais et la réponse est FAUX (false).
Quand on ne sait pas, on ne peut pas répondre par l'une de ces deux valeurs. Mettre NULL, pour reprendre ton expression, est un non-sens.

Dans une logique ternaire, la troisième valeur serait "inconnue". On peut alors s'imaginer que cela se traduise pas un "NULL".
En toute logique NON, car "inconnue" est synonyme d'indécidabilité et n'a aucun rapport avec l'absence de valeur.
Indécidabilité signifie que la réponse est ni VRAI, ni FAUX.

Le NULL a été inventé pour faire la distinction dans une variable numérique entre :
--> le zéro comme valeur renseignée et connue.
--> le zéro comme valeur par défaut, c'est-à-dire absence de valeur.

Le fait de ne pas savoir répondre à une question, ne signifie pas pour autant que la réponse est indécidable.
Mettre "NULL" signifie que je n'ai pas la valeur quand la question est posée, mais je sais qu'elle existe.
Autrement dit, l'état NULL est un état transitoire, à l'inverse de VRAI, FAUX et indécidable qui sont des états définitifs.

Pour moi, dire "je ne sais pas" est du domaine de l'indécidabilité.
Inversement, une information absente est juste le fait de dire que je ne l'ai pas en ma possession mais je sais qu'elle existe.
Ce qui n'est pas exactement la même chose en terme sémantique. D'où ma réaction !

@+

[fsmrel]

Bonsoir,

Non, les pères de Merise sont René Coletti, Arnold Rochfeld et Hubert Tardieu.
Pour le tome 1 (Principes et outils) on retrouve bien ces trois auteurs.
Pour le tome 2 (démarche et pratiques), il y a en plus Georges Panet et Gérard Vahée.
Pour le tome 3 (gamme opératoire), il y plus que Arnold Rochfeld et José Moréjon.

Je suis désolé, mais vous allez un peu trop vite en besogne. Certes, ces trois ouvrages de référence (parus respectivement en 1983, 1985, 1989) sont importants, ils ont permis au public de découvrir Merise, mais ils ont des prédécesseurs.

En réalité, après deux années de gestation, Merise est née officiellement en 1979, et voici son acte de naissance, la couverture du fascicule 4 (commis par le CTI, centre technique informatique du Ministère de l’Industrie), lequel est consacré à la modélisation des données et des traitements :





Bien entendu, de mon côté je possède ce fascicule (avec lequel j’ai appris à faire des MCD), ainsi que les ouvrages que vous citez, et dont j’ai annoté à peu près chaque page du 1er et du 3e tomes, au cours de ces 25 dernières années...

Cela dit, les travaux du CTI s’appuient sur ceux des précurseurs, à savoir la petite équipe d’Hubert Tardieu, au Centre d’Études Techniques de l’Équipement d’Aix (CETE), et dont faisait justement partie Dominique Nanci. Je vous renvoie au chapitre premier de « La méthode Merise, tome 1, principes et outils » : au paragraphe 1.3.2 « Deuxième génération (décennie 70) », on y lit ceci :

« Les principaux formalismes qui apparaissent, sont les suivants :

— le formalisme « Individuel » proposé par l’équipe d’Hubert Tardieu, formalisme repris dans la méthode Merise, objet de cet ouvrage ¹;

...

¹ Hubert Tardieu, Dominique Nanci, Daniel Pascot : Conception d’un système d’information : construction de la base de données, Les Editions d’Organisation, 1979. »

Par ailleurs, Arnold Rochfeld fait référence à un ouvrage (dont je ne dispose malheureusement pas), daté de 1975, dont les auteurs sont Tardieu, Heckenroth et Nanci : « Méthode, modèle et outils pour la conception de la base de données d’un système d’information », je vous renvoie aux page 22 et 263 du tome 3 dont vous faites mention (« La gamme opératoire »).



En complément, vous consulterez avec profit la FAQ Merise, dont j’extrais ceci :

« La recherche sous contrat (74 – 81)

Courant 74, le CETE d'Aix en Provence et l'Université d'Aix-Marseille s'associent pour présenter un projet de recherche auprès de l'I(N)RIA intitulé : « Méthode, modèles et outils pour la conception de la base de données d'un système d'information ».
L'équipe, placée sous la direction scientifique du Prof J.L. Le Moigne (qui vient d'inventer en 73 la notion de système d'information), est pilotée par Hubert Tardieu. Elle est composée au départ d'Henri Heckenroth et de Dominique Nanci. Au cours du projet, d'autres personnes rejoindront l'équipe, plus ou moins longtemps, dont : Daniel Pascot, Bernard Espinasse, Mokrane Bouzeghoub. »

Vous pourrez juger sur pièce des travaux de Dominique Nanci dans l’ouvrage dont il fut la cheville ouvrière, Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

Voici un extrait de la préface de cet ouvrage, par le Professeur Jean Louis Le Moigne et Hubert Tardieu :

« Le "noyau" de MERISE ne fut-il pas établi entre 1974 et 1978 par une équipe d'ingénieurs et de chercheurs aixois ⁽³⁾ : on vérifiera la pérennité de ce noyau en relisant le livre que publièrent en 1979, H. Tardieu, et D. Nanci et D. Pascot, que préfaçait Jean-Louis Le Moigne : "La conception du système d'information, construction de la base de données" (Ed. d'Organisation, Paris, 1979). Plus tard, avec le concours du ministère de l'industrie qui souhaitait disposer d'une méthode standard pour organiser les rapports contractuels entre l'administration et ses sous-traitants, fut développée MERISE à partir du "noyau" aixois.
...

⁽³⁾ - L'équipe d'Aix comprenait alors, sous la responsabilité conjointe de J.L. LE MOIGNE et de H.TARDIEU : D.NANCI, H.HECKENROTH, auxquels s'étaient joints D.PASCOT puis B.ESPINASSE. »

Ce Dominique Nanci doit être un fils spirituel.

Vu tout ce qui précède, je dirais plutôt qu'il fut un des pères spirituels...

Je viens de découvrir que l’ouvrage très complet de Dominique Nanci était téléchargeable, voyez ici.

Je ne sais pas si j'ai mal cherché dans mes vieux bouquins consacrés à Merise, mais je n'ai rien trouvé sur la "relation identifiante".

Dans le document résumant les travaux des merisiens en 1990 (Afcet – Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information » (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.), l’identifiant relatif est officiellement caractérisé par le fait qu’il « comprend » au moins une relation (association) :





Mais bien sûr, vous retrouvez le concept dans l’ouvrage téléchargeable de Nanci et Espinasse, à la page 130.

Voyez aussi l’ouvrage de Jean-Patrick Matheron, Comprendre Merise (12e tirage, en 2007), au chapitre IX, paragraphe IV.1 « Identification relative ».

Vous pouvez aussi fouiller chez developpez.com, j’y traite souvent de l’identification relative.

Le NULL a été inventé pour faire la distinction dans une variable numérique entre :
--> le zéro comme valeur renseignée et connue.
--> le zéro comme valeur par défaut, c'est-à-dire absence de valeur.

NULL a été inventé par Chamberlin et son équipe et ne correspond pas à cette affaire de zéro. Je vous renvoie à SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control, Chamberlin & al, 1976. Chamberlin y présente les tables de vérité de la logique ternaire qu’il utilise pour SQL (en se plantant, en assimilant Null à une valeur, mais depuis il a fait son aggiornamento) :




Avec cette logique trivaluée, il y a des évidences, des tautologies qui n’en sont plus, telle celle-ci : SI p ALORS p au cas où p est inconnu. Par exemple : « Si je chante alors je chante » peut poser problème. Même chose pour une contradiction telle que p ET NON p : « Je chante et je ne chante pas » n’est plus une contradiction. De la même façon, dans le cas du biconditionnel, p SI ET SEULEMENT SI p, on retrouve les mêmes problèmes : « Je chante si et seulement si je chante » n’est plus une tautologie.

Ted Codd a été plus loin, en passant à une logique quadrivaluée , voyez The Relational Model for Database Management, Version 2 aux paragraphes 8.9 et 8.10.


Incidemment, la logique quadrivaluée de Codd pose aussi bien des problèmes car, entre autres, des lois fondamentales telles que les lois de De Morgan sont mises en échec :

¬(p ET q)

et

¬p OU ¬q

ne sont plus des formules équivalentes : si p et q prennent respectivement les valeurs de vérité APPLICABLE et INAPPLICABLE, la 1re expression sera évaluée à INAPPLICABLE tandis que la 2e sera évaluée à APPLICABLE. De la même façon, l’équivalence suivante ne vaut plus :

∀x (p) ≡ ¬∃x (¬p)

Ou, si vous préférez, "Tous les hommes sont mortels" n’est plus équivalent à "Il n’existe pas d’homme non mortel".

En passant, le théorème de Heath est mis en échec, alors qu’il est au cœur de la théorie de la normalisation...

Etc.

Lisez attentivement l'ouvrage de Codd...

[Artemus24]

Bonjour fsmrel.

Ouah, impressionnant sont vos connaissances !

J'ai en effet, consulté le tome 1 de Merise et en bas de page 27, je retrouve bien la référence que vous nous avez indiqué.
Pourtant en page 6, là où il y a les remerciements, aucune référence à M. Dominique Nanci. Je reproduis ci-après cette page :

Le présent ouvrage ne serait pas ce qu'il est si, en 1977 et en 1978, ne s'était pas réalisé le projet MERISE.
Certes, certaines propositions qui y figurent avaient été formalisées auparavant.
Ceci est particulièrement vrai en ce qui concerne la modélisation des données. Même dans ce cas la confrontation d'idées à laquelle il a donné leu a son bénéfice.
Les auteurs tiennent donc à remercier plus particulièrement H. HECKENROTH, G. PANET, G. VAHEE, de l'ex-équipe de Projet pour leur contribution à l'élaboration de la méthode MERISE.
En ce qui concerne l'ouvrage proprement dit, il doit beaucoup aux amicales mais néanmoins fructueuses discussions avec J.L. LE MOIGNE, ainsi qu'aux soins qu'ont apporté à sa relecture M. BOUZEGHOUB, K. CROCHART, G.PANET, E. PICHAT, M.SCHOUHMANN.
Le texte de la deuxième édition a bénéficié des critiques constructives de J.L. LE MOIGNE et Y. TABOURIER

J'ai téléchargé l'ouvrage que vous nous donnez en référence. Je le lirai plus tard.

Vous pouvez aussi fouiller chez developpez.com, j’y traite souvent de l’identification relative.

Je tiens à porter à votre connaissance que je ne suis pas à l'origine de cette demande.
Mais bon, rafraîchir ses connaissances n'est pas un mal en soi, surtout par un maître Capelovici de votre envergure.

NULL a été inventé par Chamberlin et son équipe et ne correspond pas à cette affaire de zéro.

Votre érudition est bien plus grande que la mienne sur ce sujet et je ne mettrais pas votre parole en doute.
Mais aussi loin que remonte mon souvenir, on m'a présenté l'utilité du NULL, par l'exemple où l'on désire faire la distinction entre le zéro (valeur par défaut que l'on met quand on ne sait pas comment renseigner la valeur) et le zéro (comme valeur connue).
NULL n'est pas une valeur mais juste une façon d'indiquer l'absence de valeur.

Chamberlin y présente les tables de vérité de la logique ternaire qu’il utilise pour SQL

Je ne suis pas d'accord. SQL est une logique binaire parce que NULL n'est pas une valeur.

(en se plantant, en assimilant Null à une valeur, mais depuis il a fait son aggiornamento)

Toute l'ambiguïté réside dans le rôle que doit jouer ce NULL dans SQL.
Il a, selon moi, plus le comportement de l'élément neutre, comme à l'instar du zéro dans l'addition et du '1' dans la multiplication.
Rien à voir avec l'indécidabilité dont je parlais dans mon message précédant.

@+

[fsmrel]

Bonsoir et bonne année !

J'ai en effet, consulté le tome 1 de Merise et en bas de page 27, je retrouve bien la référence que vous nous avez indiqué.
Pourtant en page 6, là où il y a les remerciements, aucune référence à M. Dominique Nanci.

Ce qui n’enlève rien aux mérites de Dominique Nanci, suite à ses travaux précurseurs en compagnie de Jean-Louis Le Moigne, Hubert Tardieu, Daniel Pascot, Henri Heckenroth et Bernard Espinasse.

NULL n'est pas une valeur mais juste une façon d'indiquer l'absence de valeur.

Plus précisément, comme je l’ai écrit dans le post #13, Null est en fait une marque pour exprimer l’absence de valeur. Pour approfondir, je vous renvoie à l’ouvrage de C.J. Date, SQL and Relational Theory.

SQL est une logique binaire parce que NULL n'est pas une valeur.

Je traduis ce qu’écrit C.J. Date, page 120 de l’ouvrage dont je viens de faire mention :

« La notion de null, telle qu’on la comprend en SQL conduit inévitablement à une logique dans laquelle il y a trois valeurs de vérité au lieu de deux. »

Je vous renvoie au tables de vérité présentées par Don Chamberlin, père de SQL (cf. une fois de plus le post #13) à l’occasion de la publication en 1976 de l’article SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control. Ces tables de vérité sont bien relatives à une logique non pas binaire, mais bien ternaire. En revanche, la logique sur laquelle se base le modèle relationnel de données est binaire.

Que vous soyez d'accord ou pas, SQL est basé sur une logique ternaire.

Toute l'ambiguïté réside dans le rôle que doit jouer ce NULL dans SQL. Il a, selon moi, plus le comportement de l'élément neutre, comme à l'instar du zéro dans l'addition et du '1' dans la multiplication.

Null est une marque dont l’utilisation a pour conséquence la mise en oeuvre nécessaire d’une logique ternaire. Quant à l’élément neutre, dans le modèle relationnel de données, il a pour nom TABLE_DEE. Si R est une variable relationnelle (table en SQL pour faire court), on a :

R TIMES TABLE_DEE = R

TABLE_DEE est une relation, une constante unique, à un tuple (ligne) et zéro attribut (colonne).

Son camarade de jeu inséparable s’appelle TABLE_DUM et se comporte ainsi :

R TIMES TABLE_DUM = TABLE_DUM

TABLE_DUM est une relation, une constante unique, à zéro tuple et zéro attribut.

TABLE_DEE et TABLE_DUM peuvent être respectivement interprétés comme le VRAI et le FAUX.

Les deux comparses doivent vous rappeler ceux-ci :

[Artemus24]

Salut fsmrel.

Vous dites :

Plus précisément, comme je l’ai écrit dans le post #13, Null est en fait une marque pour exprimer l’absence de valeur.

Donc ce n'est pas une valeur ! Est-ce bien cela ?

Alors quand tu reprends cet extrait :

« La notion de null, telle qu’on la comprend en SQL conduit inévitablement à une logique dans laquelle il y a trois valeurs de vérité au lieu de deux. »

ne voyez-vous une contradiction ?
Si ce n'est pas une valeur, cela ne peut pas être un composant d'une table de vérité d'une logique dite ternaire.

Ces tables de vérité sont bien relatives à une logique non pas binaire, mais bien ternaire.

Non, pas d'un point de vue mathématique.

Quand tu parles de négation, cela à un sens dans une logique binaire, mais pas dans une logique ternaire.
Quand tu écris NON NULL = NULL on se retrouve dans une contradiction où une valeur est égale à son contraire.
Et de ce fait, NULL est une valeur indécidable dans l'acceptation de la logique ternaire.
Or NULL n'est pas une valeur mais juste une marque pour signaler l'absence de valeur.
Nous sommes bien dans une logique binaire où tout simplement le NULL est ignoré.

Je ne connais aucun exemple dans les SGBD, qui retourne comme résultat un NULL. C'est normal, ce n'est pas une valeur.
Mais inversement si tu le considères comme une valeur que je qualifie de particulière, alors OUI. Exemple : 'IF toto IS NULL'.

D'où NULL est ambiguë ! Selon l'usage que l'on en fait, il est une marque ou une valeur.

@+

[fsmrel]

Bonsoir Artemus24,

ne voyez-vous une contradiction ?
Si ce n'est pas une valeur, cela ne peut pas être un composant d'une table de vérité d'une logique dite ternaire.

Pas d’amalgame ! Dans la logique trivalente (ternaire) à laquelle on s’intéresse, les valeurs de vérité sont au nombre de trois : vrai, faux, inconnu et donnent lieu aux tables de vérité suivantes :

NON     |                    ET      | vrai    | inconnu | faux           OU      | vrai    | inconnu | faux
--------+--------            --------+---------+---------+------          --------+---------+---------+-----
vrai    | faux               vrai    | vrai    | inconnu | faux           vrai    | vrai    | vrai    | vrai
inconnu | inconnu            inconnu | inconnu | inconnu | faux           inconnu | vrai    | inconnu | inconnu
faux    | vrai               faux    | faux    | faux    | faux           faux    | vrai    | inconnu | faux

J’insiste : vrai, faux, inconnu sont des valeurs, celles du type « valeur de vérité » et la valeur de vérité d’une expression logique est donc une de ces trois valeurs. Null est évidemment exclu des tables de vérité.

Ce n’est qu’en fonction du résultat (vrai, faux, inconnu) de l’évaluation d’une expression logique que SQL décidera de marquer une cellule de table à Null ou pas : si le résultat a la valeur inconnu, alors pour chaque colonne de la table partie prenante, les lignes concernées seront marquées Null (par exemple, avec DB2 for z/OS, au niveau physique, sous le capot, pour chaque colonne non déclarée NOT NULL, un octet supplémentaire est affecté à cette colonne et vaut X'00' si une valeur est présente pour cette colonne, et vaut X'FF' sinon (marquage Null)).

Prenons le cas de la base de données fournie par C.J. Date dans tous ses ouvrages, depuis 1975. Cette base de données contient notamment une table des produits, dans laquelle, pour les besoins de la cause, j’ai supprimé l’option « NOT NULL » pour la colonne Weight (Chris ne m’en voudra pas ) :

CREATE TABLE P
(
        Pno     CHAR(3)         NOT NULL
      , Pname   VARCHAR(16)     NOT NULL
      , Color   VARCHAR(16)     NOT NULL
      , Weight  DECIMAL(5,1)
      , City    VARCHAR(16)     NOT NULL
    , CONSTRAINT P_PK PRIMARY KEY (Pno) 
) ;

Le jeu d’essai :

INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P1', 'Nut',   'Red',   12.0, 'London') ;
INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P2', 'Bolt',  'Green', 17.0, 'Paris') ;
INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P3', 'Screw', 'Blue',  null, 'Oslo') ;
INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P4', 'Screw', 'Red',   14.0, 'London') ;
INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P5', 'Cam',   'Blue',  12.0, 'Paris') ;
INSERT INTO P (Pno, Pname, Color, Weight, City) VALUES ('P6', 'Cog',   'Red',   19.0, 'London') ;

Soumettons la requête suivante, « Sélectionner tous les produits dont le poids est connu pour ne pas être égal au poids des produits stockés à Oslo » :

SELECT P.*
FROM   P
WHERE P.Weight NOT IN (SELECT P.Weight
                       FROM   P
                       WHERE  P.City  = 'Oslo') ;

Cette requête comporte une sous-requête dont le résultat est marqué null : du point de vue de la logique trivalente, SQL infère (correctement !) que la valeur de l’expression correspondant à cette sous-requête est égale à inconnu. Le poids de chaque produit est ensuite évalué en fonction de cela, et, conformément aux tables de vérité, le résultat final est le suivant :

Pno    Pname    Color    Weight    City
---    -----    -----    ------  ------
Null   Null     Null     Null      Null
  

Non, pas d'un point de vue mathématique.

On est ici dans l’univers de la logique.

Quand tu parles de négation, cela à un sens dans une logique binaire, mais pas dans une logique ternaire.

Il faudra expliquer ça aux successeurs de Kleene et Łukasiewicz ! Pour sa part, Chamberlin n’a évidemment pas inventé la logique trivalente, il en a choisi une qui lui convenait.

Quand tu écris NON NULL = NULL on se retrouve dans une contradiction où une valeur est égale à son contraire.

Null n’est pas une valeur mais une marque. En revanche, en logique ternaire, la négation de inconnu est inconnu.

Pour changer de théoricien, voici un extrait de l’article Extending the database relational model to capture more meaning publié en 1979 par Ted Codd, père de la théorie relationnelle :

NOT(F) = T ; NOT(ω) = ω ; NOT(T) = F ;

Où F symbolise faux, T symbolise vrai et ω symbolise inconnu.

Voyez aussi ses tables de vérité, au paragraphe 8.9, « The Three-Valued Logic of RM/V1 » de son ouvrage The Relational Model for Database Management, Version 2.

Attention, quand il passe à la logique quadrivaluée, ça peut faire mal quand on n’est pas préparé, c’est du brutal...

Et de ce fait, NULL est une valeur indécidable dans l'acceptation de la logique ternaire.

Null n’est pas une valeur, mais une marque. A cette occasion, voyez ce que dit Codd à la page 172 (dernier paragraphe) de l’ouvrage auquel je viens de faire référence. Accessoirement, je rappelle que dans la soute, sur le disque, au niveau fichier donc, chaque colonne pouvant être marquée Null est accompagnée à cet effet d’un octet prenant la valeur X'00' ou la valeur X'FF' (cas de DB2 for z/OS, pour les autres SGBD, voir chez leur éditeur).

Mais inversement si tu le considères comme une valeur que je qualifie de particulière, alors OUI. Exemple : 'IF toto IS NULL'.

Null n’est pas une valeur, sinon on écrirait IF toto = NULL. Quant à IS NULL qu’il aurait été préférable syntaxiquement d’écrire IS_NULL(x), c’est un opérateur qui produit des valeurs de vérité. Par exemple, si toto = 3, alors « toto IS NULL » est égal à faux. Si toto est marqué Null, alors « toto IS NULL » est égal à vrai.

D'où NULL est ambiguë ! Selon l'usage que l'on en fait, il est une marque ou une valeur.

Au niveau du langage SQL, qu’on le veuille ou non, Null reste définitivement une marque.



En passant, saluez James de ma part.

[escartefigue]

NON     |                    ET      | vrai    | inconnu | faux           OU      | vrai    | inconnu | faux
--------+--------            --------+---------+---------+------          --------+---------+---------+-----
vrai    | faux               vrai    | vrai    | inconnu | faux           vrai    | vrai    | vrai    | vrai
inconnu | inconnu            inconnu | inconnu | inconnu | faux           inconnu | vrai    | inconnu | inconnu
faux    | vrai               faux    | faux    | faux    | faux           faux    | vrai    | inconnu | faux

J'avoue être complètement perdu par cette présentation : j'ai mis en couleur ce qui me semble faux, mais sans doute est-ce du au fait que je n'arrive pas à lire ce tableau
Quoi qu'il en soit vrai ou inconnu donne vrai et non inconnu

Le tableau ci-dessous me semble beaucoup plus facile à lire