精华内容
下载资源
问答
  • 2019-07-07 21:46:38

            数据仓库作为全行或全公司的数据中心和总线,汇集了全行各系统以及外部数据,通过良好的系统架构可以保证系统稳定性和处理高效性,那如何保障系统数据的完备性、规范性和统一性呢?这里就需要有良好的数据分区和数据模型,那数据分区在第三部分数据架构中已经介绍,本节将介绍如何进行数据模型的设计。

    1、各数据分区的模型设计思路:

           数据架构部分中提到了在数据仓库中主要分为以下区域,那各数据区域的主要设计原则如下:

           (1)主数据区:主数据区是全行最全的基础数据区,保留历史并作为整个数据仓库的数据主存储区,后续的数据都可以从主数据区数据加工获得,因此主数据区的数据天然就要保留所有历史数据轨迹。

            1) 近源模型区:主要是将所有入数据仓库的数据表按历史拉链表或事件表(APPEND算法)的方式保留所有历史数据,因此模型设计较简单,只需要基于源系统表结构,对字段进行数据标准化后,增加保留历史数据算法所需要的日期字段即可。

            2)整合模型区:该模型区域按主题方式对数据进行建模,需要对源系统表字段按主题分类划分到不同的主题区域中,并主要按3范式的方式设计表结构,通过主题模型的设计并汇总各系统数据,可以从全行及集团角度进行客户、产品、协议(账户、合同)分析,获得统一视图。比如说,全行有多少客户、有多少产品?通过主题模型事先良好的设计和梳理,可以很快获得相关统计数据。

           主数据区的模型设计按顶层设计(自上而下)为主,兼顾应用需求(自下而上)的方式,即需要有全局视角,也要满足应用需求。那顶层设计主要是需要从全行数据角度对源系统的主要业务数据进行入仓,获得全行客户、业务数据的整体视角,同时又保存所有交易明细数据,满足后续的数据分析需求;应用需求指源系统数据的入仓也需要考虑当前集市、数据应用系统的数据需求,因为数据需求是千变万化的,但是只要保留全面的基础的业务数据,就有了加工的基础,当前的数据需求只是考虑的一部分,更多的需要根据业务经验以及主题模型进行数据入仓和模型设计。

            主数据模型的设计主要自上而下,近源模型层虽然比较简单,但设计步骤和整合模型类型,分为以下几个步骤:

          步骤1:系统信息调研,筛选入仓的系统并深入了解业务数据;

          步骤2:对入仓系统进行表级筛选和字段筛选,并将字段进行初步映射;

          步骤3:根据入仓字段按一定规范设计逻辑模型;

          步骤4:对逻辑模型进行物理化;

           (2)集市区:集市区的设计表结构设计主要按维度模型(雪花模型、星形模型)进行设计,主要是为了方便应用分析,满足数据应用需求,集市区一般以切片的形式保留结果历史数据,但保留期限不会太长,比如只保留月末数据以及当前月份的每日切片数据。

           数据集市需要从数据仓库获得基础数据,对于仓内集市,可以直接访问或通过视图访问,减少数据存储,仓外集市则需要从数据仓库获得批量数据作为基础数据进行存储加工。因此仓外集市还需要设计基础数据的保留策略。

          集市区的设计步骤如下:

          (3)接口区:接口区的设计完全根据数据应用系统的接口方式来进行,一般也是维度模型(事实表+维度表)方式,接口区之前也提到过,不做复杂计算,只做简单关联,可以将复杂计算放到集市或指标汇总层加工。

     

          (4)指标汇总区:作为集市接口区和主数据区的中间层,主要是提供基于各集市和接口数据的共性需求,基于主模型区数据进行统一加工。即面向所有的应用需求来设计,那中间层一般采用维度模型,按从细粒度到粗粒度的方式逐步汇总。由于各数据应用及集市的需求不断变化,指标汇总区也是不断进行完善,许多一开始在集市的加工由于其它集市或应用也需要,则会从集市转移到指标汇总层。常见的数据就是客户、账户、合同等常用的数据实体的宽表(事实表),统一进行汇总后供各数据应用使用。

            另外指标汇总层也包括共性指标的加工,指标可以通过基础指标配置指标计算加工方式获得衍生指标,那这些基础指标和衍生指标的定义、口径以及加工方式可以由指标管理系统来维护并集成到数据标准系统和元数据管理系统中。

            指标汇总区设计步骤如下:

            (5)非结构化数据存储区:非结构化存储区的设计不仅需要考虑非结构化数据本身的存储,同时需要考虑非结构化数据所带有的结构化属性,因此在设计时主要考虑以下几点:

             1)存储路径规划:是需要将非结构化数据按源系统、类型、日期、外部来源等角度进行存储路径的规划,分门别类,便于管理。

             2)对非结构化数据的元数据建立索引:比如对于凭证的影像,需要有账户、流水号、客户名等相关结构化数据,以便完整描述影像图片的来源,通过对这些结构化数据建立索引,方便查找。

             3)对部分文档内容建立索引:对于部分文档如合同电子版、红头文件PDF需要建立内容索引,以便快速搜索查找文件内容,一般可用支持HADOOP的ElasticSearch来实现。

             4)设立计算区和结果区:由于非结构化数据往往需要使用MAPREDUCE或程序化语言进行处理,也会产生中间临时文件和结果数据,因此需要规划计算区和结果区来存放这些数据。

     

            (6)历史数据存储区:历史数据区作为历史数据的归档,即包括结构化数据,也包括非结构化数据,对于历史数据除了存储也需要方便查找,历史数据区的规划设计需要考虑非结构化数据存储区的存储、索引设计外,还需要考虑以下几点:

            1)压缩,由于历史数据使用频率低,可以选择压缩率较高的算法,降低存储空间。

             2)容量规划:由于历史数据归档会越来越大,因此需要提前进行容量规划以及历史数据清理。比如10年以上的数据进行删除。

             3)可设计一个管理系统对历史数据进行归档、查找以及管理。

     

            (7)实时数据区:实时数据区需要使用部分批量数据来和实时流数据进行关联加工,因此可从主数据区获得所需要的数据后进行存放在实时数据区的关联数据区,同时对于加工结果不仅可以推送到KAFKA等消息中间件,同时也可输出到实时数据区的结果区进行保留。

     

            (8)在线查询区:在线查询区主要在线提供计算结果查询,常用HBASE来实现,设计按照接口来分别存放到不同的HBASE表,字段内容也主要是接口字段内容。HBASE表可以根据应用或者接口类型进行分目录和分用户。由于在线查询区和实时数据区考虑到作业的保障级别以及资源竞争,往往会单独建立一套集群,与批量作业集群进行隔离,在线查询的结果计算可以在批量集群计算后加载到在线查询区。

     

           后续将分别对主数据区、集市及汇总指标层模型设计进行介绍,敬请关注。

    目前字节跳动数据团队(上海)有内推职位,主要面向字节所有产品数据仓库及大数据开发岗位,如tiktok等,包括社招,校招,实习,大家可在2021年5月23号之前私信联系,内推方式成功率更高,机会有限,先到先得!

    更多相关内容
  • 数据仓库多维数据模型设计

    万次阅读 多人点赞 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...

    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。


    数据仓库建模方法

    大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。

    数据仓库的建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。

    目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。

    我们下面给大家详细介绍一下这些建模方法。


    范式建模法(Third Normal Form,3NF)

    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。
    目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。
    在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :
    每个属性值唯一,不具有多义性 ;
    每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;
    每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
    由于范式是基于整个关系型数据库的理论基础之上发展而来的,因此,本人在这里不多做介绍,有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
    根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。

    从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。
    这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
    数据仓库的域模型应该包含企业数据模型的域模型之间的关系,以及各主题域定义。
    数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
    在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类,以及实体的关系等。
    以笔者的观点来看,Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。
    但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。


    维度建模法

    维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。

    事实表是用来记录具体事件的,包含了每个事件的具体要素,以及具体发生的事情;维表则是对事实表中事件的要素的描述信息。

    比如一个事件会包含时间、地点、人物、事件,事实表记录了整个事件的信息,但对时间、地点和人物等要素只记录了一些关键标记,比如事件的主角叫“Michael”,那么Michael到底“长什么样”,就需要到相应的维表里面去查询“Michael”的具体描述信息了。

    基于事实表和维表就可以构建出多种多维模型,包括星形模型、雪花模型和星座模型。

    维度建模法最被人广泛知晓的名字就是星型模式(Star-schema)。

    [1345621614_4017.JPG]

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。
    通过这些预处理,能够极大的提升数据仓库的处理能力。
    特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。
    不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
    但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。
    而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。
    而在这些与处理过程中,往往会导致大量的数据冗余。
    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
    因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。
    维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。


    实体建模法

    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。
    从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。
    那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。
    即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明。
    例如我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:
    实体,主要指领域模型中特定的概念主体,指发生业务关系的对象。
    事件,主要指概念主体之间完成一次业务流程的过程,特指特定的业务过程。
    说明,主要是针对实体和事件的特殊说明。
    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。


    维度建模法数据模型的区别

    多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。


    星型模式(star schema)

    星型模式的核心是一个大的中心表(事实表),一组小的附属表(维表)。星型模式示例如下所示:

    [903014-20160324180338683-1916113766.jpg]

    [200916184066377.jpg]

    可以看出,星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:

    a. 维表只和事实表关联,维表之间没有关联;

    b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;

    c. 以事实表为核心,维表围绕核心呈星形分布;


    雪花模式(snowflake schema)

    雪花模式是星型模式的扩展,其中某些维表被规范化,进一步分解到附加表(维表)中。雪花模式示例如下图所示:

    [903014-20160324180236104-1134926519.jpg]

    [200918380319666.jpg]

    从图中我们可以看到地址表被进一步细分出了城市(city)维。supplier_type表被进一步细分出来supplier维。

    星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重。


    事实星座模式(Fact Constellation)或星系模式(galaxy schema)

    数据仓库由多个主题构成,包含多个事实表,而维表是公共的,可以共享,这种模式可以看做星型模式的汇集,因而称作星系模式或者事实星座模式。本模式示例如下图所示:

    [903014-20160324175828948-2089267269.jpg]

    [200924338912918.jpg]

    如上图所示,事实星座模式包含两个事实表:sales和shipping,二者共享维表。

    事实星座模式是数据仓库最常使用的数据模式,尤其是企业级数据仓库(EDW)。

    前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

    这也是数据仓库区别于数据集市的一个典型的特征,从根本上而言,数据仓库数据模型的模式更多是为了避免冗余和数据复用,套用现成的模式,是设计数据仓库最合理的选择。


    三种模式对比

    归纳一下,星形模式/雪花模式/星座模式的关系如下图所示:

    [903014-20160324103125073-1838397443.jpg]


    实例

    在进行维度建模前,首先要了解用户需求。而笔者在数据库系列的第一篇就讲过,ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后,得到以下ER图:
    [903014-20160324160704776-1647702727.png]

    随后可利用建模工具将ER图直接映射到关系图:
    [903014-20160324160724151-2139740081.png]

    需求搜集完毕后,便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式,维度建模的关键在于明确下面四个问题:

    1.哪些维度对主题分析有用?

    本例中,根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的;

    2.如何使用现有数据生成维表?

    a. 维度PRODUCT可由关系PRODUCT,关系VENDOR,关系CATEGORY连接得到;

    b. 维度CUSTOMER和关系CUSTOMER相同;

    c. 维度STORE可由关系STROE和关系REGION连接得到;

    d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到;

    3.用什么指标来”度量”主题?

    本例的主题是销售,而销量和销售额这两个指标最能直观反映销售情况;

    4.如何使用现有数据生成事实表?

    销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到;

    明确这四个问题后,便能轻松完成维度建模:

    [903014-20160324160936308-1545323262.png]

    细心的读者会发现三个问题:1. 维表不满足规范化设计(不满足3NF);2. 事实表也不满足规范化设计(1NF都不满足); 3. 维度建模中各维度的主码由***ID变成***Key;

    对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。

    因此虽然可以以雪花模型进行维度建模,如下所示:

    [903014-20160324162335339-887948324.png]

    但这样会加大查询人员负担:每次查询都涉及到太多表了。因此在实际应用中,雪花模型仅是一种理论上的模型。星座模型则出现在”维度建模数据仓库”中,本文后面将会讲到。

    对于第三个问题,***Key这样的字段被称为代理码(surrogate key),它是一个通过自动分配整数生成的主码,没有任何其他意义。使用它主要是为了能够处理”缓慢变化的维度”。


    经典星座模型

    前文已经讲过,有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用:共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析:

    1. 共享维度

    以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:

    [903014-20160324163010683-2065536046.png]

    1. 细节/聚集事实表

    细节事实表(detailed fact tables)中每条记录表示单一事实,而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看,细节事实表通常有设置TID属性,而聚集事实表则无。

    两种事实表各有优缺点,细节事实表查询灵活但是响应速度相对慢,而聚集事实表虽然提高了查询速度,但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中,聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表:

    [903014-20160324163348964-833179105.png]

    展开全文
  • Neo4j数据模型设计

    千次阅读 2017-06-19 09:30:17
    数据模型设计是数据建模的第一步,因为Neo4j不需要模式结构定义,所以使用简单框图就可以为一个项目或应用设计数据模型。创建数据模型之后,就可以使用SDN进行数据实体建模和一些数据访问的设计。 本文选自《Neo4j...

    摘要: 数据模型设计是数据建模的第一步,因为Neo4j不需要模式结构定义,所以使用简单框图就可以为一个项目或应用设计数据模型。创建数据模型之后,就可以使用SDN进行数据实体建模和一些数据访问的设计。 本文选自《Neo4j全栈开发》。

      开始数据模型设计,一般通过分析业务需求就可以提取出需要建立的节点和关系,然后使用节点和关系画出框图,即可完成数据模型的设计。下面通过两个实例来简要说明数据模型的设计过程。

    用户访问控制数据模型

      在一个访问控制系统中,它的业务需求可以简单地描述为:怎样控制一个用户的访问权限。即一个用户登录系统后,他对系统的哪些资源具有访问权限。通过分析和结合以往的经验,我们可能需要四个节点,分别是用户、部门、角色和资源;三个关系,分别是隶属、拥有和权限。这样,我们就可以画出下图的用户访问控制数据模型。
                 图片描述
      这个数据模型是否合理、是否符合业务需求?我们可以用这个简单框图模拟一下业务流程,简单地测试一下它的合理性。首先看看从这个框图中能不能读出类似这样的信息:隶属于一个部门的一个用户拥有哪些角色就能对哪些资源具有访问权限。如果可以,就可以说明这个模型设计是可行的。
      很明显,这个数据模型设计的业务流程是通顺的。因为对于这个框图,我们可以这样读出它的流程:部门具有一些隶属用户,用户拥有一些角色,角色对一些资源具有访问权限。
      有了这个数据模型之后,就可以对节点和关系进行建模了。在建模中再来确定节点和关系的属性,例如,用户节点可能需要用户名、密码、性别、邮箱、创建日期等属性,同时还要确定关系的对等方式,例如,是一对一、一对多还是多对多等。对于这个实例来说,用户与部门的隶属关系是多对一关系,用户与角色的拥有关系和角色与资源的权限关系都是多对多关系。

    购物网站数据模型

      如果觉得上面的数据模型简单了一点,那么接下来我们使用一个业务需求比较复杂的实例来试一试,比如一个购物网站。购物网站的业务需求大概具有这样的流程:首先商家上架了商品,然后顾客浏览或查找商品,顾客找到自己需要的商品之后,确定购买,接着使用他的账户支付款项,商家收到货款后,将商品快递给顾客,从而完成一笔交易。根据这个业务流程,我们画出下图的数据模型。
                图片描述
      使用这个数据模型,我们同样也可以先测试一下,即看一看它能不能通顺地读出一个购物网站的基本流程。比如完成一个完整的购物流程,首先是商家的库存要上架商品,然后是顾客购买商品,即商品出售形成订单;接下来是顾客结算订单,使用账户付款,形成支付记录,同时商家账户收到款项,并且订单进入发货状态,同时生成物流记录;这时候,商家的库存办理商品出库,这样商品就通过快递进入送货过程之中;最后顾客从收货地址收到商品,并对订单执行确认收货操作,同时对商品进行评价,至此完成一次购物流程。这就可以说明,这个数据模型所表现的业务流程是通顺的,所以它的设计是合理的。
      一般的购物网站还有购物车这一项,以满足顾客一次选购多个商品的需求,所以还必须设计一个购物车,即在上述流程中插入一个挑选商品到购物车的过程。其中购物车只是顾客与商品的一个关联关系。
               图片描述
      这下应该很完整了吧?这个模型的整个流程可以通过数据库来表示。下图是一个网上书店的模拟数据。
               图片描述
      其中“顾客1”挑选了两本书到他的购物车中,“顾客2”购买了一本小说,完成了一个完整的购物流程。
      不过,如果再仔细想想,则可能会发现,上面的流程还需要更多的细化。比如,上面的数据模型虽然可以表现一个正常交易的流程,但是如果出现不正常的交易情况,那这个数据模型就走不通了。例如,顾客下单后,有可能又不要了,所以,这就需要有撤销订单流程。又如,顾客收到商品之后,可能因为质量问题需要退货和退款,所以,还需要增加相应的退货和退款处理流程。另外,商家售卖的一种商品中还有可能具有型号、颜色、价格和库存数量等不同分类,所以,对于商品节点还有必要进行细分。
      不难看出,对上面的数据模型还必须再进行加工和细化。当然,除了这些,还可能有其他各种各样的情况。不过,不管是什么情况,都可以通过简单框图对数据模型进行细化和加工。至于最终怎么建立起一个完整的购物网站数据模型,这里就不再深入探索了。
      本文选自《Neo4j全栈开发》,点此链接可在博文视点官网查看此书。
                          图片描述
      想及时获得更多精彩文章,可在微信中搜索“博文视点”或者扫描下方二维码并关注。
                             图片描述

    展开全文
  • 数据仓库模型设计与工具

    千次阅读 2020-04-01 10:09:57
    数据模型对于数仓是最核心的东西,数据模型是数据组织和存储方法,模型的好坏,决定了数仓能支撑企业业务多久。 为什么大多数企业,数仓都要重建,这不仅仅是业务拓展、发展迅速,很大一部分是因为模型建的很烂。 ...

    数据模型对于数仓是最核心的东西,数据模型是数据组织和存储方法,模型的好坏,决定了数仓能支撑企业业务多久。为什么大多数企业,数仓都要重建,这不仅仅是业务拓展、发展迅速,很大一部分是因为模型建的很烂。

    一、基本概念

    维度建模,是数据仓库大师Ralph Kimball提出的,是数据仓库工程领域最流行的数仓建模经典。

    维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。

    它是面向分析的,为了提高查询性能可以增加数据冗余,反规范化的设计技术。

    • 1.1事实表

    事实表产生于业务过程,存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看,事实表行对应一个度量事件。

    事实表根据粒度的角色划分不同,可分为事务事实表、周期快照事实表、累积快照事实表。

    (1)事务事实表,用于承载事务数据,通常粒度比较低,它是面向事务的,其粒度是每一行对应一个事务,它是最细粒度的事实表,例如产品交易事务事实、ATM交易事务事实。

    (2)周期快照事实表,按照一定的时间周期间隔(每天,每月)来捕捉业务活动的执行情况,一旦装入事实表就不会再去更新,它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据,通常粒度比较高,例如账户月平均余额事实表。

    (3)累积快照事实表,用来记录具有时间跨度的业务处理过程的整个过程的信息,每个生命周期一行,通常这类事实表比较少见。

    注意:这里需要值得注意的是,在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。

    • 1.2维度表

    维度表,一致性维度,业务过程的发生或分析角度,我们主要关注下退化维度和缓慢变化维

    (1)退化维度(DegenerateDimension)

    在维度类型中,有一种重要的维度称作为退化维度,亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度一般在分析中可以用来做分组使用。

    (2)缓慢变化维(Slowly Changing Dimensions)

    维度的属性并不是始终不变的,它会随着时间的流逝发生缓慢的变化,这种随时间发生变化的维度我们一般称之为缓慢变化维(SCD)。

    SCD常用的三种处理方式:

    ① TYPE1 直接覆盖原值

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHgR0hXEic2ooibCQcliandOomZCkS90JesBrE3XfK9FT0L4mzloqeiaBLGiaQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    ② TYPE2 增加维度行

         在为维度成员增加新行时,需为其分配新的主代理键。并且,至少需要在维度行再增加三列:有效日期、截止日期、行标识。这个地方可联想拉链表设计。

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHgJQjR5Q6icbWznia9JUHr1DA4I6nNictPvXmgNayXhgcBcL96FOJGmY8kw/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    ③ TYPE3 增加属性列 

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHgB52FtYIJ0gs20XVBtSFsiaMFCtqsDZjAEkR03vFibnATtpNEBzkn3hnA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    ④ 混合方式

    可根据实际业务场景,混合或选择使用以上三种方式,以快速方便而又准确的分析历史变化情况。

    1.3粒度

    用于确定某一事实表中的行表示什么,是业务最小活动单元或不同维度组合,即业务细节程度。

    1.4维度建模流程

    维度建模步骤:选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。


     

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHgtnTjZuvh3c4TEP1jM7CDVNEHiaoic9IEexcQmqO3ZPPdnnia6icZ8vuZSQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

     

    声明粒度,为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表,需要注意的是,来自多个业务过程的事实合并到合并事实表时,它们必须具有同样等级的粒度。
     

    二、建模方法--经典数据仓库模型

    数据仓库建模方法论可分为:维度建模、范式建模、Data Vault模型、Anchor模型。

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHgmXfLOSrCP0SCAWU2zibsJSNKc9ablZkicxwtLricqoiaus0yVaH1ia2iaOibQ/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    2.1维度模型

    企业中最流行、也是最经典的数仓建模经典,数据仓库大师Ralph Kimball的经典著作《数据仓库工具箱 维度建模权威指南 第三版》一本书进行了论述。从事数据仓库/ETL/BI的同学,强烈建议买一本至少读一遍。

    按数据组织类型划分可分为星型模型、雪花模型、星座模型。

    (1)星型模型

    星型模型主要是维表和事实表,以事实表为中心,所有维度直接关联在事实表上,呈星型分布。

    https://mmbiz.qpic.cn/mmbiz_png/1OYP1AZw0W1UwPYvStthXYOIVIJMRPHg8cs4Mkghw3E3KRLbgSgMAT1PHibFQ5noseRpicmylmKp3gKPc0LMAyDg/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    图来源于Kimball《The Data Warehouse Toolkits -3rd Edition》

    (2)雪花模型

    雪花模型,在星型模型的基础上,维度表上又关联了其他维度表。这种模型维护成本高,性能方面也较差,所以一般不建议使用。尤其是基于hadoop体系构建数仓,减少join就是减少shuffle,性能差距会很大。

    (3)星座模型

    星座模型,是对星型模型的扩展延伸,多张事实表共享维度表。数仓模型建设后期,大部分维度建模都是星座模型。

    2.2范式模型即实体关系(ER)模型,数据仓库之父Immon提出的,从全企业的高度设计一个3NF模型,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF。此建模方法,对建模人员的能力要求非常高。
     

    2.3Data Vault模型

    DataVault由Hub(关键核心业务实体)、Link(关系)、Satellite(实体属性) 三部分组成 ,是Dan Linstedt发起创建的一种模型方法论,它是在ER关系模型上的衍生,同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。

    2.4Anchor模型
    高度可扩展的模型,所有的扩展只是添加而不是修改,因此它将模型规范到6NF,基本变成了K-V结构模型。企业很少使用,本文不多做介绍。


    三、建模工具

    Datablau DDM是新一代数据模型管理工具,由ERwin数据建模研发骨干开发团队荣誉出品。传统建模工具主要面向设计,而DDM创新的融合了数据治理理念,把数据治理推进到开发流程中,进行开发态的源头治理,解决了标准落地的难题。从根本上控制企业增量的数据质量问题。目前已经在多家银行、基金、保险、能源、政府、制造业等使用。

    三范式模型在建模工具中的展示

    维度模型在建模工具中的展示

     

    DataVault模型在建模工具中的展示

     

    结语:

    对于数仓而言,模型就是命脉,好与坏直接决定企业数据存储、处理和应用。

    对于维度建模,真正理解了粒度和一致性维度,也就理解了维度建模的魂。

    对于建模工具,没有最好只有更好,适合业务的就是最好的。


    Datablau Data Modeler简介

    DDM(Datablau Data Modeler)是国内首创的专业建模工具,是数据治理体系的重要组成部分。数据模型是“所有系统、文档和流程中包含的所有数据的语境。是生数据的知识。”换句话说,如果没有数据模型,组织IT系统中收集和存储的所有数据都会失去意义,也就没有业务价值。


    Datablau简介

    北京数语科技有限公司(以下简称“数语科技”)成立于2016年,是专注于数据治理领域的国内自主知识产权的专业软件产品提供商,主要业务是数据治理软件产品的研发与销售。数语科技的创始团队全部来自CA erwin,天然具有世界级水准的软件产品开发能力。

    创始人兼CEO王琤:曾任职erwin全球研发总监,拥有超过十年以上数据建模和数据管理的从业经验。

    CTO朱金宝:曾任职erwin首席架构师,先后服务多家全球知名企业,并曾全程参与中国建设银行数据治理项目,目前全面负责Datablau软件平台的研发工作和关键项目的实施工作。

    数语科技根据DAMA理论和中国国情独立研发Datablau新一代数据治理平台,平台由Datablau DDM数据建模产品和Datablau DAM数据资产管理平台两大部分组成,全部拥有软件著作权和知识产权,一站式全面满足中国企业的数据治理需求。其中数据建模产品DDM是Datablau填补国内空白的重量级产品,帮助中国客户摆脱国外产品的垄断现状。2018年,Datablau数据治理平台通过了中国信息通信研究院严格苛刻的产品评测并获得的“最佳大数据产品”奖。

    更多渠道了解我们
    官网www.datablau.cn
    关注我们,及时了解数据治理干货

     

    展开全文
  • 数据仓库之模型设计

    千次阅读 多人点赞 2020-03-22 21:01:22
    数据仓库(模型设计) 一、数据仓库与数据库的区别 1、数据仓库是集成的,数据库为单一的业务提供服务。 2、BI结构:数据整合层、数据服务层、应用分析层、信息展现层 3、数据层库结构 ODS(临时存储层),一般...
  • 证券期货行业数据模型设计

    千次阅读 2020-04-12 06:57:12
    证券期货行业数据模型(以下简称“SDOM”)是以证券期货行业相关法律法规、业务规则、制度及流程等为依据,提取市场全业务流程与数据共性,形成具有通用性、稳定性和扩展性的数据模型。 行业数据模型是以“交易”、...
  • 在数据库技术中,用数据模型的概念描述数据库的结构和语义,是对现实世界的数据抽象。数据模型是研究数据库技术的核心和基础。 文章目录1.概念数据模型(CDM)2.逻辑数据模型(LDM)3.物理数据模型(PDM) 1.概念...
  • 概念数据模型、逻辑数据模型、物理数据模型

    万次阅读 多人点赞 2018-04-30 10:11:33
    最近在系统的学习数据库存储方面的知识加上在公司经常听同事们说起CDM,结合前段时间对MySQL的使用的心得将概念数据模型(Concept Data Model,CDM)、逻辑数据模型(Logical Data Model,LDM)、物理数据模型...
  • 数据仓库-物理模型设计

    千次阅读 2019-07-07 13:13:01
    数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。... 为确定数据仓库的物理模型设计人员必须做这样几方面工作:首先要全面了解所选用的数据库管理系统,特别是存储结构和存取方法;其...
  • 多维数据模型设计

    千次阅读 2017-11-04 15:34:00
    多维数据模型设计概述 一、维表、事实表 二、星型模式(star schema) 三、雪花模式(snowflake schema) 四、事实星座模式(Fact Constellation)或星系模式(galaxy schema) 五、度量:分类与计算 六、多维数据...
  • 数据模型(Data Model)是; 数据特征的抽象,是数据库管理的教学形式框架。数据库系统中用以提供信息表示和操作手段的形式构架。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。 1...
  • 数据模型所描述的内容包括三个部分:数据结构、数据操作、数据约束。  1)数据结构:数据模型中的数据结构主要描述数据的类型、内容、性质以及数据间的联系等。数据结构是数据模型的基础,数据操作和约束都建立在...
  • 1.2 数据模型 数据模型是对现实世界数据特征的抽象。 通俗地讲数据模型就是现实世界的模拟。 数据模型应满足三方面要求: 能比较真实地模拟现实世界; 容易为人所理解; 便于在计算机上实现; 数据模型是数据库...
  • 专门针对物联网终端和网关设计数据模型,理论上可以将终端的任何信息通过TCP/UDP直连的方式传递给网关或服务器。 数据模型如下: 上述为终端数据包模型,分为两个部分:Data和用于标识的DataType,比如我需要...
  • 由于其功能与作用的差异,结合项目规模等实际情况,不一定会全部使用以节省项目时间(有时候直接设计物理模型),但我认为不应该被冠以“大家对这个概念的理解不同”不同之名而歪曲数据模型的定义。事实上,
  • PowerDesigner–创建概念数据模型 Conceptual Data Model 概念数据模型(CDM)帮助您分析信息系统的概念结构,以识别要表示的主要实体、它们的属性以及它们之间的关系。 CDM比逻辑(LDM)或物理(PDM)数据模型更抽象。 ...
  • 数据模型是指数据库的组织形式,它决定了数据库中数据之间联系的表达方式,即把在计算机中表示客观事物及其联系的数据及结构称为数据模型。本文详细讲述传统三大数据模型和空间数据模型。 一、数据模型概述 数据模型...
  • 数据仓库架构及模型设计基础

    千次阅读 多人点赞 2019-06-26 21:58:18
    注:本文所有内容摘自《Hadoop构建数据仓库实践》 1.数仓架构 1.1数据集市架构 数据集市是按主题域组织的数据集合,用于支持部门级的决策。有两种类型的数据集市:独立数据集市和从属数据集市。 独立数据集市集中...
  • 1.概念数据模型E-R图 2.设计E-R图,过程,例子 3.逻辑数据模型,分类
  • 模块开发-数据仓库的设计 及星型模型 雪花模型 星座模型 模块开发—数据仓库设计 1.维度建模:专门用于分析性数据库【还有数据仓库/数据集市建模的方法】的设计数据集市可以理解为一种小型的数据仓库。 维度表...
  • 2.1 维度模型 2.1.1 星型模型 2.1.2 雪花模型 2.1.3星座模型 2.2 范式模型 2.3 Data Vault模型 2.4 Anchor模型
  • IBM金融数据模型数据存储模型FSDM,是金融行业应用极为广泛的数据模型,可以作为我们构建企业级数据仓库主题域模型划分的重要依据。本文就IBM FSDM主题域模型进行初步的介绍。 二、模型结构 三、标准定义 ...
  • 曾经有几年逻辑数据模型很火热,大家都研究这个。道理上来说,逻辑数据模型并不仅仅是用在数据仓库。在OLTP系统中建立良好的数据模型更加重要。但只不过这东西从实践上被推广开来,很大程度是原NCR/Teradata适用于...
  • 关系数据库模型设计

    千次阅读 2020-05-19 17:13:17
    本文从现实世界-概念世界(信息世界)-机器世界(数据世界)逐级抽象,旨在以浅显易懂的语言描述关系数据库应该如何建模,最后用简单名了的描述给出关系模型设计范式的含义。
  • 理论篇~第三章 数据模型设计

    千次阅读 2017-09-24 10:07:02
    常见数据模型介绍  1 ER模型  数据仓库之父Bill Inmon提出的建模方法,是从全企业的高度设计一个3NF模型,用实体关系(Entity Relationship,ER)模型描述企业业务。其具有以下几个特点:  需要全面了解企业...
  • 前面的两篇博客分别介绍了概念数据模型、逻辑数据模型以及物理数据模型和逻辑数据模型经常使用的三种数据模型,这篇博客介绍在数据库的设计过程中将概念数据模型转化为逻辑数据模型的方法,以及涉及的一些基本的概念...
  • HBase数据模型和表设计思路

    万次阅读 2018-12-05 07:48:13
    最近在网上找到一篇描述HBase的设计思路和使用要点的文章,觉得还不错,主要是基于HBase官网推荐的一篇博客,仔细阅读了这一片博客之后,总结一下关于HBase的数据模型和表设计思路。 官方推荐的博客原文地址:...
  • 数据仓库主题一(宽表模型设计

    万次阅读 2020-07-16 14:26:21
    一、典型的数据仓库建模思想一般主流分为两种 第一种 ER模型数据仓库之父父 Bill lnmon 提出的建模方法是从全企业的高度设计 3NF 模型,用实体关系( Entity Relationship, ER )模型描述企业业 务,在范式理论上...
  • 银行数据仓库体系实践(9)--主题模型

    万次阅读 多人点赞 2019-07-13 11:49:27
    在银行主题模型中,每个数据仓库的实施公司会有金融行业或银行业的主题模型,这个模型会根据新的业务不断进行完善,是各实施公司的业务经验积累。一个良好的模型数据仓库的实施起到了事半功倍的效果,虽然不同的...
  • 数据仓库-逻辑模型设计(粗讲)

    千次阅读 2019-07-09 18:51:04
    分析主题域 在概念模型设计中,我们确定了几个基本的主题域,但是,数据仓库的设计方法是一个逐步求精的过程,在进行设计时,一般是一次一个主题或一次若干个主题地逐步完成的。所以,我们必须对概念模型设计步骤中...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,027,380
精华内容 410,952
关键字:

数据模型设计报告