DB Design: 1ère forme normale et groupes répétitifs
À adhérer à la 1ère forme normale, l'une des choses que vous devez éviter, c'est de répéter les groupes. Comme, au lieu de:
CustID Name Address Phone1 Phone2 Phone3
102 Jerry 234 East.. 555-2342 555-9854 555-2986
Vous devez créer un deuxième Numéro de Téléphone, table et ensuite sur une jointure, vous obtenez:
CustID Name Address Phone
102 Jerry 234 East.. 555-2342
102 Jerry 234 East.. 555-9854
102 Jerry 234 East.. 555-2986
Parfois, c'est un peu plus ambigu et il est difficile de dire quand un groupe d'en-têtes de colonne qualifier. Par exemple, disons que vous avez, à l'heure actuelle, deux tests à exécuter sur chaque pièce de matériel. Et votre première DB design les rendements de la plupart approche horizontale:
1
SN Test1_Max Test1_Min Test1_Mean Test2_Max Test2_Min Test2_Mean
2093 23 2 15 54 -24 45
Évidemment, c'est une répétition du groupe, qui pourrait beaucoup plus facilement être représenté comme (sur une jointure entre les "Parties" et "Tests"):
2
SN Test Max Min Mean
2093 1 23 2 15
2093 2 54 -24 45
Cependant, vous pourrait aller encore plus à la verticale:
3
SN Test Statistic Value
2093 1 Max 23
2093 1 Min 2
2093 1 Mean 15
2093 2 Max 54
2093 2 Min -24
2093 2 Mean 45
Est de Conception 3-elle nécessaire? Comment voulez-vous décider de la manière verticale pour le faire? Quels sont les avantages et les inconvénients entre le Design 2 et 3? Il semble que les deux peuvent être sélectionnés ou rejoint facilement avec SQL, avec l'avantage donné à la Conception 3 car vous pouvez facilement ajouter une nouvelle Statistique sans réellement modifier la structure de la table.
Mais avant tout va et dit que la verticale de la meilleure, il y a des moments où c'est plus ambigu. Comme:
4
SN AverageCurrent (mA) BatteryCapacity (mA)
2093 200 540
Pourraient plutôt être:
5
SN mA_Measuremnt Value
2093 AverageCurrent 200
2093 BatteryCapacity 540
Tandis que les deux attributs sont du même domaine (mA), ils représentent des choses très différentes en ce qui concerne le composant. Dans ce cas, le Design est 4 mieux depuis qu'il n'est pas strictement une répétition de groupe? Je crois que je suis à la recherche de certains critères à savoir quand le décomposer en plusieurs tables et ainsi le rendre plus à la verticale.
Pour résumer cette ridiculement longue question, si vous ne retirez et de normaliser la répétition de groupes s'ils sont exactement le même domaine et ont le même sens?. Si c'est le cas, alors, vraiment, que le numéro de l'exemple et probablement les deux tests dans la Conception 1 correspondent à ce critère. Bien qu'il semble comme il pourrait être la conception des prestations de Conception 3 et 5, même si les statistiques de la Conception 3 ont des significations différentes, à strictement parler, et AverageCurrent et BatteryCapacity certainement avoir des significations différentes dans la Conception 5.
source d'informationauteur
Vous devez vous connecter pour publier un commentaire.
De Design 2 et de Design 4 sont les meilleures façons d'aller fourni les résultats ne seront pas toujours présents (aka les valeurs Null dans les Desigin 1). Si elles sont toujours prises, puis la première conception est très bien.
Je crois que les groupes récurrents dans SQL serait effectivement si vous avez une colonne en peluche avec ajouter l de valeurs par exemple Phone_Number contient "123-444-4444,123-333-3334" etc.
De toute façon, les dessins ne sont pas optimales -- vous continuez à prendre que pour le niveau final et avoir "Une Vraie Table de Recherche" http://www.dbazine.com/ofinterest/oi-articles/celko22 ou de l'Entité la Valeur de l'Attribut http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056
De toute façon, c'est presque toujours une mauvaise chose. Bien qu'ils peuvent avoir en commun un type de données domaine, la sens diffère -- ainsi, ils devraient rester attributs individuels (maxtemp, mintemp, etc.)
Je pense (et a été enseigné) 1FN que "toutes les lignes doivent être de la même longueur" plutôt que de "pas de répétition des groupes". Avec ce point de vue, vous pouvez prendre une décision un peu plus facilement à partir de l'suivantes:
Dans la conception 1, sont à la fois des tests TOUJOURS présent? Si oui, alors ce n'est pas vraiment une répétition du groupe. Sont toutes les moyennes, toujours présent dans la conception 2? Pourrait-il y avoir de plus en plus (ou moins) dans une ligne donnée?
Dans la conception 4, sont ces deux valeurs est toujours présent? Si oui, c'est bien. Si non, alors la conception de 5 doit être utilisée.
Voici la règle sur la répétition de groupes, ce qui est fonctionnellement dépendant?
Si la valeur statistique est fonctionnellement dépendant SN, de Test et de Statistiques de Nom, alors vous avez trois éléments clés et un élément de valeur.
( SN, Test, Statistic -> Value )Dans ce cas précis -- données agrégées (moyenne, somme, min, max) -- vous avez ambiguïté parce que vous n'êtes pas affaire atomique avec des objets, vous avez affaire avec des agrégats. Strictement parlant, vous ne devrait pas stocker des agrégats, il faut calculer. (Oui, je sais que c'est impossible, mais c'est la théorie relationnelle.)
Pour d'autres cas, il est généralement évident que ce qui est et ce qui est une valeur pour la répétition de groupes. Dans ce cas, toutefois, vous êtes à l'obscur bord, car votre stockage dérivables de données.
Pour vos exemples, suivez l'entrepôt de données de conception pour localiser un point de vue plus pragmatique test:
Voulez-vous de Tranche et Dés par l'autre clé?
Pensez à vos statistiques de fait comme un point entouré par trois dimensions: (SN, le Test Statistique). Est-ce valable? (Avec un résumé des données, il est souvent glauque.)
Au lieu de cela, examinons les données de détail que nous devrions avoir gardé: SN, Test, Score. Il y a clairement deux dimensions (SN, Test) et une mesure (score) à l'intersection de ces deux dimensions. Nous pouvons tirer un certain nombre de statistiques à partir de ce détaillées des données à l'aide soit de dimension (SN ou Test)
Pour la batterie exemple, vous avez probablement ne voulez créer un EAV base de données au lieu d'un plus typiques de la base de données relationnelle. Vos mesures (AvergaeCurrent et BatteryCapacity) vous donner de bonnes raisons d'utiliser un Entité-Attribut-Valeur conception de base de données.
Noter que TOUS les relationnel design est une tension entre plus de relations et EAV triples. Vous devez toujours faire l'équilibre entre le "c'est que c'est la clé" vs "est-ce une colonne" parce que vous pouvez toujours l'étiquette, tout comme un attribut de la clé et l'utilisation d'un VAE de conception.
La conception doit être déterminé par vos scénarios de cas d'utilisation et le type de requêtes que vous prévoyez. Allez-vous faire beaucoup de lectures, d'écritures ou d'un lot de mises à jour? Voulez-vous d'obtenir l'ensemble des données de test pour un candidat ou voulez-vous d'obtenir que la meilleure façon de le tester ou de quelque chose. Quelle requête allez-vous être en cours d'exécution le plus souvent?
1
C'est le meilleur en termes de performances. Il ne nécessite pas de Joint. Si le nombre de champs est déterministe et non arbitraire (par exemple chaque personne a au plus deux scores du test) alors c'est mieux mais plus rigide si vous décidez d'associer plus de deux scores du test à une personne. Depuis SN est
uniqueici, pour chaque ligne, le moteur de base de données peut revenir dès qu'il trouve une correspondance, ce qui est une autre raison pour laquelle la performance est meilleure.2
Ceci est utile si
SN 2093peut avoir N tests dans leur profil. De même, si le nombre de tests est dire 10m, alors cette conception est mieux que d'avoir 30 colonnes. Chaque requête et de la comparaison va être très lourd. C'est aussi utile si votre application nécessite des requêtes où il veut obtenir le meilleur test pour les étudiants2093ou si souhaite faire quelques analytics et rapports sur les résultats des tests. C'est plus souple, bien que légèrement plus lente que la précédente. Je préfère cela car j'ai un pressentiment que vous serez probablement intéressé par la statistique de test et les étudiants peuvent avoir plus de deux tests de chacun.3
Ceci est utile si vos requêtes ont été intéressés par des valeurs plus que tout. Par exemple, si vous êtes intéressé par la façon dont le nombre de valeurs supérieures à 80 ce serait rapide. Dans votre scénario, ce n'est pas logique. Vous finirez par avoir trop d'auto-Jointures. Lit sera lente! Cependant, écrit sera probablement plus rapide parce que vous pouvez rapidement mettre à JOUR la note maximale pour
SN 2093etTest 2(en supposant que la Statistique de la colonne est un enum au lieu d'une chaîne, car les comparaisons de chaînes peut être coûteux).4
5
Mêmes arguments s'appliquent. Cela dépend vraiment si vous avez l'intention d'optimiser la lecture ou de l'écriture? Pour les applications web par exemple, si vous pouvez sortir avec elle, je préfère la Conception 1. Par exemple, je sais généralement qu'un utilisateur n'aura plus à 3 numéros de téléphone donc je vais faire chacune un champ dans la colonne utilisateur et d'éviter les Jointures. Les lectures sont rapides, même si les écritures ne nécessiter de définir certains champs à null.
Lorsque vous êtes sûr un "test" seront (jamais) ne possède qu'un Max, Min et Moyen -> utilisation de la conception 2.
Toutefois, s'il est possible qu'il y aura un nouveau "statistique" dans le futur, il est préférable d'utiliser de la conception 3.
Une réponse à:
Bien que dans de nombreux livres, il semble que ces formes normales sont strictement définis, ils ne le sont pas. Vous devriez voir votre propre demande quelle solution est la meilleure... Normaliser trop n'est pas toujours la meilleure solution, surtout quand vous voyez que vous avez toujours adhérer à toutes les données de retour ensemble.
Je suggère de déplacer les groupes récurrents pour se séparer de tables si elles ont une longueur variable. Si vous ne l'avez jamais fait seulement Phone1, Fixe2, et Phone3, il n'est pas nécessaire de les séparer. Dans les autres cas, si le nombre de repeatitons varie, la meilleure conception est une table distincte.
Et votre concept de l'exacte même domaine et le sens n'est pas très intuitive puisqu'il dépend du niveau d'abstraction. Phone1 n'est pas exactement la même que Fixe2, mais ils sont tous les deux numéros de téléphone. Vous pouvez également créer un tableau AddressDetails et déplacer les numéros de téléphone. Mais aussi le nom, la rue et la ville - ils sont tous les détails de l'adresse. Vous devez trouver un chemin entre les génériques paires clé-valeur et uniquement dédié colonnes.
Conception 1 est en fait en 1FN si vous avez un penalty sur CustID. Il pourrait être en 3FN si aucune donnée ne dépend de rien, mais le PK par exemple Phone1 n'est pas répété pour d'autres CustID.
Vous ne pouvez pas décider sur le modèle sans les affaires les affaires que vous essayez de résoudre. Le Design 1 pourrait être parfaitement valide modèle logique.