Bonsoir,
Envoyé par
TheLeadingEdge
Je ne me rappelle pas avoir lu 1 définition plus précise faite par Codd ensuite. Mais ça ne veut pas dire qu'elle n'existe pas. FSMREL pourra sans doute nous en dire plus à ce sujet.
Extrait de E. F. Codd. “Further Normalization of the Data Base Relational Model”. IBM Research Report, RJ909, San Jose (August 31, 1971) :
1NF.jpg)
Vous retrouverez cette définition de la 1NF dans les commentaires de Date sur les écrits de Codd (à recopier avant que ça ne disparaisse...) :
Thirty Years of Relational: The First Three Normal Forms
Envoyé par
TheLeadingEdge
L'impact des FN sur le modèle EA est indiscutable. Il serait inconscient de ne pas les avoir à l'esprit lors de la modélisation conceptuelle, mais il faut se rappeler qu'elles ont été établies pour normaliser le modèle physique
Tout à fait d’accord. Sauf sur un point : la théorie de la normalisation relève de la logique formelle (voyez les travaux de Fagin, Casey, Ullman, Delobel et autres) et concerne donc le niveau logique, tandis que le niveau physique est concerné par le fer à souder.
Permettez-moi à ce sujet une incidente. Dans son ouvrage "Les machines à penser", Jacques Arsac écrit : « Dans le rapport qu’il écrivit à la demande du Premier ministre Pierre Mauroy, Maurice Nivat, un des meilleurs spécialistes mondiaux en informatique théorique, définit l’informatique comme la rencontre de la logique formelle et du fer à souder...»
Envoyé par
TheLeadingEdge
Si l'information est présente n fois, elle sera fausse n fois.
Une information présente n fois peut aussi être juste n fois, et pour citer Codd :
If something is true, saying it twice doesn’t make it more true.
Envoyé par
TheLeadingEdge
Quant au niveau physique c'est autre chose. S'il est issu de façon ''pure'' depuis un MCD/MLD il ne contiendra pas de données calculées
Quitte à me répéter, j'entends qu’algèbre relationnelle et calcul des prédicats ne sont pas du niveau physique.
Pour ma part je préfère écrire :
Quant au niveau logique, c’est autre chose. S'il est issu de façon ''pure'' depuis un MCD il ne contiendra pas de données calculées.
Cela dit, quelle stratégie adopter dans le contexte SQL ?
Utilisons par exemple MS SQL Server et définissons les tables suivantes :
Table Client (classique), issue du MCD.
Table ReglementUnitaire, contenant le détail des règlements effectués par un client et issue du MCD.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| Create Table Client
(
ClientId Int Not Null
, ClientNom Varchar(48) Not Null
, Constraint Client_PK Primary Key (ClientId)
) ;
Create Table ReglementUnitaire
(
ClientId Int Not Null
, ReglementDate Char(10) Not Null
, ReglementUnitaire Money Not Null
, Constraint RU_PK Primary Key (ClientId, ReglementDate)
, Constraint RU_Client_FK Foreign Key (ClientId)
References Client(CLientId)
) ; |
Ajoutons une table, appelons-la ReglementTotal, chargée d'héberger le montant total des règlements effectués par chaque client. Cette table n'est pas issue du MCD, elle est ajoutée par le DBA.
La première forme normale est scrupuleusement respectée, mais on a droit à une superbe redondance, puisqu’à tout moment, pour chaque client, la valeur prise par l’attribut ReglementTotal de la table ReglementTotal doit être égale à la somme des valeurs prises par l’attribut ReglementUnitaire de la table ReglementUnitaire.
1
2
3
4
5
6
7
8
9
| Create Table ReglementTotal
(
ClientId Int Not Null
, ReglementTotal Money Not Null
, Constraint RT_PK Primary Key (ClientId)
, Constraint RT_Client_FK Foreign Key (ClientId)
References Client(CLientId)
On delete Cascade
) ; |
L’enjeu est de faire en sorte que le SGBD garantisse à lui seul la cohérence du contenu des tables ReglementTotal et ReglementUnitaire, donc sans intervention de qui que ce soit.
En ce sens, on définira deux triggers. Le premier sera utilisé pour qu’à chaque fois qu’un client est créé, il y ait insertion d’une ligne dans la table ReglementTotal pour ce client, avec un montant à zéro :
1
2
3
4
5
6
7
8
| Create Trigger TotalInit On Client
After Insert
As Select CLientId
From Inserted
;
Insert Into ReglementTotal
Select ClientId, 0
From Inserted ; |
Le deuxième trigger permettra de synchroniser la table ReglementTotal sur la table ReglementUnitaire, à chaque fois que celle-ci sera mise à jour :
1
2
3
4
5
6
7
8
9
10
11
12
13
| Create Trigger TotalSynchro On ReglementUnitaire
After Insert, Update, Delete
As Select ClientId
From ReglementUnitaire
Update ReglementTotal
Set ReglementTotal =
(Select Sum (r.ReglementUnitaire)
From ReglementUnitaire r
Where ReglementTotal.ClientId = r.ClientId)
Where Exists (Select *
From ReglementUnitaire r
Where ReglementTotal.ClientId = r.ClientId
) ; |
Ce trigger reste à tester dans tous les coins, mais l’idée est là. Il est sans aucun doute améliorable, mais ceci est du ressort des pros de SQL.
A noter que si l’on veut que l’utilisateur n’ait pas connaissance de la table ReglementTotal, mais ait une vision globale des données des clients, il suffit de lui proposer une vue :
1
2
3
4
5
|
Create View LeClient (ClientId, ClientNom, ClientTotalReglement) As
Select x.ClientId, x.ClientNom, y.ReglementTotal
From Client As x Inner Join ReglementTotal as y
On x.ClientId = y.ClientId ; |
Envoyé par
TheLeadingEdge
il est admis que pour certaines raisons, de performance notamment, on puisse dénormaliser un modèle.
En tant que DBA, permettez-moi d’en douter, au moins au vu des aménagements que j’ai proposés pour ce cas particulier de redondance. Évidemment, reste à monter un prototype orienté performance, qui puisse infirmer ce que je j’ai proposé, mais ceci est autre histoire. Quant à la solution de rechange, je ne la vois pas.
Envoyé par
TheLeadingEdge
Je ne suis pas sur qu'1 entité LigneFacture se justifie.
On est au niveau MCD. L'association FACTURER est probablement de cardinalité n,n et deviendra 1 table (''LigneFacture'' si tu veux) au niveau physique.
Merci pour cette piqûre de rappel. Nous avons trop souvent tendance à mettre en œuvre une entité-type LigneFacture, mais il arrive que cela soit nécessaire, par exemple parce que la ligne de facture peut elle-même être décomposée en engagements sur ligne de facture et autres joyeusetés et en l’occurrence, il s’agit de respecter la 1NF...
propriété calculée dans un MCD et 1ere forme normale
Répondre avec citation
Partager