Organisation et normalisation Flux RSS Catégories de données

Question

J'ai de la difficulté à normaliser les données d'un flux RSS dans une base de données. Chaque message aurait id et categories.

Le problème que j'ai est que categories est une liste qui n'est pas prédéfinie en taille. En 1FN je diviser une liste de telle sorte que chaque colonne ne dispose que des données atomiques:

+----+----------+ 
| id | name | 
+----+----------+ 
| 1 | flying | 
| 2 | swimming | 
| 3 | throwing | 
| 4 | sleeping | 
| 5 | etc  | 
+----+----------+ 

Cependant, les messages de blog peut avoir plus d'une catégorie étiquetée. Cela signifie que la table posts peut avoir une liste d'identifiants des catégories marquées.

Sinon, la table categories peut avoir deux ids:

+----+--------+----------+ 
| id | postId | name | 
+----+--------+----------+ 
| 1 |  1 | flying | 
| 2 |  1 | swimming | 
| 3 |  1 | throwing | 
| 4 |  2 | flying | 
| 5 |  2 | swimming | 
| 6 |  2 | etc  | 
+----+--------+----------+ 

Et la table postsid fera référence la colonne postId. Cependant, il y a des données répétées, ce qui n'est pas bon.

Enfin, une autre méthode que je l'avais pensé était de mettre toutes les catégories dans une table:

+----+--------+----------+----------+----------+-----+ 
| id | flying | swimming | throwing | sleeping | etc | 
+----+--------+----------+----------+----------+-----+ 
| 1 |  1 |  1 |  1 |  1 | 1 | 
| 2 |  0 |  1 |  0 |  0 | 0 | 
| 3 |  1 |  1 |  0 |  0 | 1 | 
| 4 |  0 |  0 |  1 |  1 | 1 | 
+----+--------+----------+----------+----------+-----+ 

1 s représentant présents et 0 s représentant absent, le id dans les références tableau postsid. Cette méthode n'aurait pas de données répétées. Cependant, les catégories des blogs peuvent être créées à volonté, ce qui rend difficile la maintenance d'une telle table car je devrais la mettre à jour chaque fois qu'il y a une nouvelle catégorie.

Comment mettre ma base de données en 3NF, en éliminant les répétitions tout en maintenant la maintenance?

Answer 1

TL; DR "Données répétées" est un bugbear. En savoir plus sur la conception et la normalisation. Commencez avec des lignes/tables qui rendent claires déclarations pertinentes sur une situation arbitraire. Jusqu'à présent, tout ce que vous avez besoin est:

-- [id] identifies a post with ... 
Post(id, ...) 
-- post [id] is tagged [name] 
Post_Category(id, name) 

---

il y a des données répétées, ce qui est pas bon

Que pensez-vous exactement « données répétées » est? Et pourquoi pensez-vous que c'est "pas bien"?

Il n'y a rien d'intrinsèquement mauvais à ce que la même valeur apparaisse plusieurs fois en tant que colonne d'une ligne ou partie d'une valeur pour une colonne d'une ligne. Ce qui importe, c'est de savoir si les lignes dans les tableaux disent des choses qui se chevauchent à propos d'une situation de certaines façons.

La normalisation remplace une table par des projections qui la rejoignent. Cela signifie qu'il remplace les tables dont les lignes dire (c.-à-ont prédicat) « quelques trucs et autres choses » sur les valeurs de la colonne par des tables dont les lignes dites « quelques trucs » et « autres choses » séparément. Avoir des «ET» dans une telle ligne/signification de table n'est pas toujours mauvais.Lorsqu'il n'y a qu'un ET, la normalisation dit de se décomposer en une paire particulière de tables exactement lorsqu'aucun ensemble de colonnes partagées ne contient toujours un ensemble unique de valeurs dans l'une ou l'autre des deux tables.

mettre toutes les catégories dans une table

Bien qu'il n'y ait rien d'une telle conception qui provoquerait la normalisation de le décomposer, votre dernière table est une conception « mauvais ». (Parfois, ce type de design avec des colonnes similaires répétées viole une certaine notion de "1NF" ou "normalisation", mais c'est une idée fausse.) Par exemple, ses lignes disent "(post [id] est étiqueté" volant "et ] = 1 OR post [id] n'est pas étiqueté 'flying' AND [flying] = 0) ET (post [id] est tagué 'swimming' et [swimming] = 1 OU post [id] n'est pas tagué 'swimming' AND [swimming] = 0) AND ... "alors qu'à la place nous pourrions simplement avoir une table Post_Category avec des lignes disant" post [id] est tagué [nom] ". Par exemple, nous ne pouvons pas écrire des requêtes qui posent des questions sur toutes les catégories sans mentionner explicitement toutes les catégories. Par exemple, si nous ajoutons une nouvelle catégorie, nous devons ajouter une nouvelle colonne à la table et si nous voulons que nos requêtes passées sur toutes les catégories signifient la même chose, nous devons ajouter la nouvelle colonne pour toujours faire référence à toutes les catégories.

PS Il n'est pas clair pourquoi vous avez introduit les identifiants. Il y a des raisons pour lesquelles nous le faisons, mais vous devriez le faire pour une raison. (La normalisation n'introduit pas d'identifiants.) Par exemple, introduire des identifiants de message si les messages ne sont pas uniquement identifiables par d'autres informations que nous souhaitons enregistrer.