精华内容
下载资源
问答
  •  遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。 二、正文  原则1、载入详细的原子数据到维度结构中  维度...

    一、前言

          特别声明:本文整理自互联网。

           遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。

    二、正文

      原则1、载入详细的原子数据到维度结构中

       维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组请求,用户通常不希望每次只看到一个单一的记录,但是你无法预测 用户想要掩盖哪些数据,想要显示哪些数据,如果只有汇总数据,那么你已经设定了数据的使用模式,当用户想要深入挖掘数据时他们就会遇到障碍。当然,原子数 据也可以通过概要维度建模进行补充,但企业用户无法只在汇总数据上工作,他们需要原始数据回答不断变化的问题。

      原则2、围绕业务流程构建维度模型

       业务流程是组织执行的活动,它们代表可测量的事件,如下一个订单或做一次结算,业务流程通常会捕获或生成唯一的与某个事件相关的性能指标,这些数据转换 成事实后,每个业务流程都用一个原子事实表表示,除了单个流程事实表外,有时会从多个流程事实表合并成一个事实表,而且合并事实表是对单一流程事实表的一 个很好的补充,并不能代替它们。

      原则3、确保每个事实表都有一个与之关联的日期维度表

      原则2中描述的可测量事件总有一个日期戳信息,每个事实表至少都有一个外键,关联到一个日期维度表,它的粒度就是一天,使用日历属性和非标准的关于测量事件日期的特性,如财务月和公司假日指示符,有时一个事实表中有多个日期外键。

      原则4、确保每个事实表中的事实具有相同的粒度或同级的详细程度

      在组织事实表时粒度上有三个基本原则:事务,周期快照或累加快照。无论粒度类型如何,事实表中的度量单位都必须达到相同水平的详细程度,如果事实表中的事实表现的粒度不一样,企业用户会被搞晕,BI应用程序会很脆弱,或者返回的结果根本就不对。

      原则5、解决事实表中的多对多关系

      由于事实表存储的 是业务流程事件的结果,因此在它们的外键之间存在多对多(M:M)的关系,如多个仓库中的多个产品在多天销售,这些外键字段不能为空,有时一个维度可以为 单个测量事件赋予多个值,如一个保健对应多个诊断,或多个客户有一个银行账号,在这些情况下,它的不合理直接解决了事实表中多值维度,这可能违反了测量事 件的天然粒度,因此我们使用多对多,双键桥接表连接事实表。

      原则6、解决维度表中多对一的关系

      属性之间分层的、多对一(M:1)的关系通常未规范化,或者被收缩到扁平型维度表中,如果你曾经有过为事务型系统设计实体关系模型的经历,那你一定要抵抗住旧有的思维模式,要将其规范化或将M:1关系拆分成更小的子维度,维度反向规范化是维度建模中常用的词汇。

      在单个维度表中多对一(M:1)的关系非常常见,一对一的关系,如一个产品描述对应一个产品代码,也可以在维度表中处理,在事实表中偶尔也有多对一关系,如详细当维度表中有上百万条记录时,它推出的属性又经常发生变化。不管怎样,在事实表中要慎用M:1关系。

      原则7、存储报告标记和过滤维度表中的范围值

       更重要的是,编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中,避免在事实表中存储神秘的编码字段或庞大的描述符字段,同样,不要只 在维度表中存储编码,假定用户不需要描述性的解码,或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器,那么它应该当作一个维度 属性处理。

      尽管我们在原则5中已经陈述过,事实表外键不应该为空,同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的,这样可以减少用户的困惑。

      原则8、确定维度表使用了代理键

       按顺序分配代理键(除了日期维度)可以获得一系列的操作优势,包括更小的事实表、索引以及性能改善,如果你正在跟踪维度属性的变化,为每个变化使用一个 新的维度记录,那么确实需要代理键,即使你的商业用户没有初始化跟踪属性改变的设想值,使用代理也会使下游策略变化更宽松,代理也允许你使用多个业务键映 射到一个普通的配置文件,有利于你缓冲意想不到的业务活动,如废弃产品编号的回收或收购另一家公司的编码方案。

      原则9、创建一致的维度集成整个企业的数据

       对于企业数据仓库一致的维度(也叫做通用维度、标准或参考维度)是最基本的原则,在ETL系统中管理一次,然后在所有事实表中都可以重用,一致的维度在 整个维度模型中可以获得一致的描述属性,可以支持从多个业务流程中整合数据,企业数据仓库总线矩阵是最关键的架构蓝图,它展现了组织的核心业务流程和关联 的维度,重用一致的维度可以缩短产品的上市时间,也消除了冗余设计和开发过程,但一致的维度需要在数据管理和治理方面有较大的投入。

      原则10、不断平衡需求和现实,提供用户可接受的并能够支持他们决策的DW/BI解决方案

       维度建模需要不断在用户需求和数据源事实之间进行平衡,才能够提交可执行性好的设计,更重要的是,要符合业务的需要,需求和事实之间的平衡是DW/BI 从业人员必须面对的事实,无论是你集中在维度建模,还是项目策略、技术/ETL/BI架构或开发/维护规划都要面对这一事实。

    三、未完待续

          分布式数据仓库数据存储模型设计进行中,后续会持续更新,请关注QQ群:分布式数据仓库建模 398419457。

     

    展开全文
  • 遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。本文适用于多维建模,不使用于3NF建模。 二、正文  原则1、载入...

    一、前言

             数据仓库存储逻辑模型设计,需要遵循一定的设计原则。遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。本文适用于多维建模,不使用于3NF建模。

    二、正文

      原则1、载入详细的原子数据到维度结构中

       维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组请求,用户通常不希望每次只看到一个单一的记录,但是你无法预测 用户想要掩盖哪些数据,想要显示哪些数据,如果只有汇总数据,那么你已经设定了数据的使用模式,当用户想要深入挖掘数据时他们就会遇到障碍。当然,原子数 据也可以通过概要维度建模进行补充,但企业用户无法只在汇总数据上工作,他们需要原始数据回答不断变化的问题。

      原则2、围绕业务流程构建维度模型

       业务流程是组织执行的活动,它们代表可测量的事件,如下一个订单或做一次结算,业务流程通常会捕获或生成唯一的与某个事件相关的性能指标,这些数据转换 成事实后,每个业务流程都用一个原子事实表表示,除了单个流程事实表外,有时会从多个流程事实表合并成一个事实表,而且合并事实表是对单一流程事实表的一 个很好的补充,并不能代替它们。

      原则3、确保每个事实表都有一个与之关联的日期维度表

      原则2中描述的可测量事件总有一个日期戳信息,每个事实表至少都有一个外键,关联到一个日期维度表,它的粒度就是一天,使用日历属性和非标准的关于测量事件日期的特性,如财务月和公司假日指示符,有时一个事实表中有多个日期外键。

      原则4、确保每个事实表中的事实具有相同的粒度或同级的详细程度

      在组织事实表时粒度上有三个基本原则:事务,周期快照或累加快照。无论粒度类型如何,事实表中的度量单位都必须达到相同水平的详细程度,如果事实表中的事实表现的粒度不一样,企业用户会被搞晕,BI应用程序会很脆弱,或者返回的结果根本就不对。

      原则5、解决事实表中的多对多关系

      由于事实表存储的 是业务流程事件的结果,因此在它们的外键之间存在多对多(M:M)的关系,如多个仓库中的多个产品在多天销售,这些外键字段不能为空,有时一个维度可以为 单个测量事件赋予多个值,如一个保健对应多个诊断,或多个客户有一个银行账号,在这些情况下,它的不合理直接解决了事实表中多值维度,这可能违反了测量事 件的天然粒度,因此我们使用多对多,双键桥接表连接事实表。

      原则6、解决维度表中多对一的关系

      属性之间分层的、多对一(M:1)的关系通常未规范化,或者被收缩到扁平型维度表中,如果你曾经有过为事务型系统设计实体关系模型的经历,那你一定要抵抗住旧有的思维模式,要将其规范化或将M:1关系拆分成更小的子维度,维度反向规范化是维度建模中常用的词汇。

      在单个维度表中多对一(M:1)的关系非常常见,一对一的关系,如一个产品描述对应一个产品代码,也可以在维度表中处理,在事实表中偶尔也有多对一关系,如详细当维度表中有上百万条记录时,它推出的属性又经常发生变化。不管怎样,在事实表中要慎用M:1关系。

      原则7、存储报告标记和过滤维度表中的范围值

       更重要的是,编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中,避免在事实表中存储神秘的编码字段或庞大的描述符字段,同样,不要只 在维度表中存储编码,假定用户不需要描述性的解码,或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器,那么它应该当作一个维度 属性处理。

      尽管我们在原则5中已经陈述过,事实表外键不应该为空,同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的,这样可以减少用户的困惑。

      原则8、确定维度表使用了代理键

       按顺序分配代理键(除了日期维度)可以获得一系列的操作优势,包括更小的事实表、索引以及性能改善,如果你正在跟踪维度属性的变化,为每个变化使用一个 新的维度记录,那么确实需要代理键,即使你的商业用户没有初始化跟踪属性改变的设想值,使用代理也会使下游策略变化更宽松,代理也允许你使用多个业务键映 射到一个普通的配置文件,有利于你缓冲意想不到的业务活动,如废弃产品编号的回收或收购另一家公司的编码方案。

      原则9、创建一致的维度集成整个企业的数据

       对于企业数据仓库一致的维度,是最基本的原则,在ETL系统中管理一次,然后在所有事实表中都可以重用,一致的维度在 整个维度模型中可以获得一致的描述属性,可以支持从多个业务流程中整合数据,企业数据仓库总线矩阵是最关键的架构蓝图,它展现了组织的核心业务流程和关联 的维度,重用一致的维度可以缩短产品的上市时间,也消除了冗余设计和开发过程,但一致的维度需要在数据管理和治理方面有较大的投入。常见的一致性维度包括日期、地址等。

      原则10、不断平衡需求和现实,提供用户可接受的并能够支持他们决策的DW/BI解决方案

       维度建模需要不断在用户需求和数据源事实之间进行平衡,才能够提交可执行性好的设计,更重要的是,要符合业务的需要,需求和事实之间的平衡是DW/BI 从业人员必须面对的事实,无论是你集中在维度建模,还是项目策略、技术/ETL/BI架构或开发/维护规划都要面对这一事实。

             原则11基于OLAP分析各操作进行维度设计指导

             从结果反思设计过程,基于OLAP钻取、上钻、下钻、切片、切块的业务需求,设计你的维度模型。


    三、未完待续

          分布式数据仓库数据存储模型设计进行中,后续会持续更新,请关注QQ群:分布式数据仓库建模 398419457。

    展开全文
  • 维度建模的10大基本原则

    千次阅读 2017-09-22 21:06:30
    遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。 原则一: 载入详细的原子数据到维度结构中 维度建模应该使用最...

    遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。

    原则一: 载入详细的原子数据到维度结构中

    维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组请求,用户通常不希望每次只看到一个单一的记录,但是你无法预测用户想要掩盖哪些数据,想要显示哪些数据,如果只有汇总数据,那么你已经设定了数据的使用模式,当用户想要深入挖掘数据时他们就会遇到障碍。当然,原子数据也可以通过概要维度建模进行补充,但企业用户无法只在汇总数据上工作,他们需要原始数据回答不断变化的问题。

    原则二: 围绕业务流程构建维度模型

    业务流程是组织执行的活动,它们代表可测量的事件,如下一个订单或做一次结算,业务流程通常会捕获或生成唯一的与某个事件相关的性能指标,这些数据转换成事实后,每个业务流程都用一个原子事实表表示,除了单个流程事实表外,有时会从多个流程事实表合并成一个事实表,而且合并事实表是对单一流程事实表的一个很好的补充,并不能代替它们。  

    原则三: 确保每个事实表都有一个与之关联的日期维度表  

    原则二中描述的可测量事件总有一个日期戳信息,每个事实表至少都有一个外键,关联到一个日期维度表,它的粒度就是一天,使用日历属性和非标准的关于测量事件日期的特性,如财务月和公司假日指示符,有时一个事实表中有多个日期外键。  

    原则四: 确保每个事实表中的事实具有相同的粒度或同级的详细程度  

    在组织事实表时粒度上有三个基本原则:事务,周期快照或累加快照。无论粒度类型如何,事实表中的度量单位都必须达到相同水平的详细程度,如果事实表中的事实表现的粒度不一样,企业用户会被搞晕,BI应用程序会很脆弱,或者返回的结果根本就不对。  

    原则五: 解决事实表中的多对多关系  

    由于事实表存储的是业务流程事件的结果,因此在它们的外键之间存在多对多(M:M )的关系,如多个仓库中的多个产品在多天销售,这些外键字段不能为空,有时一个维度可以为单个测量事件赋予多个值,如一个保健对应多个诊断,或多个客户有一个银行账号,在这些情况下,它的不合理直接解决了事实表中多值维度,这可能违反了测量事件的天然粒度,因此我们使用多对多,双键桥接表连接事实表。  

    原则六: 解决维度表中多对一的关系  

    属性之间分层的: 多对一(M:1)的关系通常未规范化,或者被收缩到扁平型维度表中,如果你曾经有过为事务型系统设计实体关系模型的经历,那你一定要抵抗住旧有的思维模式,要将其规范化或将M:1关系拆分成更小的子维度,维度反向规范化是维度建模中常用的词汇。在单个维度表中多对一(M:1)的关系非常常见,一对一的关系,如一个产品描述对应一个产品代码,也可以在维度表中处理,在事实表中偶尔也有多对一关系,如详细当维度表中有上百万条记录时,它推出的属性又经常发生变化。不管怎样,在事实表中要慎用M:1关系。  

    原则七: 存储报告标记和过滤维度表中的范围值  

    更重要的是,编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中,避免在事实表中存储神秘的编码字段或庞大的描述符字段,同样,不要只在维度表中存储编码,假定用户不需要描述性的解码,或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器,那么它应该当作一个维度属性处理。  尽管我们在原则5中已经陈述过,事实表外键不应该为空,同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的,这样可以减少用户的困惑。  

    原则八: 确定维度表使用了代理键  

    按顺序分配代理键(除了日期维度)可以获得一系列的操作优势,包括更小的事实表: 索引以及性能改善,如果你正在跟踪维度属性的变化,为每个变化使用一个新的维度记录,那么确实需要代理键,即使你的商业用户没有初始化跟踪属性改变的设想值,使用代理也会使下游策略变化更宽松,代理也允许你使用多个业务键映射到一个普通的配置文件,有利于你缓冲意想不到的业务活动,如废弃产品编号的回收或收购另一家公司的编码方案。  

    原则九: 创建一致的维度集成整个企业的数据  

    对于企业数据仓库一致的维度(也叫做通用维度: 标准或参考维度)是最基本的原则,在ETL系统中管理一次,然后在所有事实表中都可以重用,一致的维度在整个维度模型中可以获得一致的描述属性,可以支持从多个业务流程中整合数据,企业数据仓库总线矩阵是最关键的架构蓝图,它展现了组织的核心业务流程和关联的维度,重用一致的维度可以缩短产品的上市时间,也消除了冗余设计和开发过程,但一致的维度需要在数据管理和治理方面有较大的投入。  

    原则十: 不断平衡需求和现实,提供用户可接受的并能够支持他们决策的DW/BI解决方案  

    维度建模需要不断在用户需求和数据源事实之间进行平衡,才能够提交可执行性好的设计,更重要的是,要符合业务的需要,需求和事实之间的平衡是DW/BI从业人员必须面对的事实,无论是你集中在维度建模,还是项目策略: 技术/ETL/BI架构或开发/维护规划都要面对这一事实
    展开全文
  • PAGE ERPMRP管理)ERP编码原则 *实业有限公司ERP编码原则 目录 TOC \o "1-3" \h \z 1 前言1 2 编码基本原则1 3 物资编码2 3.1金属材料4 3.2机电类6 3.3辅料10 3.4工具类11 3.5化工木材油料23 3.6标准件24 3.7机床备件...
  • ERPMRP 管理)ERP 编码原 则 *实业有限公司 ERP 编码原则 目录 1 前言 1 2 编码基本原则 1 3 物资编码 2 3.1 金属材料 4 3.2 机电类 6 3.3 辅料 10 3.4 工具类 11 3.5 化工木材油料 23 3.6 标准件 24 3.7 机床备件 31...
  • 在经分的年代,数据仓库推倒重来了几遍,构建了很多的专题项目,经历了上万次取数,制作了成百上千的报表,但在支撑了当初的业务发展的同时,到底给如今的企业留下了多少资产? 也许是培养了一代又一代的数据人员,...

                                   关注ITValue,查看企业级市场最新鲜、最具价值的报道!



    在经分的年代,数据仓库推倒重来了几遍,构建了很多的专题项目,经历了上万次取数,制作了成百上千的报表,但在支撑了当初的业务发展的同时,到底给如今的企业留下了多少资产?

     

    也许是培养了一代又一代的数据人员,如今有的成为数据专家,有的转型业务人员,有的晋升为领导,有的离职踏上新的岗位,为企业服务的合作伙伴也由此获得快速成长,很多也成了庞然大物。

     

    但这个够吗?

     

    显然不够,但很多企业现有的数据历史底蕴就是这些了吧,老系统迟早要倒,新系统还是要建,但老系统的好基因却很难留下来,这一代的数据仓库与上一代数据仓库一般不能说是演进,而是重来,或者是靠着个人的经验撑起整片天,又如10年前笔者用逻辑回归实现的飞信潜在模型,现在只能到历史的PPT中去寻找其踪影了,反应了同样的道理。

     

    那么问题的核心在哪里?

     

    答案就是数据中台,今天就来谈一谈。

     

    广义的数据中台包括了数据技术,比如对海量数据进行采集、计算、存储、加工的一系列技术集合,对于大多企业,这些能力是能够买到的,因此无所谓积淀,要积淀大多也是别人的积淀,而不是企业的,当然自主研发的除外,比如阿里的ODPS等。

     

    笔者提的数据中台要更往上走,包括数据模型,算法服务,数据产品,数据管理等等,这些服务跟企业的业务有较强的关联性,是这个企业独有的且能复用的,比如企业自建的2000个基础模型,300个融合模型,5万个标签,这些就是笔者说的中台,它是企业业务和数据的沉淀,其不仅能降低重复建设,减少烟囱式协作的成本,也是差异化竞争优势所在。

     

    为什么数据中台如此重要呢,笔者概括大致有以下四个原因:

     

    1、回归服务的本质-数据重用

     

    今天的浙江移动已经将2000个基础模型作为所有数据服务开发的基础,这些基础模型做到了“书同文,车同轨”,无论应用的数据模型有多复杂,总是能溯源到2000张基础表,这奠定了数据核对和认知的基础,最大程度的避免了“重复数据抽取和维护带来的成本浪费。”

     

    曾经企业的数据抽取就有多份,报表一份,数据仓库一份,地市集市一份,无论是抽取压力、维护难度及数据一致性要求都很高。

     

    同时,统一的基础模型将相关业务领域的数据做了很好的汇聚,解决了数据互通的诉求,这点的意义巨大,谁都知道数据1+1>2的意思。

     

    2、数据中台需要不断的业务滋养

     

    在企业内,无论是专题、报表或取数,当前基本是烟囱式数据生产模式或者是项目制建设方式,必然导致数据知识得不到沉淀和持续发展,从而造成模型不能真正成为可重用的组件,无法支撑数据分析的快速响应和创新。

     

    究其原因是模型建设往往是项目式的建设方式,一旦项目结束,在面对业务提出更多需求时,项目模型团队可能已经撤离了,或者考核指标早已经随着项目结束,模型提供者在主观上没有太大的积极性去满足新的需求,如果当初模型的扩展性设计的不好,或者时间太紧,或者系统稳定的需要,往往导致有心无力满足新的需求,结果是数据模型无法再扩展,成为事实上稳定的但无用的模型。

     

    其实,业务最不需要的就是模型的稳定,一个数据模型如果一味追求稳定不变,一定程度就是故步自封,这样的做法必然导致其他的新的类似的数据模型产生,当越来越多的模型都采用自建的方式满足需求时,意味着老的数据模型就可能要离开历史舞台了,而留下的是割裂的成千上万的模型,也就失去了模型知识沉淀的可能,曾经做过一张几百个字段的万能宽表,由于太大后来就没人敢去动它,随着新的业务不断增加,这张宽表的价值却越来越低直至退出历史舞台。

     

    数据模型不需要“稳定”,而需要不断的滋养,只有在滋养中才能从最初的字段单一到逐渐成长为企业最为宝贵的模型资产。

     

    其实标签也一样,做过不少异动标签或离网模型,曾经效果不错,随着公司转型流量经营,原来以语音异动判断为主的这类标签开始难以适应变化,但后续已经没人能改得动它,这个标签也就退出了历史舞台,退出的可不仅仅是一个标签,这个标签承载的所有的既有经验也就被废弃掉了,想想这些标签当初花了多大的代价做成就会感觉非常可惜。

     

    再以报表为例,企业报表成千上万的原因往往也是没有沉淀造成的,针对一个业务报表,由于不同的业务人员提出的角度不同,会幻化出成百上千的报表,如果有报表中台的概念,就可以提出一些基准报表的原则,比如一个业务一张报表,已经有的业务报表只允许修改而不允许新增,自然老报表就会由于新的需求而不断完善,从而能演化成企业的基础报表目录,否则就是一堆报表的堆砌,后续的数据一致性问题层出不穷,管理成本急剧增加,人力投入越来越多,这样的事情在每个企业都在发生。

     

    3、数据中台是培育业务创新的土壤

     

    企业的数据创新一定要站在巨人的肩膀上,即从数据中台开始,不能总是从基础做起,数据中台是数据创新效率的保障。

     

    搞过机器学习的都知道,没有好的规整数据,数据准备的过程极其冗长,这也是数据仓库模型的一个核心价值所在,比如运营商中要获取3个月的ARPU数据,如果没有融合模型的支撑,得自己从账单一层层汇总及关联,速度可想而知。

     

    很多合作伙伴的数据科学家到一个企业水土不服,除了业务上不熟悉外,往往还面临着数据准备的困境,取数的高难度导致他难以快速的去验证想法,企业想借助外力去搞数据创新有时成了一厢情愿。

     

    标签也一样,企业打造标签可并不仅仅是做几个标签那么简单,它需要打造的是一个标签服务平台,要能最大限度的规范标签的格式,接入方式,组合方式,调用方式等等,只有这样,基于标签的二次快速创新才有可能,企业每发布一个新的标签,就意味着新增了一种能力,这才是数据知识的真正传承。

     

    比如当常驻地模型发布成为标签平台的一个标签后,以后凡是涉及到常驻地判断的都可以直接调用,这极大降低了关于用户位置数据准备的成本。

     

    在如今的互联网时代,企业都在全力谋求转型,转型的关键是要具备跟互联网公司一样的快速创新能力,大数据是其中一个核心驱动力,但拥有大数据还是不够的,数据中台的能力往往最终决定速度,拥有速度意味着试错成本很低,意味着可以再来一次。

     

    4、数据中台是人才成长的摇篮

     

    记得笔者刚进企业的时候,要获得成长一是靠人带,二是找人问,三是自己登陆各种系统去看源代码,这样的学习比较支离破碎,其实很难了解全貌,无法知道什么东西对于企业是最重要的,获得的文档资料也往往也是过了时的。

     

    现在有了数据中台,很多成长问题就能解决,有了基础模型,新人可以系统的学习企业有哪些基本数据能力,O域数据的增加更是让其有更广阔的视野,有了融合模型,新人可以知道有哪些主题域,从主题域切入去全局的理解公司的业务概念,有了标签库,新人可以获得前人的所有智慧结晶,有了数据管理平台,新人能清晰的追溯数据、标签和应用的来龙去脉,所有的知识都是在线的,最新的,意味着新人的高起点。

     

    更为关键的是,数据中台让新人摆脱了在起步阶段对于导师的过渡依赖,能快速的融入团队,在前人的基础上进行创新。

     

    数据中台天然的统一,集成的特性,有可能让新人打破点线的束缚,快速构筑起自己的知识体系,成为企业数据领域的专家。

     

    当然,数据中台的建立不是一蹴而就的,每个企业都应该基于实际打造独有的中台能力,在这个过程中,需要遵循一些原则:

     

    首先,企业的组织架构及机制需要顺势而变,比如以前负责数据的部门或团队往往缺乏话语权,面对业务需求往往是被动的接受的角色,这让一切数据中台的想法化为泡影,需要为数据中台团队授权。

     

    其次,要改变工作方式,现在很多企业的数据团队的主要工作内容就是项目管理、需求管理等等,当一个项目完成后又投入到下一个项目,做好一个需求后又开始负责下一个需求,这样的工作确实非常锻炼人的组织、协调能力,但这样能力的提升与工作时间的长短并不是呈线性增长的,虽然增加了项目和需求管理经验,但并不能在某一个专业领域得到知识和经验的沉淀,随着时间的流逝,越来越多的人会失去最初的工作积极性和创造性,事实上,数据人员只有深入的研究业务、数据和模型,端到端的去实践,打造出数据中台,才是最大的价值创造,才能使得持续创新成为可能。

     

    第三,数据中台的团队要从传统的支撑角色逐步向运营角色转变,不仅在数据上,在业务上也要努力赶超业务人员,中台人员要逐步建立起对于业务的话语权,不仅仅是接受需求的角色,更要能提出合理的建议,能为业务带来新的增长点,比如精确营销。

     

    DT时代,接下来整个社会会进入开放共享的时代,致力于大数据变现的企业最大的价值就是将这些核心数据能力进行对外开放的运营,到那个时代,数据中台将成为企业最为宝贵的资产。

     

    从个人的角度讲,将自己的贡献幻化为中台能力,能够持续的为公司创造价值,这是值得骄傲的事情。( 本文转载自微信公众号:与数据同行,ID:ysjtx_fyp)







    中国最大的技术高管实名社区,提供互联网时代最全面权威、也最前沿有趣的B2B市场信息解读。

    点击【阅读原文】,进入ITValue社区,与CIO们一起脑力激荡!


    我们只提供有价值的干货!

    长按二维码
    关注ITValu

    展开全文
  • 遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。 原则1、载入详细的原子数据到维度结构中 维度建模应该使用最基础...
  • 做好PMC管理三大工作,轻松搞定生产计划与物料控制  PMC管理在工厂企业日常操作中无外乎“后推前拉、滚动排查”,概括来讲PMC管理整体职能体现为六个字:计划、控制、协调。    那么如何做好PMC管理:  一、...
  • 信息分类的基本原则与方法

    万次阅读 2013-09-30 13:47:29
    信息分类应根据信息内容的属性或特征,按照一定的规范和标准直,为了方便信息的交流与共享,应遵循以下原则: 1. 科学性 :在分类时,应选准信息的最稳定的本质属性,作为分类的基础和依据,确保一个稳定的分类...
  • 数据库设计的基本规范和原则

    千次阅读 2017-08-11 09:03:52
    关键字: 数据库建表原则·1. 原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据...〖例〗:一份员工履历资料,在人力资源信息系统中,就对应基本
  • 在此,大圣众包威客平台将为你提供几个数据仓库维度建模的原则,让你妥妥地避开“陷阱”。  1.原子数据需详细  维度建模应该使用最基础的原子数据进行填充,以支持不可预知的来自用户查询的过滤和分组...
  • 基于Web的仓库管理系统的设计与实现

    万次阅读 多人点赞 2019-07-02 20:27:48
    随着我国经济飞速的发展,改革开放的不断深入,企业要想在激烈的市场竞争中立于不败之地,要想继续的发展与生存,没有现代化的管理方式与方法是万万不行的,仓库管理的全面信息化、自动化则是在其中占有极其重要的...
  • 身体仓库管理系统 1模块说明每个模块一般可分为六组基本资料日常作业凭证打印清单与报表 批次处理查询作业 基本资料产品类别设定编码原则设定产品编码仓别设定单据性质设定 产品类别设定 此为后续报表数据收集索引和...
  • 数据库表设计的技巧 1. 原始单据与实体之间的关系  可以是一对一、一对多、多对...这里的实体可以理解为基本表。明确这种对应关系后,对我们设计 录入界面大有好处。  〖例1〗:一份员工履历资料,在人力资源信...
  • Git远程仓库与分支管理

    千次阅读 2019-04-07 00:57:44
    Git远程仓库 、什么是远程仓库 、什么是GitHub 、环境搭建 、添加远程库 、从远程库克隆 、Git分支管理 、创建与合并分支 、解决冲突 、分支管理策略 、Bug分支 、Feature分支 、多人协作 、Rebase
  • 数据仓库基本理论

    千次阅读 2019-08-01 10:58:36
    关系型数据库设计时,遵照一定的规范要求,目的在于降低数据的冗余性和数据的一致性,目前业界范式有:第一范式(1NF)、第二范式(2NF)、第范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。...
  • 仓库管理常见问题

    千次阅读 2010-01-15 23:23:00
    ERP系统上线初期如何加强仓库管理仓库是ERP系统数据源之一,仓库管理也是企业高管的普遍心病。在系统上线初期,每天物料出、入库频繁,收发单据数量,仓管员、录单员加班多,再加上编码观念没有深入人心等原因...
  • 仓库管理系统

    千次阅读 2009-10-12 23:44:00
    一、课题来源二、系统概述1、本课题的研究意义2、本论文的目的、内容及作者主要贡献3、作者的主要贡献管理系统概述1、管理系统现状2、管理信息系统开发方法介绍四、系统调研及可行性分析1、系统调研2、可行性...
  • 基于WEB的仓库管理系统主要用于实现仓库的出入库管理基本功能包括:入库模块、出库模块、商品查看模块、用户注册模块、个人信息管理模块等。本系统结构如下: 入库模块:入库新商品,或者是入库已有商品。 出库...
  • 数据仓库基本概念

    千次阅读 2011-08-12 08:35:27
    数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,它用于支持...功能结构层次:(数据采集、数据存储和管理、数据展现)
  • 仓库管理概况

    千次阅读 2010-04-12 14:23:00
    仓库总体运作流程一、仓库总体运作流程图二、物料收货控制程序(受控)1、目的对本公司进料的数量进行控制,确保进料的数量符合物控要求,及时满足生产需要。2、适用范围适用于本公司对外采购的物料、发外加工的半...
  • Java仓库管理系统(一)

    千次阅读 2017-05-11 12:34:00
    从小到没有写日记的习惯,但本着互联网开放,共享的原则,并且马士兵老师曾说:当你学会一些技能的时候,看到别人正被你会的东西所困扰,你应该去帮助他。所以把仓库管理系统的详解记录一下。说的可能不那么专业,...
  • 仓库管理基础知识总结

    千次阅读 2012-11-07 17:31:33
    第一章 仓库管理 1 、物料的基本知识:  1.1 、物料的分类:  1.1.1 、依物理化学性质来分:如五金、塑胶、线材、电子元件等。  1.1.2 、依形态来分:原料、部品、半成品、成品。  1.1.3 、依重要性来...
  • 仓库管理标准

    千次阅读 2009-11-01 23:37:00
    (1)库存过的定义:正常情况下,对于销售面积1万平方米左右的超市,若基本的送货周期可以维持在每周一次,干货食品以及百货(季节性商品除外)商品的库存不能超过周的销量,否则为库存过,周转时间超过90天...
  • 在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical ...
  • 数据仓库面试资料(基本概念)

    千次阅读 2015-09-12 16:13:31
    什么叫数据仓库? 数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,它用于支持企业或组织的决策分析处理。 数据...
  • 设计原则范式 之 数据库设计范式

    千次阅读 2013-12-30 08:13:43
    设计范式(范式,数据库设计...目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,108
精华内容 12,043
关键字:

仓库管理三大基本原则