2010-07-06 10 views
3

У меня есть приложение, которое, как я знаю, создаст отличный куб и будет полезно для более чем стандартных отчетов Reporting Services. Мы собираемся перейти к BI-материалу с консультантом, но я бы хотел сделать это, прежде чем мы это сделаем, в основном, поэтому я знаю кое-что о том, что мы собираемся делать.Что такое Dim, что такое Факт?

Приложение отслеживает обследования в домах престарелых по всей стране. Они могут быть годовыми, жалобами или несколькими другими типами опросов, у них есть наказания, связанные с указанными тегами, и с документацией, связанной с ними.

Что бы я хотел сделать, это придумать способ, который позволит нам использовать данные, которые у нас есть, - сколько тегов во Флориде в июне месяце? Сколько объектов было своевременно доставлять свою документацию? Сколько ежегодных (сюрпризов) опросов произошло в I квартале этого года по сравнению с прошлым годом?

Я включаю схемы в надежде, что кто-то сможет сказать мне не только то, что является тусклым, а то, что есть факт, но какие данные идут туда. Я полагаю, что это будет отличное начало.

Все, что было бы действительно полезно. Я пытаюсь создать небольшой набор данных, созданный в то время как я наливаю через набор инструментов Lifecycle Lifecycle Data Warehouse Tool by Kimball.

Спасибо! M @

Платформа Entity таблицы - список всех наших объектов: Первичный ключ представляет собой пять буквенный код, обозначающий здание

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] 

Sur Вея Файлы

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] 

ответ

1

Это довольно важная задача для форума поддержки, поэтому я остановлюсь только на одной части проблемы. Кажется, что один опрос может состоять из нескольких посещений, поэтому я бы предложил factSurveyVisit с зерном одного посещения-события. Столбец SurveyID действует как вырожденное измерение в этой модели и является общим для всех посещений одного и того же опроса. SurveyVisitSequenceID - это уникальный автоинкремент (целое число) и используется для упрощения связывания двух таблиц моста для документов и тегов в таблице фактов.

Вы также можете сделать опрос в полном размере dimSurvey, чтобы добавить примечания и т. Д .; использование SurveyID для link.

Я не решать штрафы здесь, для этого я хотел бы предложить factFine таблицу, которая будет иметь свои собственные ссылки на dimDate, dimTime, dimFacility и т.д., так что отчеты о штрафах ($$) может выполняться быстро, не присоединяясь к большинству таблиц, связанных с посещением. Также должен быть стол для моста, соединяющий factFine до factSurveyVisit, предоставляя штрафы, связанные с каждым посещением, а не с полным опросом.

survey_model_6

EDIT

Просто заметил, что ваш Tag таблица date_cleared, поэтому по общему признанию, я не понимаю, мечение в этом бизнесе. В модели dimTag - это всего лишь список доступных тегов. Может быть еще factFacilityStatus таблица linking dimFacility и dimTag, статус отслеживания тегов для каждого объекта.

+0

Дамир, я полностью согласен. Я не так много искал ответа, а не поднимал ключевые слова, чтобы понять или темы, чтобы охватить мой мозг. Я никогда не видел зерна или моста, но я думаю, что я понимаю их как способ объединить данные. Идет, чтобы налить вашу информацию, спасибо за визуальные эффекты! –

6

То, что я хотел бы сделать, это придумать способ, который позволит нам использовать данные у нас есть - сколько тегов во Флориде в июне месяце? Сколько объектов было своевременно доставлять свою документацию? Сколько ежегодных (сюрпризов) опросов произошло в I квартале этого года по сравнению с прошлым годом?

A размер - диапазон измерения. Диапазон измерения может быть непрерывным, например, датами или дискретными, такими как объекты. В ваших вопросах размеры - это объект и дата, дата/время и дата, соответственно.

Единственный способ ответить на вопрос «Сколько меток во Флориде в июне месяце?» - связывать теги с объектами и тегами с датами.

Единственный способ ответить на вопрос «Сколько объектов было своевременно доставлять свою документацию?» заключается в том, чтобы связать доставку документации с объектом и датой, связанной с объектом.

Вы должны следовать этому же аналитическому процессу с остальными вопросами или запросами, которые вы ожидаете от хранилища данных.

A факт является сущностью или объектом. Тег - это факт. Доставка документации - факт. Факты практически всегда неизменяемы в хранилище данных после их загрузки.

Что касается вашей схемы, я должен изучить ее более подробно, чтобы дать конкретные рекомендации, но в целом вы хотите использовать star schema. Центр звезды (ов) - это ваши факты, сущности и объекты. Таблицы, составляющие точки звезды, являются вашими таблицами измерений.

Первое, что вам нужно сделать, это разделить ваши факты и ваши измерения. Ни одна из таблиц вашей сущности не должна содержать даты, коды местоположения или все, что вы определяете, это измерение. Однако ваши таблицы фактов будут содержать внешние ключи для таблиц даты, таблиц местоположения или других таблиц измерений.

Вам также понадобятся сводные таблицы. Сводные таблицы содержат те же столбцы, что и ваши таблицы фактов, с добавлением одной или нескольких сумм в разных измерениях. Например, вопрос «Сколько тегов во Флориде в июне месяце?» можно ответить гораздо быстрее, если у вас уже есть сумма тегов для Флориды (или, вернее, каждого объекта во Флориде) за месяц (или каждый день) июня 2010 года.

Период, в течение которого вы sum for зависит от сочетания запросов, которые вы ожидаете. В вашем хранилище данных день может быть слишком коротким. Другими словами, так же быстро сделать сводку в SQL, поскольку она предназначена для выбора итоговой строки.

