Discussion :

[Deaf]

Bonjour,

je suis peu expérimenté en Base de données et j'aurais besoin d'un conseil.

Voilà mon cas :
j'ai une relation entre deux tables de type 0..1 / 1..1
Ce qui peut être par exemple une Personne et un Casier judiciaire.
On a bien qu'une Personne a au plus un casier et peut ne pas en avoir et un casier est attaché strictement à une personne.

J'aimerais connaître la conception la plus adaptée et la plus complète à cet exemple simple (avec les cascade, Foreign Key etc...).

Merci!

[CinePhil]

Tu as déjà fait la moitié du travail, il n'y a plus qu'à continuer...

Régle de gestion :

Une Personne a au plus un casier et peut ne pas en avoir et un casier est attaché strictement à une personne.

MCD :
Personne -0,1----Avoir----1,1- Casier judiciaire

Tables :
Personnes (P_Id, P_Nom, P_Prenom, P_DateNaiss, P_NumInsee, ...)
CasiersJud (CJ_Id, CJ_IdPersonne, ...)

Clés primaires soulignées et clé étrangère en italique.

[Deaf]

Ma question va peut être te paraître idiote, mais comment la base sait-elle qu'une Personne a au plus un Casier?

[Hatchepsout]

Ma question va peut être te paraître idiote, mais comment la base sait-elle qu'une Personne a au plus un Casier?

la combinaison de clé CJ_Id, CJ_IdPersonne va indiqué ca
par contre je pense que


Tables :
Personnes (P_Id, P_Nom, P_Prenom, P_DateNaiss, P_NumInsee, ...)
CasiersJud (CJ_Id, CJ_IdPersonne, ...)

que CJ_Id, CJ_IdPersonne toute cette combinaison soit la clé primaire de table CasiersJud



a ce que je connais c'est que pour une association portant un lien identifiant (1,1), la clé étrangère migrée fait partie de la clé primaire de la table dans laquelle elle migre

[CinePhil]

Comment la base sait-elle qu'une Personne a au plus un Casier ?

Exact, j'avais oublié de traiter ce détail dans mon schéma.

La combinaison de clé CJ_Id, CJ_IdPersonne va indiqué ça

CasiersJud (CJ_Id, CJ_IdPersonne, ...)

toute cette combinaison soit la clé primaire de table CasiersJud

Un casier n'appartiendra bien qu'à une seule personne mais rien n'interdit qu'une personne n'ait pas plusieurs casiers !
Exemple de données
CJ_Id / CJ_IdPersonne
1 / 1
2 / 2
3 / 1

Les trois couples sont différents et peuvent constituer une clé primaire mais la personne n° 1 a deux casiers !

Par contre, en gardant ma structure de départ, c'est à dire sans inclure la clé étrangère C_IdPersonne dans la clé primaire, et en ajoutant une contrainte d'unicité sur cette clé étrangère, on est sûr qu'une personne ne figurera qu'une seule fois dans la table CasiersJud et n'aura donc au plus qu'un seul casier judiciaire.

Code :

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

1
2
3
4
5
6
CREATE TABLE CasiersJud(
  CJ_Id INTEGER UNSIGNED NOT NULL PRIMARY KEY
  CJ_IdPersonne INTEGER UNSIGNED NOT NULL
...
  CONSTRAINT UNIQUE CJ_IDPersonne
...)

[Deaf]

Merci beacoup!

[fsmrel]

Bonsoir,

pour une association portant un lien identifiant (1,1), la clé étrangère migrée fait partie de la clé primaire de la table dans laquelle elle migre

Si le lien est identifiant, vous avez raison, mais ça n’est pour autant que la clé primaire doit être composée des deux attributs CJ_ID et CJ_IdPersonne.

Pour confirmer ce qu’écrit CinePhil, je rappelle que Deaf fait mention d’un lien 0..1 / 1..1, et le fait de faire entrer les deux attributs dans la composition de la clé revient à transformer le lien en 0..N / 1..1.

Le lien 0..1 / 1..1 formalise les deux règles de gestion suivantes :

