3

私は、優れたキューブを作成し、標準のフラットな Reporting Services レポート以外にも役立つことがわかっているアプリケーションを持っています。コンサルタントと一緒に BI の作業に取り掛かろうとしていますが、その前に試してみたいと思っています。

このアプリケーションは、全国の老人ホームでの調査を追跡します。年次、苦情、またはその他のいくつかの種類の調査である可能性があり、指定されたタグに関連付けられたペナルティがあり、それらに関連付けられたドキュメントがあります。

私がやりたいことは、私たちが持っているデータを活用できるようにする方法を考え出すことです.6月にフロリダにいくつのタグがありましたか? 書類を時間通りに配達した施設はいくつありましたか? 昨年と比較して、今年の第 1 四半期に行われた年次 (サプライズ) 調査の数は?

何が曖昧で何が事実なのかだけでなく、どのデータがどこにあるのかを誰かが教えてくれることを期待して、スキーマを含めています。素晴らしいスタートになると思います。

何でも本当に役に立ちます。Kimball の Data Warehouse Lifecycle Toolkit を使って、小さなデータ マートをセットアップしようとしています。

ありがとう!M@

エンティティ テーブル - すべての施設のリスト: 主キーは、建物を示す 5 文字のコードです。

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]

調査メイン

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]

アンケートの種類:

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]

調査ファイル

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]

調査の罰金

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]

調査タグ

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]
4

4 に答える 4

6

私がやりたいことは、私たちが持っているデータを活用できるようにする方法を考え出すことです.6月にフロリダにいくつのタグがありましたか? 書類を時間通りに配達した施設はいくつありましたか? 昨年と比較して、今年の第 1 四半期に行われた年次 (サプライズ) 調査の数は?

寸法は測定範囲です。測定範囲は、日付のように連続的なものにすることも、施設のように離散的にすることもできます。あなたの質問では、ディメンションはそれぞれ施設と日付、日付/時刻、および日付です。

「6 月のフロリダ州のタグ数は?」という質問に答える唯一の方法は? タグを施設に、タグを日付に関連付けることです。

「ドキュメントを時間通りに配達した施設はいくつありましたか?」という質問に答える唯一の方法は? 文書の送付を施設に関連付け、期日を施設に関連付けることです。

データ ウェアハウスが回答すると予想される残りの質問やクエリについても、この同じ分析プロセスに従う必要があります。

ファクトは、エンティティまたはオブジェクトです。タグは事実です。ドキュメントの配信は事実です。ファクトは、一度読み込まれると、ほとんどの場合、データ ウェアハウスで不変になります。

あなたのスキーマに関しては、具体的な推奨事項を提供するためにもっと研究する必要がありますが、一般的にはスタースキーマを使用したいと考えています。星の中心は、事実、エンティティ、およびオブジェクトです。星のポイントを構成するテーブルは、ディメンション テーブルです。

最初に行う必要があるのは、事実とディメンションを分離することです。エンティティ テーブルには、日付、場所コード、またはディメンションであると判断したものを含めないでください。ただし、ファクト テーブルには、日付テーブル、ロケーション テーブル、またはその他のディメンション テーブルへの外部キーが含まれます。

おそらく、要約表も必要になるでしょう。サマリー テーブルには、ファクト テーブルと同じ列が含まれ、異なるディメンション間で 1 つ以上の合計が追加されます。例として、「6 月のフロリダ州のタグ数は?」という質問があります。2010 年 6 月の 1 か月 (または各日) のフロリダ (または、より正確には、フロリダの各施設) のタグの合計が既にある場合は、はるかに迅速に回答できます。

合計する期間は、予想されるクエリの組み合わせによって異なります。データ ウェアハウスでは、1 日が短すぎる場合があります。つまり、SQL で集計を実行するのは、集計行を選択するのと同じくらい迅速です。

カレンダー表も必要です。カレンダー テーブルは、「昨年の (第 1 四半期) と比較して、今年の第 1 四半期に行われた年次 (サプライズ) 調査の数は?」のような質問をします。クエリがはるかに簡単になります。

于 2010-07-09T15:50:36.287 に答える
1

調査ごとに複数の罰金、ファイル、タグがあるようです。

私は4つのファクトテーブルを期待します-それぞれのファクトは主に日時データのように見えます(これらは多くの場合、日付や時刻のディメンションの役割としてモデル化されていますが-ここでいくつかメモしましたが、フラグは一般的に進んでいます寸法になります):

SurveyMain

SurveyFine(wasImposedはこのファクトにリンクされたディメンションにあり、totalFineAmtはこのテーブルのファクトです)

