科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技百科
  • 人气指数: 2725 次
  • 编辑次数: 1 次 历史版本
  • 更新时间: 2009-03-18
admin
admin
发短消息
相关词条
bat
bat
Processing语言
Processing语言
固件
固件
SSID
SSID
LAMP
LAMP
Flash和HTML5
Flash和HTML5
沙盒
沙盒
六种主要计算机语言优缺点
六种主要计算机语言优缺点
系统集成
系统集成
间谍软件
间谍软件
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
2017年特斯拉
2017年特斯拉
MIT黑客全纪录
MIT黑客全纪录
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

(图)数据集市
数据集市
数据集市(Data Mart) ,也叫数据市场,是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中收集数据的仓库。从范围上来说,数据是从企业范围的数据库数据仓库,或者是更加专业的数据仓库中抽取出来的。数据中心的重点就在于它迎合了专业用户群体的特殊需求,在分析、内容、表现,以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。

目录

[显示全部]

简介编辑本段回目录

(图)两种类型的数据集市
两种类型的数据集市
数据仓库是一个集成的、面向主题的数据集合,设计的目的是支持DSS决策支持系统)功能。在数据仓库里,每个数据单元都和特定的时间相关。数据仓库包括原子级别的数据和轻度汇总的数据,是面向主题的、集成的、不可更新的(稳定性)、随时间不断变化(不同时间)的数据集合,用以支持经营管理中的决策制定过程。

单独的DB2数据库包括企业的数据集市。每个数据集市包括来自中央数据仓库的历史数据的子集,用以满足特定部门、团队、客户或应用程序分析和报告需求。主管此DB2数据库的系统称为数据集市服务器。尽管可以有许多数据集市,但只能有一个数据集市服务器。

数据集市组件需要IBMDB2UniversalDatabaseEnterpriseEdition,您必须在安装控制服务器前手工安装它。

IBMTivoliMonitoringforTransactionPerformance仓库包创建结构适用于报告界面的数据集市。IBMTivoliMonitoringforTransactionPerformance通过提供一个称为数据集市ETL的抽取、转换和装入(ETL)过程来实现此操作,该进程创建数据集市并将来自中央数据仓库的数据装入其中。

可以修改现有的数据集市或创建包含略微不同的数据的新数据集市,以迎合您所在环境下的特定报告需要。要修改或创建数据集市,必须熟悉数据库ETL过程以及数据集市在Tivoli 。

那么数据集市就是企业级数据仓库的一个子集,他主要面向部门级业务,并且只面向某个特定的主题。为了解决灵活性和性能之间的矛盾,数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据,从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

特征 编辑本段回目录

(图)数据集市
数据集市
1、数据集市的特征包括规模小

2、有特定的应用

3、面向部门

4、由业务部门定义、设计和开发

5、业务部门管理和维护

6、能快速实现

7、购买较便宜

8、投资快速回收

9、工具集的紧密集成

10、提供更详细的、预先存在的、数据仓库的摘要子集

11、可升级到完整的数据仓库

数据结构 编辑本段回目录

(图)数据仓库与数据集市的区别
数据仓库与数据集市的区别
数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分——一个事实表和各种支持维表。

一、事实表

事实表描述数据集市中最密集的数据。在电话公司中,用于呼叫的数据是典型的最密集数据;在银行中,与账目核对和自动柜员机有关的数据是典型的最密集数据。对于零售业而言,销售和库存数据是最密集的数据等等。

事实表是预先被连接到一起的多种类型数据的组合体,它包括:一个反映事实表建立目的的实体的主键,如一张订单、一次销售、一个电话等等,主键信息,连接事实表与维表的外键,外键携带的非键值外部数据。如果这种非键外部数据经常用于事实表中的数据分析,它就会被包括在事实表的范围内。事实表是高度索引化的。事实表中出现30到40条索引非常常见。有时实事表的每列都建了索引,这样作的结果是使事实表中的数据非常容易读取。但是,导入索引所需的资源数量必须为等式提供因数。通常,事实表的数据不能更改,但可以输入数据,一旦正确输入一个记录,就不能更改此记录的任何内容了。

