数据仓库物理模型设计
数据库建模：概念模型,逻辑模型和物理模型
数据库建模：概念模型,逻辑模型和物理模型概念模型设计 , 逻辑模型设计 , 物理模型设计是数据库及数据仓库模型设计的三个主要步骤1. 概念模型概念模型就是在了解了⽤户的需求 , ⽤户的业务领域⼯作情况以后 , 经过分析和总结 , 提炼出来的⽤以描述⽤户业务需求的⼀些概念的东西 ;如销售业务中的客户和定单 , 还有就是商品 , 业务员 , ⽤ USE CASE 来描述就是 : 业务员与客户就购买商品之事签定下定单 , 概念模型使⽤ E-R 图表⽰ , E-R 图主要是由实体 , 属性和联系三个要素构成的 , 该阶段需完成 :1. 该系统的商业⽬的是什么 , 要解决何种业务场景2. 该业务场景中 , 有哪些⼈或组织参与 , ⾓⾊分别是什么3. 该业务场景中 , 有哪些物件参与 ,4. 此外需要具备相关⾏业经验 , 如核⼼业务流程 , 组织架构 , ⾏业术语5. 5w1h , who , what , when , where , why, how2. 逻辑模型逻辑模型是将概念模型转化为具体的数据模型的过程 , 即按照概念结构设计阶段建⽴的基本 E-R 图 , 按选定的管理系统软件⽀持的数据模型(层次/⽹状/关系/⾯向对象) , 转换成相应的逻辑模型 , 这种转换要符合关系数据模型的原则 ;还以销售业务为例 : 客户信息基本上要包括 : 单位名称 , 联系⼈ , 联系电话 , 地址等属性商品信息基本上要包括 : 名称 , 类型 , 规格 , 单价等属性定单信息基本上要包括 : ⽇期和时间属性 ; 并且定单要与客户 , 业务员和商品明细关联 , 该阶段需完成 :1. 分多少个主题 , 每个主题包含的实体2. 每个实体的属性都有什么3. 各个实体之间的关系是什么4. 各个实体间是否有关系约束3. 物理模型物理模型就是针对上述逻辑模型所说的内容 , 在具体的物理介质上实现出来 , 系统需要建⽴⼏个数据表 : 业务员信息表 , 客户信息表 , 商品信息表 , 定单表 ; 系统要包括⼏个功能 : 业务员信息维护 , 客户信息维护 , 商品信息维护 , 建⽴销售定单 ; 表 , 视图 , 字段 , 数据类型 , 长度 , 主键, 外键 , 索引 , 约束 , 是否可为空 , 默认值 , 该阶段需完成 :1. 类型与长度的定义2. 字段的其他详细定义 , ⾮空 , 默认值3. 却准详细的定义 , 枚举类型字段 , 各枚举值具体含义4. 约束的定义 , 主键 , 外键这三个过程 , 就是实现⼀个数据库设计的三个关键的步骤 , 是⼀个从抽象到具体的⼀个不断细化完善的分析 , 设计和开发的过程 ;。
数据库物理设计的内容和步骤
数据库物理设计的内容和步骤数据库物理设计是啥玩意儿？简单来说，就是把你的数据放在一个地方，让它们井井有条地排列好，这样计算机才能轻松找到它们。
那么，这个过程是怎么进行的呢？别着急，我们一步一步来告诉你。
我们需要明确数据库的类型。
数据库有很多种，比如关系型数据库、非关系型数据库等等。
不同的数据库有不同的物理设计方法。
这里我们以关系型数据库为例，来看看它的物理设计过程。
1.1 确定数据结构在开始物理设计之前，我们首先要确定数据的结构。
这就像是给你的数据搭建一个框架，告诉计算机它们应该长成什么样子。
关系型数据库中，数据是由行和列组成的表格。
每一行代表一条记录，每一列代表一个属性。
所以，我们需要知道每个属性的数据类型(如整数、字符串等)以及属性之间的关系(如一对一、一对多等)。
1.2 选择存储引擎接下来，我们需要选择一个合适的存储引擎。
存储引擎是关系型数据库中负责将数据存储到磁盘上的软件。
不同的存储引擎有不同的性能特点和适用场景。
例如，InnoDB存储引擎适用于高并发、高可用的场景，而MyISAM存储引擎则适用于读密集型的应用。
1.3 创建表空间有了数据结构和存储引擎，我们就可以开始创建表空间了。
表空间是关系型数据库中用于存放数据的逻辑结构。
它可以是一个文件、一个分区或者一个分布式文件系统。
创建表空间时，我们需要考虑数据的容量、备份策略等因素。
1.4 分配磁盘空间在创建好表空间之后，我们需要为每个表分配磁盘空间。
这就像是给数据找一个家。
在关系型数据库中，每个表都有一个唯一的表名，我们可以通过这个表名找到对应的磁盘空间。
为了提高查询效率，我们通常会将经常访问的表放在离磁盘更近的位置。
2.1 建立索引为了提高查询速度，我们还需要为经常用于查询条件的列建立索引。
索引就像是一本字典，可以帮助我们快速找到需要的数据。
不过，索引也会占用额外的磁盘空间，并且在插入、更新和删除数据时会降低性能。
因此，我们需要权衡索引的大小和性能。
数据库设计物理设计
数据库设计物理设计
数据库的物理设计主要包括以下几方面：
1. 硬件选择：选择适合数据库应用的硬件平台，包括服务器和存储设备。
考虑数据库的规模、性能要求和可靠性需求，选择合适的硬件配置。
2. 存储设备布局：根据数据库的大小和访问模式，确定数据存储的布局。
常见的存储布局包括磁盘阵列(RAID)、分区和表空间划分等。
3. 数据库文件组织方式：确定数据在物理磁盘上的组织方式，包括表空间、数据文件和日志文件等。
可以选择不同的组织方式来满足不同的访问需求，如堆文件组织方式、索引文件组织方式和哈希文件组织方式等。
4. 数据库缓存管理：通过设置数据库缓冲区大小和缓存调度策略来提高数据库的性能。
合理设置缓冲区大小可以避免频繁的磁盘读写，提高查询性能。
5. 数据库备份和恢复策略：制定数据库的备份和恢复策略，包括全量备份、增量备份和差异备份等。
根据业务需求和数据重要性确定备份频率和保留时间。
6. 数据库性能调优：通过对数据库的物理设计进行优化，提高数据库的性能。
可以通过建立合适的索引、优化查询语句和调整参数等方式来达到性能优化的目的。
7. 数据库安全性考虑：通过合理的物理设计来保护数据库的安全性，包括访问控制、权限管理和加密等。
确保只有授权用户可以访问数据库，并且数据在传输和存储过程中得到保护。
综上所述，数据库的物理设计是对数据库进行硬件选择、存储设备布局、文件组织方式、缓存管理、备份和恢复策略、性能调优和安全性考虑等方面的设计和优化。
这些设计和优化可以提高数据库的性能、可靠性和安全性，满足业务需求。
CDM & LDM & PDM
概念数据模型设计（CDM）与逻辑数据模型设计（LDM）、物理数据模型设计（PDM）是数据库及数据仓库模型设计的三个主要步骤。
在数据仓库领域有一个概念叫conceptual data model，中文一般翻译为“概念数据模型”。
概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。
概念数据模型的内容包括重要的实体及实体之间的关系。
在概念数据模型中不包括实体的属性，也不用定义实体的主键。
这是概念数据模型和逻辑数据模型的主要区别。
概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。
在有些数据模型的设计过程中，概念数据模型是和逻辑数据模型合在一起进行设计的。
在数据仓库领域有一个概念叫logical data model，中文一般翻译为“逻辑数据模型”。
逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。
逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。
逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。
逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。
逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。
如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。
在数据仓库领域有一个概念叫physical data model，中文一般翻译为“物理数据模型”。
物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。
物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行发范式化等内容。
数据仓库物理模型设计
数据仓库物理模型设计数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。
其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。
在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。
为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。
只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。
1 设计存储结构在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。
重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。
另外，在设计时还要考虑数据在特定存储介质上的布局。
在设计数据的布局时要注意遵循以下原则。
l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。
l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。
l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。
l 不要把表格和它们的索引放在同一设备上。
一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。
在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。
2 设计索引策略数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。
数据仓库设计 物理模型设计
（3）对数据仓库外部储存设备的特性，必须有足够的 了解，如I/O接口的特性、数据分组的方法、RAID的种类 与现实手段等。
3.4物理模型设计
为了保证数据仓库系统的效率，减少查询、备份、恢复 等操作所需要的时间，降低数据过于集中而带来的风险， 在设计事实表时，必须注意数据分割、粒度控制等环节， 并合理设置每个事实表中列的数量，将过于复杂的表加以 分解。
此外，还可以将历史数据归档到独立的事实表中，从而 有效地Biblioteka 制表的大小。3.4物理模型设计
3.4.3维度表的设计
完成事实表的设计之后，就应当根据逻辑模型来 设计维度的模型。
在设计事实表和维度表之间的关系时，应注意尽 可能让维度表中的数据直接参考事实表，避免通过 其他的中介而间接参考事实表的做法，以防止在查 询中出现大量的表的相互关联，给系统的CPU、I/O 通道及存储设备增加太大的负担，这样才能保证系 统具有较高的效率。
3.4.1物理模型设计要点
物理模型设计的主要内容，包括以下几个方面：
3.4物理模型设计
3.4.2事实表的设计
3.4物理模型设计
3.4.2事实表的设计
在数据仓库中，业务数据主要记录在事实中。因此，在 物理模型的层次上看，事实表不仅是数据仓库的核心，也 是构成数据仓库的所有类型的表中体积最大的表。
3.4物理模型设计
3.4.3维度表的设计
维度表的内容，是对所依附的事实表的某些信息的描 述，这种描述应具有以下特征
3.4物理模型设计
3.4.4物理模型对数据仓库性能的影响
数据仓库的数据模型设计和数据库系统的数据模型设计有什么不同？
数据仓库的数据模型设计和数据库系统的数据模型设计有什么不同？数据模型是指现实世界数据特征的抽象，是客观事物及其联系的数据描述。
数据仓库和数据库系统的数据模型设计都包括概念模型设计、逻辑模型设计和物理模型设计。
数据仓库的数据模型设计和数据库系统的数据模型设计的区别：一、模型设计阶段的不同1) 数据仓库的概念模型设计以用户理解的方式表达数据仓库的结构，确定数据仓库要访问的信息，主要是以信息包图的方法用二维表格反映数据多维性，从整体上表示用户对信息的需求，指明用户希望从数据仓库中分析的各种指标，它包括三个重要对象：指标、维度和类别。
与数据库的概念模型设计类似，也采用“实体——关系”（E-R）方法来建模，但不同的是需要用分析主题代替传统E-R方法中的实体。
数据库系统的数据模型包括概念模型——按用户的观点对数据建模。
主要用于数据库设计，采用“实体——关系”（E-R）方法来建模；逻辑模型——按计算机系统的观点对数据建模，是具体的DBMS所支持的数据模型；物理模型——对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法。
2) 数据仓库的逻辑模型设计：数据仓库是多维数据库。
数据仓库的逻辑模型是对主题域进行细化，每个主题域包含若干个数据表，并为表增加时间字段，进行表的分割，合理化表的划分。
它扩展了关系数据库模型，以星型架构为主要结构方式的，并在它的基础上，扩展雪花型架构、星群型架构等方式。
3) 数据仓库的物理数据模型就是逻辑数据模型在数据仓库中的实现，如：物理存取方式、数据存储结构、数据存放位置以及存储分配等。
物理数据模型设计实现时，所考虑的主要因素有：I／O存取时间、空间利用率和维护代价。
数据库系统的物理数据设计是在已确定的逻辑数据库结构设计的基础上，兼顾数据库的物理环境、操作约束、数据库性能和数据安全性等问题，设计出在特定环境下，具有高效率、可实现性的物理数据库的过程。
二、数据模型类别、结构不同数据仓库常用的数据模型有星型、雪花型、星群型三种。
Craft6 数据库设计教程——物理模型设计模式
一、实体分割模式（一对一）针对实体表进行字段分割处理。
一般是将一张字段较多的实体表如产品实体、订单实体等，将若干字段分割出来，独立设计一张一对一从表。
原则是：当查询实体集合时，一般不会用到的字段可以进行分割，如统计，详细描述等。
基于主体进行一对一形式的分割。
如：产品是主表，产品统计是从表。
这些字段原先是设计在主表的，为了优化分割到从表中。
从表可以设计外键，也可以不设计，一般为一对一联系，即从表的主键值为主表的主键值。
二、继承扩展模式（一对一）继承扩展同样是一对一的形式，但是业务上和主从扩展不一样。
继承扩展适合抽象实体和具体实体的扩展。
比如抽象实体参与者和具体实体员工、组织、职位等的关联关系。
设计时，可以将子表的主键设置为，既是主键又是外键。
三、主从扩展模式（一对多）这种是最为常见的模式，即主表和从表是一对多关系。
比如对于论坛系统，帖子和回复，则是明显的主从扩展模式。
表示一张帖子可以有N个回复。
设计是，从表是外键关联主表，一般外键字段设置为非空，级联约束则根据实际需要而设置，如级联删除。
四、多对多转换当两个实体或多个实体之间存在多对多关联时，实际设计数据库是设计一张多对多联系表，该表有独立的主键，但是外键关联各个实体表。
这张表就是将实体之间的多对多联系转换为一对多联系。
对于数据库范式，两个实体的多对多联系转换为两张一对多表是符合范式要求的，但对于多个实体的公共的多对多联系转换为一张公共的联系表（超过2个外键），则不符合第五范式，并且这样设计也容易混乱，所以这种情况会对实体两两分别设计一对多联系表。
即将下图的左边的联系改成右边的联系结构。
五、实体属性值扩展（EAV）如果要对一个实体进行信息扩展，可以增加一些字段，但这样在系统运营时，则比较麻烦。
需要修改数据表，修改代码等。
所以对于一些非核心属性，如描述性的信息，可以通过实体属性值扩展模式处理，即EAV模型。
此模式可以参考笔者分享的方案《 电商研发方案—— EAV实体属性值模型分析和设计》。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据仓库物理模型设计
数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。
其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。
在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。
为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。
只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。
1 设计存储结构
在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。
重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。
另外，在设计时还要考虑数据在特定存储介质上的布局。
在设计数据的布局时要注意遵循以下原则。
l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。
l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。
l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。
l 不要把表格和它们的索引放在同一设备上。
一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。
在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。
2 设计索引策略
数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。
由于数据仓库的数据一般很少更新，所以可以设计索引结构来提高数据存取效率。
在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。
数据仓库中的表通常要比联机事务处理系统（OLTP）中的表建立更多的索引，表中应用的最大索引数应与表格的规模成正比。
数据仓库是个只读的环境，建立索引可以取得灵活性，对性能极为有利。
但是表若有很多索引，那么数据加载时间就会延长，因此索引的建立需要进行综合的考虑。
在建立索引时，可以按照索引使用的频率由高到低逐步添加，直到某一索引加入后，使数据加载或重组表的时间过长时，就结束索引的添加。
最初，一般都是按主关键字和大多数外部关键字建立索引，通常不要添加很多的其他索引。
在表建立大量的索引后，对表进行分析等具体使用时，可能需要许多索引，这会导致表的维护时间也随之增加。
如果从主关键字和外部关键字着手建立索引，并按照需要添加其他索引，就会避免首先建立大量的索引带来的后果。
如果表格过大，而且需要另外增加索引，那么可以将表进行分割处理。
如果一个表中所有用到的列都在索引文件中，就不必访问事实表，只要访问索引就可以达到访问数据的目的，以此来减少I/O操作。
如果表太大，并且经常要对它进行长时间的扫描，那么就要考虑添加一张概括表以减少数据的扫描任务。
3 设计存储策略
确定数据的存储结构和表的索引结构后，需要进一步确定数据的存储位置和存储策略，以提高系统的I/O效率。
下面介绍几种常见的存储优化方法。
a．表的归并
当几个表的记录分散存放在几个物理块中时，多个表的存取和连接操作的代价会很大。
这时可以将需要同时访问的表在物理上顺序存放，或者直接通过公共关键字将相互关联的记录放在一起。
在图1中商品表和商品存储关系表是2个经常需要同时访问的表，在对存储关系表进行查询后，需要通过商品ID到商品表中获取商品的其他基本属性，以比较直观的方式显示给最终用户。
图1 表归并的表现形式
对于这种情况，我们可以将2个表的记录通过公共关键字将相互关联的记录放在一起。
如图3-57所示。
设计时可以先存放商品ID为1的商品在商品表中的记录，然后将仓储关系表中同商品1相关的2条记录放在其后。
这样，在进行数据访问时，就可以提高I/O的效率。
表的归并只有在访问序列经常出现或者表之间具有很强的访问相关性时才有较好的效果，对于很少出现的访问序列和没有强相关性的表，使用表的归并没有效果。
b．引入冗余
一些表的某些属性可能在许多地方都要用到，将这些属性复制到多个主题中，可以减少处理时存取表的个数。
例如，在图3-58所示的商品存储关系表中增加“商品名称”和“商品类型”等用户常用的字段。
这样通过在逻辑设计中引入冗余数据来达到提高更新和访问速度的效果。
c．其他方法
除了以上2种主要的方法外，还有以下3种方法可以对存储分配进行优化。
l 建立数据序列。
按照某一固定的顺序访问并处理一组数据记录。
将数据按照处理顺序存放到连续的物理块中，形成数据序列。
l 表的物理分割。
每个主题中的各个属性存取频率是不同的。
将一张表按各属性被存取的频率分成2个或多个表，将具有相似访问频率的数据组织在一起。
l 生成派出数据。
在原始数据的基础上进行总结或计算，生成派出数据，可以在应用中直接使用这些派出数据，减少I/O次数，免去计算或汇总步骤，在更高级别上建立了公用数据源，避免了不同用户重复计算可能产生的偏差。
以上完成了数据仓库从概念模型到物理模型的整个设计过程。
下一步的工作就是创建数据仓库。
由于数据仓库本身是由DBMS管理的，因此可以像创建普通的数据库一样创建设计好
的数据仓库。