R1. Une personne a au plus un casier judiciaire.

R2. Un casier judiciaire appartient à une seule personne.

Clairement, vous changez radicalement la règle R1. Passons maintenant à un peu de théorie, ça ne peut pas faire de mal.

Si au niveau conceptuel, l’entité-type CasierJud a pour attribut identifiant CJ_Id et pour autres attributs : attribut1, attribut2, ..., attributn, cela veut dire que pour une valeur de CJ_Id on ne peut pas avoir plus d’une valeur pour ces attributs.

Si l’on fait un détour par la théorie relationnelle, cela revient à dire qu’il existe les dépendances fonctionnelles (DF) suivantes :

DF11 : {CJ_Id} → {attribut1}
DF12 : {CJ_Id} → {attribut2}
...
DF1n : {CJ_Id} → {attributn}

Je rappelle à cette occasion ce qu’est une dépendance fonctionnelle au sens de la théorie relationnelle. C’est une instruction de la forme :

X → Y

où X et Y sont deux sous-ensembles d’attributs de l’en-tête d’une table, et répondant à la règle : pour une valeur de X, correspond exactement une valeur de Y, c'est-à-dire que si deux lignes ont la même valeur vx pour X, alors ils ont aussi la même valeur vy pour Y.

Au niveau tabulaire, considérons donc la table :

CasierJud (CJ_Id, CJ_IdPersonne, attribut1, attribut2, ..., attributn)

Étant donné qu’un casier judiciaire appartient à une seule personne (règle R2), outre les DF énumérées ci-dessus, il existe aussi la DF :

DF1 : {CJ_Id} → {CJ_IdPersonne}

Et comme une personne a au plus un casier judiciaire (règle R1), il existe en outre la DF :

DF2 : {CJ_IdPersonne} → {CJ_Id}

Il existe aussi notamment les DF (triviales) :

DF3 : {CJ_Id} → {CJ_Id}

DF4 : {CJ_IdPersonne} → {CJ_IdPersonne}

Comme l’explique CinePhil, si vous retenez la paire {CJ_Id, CJ_IdPersonne} pour être clé, cela veut dire que vous établissez les DF suivantes, entre autres :

DF21 : {CJ_Id, CJ_IdPersonne} → {attribut1}
DF22 : {CJ_Id, CJ_IdPersonne} → {attribut2}
...
DF2n : {CJ_Id, CJ_IdPersonne} → {attributn}

Ainsi que les DF triviales (« Le tout détermine la partie ») :

DF31 : {CJ_Id, CJ_IdPersonne} → {CJ_Id}
DF32 : {CJ_Id, CJ_IdPersonne} → {CJ_IdPersonne}

Passons à la définition de la clé : c’est un sous-ensemble d’attributs K de l’en-tête d’une table T, respectant les deux contraintes suivantes :

(a) Unicité. Deux lignes distinctes de T ne peuvent avoir même valeur de K.

(b) Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

La règle d’unicité signifie que quel que soit l’attribut A de T, on vérifie la DF : K → {A}.

La paire {CJ_Id, CJ_IdPersonne} constitue-t-elle une clé ? Du fait de l’existence des DF : DF21, .., DF2n, DF31, DF32, on conclut qu’elle respecte la règle d’unicité. Mais elle ne respecte pas la règle d’irréductibilité, puisqu’elle contient un sous-ensemble strict {CJ_Id} qui vérifie lui aussi la règle d’unicité. Ceci est la conséquence des DF : DF1, DF3, DF11, ..., DF1n.

Par ailleurs, en tant que singleton,{CJ_Id} n’est pas réductible, sinon on vérifierait :

∅ → {CJ_Id},
∅ → {CJ_IdPersonne},
∅ → {attribut1},
...
∅ → {attributn}.

Le singleton {CJ_Id} est donc clé de la table CasierJud, ce qui n’est pas le cas de la paire {CJ_Id, CJ_IdPersonne}, qui a le droit seulement au statut de surclé parce qu’elle vérifie au moins la règle d’unicité.

