BI建模原则和常见问题

BI建模的质量直接影响数据仓库项目的质量,所以在建模前,要对数据仓库的架构组成、大小以及模型功能有明确的定义。

影响BI数据仓库建模的因素众多,往往会随着项目的具体情况不同而变化。但有些原则是相通的,各种项目的实施过程都需要考虑,而一些常见的、项目人员容易不解的问题也同样需要重视。

      BI建模原则

1、  围绕业务情况建模:业务需求是基础,数据仓库的数据组织是面向主题的,而不是面向报表的,是面向业务分析的主题领域的,比如常见的销售分析、合同尾款分析、客户关系分析等等。

2、  保证数据的一致性:要保证数据之间逻辑关系的正确性和完整性,数据仓库要实现对数据的集成与数据的同构性,和数据的相对稳定,为实现应用而进行实时读写操作。

3、  使用调度:数据仓库要有能反映历史变化与及时准确的数据处理能力,所以BI建模增量更新时必须使用调度,即对事实数据表进行增量更新处理。在使用调度前要考虑到实际的数据量,明确数据多久更新一次。数据量大的可以每天,那么数据可以按天抽取,或者像帆软商业智能FineBI那样,采用定时增量更新;变化不大的可以一周或是更久。如果有缓慢变化维度情况,调度时需要考虑到维度表更新情况,在更新事实数据表之前要先更新维度表。

4、  需求与现实的平衡:依据业务需求提供用户可接受BI方案,在进行BI建模时需要不断在用户需求和数据源事实之间进行平衡,不光是设计人员自身平衡,企业业务人员也同样要面对这样的现实。

      常见问题

1、  模型的设计如何入手?

BI建模的目的无非是为了提升管理水平,这也是上BI项目的核心意义所在。前期一定要了解清楚业务需求、业务范围等内容,明确企业对商业智能的期望和需要分析哪些主题。协同分析客户目前的管理水平、企业架构和运作流程,管理过程的薄弱点和关键点是什么,来帮助企业人员认识自己的需求。

2、实施忽略确认过程

很多项目人员在确认过企业需求后就觉得可以大刀阔斧地设计实施了,但在实际过程中往往遇到各种对不上的问题。究其原因在前期商讨过程中总会有遗漏,一些人员对业务也并非有深刻的理解,造成后续不断调整,项目周期拖延。所以在建模过程中,一定要不断地确认业务分析模型,数据能否支撑。好的商业智能BI项目实施,通常会充分了解数据抽取对象的业务系统,和业务人员充分沟通,与领导反复确认,避免企业后续的重复工作,加重企业负担。

本文转载自帆软商业智能FineBI: http://www.finebi.com/bi/?p=3362

时间: 2024-10-14 14:05:07

BI建模原则和常见问题的相关文章

一起学微软Power BI系列-官方文档-入门指南(3)Power BI建模

我们前2篇文章:一起学微软Power BI系列-官方文档-入门指南(1)Power BI初步介绍 和一起学微软Power BI系列-官方文档-入门指南(2)获取源数据 中,我们介绍了官方入门文档与获取数据等基本知识.今天继续给大家介绍官方文档中,最核定的一个步骤,建模,不管是在Power BI还是在Tableau中,建模都是一个必不可少的步骤,包括传统的Power Privot中,也需要建模这个过程.建模的过程是一个不断演变和需要不断总结经验的过程,和我们传统的关系类型数据库设计有一些类似. 本

软件缺陷常见问题总结(测试新手速成篇)

常见问题一: 统一性 不要在软件中使用中英文混合的提示,比如对于用户的操作提示,不要一会用"error"一会用"错误":一会用"succeed"另一会用"成功"总之要统一.某局长使用心得:删除的时候提示Error,幸亏我英语水平好,可是你换成中文不行吗? 比如在我们开发过的系统出现过: 1:operation is  succeed,具体看一下我们公司jira中哪个系统出现的问题. 2:另外,食药监项目初期阶段,日期控件有的采

OLAP -- ODS 项目总结 -- BI 中的关键

