2010-07-06 8 views
3

J'ai une application qui, je le sais, ferait un grand cube et serait utile pour bien plus que le rapport standard de Reporting Services. Nous sommes sur le point de nous lancer dans des affaires de BI avec un consultant, mais j'aimerais essayer avant de le faire, surtout pour savoir ce que nous allons faire.qu'est-ce que Dim, qu'est ce que c'est?

L'application suit les enquêtes dans les maisons de soins infirmiers à travers le pays. Ils peuvent être annuels, plainte, ou plusieurs autres types d'enquête, ils ont des sanctions associées à des étiquettes données, et ont une documentation qui leur est associée.

Ce que je voudrais faire est de trouver un moyen qui nous permettra de tirer parti des données que nous avons - combien de tags en Floride pour le mois de Juin? Combien d'installations ont livré leur documentation à temps? Combien d'enquêtes annuelles (surprises) ont eu lieu au premier trimestre de cette année par rapport à l'année dernière?

J'inclus les schémas dans l'espoir que quelqu'un sera capable de me dire non seulement ce qui est sombre et ce qui est un fait, mais quelles données vont où. Je pense que ce sera un bon début.

Tout serait vraiment utile. J'essaie de mettre en place un petit magasin de données pendant que j'utilise le Data Warehouse Lifecycle Toolkit de Kimball.

Merci! M @

Le tableau entité - une liste de toutes nos installations: clé primaire est un code à cinq lettres désignant le bâtiment

