Bases de données relationnelles vs. dimensionnelles, Quelle est la différence?
j'essaie d'en savoir plus sur OLAP et data warehousing, et je suis confus sur la différence entre la modélisation relationnelle et dimensionnelle. La modélisation dimensionnelle est-elle essentiellement une modélisation relationnelle, mais permet-elle des données redondantes/non normalisées?
par exemple, disons que j'ai des données historiques sur les ventes (produit, ville, # ventes). Je comprends que le suivant serait un relationnel de point de vue:
Product | City | # Sales Apples, San Francisco, 400 Apples, Boston, 700 Apples, Seattle, 600 Oranges, San Francisco, 550 Oranges, Boston, 500 Oranges, Seattle, 600
alors que ce qui suit est un plus dimensionnel point de vue:
Product | San Francisco | Boston | Seattle Apples, 400, 700, 600 Oranges, 550, 500, 600
mais il semble que les deux points de vue seraient néanmoins mis en œuvre dans un schéma stellaire identique:
Fact table: Product ID, Region ID, # Sales Product dimension: Product ID, Product Name City dimension: City ID, City Name
et ce n'est que lorsque vous commencez à ajouter des détails supplémentaires à chaque dimension que les différences commencent à apparaître. Par exemple, si vous voulez suivre les régions aussi, une base de données relationnelle aurait tendance à avoir une table de région séparée, afin de garder tout normalisé:
City dimension: City ID, City Name, Region ID Region dimension: Region ID, Region Name, Region Manager, # Regional Stores
Tout en un dimensions la base de données permettrait la dénormalisation pour garder les données de la région dans la dimension de la ville, afin de rendre plus facile de trancher les données:
City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores
Est-ce correct?
4 réponses
un schéma d'étoile se trouve vraiment à l'intersection du modèle relationnel des données et du modèle dimensionnel des données. C'est vraiment une façon de commencer avec un modèle dimensionnel, et le mapping en tables de SQL qui ressemblent un peu les tables de SQL que vous obtenez si vous commencez à partir d'un modèle relationnel.
je dis un peu ressemblent parce que beaucoup de méthodologies de conception relationnelle résultent en une conception normalisée, ou au moins une conception presque normalisée. Un schéma en étoile aura des départs de la normalisation.
tout écart par rapport à la normalisation complète comporte une anomalie de mise à jour de données conséquente. (J'inclus des anomlaies sur les opérations d'insertion, de mise à jour et de suppression sous un parapluie). Ces anomalies n'ont rien à voir avec le modèle de données avec lequel vous avez commencé.
Les commentaires sur OLTP rapport OLAP est pertinente ici. Les anomalies de mise à jour auront des impacts différents sur la performance et/ou la difficulté de programmation dans ces deux situation.
en plus d'un schéma d'étoile dans une base de données SQL, il y a des produits de base de données dimensionnels là-bas qui stockent des données dans une forme physique qui est unique à ce produit. Avec ces produits, vous ne voyez pas un schéma d'étoile autant que vous voyez une implémentation directe du modèle dimensionnel, et une interface qui pourrait être propre au produit. Certaines de ces interfaces permettent aux opérations OLAP d'être complètement pointées et cliquées.
tout comme une digression de votre question, j'ai une fois construit un schéma d'étoile comme une étape intermédiaire entre une base de données OLTP qui a soutenu une application basée sur la transaction et un datacube à L'intérieur de Cognos PowerPlay. En utilisant les techniques ETL standard, le transfert combiné de la base de données OLTP vers le schéma stellaire, puis du schéma stellaire vers le cube de données, a en fait dépassé le transfert direct de la base de données OLTP vers le datacube. Ce résultat était inattendu.
J'espère que cela vous aidera.
en termes simples, les bases de données normalisées OLTP sont conçues avec le point de vue "transactionnel" le plus optimal. Les bases de données sont normalisées pour fonctionner de façon optimale à un système transactionnel. Quand je dis optimisation du système transactionnel, je veux dire ..accéder à un État de conception de la structure de la base de données où toutes les opérations transactionnelles comme supprimer,insérer, mettre à jour et sélectionner sont équilibrées pour donner une importance égale ou optimale à chacun d'eux à tout moment...comme ils sont également évalués dans une transaction système.
et c'est ce qu'offre un système normalisé ..mises à jour minimales possibles pour une mise à jour des données,insertion minimale possible pour une nouvelle entrée,suppression d'un endroit pour la suppression d'une catégorie, etc. (p. ex. nouvelle catégorie de produits )...tout cela est possible une branche nous créons des tables maîtresses.....mais c'est au prix de "sélectionner" opération de retard ..mais comme je l'ai dit son (normalisation) pas le modèle le plus efficace pour toutes les opérations ..son "Optimale"...cela dit nous avons d'autres méthodes pour améliorer la récupération de données vitesse..comme l'indexation, etc
d'autre part, le modèle dimensionnel (principalement utilisé pour la conception de la maison)..destiné à donner de l'importance à un seul type d'opérations thats sélection de données...comme dans les maisons de données ..la mise à jour/insertion des données se produit périodiquement ..et ses un coût.
donc si l'on essaye de modifier la structure de données normalisées de sorte que seule la sélection est l'opération la plus importante à tout moment ...nous finirons par être dénormalisés (je dirais partiellement dénormalisé)..structure stellaire dimensionnelle.
- toutes les clés étrangères à un seul endroit
- aucune dimension à joindre dimension (c.-à-d. le maître à la table de maître jointure)..le flocon de neige représente la même dimension
- idéalement, les faits ne portent que des chiffres ..mesures ou clés étrangères--12-->
- dimension sont utilisés pour transporter de la description et non agrégées info
- la redondance des données est ignorée ...mais dans de rares cas, si les Dimensions elles-mêmes grandissent trop .la conception de flocons de neige est considérée comme une option..mais c'est encore évitable
pour plus de détails, veuillez consulter les livres détaillés sur ce sujet.
je viens tout juste de lire sur la différence entre la modélisation de données dimensionnelles et relationnelles puisque nous utilisons principalement des modèles relationnels à mon entreprise où nous stockons un entrepôt de données D'entreprise (EDW).
selon Steve Hoberman dans son livre "Data Modeling Made Simple" la distinction entre les 2 types de modèles est la suivante:
- Relationnelle des Modèles de Données de capture de la solution d'affaires pour une partie de l'entreprise, un.k.une entreprise processus
- les Modèles de données dimensionnels permettent de saisir les détails dont l'entreprise a besoin pour répondre aux questions sur son rendement
on peut avancer qu'un modèle relationnel peut aussi servir de base pour répondre à des questions d'affaires, mais au niveau tactique. "Combien de commandes sont dans une vaine état pour le client x en raison de crédit?"Mais la distinction est celle de l'endroit où la question de rapport a besoin du "grain indigène" du tableau et quand le reporting question peut être répondue avec des données résumées.
dans vos 2 exemples ci-dessus, ce sont en fait les deux exemples de modélisation dimensionnelle de données puisqu'aucun des 2 tableaux ne stocke la commande de vente à son "grain natif", et donc ne saisit pas le processus d'affaires de la création d'une commande de vente. La seule différence entre les deux tableaux est que dans le deuxième tableau, la dimension de la ville a été transposée dans le tableau factuel.
j'ai trouvé la description que j'ai trouvé sur http://www.orafaq.com/node/2286 pour être très utile lors de la venue de la star du schéma à partir d'une perspective relationnelle.
envisager un modèle de données entièrement normalisé. Maintenant pensez exactement le contraire, où vous dénormalisez complètement votre modèle de données relationnelles de sorte que vous avez seulement un enregistrement plat comme un grand tableur ol avec une rangée très large. Maintenant, revenez en arrière de cet enregistrement plat juste un peu de sorte que vous avez un modèle de données c'est seulement deux niveaux de profondeur; une grande table, et plusieurs petites tables que la grande table renvoie. C'est un schéma en ÉTOILE. Ainsi, un vrai modèle de données stellaires a deux attributs, il est toujours à deux niveaux de profondeur, et un vrai modèle stellaire ne contient toujours qu'une seule grande table qui est au centre du modèle.