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.

[fsmrel]

Bonsoir,

J'avais prévu un long discours pour vous contredire

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

Je ne suis pas contre les débats contradictoires, au contraire, mais j’ai du mal à saisir ce sur quoi vous voulez apporter la contradiction.

En tout état de cause, la norme ISO, la pauvre, est complètement étrangère à cette affaire, et peu importe la structure du RIB tout comme celle du SIREN, de l'EAN8 ou de l'ISBN.

J’ai peur que vous n’ayez pas bien compris ce que j’ai essayé de vous expliquer. J’ai écrit que, à l’instar d’Yves Tabourier, je faisais soigneusement la part entre les attributs naturels tels que le RIB et les attributs techniques qui servent in fine pour les opérations relationnelles (qui sont du ressort de l’algèbre relationnelle), et en particulier pour l’opérateur par excellence, la jointure naturelle (JOIN).

Imaginez que, chez un marchand de biglotrons et autres curiosités, on ait une table des clients et une table des commandes passées par les clients.

Table des clients (dans le style de Tutorial D), qui possède deux clés distinctes, {ClientId} et {RIB} :

Code D :

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

1
2
3
4
5
6
7
8
9
BASE CLIENT RELATION 
{ClientId  INTEGER, 
 NomClient CHAR, 
 RIB       CHAR, 
 Adresse   CHAR,
 ...}
KEY {ClientId}
KEY {RIB} ;

Table des commandes, pour laquelle on a décidé que l’attribut ClientId participait à la clé primaire (et bien entendu à la clé étrangère) :

Code D :

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

1
2
3
4
5
6
7
8
9
10
BASE COMMANDE RELATION 
{ClientId     INTEGER, 
 CommandeId   INTEGER,
 CommandeNo   CHAR,
 CommandeDate DATE, 
...}
KEY {ClientId, CommandeId}
KEY {CommandeNo}
FOREIGN KEY {ClientId} REFERENCES CLIENT ;

Et soit un instantané de ces tables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CLIENT  ClientId  NomClient  RIB                      Adresse    ... 
        1         Mézig      00001000010000000000194  Clipperton  
        2         Tézig      12345000100123456789059  Yadupour
        ...       ...        ...                      ...

COMMANDE  ClientId  CommandeId  CommandeNo    CommandeDate  ...
          1         1           210-1234567   1988-07-14 
          1         2           317-3456789   1988-12-18  
          1         3           547-4702146   1989-02-15  
          2         1           110-1254897   1986-04-01  
          2         2           210-1235689   1988-07-31  
          ...       ...         ...           ...

Interrogeons maintenant la base de données :

Quelles sont les commandes du client dont le RIB est égal à 12345000100123456789059 ?

En Tutorial D :

Code D :

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

JOIN {CLIENT WHERE RIB = '12345000100123456789059', COMMANDE} {CommandeNo} ;

Ou en SQL :

Code SQL :

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

1
2
3
SELECT  y.CommandeNo
FROM    CLIENT AS x JOIN COMMANDE AS y ON x.ClientId = y.ClientId
WHERE   x. RIB = '12345000100123456789059' ;

Réponse :

110-1254897
210-1235689

Vous aurez remarqué que l'attribut RIB ne figure que dans la seule table CLIENT. Considérons maintenant la structure suivante pour les tables CLIENT et COMMANDE, avec propagation du RIB :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
BASE CLIENT RELATION 
{RIB        CHAR,
 NomClient  CHAR,
 Adresse    CHAR,  ...}
KEY {RIB} ;

BASE COMMANDE RELATION 
{RIB           CHAR,
 CommandeId    INTEGER,
 CommandeNo    CHAR,
 CommandeDate  DATE, ...}
KEY {RIB}
KEY {CommandeNo}
FOREIGN KEY {RIB} REFERENCES CLIENT ;

Certes, votre propre RIB n’a pas changé et cela montre votre fidélité à votre banque, mais il y a quand même des gens qui en changent, et imaginez, chez le marchand de biglotrons, le coût en conséquence des mises à jour de toutes les tables dans lesquelles figure le RIB : plus il aura été répliqué, plus le coût des mises à jour deviendra critique (essentiellement du fait des index). Le seul et mince avantage est que les requêtes se simplifient, puisqu’il n’y a plus besoin d’effectuer de jointure. Cela dit, le gain en performance est très minime, quoi qu’en disent depuis plus de trente ans ceux qui n’ont jamais mouillé leur chemise, passé des nuits à améliorer les performances des bases de données et qui oublient que ce sont les mises à jour qui posent des problèmes d'exploitation (voyez par exemple ici).

