2010-11-11 65 views
2

Y a-t-il un nom pour un type de Star Schema dans lequel il y a un seul Fact table qui a une seule colonne pour la valeur, et le type de valeur (la mesure) est défini par un dimension?Y a-t-il un nom pour ce type de structure de données?

En d'autres termes, une table comme ceci:

Dim1ID  Dim2ID  MeasureID  Value 
--------- ----------- ------------- ------------ 
543  44   1    234.3 
543  45   1    256.3 
544  44   1    245.3 
544  45   1    264.5 
543  44   2    10 
543  45   2    8 
544  44   2    9 
544  45   2    10 

Avec une colonne valeur qui représente différentes mesures par une clé étrangère.

Y a-t-il un nom pour ce modèle?

+0

DB – Andrey

+1

@Andrey: C'est vrai, mais la normalisation est une technique, pas une religion que nous devons tous suivre:) – codeulike

Répondre

2

Entity-Attribute-Value Model peut-être?

Éditorial: Certaines personnes considèrent qu'il s'agit d'un anti-pattern (en SQL), bien que dans les mémoires basées sur les colonnes, ceci soit le comportement habituel (BigTable, Cassandra).

+0

Merci, EAV et aussi Open-Schema semble être les noms. Maintenant, je connais le nom, je peux lire sur la théorie:) ... Ce lien wikipedia est très bon, aussi ces deux questions SO ... http://stackoverflow.com/questions/2854312/database-with-open- schéma-bon-ou-mauvaise-idée http://stackoverflow.com/questions/192892/performance-of-large-eav-open-schema-systems-on-sql-server – codeulike

0

Il me semble que, comme MeasureID ferait référence à un tableau énumérant toutes les mesures possibles, vous avez juste un schéma en étoile avec trois dimensions où une dimension est appelée "Mesure".

+0

Ouais je suppose, mais en lisant sur schémas-étoiles il semble que la chose habituelle est d'avoir des clés étrangères pour les dimensions mais de stocker chaque type de mesure dans sa propre colonne ou table – codeulike

0

Je l'appellerais simplement une table 4D: trois attributs clés et une non-clé. Je ne pense pas qu'il a besoin d'un nom spécial.

J'ai travaillé avec un modèle presque identique il y a quelque temps. Nous avions plus de 8000 mesures et plusieurs milliards de lignes. Dans le SGBD que nous utilisions, il était totalement impossible (et inutile) de créer des tables avec des milliers de colonnes. La version "large" de la ligne n'aurait eu aucune valeur pour la plupart des mesures sur la plupart de ses lignes. Nous aurions donc dû générer des valeurs NULL ou des valeurs fictives pour les données là où elles n'existaient pas ou nous aurions dû créer des centaines de tables "plus étroites" avec des ensembles de mesures presque arbitraires. Le modèle «vertical» a beaucoup plus de sens et jouera plutôt bien avec le bon SGBD.

Je ne suis pas d'accord avec la suggestion que votre conception n'est pas correctement normalisée. Tant que toutes les mesures sont du même type de données, il s'agit d'un dessin légitime et est au moins dans la 5ème forme normale (en supposant que les identificateurs de dimension et de mesure forment la clé). Une conception alternative avec beaucoup de colonnes ne serait certainement pas normalisée si elle vous obligeait à utiliser des valeurs nulles.

+0

Je vois que vous pouvez juste penser à 'MeasureID' comme un autre attribut, mais je pense que c'est significatif MeasureID' change la signification de 'value', plutôt que de simplement en décrire une dimension. Par exemple, dans le tableau ci-dessus, l'utilisation de la validation au niveau DB ou des contraintes sur 'value' ne serait pas très simple car les règles de validation dépendraient de' MeasureID'. Je me suis donc demandé si ce motif avait un nom (et donc je peux aller chercher une théorie à ce sujet ...). Merci pour vos commentaires. – codeulike

+0

@codeulike: Bon point sur la complexité des contraintes (et autres logiques) sur différents types de valeur. Si vous devez traiter différentes mesures de manière très différente, cela peut être une bonne raison d'avoir plusieurs colonnes/tables de mesures. – sqlvogel