Des dysfonctionnements oculaires
Bonsoir Daranc,
Vous écrivez
Citation:
je croyais apercevoir la lumière mais ce n'était qu'un dysfonctionnement oculaire
On sent comme une pointe d’amertume...
On va essayer de remédier à cela et de faire en sorte que le mirage se dissipe. Je vous ai demandé de vous rabattre sur le lien "hippique" ("Unicité d'une clef composée") parce que, à l’aide d’un exemple simple mais fort intéressant, on y a traité de la normalisation (par exemple mon message du 20/02/2007, 12h36) : définition des dépendances fonctionnelles, contraintes d’unicité et d’irréductibilité, clés candidates, surclés, forme normale de Boyce-Codd (BCNF), etc. On a montré pourquoi la table T (Jockey, Cheval, Course, Dossard) était en BCNF. Dans mon message du 21/02/2007, 01h09, j’ai rappelé la définition de la Première forme normale (1NF). J’ai mis en garde contre les définitions fantaisistes (21/02/2007, 12h49). J’ai aussi traité de la 2NF (24/02/2007, 00h18).
Recommencer tout cela au sein de la discussion " Dénormalisation de table. Quand ?" n’est pas très approprié, car si les concepts sont parfois évoqués (dépendance fonctionnelle), ils sont généralement omis et de toutes façons non formellement définis, tout devra être repris à zéro. D’autre part, le débat y est plutôt : faut-il dénormaliser ?
Citation:
je fait une très grave allergie à l'anglais
C’est bien dommage, car la littérature anglo-saxonne est très riche pour le sujet qui nous concerne (Codd, Fagin, Rissanen, Armstrong, Date, etc.)
Je vous rappelle qu’il existe une traduction en français de l’ouvrage de référence :
C.J. Date. Introduction aux bases de données, 8e édition (Vuibert)
http://www.amazon.fr/Introduction-ba.../dp/2711748383
Citation:
je ne vois pas trop comment un arrangement mathématique peut influer sur un stockage de données
Tout d’abord, ceux qui ont contribué à la théorie de la normalisation sont des mathématiciens. Même si tout y est en anglais, je vous conseille de visiter le site de Ronald Fagin (sans trop vous attarder quand même...), c’est édifiant.
http://www.almaden.ibm.com/cs/people/fagin/sigmod79.pdf
http://www.almaden.ibm.com/cs/people/fagin/
http://www.almaden.ibm.com/cs/people/fagin/papers.html
Quant aux conséquences sur le stockage de données, je commence par rappeler, comme je l’ai fait précédemment dans cette discussion, qu’il faut faire une distinction très nette entre le niveau logique et le niveau physique : l’indépendance du premier est totale par rapport au second.
A ce jour, on peut voir les choses ainsi, à l’aide d’un exemple très simple. Prenons celui des courses hippiques et considérons la table suivante :
Edition (Course_Id, Course_Date_Id, Course_Date, Temps_Vainqueur, Course_Nom, Course_Lieu)
La 2NF est violée (cf. la discussion sur ces courses, mon message du 24/02/2007, 00h18).
A l’instar du ver de terre, la table doit subir une scissiparité et donner lieu donc à deux tables, celles que l’on a définies dans ce même message et qui sont en BCNF, sachant que par jointure naturelle de ces deux tables, on retrouve la table délinquante, ni plus ni moins (par application du théorème de Heath, voir à la fin de ce message).
Course (Course_Id, Course_Nom, Course_Lieu)
Edition (Course_Id, Course_Date_Id, Course_Date, Temps_Vainqueur)
Si l’on fait référence aux Create Table (toujours mon message du 24/02/2007, 00h18), chaque tuple occupe ici respectivement 16 octets et 68 octets (je ne tiens pas compte des octets dont le système a besoin).
En supposant que les volumétries soient les suivantes :
Table Course, V1 : 10 000 lignes,
Table Edition, V2 : 1 000 000 lignes,
L’encombrement global logique est le suivant :
V1 * 68 + V2 * 16 = 16 680 000 octets
Si l’on considère la table Edition qui viole la 2NF, son encombrement logique est de l’ordre de :
(16 + 64) * V2 = 80 000 000 octets.
Dans la mesure où la correspondance entre un tuple (logique) et un enregistrement (physique) est de un pour un dans les systèmes actuels :
=> Un arrangement mathématique peut manifestement avoir des conséquences sur le stockage des données.
Les volumétries ne sont peut-être pas très pertinentes concernant des courses hippiques (quoique à l’échelon planétaire...), mais si l’on remplace ces tables par celles que l’on rencontre dans le monde de la banque, de l’assurance, de la retraite, de la sécu, de la DGI, de la téléphonie, j’en passe et des meilleures, on change d’échelle et vous pouvez multiplier par un facteur 100.
Il y a quand même un élément dont il faut tenir compte : les mathématiques ne se situent ni dans le temps ni dans l’espace. Au niveau physique, on ne peut pas en dire autant !
En l’occurrence, ce qui était vrai il y a dix, vingt, trente ans ne l’est plus aujourd’hui et ce qui est vrai aujourd’hui fera sourire dans dix, vingt ou trente ans.
Ainsi, il est naturel aujourd’hui de compresser les données et les 80 000 000 d’octets n’en font peut-être plus que le tiers : contrairement à hier ou avant-hier, l’encombrement physique n’est plus égal à l’encombrement logique (au moins sur disque, pour ce qui se passe dans les buffers et espaces apparentés, c’est une autre histoire).
Et demain ? Si l’on utilise le modèle TransRelational (TM) de Steve Tarin, on dira adieu aux index, les colonnes Course_Nom et Course_Lieu de la table Edition non 2NF comporteront physiquement le même nombre de lignes que la table Course en BCNF. Les DBA de demain auront une pensée émue pour leurs anciens qui projetaient au niveau physique l’image qu’ils avaient des tuples logiques. Attention, le modèle TransRelational (TM) ne remplace pas le Modèle relationnel ! Son rôle est de réaliser la correspondance avec le niveau physique ("Trans" est l’abréviation de "Transform"). Mais quelle révolution sous le capot !
Autrement dit, le gaspillage physique pour cause de non normalisation 2NF, 3NF ou BCNF ne sera plus un argument d’optimisation. Resteront les arguments traditionnels : — Éliminer la redondance inutile.
— Minimiser les difficultés et les anomalies lors des opérations de mise à jour (INSERT, UPDATE, DELETE).
— Réduire la nécessité de modifier la structure des relations à l’occasion de la prise en compte de nouveaux types de données (donc d’attributs), donc faire des économies du côté de la maintenance des applications.
— Aboutir à une base de données structurellement correcte.
— Éviter de favoriser certaines requêtes au détriment des autres.
—...
Citation:
L'écriture dans la table principale doit bien faire des aller et retour avec les tables satellites pour récupérer les équivalences des code des champs ! Ceci ne ralentis pas le traitement ?
Je ne sais pas ce que vous entendez par table principale et tables satellites.
En tout état de cause, j’utiliserai les tables que j’avais définies (toujours mon message du 24/02/2007, 00h18). En effet, vous mentionnez "Deauville, 7e", quand de mon côté je mentionne "Prix d’Amérique, édition [de l’année] 1956" (voyez les Insert) :
Course (Course_Id, Course_Nom, Course_Lieu)
Edition (Course_Id, Course_Date_Id, Course_Date, Temps_Vainqueur)
Resultat (Course_Id, Course_Date_Id, Dossard_Id, Jockey_Id, Cheval_Id, Place)
Jockey (Jockey_Id, Jockey_Nom)
Cheval (Cheval_Id, Cheval_Nom, Cheval_Date_Naissance, Propriétaire)
A partir de ces tables, on peut définir une table des résultats, qui rende transparentes les jointures :
V_COURS (Course_Nom, Course_Lieu, Cheval_Nom, Jockey_Nom, Dossard_Id, Course Date)
Table virtuelle certes, mais table quand même, résultant de la jointure des autres tables :
Code:
1
2
3
4
5
6
7
8
9
|
Create View V_COURS as
Select S.Course_Nom, S.Course_Lieu, V.Cheval_Nom, J.Jockey_Nom, R.Dossard_Id, E.Course_Date
From Course as S, Edition as E, Resultat as R, Jockey as J, Cheval as V
Where S.Course_Id = E.Course_Id
And E.Course_Id = R.Course_Id And E.Course_Date_Id = R.Course_Date_Id
And R.Jockey_Id = J.Jockey_Id
And R.Cheval_Id = V.Cheval_Id
; |
Quant aux "Allers-retours", je suppose qu’il s’agit des entrées-sorties. En l’occurrence, la performance dépend de pas mal de paramètres, au niveau physique.
Si par exemple, vous disposez d’une machine bases de données Teradata, les E/S sont effectuées en parallèle (à charge bien sûr du DBA de s’en assurer). Avec DB2 for z/OS, même principe, vous disposez des tuyaux nécessaires pour paralléliser. Avec ce genre de systèmes, les DBA savent agir pour que l’on ne ressente pas de différence de performances. Je suppose qu’un expert Oracle tiendra un discours de cette nature. Avec mon SQL Server Express sur mon modeste PC avec un seul disque dur, je constaterai peut-être la différence, mais je n’ai pas testé.
Quoi qu’il en soit, comme je l’ai déjà écrit dans cette discussion, quand c’est pour de vrai et que j’engage ma société sur la performance de la base de données dont j’ai réalisé l’architecture, je prototype encore et encore, jusqu’à ce que la performance définie par le cahier des charges soit effective. Et croyez-moi, j’ai de sacrés souvenirs à ce sujet.
Je peux vous dire que j’ai effectué des jointures impliquant plus de 10 tables (en BCNF bien entendu), chacune comportant des dizaines de millions de lignes : si je n’ai pas eu de problèmes de performance, c’est parce que j’ai toujours commencé par une validation vigilante et sévère des modèles conceptuels de données Entités/Relations, et poursuivi au niveau physique par un choix et une organisation soignés des index et autres ressources, avec tests de performance (et de contention...) très complets, en collaboration avec l’équipe des DBA.
Une fois encore, ne mélangeons pas les niveaux.
Vous savez peut-être que les SGBD relationnels devancent les autres d’un bon paquet de longueurs, en termes de performance. Mais, quand en 1975, Ted Codd présenta le Modèle relationnel (qui n’existait bien sûr que sur le papier) à des pontes d’IBM, les questions qu’on lui posa furent du genre :
— Pourriez-vous fournir la justification économique de solutions d’entreprises.
— Une estimation des applications potentielles chez les utilisateurs, par secteur d’activité et par type d’application si possible.
— Les méthodes de programmation, leur compatibilité et un comparatif avec notre standard actuel de bases de données, DL/1.
J’en passe et des meilleures. Pauvre mathématicien égaré chez les managers...
Ses collègues réussirent à obtenir qu’un prototype fut réalisé : System R. La révolution était commencée.
Si vous vous sentez toujours victime d’un dysfonctionnement oculaire, précisez ce qui vous gêne plus particulièrement...
__________________________________
NB. Théorème de Heath (1971) :
Soit la variable relationnelle R (A, B, C) dans laquelle A, B et C sont des ensembles d’attributs de R.
Si R satisfait à la dépendance fonctionnelle A -> B, alors R est égale à la jointure de ses projections sur {A,B} et {A,C}.
(Le terme "variable relationnelle" peut être traduit informellement par le terme "table").
Finalement je joue pas aux courses
Bonjour
je crois que pour la normalisation j'ai compris le but (sinon la construction)
c'est l'exemple des courses qui me bloquait un peu :(un jockey peut monter le même cheval dans la même course à un an d'intervalle et ça, ça me chagrinais) j'ai en suivant les liens donnés (et en recherchant les définitions des termes employés) trouvé un exemple de bibliothèque.
un fournisseur change d'adresse et ce sont tous les livres y référant qu'il faut modifier alors que si il est relié aux livres par une table fournisseurs seul sa fiche fournisseurs est à mettre à jour ;Ce qui prends trois minutes ( compris le temps de parler du film du dimanche, un navet, soir avec la collègue ) autrement une semaine à plein temps pour un petit fournisseur ,sans certitude de ne rien oublier; de même on peut rajouter un fournisseur qui n'a pas encore fournit quoi que ce soit .
Bon j'ai pas fini de décortiquer , j'y retourne
Cordialement
Daranc
Prise de relais, suite...
Citation:
Envoyé par
StringBuilder
Je ne parle pas du tout de simplifier les requêtes SQL, on s'en cogne des requêtes SQL.
Qu’en termes peu châtiés ces choses sont dites... Bref, passons, mais c’est l’homme à la moto, Don Chamberlin qui va être bien déçu de savoir que d’aucuns ne portent guère d’intérêt à SQL (du moins c’est ce qu’ils proclament), langage qu’il a inventé il y a trente-cinq ans avec Raymond Boyce (RIP)... D’accord, SQL n’est pas le prince des langages (il s’en faut de beaucoup !), mais il est dommage de vouloir se passer de la puissance de l’algèbre relationnelle et donc de raisonner (quelle alternative ?) séquentiellement. En outre, au-delà des requêtes, on doit savoir sous-traiter un maximum de choses à son SGBD, histoire de se simplifier la vie et assurer une meilleure pérennité des règles de gestion. Prenons l’exemple très simple d’une date de début qui ne doit pas être postérieure à la date de fin associée : la commande CREATE TABLE comportera une clause CHECK à cet effet. Autre exemple, quand on a une table T1 des entreprises et une table T2 des établissements et que l’on veuille s’assurer qu’un établissement n’est pas simultanément une entreprise (contrainte d’exclusion), avec SQL on mettra en oeuvre une assertion (cf. CREATE ASSERTION), ou un trigger (CREATE TRIGGER) si le SGBD ne nous permet pas de coder des assertions. En tout cas, dès que l’on peut les sous-traiter au SGBD, ces contraintes n’ont plus rien à faire dans les programmes d’application. Vous me direz que votre ERP s’occupe de tout, mais ça reste du code applicatif et par ailleurs comment développerez-vous quand les aléas de la vie vous éloigneront de lui ?
=> Sous-traiter le maximum de contrôles au SGBD (lequel est de plus en plus performant au fil des ans) et ne conserver dans les programmes que la partie productive.
Citation:
Envoyé par
StringBuilder
Moi je parle de simplifier les algorythmes des applications consommatrices
Intention louable, mais simplifier un algorithme dans un programme n’entraîne pas a priori la réduction de la consommation de ressources, mais a un coût en termes de maintenance. En revanche, un SGBD comme DB2 utilise sous le capot des algorithmes de plus en plus astucieux et sophistiqués, dont l’objet est bien de réduire la consommation des ressources, sans que l’on ait en contrepartie à modifier une ligne de code dans les programmes.
Citation:
Envoyé par
StringBuilder
Y'a qu'un chercheur de l'EDNAT pour croire qu'un modèle hyper normalisé est super optimisé pour une application de production
Non. Il y a aussi ceux dont je fais partie et qui ont passé leur vie dans la soute et à la dunette, à modéliser, prototyper et garantir les performances de la production informatique dans les entreprises. Comme je l’ai déjà mentionné, j’ai passé le plus clair de mon temps sur le terrain, notamment suite à des appels au secours, pour rattraper en catastrophe les bourdes des autres mettant à mal la production. Cela fait un bon moment que j’ai conclu que, même si elle n’est pas la panacée, la normalisation des bases de données est déterminante et singulièrement bénéfique. Par ailleurs, je rappelle que normaliser et optimiser sont deux choses différentes mais qui sont complémentaires.
Citation:
Envoyé par
StringBuilder
Citation:
Envoyé par
fsmrel
Les développeurs ne sont pas concernés, c’est aux DBA de se prononcer, suite aux résultats du prototypage au besoin.
Détrompe-toi. Le développeur ne se contente pas de faire des INNER JOIN dans son code
Que le développeur n’ait pas à coder que des INNER JOIN, personne n’en disconvient ! Cela dit, je vous rappelle ce que j’ai écrit dans un précédent message : « des mois avant que les développements ne commencent on connaissait la performance de la base de données normalisée suite au prototypage » et l’équipe de la production de la banque a du coup obtenu que soit imposé le prototypage des performances à l’ensemble des projets. Par ailleurs, j’ai quand même commencé à développer il y a quarante cinq ans et j’étais aussi DBA quand vous êtes né, j’ai donc le sentiment de pouvoir affirmer que je sais de quoi je parle.
Citation:
Envoyé par
StringBuilder
CODSOC et TYPTIE sont des données contextuelles, dont l'utilisateur n'a que faire. Donc si, SIGTIE est un identifiant unique pour un contexte donné (les clients du magasin, les fournisseur de la centrale d'achat, etc.) C'est donc une clé toute trouvée, dans le plus strict respect de la conceptualisation.
Plaît-il ? Vous aviez écrit :
Citation:
Envoyé par
StringBuilder
dans le cas que je décrit, SIGTIE peut être identique selon les TYPTIE et les CODSOC.
=> Pour deux tiers différents, la colonne SIGTIE peut avoir la même valeur, donc le singleton {SIGTIE} ne peut pas être clé candidate.
Citation:
Envoyé par
StringBuilder
Les informations de SIRET, etc. sont bien évitement stockées soit dans la table des tiers (lorsqu'elles sont succeptibles d'être communes à suffisament de types de tiers -il vaut mieux parfois sacrifier une normalisation à l'extrême au profit de la simplicité lorsque la simplicité s'applique au plus grand nombre-) ou dans des tables dépendantes.
Dans mon message précédent, je vous avais demandé de nous éclairer, car votre explication n’est pas claire (euphémisme...) Je repose donc ma question :
Citation:
Envoyé par
fsmrel
Le numéro Siret des entreprises fait-il bien l’objet d’une colonne qui lui est propre ?
De la même façon, le matricule des vendeurs fait-il bien l’objet d’une colonne qui lui est propre (que ce soit dans la table TIERS ou une autre) ? Plus généralement, conformément aux règles de la modélisation, chaque donnée identifiante « naturelle » fait-elle bien l’objet d’une colonne qui lui est propre ?
Citation:
Envoyé par
StringBuilder
C'est pourtant vers ce genre de choses qu'on s'oriente avec les framework SQL Less.
L'ERP sur lequel je travaille utilise ce système pour construire dynamiquement des écrans : dans un fichier XML on indique qu'on veut parcourir un objet métier (qui correspond généralement à une table) et pour chaque ligne, on va parcourir d'autres objets métiers : on a donc rapidement des centaines (voir des milliers) de requête qui sont exécutées pour un seul écran.
Pardon ? Des centaines (des milliers) de requêtes pour un seul écran ?! Il y a de l’optimisation à prévoir en ce qui concerne la manipulation des données, les requêtes SQL il ne faut pas « s’en cogner », même si celui qui les génère est un ERP...
Citation:
Envoyé par
StringBuilder
[...]l'ajout de 3 colonnes dans une autre table éviterait des jointures inutiles.
J’inverse le propos : la jointure (l’opérateur relationnel par excellence) permet de ne pas avoir à ajouter inutilement des colonnes dans l’en-tête d’une table. Ajouter une colonne est une opération lourde s’il en est quand il faut s’y résoudre, alors qu’ajouter une ligne dans une table est transparent, et comme on l’a vu, sans que la performance soit impactée.
Citation:
Envoyé par
StringBuilder
au plus on aura des valeurs NULL dans ces colonnes supplémentaires
Le défi de la modélisation est — entre autres — de ne jamais avoir d’attribut qui puisse être marqué NULL.
Citation:
Envoyé par
StringBuilder
[...]le SGBD, il ne faut pas oublier que c'est qu'un moyen de stocker les données.
Êtes-vous conscient de l’énormité que vous proférez ? Grâce au langage qu’il propose, le SGBD vous permet de structurer les données (le typage sert par exemple à éviter de comparer des choux et des carottes, les vues vous permettent de présenter les données de différentes façons, etc.), les manipuler en tant qu’ensembles (grâce aux opérateurs de l’algèbre relationnelle), en garantir l’intégrité (intégrité d’entité, intégrité référentielle, contraintes de base de données (instruction CONSTRAINT de Tutorial D ou assertions et triggers SQL)). Et je ne parle même pas des propriétés ACID que le SGBD doit assurer outre d’autres fonctions. Si vous vous limitez au stockage, autant en passer par des fichiers.
Citation:
Envoyé par
StringBuilder
Si la représentation des données n'est pas compatible avec la représentation qu'on en a dans l'outils qui les traites, là il y a un vrai problème, bien plus grave qu'un souci de dénormalisation.
Effectivement, il faut changer d’outil, ou envoyer celui qui en est l’auteur apprendre à modéliser correctement (5NF, voire 6NF pour les données temporelles), apprendre l’algèbre relationnelle, apprendre à faire des vues. La modélisation des bases de données ne se fait pas en plaquant dans des tables ce qu’on voit à l’écran, la vue qu’on a de l’écran est indépendante (orthogonale comme dirait Chris Date) de la structure de la base de données.