N.B.
Quand je parle des immatriculations ou des EAN8 et ISBN, j’espère que vous avez compris que je voulais dire que les bases de données ne sont pas faites que pour exploiter des RIB.

[seabs]

Bonjour,

Réponse à fsmrel

Je vous remercie pour votre aide, je pense avoir bien compris le principe de la normalisation jusqu'à la BCNF et même la 4NF. Il reste certainement des points d'incompétence, mais pour mes besoins pratiques cela me convient.

Pour votre remarque

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

Je vous rassure, je m'encombre pas la tête, mais j'aime bien comprendre et acquérir des connaissances. Comme il fréquent d'entendre tout et n'importe quoi, il vaut mieux posséder les connaissances pour se faire sa propre opinion.

Si je reprends l'exemple

Citation:
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.

Cette personne est chef de projet informatique à la Banque de France, responsable d'applications d'intelligence artificielle. Elle enseigne l'informatique au Conservatoire des Arts et Métiers de Poitou-Charentes. Il semble anormal que son ouvrage comporte plusieurs anomalies grossières. J'ai personnellement trouvé d'autres erreurs, alors que je suis qu'un débutant.

J'espère que son enseignement est plus rigoureux que son livre, qui pour moi me semble un travail bâclé sans aucun respect du lecteur.

Réponse à dba01.

Je vous remercie de vous intéressé à mon sujet. Sans entrer dans une discussion sans fin, je ferai deux remarques.

J'ai lu dans les nombreux ouvrages consultés que la clé primaire pour une table SQL ne devait jamais déprendre d'une source d'information susceptible de varier dans le temps. La standardisation du RIB d'aujourd'hui sera peut être changé demain.

Pour les normes, sujet que je connais parfaitement, je peux dire qu'elles ne sont jamais définitives et enregistrent régulièrement des ajouts, des modifications et des suppressions. Exemple la norme SQL, Comptables, Audit, Electrique, etc.

Après je ne vois pas la simplification en utilisant le RIB comme clé primaire par rapport à une clé auto-incrémentée. Le point essentiel c'est que la base de données soit normalisée avec des informations significatives et sans redondances. Le reste relève de l'appréciation personnelle.

J'aurai certainement encore des interrogations, mais grâce à ce forum nous pouvons progresser et apprendre.

[fsmrel]

Bonsoir,

Le point essentiel c'est que la base de données soit normalisée avec des informations significatives et sans redondances.

Je reformulerais cela ainsi :

Le point essentiel est que la base de données soit normalisée, donc sans redondances, que les données soient significatives ou non (ce dernier point est en effet indépendant de la normalisation des BDD).

Cela dit, l’objet de la normalisation des bases de données est de décomposer une relation (table) contenant des redondances, par application du théorème de Heath en ce qui concerne la BCNF, et des théorèmes de Fagin pour les 4e et 5e formes normales ; en fait cette normalisation constitue une branche des mathématiques appliquées. Je subodore un quiproquo par rapport à la normalisation au sens où l’entendrait dba01 : la norme ISO, la structure du RIB et autres, tout cela n’a rien à voir avec les théorèmes susmentionnés...

@ dba01

Vos interrogations ne seraient-elles pas la conséquence d’une acception différente du terme « normalisation », structurelle concernant le RIB et théorèmique concernant les bases de données ?

Comme disait Ted Codd, l’inventeur de la théorie relationnelle, la normalisation des relations (composant les bases de données relationnelles) n’a rien à voir avec la normalisation des relations Est-Ouest (on était à l’époque en pleine Guerre froide...) Ça sent le zeugma (comme disait Pierre Dac, « Mieux vaut s'enfoncer sans la nuit qu'un clou dans la fesse droite »...)

Pour les normes, sujet que je connais parfaitement, je peux dire qu'elles ne sont jamais définitives et enregistrent régulièrement des ajouts, des modifications et des suppressions. Exemple la norme SQL, Comptables, Audit, Electrique, etc.

Pour parler d’elle, la norme SQL évolue plein pot, mais pas toujours dans le bon sens, c’est le moins qu’on puisse dire. Quand je pense qu’on l’a échappé belle avec la gestion des données temporelles (fascicule 7, « TEMPORAL/SQL »), mais cette partie a heureusement été retirée à temps, fin des années quatre-vingt-dix, grâce à l’action énergique et convaincante des représentants du Royaume Uni, en la personne notamment d’Ed Dee, qui ont démontré que les propositions de normalisation étaient entachées d’erreurs sévères, voyez par exemple l’article de Hugh Darwen et C.J. Date, An Overview and Analysis of Proposals Based on the TSQL2 Approach pour les détails. Mais les affreux seraient bien capables de revenir par une porte dérobée, horresco referens...

