Normalisation: que signifie «groupes répétitifs»?
J'ai lu différents tutoriels et vu différents exemples de normalisation, spécialement la notion de "groupes répétitifs" dans la première forme normale. J'en ai déduit que les groupes répétitifs sont des "sortes" d'attributs à valeurs multiples (par exemple ici et ici ).
Mais nous faisons déjà des tables distinctes pour chaque attribut à valeurs multiples en incluant des clés étrangères de la table parent pendant le processus de mappage d'un ERM (Entity Relation Model) à un RDM (Relational Data Model)? Référence: this
Deuxièmement, ces "groupes répétitifs" sont-ils essentiellement disposés horizontalement dans la même ligne, ou la même valeur peut-elle apparaître encore et encore dans la même colonne, c'est-à-dire la même valeur d'un attribut encore et encore , également un groupe répétitif et devrait être éliminé?
Dans cet exemple, la valeur English se répète encore et encore. Est-ce un groupe répétitif? Si je l'élimine pour faire une autre table SUBJECT avec Subject Name et Module_ID (clé étrangère), c'est ce que j'obtiens. Bien sûr, il supprime la valeur de répétition, mais je ne suis pas sûr que ce soit la bonne chose. Est ce juste? 
Le terme "groupe répétitif" signifiait à l'origine le concept dans les langages basés sur CODASYL et COBOL où un seul champ pouvait contenir un tableau de valeurs répétitives. Quand E.F.Codd a décrit sa première forme normale, c'est ce qu'il entendait par un groupe répétitif. Le concept n'existe dans aucun SGBD relationnel ou SQL moderne.
Le terme "groupe répétitif" est également devenu utilisé de manière informelle et de manière imprécise par les concepteurs de bases de données pour désigner un ensemble répétitif de colonnes , ce qui signifie une collection de colonnes contenant des types similaires de valeurs dans une table. Ceci est différent de sa signification d'origine par rapport à 1NF. Par exemple, dans le cas d'une table appelée Familles avec des colonnes nommées Parent1, Parent2, Child1, Child2, Child3, ... etc la collection Child [~ # ~] n [~ # ~ ] les colonnes sont parfois appelées un groupe répétitif et supposées être en violation de 1NF même si elles ne sont pas un groupe répétitif dans le sens voulu par Codd.
Ce dernier sens d'un soi-disant groupe répétitif n'est pas techniquement une violation de 1NF si chaque attribut n'a qu'une seule valeur. Les attributs eux-mêmes ne contiennent pas de valeurs répétitives et il n'y a donc pas de violation de 1NF pour cette raison. Une telle conception est souvent considérée comme un anti-modèle, car elle contraint la table à un nombre fixe de valeurs prédéterminé (N enfants maximum dans une famille) et parce qu'elle oblige les requêtes et autres logiques métier à être répétées pour chacune des colonnes. En d'autres termes, il viole le principe de conception " SEC ". Parce qu'il est généralement considéré comme une mauvaise conception, il convient aux concepteurs de bases de données et parfois même aux enseignants de se référer à des colonnes répétées de ce type comme un "groupe répétitif" et une violation de l'esprit de la première forme normale.
Cet usage informel de la terminologie est légèrement regrettable car il peut être un peu arbitraire et déroutant (quand un ensemble de colonnes constitue-t-il réellement une répétition?) Et aussi parce qu'il détourne l'attention d'un problème plus fondamental, à savoir le problème Null. Toutes les formes normales concernent les relations qui ne permettent pas la possibilité de null. Si une table autorise une valeur nulle dans n'importe quelle colonne, elle ne répond pas aux exigences d'un schéma de relation satisfaisant 1NF. Dans le cas de notre table Familles, si les colonnes Enfant autorisent des valeurs nulles (pour représenter les familles qui ont moins de N enfants), la table Familles ne satisfait pas 1NF. La possibilité de valeurs nulles est souvent oubliée ou ignorée dans les exercices de normalisation, mais le fait d'éviter les colonnes nulles inutiles est une très bonne raison pour éviter de répéter des ensembles de colonnes, que vous les appeliez ou non "groupes répétitifs".
Voir aussi cet article .
la valeur anglaise se répète encore et encore. Est-ce un groupe répétitif?
Non. Les multiples apparitions de l'anglais dans SUBJECT_MODULE ne sont pas un groupe répétitif ou même l'une des deux choses que les gens entendent par erreur par un groupe répétitif. Ils ne sont pas non plus la preuve d'une redondance ou d'un manque de normalisation. Ces apparences multiples peuvent être liées à la redondance ou à la normalisation, mais elles apparaissent tout le temps en l'absence de redondance et à différents niveaux de normalisation.
Si SUBJECT_MODULE est une ligne où "[SUBJECT_NAME] a [MODULE_NAME] identifié par [MODULE_ID]" et qu'un sujet peut avoir plus d'un module, alors quelque part vous devez avoir plusieurs mentions de ce sujet (peut-être via son nom) avec des mentions de différents modules (peut-être par nom ou id). Cela n'impliquerait pas de redondance.
Student Age Subject
Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths
La redondance dans cet exemple du deuxième lien " this " de votre question n'est pas qu'Adam apparaît sur deux lignes ou qu'Adam apparaît avec 15 sur deux lignes. C'est que si le tableau est des lignes où "[Student] a [Age] ans et prend [Subject]" alors Student (par exemple Adam) peut apparaître sur plusieurs lignes mais apparaît toujours avec le même âge (par exemple 15). Mais si le tableau était constitué de lignes où "[L'élève] a un ami [Âge] ans dans [Sujet]", alors le tableau pourrait déjà être entièrement normalisé.
Bien sûr, il supprime la valeur de répétition, mais je ne suis pas sûr que ce soit la bonne chose.
C'est le cas pour vos données d'exemple, mais pas pour d'autres données d'exemple. Vous ne nous en avez pas assez dit. (Quoi qu'il en soit, comme je l'ai dit ci-dessus, les multiples apparences pourraient même ne pas avoir besoin d'être normalisées.)
Qu'il y ait des redondances pertinentes pour la normalisation dans SUBJECT_MODULE ou même qu'il y ait des décompositions valides, y compris celle que vous avez donnée, dépend des informations habituelles nécessaires pour normaliser au-dessus de 1NF. A savoir si certaines de ses colonnes sont des fonctions d'autres (dépendances fonctionnelles) et si ses lignes sont aussi celles où "..." ET "..." (jointures de dépendances).
En donnant une décomposition possible, vous avez dit que ce sont aussi des lignes où "... [Subject_Name] ... [Module_ID] ..." AND "... [Module_Name] ... [Module_ID] ..." Et vous avez donné quelques exemples de données de décomposition. Mais nous savons seulement qu'il pourrait être ainsi décomposé parce que vous avez ajouté la décomposition. Et la décomposition plus les données ne sont toujours pas suffisantes pour que nous sachions si devrait être ainsi décomposé.
J'ai lu différents tutoriels et vu différents exemples de normalisation, spécialement la notion de "groupes répétitifs" dans la première forme normale.
Les "groupes répétitifs" proviennent de bases de données pré-relationnelles et ne peuvent pas apparaître dans une table relationnelle (relation). Ils sont comme un ensemble de valeurs nommées qui est comme un champ d'un enregistrement mais qui n'est pas tout à fait. Une table relationnelle est toujours en 1NF. Chaque colonne d'une ligne a une valeur unique du type de la colonne. Une base de données non relationnelle est "normalisée" par rapport aux tables, c'est-à-dire 1NF (premier sens de "normalisé") qui supprime les groupes répétitifs. Ensuite, ces tables/relations sont "normalisées" à des formes normales supérieures (deuxième sens de "normalisé").
Une table relationnelle ayant plusieurs colonnes similaires ou ayant un type de colonne avec plusieurs parties similaires rappelle chacune d'avoir un groupe extensible dans une base de données non relationnelle. Et les multiples colonnes et parties doivent devenir plusieurs lignes dans une table distincte, tout comme les multiples membres d'un groupe répétitif. Mais ces problèmes ont à voir avec la qualité relationnelle de la conception , pas la répétition de groupes ou la normalisation (dans les deux sens) ou le fait d'être relationnel (c'est-à-dire d'être dans 1NF).
Notez qu'une base de données non relationnelle peut elle-même avoir des problèmes similaires avec plusieurs champs similaires et/ou ensembles nommés ou avec plusieurs parties similaires de valeurs de champs. La normalisation vers les tableaux ne les supprime pas quand elle supprime les groupes répétitifs.
Quelle que soit la façon dont ils sont entrés dans une conception relationnelle, leur suppression donne une "meilleure" conception. C'est simplement parce que ces problèmes de conception rappellent les groupes répétitifs que les gens sont confus et imaginent qu'une table pourrait contenir un groupe répétitif. Ainsi, les multiples colonnes et valeurs similaires avec plusieurs parties similaires (ou les parties) sont incorrectement appelées "groupes répétitifs".