精华内容
下载资源
问答
  • 基于问卷调查的数据,采用因子分析方法构建多维领导方式对于煤矿工人安全行为影响的RERACO模型,并将模型中指标的权重按照对煤矿工人安全行为的影响程度进行等级分类,再利用中介变量检验的方法对模型进行中介变量分析...
  • 星星模型&&雪花模型

    2020-05-14 10:42:12
    乖乖猪001 2018-12-22 21:55:58 437 已收藏 ...在多维分析的商业智能解决方案中,根据事实表和维度表的关系,可将常见的模型分为星型模型和雪花型模型。在设计逻辑数据的模型的时候,就应考虑数据是按照星型模型还...

     

    乖乖猪001 2018-12-22 21:55:58  437  已收藏 1
    分类专栏: 大数据
    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
    本文链接:https://blog.csdn.net/xiaozhaoshigedasb/article/details/85218499
    收起
    在多维分析的商业智能解决方案中,根据事实表和维度表的关系,可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候,就应考虑数据是按照星型模型还是雪花型模型进行组织。

    星型模型
    当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型。

    星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在time维度表中,存在2016年5月2日以及2016年5月3日两条记录,那么2016年和5月信息分别存储了两次,即存在冗余。

    雪花模型
    当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表,形成一些局部的" 层次" 区域,这些被分解的表都连接到主维度表而不是事实表。如图所示,将时间维表又分解为国家,省份,城市等维表。它的优点是:通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

    雪花模型和星星模型的区别:
    星型模型因为数据的冗余所以很多统计查询不需要做外部的连接,因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素,设计与实现都比较简单。雪花型模型由于去除了冗余,有些统计就需要通过表的联接才能产生,所以效率不一定有星型模型高。正规化也是一种比较复杂的过程,相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下,实际运用中星型模型使用更多,也更有效率。
    1)数据优化
    雪花模型使用的是规范化数据,也就是说数据在数据库内部是组织好的,以便消除冗余,因此它能够有效地减少数据量。通过引用完整性,其业务层级和维度都将存储在数据模型之中。

    2)业务模型
    主键是一个单独的唯一键(数据属性),为特殊数据所选择。在上面的例子中,Advertiser_ID就将是一个主键。外键(参考属性)仅仅是一个表中的字段,用来匹配其他维度表中的主键。在我们所引用的例子中,Advertiser_ID将是Account_dimension的一个外键。
    在雪花模型中,数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中,所有必要的维度表在事实表中都只拥有外键。
    3)性能
    第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多,因此性能方面会比较低。举个例子,如果你想要知道Advertiser 的详细信息,雪花模型就会请求许多信息,比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来,然后再与事实表连接。
    而星形模型的连接就少的多,在这个模型中,如果你需要上述信息,你只要将Advertiser的维度表和事实表连接即可。
    4)ETL
    雪花模型加载数据集市,因此ETL操作在设计上更加复杂,而且由于附属模型的限制,不能并行化。
    星形模型加载维度表,不需要再维度之间添加附属模型,因此ETL就相对简单,而且可以实现高度的并行化。


    ————————————————
    版权声明:本文为CSDN博主「乖乖猪001」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/xiaozhaoshigedasb/article/details/85218499

    展开全文
  • OLAP的分类

    千次阅读 2010-02-22 23:33:00
    根据多维数据模型存储方式不同,OLAP主要可以分为两类:基于多维数据库OLAP(MOLAP)和基于关系数据库的OLAP(ROLAP)。...多维数据库和关系型数据库的主要不同是存储数据的方式,关系型数据库在一系列表格和列中存储

    根据多维数据模型存储方式不同,OLAP主要可以分为两类:基于多维数据库OLAP(MOLAP)和基于关系数据库的OLAP(ROLAP)

    1 MOLAP

    MOLAP的核心是多维数据库。在多维数据存贮方式中,OLAP的服务设施包含OLAP软件和多维数据库,数据在逻辑上按数组存贮,一般可选用超立方体或多立方体。

    多维数据库和关系型数据库的主要不同是存储数据的方式,关系型数据库在一系列表格和列中存储数据。相反,多维数据库则在大量的多维数组中存储数据。多维数据库为终端用户提供一种可对数据进行灵活访问的信息结构,利用多维数据库可以对数据进行切片、切块、动态地观察汇总数据与细节数据的关系多维数据库中的数据是按应用中处理数据的方式来组织的,作为一种规则,应按概括或聚集形式存贮数据。这样多维数据库中信息粒度较大,因而索引较小,可以常驻内存,使查询效率大为提高。由于多维数据库以数据方式存贮,数组中值的修改可以不影响索引,这样能很好地适应读写应用。

    用户可以通过客户端的应用软件界面向服务器提交分析请求,由OLAP服务器检索多维数据库,最后将结果返回给用户。由于得益于独特的多维数据库结构及很高程度的数据预处理能力,因此基于MOLAP技术可以迅速地响应决策分析人员的分析请求,并快速地将分析结果返回给用户。但对一些新需求还需要重建多维数据库,因此限制了MOLAP 结构的灵活性。由于对数据预处理程度高,因此需要极大的数据容量,而且数据的维护量也很大。另外由于数据需下载到特定的多维数据库中,因此安全性相对较差。

    2 ROLAP

    ROLAP是基于关系型数据库技术的OLAP技术。在使用这种技术时,关系型数据库将多维数据库中的多维结构划分为两类,一类是事先用存储事实的度量值及各个维的码值;另一类是维表,对每个维来说,至少有以个表用来保存该维的元数据,即维的描述信息,包括维的层次及成员类别等。事实表是通过每一个维的值和维表联系在一起的,这种结构有时被称为“星型模式”。如果用多个表来描述一个复杂维。这样在“星”的角上又出现了分支,这种变形的“星型模式”被称为“雪花模式”。基于关系型数据库的OLAP的优势是技术成熟,有现成的产品可以借鉴开发过程快,风险小。其缺点是速度不如基于多维数据库的OLAP快。

    而其相对与MOLAP一个比较明显的优点是适应性较好,主要表现在:由于MOLAP的预综合程度很高,对多维模型的扩充会使数据立方体的规模迅速增长,而且还关系到采用何种数据聚集方式的问题。而ROLAP的预综合程度比较灵活,可以根据用户需要进行,增加一维意味着增加一些维表与用户相关的综合表,还有事实表中的相应内容;同时由于MOLAP的预综合度高,当数据频繁变化时,需要重新进行很多计算,而ROLAP的预综合度比较灵活可以较好的适应数据变化;再一点,ROLAP的基础关系型数据库已经发展了20多年,技术上比较成熟,在适应大数据量和不同运行环境的能力都比较好。

    展开全文
  • 数据库分类和典型产品关系型数据库的数据模型键值对数据库的数据模型文档数据库的数据模型文档与关系“关系”“文档”比较并发性灵活性优缺点总结图数据库的数据模型列数据库的数据模型BigTable多维稀疏分布式如何...

    总述:数据库分类和典型产品

    • 关系型数据库
      • 关键词:SQL(结构化查询语言)、RDB(关系型数据库)
      • 典型产品:MySQL、Oracle、SQL Server
    • 非关系型数据库
      • 关键词:NoSQL(Not only SQL)
      • 典型产品:
        • 键值对数据库:Memcached(临时性键值存储)、Redis(临时+永久键值存储)
        • 文档数据库:MongoDB、CouchDB
        • 图数据库:Neo4J、InfoGrid
        • 列数据库:Cassandra、HBase

    关系型数据库的数据模型

    建立在关系模型基础上的数据库,借助于集合代数等数学概念和方法来处理数据库中的数据。

    键值对数据库的数据模型

    • Key指向Value的键值对,通常用HashTable来实现
    • 键值对数据库中的Value值是纯非结构数据,一般作为字符串或者二进制处理
    • 就是一个多功能的大字符串数组

    文档数据库的数据模型

    • Key指向(Attribute,Value)的键值对
    • 和键值对数据库不同,文档数据库中的Value值是结构化数据
    • 文档数据模型和关系型数据库的数据模型类比关系如下(以MySQL和MongoDB为例):
    关系型数据库 文档数据库
    database database
    table collection(集合)
    row(行) document(文档)

    文档与关系

    “关系”

    如上所示,关系型数据库中的每一条记录存储都需要遵守一个固定的模式(固定的列数/属性数),每一列有特定的意义而且规定了数据类型。如果要获取不同的数据,数据库的模式就需要重新修改。

    此外,关系型模型还有一个特点就是“数据库标准化”。按照关系型数据的NF法则,在关系型数据库结构时,会将大的表(多个列/属性)压缩成小的、整合的表(把重复的属性值拎出来单独一张表),然后互相之间以“外键”连接,就像下图所展示的一样。这种“外键”就是关系型数据库中的“关系”的体现

    “文档”

    使用“文档”这个词似乎让人觉得奇怪,但是其实 “文档型数据模型”真的和传统意义的文字“文档”没有什么关系。他不是书、信或者文章,这里说的“文档”其实是一个数据记录,这个记录能够对包含的数据类型和内容进行“自我描述”。XML文档、HTML文档和JSON 文档就属于这一类。例如,上面的四条错误信息记录在JSON文档数据库中可能会是像下面这样:

    • 记录1
    {
        "_id": 1,
        "Err": "ERR",
        "Time": "00:08",
        "DC":{
            "id": 1,
            "Loc": "北京",
            "Num": "010",
            "Street": "长安街"
        },
        "level": 0
    }
    
    • 记录2
    {
        "_id": 1,
        "Err": "ERR",
        "Time": "02:06",
        "DC":{
            "id": 2,
            "Loc": "上海",
            "Num": "021",
            "Range": "闵行区"
        },
        "Note": null
    }
    

    比较

    从上面的对比中也可以很容易的看出,这种文档型的记录方式所记录的数据是不规则的,很容易出现冗余信息,而关系型数据库则不会,比如上面的记录中,“DC”信息在关系型数据库中只会存储一次,由其他的表通过“外键”建立指向性的“关系”,使得一条数据被多条记录共享,极大地减少了重复数据的出现;并且当“DC”的某些信息发生改变时也完全不需要对其他数据进行进一步的修改。这也是关系型数据模型的“一致性”所带来的好处。

    但是,这种“一致性”的缺陷在于,复杂的共享数据内部关系网的存在,使得关系型数据在多个服务器之间的传递变得复杂而缓慢,同时让读和写操作的性能变差,不利于分布式系统的构建。

    而文档数据库则可以很好地解决这个问题。从上面文档数据库存储的方式可以看出,文档数据的每一条记录包含了所记录的抽象个体的全部信息,没有任何外部的引用,这条记录就是“自包含”的。这就使得记录很容易完全移动到其他服务器,因为这条记录的所有信息都包含在里面了,不需要考虑还有信息在别的表没有一起迁移走。

    有利于分布式部署是文档型数据库最有力的优势。除此之外,用不规则的结构化文档存储数据的优势还有以下两点:

    并发性

    并发性的原理和分布式相同,都是源自文档数据库的“自包含”特性。关系型数据库中,为了保证数据的一致性,一张表一次只能由一个线程进行修改,当并发量大的时候显然很低效。而文档数据库因为“自包含”,所以可以由多个线程同时修改不同的文档,因此可以并发操作。

    灵活性

    面对大量而多样性的数据,如果使用关系型模型,就需要不断修改数据操作模式,这样,可能会引起系统负载的大大提升,同时也会大大增加处理的时间。这一点在社交网站应用中尤其明显:有人会发布风景照片、有人发布对时事的评论还有人分享音乐表达心情,不同的数据有不同的关系,不利于在关系数据库中处理。

    优缺点总结

    - 优点 缺点
    文档数据库 没有数据间的依赖关系,有利于分布和并发 数据之间没有一致性
    关系数据库 数据之间有一致性,不容易出错且节约存储空间 数据间严格而复杂的关系不利于分布式部署

    图数据库的数据模型

    图数据库是关系型数据库在“外键”连接方面进行特化后的一种数据库。相对于关系数据库来说,图数据库善于处理大量复杂互连接且低结构化的数据,这些数据变化迅速,需要频繁的查询——在关系数据库中,这些查询会导致大量的表连接,因此会产生性能上的问题。图数据库重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。

    列数据库的数据模型

    BigTable

    教程参考

    列数据库模型最初来源于Google提出的Bigtable。Bigtable看起来像一个关系型数据库,采用了很多数据库的实现策略。但是Bigtable并不支持完整的关系型数据模型;而是为客户端提供了一种简单的数据模型,客户端可以动态地控制数据的布局和格式,并且利用底层数据存储的局部性特征。本质上说,Bigtable是一个键值(key-value)映射。

    按作者的说法,Bigtable是一个稀疏的,分布式的,持久化的,多维排序映射

    多维

    Bigtable的键有三维:(row:string, column:string, time:int64)->string

    • row:行键(row key):
      • 行键可以是任意字节串,通常有10-100字节。
      • 行的读写都是原子性的。
      • Bigtable按照行键的字典序存储数据
      • Bigtable的表会根据行键自动划分为片(tablet),片是负载均衡的单元。最初表都只有一个片,但随着表不断增大,片会自动分裂,片的大小控制在100-200MB。
      • 行是表的第一级索引,我们可以把该行的列、时间和值看成一个整体,简化为一维键值映射
    • column:列键(column key):
      • 列是第二级索引,每行拥有的列是不受限制的,可以随时增加减少
      • 为了方便管理,列被分为多个列族(column family,是访问控制的单元),一个列族里的列一般存储相同类型的数据
        • 一行的列族很少变化,但是列族里的列可以随意添加删除。列键是按照[列族名]:[列名]格式命名的。
        • 访问控制以及磁盘和内存审计是在列家族层面上进行的。这些控制允许我们管理几种不同类型的应用,可以让应用只被允许浏览某些列,无法浏览全部列家族。
    • time:时间戳(timestamp):
      • 时间戳是第三级索引。
      • Bigtable允许保存数据的多个版本,版本区分的依据就是时间戳。
      • 时间戳可以由Bigtable赋值,代表数据进入Bigtable的准确时间,也可以由客户端赋值。
      • 数据的不同版本按照时间戳降序存储,因此先读到的是最新版本的数据。
      • 用户可以设定只保存单元格中数据的最近n个版本,或者只保存足够新版本(比如只保存最近7天内的数据版本)。

    BigTable的一行可以以如下所示的方式存储(以JSON为例):

    table{
      "aaaaa" : {//行键
        "A:foo" : {//列键,A族foo键
            15 : "y", //时间戳
            4 : "m"  
          },  
        "A:bar" : {//一列,A族bar列
            15 : "d",//一个版本
          },  
        "B:" : {//一列,空列族
            6 : "w"  
            3 : "o"  
            1 : "w"  
          }  
      },  
      // ...  
    }  
    

    例如GFS原论文中给出的“Webtable”示例:

    在“Webtable”中:

    • 行键是倒序的URL,表示一个网页(倒序是为了让同一域名下的不同子域存储在一个地方)
    • 列键分两个族:
      • contents族:该族中没有键,其中直接存储了网页内容及历史版本
      • anchor:[网址]键:archor族中的键代表那些引用了该行对应网页的页面

    稀疏

    “稀疏”是指表中每一列的值的存储格式都可以有很大不同。

    分布式

    Bigtable依赖于google的几项重要的分布式技术:

    • GFS(Google File System):分布式的文件系统,是BigTable用来存储日志和数据文件的文件系统
    • SSTable(Sorted String Table):不可修改的有序的键值映射,提供了查询、遍历等功能,是BigTable存储数据的格式
    • Chubby:一种高可用的分布式锁服务,在BigTable中于片定位、片服务器的状态监控、访问控制列表存储等任务

    正如上文所说,Bigtable会将表(table)进行分片,片(tablet)的大小维持在100-200MB范围,一旦超出范围就将分裂成更小的片,或者合并成更大的片。每个片服务器负责一定量的片,处理对其片的读写请求,以及片的分裂或合并。片服务器可以根据负载随时添加和删除。

    按照这种结构,Bigtable集群包括三个主要部分:

    • 一个供客户端使用的库:负责用户与集群的通信
    • 一个主服务器(master server):负责将片分配给片服务器,监控片服务器的添加和删除,平衡片服务器的负载,处理表和列族的创建等。
      • 注意,主服务器是用来管理片服务器的,不存储任何片,不提供任何数据服务,也不提供片的定位信息。客户端的读写操作是通过分布式算法直接在片服务器上进行的
    • 许多片服务器(tablet server):这里片服务器并不真实存储数据,而相当于一个连接Bigtable和GFS的代理,客户端的一些数据操作都通过片服务器代理间接访问GFS,就好像数据都存储在片服务器上。

    客户端需要读写数据时,直接与片服务器联系。因为客户端并不需要从主服务器获取片的位置信息,所以客户端的读写操作并不需要访问主服务器,主服务器的负载一般很轻。

    如何查询(片的定位)

    展开全文
  • 【总结】数据库原理

    千次阅读 2018-12-24 13:28:33
    文章目录数据库通用概念数据库的产生理论分类关系数据库非关系数据库规模分类内存文档服务应用场景事务OLTP分析OLAP建模思路范式建模(雪花型模型)维度建模(星型模型)大数据分析数据迁移ETL数据仓库DW...

    (本文只是自己的学习总结,不一定正确,仅供参考)

    文章目录

    数据库通用概念

    数据库的产生

    人类最开始持久化存储数据:文字、书籍、图书档案馆

    信息科技兴起后数字化存储:数字文档、数字多媒体、树型文件管理

    数据库:特点——持久化存储、优化读写、保证数据的有效性

    理论分类

    关系数据库

    传统数据库,按照关系理论建立二维表格。

    非关系数据库

    没有关系或者是树数据结构的字典关系,表内部记录之间没有联系。

    规模分类

    内存型

    只加载到内存的微型数据库。

    文档型

    单个数据库就是单个文件,单用户、简洁。

    服务型

    大规模数据库系统,一般开机启动作为服务,多用户、占用端口、复杂。

    应用场景

    https://img-my.csdn.net/uploads/201212/08/1354896501_9646.jpg

    事务型OLTP

    联机事务处理OLTP(on-line transaction processing)

    OLTP
    系统强调数据库内存效率,强调内存各种指标的命令率,强调绑定变量,强调并发操作。

    用于日常事务处理,要求速度快、实时性高,逻辑明确、准确性好,记录最原始、最精确的信息。

    性能瓶颈在CPU。

    分析型OLAP

    联机分析处理OLAP(On-Line Analytical Processing)

    OLAP 系统则强调数据分析,强调SQL执行时长,强调磁盘I/O,强调分区等。

    用于统计性的决策分析,要求海量数据,可按照维度分析,可读性,可扩展性,一般也要求准实时性。

    性能瓶颈在IO和内存。

    建模思路

    范式建模(雪花型模型)

    传统数据库建模方法,严格按照三范式规范化建模。

    维度建模(星型模型)

    事实表-维度表。

    不严格按照三范式,存在数据冗余,但可读性好,查询效率高。

    大数据分析

    数据迁移ETL

    抽取-转换-加载,一般是指将已有的传统数据库数据加载到数据仓库的过程。

    数据仓库DW

    对海量历史数据进行汇总,适用于大数据分析的数据仓库。

    多维数据

    分析模型:数据立方体Cube;将数据构造成按照多维表,而不是关系数据库里的二维表。

    维、维的粒度(层次)、度量、钻取、切片、旋转等概念。

    数据分析

    传统数据库也有数据分析,但比较受限。

    大数据时代,可对专门适用于大数据分析的数据仓库进行数据分析。此过程也叫商业智能BI。

    关系数据库(RDBMS)

    基本概念

    ACID规则

    A-原子性

    原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。

    比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

    C-一致性

    一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

    例如现有完整性约束a+b=10,如果一个事务改变了a,那么必须得改变b,使得事务结束后依然满足a+b=10,否则事务失败。

    I-独立性

    所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。

    比如现在有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的。

    D-持久性

    持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。

    E-R模型

    关系数据库基于E-R模型设计,即实体-关系模型(Entity-Relationship),实体即数据对象(每一个表的每一条记录都是一个实体,每条记录的不同的列是这个实体的各种属性),关系即数据对象之间的关系。

    SQL语言

    关系数据库使用SQL语言进行操作,不同品牌的数据库SQL语言略有差别,但大体一致。

    关系数据库的分类

    内存型关系数据库,无文件,直接保存在内存中,供程序直接修改与使用,临时性保存。(典型如redis,但它是非关系数据库)

    文档型关系数据库,典型例子sqlite,对数据库文件直接操作,常用于移动设备或单用户简单场景。

    服务型关系数据库,大多数数据库是这种类型,在系统中添加服务,程序需访问服务端口间接访问对应的数据库文件,支持多用户、复杂操作、复杂存储,但使用起来也复杂,占用资源也多。

    数据库设计范式

    (设计范式的资料中讲人话的不多,本该容易理解的地方被别人绕晕了)

    第一范式1NF:列不可再分(确保每列保持原子性)

    反例:学生信息表,学生班级列存储(商学院,13级,2班)

    应改为:把学生班级列拆分为学院、年级、班级三列

    第二范式2NF:消除部分依赖(确保每列都和主键列完全相关,而不是部分相关)

    (注:主要指联合主键的情况)

    反例:订单信息表,订单号与商品编号作为联合主键,商品名称、商品价格等只依赖于联合主键中的商品编号,而不依赖于订单号,存在部分依赖

    应改为:拆分为两张表,订单表只存储订单相关,商品编号列作为外键;商品表只存储商品相关

    第三范式3NF:消除传递依赖(确保每列都和主键列直接相关,而不是间接相关)

    反例:用户表,在一张表中存储身份证号、用户ID、用户等级,用户等级依赖于用户ID,用户ID又依赖于身份证号,存在传递依赖

    应改为:拆分为两张表,一张存储身份证号和用户ID,身份证号为主键;另一张表引用外键用户ID,存储用户等级

    实体间映射关系

    1对1

    任意一方存储外键都可

    1对n

    n侧表存储外键

    m对n

    额外设计一张关系表,存储双方的关系

    数据库建模步骤

    概念数据模型CDM

    即设计E-R模型。把现实问题抽象,形成数据库的初步设计概念。

    逻辑数据模型LDM

    进一步确定存储逻辑,遵循设计范式,确定数据表、数据列、主键、外键约束,特别是外键。要根据实体间映射关系的三种分类确定不同的设计思路,m对n的情况要特别建立关系表。

    物理数据模型PDM

    物理模型就是根据逻辑模型对应到具体的数据模型的机器实现。物理模型是对真实数据库的描述。如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。

    物理模型会适配到具体的系统、数据库软件,可生成直接能够使用的SQL建表语句,形成最终的存储模型。

    内容

    数据库database(单独一个数据库文件,一般会伴随生成日志文件,数据库是数据存储最基本的独立单元)

    数据表table(数据表之间可形成外键关系,各表之间一般不独立)

    临时表

    进行数据库操作需要用到临时表时,可通过某些关键字新建临时表,关闭数据库连接后会自动销毁,不会对原数据库产生影响

    记录item(数据表中的行(row),每一行是一条记录/实体)

    字段column(数据表中的列,每一列是一种属性/一个字段)

    索引index(通过对表中的某些列进行排序,提高查询速度,建立主键会自动建立关于主键的索引)

    视图view(从表中查询得到的虚拟表,简化查询,保护私有数据,在SQL语句的执行过程中也会形成临时的视图表)

    约束constraint(完整性约束,限制条件)

    约束是用来确保数据的准确性和一致性。常见的约束就是主键、外键、非空等。

    实体完整性:主键。

    域完整性:数据列的类型、长度、是否允许空。

    参照完整性:外键与主表的主键的数据应当一致。

    用户定义完整性:用户自定义的约束。

    primary key(主键)约束

    被约束的列或一组列作为主键,唯一且不能为空

    【难点】foreign key(外键)约束

    foreign
    key约束指定某一个列或一组列作为外部键,其中包含外键的表称为子表(从表),外键所引用的主键的表称为父表(主表),外键名称规范:fk_从表名_主表名。

    定义语句:

    CONSTRAINT E_SAL FOREIGN KEY(emp_id,account) REFERENCES EmployeeInfo
    (emp_id,account))

    在E_SAL表中定义外键,引用EmployeeInfo中的主键。E_SAL为子表,EmployeeInfo为主表。外键的命名为
    fk_外键所在的表名_外键引用的表名。因为外键所在的表为从表,所以上式可以写为
    fk_从表名_主表名。在维度模型中,维度表是主表,事实表为从表。

    更新、删除操作规则:

    在删除或更新有primary key值的行,且该值与子表的foreign
    key中一个或多个值相匹配时,会引起匹配完整性的丧失。

    在foreign key创建语法中,提供了可选的on update和on
    delete子句,可用此保持引用完整性。

    on update / on delete

    no action|cascade|restrict|set null|set default

    no
    action:更新或删除父表中的数据时,如果会使子表中的外键违反引用完整性,该动作将被禁止执行。不过在某些条件下,可出现暂时的,但在数据的最终状态中,不能违反外键的引用完整性。

    cascade:
    当父表中被引用列的数据被更新或删除时,子表中的相应的数据也被更新或删除。

    restrict:与no
    action规则基本相同,只是引用列中的数据永远不能违反外键的引用完整性,暂时的也不行。

    set
    null:当父表数据被更新或删除时,子表中的相应数据被设置成Null值,前提是子表中的相应列允许null值。

    set
    default:当父表数据被更新或删除时,子表中的数据被设置成默认值。前提是子表中的相应列设置有默认值。

    not null(非空)约束

    被约束的列列值不能为空

    unique(惟一)约束

    被约束的列列值不能重复,可允许为空,但只能有一个空值

    default (默认)约束

    给列设置默认值

    check(校验)约束

    用来检查字段值所允许的范围。DBMS每当执行delete,insert或update语句时,都对这个约束过滤。如果为true,则执行。否则,取消执行并提示错误。

    锁lock

    锁用来限制并发情况下的写操作(增删改),防止产生冲突。此处的锁都是悲观锁,设计人员在数据表中定义的时间戳等标识字段是乐观锁。

    按层次分

    库级锁

    数据库加锁(超级管理员级别)

    表级锁

    每个表都有单独的锁(普通管理员级别)

    行级锁

    每个数据行都有单独的锁(用户级别)

    按类型分

    共享锁

    多个用户均可加锁,加锁后只能读不能写

    排他锁

    禁止任何人给表加锁,更不能做写操作

    触发器trigger(特定事件触发特定操作)

    事务transaction(数据库的增删改操作流程)

    存储过程procedure(对数据进行操作的函数)

    数据类型

    字符型

    char(长度)——定长非unicode

    varchar(一般长度)——变长非unicode,变长能高效利用存储空间

    nvarchar(一般长度)——变长unicode,unicode对汉字支持比较好

    [n]varchar(MAX)——存储大容量字符串

    数字型

    bit——0和1

    int(长度)——整形

    decimal(整体长度,小数长度)——浮点数

    日期时间型

    datetime(date/time)——存放日期时间

    timestamp——实时时间戳

    其他类型

    二进制型——存储图片等二进制内容

    特性

    网络接口一般为TCP协议,IP地址或网址+端口号

    服务型数据库的数据库文件一般存放在它自己的目录

    大小写不敏感

    自然语言脚本式SQL

    与关键词重名可用中括号[]括起来区分

    SQL中的字符串用引号‘’括起来

    存储特殊字符需加反斜杠\转义

    常用关系数据库

    对比:

     

    sqlite

    mysql

    sqlserver

    oracle

    postgresql

    greenplum

    性能与适用范围

    小数据量,测试demo环境,应用内自维护数据库,移动APP

    互联网,关系简单,中等数据量,简单操作性能高

    windows平台服务,操作简单,中等数据量

    大数据量,大企业平台,复杂关系,高可靠性

    适合关系特别复杂的应用,大数据量

    适合关系特别复杂的应用,大数据量

    开放性

    完全开源

    商业开源

    仅限于windows

    商业

    完全开源

    完全开源

    数据库特性

    最简单的数据库引擎,单库单文件,内置SQL也有很多删减,没有服务和用户系统

    简单开源

    简单易用

    传统关系数据库的最高水平,大型企业级

    学院派,设计理念先进合理,支持标准SQL,支持json等非关系数据类型

    基于postgresql,适合构建集群支持大数据

    字符串边界

    单引号

    单引号

    单引号

    单引号

    单引号

    单引号

    多表联查

    只支持左外连接

    所有连接

    所有连接

    所有连接

    所有连接

    所有连接

    数据类型

    数据类型只与数据本身有关,与容器列无关,可选设置列的首选数据类型

    数值、字符串、日期时间等标准化格式,同一列只能存储同类数据

    数值、字符串、日期时间等标准化格式,同一列只能存储同类数据

    数值、字符串、日期时间等标准化格式,同一列只能存储同类数据

    支持json等非结构数据类型

    支持json等非结构数据类型

    Sqlite(文档型)

    数据类型较为独特,数据类型只与数据本身有关,与容器列无关,可选设置列的首选数据类型:

    数据的存储类——

    列的首选数据类型——

    Mysql(开源灵活)

    Sqlserver(微软系)

    Postgresql(学院派)

    Oracle(大型商用)

    Greenplum(大数据)

    数据库的使用和运维

    数据库安装运行

    Linux命令行安装,windows图形界面安装可选组件,默认添加到服务。

    数据库的管理员和用户

    首次运行进入管理程序设置管理员账户的密码。

    添加其他用户,只需像操作一般数据一样往系统自带的user数据表中添加用户项。

    数据库SQL交互程序一般开放一些元数据供管理员查看。

    数据库的备份和导入导出

    备份/复制表结构

    导出建表语句,直接在另一处执行,即可达到复制效果。

    备份/复制表数据

    由于数据过大,不能采用导出包含数据的建表语句的方法。

    先在另一处构建好表结构。导出数据,到另一处导入数据。

    数据库连接

    连接字符串

    服务主机(IP地址)、端口、数据库、用户名、密码;其他参数(连接池、字符编码等)

    连接池

    数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是重新建立一个。提高执行效率。

    在数据库连接的时候会有设置连接池的选项。

    编程语言接口

    编程语言中把数据库的连接封装为某个编程对象,然后开放为对外的接口。于是数据库的连接除了通过数据库客户端直连,还可以通过接口连接。

    例:jdbc/odbc

    数据库安全

    防SQL注入

    对用户输入进行白名单校验

    不要动态拼接SQL语句

    数据库连接必须限制权限

    机密信息如密码必须加密存储

    捕获所有异常信息不能暴露给用户

    对用户输入SQL进行转码过滤特殊字符

    终极策略:改用ORM模型

    数据库性能

    SQL优化

    并发优化

    展开全文
  • 2. 数据存储和查询,存储模型应包括关系型模型,非关系型模型,文档模型等。 3. 数据计算,包括离线批处理,实时计算,机器学习,多维分析和全文检索。 4. 平台安全与管理,解决用户管理,数据隔离,访问授权,...
  • ├─14、课程:基于RDS的维度数据模型.3、星型模式与OLAP多维数据库.mp4 ├─14、课程:基于RDS的维度数据模型.4、如何设计维度模型.mp4 ├─14、课程:基于RDS的维度数据模型.5、选择业务过程.mp4 ├─14、课程:...
  • MS医院BI解决方案Doc.pdf

    热门讨论 2012-11-01 09:30:40
    直接基于HIS关系型数据库上的统计分析缺点是无法实现对整个企 业集成信息进行报表和图表制作,获得全面的信息。并且由于数据没有经过处理,而是使用原始的业务记录进行计算,大大降低了运算的效率。 解决方案基于...
  • 利用了贝叶斯网络的DAG有向无环图,允许各个事件保留一定的依赖关系,网络结构中的每个节点代表一种属性,边代表相应的条件概率值,通过计算从而能得到精准的分类效果。详细介绍链接 TAN 树型朴素贝叶斯算法。此...
  • 第二部分面向Analysis Services开发人员,详细介绍了如何使用BIDS以及BIDS的所有功能,提供了使用SSAS构建OLAP多维数据集和数据挖掘模型的指南;第三部分面向Integration Services开发人员,详细介绍如何使用SSIS...
  • 第二部分面向Analysis Services开发人员,详细介绍了如何使用BIDS以及BIDS的所有功能,提供了使用SSAS构建OLAP多维数据集和数据挖掘模型的指南;第三部分面向Integration Services开发人员,详细介绍如何使用SSIS...
  • 第二部分面向Analysis Services开发人员,详细介绍了如何使用BIDS以及BIDS的所有功能,提供了使用SSAS构建OLAP多维数据集和数据挖掘模型的指南;第三部分面向Integration Services开发人员,详细介绍如何使用SSIS...
  • 第二部分面向Analysis Services开发人员,详细介绍了如何使用BIDS以及BIDS的所有功能,提供了使用SSAS构建OLAP多维数据集和数据挖掘模型的指南;第三部分面向Integration Services开发人员,详细介绍如何使用SSIS...
  • 第二部分面向Analysis Services开发人员,详细介绍了如何使用BIDS以及BIDS的所有功能,提供了使用SSAS构建OLAP多维数据集和数据挖掘模型的指南;第三部分面向Integration Services开发人员,详细介绍如何使用SSIS...
  • 数据挖掘论文合集-242篇(part1)

    千次下载 热门讨论 2009-01-13 14:03:31
    基于约束的多维数据挖掘技术.caj 基于遗传算法和受控随机搜索的系统优化策略.pdf 基于高校人事信息库的数据挖掘研究.caj 多媒体数据挖掘的相关媒体特征库方法.caj 多段支持度数据挖掘算法研究.caj 工业控制计算机的...
  • 数据挖掘论文合集-242篇(part2)

    千次下载 热门讨论 2009-01-13 14:06:31
    基于约束的多维数据挖掘技术.caj 基于遗传算法和受控随机搜索的系统优化策略.pdf 基于高校人事信息库的数据挖掘研究.caj 多媒体数据挖掘的相关媒体特征库方法.caj 多段支持度数据挖掘算法研究.caj 工业控制计算机的...
  • 数据挖掘论文合集-242篇(part3)

    热门讨论 2009-01-13 14:08:51
    基于约束的多维数据挖掘技术.caj 基于遗传算法和受控随机搜索的系统优化策略.pdf 基于高校人事信息库的数据挖掘研究.caj 多媒体数据挖掘的相关媒体特征库方法.caj 多段支持度数据挖掘算法研究.caj 工业控制计算机的...
  • 数据挖掘在各行业的应用论文

    热门讨论 2010-04-19 09:40:57
    基于约束的多维数据挖掘技术.caj 在IDS中利用数据挖掘技术提取用户行为特征.caj 数据挖掘与数据库知识发现.caj 数据挖掘技术在农业数据中的有效应用.kdh 面向数据挖掘的时间序列符号化方法研究.kdh Internet数据...
  • corejava培训文档

    2010-08-25 21:06:12
    10. 九 AWT(Abstract Window Toolkit) 事件模型 11. 十 The AWT Component Library 12. 十一 JFC(Java Foundation Classes) 13. 十二 Applets 14. 十三 线程Thread 14.1. 线程原理 14.2. 线程实现的两种形式...
  • 为什么不用线性回归的代价函数表示,因为线性回归的代价函数可能是非凸的,对于分类问题,使用梯度下降很难得到最小值,上面的代价函数是凸函数 的图像如下,即y=1时: 可以看出,当趋于1,y=1,与预测值一致,...
  • <br>目录: <br>第1章 项目的困境 <br> 1.1 目标 1.2 项目的困境 1.2.1 迭代和增量的软件开发 1.2.2 基于风险的开发 1.2.3 迭代软件过程模型 1.2.4 将迭代与增量结合起来:多维视图 ...
  • 它主要提供特征选择、模型选择、组合分类器、分类评估等功能。 项目主页: http://cmgm.stanford.edu/~asab/pyml/tutorial/ http://pyml.sourceforge.net/ 9. Milk Milk是Python的一个机器学习工具箱,其重点是...
  • 10. 九•AWT(Abstract Window Toolkit) 事件模型 10-41 11. 十•The AWT Component Library 11-41 12. 十一•JFC(Java Foundation Classes) 12-41 13. 十二•Applets 13-41 14. 十三•线程Thread 14-41 14.1. ...
  • corejavaNoteBook

    2010-04-21 14:28:21
    10. 九•AWT(Abstract Window Toolkit) 事件模型 10-41 11. 十•The AWT Component Library 11-41 12. 十一•JFC(Java Foundation Classes) 12-41 13. 十二•Applets 13-41 14. 十三•线程Thread 14-41 14.1. ...
  • php网络开发完全手册

    热门讨论 2009-03-02 13:17:26
    13.1 关系型数据库与关系型数据库系统的 13.1 介绍 204 13.2 关系型数据库系统的结构与运行过程 205 13.2.1 关系型数据库系统的层次结构 205 13.2.2 关系型数据库系统的运行过程 206 13.3 常用的关系型数据库的介绍 ...
  • 13.16.1 新的事件模型 13.16.2 事件和接收者类型 13.16.3 用Java 1.1 AWT制作窗口和程序片 13.16.4 再探早期示例 13.16.5 动态绑定事件 13.16.6 将商业逻辑与UI逻辑区分开 13.16.7 推荐编码方法 13.17.1 桌面颜色 ...
  • ThinkInJava

    2013-05-28 14:36:27
    13.16.1 新的事件模型 13.16.2 事件和接收者类型 13.16.3 用Java 1.1 AWT制作窗口和程序片 13.16.4 再探早期示例 13.16.5 动态绑定事件 13.16.6 将商业逻辑与UI逻辑区分开 13.16.7 推荐编码方法 13.17 Java 1.1 UI ...
  • jpivot学习总结.doc

    2011-12-09 08:38:08
    memberReaderClass 设定一个成员读取器,默认情况下 Hierarchy 都是从关系型数据库里读取的,如果你的数据不在 RDBMS 里面的话,你可以通过自定义一个 member reader 来表现一个 Hierarchy 。 3.5. Level 级别 , ...

空空如也

空空如也

1 2 3
收藏数 52
精华内容 20
关键字:

关系型多维模型分类