Après je ne vois pas la simplification en utilisant le RIB comme clé primaire par rapport à une clé auto-incrémentée.

Attention, l’auto-incrémentation n’est pas la panacée, elle peut être source de contentions en mise à jour pour les applications de type conversationnel quand de nombreux utilisateurs sont actifs en même temps. A l’occasion de mes prototypages de performance, il m’est arrivé de devoir « hacher » les valeurs des clés, c'est-à-dire par un algorithme approprié, les remplacer par d’autres qui donnent lieu à une répartition complètement aléatoire, pour parvenir ainsi à éliminer les embouteillages. Ma préférence va l’a l’utilisation de timestamps (en l’occurrence, la date de création du tuple, calée sur la microseconde, voire plus fin, avec hachage bien entendu, ne serait-ce que pour arriver à ce que la valeur ainsi générée occupe un minimum de place, disons 4 octets).

Comme il fréquent d'entendre tout et n'importe quoi, il vaut mieux posséder les connaissances pour se faire sa propre opinion.

Je ne vous le fais pas dire. En tout cas, si vous souhaitez disposer de l’ouvrage de référence, n’hésitez pas à acquérir An Introduction to Database Systems de Chris Date, c’est dans les éditions successives de cet ouvrage que j’ai pratiquement tout appris de la théorie relationnelle, avant de soumettre celle-ci à l’épreuve du terrain. Il en existe une version française, mais qui comporte des coquilles fâcheuses (en plus, elle n’a pas été soumise à la relecture de Chris).

Cette personne est chef de projet informatique à la Banque de France

Bigre ! C’était bien la peine que je donne des cours dans cette noble et vénérable maison... Mais c’était il y a 23 ans, et peut-être n’avait-elle pas encore fréquenté la rue Croix-des-Petits-Champs...

[dba01]

Bonjour.

Je voulais seulement dire que je n'aavais fait qu'un bond en voyant ce schéma Client-->Banque-->Compte.
Ne confondez pas les références d'un client avec celles d'un paiement.
Même des paires Client-->Banque, ou Banque-->compte, ou Client-->compte, ou de simples "Banque_Id" : ça coince !
(BNP ou Parisbas ou BNP-Parisbas ?)
Le client a plusieurs banques, et plusieurs numéros de téléphone, et il en changera, ou peut-être pas, et les noms/groupes évoluent.
>>> La banque n'est pas une clef, et le RIB non plus d'ailleurs <<<

Un compte ne sert qu'à effectuer un paiement. Dans ce cas, comme chez vos fournisseurs habituels, EDF, Télécoms, Sécu, nationaux ou étrangers, etc... on vous demande OBLIGATOIREMENT un RIB ou un IBAN. L'avantage de ce machin est qu'il ne dépend pas de l'enseigne commerciale, qu'il est d'un format déterminé et universel, qu'il contient ses propres contrôles de cohérence (trois clefs numériques imbriquées), et qu'il ne tolère pas les doublons.
Des banques peuvent fusionner, des agences ou succursales changer de nom et d'adresse (ça m'est arrivé), le Crédit Lyonnais peut s'appeler LCL, le RIB reste la seule coordonnée utilisable pour toutes les entrées-sorties de fonds.
Un RIB n'est pas modifiable : on ferme un compte pour en ouvrir un autre, ici ou ailleurs. On peut aussi en avoir plusieurs, c'est mon cas.

Imaginez un peu que vous ayez comme client...TOTAL, même pour une opération insignifiante comme la fourniture de crayon noirs à toutes les succursales. Et réfléchissez un peu au nombre de coordonnées bancaires qu'ils peuvent utiliser dans le monde entier. Si pour vous UN client est dans UNE banque, vous êtes mal partis. Le compte de TOTAL New York sera peut-être chez la First National City Bk et en $US. Mais seulement pour les crayons, car pour les écrans plats ce sera chez BNP Paris et en Euros, d'ailleurs déjà référencé un peu plus loin pour autre chose. Alors ?
Et quand je travaillais à la Tréso (mais pas chez TOTAL), nous avions 50 comptes aux Etats Unis, mais dans moins de 50 banques.
S'il ne s'agissait que de VOS propres comptes, donc sur un seul client, alors vous pourriez noter les différentes banques. Mais on n'obtiendrait alors qu'un simple changement d'étage, et les banques seraient...des clients. On revient au départ !

