精华内容
下载资源
问答
  • 数据仓库多维数据模型设计

    万次阅读 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]

    展开全文
  • 数据模型

    千次阅读 2006-12-26 10:47:00
    数据模型是数据库系统的核心和基础。任何一种数据库系统,都必须建立在一定的数据模型之上。由于现实世界的复杂性,不可能直接从现实世界中建立数据模型。现实世界 →(抽象)→ 信息世界 →(转化)→ 数据世界...
    建立数据库系统的目的,是为了实现对现实世界中各种信息的计算机处理。换言之,要实现计算机对现实世界中各种信息的自动化、高效化的处理,首先必须建立能够存储和管理现实世界中的信息的数据库系统。数据模型是数据库系统的核心和基础。任何一种数据库系统,都必须建立在一定的数据模型之上。由于现实世界的复杂性,不可能直接从现实世界中建立数据模型。
    现实世界 →(抽象)→ 信息世界 →(转化)→ 数据世界
                          (建立概念模型)        (建立数据模型)
    (而首先要把现实世界抽象为信息世界,并建立信息世界中的数据模型,然后再进一步把信息世界中的数据模型转化为可以在计算机中实现的、最终支持数据库系统的数据模型)。信息世界中的数据模型又称为概念模型,概念模型必须具有:
    (1)抽象的真实性:是对现实世界本质的、确实存在的内容的抽象。而忽略了现实世界中非本质的和与研究主题无关的内容。
    (2)完整、精确的语义表达力,能够模拟现实世界中本质的、与研究主题有关的各种情况
    (3)易于理解和修改
    (4)易于向DBMS所持的数据模型转换,现实世界抽象成信息世界的目的,是为了用计算机处理现实世界中的信息。
    概念模型,作为从现实世界到其数据世界转换的中间模型,它不考虑数据的操作,而只是用比较有效的、自然的方式来描述现实世界的数据及其联系。
    最著名、最实用的概念模型设计方法是P.P.S.Chen于1976年提出的“实体-联系模型”(Entity-Relationship Approach),简称E-R模型。
     
     
    5.1 建立实体联系模型
     
    1、E-R模型的基本构构成:
    三个主要概念:实体集、联系集和属性,分别用矩形框、菱形框和椭圆表示。
    联系集的类型:一对一(1:1)、 一对多(1:n)、多对多(m:n)及表示
    主码的表示:用带下划线的属性表示
    2、多元联系
    在E-R中,可以表示两个以上实体集之间的联系,称为多元联系。
    3、联系的属性
    联系集和实体集一样,也可以有自己的属性,来表现联系的特点。
    4、自身联系
    在一个联系中,一个实体可以出现两次或多次,扮演多个不同角色,此种情况称为实体集的自身联系。
    例如,同一部门中,职工与职工之间可以有领导和被领导的关系。
    5、子类和 is-a 层次联系
    信息世界中常常有这样的实体集B,它属于另一个实体集A,B中实体的都有特殊的属性需要描述,并且这些特殊属性对实体集A的其它实体无意义。在E-R模型中,称B是A的子类,或A是B的父类。两类实体集之间存在着一种层次联系——is-a 联系。
    例如,一个企业中的职工实体集和经理实体集,经理集中的每一位经理,又是职工集中的一位职工,他具有职工的所有属性,但他自己的属性“任职时间”对职工集的其他职工却没意义。此时,我们可以说,经理集与职工集存在着 is-a 联系。(P85图5-8所示)
     
    5.2 ER模型的设计方法
     
    在设计E-R模型时,首先应根据需求分析,确认实体集、联系集和属性这三种E-R模型的基本要素。
    需要强调的三条设计原则是:
    (1)相对原则:
    建模的过程实际上是对对象抽象的过程。实体、联系、属性,是对同一个对象抽象过程的不同解释和理解。在同一情况下不同的人,或同一人在不同的情况下,对事物抽象的结果可能是不同的。
    在E-R模型的整个设计过程中,实体、联系和属性不是一成不变的,而可能会被不断的调整和优化。
    (2)一致原则:
    同一对象在不同的业务系统中抽象的结果要求保持一致。因为业务系统是建立系统的各子系统。
    (3)简单原则:
    为简化E-R模型,现实世界中的事物,能作属性对待时,应尽量作为属性处理。
    属性与实体和联系之间,并无一定界限。当属性满足如下两个条件时,就不能作实体或联系对待:
    ①它不再具有需要进一步描述的性质,因为属性在含义上是不可再分的数据项
    ②属性不能再与其它实体集具有联系,即E-R模型中的联系只能是实体集之间的联系。
    设计一个大型的企业或单位的E-R模型,一般按照先局部、后整体,最后优化的方法进行。
    下面以一个企业的职工信息管理系统为例,说明E-R模型的设计过程:
    该管理系统涉及到三个部门的业务:
    Ø         人事处管理职工的基本信息、职务信息和所在部门信息
    Ø         财务处管理职工的工资情况
    Ø         科研处管理科研项目和职工参加项目的情况
     
    第一步:确定局部应用范围,设计局部E-R模型
    1、确定局部应用范围
    本例中初步决定按照不同的职能部门划分不同的应用范围,即分为三个子模块:人事管理、工资管理和项目管理。
    下面以人事管理为例,说明设计局部E-R模型的一般过程。
    2、确认实体集
    在人事管理中,需要对职工、部门、职称职务进行管理,所以需要确定相应的三个实体集
    3、确认实体集间的联系集
    需要判断所有二二实体集之间是否存在或存在着怎样联系:
    Ø         职工与部门:n:1;
    Ø         职工与职称职务:m:n
    Ø         部门与职称职务之间没有联系
    4、确认实体集及联系集的属性
    Ø         职工:职工号、姓名、性别、年龄
    Ø         部门:部门号、名称、电话
    Ø         职称职务:代号、名称、津贴,住房面积
    Ø         职工和职称职务的联系:任职时间;
    Ø         职工和部门的联系,没有单独的属性;
    5、画出局部E-R模型
    (P88图5-12、13、14分别人事管理、工资管理、项目管理的局部E-R模型)
     
    第二步:集成局部E-R模型,形成全局初步的E-R模型
    由于各局部E-R模型设计时所考虑问题的角度不同和各自业务需要的不同,合并各局部E-R模型时可能会存在许多不一致的地方,称为冲突。而这些冲突,必须在合并局部E-R模型时进行合理的消除。
    冲突主要有如下三类:
    1、命名冲突:
    包括实体集名、联系集名和属性名之间的同名异义和异名同义等冲突。
    同名异义:同样的名称,在不同的局部E-R模型中表示不同含义的对象
    异名同义:相同意义的对象在不同局部E-R模型中具有不同的名称
    命名冲突通过不同部门间协商解决
    2、属性冲突:
    包括属性值类型、取值范围、数量单位的冲突
    3、结构冲突:
    包括两种情况:
    Ø         一是同一对象在不同应用中具有的抽象不同。如职工工资,在人事部门的业务中可能作为属性对待,而在财务部门的业务中会作为一个实体集处理。另外,实体集间的联系在不同的业务应用中也可能有不同的联系集。
    Ø         二是同一实体在各局部应用中包含的属性个数和属性排列次序不完全相同。
    处理冲突,要根据具体需求分析,在各方兼顾的情况下,对发生冲突的属性、实体集、联系集进行合理的调整和综合。形成一个全系统用户共同理解和认可的统一的E-R模型,是合并各局部E-R模型的主要工作和关键所在。
    在集成全局E-R模型时,一般采用两两集成的方法进行。将两个具有相同实体集的E-R模型,以该相同实体集为基准进行集成。
    第三步:消除冗余,优化全局E-R模型
    一个“好”的全局E-R模型,除了能够满足用户的功能需求外,还必须符合下列三个条件:
    Ø         实体集个数应尽可能少;
    Ø         实体集所含属性尽可能少;
    Ø         实体集间的联系无冗余。
    对于具有1:1的联系的,且有相同码的两个实体集可以合并,以减少实体集的个数;
    另外,有些实体集中的属性,可能是冗余数据,需要进行适当的取舍。
    所谓冗余数据,是指在不同实体集中重复存在的,或在同一实体集中可以由其它属性值计算得到的数据。
    冗余数据一方面加大了工作量,浪费了存储空间,另一方面,又有可能造成数据的不一致性,破坏数据的完整性。
    但并不是所有的数据冗余都必须被消除,所有能合并的实体集都要被合并,有时,为了工作的方便或工效的提高,要保持适当的数据冗余,和合理的实体集分解。
     
     
    5.3 ER模型向关系模型的转化
     
    E-R模型是概念模型的表示。它是对现实世界客观事务及其联系的抽象,是用户对系统的应用需求的概念化表示,计算机不能直接处理它。
    要使计算机能够处理E-R模型中的信息。首先必须将它转化为具体的DBMS能处理的数据模型。
    E-R模型可以向现有的各种数据模型转换。而目前市场上DBMS大部分是基于关系数据模型的,所以我们只学习E-R模型向关系数据模型的转换方法。
    从E-R图中可以看出,E-R模型实际上是实体型及实体间联系所组成的有机整体,而前面我们也学过,关系模型的逻辑结构是一系列关系模式的集合。所以将E-R模型转化为关系模型,实质上就是将实体型和联系转化为关系模式。也就是如何用关系模式来表达实体型以及实体集之间的联系的问题。下面学习这种转化的步骤:
     
    第一步:将每一个实体型转换为一个关系模式
    将实体集的属性转换成关系的属性,实体集的码对应关系的码。实体集的名对应关系的名。例如职工管理系统全局E-R模型中的五个实体集可以表示如下:
    Ø         职工(职工号,姓名,性别,年龄)*
    Ø         部门(部门号,名称,电话,负责人)
    Ø         职称职务(代号,名称,津贴,住房面积)
    Ø         工资(工资号,补贴,保险,基本工资,实发工资)
    Ø         项目(项目号,名称,起始日期,鉴定日期)
     
    第二步:将每个联系转换为关系模式
    用关系表示联系,实质上是用关系的属性描述联系,那么该关系的属性从何而来呢?我们说,对于给定的联系R,由它所转换的关系具有以下属性:
    Ø         联系R单独的属性都转换为该关系的属性;
    Ø         联系R涉及到的每个实体集的码属性(集)转换为该关系的属性。
    如职工管理系统中的联系可以表示如下:
    Ø         分工(职工号,部门号)*           n:1联系
    Ø         任职(职工号,代号,任职日期)     n:m 联系
    Ø         拥有(职工号,工资号)*           1:1联系,职工号和工资号都可以作为主码
    Ø         参加(职工号,项目号,角色)       n:m联系
    根据联系的类型不同,联系转换为关系后,关系的码的确定也相应有不同的规则:
    Ø         若联系R为1:1联系,则每个相关实体的码均可作为关系的候选码;
    Ø         若联系R为1:n联系,则关系的码为n端实体的码;
    Ø         若联系R为n:m联系,则关系的码为相关实体的码的集合;
     
    第三步:根据具体情况,把具有相同码的多个关系模式合并成一个关系模式
    具有相同码的不同关系模式,从本质上说,它们描述的是同一实体的不同侧面(即属性),因此,它们可以合并。合并的过程也就是将对事物不同侧面的描述转化为对事物的全方位的描述。
    合并后关系包括两关系的所有属性,这样做可以简化系统,节省存储空间。上列关系中的职工关系、分工关系和拥有关系就可以合并为一:
    职工(职工号,姓名,性别,年龄,部门,工资号)
    现在我们不难看,当将联系R转换为关系模式时,只有当R为m:n联系时,才有必要建立新的关系模式;当R为1:1、1:n及is-a联系时,只需对与该联系有关的关系作相应的修改即可。
     
    5.4 历史上有影响的数据模型
     
    在关系数据模型产生之前,数据库管理系统普遍使用的数据模型是层次和网状数据模型,它们又被称为非关系数据模型.它们的数据结构和图的结构是相互对应的.
    在非关系模型中,概念模型中的实体型反映为记录型, 实体型的属性反映为记录的字段。因此,图的结点表示为记录型,结点之间的连线表示为记录型之间的联系。
    在非关系数据模型中,将两个记录型之间的一对一、一对多和多对多的联系,归结为一个只有1:n联系的基本层次联系,(因为1:1可以看作是1:n的特例,m:n可以分解为两个1:n的联系)。

    双亲结点
    子女结点
    1n的联系名
    Ri
    Rj
    Lij
    图中Ri位于联系Lij的始点,称为双亲结点(Parent),Rj位于联系Lij的终点,称为子女结点(Child)。

    双亲结点
    1、层次模型

    子女结点
    在现实世界中,许多事物都是按层次组织起来的,如一个家族、一所高校的组成都是典型的层次结构,为了描述这样的客观对象,层次数据模型也就应运而生。
    层次数据模型,满足下列两个基本条件:
    Ø         有且仅有一个结点无双亲,这个结点称为根结点;
    Ø         其它结点有且仅有一个双亲。(如P22图1.17)
    在层次模型中,同一双亲的子女结点称为“兄弟结点”,没有子女的结点称为“叶结点”。
    P92图5-18可以看出,层次模型象一棵倒立的树,所以层次模型也称为树状模型
    层次模型中的每一个结点表示一个记录型。结点之间的有向线表示记录型之间的联系,这种联系是父与子之间的一对多的联系。
    在层次模型的中,任何一个给定的记录值只有按其路径查看时,才能显出它的全部意义,没有一个子女记录值能够脱离双亲记录值而独立存在。
    层次模型对具有一对多的层次联系的部门描述得非常自然、直观,易于理解。
    历史上最典型层次模型,是1968年由IBM公司推出的数据库管理系统是IMS(Information Management System)。
     
    3、网状模型
    采用层次模型组织数据,使数据的查询变得很简便,无需设计特别的算法,因为查询路径是唯一的。它的这种简单性,一方面给数据的查询带来了好处。另一方面,又使它在描述具有复杂联系的客观事物时,显得力不从心。这使得它不得不重新考虑放宽对其结构中结点的两个限制条件。从而使它让位于网状数据模型,即网状数据模型符合下列两个条件:
    Ø         允许有一个以上的结点无双亲;
    Ø         允许一个结点可以有多于一个的双亲。
    从上述定义看出,层次模型中子女结点与双亲结点的联系是唯一的,而在网状模型中这种联系可以不唯一。因此,在网状模型中,要为每个联系命名,并指出与该联系有关的双亲记录和子女记录。(P93图5-20)
    网状数据模型中记录的概念,类似于关系数据模型中关系的概念。如:
    记录型→(对应)→关系模式,记录→(对应)→关系的元组,记录字段→(对应)→关系的属性
    网状数据库采用网状模型作为数据的组织方式。网状数据库的典型代表是CODASYL系统,这是20世纪70年代数据系统语言研究会CODASYL(Conference On Data Systems Language)下属的数据库任务组(DataBase Task Group, DBTG)提出的一个系统方案,所以又称为DBTG报告。
    DBTG报告虽然不是一个具体的数据库管理系统,但是它提出的基本概念、方法和技术具有普遍意义,后来很网状数据库管理系统都是采用DBTG报告所提出的模型设计的。
    网状模型取消了对层次模型结点的两个限制,从而构成了比层次结构更复杂的网状结构。尽管网状模型也不支持多对多联系,但由于一个多对多联系可以转化为两个一对多联系,所以网状模型可以间接地描述多对多联系。
    例如学生(S)与课程(C)是多对多的联系,一个学生可以选修多门课程,一门课程也可以供多个学生选读,这种联系用层次模型是很难描述的,如果在学生与课程之间建立一个中间实体:“学生-课程(SC)”,这就可以把原来的多对多联系转化为S与SC、C与SC这两个一对多联系,而这种情况正是典型的网状结构,(如P93图5-20)。
    网状数据模型的优点:
    ü         能够更为直接地描述现实世界,如一个结点可以有多个双亲。
    ü         具有良好的性能,存取效率较高。
    网状数据模型的缺点:
    ²        结构比较复杂,且随着应用环境的扩大,数据库的结构变得越来越复杂,不利于最终用户的掌握。
    ²        DDL,DML语言复杂,用户不易使用
    ²        由于记录之间的联系是通过存取路径实现的,应用程序在访问数据时必须选择适当的存取路径,因此,用户必须了解系统结构的细节,加重了编写应用程序的负担。
    层次数据库是数据库应用的先驱,而网状数据库则对数据库的概念、方法、技术进行了较全面的发展。所以对这两种数据模型的了解有助于今后对数据库技术的进一步学习和研究。
     
    5.5 数据模型与数据库系统的发展
     
    数据模型是数据库系统的核心和基础。按照计算机所支持的数据模型的发展历史,数据库系统的发展过程可分为以下三个阶段:
    一、第一代数据库系统
    层次数据库系统和网状数据库系统,统称为第一代数据库系统。支持它们的数据模型的数据结构可以用图来表示。层次模型对应于一棵有根的定向树,网状模型对应于平面有向图。它们被统称为格式化的数据模型
    层次和网状数据库系统有许多共同特征,如它们:
    1.         都支持数据库的三级模式结构;
    2.         都用存取路径来表示数据之间的联系;
    3.         用户对数据的存取,必须按照定义了的存取路径进行;
    4.         必须清楚地了解数据在数据库中的位置;
    5.         对数据的操作是一次一个记录地、导航式地进行;
    6.         程序和数据都具有较高的物理独立性,但逻辑独立性较低。
    以上六点特征,关键一点是用户和应用程序必须知道所操作的数据在数据库中的位置。而且必须用存取路径来指引系统完成你的指令。既要告诉系统你要干什么?还要指出怎么干?即要使用所谓的导航式的数据操纵语言。
    导航式的数据操纵语言的优点是对数据的存取效率高。缺点是要求用户或程序员必须掌握数据库的逻辑结构和物理结构。所以第一代数据库又被称为专家数据库,不利于数据库应用的推广和普及。
    二、第二代数据库系统
    关系模型数据库系统被称为第二代数据库系统。其特点是:
    1.         关系数据模型概念清晰、简单、易于用户理解和使用,而且具有关系代数这个严格理论做基础;
    2.         关系模型中,实体和实体间联系均用关系表示,数据结构单一,数据操作简化,克服了非关系模型中由于信息表示方式多样性带来的操作复杂性;
    3.         支持非过程化数据操作语言(如SQL),将用户从对数据库的导航式编程语言中解脱出来,大大降低了编程的难度。用户只要指出做什么,而无需指出怎么,因此无需了解数据库的存取路径,这不但减轻了用户的负担,也提高了数据的独立性。
    4.         非关系模型采用的是面向记录的操作方式,而关系模型采用的是面向关系即集合的操作,操作的对象和结果都是元组的集合。
    自从E.F.Codd于1970年首次提出了关系模型以后,关系数据库系统很快就在数据库领域中占据了相当重要的地位。微机型RDBMS的使用,已使数据库技术广泛应用于企业管理、情报检索、科学研究、管理信息系统等各个领域。
    三、第三代数据库系统
    随着数据库技术的发展,人们正试图将数据库技术应用到更深更广的领域,如计算机辅助设计/管理/集成制造(CAD/CAM/CIMS)、联机分析处理(OLAP)、办公自动化系统(OAS)、地理信息系统(GIS)/知识库系统、图像处理、模式识别、实时仿真等。变些应用有着与传统应用不同的行为特性数据特性。关系数据模型在这些应用中开始显露出许多缺陷,如:
    1.         不能存储和处理复杂对象。
    2.         支持的数据类型有限,不能存储和检索复杂的数据类型。
    3.         关系数据库语言(SQL)与程序设计语言之间差距较大,不能进行无缝连接。
    4.         关系模型对应用环境适应性差,缺乏灵活丰富的建模能力。
    为此,人们已开始提出并发展了许多新的数据模型。目前,关于数据模型的研究,主要沿着下列三个方向进行:
    1.         对传统的关系数据模型进行扩充,引入构造器,使之能表达复杂的数据类型,增强其建模能力。
    2.         抛弃关系数据模型,发展全新的语义数据模型。语义数据模型可表达复杂的结构和丰富的语义,具有全新的数据构造器和数据处理原语。代表模型有:语义数据模型(SDM)、E-R模型、函数数据模型(FDM)
    3.         结合语义数据模型和面向对象程序设计方法,提出了面向对象数据模型(OODM)。它是一种可扩充的数据模型,以对象为基础,支持面向对象的分析、设计和编程。(第九章详介)
    人们把支持新的数据模型的数据库系统,统称为第三代数据库系统。究竟谁能最终成为第三代数据库系统的基本模型,目前还处于诸侯纷起,群雄争霸的时期,但无论是基于哪一种数据模型,体系结构如何,应用在何种领域,第三代数据库系统都应具有以下三个基本特点:
    1.         必须保持或继承第二代数据库系统的技术
    2.         应支持数据管理、对象管理和知识管理
    3.         应该对其他系统开放
     
    本章我们主要学习了实体-联系模型(E-R模型)的建立、设计方法和步骤;并学习了E-R模型向关系模型的转化过程;还了解了历史上有影响的层次和网状数据模型的特点,最后介绍了数据模型和数据库系统发展的历史和前景。其中最关键的内容是E-R模型的设计和E-R模型向关系数据模型的转换,要求一定要掌握。
     
    展开全文
  • 我们常说,办事情要“名正言顺”,而数据领域的名字则是格外的多,商业分析、数据分析、数据挖掘、算法模型……经常把大家绕晕,今天系统科普一下。商业分析VS 数据分析广义上...
        

    我们常说,办事情要“名正言顺”,而数据领域的名字则是格外的多,商业分析、数据分析、数据挖掘、算法模型……经常把大家绕晕,今天系统科普一下。

     

    商业分析VS 数据分析

     

    广义上的数据分析,指的是“利用数据对XX问题进行分析”。包括了数据采集、数据存储、数据清洗、数据计算、结论输出、数据可视化等部分。大家注意到了,这里是有个空白的XX没有填的。实际上,广义上的数据分析是一个基础技能,可以利用到很多很多领域。空白处可以填学术、理论、科学、医疗、教育、情感、心理……等等名词。是滴,这个空白处也可以填“商业问题”。如果是:利用数据分析方法进行商业问题的分析,那就是商业分析了。商业分析是广义的数据分析方法的一个具体应用场景。

     

    狭义上的数据分析, 应该叫“对企业内部系统采集的数据进行分析”。实际上,我们在招聘时看到的要求懂sqlhivepythonR等软件操作的“数据分析岗位”,指的都是狭义的数据分析。这些分析工作基于企业网站、APP、订单、售后、客服、物流、财务系统记录的数据,进行计算、建模、报告等工作。

     

    内部数据质量不行,是个永恒的问题,也常常成为分析的死穴。不懂数据的人往往想当然的认为:数据不是很多吗,分析分析就好了呀。可真正做数据工作的都知道,急躁的业务领导、投机取巧的同事、薅羊毛的用户、落后的IT建设,都会让内部数据看似庞大,实则一塌糊涂。常见的内部数据的分类与问题,简单归纳如下,大家感受一下: 


    640?wx_fmt=png

     

    商业分析不仅仅利用企业内部系统数据,还需要大量利用外部数据。它由四个构成部分:行业研究、定性访谈、定量调研、内部数据分析。因为影响企业经营状况的因素,本身就包括了宏观环境、竞争对手、内部组织、员工能力、消费者态度与意愿等等方面。这些因素非常重要,但不一定都能通过系统采集到。因此就得靠多方面的信息采集来满足需求。具体每个部分的采集方式、用途,如下表所示:

     

    640?wx_fmt=png

       

    真正进行商业分析,需要有综合性技能和多方面获取数据的能力。很多企业拿着做内部数据分析的要求招商业分析师,结果招来的人只会跑数据,没有解决真实问题的能力。写代码的小哥每天对着销售曲线发呆,冥思苦想不得其解。其核心症结就在这里:本身商业分析就不是敲两行代码就能完事的。至少要有行业研究-市场调查-内部访谈-内部数据分析四部分相互配合,不是200行代码就能让阿尔法狗子开口说人话:贵公司的问题是XXXX200万行代码都不行。

     

    更何况,很多企业对数据的重视程度远远不够。

    • 有新政策出台也不知会;

    • 外部信息系统采集、共享机制不存在;

    • 内部做事情的背景、现状、目标啥都不交代;

    • 不给做分析的同学走访一线,了解实际的机会;

    • 遇到问题就知道甩给分析:“你建个模型分析分析”

    • 私下里搞小动作,做分析的同学甚至是最后一个知道企业发生什么事的人

    这就让做分析的同学们无米下锅了。就更难通过分析产出效益了。
     

    商业分析VS 算法模型

     

    Alpha Go所赐,现在人人都知道人工智能很厉害。阿尔法狗子一声汪汪,咬哭了柯洁,也让人们产生了无数对人工智能、算法模型的幻想。实际上算法模型最大、最成功、最多精力去做的内容,和数据分析没啥关系。算法模型目前比较成熟应用的领域,在于图像识别、语义识别、路线规划等方面,具体应用在安防、风控、物流、驾驶等领域,是基础的工业级应用。

     

    在商业领域算法的用处相当有限。因为本身企业经营靠的就不一定是精细的计算,政策大势、老板的资源、员工创新、创意、创造能力,这些都很难用数据量化。换句话说:如果给定围棋的规则让算法去学习,算法可以打败最一流的高手;但在商业领域不是下围棋,有可能明年下棋的规则都变成在围棋盘上摆车马炮……别说阿尔法狗了,阿尔法喷火大恐龙都搞不掂。

     

    因此,在商业领域算法往往应用在特定场景上。第一类常用的是直接针对用户场景的算法。具体场景往往有以下特点:个人决策、封闭信息、一对一沟通、用户决策容易被营销策略影响、数据指标多需要压缩、创意影响较少。比如常见的:风控。都是个人申请资料,金融机构审核。如果这个人信用不好,我们也没必要帮助他好,拒绝他就是了。设计信用的指标很多,单靠一两个指标很难判断,因此可以建模(最常用的是逻辑回归)来区分用户风险等级。类似的如推荐算法或者大数据杀熟,往往在APP里应用多,欺负的就是一对一的封闭场景沟通。如果真在实体店搞这一套,估计早就被客人告到工商局,或者干脆砸了招牌走人。

     

    第二类常用的是预测算法,包括基于时间序列和因果关系预测两类。商业分析很需要对未来发展趋势做预测,因此需要算法辅助。常见的用法、优缺点如下表所示

     

    640?wx_fmt=png

     

    第三类是用来降维的算法。包括因子-聚类分析、AHP、主成份分析等。往往是评估一个问题,考虑指标太多的时候,需要做降维处理,压缩指标方便评分。常用于评估类问题,比如项目、新产品、品牌评估等等。

     

    综上,可以看到算法模型在商业分析中是非常有用的,可它本身不能替代商业分析,更不是一个问题思考不清楚了,就甩给做分析的同学:“人工智能好厉害,快人工智能分析一下为什么我们业绩做不起来”。业绩是做出来的,不是算出来的。更多的商业问题是和人的主观能动性有关,因此脱离人的因素去指望算法,最后就沦为数字游戏。

     

    以上就是商业分析、数据分析、算法模型的关系与区别。用一句话概括,可以说是:商业分析是数据分析方法在商业问题的具体应用,算法模型是一个有效解决特定商业分析问题的工具。


    640?wx_fmt=other

    展开全文
  • 数据库基础:关系模型

    千次阅读 2017-09-25 23:46:39
    诸多数据模型中,关系模型是目前最重要的一种模型。下面来详述一下关系模型的数据结构。一、关系模型的数据结构关系模型与以往的模型不同,它是建立在严格的数学概念的基础上。没给个关系的数据结构是一张规范的二维...

    目前,数据库领域中最常用的数据模型有:
    - 层次模型
    - 网状模型
    - 关系模型
    - 面向对象模型
    - 对象关系模型
    其中层次模型与网状模型统称为格式化模型。

    诸多数据模型中,关系模型是目前最重要的一种模型。下面来详述一下关系模型的数据结构。

    一、关系模型的数据结构

    关系模型与以往的模型不同,它是建立在严格的数学概念的基础上。没给个关系的数据结构是一张规范的二维表。现在以学生登记表为例,介绍关系模型中的一些术语。

    • 关系:一个关系对应通常说的一张表。
    • 元组:表中的一行即为一个元组;
    • 属性表中的一个列即为一个属性,给每一个属性起一个名称即属性名。
    • 码:也成为码键。表中的某个属性组,他可以唯一确定一个元组。
    • 域:属性的取值范围
    • 分量:元组中的一个属性值;
    • 关系模式:对关系的描述一般表示为:关系名(属性1,属性2,属性3,…,属性n)
      在关系模式中,实体以及实体之间都是用关系表示的。例如,学生、课程、学生与课程之间的多对多联系在关系模型中可以如下表示:
      学生(学号,姓名,年龄,性别,系名,年级)
      课程(课程号,课程名,学分)
      选修(学号,课程号,成绩)
      关系模式要求关系必须是规范化的,即要求关系必须满足一定的规范条件,这些规范条件中最基本的一条就是,关系的每一个分量必须是一个不可分数据项,也就是说,不允许表中还有表。

    二、关系数据模型的操纵与完整性约束条件

    关系数据模型的操作主要包括查询、插入、删除和更新数据。这些操作必须满足关系的完整性性约束条件。关系的完整性约束条件包括:实体完整性,参照完整性和用户自定义完整性。
    

    三、关系数据模型的存储结构

    在关系模型数据库中,实体及实体间的联系都用表来表示。

    四、关系数据模型的优缺点

    关系数据模型具有以下优缺点:
    1. 关系模型与格式化模型不同它是建立在严格的数学概念基础上的。
    2. 关系模型的概念单一。
    3. 关系模型的存取路径对用户透明,从而具有更高的数据独立性、更好的安全保密性,也简化了程序员的工作和数据库开发建立的工作。

    展开全文
  • 数据模型概述

    千次阅读 2015-09-04 13:59:41
    模型,特别是具体模型,人们并不陌生。一张地图、航模、一组建筑设计沙盘。。。都是具体模型。一眼望去,就会使人联想到...数据模型也是一种模型,他是对现实世界数据特征的抽象,也就是说数据模型是用来描述数据、组
  • [GIS原理] 3 空间数据模型

    千次阅读 多人点赞 2018-11-22 20:31:05
    文章目录相关概念空间数据模型地理空间空间现象空间实体地理空间与空间抽象概念数据模型逻辑数据模型物理数据...关系空间数据逻辑模型矢量数据模型栅格数据模型矢量——栅格一体化数据模型镶嵌数据模型面向对象数据模型...
  • 但是对于大数据中数据仓库上构建数据模型的方法和传统的关系数据库的方法 是否还是可以使用。 世间万物不会孤立的存在,它们以各种关系进行联系;构建的数据模型如何体现这些关系。 从目前各大厂商(IBM,微软)的数据...
  • 证券期货行业数据模型设计

    千次阅读 2020-04-12 06:57:12
    证券期货行业数据模型(以下简称“SDOM”)是以证券期货行业相关法律法规、业务规则、制度及流程等为依据,提取市场全业务流程与数据共性,形成具有通用性、稳定性和扩展性的数据模型。 行业数据模型是以“交易”、...
  • 数据分析-PART2--10大数据分析模型

    万次阅读 多人点赞 2018-07-31 10:00:39
    数据分析-PART2--10大数据分析模型 数据分析-PART3--数据分析常用指标 数据分析-PART4--数据分析方法 数据分析-PART5--数据分析可视化 数据分析-PART6--数据分析能力培养 数据分析-PART 7--数据分析工具网站...
  • 数据库-数据模型(分类、三要素、概念)

    万次阅读 多人点赞 2015-08-28 15:43:47
    常用的数据模型是概念数据模型和结构数据模型:  ①概念数据模型(信息模型):面向用户的,按照用户的观点进行建模,典型代表:E-R图  ②结构数据模型:面向计算机系统的,用于DBMS的实现,典型代表有:层次...
  • 数据仓库模型设计与工具

    千次阅读 2020-04-01 10:09:57
    数据模型对于数仓是核心的东西,数据模型是数据组织和存储方法,模型的好坏,决定了数仓能支撑企业业务多久。 为什么大多数企业,数仓都要重建,这不仅仅是业务拓展、发展迅速,很大一部分是因为模型建的很烂。 ...
  • 业务模型;UML类图
  • 第4章关系系统及其优化   一、选择题 1.概念模型是现实世界的第一层抽象,这一类最...3.关系数据模型目前最重要的一种数据模型,它的三个要素分别为(B)。 A.实体完整、参照完整、用户自定义完整 B.数据结构、
  • 1、首先提一个问题,什么是模型模型这个词频繁出现在我们平时的工作中、生活中、新闻里,但什么是模型呢,不同的学科有不同的定义。在这里我不想列举学术上的定义,只谈一下我自己的理解:模型是为了模拟、演示、...
  • 关系模型中设计表时的约束条件

    千次阅读 2019-02-26 15:27:19
    关系模型是目前最重要的也是应用最广泛的数据模型。简而言之,关系就是一张二维表,由行和列组成。关系模型将数据模型组织成表格的形式,这种表格在数学上称为关系 设计表时,可对表中的一个字段或多个字段的组合...
  • 提到数据分析,肯定要提到数据分析模型,在进行数据分析之前,先搭建数据分析模型,根据模型中的内容,具体细分到不同的数据指标进行细化分析,最终得到想要的分析结果或结论。 一:数据分析模型 要进行一次完整的...
  • Stata: 空间面板数据模型及Stata实现

    万次阅读 多人点赞 2019-05-10 10:37:56
      作者:游万海 (福州大学) Stata 连享会: 知乎 | 简书 | 码云 | CSDN ...在 「 Stata: 面板数据模型-一文读懂」 文中,我们已对面板数据模型进行了介绍。 然而,当研究样本涉及到多个...
  • 数据挖掘算法&模型

    万次阅读 2016-06-13 15:59:45
    在行业设备大数据平台建设中,势必要用到大数据技术,而大数据技术中,机器学习与数据挖掘算法是重要的一环,我们通过这些算法与模型对设备的故障进行监控与预测,对设备技改需求进行预测,对设备采购需求进行预测...
  • 数据挖掘过程模型研究

    千次阅读 2014-12-06 22:39:15
    近几年,数据挖掘及大数据处理技术得到了空前的发展,这得益于数据量...CRISP-DM通过6个步骤,对企业数据挖掘过程进行了描述,目前是行业的事实标准。本文将对数据挖掘过程进行介绍,并针对CRISP-DM模型进行详细描述。
  • 数据仓库之模型设计

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

    万次阅读 2019-04-21 18:47:46
    1. 容量(Volume):数据量大,数据量的大小决定所考虑的数据的价值和潜在的信息; 2. 种类(Variety):数据类型多,包括但不仅限于文本,音频,视频以及图片; 3. 速度(Velocity):指数据产生和获取的速度快;...
  • 什么是有指导的数据挖掘方法模型,以及数据挖掘如何构建模型。在构建一个有指导的数据挖掘模型,首先要理解和定义一些模型试图估计的目标变量。 首先要定义模型的结构和目标。 二、增加响应建模。 三、考虑模型的...
  • 银行数据仓库体系实践(9)--主题模型

    千次阅读 多人点赞 2019-07-13 11:49:27
    在银行主题模型中,每个数据仓库的实施公司会有金融行业或银行业的主题模型,这个模型会根据新的业务不断进行完善,是各实施公司的业务经验积累。一个良好的模型数据仓库的实施起到了事半功倍的效果,虽然不同的...
  • TCP/IP 模型 与 OSI 七层模型的对应关系

    万次阅读 多人点赞 2018-08-27 20:39:29
    TCP/IP 模型与 OSI 七层模型 七层有底向上分别是:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。 简化后的四层分别是:主机到网络层(比特)、网络层(数据帧)、传输层(数据包)、应用层...
  • 如何建立和评估数据仓库逻辑模型

    千次阅读 2006-07-18 16:46:00
    从最终应用的功能和性能的角度来看,数据仓库的数据逻辑模型也许是整个项目最重要的方面,需要领域专家的参与。从内容上看,涉及的方面有确立主题域,粒度层次的划分,确定数据分割策略,关系模式的确定。 逻辑模型...
  • 分布式文件系统元数据服务模型

    万次阅读 多人点赞 2011-09-05 12:05:38
    随着非结构化数据的爆炸,分布式文件系统进入了发展的黄金时期,从高性能计算到数据中心,从数据共享到互联网应用,已经渗透到数据应用的各方各面。对于大多数分布式文件系统(或集群文件系统,或并行文件系统)而言,...
  • 一、数据模型 ZooKeeper的视图结构和标准的Unix文件系统非常类似,但没有引入传统文件系统中目录和文件等相关概念,而是使用了其特有的“数据节点”概念,我们称之为ZNode.ZNode是ZooKeeper中数据的最小单元,每个ZNode...
  • 机器学习和数据挖掘是紧密相关的,要进行数据挖掘需要掌握一些机器学习所用的方法和模型知识,通过模型的训练可以得到处理数据的最优的模型数据挖掘常用的模型如下: 3.1 监督学习模型 就是人们常说的分类,通过已...
  • 浅谈BI领域的数据模型设计(二)

    千次阅读 2017-04-20 01:34:20
    第三部分:银行业数据模型基本概念介绍 第四部分:银行业数据模型分主题介绍 第五部分:ODS和EDW /**********************************/ 第三部分:银行业数据模型基本概念介绍 1.什么是数据
  • [方法]本文通过对web影视作品评论数据建立评估模型,通过LDA和关系网络进行分析研究,并将结果与影视作品的网站评分做比较,从而得到较为准确的分析结果。[结果]对影视作品的评论数据进行文本挖掘分析,能够得到...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 196,222
精华内容 78,488
关键字:

关系数据模型是目前最重要的