二、维表

维表是围绕着事实表建立的。维表包含非密集型数据,它通过外键与事实表相连。典型的维表建立在数据集市的基础上,包括产品目录、客户名单、厂商列表等等。

数据集市中的数据来源于企业数据仓库。所有数据,除了一个例外,在导入到数据集市之前都应该经过企业数据仓库。这个例外就是用于数据集市的特定数据,它不能用于数据仓库的其他地方。外部数据通常属于这类范畴。如果情况不是这样,数据就会用于决策支持系统的其他地方,那么这些数据就必须经过企业数据仓库。

数据集市包含两种类型的数据,通常是详细数据和汇总数据。

三、详细数据

就像前面描述过的一样,数据集市中的详细数据包含在星型结构中。值得一提的是,当数据通过企业数据仓库时,星型结构就会很好的汇总。在这种情况下,企业数据仓库包含必需的基本数据,而数据集市则包含更高间隔尺寸的数据。但是,在数据集市使用者的心目中,星型结构的数据和数据获取时一样详细。

四、汇总数据

数据集市包含的第二种类型数据是汇总数据。分析人员通常从星型结构中的数据创建各种汇总数据。典型的汇总可能是销售区域的月销售总额。因为汇总的基础不断发展变化,所以历史数据就在数据集市中。但是这些历史数据优势在于它存储的概括水平。星型结构中保存的历史数据非常少。

数据集市以企业数据仓库为基础进行更新。对于数据集市来说大约每周更新一次非常平常。但是,数据集市的更新时间可以少于一周也可以多于一周,这主要是由数据集市所属部门的需求来决定的。

常见问题 编辑本段回目录

(图)BI的数据集市模式
BI的数据集市模式
一、数据集市的建立

建立不同规格的数据仓库、数据集市的成本,国外的咨询机构有专门的评估,在一定程度上可以借鉴。但是这些结果在国内也许并不适用,因为国情不同,在国内的构建成本需要专门的调研。以人们为企业构建的客户主题数据集市为例,一般成本在20万元到50万元人民币之间。

数据集市的设计可以采用迭代式的方法。在迭代式开发中,每个迭代为上一次的结果增加了新的功能。功能增加的顺序要考虑到迭代平衡以及尽早发现重大风险。通俗地说,就是在正式交货之前多次给客户交付不完善的中间产品“试用”。这些中间产品会有一些功能还没有添加进去、还不稳定,但是客户提出修改意见以后,开发人员能够更好地理解客户的需求。如此反复,使得产品在质量上能够逐渐逼近客户的要求。这种开发方法周期长、成本高,但是它能够避免整个项目推倒重来的风险,比较适合大项目、高风险项目

理论上讲,应该有一个总的数据仓库的概念,然后才有数据集市。实际建设数据集市的时候,国内很少这么做。国内一般会先从数据集市入手,就某一个特定的主题(比如企业的客户信息)先做数据集市,再建设数据仓库。数据仓库和数据集市建立的先后次序之分,是和设计方法紧密相关的。而数据仓库作为工程学科,并没有对错之分,主要判别方式应该是能否解决目前存在的实际问题,并为今后可能发生的问题保持一定的可伸缩性。

二、数据集市的 “独立” 性

企业规划数据仓库项目的时候,往往会遇到很多数据仓库软件供应商。各供应商除了推销相关的软件工具外, 同时也会向企业灌输许多概念。其中,数据仓库和数据集市是最常见的两个术语了。各个供应商术语定义不统一、销售策略不一样,这往往会给企业带来很大的混淆。最典型的问题是:到底是先上一个企业级的数据仓库呢?还是先上一个部门级的数据集市?这其实是是否要上独立型数据集市的问题。

数据集市可以分为两种类型——独立型数据集市和从属型数据集市。独立型数据集市直接从操作型环境获取数据,从属型数据集市从企业级数据仓库获取数据,带有从属型数据集市的体系结构。