Votre association Client-->Banque-->compte ne peut que vous apporter des problèmes. Le seul profil valable est Client-->facture-->RIB(IBAN). Si on change de commande, on change de RIB, ou peut-être pas. Un client a, a eu, ou aura, plusieurs RIB. Mais un RIB est à un client. Quant au nom ou adresse de la banque, c'est un détail sans la moindre utilité, pour faire joli et uniquement en interne. Après tout, qu'importe si le nom est faux, tant que le RIB est juste. A l'inverse, le RIB contient le code de la banque (et l'IBAN celui du pays), pour faire de l'affichage, et la liste n'est pas si longue.
Et si vous voulez prévoir les impayés sur compte fermés, ce sera "client+RIB" et non "client+banque".

C'est cette série Client-->Banque-->compte qui m'a accroché.
Et si la norme change, il y aura de l'embauche dans l'informatique, depuis la banque régionale DUCHMOLL jusqu'à la BRI (Banque des Règlements Internationaux). Vous n'allez pas vous en plaindre. Mais ce sera pire que le bug de l'an 2000 ! Imaginez : changer la finance mondiale.
Ca date de quand le RIB ? 30 ou 40 ans ? Plus vieux que vos langages !

Eventuellement, si vous avez la très bonne idée de m'envoyer un virement (mais si, mais si, c'est parfaitement autorisé), ne l'envoyez pas au code de mon agence, ce n'est pas celui qui figure dans mon RIB (500 Km d'écart). A moins de l'envoyer dans une enveloppe : alors ce sera bien la bonne adresse, mais mentionnez bien le RIB complet sinon...pas de compte.

Les comptes bancaires sont sources à emm...des.
J'ai essayé.
Méfiez-vous.
.db.

[seabs]

Bonjour,

Voilà comment en posant une question sur la normalisation, nous en sommes arrivés à parler de 50 comptes aux Etats-Unis.

Je rappelle que mon programme va traiter uniquement une prévision de trésorerie à 3 mois. Il s'agit de suppléer une carence de l'organisation actuelle. Il est fort probable que ce produit ne sera plus utiliser dans un délai de 12 à 24 mois lorsque nous aurons remplacé le logiciel comptable actuel par un produit plus conforme aux besoins de l'entreprise.

Si j'ai beaucoup à apprendre dans le domaine des bases de données, je suis plutôt à mon affaire dans l'organisation administrative des entreprises car il s'agissait d'une activité incluse dans le métier que j'ai exercé pendant 40 ans.

A toutes fins utiles, je vous signale que le produit développé est en phase de tests dans l'entreprise et qu'à priori, il répond aux besoins des utilisateurs.

@fsmrel

Cela dit, l’objet de la normalisation des bases de données est de décomposer une relation (table) contenant des redondances, par application du théorème de Heath en ce qui concerne la BCNF, et des théorèmes de Fagin pour les 4e et 5e formes normales ; en fait cette normalisation constitue une branche des mathématiques appliquées

Je subodore un quiproquo par rapport à la normalisation au sens où l’entendrait dba01 : la norme ISO, la structure du RIB et autres, tout cela n’a rien à voir avec les théorèmes susmentionnés...

Pour moi, il n'y aucune ambiguïté, je fais bien la distinction entre la normalisation appliquée aux bases de données et les normes qui sont validées par différents organismes ISO, AFNOR, etc.

Attention, l’auto-incrémentation n’est pas la panacée, elle peut être source de contentions en mise à jour pour les applications de type conversationnel quand de nombreux utilisateurs sont actifs en même temps. A l’occasion de mes prototypages de performance, il m’est arrivé de devoir « hacher » les valeurs des clés, c'est-à-dire par un algorithme approprié, les remplacer par d’autres qui donnent lieu à une répartition complètement aléatoire, pour parvenir ainsi à éliminer les embouteillages. Ma préférence va l’a l’utilisation de timestamps (en l’occurrence, la date de création du tuple, calée sur la microseconde, voire plus fin, avec hachage bien entendu, ne serait-ce que pour arriver à ce que la valeur ainsi générée occupe un minimum de place, disons 4 octets).

J'avais bien compris que l'auto-incrémentation ne répond pas tout. Pour ma part, les développements que je fais concernent des petites entreprises voir infiniment petites. En générale, le nombre d'utilisateurs se situe entre 5 et 10 personnes et encore très rarement en simultané. Il est certain que pour des accès importants, il faut posséder des techniques plus appropriées. Je n'avais pas réfléchi à la question, mais vous venez de me donner une réponse pour ma culture base de données.

Je ne vous le fais pas dire. En tout cas, si vous souhaitez disposer de l’ouvrage de référence, n’hésitez pas à acquérir An Introduction to Database Systems de Chris Date, c’est dans les éditions successives de cet ouvrage que j’ai pratiquement tout appris de la théorie relationnelle, avant de soumettre celle-ci à l’épreuve du terrain

Je possède la version française, vous m'avez d'ailleurs donné, dans un précédent message, les fautes graves que vous aviez identifiées. Je ne maitrise pas suffisamment l'anglais pour m'attaquer à la version originale.

Merci à vous deux pour vos interventions. Je considère ma demande comme résolue?

[fsmrel]

Bonjour,


@ dba01

Avec seabs, notre but n’était pas de modéliser les relations des entreprises (ou de celles de leurs clients) avec les établissements bancaires : ceci est le rôle des équipes fonctionnelles dans les entreprises, qu’elles s’appellent TOTAL, AXA, MICHELIN, DGI, etc., et fait l’objet du dossier de conception, validé par la MOE et la MOA. Pour notre part, nous nous situions au niveau de la base de données, à un stade où le fonctionnel est donc entériné et notre réflexion portait sur tout autre chose : une table réputée en BCNF peut elle violer celle-ci après ajout d’une clé ? Faut-il continuer à appliquer le théorème de Heath ?

seabs aurait très bien pu présenter ses structures de tables de façon plus abstraite, en sorte que l'émotion ne vienne pas polluer l'exposé :

T1 (A11, A12, A13, ..., A1n)
T2 (A21, A22, A23, A24, ..., A2m, #A11)

En précisant le cas échéant quels attributs sont artificiels ou naturels et autres particularités : la teneur de nos échanges (portant sur le besoin d'une clé supplémentaire) aurait été la même et vous vous ne seriez pas senti obligé d’intervenir. A combien de messages passionnés aurions-nous eu droit si, par exemple, thomine avait utilisé les termes "banque", etc. ?

Maintenant, rien ne vous empêche de rédiger un billet chez DVP, à l’intention des étudiants, pour les initier à la modélisation correcte des relations entre les banques, les clients, les comptes, les opérations, que tout cela vu soit du client soit de la banque, en précisant bien que vous situez au stade de l’architecture fonctionnelle et non pas de celle de la base de données. Les plus jeunes ont besoin de l'expérience des plus anciens.

Ca date de quand le RIB ? 30 ou 40 ans ? Plus vieux que vos langages !

C'est-à-dire ? Vous me rappelez un entretien à la TV entre André Frossard et un journaliste qui lui posait la question suivante :

« Maître, quels sont les rapports entre Science et Religion ? »

Réponse de Frossard :

« Ce sont les rapports qui existent entre la Compagnie du gaz et Léonard de Vinci. »

Cela dit, « mon langage », celui dont je me sers pour exprimer mes idées, pour ensuite les traduire en logique du 1er ordre façon Gottlob Frege (1848-1925), puis façon calcul de tuples (ou de domaines), puis en Tutorial D et le cas échéant en SQL (Sorry Query Language, langage hybride datant de 1975), est d’abord le français, en application de l’ordonnance de Villers-Cotterêts (1539), édictée par François Ier (RIP).

Pour moi, il n'y aucune ambiguïté, je fais bien la distinction entre la normalisation appliquée aux bases de données et les normes qui sont validées par différents organismes ISO, AFNOR, etc.

Je n’en ai jamais douté !

Merci à vous deux pour vos interventions. Je considère ma demande comme résolue ?

Sans problème. Et n’hésitez pas à poser d’autres questions, en précisant bien que l’on n’en est plus au stade fonctionnel...

[dba01]

Autrement dit : bien qu'utilisant le même Français, on ne parlait pas de la même chose.

J'ai dû rater une marche.
Veuillez m'excuser.
.db.

[fsmrel]

Bonjour Daniel,

Vous êtes tout excusé. Pour ma part j'aurais dû me rendre compte plus tôt du quiproquo.

Bonne route !

N.B. Pour ma part, mon RIB est toujours le même depuis quarante ans...