这个项目在年前已经完成,回顾起来小问题挺多.有点乱.还是从需求说起. 一.单纯讲需求每个行业的都不同.很难划一而论.总体来说也就是这几个方面 1.时间窗 常见的分类也就1类ODS ,II类ODS ,III类ODS I类ODS:与应用系统的数据延迟为1~2秒,实时或近似实时 II 类ODS:与应用系统的数据延迟为2~4小时 III类ODS:与应用系统的数据延迟为12~24小时 IV类ODS:数据仓库中部分决策分析数据回流至ODS中 数据实时性越高,越好CPU ,软件成本越高.在 选型时也不同, 如

一文读懂商业智能(BI):企业数据分析的中枢

商业智能(BI)大家可能早已耳熟能详.从早期的报表自动化,到现在的复杂灵活分析,多平台支持,优秀的人机互动,多数据抽取,大数据整合,甚至和当下最火的人工智能都有结合点.可能一提到BI,大家都会自然而然地把这个话题丢给IT.但是由IT主导的BI项目最终是否能够落地? 为什么以技术为主导的IT部门做不好BI项目? 首先我认为BI是最直接,最重要地服务于商业决策者的,尤其是管理层.BI应用是否符合用户习惯,数据是否准确及时,是BI能否活下来的关键之关键.试想一个难以操作,挤满了图表,而且错误百出的BI

Deep Learning for Natural Language Processing1

Focus, Follow, and Forward Stanford CS224d 课程笔记 Lecture1 Stanford CS224d 课程笔记 Lecture1 Stanford大学在2015年开设了一门Deep Learning for Natural Language Processing的课程,广受好评.并在2016年春季再次开课.我将开始这门课程的学习,并做好每节课的课程笔记放在博客上.争取做到每周一更吧.本文是第一篇. NLP简介 NLP,全名Natural Languag

分析模式(可复用的对象模型)- 读书笔记

读后感: Martin Fowler 20年前的书,OO和领域的思想对于今天的我们来说很基础,但在那时应该算是萌芽.Smalltalk语言简单,语法中省略空格可能因为那时的硬件设备昂贵,而不得不做出的选择,但是可读性真的很差,而书中基本是用Smalltalk进行示例.翻开这本书是为了查找财务模型,它没有让我失望,特别是第6章"库存与财务"给了我思维建模的概念.这本书和UML.GOF的"设计模式"差不多是在同一时间段出现,所以书的内容看上去有点古董的感觉.不过,大师的

框架设计总结

框架设计总结 温昱老师的<一线架构师实现指南>读完好几天了,本书很多大牛都有推荐,自己从头到底一字不漏的看了,很多关键的方法,做了标记,看了多次,是一本介绍构架设计方面很好的书,准备把它做为工具书,在开始中用好其中的方法. 大学学的软件工程,软件设计要从需求分析.可行性分析.概要设计.软件设计.软件开发和测试,说的是一个大的过程,具体到针对一个项目时还是会感觉无从下手:本书提供的ADMEMS方法体系,把这一过程形成方法体系,让框架设计的操作性更强,四个核心主张: 1)       方法体系是大

数据仓库专题(16)-分布式数据仓库实践指南-目录篇

前言: 准备系统化整理一套分布式数据仓库建模实践指南,先把目录列出来吧,算是给自己设计一个目标吧. 第一部分 基础篇 第一章 数据仓库概念与定义 1.1 数据管理体系 1.2 数据仓库概念 1.3 数据仓库职责 第二章 数据仓库体系结构 2.1 Inmon CIF 2.2 Kimball 2.3 对于与分析 第三章 维度建模基础 3.1 kimball四步建模法 3.2 维度设计 3.3 事实表设计 第二部分 实践篇 第一章 路线图 第二章 业务分析-深浅有度 第三章 数据分析-区别对待 第四章

谈谈ODPS商业化(二):ODPS的计量计费模型

ODPS正式商业化以后,微博上议论比较多的是计量计费模型.刚好这件事我全程参与,仔细写写.ODPS的计量计费规则和价格请以阿里云官方网站上的说明和数字为准.这里的内容只反映当前状态,不能保证实时更新. ODPS收费以项目(Project)为单位,对存储.计算和数据下载三个方面分别计费.存储和数据下载的收费形式与其他云产品很类似.而计算这边,目前ODPS仅开放了SQL任务,计费公式为:一次SQL计算费用 = 计算输入数据量 * SQL复杂度 * SQL价格.具体而言: 1.计算输入数据量:指一个S