Discussion :

[Elkana49]

Bonjour je suis Fred étudiant en Sciences des données et dans le cadre de mon stage en BUT Science des Données, je participe à un projet de mise à jour et de valorisation des activités proposées aux seniors par les structures locales (associations, centres sociaux, professionnels, etc.).
Dont objectif principal est de concevoir une base de données relationnelle, de recueillir les informations via une enquête (KoboToolbox), puis de développer une interface web ou un outil de datavisualisation destiné au Pôle Seniors du CCAS de Bron. Et j'aimerai que vous critiquez mon MCD dans le but de le perfectionner tout en respectant le besoin métier et la 3ème FN :

[escartefigue]

Bonjour,

Respecter les règles de métier est en effet essentiel, mais pour que ce soit possible, encore faut il que ces règles sont rédigées clairement.

Voyez dans ce fil de discussion, réponse n°8, comment formuler ces règles de gestion
https://www.developpez.net/forums/d2...b-d-actualite/

[escartefigue]

infos complémentaires :

-1- le typage des attributs doit être fait avec soin

Il ne faut pas tout définir en varchar. S'il existe différent types, c'est qu'il y a une bonne raison .

Les identifiants se propagent des tables où elles sont PK (primary key) vers les tables où elles sont FK (foreign key).
Il est donc très important que ces identifiants ne changent pas. Or, une colonne de type char ou varchar contient le plus souvent des données fonctionnelles susceptibles de changer.

Ici, vous avez choisi des codes, donc des valeurs plus ou moins stables, mais, le code commune par exemple, s'il s'agit du code INSEE, est régi par un organisme externe, qui peut à tout moment en changer la structure, la longueur ou le contenu. Et là, c'est le drame, car toutes les tables où ce code sera présent seront alors impactées par cette modification.

De plus, les types char et varchar sont beaucoup plus encombrants à nombre de valeurs égale que des types integer et également, les colonnes char et varchar sont sensibles à la collation.

Pour les structures, vous avez choisi un identifiant de type varchar(100), soit 800 bits ! Ça signifie que pour une CPU de 64 bits, il faut 13 cycles CPU rien que pour transporter l'identifiant. Le double pour une jointure avec seulement 2 tables, imaginez ce que ça fait pour une requête joignant 5 ou 6 tables, monnaie courante dans les traitements
Remplacez ce type aberrant par du bigint si besoin ou plus probablement de l'integer, vous n'utiliserez que 4 octets (soit 32 bits donc un seul cycle CPU) pour 2 147 483 647 valeurs signées et le double si ce sont des valeurs non signées !

Et pour le varchar, il faut ajouter que les opérations de tri (ORDER BY, GROUP BY, DISTINCT, PARTITION BY) doivent d'abord aligner les valeurs sur une longueur fixe ce qui évidemment coute en CPU et en espace disque de travail.
Et aussi, contrairement au char fixe, le varchar peut provoquer des désorganisations des données (fragmentation) si la longueur effective du contenu varie (déplacement dans les pages data et index).
Enfin, du varchar pour des longueurs très courtes est moins performant que du char.

Bref, pour ce qui concerne les identifiants, le varchar est ce qu'on peut faire de pire

La meilleure solution pour les identifiants, à la fois en matière de stabilité et de performances, est d'utiliser un identifiant technique asémantique, attribué par le SGBD (counter, auto_increment, identity... selon le SGBD)


-2- adresses, villes et codes postaux doivent faire l'objet d'entité-types distinctes

il n'y a pas bijection entre ville et code postal, certaines villes partagent le même code postal, d'autres ont plusieurs codes postaux.
Voyez dans ce fil de discussion , réponse n°4, comment modéliser les adresses, villes et codes postaux