Discussion :

[seabs]

Bonjour,

Je fais la mise en place d'une petite prévision de trésorerie. Pour cela, au niveau du MPD, j'ai deux entités

BANQUE(Banq_Init, Banq_Desig, Banq_No, etc)
ECRITURE(Ecrit_Id, Ecrit_Date, Ecrit_Lib, Ecrit_Valeur, etc, #Banq_Init)

Les règles de gestion sont :
R1 - Chaque compte en banque est identifiée par plusieurs lettres, en principe les initiales du nom. En cas de doublons, deux comptes à une même banque, les initiales seront complétées par un numéro d'ordre. Exemple SG_1, SG_2 pour Société Générale
R2 - Chaque écriture comporte un numéro d'ordre et doit obligatoire être rattachée à un compte en banque

Les autres règles n'ont pas d'influence sur ma difficulté

Jusqu'ici, tout va bien mes tables sont normalisées en BCNF voire plus.

Si nous passons au niveau de la quincaillerie comme nous le dit gentiment fsmrel, plusieurs intervenants de ce forum indiquent qu'il est préférable d'utiliser, dans une jointure, une clé numérique. Or la clé de l'entité BANQUE est alphabétique.

Dans une premier temps, j'ai envisagé d'ajouté une clé numérique à l'entité. Le schéma deviendrait :
BANQUE(Banq_Id, Banq_Init, Banq_Desig)
ECRITURE(Ecrit_Id, Ecrit_Date, Ecrit_Lib, Ecrit_Valeur, etc, #Banq_Id)

Après cette modification, mon entité BANQUE n'est plus en BNCF et même pas en 3NF, d'où des soucis en perspective car je n'ai plus aucun contrôle pour m'assurer qu'il n'existe aucun doublons dans l'attribut Banq_Init.

Code :

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

1
2
3
4
5
6
  Banq_Id    Banq_Init          Banq_Desig            Banq_No
      1            SG_1          Société Générale    00051102675
      2            SG_2          Société Générale    00051102680 
  Ici, nous commettons une erreur
      3            SG_2          Société Générale    00051102685

Bien entendu, je peux mettre place, pour garantir l'unicité, une clé alternative ou un trigger

Avez-vous une solution différente à me proposer pour répondre à la règle de gestion, respecter la normalisation et ne pas pénaliser l'exécution.

D'avance merci

[fsmrel]

Bonjour seabs,

C'est un plaisir de vous retrouver !

Bien entendu, je peux mettre place, pour garantir l'unicité, une clé alternative ou un trigger

Ben oui, une clé alternative suffit. Et si l’attribut Banq_No prend lui aussi des valeurs qui ne peuvent doublonner, il donnera naissance à une clé alternative. En SQL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE BANQUE
(
    Banq_Id        INT              NOT NULL,
    Banq_Init      CHAR(5)          NOT NULL,
    Banq_Desig     VARCHAR(32)      NOT NULL,
    Banq_No ...,
    Etc     ...,
  CONSTRAINT   BANQUE_PK     PRIMARY KEY (Banq_Id),
  CONSTRAINT   BANQUE_AK1    UNIQUE (Banq_Init),
  CONSTRAINT   BANQUE_AK2    UNIQUE (Banq_No) 
) ;

A cette occasion, je rappelle que dans la théorie relationnelle, il n’y a pas de clé privilégiée (primaire vs alternative), il n’y a que des clés :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
VAR BANQUE BASE RELATION 
{
    Banq_Id        INT,
    Banq_Init      CHAR,
    Banq_Desig     CHAR,
    Banq_No ...,
    Etc     ...,
}
KEY {Banq_Id}
KEY {Banq_Init}
KEY {Banq_No} 
;

Et du coup, vous pouvez vous rendre compte que la BCNF est respectée.

Je reste à votre disposition pour plus d'explications.

[dba01]

Bonjour.

Je ne comprends pas ces complications pour désigner un compte bancaire. Il suffit d'utiliser simplement le RIB, qui contient déjà banque+guichet+compte : pas de doublon possible et tout en numérique.
Seul le RIB international, appelé IBAN, contient de l'alpha. Mais toujours sans doublon possible au niveau mondial.

Ensuite, on a tout loisir d'attribuer un numéro d'ordre dans la compta de l'entreprise, un libellé alpha de la banque, du guichet, du type de compte, pour faire plus joli dans les restitutions, mais c'est une autre affaire.

Et c'est même récupérable pour envoyer des ordres de paiement normalisés.

.db.

[seabs]

Bonjour,

Je remercie fsmrel pour son aide immédiate et toujours très avertie.

Si j'avais été plus attentif lors de la lecteur de votre tutorial "Bases de données et normalisation" et du livre "Introduction aux bases de données de Chris J. Date 8ème édition", j'aurai trouvé la réponse à mes interrogations page 278 qui indique

Lorsqu'une entité possède deux clés candidates ou plus, il convient d'en retenir une comme clé primaire et les autres deviennent des clés alternatives.

C'est pourtant limpide

Il faut dire que j'ai encore quelques difficultés à éclaircir tout cela avec le noyau de quelques neurones qui restent actif dans mon cerveau.

Entre les dépendances fonctionnelles, les axiomes d'Armstrong qui présentent la réflexivité, l'augmentation, la transitivité, puis les règles de décomposition, union, pseudo-transitivité, composition.

A cela, il faut ajouter la fermeture des DF, plus l'algorithme du seau, la méthode pratique, etc.

J'ai fait quelques progrès, mais il reste surtout à ordonner tout cela dans ma petite tête.

J'ai acheté d'autres livres pour m'aider à comprendre. Par respect pour le travail fait je ne nommerai pas les auteurs, mais certains sont bâclés. Cependant, les erreurs qu'ils contiennent me permettre de comprendre par comparaison avec le livre de référence de Chris J. Date.

J'ai effectivement trouvé

Une relation est en FNBC si et seulement si :
- elle est en 3NF,
- aucun attribut faisant partie de la clé ne dépend d'un attribut ne faisant pas partie de la clé primaire.

Une relation ne possède pas de clé primaire, mais une ou plusieurs clés candidates.

Puis en appliquant cette définition à mon entité
BANQUE(Banq_Id, Banq_Init, Banq_Desig)
j'ai bien aucun attribut de la clé qui dépend d'un attribut ne faisant pas partie de la clé
{Banq_Id} --> {Banq_Init, Banq_Design}
Et pourtant, je ne respecte pas la BCNF.

Me dire si mon analyse est bonne ou si l'erreur provient de mon incompétence. Mes commentaires sont peut être brouillons.

Je considère mon problème est résolu.

Je ne clôture pas le sujet car j'ai un question à poser sur le n° du compte bancaire. Un point où je voudrais quelques éclaircissements. Je développerai ce point demain ou après demain

Encore merci et à bientôt.

[fsmrel]

Bonsoir,

J'ai effectivement trouvé

Une relation est en FNBC si et seulement si :
- elle est en 3NF,
- aucun attribut faisant partie de la clé ne dépend d'un attribut ne faisant pas partie de la clé primaire.
Une relation ne possède pas de clé primaire, mais une ou plusieurs clés candidates.

Puis en appliquant cette définition à mon entité
BANQUE(Banq_Id, Banq_Init, Banq_Desig)
j'ai bien aucun attribut de la clé qui dépend d'un attribut ne faisant pas partie de la clé
{Banq_Id} --> {Banq_Init, Banq_Design}
Et pourtant, je ne respecte pas la BCNF.

Il est un fait que l’auteur s’est lamentablement planté dans sa définition de la BCNF et vous a fait croire que votre table la violait. Il aurait dû commencer par lire l’ouvrage de Chris Date dont vous faites mention ⁽¹⁾. Il ne fait que répéter une ânerie (et malheureusement véhiculer, la preuve !) ce que lui ont enseigné d’autres prétendus experts en relationnel, sans qu’il cherche à vérifier la validité et les conséquences funestes d’une telle définition (remarquez que pendant quelques semaines, il y a de cela fort longtemps je fus aussi victime de cette ânerie...), et l’on peut craindre que ce ne soit pas la seule erreur qu’il ait proférée...

Si vous l’aviez suivi, vous auriez dû décomposer votre table BANQUE, « Ô tempo’a, ô mo’es » comme clamait la vigie après le passage d’Obélix et la décomposition de son bateau...

Vous avez trois clés candidates, {Banq_Id}, {Banq_Init}, {Banq_No} et selon la vraie définition de la BCNF, la table BANQUE est normalisée, allez en paix !

Et ne vous encombrez pas trop la tête avec les règles d’Armstrong et toutes ces sortes de choses, que j’ai fait figurer dans mon article à l’attention des plus jeunes, obligés de répondre aux questions de leurs professeurs, qui du reste, arrivent eux aussi facilement à se planter dans les calculs de couvertures irréductibles et autres joyeusetés...
_______
⁽¹⁾ De préférence dans la version originale, en anglais, car la traduction en français n’a pas été portée à la connaissance de Chris Date et contient quelques erreurs fâcheuses du genre :

Intégrité référentielle : aucun composant de la clé primaire d’une relvar de base ne peut admettre les nulls.

Alors qu’il fallait écrire : Intégrité d’entité au lieu d’intégrité référentielle...

[fsmrel]

Je ne comprends pas ces complications pour désigner un compte bancaire. Il suffit d'utiliser simplement le RIB, qui contient déjà banque+guichet+compte : pas de doublon possible et tout en numérique.
Seul le RIB international, appelé IBAN, contient de l'alpha. Mais toujours sans doublon possible au niveau mondial.

Oui, mais... J’ai passé 25 ans de ma vie à expertiser et soigner des bases de données dont les tables étaient dotées de clés (primaires pour parler SQL) dont les éléments (colonnes) étaient composées d’attributs si-gni-fi-ca-tifs faisant qu’à un moment on se trouve coincé, au point d’avoir à tout remettre à plat : EAN8 dans la distribution, matricule des employés du genre les deux premiers caractères représentent le code du département dans l’entreprise, numéro SIREN des entreprises, numéro de téléphone (à 8 chiffres à l’époque) chez les opérateurs, l’ISBN des ouvrages, etc.
Imaginez une table des automobiles pour laquelle l’identifiant est constitué du numéro d’immatriculation selon l’ancien système : que faire en cas de changement de ce numéro (suite à un changement de propriétaire) répliqué dans plusieurs tables ? Sans parler du passage au nouveau système d’immatriculation...

Je répète ce qu’écrivait il y a 25 ans le grand Yves Tabourier (De l'autre côté de MERISE) :

« ... la fonction d'une propriété est de décrire les objets (et les rencontres), alors que l'identifiant ne décrit rien. Son rôle fondamental est d'être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.

L'expérience montre d'ailleurs que l'usage des « identifiants significatifs » (ou « codes significatifs ») a pu provoquer des dégâts tellement coûteux que la sagesse est d'éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d'autres objets... »

Il est capital d’utiliser des identifiants qui soient invariants et non significatifs, donc qui ne concernent en rien l’utilisateur : les attributs (colonnes) qui en seront dérivés au niveau SQL ne serviront essentiellement que pour les opérations relationnelles (jointure par exemple), toutes choses qui se passent sous le capot. Les données naturelles : à un seul endroit dans la base de données.

Je reprends l’exemple que j’utilise invariablement :

Les concepteurs d’un projet d’une grande banque avaient retenu le numéro SIREN des entreprises pour identifier celles-ci (attribut NoSiren de l’entité-type Entreprise). Au niveau SGBD, par le jeu des liens inter-tables (clé primaire - clé étrangère), le numéro Siren se propageait dans de nombreuses tables. Or, ce numéro est fourni par l’INSEE, lequel envoyait tous les mois les correctifs modifiant le Siren des nouvelles entreprises (10% d’entre elles à peu près). Les concepteurs en avaient tenu compte et me montrèrent le modèle correspondant à la mise à jour des tables impliquées : une usine à gaz ! J’avais fait observer que, vu le nombre de tables touchées et leur volumétrie (plusieurs millions de lignes chacune), cela pouvait faire exploser la production informatique (batchs de nuit), du fait d’une activité de mise à jour excessive et en plus, délicate à ordonnancer. Sans que j'ai eu à le leur demander, les concepteurs définirent une nouvelle propriété, non porteuse d’information, artificielle (non significative) et invariante, destinée à être l’attribut composant la clé primaire de la table Entreprise, propagé en conséquence dans les autres tables, en lieu et place de l’attribut NoSiren. A partir de là, modifier un numéro de Siren n’impactait plus que la seule table Entreprise, les utilisateurs ayant bien évidemment toujours accès au contenu de l’attribut NoSiren, devenu clé alternative (et n’ayant donc pas perdu sa propriété d’unicité).

Même si on admet que la structure du numéro SIREN a peu de chances d’évoluer en tant que tel, les corrections apportées avaient de quoi ficher la zoubia dans le système.

Pour les RIB et les IBAN, même punition, même motif : « Chef ! on s’est trompé pour le RIB d’untel ! » Résultat : n tables à mettre à jour, parce que le RIB sert pour la clé primaire, les clés étrangères et tout le toutim. Non et non. Le défi à nouveau : si une donnée change de valeur, une seule modification, dans une seule table.

Ensuite, on a tout loisir d'attribuer un numéro d'ordre dans la compta de l'entreprise, un libellé alpha de la banque, du guichet, du type de compte, pour faire plus joli dans les restitutions, mais c'est une autre affaire.

Je note que seabs ne traite pas des comptes mais des banques. Mais peu importe, le problème de la « restitution » c’est effectivement une autre affaire, je dirais même que ça n’a aucun rapport avec ce qui nous concerne. Par exemple, une jointure naturelle de la table des comptes et de la table des banques pour récupérer le nom de celles-ci, c’est indépendant du système d’identification, sinon que l’identifiant de la table des banques lui aussi doit être non significatif et invariant.

[dba01]

Bonjour.
J'avais prévu un long discours pour vous contredire. Mais après tout ce ne serait que ma parole, sans plus.
Je dirais simplement : un compte (bancaire) ne se modifie pas, ce n'est pas une immatriculation. Par exemple : mon propre RIB ne correspond même pas à mon agence, ne correspond plus, car il n'a pas changé après mon déménagement.

Mais vous avez parfaitement le droit de ré-inventer la norme ISO.