数据仓库规模大、周期长,一些规模比较小的企业用户难以承担。因此,作为快速解决企业当前存在的实际问题的一种有效方法,独立型数据集市成为一种既成事实。独立型数据集市是为满足特定用户(一般是部门级别的)的需求而建立的一种分析型环境,它能够快速地解决某些具体的问题,而且投资规模也比数据仓库小很多。

独立型数据集市的存在会给人造成一种错觉,似乎可以先独立地构建数据集市,当数据集市达到一定的规模再直接转换为数据仓库。有些销售人员会推销这种观点,其实质却常常是因为建立企业级数据仓库的销售周期太长以至于不好操作。

多个独立的数据集市的累积,是不能形成一个企业级的数据仓库的,这是由数据仓库和数据集市本身的特点决定的—数据集市为各个部门或工作组所用,各个集市之间存在不一致性是难免的。因为脱离数据仓库的缘故,当多个独立型数据集市增长到一定规模之后,由于没有统一的数据仓库协调,企业只会又增加一些信息孤 岛,仍然不能以整个企业的视图分析数据。借用Inmon的比喻:人们不可能将大海里的小鱼堆在一起就构成一头大鲸鱼,这也说明了数据仓库和数据集市有本质的不同。

如果企业最终想建设一个全企业统一的数据仓库,想要以整个企业的视图分析数据,独立型数据集市恐怕不是合适的选择;也就是说“先独立地构建数据集市,当数据集市达到一定的规模再直接转换为数据仓库”是不合适的。从长远的角度看,从属型数据集市在体系结构上比独立型数据集市更稳定,可以说是数据集市未来建设的主要方向。

主要意义编辑本段回目录

数据集市(图)示意图
示意图
快速发展的、充满竞争的商业世界对于及时、准确的信息有着永无止境的需求,一些IT专家对此认为其必然结果就是创建数据集市。其他专家却质疑用户和客户所要付出的工作和成本。毕竟,难道不能直接从遗留系统和在线事务处理(On Line Transaction Processing,OLTP)系统通过特定的报表获得相同的信息吗?在EDS商业智能小组里,人们就经常被问到这一问题。经验让人们有许多机会使人们的同行和客户了解这项有用技术的价值。

那么,一个组织为何要构建数据集市呢?虽然OLTP和遗留系统拥有宝贵的信息,但是可能难以从这些系统中提取有意义的信息并且速度也较慢。而且这些系统虽然一般可支持预先定义操作的报表,但却经常无法支持一个组织对于历史的、联合的、“智能的”或易于访问的信息的需求。因为数据分布在许多跨系统和平台的表中,而且通常是“脏的”,包含了不一致的和无效的值,使得难于分析。数据集市将合并不同系统的数据源来满足业务信息需求。

若能有效地得以实现,数据集市将可以快速且方便地访问简单信息以及系统的和历史的视图。一个设计良好的数据集市将会:发布特定用户群体所需的信息,且无需受制于源系统的大量需求和操作性危机。支持访问非易变(nonvolatile)的业务信息。(非易变的信息是以预定的时间间隔进行更新的,并且不受OLTP系统进行中的更新的影响)。调和来自于组织里多个运行系统的信息,比如账目、销售、库存和客户管理以及组织外部的行业数据。通过默认有效值、使各系统的值保持一致以及添加描述以使隐含代码有意义,从而提供净化的(cleansed)数据。为即席分析和预定义报表提供合理的查询响应时间(不同于OLTP系统中所需的调优需求)。通过提供对于遗留系统和OLTP应用程序的选择来减少对这些应用程序的要求,以获得更多所需信息。

案例分析编辑本段回目录

数据集市(图)中国移动
中国移动
通过吉林市等城市的成功试点,中国移动已经决定将数据集市作为2006年移动地市级公司的建设重点之一。这也同时意味着,电信行业建立在数据仓库基础上的BI应用已经进入到更加深入挖掘的阶段,其产生的结果将直接服务于一线的生产销售…… 

 数据集市:深化挖掘第一步