A son tour, le singleton {CJ_IdPersonne} est-il clé lui aussi ? La réponse est affirmative. En effet, du fait de la DF : DF2, par transitivité {CJ_IdPersonne} détermine fonctionnellement chaque attribut de la table, donc vérifie la règle d’unicité, et est irréductible, pour les mêmes raisons que {CJ_Id}.

On a donc deux clés, ce que CinePhil a très justement exprimé en termes SQL :

Code :

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

1
2
3
4
5
6
CREATE TABLE CasiersJud(
  CJ_Id INTEGER UNSIGNED NOT NULL PRIMARY KEY
  CJ_IdPersonne INTEGER UNSIGNED NOT NULL
...
  CONSTRAINT UNIQUE CJ_IDPersonne
...)

Maintenant, si l’attribut CJ_Id est artificiel, il fait double emploi et n'offre pas de valeur ajoutée. Un coup de rasoir d’Ockham s’impose, il doit disparaître. L’instruction devient alors la suivante :

Code SQL :

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

1
2
3
4
CREATE TABLE CasiersJud(
  CJ_IdPersonne INTEGER UNSIGNED NOT NULL PRIMARY KEY
...
...)

Pour la forme, ajoutons la contrainte référentielle permettant de faire le lien entre les deux tables (c'est la valeur ajoutée de l'attribut CJ_IdPersonne) :

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE CasiersJud(
  CJ_IdPersonne INTEGER UNSIGNED NOT NULL PRIMARY KEY
...
  Constraint CasierFK Foreign Key (CJ_IdPersonne) 
         References PERSONNES (P_Id)
...)

[CinePhil]

Effectivement, je n'avais pas pensé au coup de rasoir sur la clé CJ_Id, trop habitué que je suis de partir d'entités avec un identifiant pour clé primaire...

D'ailleurs, à ce propos, puisqu'on opère au final un coup de rasoir, si on fait le chemin inverse MPD > MLD > MCD, on se retrouve avec une entité CasiersJud sans clé primaire !
Est-ce correct d'avoir dans un MCD une entité sans clé ?
Aurait-on pu directement détecter ça des cardinalités de l'association entre Personnes et CasiersJud et supprimer la clé directement dans le MCD ?
Comment se comportent les logiciels de modélisation qui automatisent le passage du MCD au MLD si on ommet une clé primaire dans une entité du MCD ?

[fsmrel]

Bonsoir,

[...]puisqu'on opère au final un coup de rasoir, si on fait le chemin inverse MPD > MLD > MCD, on se retrouve avec une entité CasiersJud sans clé primaire !

1) Le MPD est étranger à tout cela (même si un AGL comme Power AMC mélange MPD et MLD, c'est-à-dire fer à souder et logique des prédicats).

2) L’entité-type CasierJud a bien un identifiant (plutôt qu’une clé primaire, concept du niveau SQL). Cet identifiant n’est pas représenté par son nom sur le graphique, mais au moyen d’un artifice tel que la mise entre parenthèses de la cardinalité 1,1 (Power AMC) ou bien l’ajout de la lettre 'R' à la suite de la cardinalité (Win’Design), etc.

3) On conclut que CasierJud est une entité-type faible, donc identifiée relativement à l’entité-type Personne.

Partons du MLD :



Si on utilise Power AMC, la rétroconception donne lieu au MCD :



Et je suppose que Win’Design produira le MCD :

Est-ce correct d'avoir dans un MCD une entité sans clé ?

Si l’entité-type est forte, ne pas la doter d’un identifiant est une erreur, et les AGL comme Power AMC et Win’Design refuseront de générer le MLD. Si elle est faible, elle hérite de l’entité-type dont elle dépend. Si la cardinalité du côté de l’entité-type forte est 0,1, on en reste là (comme dans notre cas). Si cette cardinalité est 0,N, alors il faudra compléter l’identifiant de l’entité-type faible, pour garantir la règle de l’unicité. A cet effet, on dote l'entité-type d'un attribut identifiant (relatif).