что такое Дим, что такое Факт? - PullRequest
3 голосов
/ 06 июля 2010

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

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

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

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

Все было бы очень полезно.Я пытаюсь настроить небольшую витрину данных, пока просматриваю набор инструментов жизненного цикла хранилища данных от Kimball.

Спасибо!M @

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

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]

Survey Main

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 ]

6 голосов
/ 09 июля 2010

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 17 июля 2010

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

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

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

survey_model_6

EDIT

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

1 голос
/ 14 июля 2010

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

Все они будут иметь с собой дату, размеры объекта и опроса.

Затем я бы настроил предварительно агрегированные таблицы метрик для тех метрик, которым может потребоваться объединить все три факта.

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

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

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

Дата (дата, когда я загрузил таблицу метрик) SurveyDimID EntityDimID NumTagsAssigned NumFilesRequested NumFilesReceived NumFines TotalFines и т.д ...

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

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

1 голос
/ 13 июля 2010

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

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

SurveyMain

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

SurveyFile

SurveyTag

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

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

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

...