Вам понадобится calendar table. В таблице календаря возникают такие вопросы, как «Сколько ежегодных (сюрпризов) опросов произошло в I квартале этого года по сравнению с (1-м кварталом) в прошлом году?» гораздо проще запросить.

+0

Gilbert, Вау, большое вам спасибо за это, это действительно очистило многое для меня. Я собираюсь потратить некоторое время на этой неделе, чтобы действительно вникать в это, я постараюсь поделиться своими выводами, если вы не возражаете :) спасибо! M @ –

+0

Нет, я не возражаю и приветствую вас. –

+0

Я немного смущен. Основная часть здесь - опрос. В каждом опросе могут быть теги, если что-то происходит плохо. Будет ли информация обследований и информация тегов отдельными таблицами фактов? Давайте сделаем шаг назад и упростим - скажем, я хочу просто отслеживать количество опросов на объект. Вся эта информация содержится в таблице SurveyMain. Я бы установил таблицу календаря, факт опроса и тусклый стол объекта, правильно? Исследуемый факт, который я бы заполнил фактическим типом опроса вместо fk в другой таблице, правильно? Я направляюсь в правильном направлении? –

1

Похоже, у вас есть несколько штрафов, файлов и тэгов для каждого опроса.

Я бы ожидал, что 4 таблицы фактов - с фактами в каждом, которые выглядят так, как будто они в основном датируют данные (хотя они часто моделируются как роли даты и/или времени - здесь я сделал пару заметок, но флаги, как правило, будет в размерах):

SurveyMain

SurveyFine (wasImposed находится в измерении, связанный с этим, totalFineAmt факт в этой таблице)

SurveyFile

SurveyTag

Все они будут обладать измерением Survey, и я бы пошел дальше и разделил измерение Entity/Facility в каждом из них. Вы можете прокручивать снежинки через измерение Survey, но это побеждает наиболее выгодный момент звездных моделей, позволяя вам получить все данные напрямую, а не идти за мостиковыми таблицами.

У вас есть возможность поместить тип опроса в его собственное измерение (или размер мусора, возможно) или получить его через измерение съемки (не через снежинки).Это типично для моделирования размеров - вам не нужно следить за вашими сущностями - вам просто нужно избегать слишком большого количества измерений и слишком мало размеров ловушки и следить за мощностью ваших измерений, особенно если вы случайно включили некоторые вырожденные размеры, такие как номер счета-фактуры, который изменяется с каждым фактом и поэтому должен храниться в таблице фактов.

На самом деле, иногда бывает проще делать ваши звездные модели, выполняя типичные объединения в вашем 3NF, которые создают типичные плоские отчеты, а затем просто берут эти плоские ряды и превращают их в звезды. (Вот как мало имеет отношение модель сущностных отношений к размерной модели). Таким образом, вы можете присоединиться к SurveyMain к SurveyTypes и SurveyFine по вашим текущим нормализованным ключам и посмотреть все столбцы. Это послужило бы основой для таблицы фактов SurveyFine. То же самое для других таблиц фактов, которые я определил. Общий материал будет кандидатом для общих измерений. Сущность является хорошим кандидатом для согласованного измерения (т. Е. Она будет использоваться совместно с этими моделями опроса и другими моделями, связанными с вашими корпоративными моделями HR или моделью учета).

1

Я бы установил таблицы фактов SurveyFines, SurveyTag и SurveyFiles, они все разные зерна фактов, и все они представляют собой самое низкое зерно.

Все они имеют дату, сущность и размеры съемки с ними.

Я бы установил предварительно агрегированные метрические таблицы для тех показателей, которые могут потребовать объединения всех трех фактов.

Если вы хотите, чтобы я разработал, не стесняйтесь спрашивать. Сегодня я немного поторопился.

(продолжение ...) Мне кажется, что ваши пользователи хотят поворачивать измеряемые данные (количество файлов, дата файлов отправлено, сумма штрафов). Они хотят посмотреть эти показатели по атрибутам опроса. Вот почему я предлагаю измерение опроса.

Учитывая ваш комментарий ниже, я мог бы затем построить предварительно суммарную метрическую таблицу,

Дата (дата я загружен метрическую таблицу) SurveyDimID EntityDimID NumTagsAssigned NumFilesRequested NumFilesReceived NumFines TotalFines и т.д. ...

Я бы ежедневно загружал эту таблицу с полным набором активных данных опроса из моих таблиц фактов. Это позволяет пользователям идти туда и обратно по истории, чтобы увидеть, как вошла съемка.

Я предполагаю, что в какой-то момент весь процесс обследования будет завершен, и в этот момент эти записи не будут включены в метрическую нагрузку. (Они останутся в фактах).

+0

Итак, вы говорите, что само исследование - это измерение? Способ, которым он работает, - это опрос, оценка тегов и штрафы, назначенные этим тегам. Файлы - это то, что необходимо для завершения процесса. file1 - это то, что посылает нам правительство. file2 - наш ответ обратно в правительство. Основная причина этого заключается в том, чтобы оценить, сколько времени требуется для получения файлов, чего нет и сколько времени требуется для ответа на правительство/штат/уезд. Мне бы хотелось, чтобы наши люди хорошо знали, что произошло исторически. думаю, что я смогу получить государственные и федеральные данные, чтобы сравнить их со временем. –

+0

Привет, Мэтт, я немного обновил ответ. Одним из показателей в таблице примеров может быть daysToRespond и т. Д. – Markus

Смежные вопросы