CREATE TABLE [dbo].[Entity](
[entID] [varchar](10) NOT NULL, 
[entShortName] [varchar](150) NULL, 
[entNumericID] [int] NOT NULL, 
[orgID] [int] NOT NULL, 
[regionID] [int] NOT NULL, 
[portID] [int] NOT NULL, 
[busTypeID] [int] NOT NULL, 
[adpID] [varchar](50) NULL, 
[eHealthDataID] [varchar](50) NULL, 
[updateDate] [datetime] NULL CONSTRAINT [DF_Entity_updateDate] DEFAULT (getdate()), 
[powProID] [int] NULL, 
[regionReportingID] [int] NULL, 
[regionPresEmail] [varchar](300) NULL, 
[regionClinDirEmail] [varchar](300) NULL, 
CONSTRAINT [PK_EntityNEW] PRIMARY KEY CLUSTERED 
(
[entID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 75) ON [PRIMARY] 
) ON [PRIMARY] 

enquête principale

CREATE TABLE [dbo].[surveyMain](
[surveyID] [int] IDENTITY(1,1) NOT NULL, 
[surveyDateFac] AS (([facility]+'-')+CONVERT([varchar],[surveyDate],(101))), 
[surveyDate] [datetime] NOT NULL, 
[surveyType] [int] NOT NULL, 
[surveyBy] [int] NULL, 
[facility] [varchar](10) NOT NULL, 
[originalSurvey] [int] NULL, 
[exitDate] [datetime] NULL, 
[dpnaDate] AS (dateadd(month,(3),[exitDate])), 
[clearedTags] [varchar](1) NULL, 
[substantiated] [varchar](1) NULL, 
[firstRevisit] [int] NULL, 
[secondRevisit] [int] NULL, 
[thirdRevisit] [int] NULL, 
[fourthRevisit] [int] NULL, 
[updated] [datetime] NULL CONSTRAINT [DF_surveyMain_updated] DEFAULT (getdate()), 
CONSTRAINT [PK_tagSurvey] PRIMARY KEY CLUSTERED 
(
[surveyID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY] 
) ON [PRIMARY] 

Types de Levé:

CREATE TABLE [dbo].[surveyTypes](
[surveyTypeID] [int] IDENTITY(1,1) NOT NULL, 
[surveyTypeDesc] [varchar](100) NOT NULL, 
CONSTRAINT [PK_surveyTypes] PRIMARY KEY CLUSTERED 
(
[surveyTypeID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

Sur Vey Fichiers

CREATE TABLE [dbo].[surveyFiles](
[surveyFileID] [int] IDENTITY(1,1) NOT NULL, 
[surveyID] [int] NOT NULL, 
[surveyFilesTypeID] [int] NOT NULL, 
[documentDate] [datetime] NOT NULL, 
[responseDate] [datetime] NULL, 
[receiptDate] [datetime] NULL, 
[dateCertain] [datetime] NULL, 
[fileName] [varchar](250) NULL, 
[fileUpload] [image] NULL, 
[fileDesc] [varchar](100) NULL, 
[updated] [datetime] NOT NULL CONSTRAINT [DF_surveyFiles_updated] DEFAULT (getdate()), 
CONSTRAINT [PK_surveyFiles] PRIMARY KEY CLUSTERED 
(
[surveyFileID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 75) ON [PRIMARY] 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] 

Les amendes de l'enquête

CREATE TABLE [dbo].[surveyFines](
[surveyFinesID] [int] IDENTITY(1,1) NOT NULL, 
[surveyID] [int] NULL, 
[surveyFinesTypeID] [int] NULL, 
[dateRecommended] [datetime] NULL, 
[dateImposed] [datetime] NULL, 
[totalFineAmt] [varchar](100) NULL, 
[wasImposed] [varchar](3) NULL, 
[dateCleared] [datetime] NULL, 
[comments] [varchar](500) NULL, 
[updated] [datetime] NOT NULL CONSTRAINT [DF_surveyFines_updated] DEFAULT (getdate()), 
CONSTRAINT [PK_surveyFines] PRIMARY KEY CLUSTERED 
(
[surveyFinesID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 75) ON [PRIMARY] 
) ON [PRIMARY] 

Balises Enquête

CREATE TABLE [dbo].[surveyTags](
[seq] [int] IDENTITY(1,1) NOT NULL, 
[surveyID] [int] NOT NULL, 
[tagDescID] [int] NOT NULL, 
[tagStatus] [int] NULL, 
[scopesev] [varchar](5) NOT NULL, 
[comments] [varchar](1000) NULL, 
[clearedDate] [datetime] NULL, 
[updated] [datetime] NULL CONSTRAINT [DF_surveyTags_updated] DEFAULT (getdate()), 
CONSTRAINT [PK_tagMain] PRIMARY KEY CLUSTERED 
(
[seq] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY] 
) ON [PRIMARY] 

Répondre

1

C'est une tâche assez complexe pour un forum de support, je vais donc me concentrer sur une partie du problème. Il semble qu'une enquête peut se composer de plusieurs visites, donc je suggère factSurveyVisit avec un grain d'un événement-visite. La colonne SurveyID agit comme une dimension dégénérée dans ce modèle et est commune à toutes les visites d'une même enquête. Le SurveyVisitSequenceID est un auto-incrément unique (integer) et est utilisé pour simplifier la liaison des deux tables de pont pour les documents et les balises à la table de faits.

Vous pouvez également promouvoir une enquête dans une dimension complète dimSurvey pour ajouter quelques notes etc; utilisez SurveyID pour le lien.

Je n'abordaient des amendes ici, pour cela, je suggère factFine tableau qui aurait ses propres liens vers DimDate, DimTime, dimFacility, etc pour que les rapports sur les amendes ($$) peut être fait rapidement sans se joindre à la plupart des tables liées à la visite. Il doit également y avoir une table de liaison reliant factFine à factSurveyVisit, prévoyant des amendes liées à chaque visite et non à un sondage complet.

survey_model_6

EDIT

juste remarqué que votre Tag Table a date_cleared, donc il est vrai que je ne comprends pas le marquage dans cette affaire. Dans le modèle, dimTag est juste une liste de tags disponibles. Il peut y avoir une autre table factFacilityStatus reliant dimFacility et dimTag, le statut de l'étiquette de suivi pour chaque installation.

+0

Damir, je suis complètement d'accord. Je ne cherchais pas vraiment une réponse, par opposition à la levée de mots-clés à comprendre ou à des sujets pour envelopper mon cerveau. Je n'ai jamais vu de grain ou de pont utilisé, mais je pense que je les comprends comme des moyens de rassembler des données. Vous allez verser vos infos, merci pour les visuels !! –

6

Ce que je voudrais faire est de trouver un moyen qui nous permettra d'exploiter les données nous avons - combien de tags en Floride pour le mois de juin? Combien d'installations ont livré leur documentation à temps? Combien d'enquêtes annuelles (surprises) ont eu lieu au premier trimestre de cette année par rapport à l'année dernière?

Une dimension est une plage de mesure. La plage de mesure peut être continue, comme les dates, ou discrète, comme les installations. Dans vos questions, les dimensions sont la facilité et la date, la date/heure et la date, respectivement.

La seule façon de répondre à la question "Combien de tags en Floride pour le mois de juin?" est d'associer des balises à des fonctionnalités et des balises avec des dates.

La seule façon de répondre à la question "Combien d'installations étaient livrées à temps?" est d'associer la livraison de la documentation avec la facilité et la date en raison de la facilité.

Vous devez suivre le même processus analytique avec le reste des questions ou des requêtes auxquelles l'entrepôt de données doit répondre.

Un fait est une entité ou un objet. Un tag est un fait. La livraison de la documentation est un fait. Les faits sont presque toujours immuables dans un entrepôt de données une fois qu'ils sont chargés.

Quant à votre schéma, je dois étudier plus de donner des recommandations spécifiques, mais en général, vous voulez utiliser un star schema. Le centre de l'étoile (s) sont vos faits, entités et objets. Les tables qui composent les points de l'étoile sont vos tables de dimension.

La première chose que vous devez faire est de séparer vos faits et vos dimensions. Aucune de vos tables d'entités ne doit contenir de dates, de codes d'emplacement ou tout autre élément que vous déterminez comme une dimension. Toutefois, vos tables de faits contiendront des clés étrangères pour les tables de dates, les tables d'emplacement ou d'autres tables de dimension.

Vous aurez probablement aussi besoin de tables récapitulatives. Les tables récapitulatives contiennent les mêmes colonnes que vos tables de faits, avec l'ajout d'une ou de plusieurs sommes dans différentes dimensions. A titre d'exemple, la question "Combien de tags en Floride pour le mois de Juin?" peut être répondu beaucoup plus rapidement si vous avez déjà la somme des tags pour la Floride (ou, plus précisément, chaque installation en Floride) pour le mois (ou chaque jour) de Juin, 2010.

La période que vous somme pour dépend du mélange de requêtes que vous attendez. Dans votre entrepôt de données, le jour peut être une période trop courte. En d'autres termes, il est tout aussi rapide de faire le résumé en SQL que de sélectionner la ligne de résumé.

Vous aurez également besoin d'un calendar table. Un tableau de calendrier pose des questions comme: «Combien d'enquêtes annuelles (surprise) ont eu lieu au premier trimestre de cette année par rapport à (le 1er trimestre de) l'année dernière? beaucoup plus facile à interroger.

+0

Gilbert, Wow, merci beaucoup pour ça, ça m'a vraiment éclairci beaucoup de choses. Je vais prendre un peu de temps cette semaine pour vraiment creuser dans ce domaine, je vais essayer de partager mes conclusions si cela ne vous dérange pas :) merci! M @ –

+0

Non, ça ne me dérange pas, et je vous en prie. –

+0

Je suis un peu confus. La pièce principale ici est l'enquête. Chaque enquête peut avoir des tags si quelque chose de mal arrive. Les informations d'enquête et les informations d'étiquette seraient-elles des tables de faits séparées? Permettez-moi de prendre du recul et de simplifier les choses - disons que je veux juste suivre le nombre de sondages par installation. Toutes ces informations sont contenues dans la table SurveyMain. Je voudrais mettre en place une table de calendrier, le fait de l'enquête, et une table dim de l'installation, correct? Le sondage que je voudrais remplir avec le type d'enquête réelle au lieu de la fk à l'autre table, correct? Suis-je dans la bonne direction? –

1

Il semble que vous ayez plusieurs amendes, fichiers et étiquettes pour chaque enquête.

Je m'attendrais à 4 tables de faits - avec les faits dans chacun semblant être en grande partie des données datetime (bien qu'elles soient souvent modélisées comme des rôles de date et/ou de temps), j'ai fait quelques notes ici, mais drapeaux vont généralement être dans les dimensions):

SurveyMain

SurveyFine (wasImposed est dans une dimension liée à ce fait, totalFineAmt est un fait dans ce tableau)

SurveyFile

SurveyTag Ils partageraient tous une dimension d'enquête, et j'irais de l'avant et partagerais une dimension entité/installation dans chacun d'eux. Vous pouvez flotter à travers la dimension Survey, mais cela vainc le point le plus bénéfique des modèles d'étoiles vous permettant d'accéder à toutes les données directement au lieu de passer par des tables de bridge.

Vous avez la possibilité de placer le type d'enquête dans sa propre dimension (ou une dimension indésirable, peut-être) ou de l'avoir accédé via la dimension Levé (pas par un flocon de neige).C'est typique avec la modélisation dimensionnelle - vous n'avez pas besoin de suivre vos entités - vous avez juste besoin d'éviter les trop nombreuses dimensions et trop peu de dimensions piéger et regarder la cardinalité de vos dimensions - surtout si vous avez accidentellement inclus une dimension dégénérée comme un numéro de facture qui change avec chaque fait et doit donc être stocké dans la table de faits.

En fait, il est parfois plus facile de faire vos modèles d'étoile en faisant les jointures typiques dans votre 3NF qui créent des vues de rapport plat typiques et en prenant simplement ces lignes plates et les transformant en étoiles. (C'est le peu de pertinence du modèle entité-relation pour le modèle dimensionnel). Vous pouvez donc rejoindre SurveyMain à SurveyTypes et SurveyFine sur vos clés normalisées actuelles et regarder toutes les colonnes. Ce serait la base de la table de faits SurveyFine. Idem pour les autres tables de faits que j'ai identifiées. Les éléments partagés seraient candidats aux dimensions partagées. L'entité est un bon candidat pour une dimension conforme (c'est-à-dire qu'elle sera partagée entre ces modèles d'enquête et d'autres modèles liés à votre entreprise - comme les modèles RH ou les modèles comptables).

1

Je voudrais configurer les tables de faits SurveyFines, SurveyTag et SurveyFiles, ils sont tous différents grains de faits et ils représentent tous le grain le plus bas.

Ils auraient tous des dimensions de date, d'entité et de levé avec eux.

Je voudrais ensuite configurer des tables de métriques pré-agrégées pour ces métriques qui pourraient avoir besoin de combiner les trois faits.

Si vous souhaitez que je développe élaborer n'hésitez pas à demander. Je suis un peu pressé aujourd'hui.

(suite ...) Il me semble que vos utilisateurs veulent faire pivoter les données mesurables (nombre de fichiers, date d'envoi des fichiers, somme des amendes). Ils veulent examiner ces paramètres en fonction des attributs de l'enquête. C'est pourquoi je suggère une dimension d'enquête.

Compte tenu de votre commentaire ci-dessous, je pourrais alors construire une table métrique pré-agrégat,

Date (la date que j'ai chargé la table métrique) SurveyDimID EntityDimID NumTagsAssigned NumFilesRequested NumFilesReceived NumFines TotalFines etc ...

Je voudrais charger cette table tous les jours avec l'ensemble complet de données d'enquête actives de mes tables de faits. Cela permet aux utilisateurs de parcourir l'historique pour voir comment l'enquête est arrivée.

Je suppose qu'à un certain moment, le processus d'enquête complet est terminé, à ce moment-là ces enregistrements ne seraient pas inclus dans la charge métrique. (Ils resteraient dans les faits).

+0

Donc, vous dites que l'enquête elle-même est une dimension? La façon dont cela fonctionne est une enquête qui se passe, les étiquettes sont évaluées, et les amendes attribuées à ces étiquettes. Les fichiers sont ce qui est nécessaire pour terminer le processus. file1 est ce que le gouvernement nous envoie. file2 est notre réponse au gouvernement. La principale raison de cette situation est d'évaluer combien de temps il faut pour obtenir les fichiers, ce qui manque et combien de temps il faut pour répondre au gouvernement/état/comté. J'aimerais pouvoir donner à nos gens une bonne idée de ce qui s'est passé historiquement. Je pense que je peux obtenir des données nationales et fédérales pour les comparer. –

+0

Salut Matt, j'ai mis à jour la réponse un peu. L'une des mesures de la table d'exemple peut être daysToRespond et ainsi de suite. – Markus