Bases de données relationnelles ou dimensionnelles, quelle est la différence?
J'essaie d'en savoir plus sur OLAP et l'entreposage de données, et je suis confus quant à la différence entre la modélisation relationnelle et dimensionnelle. La modélisation dimensionnelle est-elle essentiellement une modélisation relationnelle, mais permettant une redondance/non normalisée Les données?
Par exemple, supposons que j'ai des données historiques sur les ventes (produit, ville, # ventes). Je comprends que ce qui suit serait un point de vue relationnel:
Produit | Ville | # Ventes Pommes, San Francisco, 400 Pommes, Boston, 700 Pommes, Seattle, 600 Oranges, San Francisco, 550 Oranges , Boston, 500 Oranges, Seattle, 600
Alors que ce qui suit est un point de vue plus dimensionnel:
Produit | San Francisco | Boston | Seattle Pommes, 400, 700, 600 Oranges, 550, 500, 600
Mais il semble que les deux points de vue seraient néanmoins implémentés dans un schéma en étoile identique:
Tableau de faits: ID produit, ID région, # Ventes Dimension produit: ID produit, nom produit Dimension ville: ID ville, nom ville
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 vouliez également suivre les régions, une base de données relationnelle aurait tendance à avoir une table de régions distincte, afin de garder tout normalisé:
Dimension de ville: ID de ville, nom de ville, ID de région Dimension de région: ID de région, nom de région, gestionnaire de région, # magasins régionaux
Alors qu'une base de données dimensionnelle permettrait à la dénormalisation de conserver les données de la région à l'intérieur de la dimension de la ville, afin de faciliter la découpe des données:
Dimension de la ville: identifiant de la ville, nom de la ville, nom de la région, gestionnaire de région, # magasins régionaux
Est-ce correct?
Un schéma en étoile se situe 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 de le mapper dans des tables SQL qui ressemblent un peu aux tables SQL que vous obtenez si vous commencez à partir d'un modèle relationnel.
Je dis quelque peu ressembler parce que de nombreuses méthodologies de conception relationnelle aboutissent à une conception normalisée, ou au moins une conception presque normalisée. Un schéma en étoile s'écartera considérablement de la normalisation complète.
Chaque dérogation à la normalisation complète entraîne une anomalie de mise à jour des données conséquente. (J'inclus des anomalies sur les opérations d'insertion, de mise à jour et de suppression sous un même parapluie). Ces anomalies n'ont rien à voir avec le modèle de données avec lequel vous avez commencé.
Le commentaire sur OLTP versus OLAP est pertinent ici. Les anomalies de mise à jour auront des impacts différents sur les performances et/ou les difficultés de programmation dans ces deux situations.
En plus d'un schéma en étoile dans une base de données SQL, il existe des produits de base de données dimensionnels qui stockent les données sous une forme physique unique à ce produit. Avec ces produits, vous ne voyez pas un schéma en étoile autant que vous voyez une implémentation directe du modèle dimensionnel et une interface qui peut être particulière au produit. Certaines de ces interfaces permettent aux opérations OLAP d'être entièrement pointer-cliquer.
Tout comme une digression de votre question, j'ai déjà construit un schéma en étoile comme étape intermédiaire entre une base de données OLTP qui prend en charge une application basée sur les transactions et un cube de données dans Cognos PowerPlay. À l'aide de techniques ETL standard, le le transfert combiné de la base de données OLTP vers le schéma en étoile, puis du schéma en étoile vers le cube de données a surpassé le transfert direct de la base de données OLTP vers le cube de données) C'était un résultat inattendu.
J'espère que cela t'aides.
En termes simples OLTP la base de données normalisée est conçue avec le point de vue "transactionnel" le plus optimal. Les bases de données sont normalisées pour fonctionner de manière optimale avec un système transactionnel. Quand je dis optimisation du système transactionnel, je veux dire .. à un état de conception de la structure de base de données où toutes les opérations transactionnelles telles que supprimer, insérer, mettre à jour et sélectionner sont équilibrées pour donner une importance égale ou optimale à toutes à tout moment ... car elles sont également valorisées dans un système transactionnel.
Et c'est ce que propose 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 seul endroit pour la suppression de catégorie, etc. (par exemple, nouvelle catégorie de produit) ... tout cela est possible si nous branchons un maître de création tableaux ..... mais cela se fait au prix d'un retard de fonctionnement "select" ..mais comme je l'ai dit, son modèle (de normalisation) n'est pas le plus efficace pour toutes les opérations .. son "Optimal" ... ayant dit que nous obtenons d'autres méthodes pour améliorer la vitesse de récupération des données ... comme l'indexation, etc.
D'un autre côté, le modèle dimensionnel (principalement utilisé pour la conception des entrepôts de données) .. destiné à donner de l'importance à un seul type d'opérations qui est la sélection des données ... comme dans les entrepôts de données .. la mise à jour/insertion des données se produit périodiquement. .et c'est un coût unique.
Donc, si l'on essaie de modifier la structure de données normalisée afin que seule la sélection soit l'opération la plus importante à tout moment ... nous finirons par obtenir une structure d'étoiles dimensionnelle dénormalisée (je dirais partiellement dénormalisée).
- toutes les clés étrangères un seul endroit Fait -pas de dimension à jointure de dimension (c'est-à-dire jointure de table maître à maître) .. flocon de neige représente la même dimension
- les faits idéalement conçus ne comportent que des chiffres ... des mesures ou des clés étrangères
- les dimensions sont utilisées pour transporter la description et les informations non agrégables
- la redondance des données est ignorée ... mais dans de rares cas si les dimensions elles-mêmes augmentent trop. la conception de flocons de neige est considérée comme une option ... mais cela est toujours évitable
Pour plus de détails, veuillez consulter des livres détaillés sur ce sujet.
Je viens de lire récemment la différence entre la modélisation de données dimensionnelle et relationnelle puisque nous utilisons principalement des modèles relationnels dans 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:
- Les modèles de données relationnelles capturent la solution métier pour le fonctionnement d'une partie de l'entreprise, alias un processus métier
- Les modèles de données dimensionnelles capturent les détails dont l'entreprise a besoin pour répondre aux questions sur ses performances.
On peut faire valoir qu'un modèle relationnel peut également être utilisé comme fondement sur lequel répondre à des questions commerciales, mais au niveau tactique. "Combien de commandes sont en attente pour le client x en raison d'un blocage de crédit?" Mais la distinction est celle de l'endroit où la question de déclaration a besoin du "grain natif" du tableau et du moment où la question de déclaration peut être répondue avec des données résumées.
Dans vos 2 exemples ci-dessus, ils sont en fait les deux exemples de modélisation de données dimensionnelles car aucune des 2 tables ne stocke la commande client à son `` grain natif '', et ne capture donc pas le processus métier de création d'une commande client. La seule différence entre les 2 tableaux est que dans le 2ème tableau la dimension de la ville a été transposée dans le tableau des faits.
J'ai trouvé la description que j'ai trouvée sur http://www.orafaq.com/node/2286 pour être très utile lorsque j'arrivais aux schémas en étoile d'un point de vue relationnel.
Prenons un modèle de données entièrement normalisé. Pensez maintenant exactement à l'opposé, où vous dénormalisez complètement votre modèle de données relationnel de sorte que vous n'avez qu'un seul enregistrement plat comme une feuille de calcul big'ol avec une ligne très large. Maintenant, sauvegardez un peu cet enregistrement plat pour avoir un modèle de données qui ne soit qu'à deux niveaux de profondeur; une grande table et plusieurs petites tables vers lesquelles pointe la grande table. Il s'agit d'un schéma STAR. Ainsi, un véritable modèle de données d'étoiles a deux attributs, il a toujours deux niveaux de profondeur et un véritable modèle d'étoiles ne contient toujours qu'une seule grande table qui fait l'objet du modèle.