电信行业对于数据仓库并不陌生,为了实现从产品导向往客户导向的转变,电信公司纷纷建立以客户为中心的数据仓库,希望依据客户的需要、期望及喜好来制订策略,提升企业竞争力。简单说,数据仓库就是为了保证数据查询和分析的效率,按照主题将所有的数据分门别类进行存储,需要的时候,可以按主题提取数据并做进一步的分析处理。 

数据集市,可以称作"小数据仓库",是用来分析相关专门业务问题或功能目标而做的专项的数据集合。它建立在具有统一数据存储模型的数据仓库下,各级业务人员按照各部门特定的需求把数据进行复制、处理、加工,并最终统一展现为有部门特点的数据集合,数据集市的应用是对数据仓库应用的补充。

经过近几年的努力,吉林移动通信有限责任公司已经成功在省级公司建立起了面向决策支持的经营分析系统,BI系统也逐渐完善。省级公司从业务系统中将相关业务数据进行抽取、清洗、加工、整理、加载到数据仓库中,在数据仓库中形成基础的分析数据的存储,对地市一级公司的营销策略进行指导。

问题也随之产生,由于下属分公司在客户群体、市场容量、利润来源等地域差异明显,省级公司通过全省范围内分公司数据的汇总和分析,难以对单个地市级分公司产生个性化决策支持。另一方面,地市一级的分公司在开拓终端市场的过程中,激发了旺盛的应用需求,具体表现为对数据粒度的要求更加精细、需求更加灵活多变、要求更强的可操作性。 

 2005年6月,中国移动通信有限公司制定了《中国移动经营分析系统数据集市(试点)业务技术建议书》。为了使经营分析系统在地市级公司日常生产经营中发挥更大作用,吉林移动最终决定与亚信科技合作,全面进行"数据集市"的搭建。吉林省吉林市成为12个试点中第一个"吃螃蟹"的城市。

吉林移动希望通过数据集市的建设及时准确地了解掌握地市公司的分析需求,更好地为一线地市公司的生产营销服务。吉林市分公司也希望提升自身的经营分析水平,落实集团公司的精细化营销战略。

在总体设计方面,吉林移动希望通过吉林市的试点为吉林省其它分公司建设统一的数据集市的模型,基本涵盖地市固定统计报表及分析的需求,统一建模,统一管理。在功能上,为地市分公司的市场营销行为提供客户个体分析,提高经营分析结果的可实施能力,支持精细化营销,支持地市开发过灵活专题分析。开发标准化、开放的数据平台,满足省内不同地市分公司更多个性化的、临时性的分析需求。

总体来说,吉林移动对亚信科技提出了很实际的业务描述,就是"以提供丰富的数据为基础,以提供简要分析功能、提高日常分析能力为主要手段,以解决各类业务目标为最终目的,大力提升地市公司数据综合运用、分析能力,大力提升分公司主动服务、主动营销效能"。

数据集市项目从2005年6月开始组织需求调研,经历了5个月的建设时间,于2005年11月底上线使用,完成了中国移动集团公司试点所要求完成的所有基本集功能以及符合吉林本地特色的扩展集的内容。 

作为实施方,亚信科技在吉林数据集市建设过程中遵循了"平台标准化、业务个性化"的原则。亚信一方面在数据集市基础平台采用标准的系统软件,使数据集市的逻辑数据模型统一、标准;另一方面,在地市分公司开发应用功能时,结合本地的实际情况,体现了本地的需求特色。在项目建设期间,吉林移动曾两次就该项目建设的方法与思路向中国移动集团公司领导汇报,亚信的建设思路及建设成果得到了移动总公司的高度认可。 

 随着吉林移动、云南移动等公司"数据集市"项目的成功试点,中国移动31个省的上百家地市级公司将纷纷上马数据集市项目。可以预见,2006年将是移动公司进一步深入挖掘BI应用,提升BI建设水平的一年,数据集市作为专项的数据集合与分析系统,对中国移动地市级分公司的日常经营管理将产生至关重要的作用,成为中国移动落实精细化经营策略的重点工程。

相关词条编辑本段回目录

参考资料编辑本段回目录

→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
0

标签: 数据集市

收藏到: Favorites  

同义词: 暂无同义词

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。