Concernant la table ARTICLE, pour la structure ci-dessous, pour 100 000 articles, la volumétrie avec DB2 est de l'ordre de 5,2 MO, ce à quoi on ajoute 1,2 MO pour l'index de clé {ArticleId} et 1,7 MO pour l'index de clé {ArticleCode}.
Il va falloir en acheter des articles pour occuper les 10 GO...
Envoyé par
RZinaoui
Pour la CIF on l'a jamais vu sauf en ACCESS mais, je crois que vous avez donné une autre méthode pour remédier à ce problème: pour un article et une demande donné il n’y a qu’un fournisseur.
La CIF n’est pas un concept ACCESS. La CIF (contrainte d'intégrité fonctionnelle) est un concept merisien depuis les années soixante-dix, alors qu’ACCESS est né dans les années quatre-vingt-dix et reste muet à son propos. Je n’ai pas donné d’autre méthode :
En Merise on résout le problème de la contrainte ARTICLE X DEMANDE -> FOURNISSEUR par le biais de la CIF (encore appelée DF (dépendance fonctionnelle) en Merise 2). PowerAMC ne connaît pas, mais WinDesign connaît parfaitement.
J’ai utilisé la représentation suivante :
Équivalente à celle-ci, plus dans le style de la FAQ Merise :
Exemple proposé par WinDesign :
MCD
MLD
Envoyé par
Kropernic
Autant la proposition de Tabourier, je la connais et la prêche comme un fervent défenseur, autant le théorème de Heath, je sais à quoi il sert mais de là à le connaître au sens mathématique, il y a un pas que je ne franchirais pas.
Maintenant, il fort possible que je l'applique de manière naturelle sans savoir qu'il s'agisse en fait de cela ^^
Pour une approche mathématique du théorème de Heath, je vous renvoie à Ullman (Principles of DATABASE SYSTEMS. Second Edition. (Computer Science Press. 1982).). L’application de ce théorème est quand même simple et ce qui est important c’est de s’en servir pour normaliser, c'est-à-dire éliminer certaines redondances et des anomalies de mise à jour.
Supposons par exemple que la table DEMANDE ait la structure suivante :
{DemandeId, FournisseurId, UtilisateurId, UtilisateurNom, DemandeDate}
Et qu’elle soit munie des dépendances fonctionnelles :
{DemandeId -> FournisseurId}
{DemandeId -> UtilisateurId}
{DemandeId -> UtilisateurNom}
{DemandeId -> DemandeDate}
{UtilisateurId -> UtilisateurNom}
{DemandeId} détermine fonctionnellement chaque attribut de la table : c’est donc une clé.
On observera que la BCNF est violée car il existe la DF {UtilisateurId -> UtilisateurNom} dont le déterminant {UtilisateurId} n’est pas clé, on applique donc le théorème de Heath à cette DF pour décomposer la table en :
R1 {UtilisateurId -> UtilisateurNom}
R2 {DemandeId, FournisseurId, UtilisateurId, DemandeDate}
Au besoin, par jointure de R1 et R2 on retrouve la table DEMANDE peccamineuse.
Envoyé par
RZinaoui
vous insistez trop sur le coté mathématique des choses (Algèbre relationnelle).
Vous oubliez que la normalisation est à considérer comme une branche des mathématiques appliquées... Cela dit, l’algèbre relationnelle n’est pas partie prenante dans les concepts structurels auxquels nous nous intéressons dans cette discussion : l’algèbre relationnelle est une collection non limitée d’opérateurs qui nous permettent d’utiliser des relations en tant qu’opérandes pour produire de nouvelles relations. L’opérateur JOIN nous permet par exemple de produire une relation par jointure de deux relations : par le mariage d’un papa relation et d’une maman relation, naît un bébé relation de même nature que ses parents et capable à son tour de procréer (principe de clôture algébrique, algebraic closure) :
Envoyé par
RZinaoui
Je vais brièvement rappeler les règles 2 et 4 de la normalisation qu'on a vues:
N°2: On dit que A est en dépendance fonctionnelle de B si pour toutes valeurs de B il existe une et une seule valeur de A.
Il faut que vous complétiez votre définition : Que sont A et B ici ? Il est nécessaire de préciser exactement ce dont on parle. A cette occasion voici la définition de la dépendance fonctionnelle dans son cadre naturel, c'est-à-dire la théorie relationnelle :
Une dépendance fonctionnelle (DF) est une expression de la forme
A → B dans laquelle le déterminant
A et le dépendant
B sont des sous-ensembles (au sens de la théorie des ensembles) de l’
en-tête d’une
relvar R donnée ; cette expression se lit «
B dépend fonctionnellement de
A » ou «
A détermine fonctionnellement
B ». La relvar
R satisfait à la dépendance fonctionnelle
A → B si pour chaque valeur légale de
R, lorsque deux
tuples ont même valeur pour
A alors ils ont aussi même valeur pour
B.
Exemple :
Partons de l’entité-type ARTICLE :
Et considérons la relvar ARTICLE qui en est dérivée :
{ArticleId INTEGER, ArticleCode CHAR, ArticleDesignation CHAR, StockInitialQte INTEGER, StockInitialDate DATE}
Cette relvar satisfait les dépendances fonctionnelles :
{ArticleId} → {ArticleId},
{ArticleId} → {ArticleCode},
{ArticleId} → {ArticleDesignation},
{ArticleId} → {StockInitialQte},
{ArticleId} → {StockInitialDate},
{ArticleCode} → {ArticleId},
{ArticleCode} → {ArticleCode},
{ArticleCode} → {ArticleDesignation},
{ArticleCode} → {StockInitialQte},
{ArticleCode} → {StockInitialDate},
{ArticleId, ArticleDesignation} → {ArticleDesignation},
{ArticleDesignation} → {ArticleDesignation},
{ArticleId} → {}
{} → {}
Et de très nombreuses autres !
Notez l’emploi des accolades, car une DF est un ensemble au sens de la théorie des ensembles.
Ce qui vaut pour les relvars vaut évidemment pour les tables SQL et pour les entités-types merisiennes (exception faite de celles qui sont identifiées relativement : voyez l'exemple des lignes de facture proposé par l'infatigable Krop : quand on remonte au niveau MCD, on doit constater que l'attribut FAC_ID ne fait pas partie de l'en-tête de l'entité-type LDF, un nombre élevé de DF ne peuvent donc pas être mises en évidence).
Envoyé par
RZinaoui
La DF directe: les attributs d'une entité doivent dépendre directement de sa clé primaire et non par l’intermédiaire d'une autre propriété
Faux. Le déterminant (la partie gauche de la DF, voyez ci-dessus) n’est pas nécessairement clé ! Voyez ici. En plus, si vous utilisez le terme « entité », alors il faut le remplacer par « type d’entité » (ou « entité-type ») : un type d’entité est à considérer comme une classe dont les instances sont des entités. Par ailleurs, soit vous utilisez le terme « attribut » soit le terme « propriété », mais pas deux à la fois. Attention à l’utilisation de l’expression « clé primaire » : si vous vous situez dans le contexte de Merise, alors il faut remplacer par « identifiant ».
=> La rigueur dans le vocabulaire est particulièrement importante dans la modélisation des bases de données.
Envoyé par
RZinaoui
La DF complète: les attributs d'une entité doivent dépendre de tout l'identifiant et non une partie de cet identifiant.
Cette fois-ci, vous vous placez clairement dans le contexte merisien puisque vous parlez d’identifiant. Même si entre nous, nous parlons des dépendances fonctionnelles, le problème est que les pères de Merise ne parlent pas des dépendances fonctionnelles entre attributs (ou plutôt propriétés) d’un type d’entité... Ils parlent seulement de DF entre types d’entités (revoyez la CIF ci-dessus).
Là encore il y a beaucoup de mélange. Notamment, on ne doit pas limiter le déterminant à l’identifiant (ou la clé...)
Envoyé par
RZinaoui
Les attributs d'une association doivent dépendre de tout l'identifiant de l'association (concaténation des identifiants des entités participant à l'association) et non une partie de cet identifiant.
En Merise, une association n’a pas d’identifiant ! Voici ce qu’écrivent les pères de Merise (ils utilisent eux aussi le terme « normalisation » mais qui a seulement un vague rapport disons avec la normalisation en 2NF) :
« La normalisation permet de s’assurer que chacune des propriétés ne peut être vérifiée sur un sous-ensemble de la collection de la relation-type »
Envoyé par
RZinaoui
J'attends votre opinion à ce propos, est-ce qu'elles sont similaires ou non parce que je ne suis pas arrivé à bien assimiler ce qui est expliqué dans les liens que vous m'avez laissé.
Hélas ! Les définitions que vous donnez sont incomplètes, non cohérentes, fantaisistes, voire fantaisistes, fausses... Dites-moi ce que vous n’avez pas compris, qu’on essaie de mettre la lumière...
@Les lions :
Plus généralement, pourriez-vous reformuler les questions quant aux points qui vous tracassent, car vous allez plus vite que la musique, il y a beaucoup de choses éparpillées dans la discussion et je ne suis pas chaud pour tout relire...
Répondre avec citation
Stock_IdRel_MCD.png)
Stock_IdRel_MLD.png)
Oracle_Refresh.png)
) ou non car j'ai commencé une auto-formation en sql server
. Mais il ne faut pas avoir 40 ans d'expérience dans le domaine pour se rendre compte que devoir parcourir l'historique complet de l'article pour connaître son stock actuel va prendre de plus en temps à la longue. Combien de temps, je l'ignore. C'est pourquoi je parlais de faire des tests, d'ajouter des indexes si possible et de retester. Le tuning est l'action, par exemple, d'ajouter des indexes pour améliorer l'efficacité des requêtes.
MLD_provisoire.png)
Articles_volumetrie.png)
CIF.png)
(CIF)2.png)
EntiteType_Article.png)
Demandes_MCD.png)
Demandes_ternaire_MCD.png)
Partager