博客访问： 1882
博文数量： 3
注册时间：
鏆傛棤浠嬬粛
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 数据仓库与数据挖掘
　数据仓库，在1991年就得到这样一个定义，即它是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，它用于对管理决策过程的支持。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础的。因此数据仓库必须保持与业务相关，与企业自身发展需求相关。那么如何将数据仓库落脚于业务呢?
　　数据最终带来的是业务战略与行动，数据仓库将企业中不同信息岛上的商业数据集中到一起，存储数据仓库中，提供各种手段对数据进行统计、分析形成知识，在企业的各个业务单位进行共享，为企业更快、更好地做出商业决策提供更加准确、完整的信息。在商业分析产业链中，数据仓库的作用在于梳理业务，为海量的数据分析提供物理构架和依据。
　　数据仓库落脚于业务，必须拥有三方面能力，一是数据整合的能力，即将需要做分析的相关数据整合到数据分析平台;二是数据探索的能力，即以企业当前业务需求为参考，探索数据背后隐含的商业价值的能力;三是转化知识的能力，即通过挖掘出有用的信息，为制定更好的行动纲领提供知识，以帮助企业能够快速地采取正确的行动，最终决策于业务。
　　用友华表最新推出的用友BQW是一款全新的用于打造主题数据仓库/分析应用的开发工具。借助于此产品可以快速满足企业不断变化的业务分析数据需求，并通过最佳实践的预置，降低用友BQ项目以及其他BI项目的交付成本和人员能力要求，加快项目的交付效率。用友BQW中有一个组件——业务数据仓库工具，它提供界面化的操作，构建以ERP为源数据的数据仓库;提供个性化业务数据扩展，开放ETL总包调度，将自定义的ETL处理纳入统一的ETL调度，实施伙伴可以根据实际情况完成数据扩展。用友BQW业务数据仓库工具具有四大特征。
　　第一，统一业务数据源。实施伙伴无须了解具体ERP系统的数据特征，只需了解BQW中的数据结构，即可完成基于NC、U8的BI项目。
　　第二，以业务分析为导向。元数据管理→语义层定义→分析数据查询，一气呵成，按需组织数据预置业务语义模型。BQW业务语义模型=BQ信息域+BQ查询。预置信息域，完成业务语义层的定义，使数据更为严谨和准确;预置基于信息域的查询，便于实施伙伴理解数据的逻辑，便于实施伙伴掌握数据仓库的使用;预置数据仓库应用案例，基于预置数据构造，简单方便。
　　第三，专业数据处理。BQW-ETL设计架构为分层架构，总包控制调度、业务子包处理数据。总包不含业务逻辑数据处理，有独立的读参模块、数据处理模块，可独立运行。业务子包同样有独立的读参模块、数据处理模块、写日志模块，可独立运行;BQW的数据处理准确、并行、独立的特点。单业务数据独立执行，保证数据仓库结果数据与业务系统一致，细粒度业务子包，保证数据处理可以并行执行，提高数据抽取效率，按功能模块独立调度，捕捉增量数量，批量更新至数据仓库。
　　第四，灵活扩展数据源。用友BQ项目实施伙伴可以通过扩展元数据的功能实现BQW未完成的NC业务数据和非NC业务数据的添加，满足实施人员个性化数据处理、数据范围、数据仓库内容扩展的需求。预置元数据，查看数据的血缘关系，方便了解数据仓库结构。扩展元数据，引入ERP二次开发、ERP系统以外的数据。开发自定义的ETL包，并在总包程序中注册，以便扩展二开数据和其他系统数据。
阅读(3) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。后使用快捷导航没有帐号？
查看: 497|回复: 5
数据仓库设计和数据库设计有区别？
金牌会员, 积分 2645, 距离下一级还需 355 积分
论坛徽章:17
& &&&请问数据仓库设计和数据库设计有区别？二者又有哪些相似呢？谢谢。
金牌会员, 积分 1615, 距离下一级还需 1385 积分
论坛徽章:31
去搜下关键词：ER模型 vs 星型模型
金牌会员, 积分 2649, 距离下一级还需 351 积分
论坛徽章:20
我的理解，数据仓库设计是数据库设计的一部分，还有一部分是OLTP的数据库设计。
注册会员, 积分 114, 距离下一级还需 86 积分
论坛徽章:2
我的理解，数据仓库设计是OLAP数据库，其设计模式有雪花型和星型两种，里面分了维度和事实表两种概念，数据记录支持冗余；而数据库设计是OLTP数据库，就是一般的关系型数据库设计，不支持冗余
中级会员, 积分 284, 距离下一级还需 216 积分
论坛徽章:16
我的理解: 数据库设计,以业务流程为导向, OLTP,&&基本都是第三范式,&&索引一般都是B-tree索引，&&数据仓库设计，OLAP,&&要分层，以数据分析和数据挖掘为导向，来源于多个系统或者一个系统，以业务分析为主题，存在部分位图索引， 一般分为三层，元数据层，应用系统清单层，数据汇总层（各种面向主题的建模） 一般都是雪花或者星型模型
中级会员, 积分 220, 距离下一级还需 280 积分
论坛徽章:27
数据仓库&&偏重于业务模型吧您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于数据仓库技术银行业务管理系统应用研究.pdf73页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：200 &&
你可能关注的文档：
··········
··········
onthe ofData Study Application Business Banking ManagementSystem Abstract The of Commercialbanksinchinahasenteredawhite?hot
foreign competition stage．The
banksentertheChinesemarketona
scaleafterthetimelimitwhichis by large stipulated
WTO．Thedomesticbankscall answerthe from only challenge by comingevery’aspect their andadministrative the
improvingmanagerial expertiseability．Inprocess，data
warehousea mean8 is efficientof thework．Fortheinner very promoting
datawarehousecan toraisethe levelofthe the help management
external detailedinformation
thedatawarehousecandirect business，the providedby activities
operating effectively． This showsthe and of
bank realizationthe paper requirementsanalysis、design whichisbasedonthedatawarehouse on
performanceassessingsystem
thedata and basedonthedata miningtechnologyapplication
customerbehavior miningproject． Themainworkofthe data dissertationis：summarizesthebasic
ofthe concept thedata and the
warehouse；discusseswarehouseframework system designthinking：presents
modelandthestructuresofthedata bank warehouse：achieves．theperformanceassessing basedonthedatawarehouse theexamination system
management system。afteranalysis anddata reflectsthe of
requirement，formulasoUrceS，the system principle
and ensuresbuildensure customer high-efficiency,which
behavior basedonthedata candirectcustomer to miningproject warehouse，which managers outthe in
carry pertinence
orderto thebusiness． marketing promote a and ofthebankinformatizationConstruction Finally,makessummary prospect words： Key data warehouse，performanceassessing，datamining 西北大学学位论文知识产权声明书 本人完全了解西北大学关于收集、保存、使用学位论文的规定。学
校有权保留并向国家有关部门或机构送交论文的复印件和电子版。本人
允许论文被查阅和借阅。本人授权西北大学可以将本学位论文的
正在加载中，请稍后...放开那程序猿！构建业务导向的大数据云平台 - 简书
放开那程序猿！构建业务导向的大数据云平台
按数据处理方式及使用目标，企业级IT系统可分为OLTP和OLAP系统。简而言之，OLTP系统生产数据，OLAP系统加工数据。从数据到智慧的转换金字塔上看，OLTP系统实现了底层的数据产生和存储以及面向事务的信息整合，在这之上的各层就要依赖OLAP系统了。OLAP概念源自决策支持系统（DSS），企业中的数据仓库、数据集市、统计报表、驾驶舱、数据挖掘等都属于OLAP体系。其中，数据仓库和数据集市主要实现信息整合，一般统称为数据整合平台。统计报表、驾驶舱、数据挖掘进一步利用数据整合平台的成果，帮助用户发现知识并最终形成智慧。
OLAP系统的主要用户是分析人员和管理人员，目标是支持管理决策，依据是企业生产经营过程中产生的全量数据，是一个按目标使用场景对数据进行加工、利用的过程。这过程一般可以划分五个阶段：业务部门定义需求；IT部门根据需求获取并整合相关数据；IT部门根据需求设计分析模型；IT部门开发实施并发布；业务部门应用并衡量实际成效。在传统的数据基础和技术环境下，这个周期可能要经历较漫长的时间。还在建设OLAP体系的情况自不必多说，即便已建成OLAP体系统，要及时响应业务部门的需求也是较困难的，而且很有可能最终的交付质量不能达到需求方的预期。
下图是目前较常见的OLAP体系简图，上游系统指那些OLTP系统，是数据源。数据整合平台包括ODS、数据仓库、数据集市等，主要实现数据整合。下游系统指那些利用数据整合平台成果的系统，包括统计报表、驾驶舱、数据挖掘等。其中，数据整合平台承上启下，在整个OLAP体系中非常重要。按照目前较普遍的架构，从上游到下游的数据流向，至少分为同构层、整合层、应用层。其中同构层在模型上基本与上游接入数据源基本保持一致，整合层一般会采用高范式模型进行数据整合，应用层面向下游具体应用采用星型模型。这个架构是在Inmon帮和Kimball派十几年如一日的不断撕逼和妥协中演进出来的，应该是一种最佳实践。但随着互联网+大数据时代到来，对数据应用有着更高效、更深入的要求，这种架构本身固有的缺点被不断放大。
开发周期长
为了避免因上游系统接入模型的变化而导致数据整合平台模型的被动调整，整合层建模时一般会采用较高范式实现高内聚、低耦合，ER实体较多、关系复杂。这样就增加了ETL设计、开发以及测试的复杂度，同时ETL程序执行效率也低。业务部门提出的需求，IT首先由下至上逐层对模型进行分析，即便只需在应用层开发，基于上述原因也需要一周以上。如果涉及要改动整合层，开发周期要一个月左右，业务部门显然是不能接受的。最后的结局不用猜都知道，苦逼的程序猿只能再一次强睁熊猫眼天天加班赶工。但是故事并没有到此结束，马上一个意想不到但细细想想又是顺理成章的伴生问题发生了。架构迅速变坏
在日复一日的高压下，程序猿只能另辟蹊径为自己减负。既然工作量是由于数据模型和层次的复杂性引起的，那最有效的减少工作量的方法无非就是：1、绕过整合层，数据直接从同构层到应用层。2、还是从通过整合层，但使用面向应用的自建模型。无论哪种方法，都使整合层形同虚设，从同构层到应用层形成一个个数据井道。虽然单个开发任务的开发时间缩短了，但各数据井道之间无法复用，所以总的开发时间绝对要更多，而且后期的维护工作将是一场噩梦。
架构变坏后，数据一致性无法保证，大量数据重复存储，大量指标重复计算，ETL作业数急剧上升，数据整合平台效率自然会越来越差。即便架构还能保持，但随着时间的推移，数据量及业务需求不断增加，架构上倾向分割出更多的层次，以便实现更多的复用。随着层次的增加，数据迁移的路径就变长了，长久以往也难逃低效率的宿命。
再回顾下OLAP数据应用的五个阶段，从业务提出需求到业务应用验证形成闭环，这过程是由IT导向推动的，IT首先与业务讨论分析需求，在业务模型层面中达成共识，然后再映射到系统模型，实现对来自上游系统的数据进行加工处理，最后通过OLAP系统将结果在业务语境中展现给用户，之前讨论的所有弊病都此有关。而对于像银行、保险等发展较成熟的行业，其业务语境、模型是较稳定的，支持业务开展的上游IT系统的系统模型也应该是相对稳定的，因此业务模型和系统模型间能形成较稳定的映射关系。这样只要能达到足够细的粒度，就能实现操纵业务模型来改变系统模型的目的。而业务模型又能被业务所能理解，因此这个闭环过程就可以完全由业务导向不需要IT的参与，整个过程可以简化为：业务设计模型，业务应用验证。