SurveyFile

SurveyTag

それらはすべて調査ディメンションを共有し、私は先に進んで、それぞれのエンティティ/施設ディメンションを共有します。サーベイディメンションを介してスノーフレークすることもできますが、それはスターモデルの最も有益なポイントを打ち負かし、ブリッジテーブルを経由せずにすべてのデータに直接アクセスできるようにします。

調査タイプを独自のディメンション(またはジャンクディメンション)に配置するか、調査ディメンション(スノーフレークではなく)からアクセスするかを選択できます。これは、ディメンションモデリングでは一般的です。エンティティを追跡する必要はありません。ディメンションが多すぎたり少なすぎたりしないようにするだけで、ディメンションのカーディナリティを監視できます。特に、誤って縮退したディメンションを含めた場合は、ファクトごとに変化する請求書番号は、ファクトテーブルに保存する必要があります。

実際、3NFで通常の結合を実行して、通常のフラットなレポートビューを作成し、それらのフラットな行を取得してスターに変換する方が、スターモデルを作成する方が簡単な場合があります。(これは、実体関連モデルが実際に次元モデルとほとんど関連性がないことです)。したがって、現在の正規化されたキーでSurveyMainをSurveyTypesおよびSurveyFineに結合し、すべての列を確認することができます。これがSurveyFineファクトテーブルの基礎になります。私が特定した他のファクトテーブルについても同様です。共有されたものは、共有されたディメンションの候補になります。エンティティは、適合ディメンションの適切な候補です(つまり、これらの調査モデルと、HRモデルや会計モデルなどの企業に関連する他のモデルとの間で共有されます)。

于 2010-07-13T18:26:02.337 に答える
1

SurveyFines、SurveyTag、SurveyFiles ファクト テーブルをセットアップします。これらはすべて異なる粒度のファクトであり、すべて最小粒度を表します。

それらにはすべて、日付、エンティティ、および調査ディメンションが含まれます。

次に、3 つの事実すべてを組み合わせる必要がある可能性があるメトリックに対して、事前に集計されたメトリック テーブルをセットアップします。

詳しく説明してほしい場合は、お気軽にお尋ねください。今日はちょっと急いでいます。

(続き...) ユーザーが測定可能なデータ (ファイルの数、ファイルが送信された日付、罰金の合計) をピボットしたいと私には思えます。彼らは、調査の属性別にこれらのメトリックを確認したいと考えています。そのため、アンケート ディメンションをお勧めします。

以下のコメントを考慮して、事前集計メトリックテーブルを作成する可能性があります。

日付 (メトリック テーブルをロードした日付) SurveyDimID EntityDimID NumTagsAssigned NumFilesRequested NumFilesReceived NumFines TotalFines など...

このテーブルには、ファクト テーブルからのアクティブな調査データの完全なセットを毎日ロードします。これにより、ユーザーは履歴を行ったり来たりして、調査がどのように行われたかを確認できます。

ある時点で調査プロセス全体が完了すると思いますが、その時点で、それらのレコードはメトリック ロードに含まれません。(彼らは事実にとどまるでしょう)。

于 2010-07-13T20:30:32.267 に答える
1

これはサポート フォーラムにとってかなりの作業なので、問題の一部だけに焦点を当てます。1 つの調査は複数の訪問で構成されている可能性があるようです。列SurveyIDは、このモデルの縮退ディメンションとして機能し、同じ調査からのすべての訪問に共通です。SurveyVisitSequenceIDは一意の自動インクリメント (整数) であり、ドキュメントとタグの 2 つのブリッジ テーブルをファクト テーブルに簡単にリンクするために使用されます。

また、調査を完全な次元のdimSurveyに昇格させて、いくつかのメモなどを追加することもできます。リンクにはSurveyIDを使用します。

ここでは罰金には取り掛かりませんでした。これは、訪問関連のほとんどのテーブルに参加しなくても、罰金 ($$) に関するレポートをすばやく作成できるように、 dimDate 、 dimTime 、 dimFacility など独自リンクを持つfactFineテーブルをお勧めします。 . また、 factFinefactSurveyVisitに結合するブリッジ テーブルも必要です。罰金は、完了した調査ではなく、各訪問に関連しています。

調査_モデル_6

編集

Tagテーブルに date_cleared があることに気付きました。このビジネスでのタグ付けについては理解できません。モデルでは、dimTagは使用可能なタグの単なるリストです。dimFacilitydimTagをリンクするfactFacilityStatusテーブルがもう 1 つある場合があり、各施設のタグ ステータスを追跡します。

于 2010-07-17T16:05:30.390 に答える