一、数据仓库结构体系
1. 数据仓库结构
1.1 数据仓库的定义:
数据仓库是一个集成的、面向主题的、相对稳定的数据集合,主要用于支持决策分析。它整合了来自不同数据源的数据,经过清洗和转换后存储在这里,以便进行查询和分析。它的结构通常包括以下几个层次:
- 数据源层:包括各种数据源,如操作数据库、外部数据、文件等。
- 数据仓库层:整合来自不同数据源的数据,经过清洗和转换后存储在这里。
- 数据访问层:用户通过各种工具(如BI工具、报表工具)访问数据仓库中的数据。
2. 数据集市及其结构
2.1 定义:
数据集市(Data Mart)是数据仓库的一个子集,通常针对特定的业务领域或部门(如销售、财务等)。
2.2 结构:
- 主题导向:数据集市通常围绕特定主题组织数据,便于特定用户群体使用。
- 简化:数据集市的数据量相对较小,查询和分析速度更快。
2.3 实际例子
假设一家大型零售公司,名为“优选超市”,它的业务涵盖多个领域,包括销售、财务、库存管理和客户服务等。为了更好地支持不同部门的决策,优选超市决定建立一个数据仓库,并在此基础上创建多个数据集市。
(1)数据集市示例:销售数据集市
- 定义:优选超市创建了一个专门的销售数据集市,专注于销售部门的需求。
- 内容:这个销售数据集市包含了与销售相关的数据,如:
- 每个产品的销售数量
- 销售额
- 销售时间
- 客户信息(如客户ID、地区等)
(2)大白话理解
-
数据集市是数据仓库的子集:
- 想象你有一个大超市(数据仓库),里面有各种各样的商品(数据)。为了方便顾客(特定用户群体),你在超市里开了一个专门的水果区(数据集市),只卖水果(特定主题的数据)。这个水果区的商品种类虽然少,但顾客能更快找到他们想要的东西。
-
主题导向:
- 水果区只关注水果,顾客在这里可以轻松找到苹果、香蕉、橙子等,而不需要在整个超市里寻找。类似地,销售数据集市专注于销售数据,方便销售人员快速获取所需的信息。
-
简化:
- 水果区的商品数量相对较少,顾客在选择时不会感到困惑,能快速做出决定。同样,销售数据集市的数据量较小,查询和分析速度更快,销售人员可以迅速获取销售报告,做出及时的决策。
3. 数据仓库系统结构
数据仓库系统的结构通常包括以下几个组件:(下面会进行详细的讲解)
- 数据抽取、转换和装载(ETL):负责从数据源提取数据,进行转换和清洗,然后加载到数据仓库中。
- 数据存储:存储经过处理的数据,通常使用关系型数据库或专门的数据仓库技术。
- 数据访问和分析工具:用户通过这些工具访问和分析数据,生成报表和可视化。
4. 数据仓库的运行结构
数据仓库的运行结构通常包括以下几个方面:
- 数据流:数据从数据源流入数据仓库,经过ETL处理后存储在数据仓库中。
- 用户访问:用户通过BI工具或查询工具访问数据仓库,进行数据分析和决策支持。
- 维护和管理:定期对数据仓库进行维护和更新,确保数据的准确性和一致性。
- 具体的流程图大家可以看一下这位博主的这篇文章
二、数据仓库中的粒度概念
粒度是指数据的详细程度。在数据仓库中,粒度的概念非常重要,因为它影响到数据的存储、查询和分析。
1.粒度的定义:
- 粒度可以理解为数据的细节层次/详细程度。粒度越细,数据越详细;粒度越粗,数据越汇总/综合。例如,销售数据的粒度可以是按每个销售交易记录(详细粒度),也可以是按每月的销售总额(汇总粒度)。
2.粒度的类型:
- 详细粒度:存储每个交易或事件的具体信息,如每笔销售的时间、地点、金额等。
- 汇总粒度:存储经过聚合的数据,如按月、按季度的销售总额。
3.粒度的选择:
- 在设计数据仓库时,需要根据业务需求选择合适的粒度。详细粒度提供了丰富的信息,但存储和处理成本较高;而汇总粒度则能提高查询效率,但可能会丢失一些细节信息。
4.举例:
- 详细粒度:你有一个销售数据表,记录了每一笔交易的信息,包括:
- 交易时间:2025年3月8日 10:30
- 产品:咖啡
- 数量:2
- 价格:5美元
- 汇总粒度:你将这些交易汇总成每月的销售总额,比如:
- 2025年3月的总销售额:5000美元
5.大白话理解:
- 粒度就像是你拍照的清晰度。拍得越清楚(详细粒度),你能看到更多细节;拍得模糊(汇总粒度),你只能看到大概的情况。
三、数据仓库模型
(一)、事实表
1. 定义
事实表是数据仓库中存储业务事件或交易数据的表格。它通常包含数值型数据(如销售额、数量、利润等),并且每一行代表一个具体的事件或事务。例如,在销售数据中,每一行可能表示一次销售交易的详细信息。
2. 特点
- 数值数据:事实表主要存储可以进行数学计算的数据,例如销售金额、交易数量等。
- 外键:事实表通常包含多个外键,这些外键指向维度表,以便提供上下文信息。外键是维度表的主键,帮助将事实与维度关联起来。
(二)、维度
维度是用于描述事实表中数据的上下文信息的表格。它们提供了对事实数据的详细说明,使得数据分析更具意义。以下是一些常见的维度及其定义:
1. 产品维度
- 定义:产品维度表存储有关产品的信息,如产品ID、名称、类别、品牌、价格等。
- 示例字段:
- 产品ID
- 产品名称
- 产品类别
- 品牌
- 价格
2. 时间维度
- 定义:时间维度表存储与时间相关的信息,如日期、星期、月份、季度、年份等。
- 示例字段:
- 日期ID
- 日期(如2025年3月8日)
- 星期(如星期六)
- 月份(如3月)
- 年份(如2025年)
3. 客户维度
- 定义:客户维度表存储有关客户的信息,如客户ID、姓名、性别、地区、联系方式等。
- 示例字段:
- 客户ID
- 客户姓名
- 性别
- 地区
- 联系电话
4. 地点维度
- 定义:地点维度表存储与销售地点相关的信息,如商店ID、商店名称、地址、城市、州等。
- 示例字段:
- 地点ID
- 商店名称
- 地址
- 城市
- 州
(三)、维度与事实表的关系
-
外键关系:
- 在事实表中,通常会有多个外键,这些外键指向不同的维度表。例如,销售事实表可能包含以下外键:
- 产品ID(指向产品维度表)
- 日期ID(指向时间维度表)
- 客户ID(指向客户维度表)
- 地点ID(指向地点维度表)
- 在事实表中,通常会有多个外键,这些外键指向不同的维度表。例如,销售事实表可能包含以下外键:
-
上下文提供:
- 维度表为事实表中的数值数据提供上下文信息,使得数据更具意义。例如:
- 销售额的上下文可以是“在2025年3月8日,某客户在某商店购买了某产品”。
- 通过结合事实表和维度表,分析师可以回答复杂的问题,比如“哪个产品在特定时间段内销售最好?”。
- 维度表为事实表中的数值数据提供上下文信息,使得数据更具意义。例如:
-
数据分析:
- 通过查询事实表和维度表,用户可以进行多维分析。例如,用户可以分析“在2025年3月的销售数据中,哪个地区的销售额最高?”通过时间维度表和地点维度表的结合,用户可以快速获取所需的信息。
(四)、大白话理解事实表与维度表的关系
1.账本(事实表):
示例账本(事实表):
销售ID | 产品ID | 客户ID | 日期ID | 地点ID | 销售数量 | 销售金额 |
---|---|---|---|---|---|---|
1 | 101 | 201 | 301 | 401 | 2 | 50.00 |
2 | 102 | 202 | 301 | 402 | 1 | 30.00 |
3 | 101 | 203 | 302 | 401 | 3 | 75.00 |
4 | 103 | 201 | 302 | 403 | 1 | 20.00 |
- 想象你有一个账本,里面记录了所有的账单信息。每一行代表一笔交易,比如某个客户在某个时间购买了某个产品,具体的销售金额和数量等。
- 这些信息可能是杂乱无章的,单独看每一行并不能让你快速理解整体的销售情况。
2.维度表:
- 维度表就像是对账本中信息的整理和分类。它们提供了关于每个交易的上下文信息,使得数据更有条理。
- 通过维度表,你可以将账本中的信息与具体的产品、客户、时间和地点关联起来,从而更好地理解每一笔交易的背景。
示例维度表:
-
产品维度表:
产品ID 产品名称 产品类别 101 咖啡 饮料 102 茶 饮料 103 饼干 零食 -
客户维度表:
客户ID 客户姓名 地区 201 张三 北京 202 李四 上海 -
时间维度表:
日期ID 日期 301 2025-03-08 302 2025-03-09 -
地点维度表:
地点ID 商店名称 401 商店A 402 商店B
3.整理与条理化
-
通过维度表整理信息:
- 当你想要分析销售数据时,你可以通过维度表来整理和条理化账本中的信息。例如:
- 你可以查看“在2025年3月8日,张三在商店A购买了2杯咖啡,总共花费50元”。
- 通过维度表,你可以快速找到与每笔交易相关的详细信息,而不必在账本中逐行查找。
- 当你想要分析销售数据时,你可以通过维度表来整理和条理化账本中的信息。例如:
-
数据分析的便利性:
- 这种结构使得数据分析变得更加高效和直观。你可以轻松回答各种问题,比如“哪个产品在特定时间段内销售最好?”或“哪个客户的购买频率最高?”。
4.总结
- 账本(事实表)记录了所有的交易信息,但这些信息可能是杂乱的。
- 维度表提供了对这些交易的上下文信息,使得数据更有条理,便于分析和理解。
- 通过维度表,你可以将账本中的信息整理成有意义的分析结果。
(五)、数据仓库模型:(可以点击链接,这个视频是我觉得B站讲得比较好的,如果大家觉得这些模型抽象的话,可以看看这个视频的讲解)
1. 星形模型(Star Schema)
1. 定义
星形模型是数据仓库中一种常用的数据建模方式,主要用于组织和存储数据。它的结构像一个星星,中心是一个事实表,周围是多个维度表。这种结构使得数据查询和分析变得更加高效和简单。
2. 组成部分
-
事实表:
- 存储与业务事件相关的数据,通常是数值型数据,如销售额、数量、利润等。
- 事实表的每一行代表一个具体的事件或交易。例如,在销售事实表中,一行可能表示某个产品在某个时间的销售情况。
-
维度表:
- 存储描述事实表中数据的上下文信息,通常是文本型数据,如时间、产品、客户、地点等。
- 维度表的每一行提供了对事实表中数据的详细描述。例如,时间维度表可能包含日期、星期、月份等信息,而产品维度表可能包含产品名称、类别、品牌等信息。
3.星形模型的优点
-
简化查询:
- 由于维度表直接连接到事实表,查询时不需要复杂的连接操作,查询速度更快。
-
易于理解:
- 结构清晰,易于理解,适合非技术用户进行数据分析。
-
灵活性:
- 可以轻松地添加新的维度表或事实表,方便扩展。
4.大白话理解
上头讲维度与事实表的那个举例就是星形模型的例子
-
星形模型就像是一个星星:
- 想象一下,你在一个星星的中心,有一个圆点(事实表),这个圆点代表着某个重要的事情,比如“销售”。然后,围绕这个圆点,有几条线连接到其他的圆圈(维度表),这些圆圈代表着与销售相关的其他信息,比如“时间”、“产品”、“客户”和“地点”。
-
快速找到信息:
- 当你想知道某个产品在特定时间的销售情况时,你只需查看中心的事实表,然后通过维度表找到相关的时间和产品信息。这样,你就能快速找到你需要的数据,而不必在复杂的数据中迷失。
5.实际例子
假设你是一家零售公司的数据分析师,你的任务是分析销售数据。
-
事实表:你有一个“销售事实表”,记录了每笔交易的信息,比如:
- 销售金额:100美元
- 销售数量:5个
- 销售日期:2025年3月8日
- 产品ID:123
- 客户ID:456
-
维度表:
- 时间维度表:记录了日期、星期、月份等信息。
- 产品维度表:记录了产品ID、产品名称、类别等信息。
- 客户维度表:记录了客户ID、客户姓名、地区等信息。
通过星形模型,你可以很方便地查询,比如“2025年3月8日,产品名称为‘咖啡’的销售额是多少?”你只需查找销售事实表,然后通过产品维度表找到“咖啡”的ID,最后得出结果。
2. 雪花模型(Snowflake Schema)
雪花模型是对星形模型的扩展,维度表进一步规范化,形成多个层次。
- 特点:维度表被拆分成多个相关表,减少数据冗余,但查询时可能会更复杂。
大白话理解:就是在星形模型的基础上再进行细分,把星形模型中的维度表中具有数据冗余的数据再进行划分出一些维度表
3. 星网模型(Galaxy Schema)
星网模型是多个星形模型的组合,适用于复杂的业务场景。
- 特点:可以同时支持多个事实表和维度表,适合大型企业的多维分析需求。
大白话理解:星网模型就像是一个星系,里面有多个星星(事实表),每个星星都有自己的维度(维度表),适合复杂的分析。
4. 第三范式对这些模型的影响和关联
- 第三范式:强调消除数据冗余,确保数据的完整性。
- 影响:在星形模型中,维度表通常不遵循第三范式,以提高查询性能;而在雪花模型中,维度表遵循第三范式,减少冗余。
5.星形模型、雪花模型和星网模型的对比表格
特性 | 星形模型 (Star Schema) | 雪花模型 (Snowflake Schema) | 星网模型 (Galaxy Schema) |
---|---|---|---|
结构 | 中心是一个事实表,周围是多个维度表。 | 维度表进一步规范化,可能有多个层次。 | 包含多个事实表和维度表,形成复杂的网络结构。 |
维度表 | 维度表通常是非规范化的,结构简单。 | 维度表是规范化的,可能分为多个子表。 | 维度表可以是非规范化或规范化的,灵活性高。 |
查询性能 | 查询性能较好,适合快速查询。 | 查询性能较差,因需要多次连接维度表。 | 查询性能介于星形模型和雪花模型之间。 |
数据冗余 | 数据冗余较高,因维度表通常不进行规范化。 | 数据冗余较低,因维度表经过规范化处理。 | 数据冗余情况因模型设计而异。 |
维护复杂性 | 维护相对简单,易于理解和使用。 | 维护较复杂,因维度表结构较为复杂。 | 维护复杂,因涉及多个事实表和维度表。 |
适用场景 | 适合于简单的查询和报表生成。 | 适合于需要高数据一致性的复杂分析。 | 适合于大型数据仓库,支持多维分析和复杂查询。 |
示例 | 销售事实表 + 产品维度表 + 客户维度表 | 销售事实表 + 产品维度表(进一步分为类别和品牌) + 客户维度表 | 销售事实表 + 订单事实表 + 产品维度表 + 客户维度表 + 时间维度表 |
详细解释
-
星形模型 (Star Schema):
- 结构:简单明了,中心是一个事实表,周围是多个维度表。
- 优点:查询性能好,易于理解和使用,适合快速查询和报表生成。
- 缺点:数据冗余较高,可能导致存储空间浪费。
-
雪花模型 (Snowflake Schema):
- 结构:维度表经过规范化,可能分为多个子表,形成层次结构。
- 优点:数据冗余较低,数据一致性高,适合需要高数据一致性的复杂分析。
- 缺点:查询性能较差,因需要多次连接维度表,维护较复杂。
-
星网模型 (Galaxy Schema):
- 结构:包含多个事实表和维度表,形成复杂的网络结构。
- 优点:灵活性高,适合大型数据仓库,支持多维分析和复杂查询。
- 缺点:维护复杂,因涉及多个事实表和维度表,可能导致理解困难。
6.总结
- 星形模型适合简单的查询和报表生成,结构简单,易于理解。
- 雪花模型适合需要高数据一致性的复杂分析,数据冗余较低,但维护复杂。
- 星网模型适合大型数据仓库,支持多维分析和复杂查询,但维护和理解较为困难。
四、数据抽取、转换和装载(ETL)
1. 数据抽取(Extract)
数据抽取是从各种数据源中提取数据的过程。数据源可以是关系型数据库、非关系型数据库、文件等。
大白话理解:就像从不同的地方收集材料,准备做一顿大餐。
2. 数据转换(Transform)
数据转换是对提取的数据进行清洗、格式化和整合的过程,以确保数据的一致性和准确性。
- 操作:包括数据清洗(去除重复、修正错误)、数据格式转换(如日期格式)、数据聚合(如求和、平均)等。
大白话理解:就像把收集到的材料洗净、切好、调味,准备好做菜。
3. 数据装载(Load)
数据装载是将转换后的数据加载到数据仓库中的过程。
- 方式:可以是全量加载(一次性加载所有数据)或增量加载(定期加载新数据)。
大白话理解:就像把准备好的菜放到锅里,开始烹饪。
五、元数据
1. 元数据的重要性
元数据是描述数据的数据,提供数据的上下文和意义。它在数据仓库中非常重要,因为:
- 理解数据:帮助用户理解数据的来源、结构和含义。
- 数据管理:支持数据的管理和维护,确保数据的一致性和准确性。
- 提高效率:通过元数据,用户可以快速找到所需的数据,减少搜索时间。
2. 关于数据源的元数据
- 定义:描述数据源的信息,如数据源的类型、位置、结构等。
- 作用:帮助用户了解数据的来源和获取方式。
3. 关于数据模型的元数据
- 定义:描述数据模型的结构和关系,如表的定义、字段的类型、约束条件等。
- 作用:帮助用户理解数据的组织方式和使用规则。
4. 关于数据仓库映射的元数据
- 定义:描述数据从数据源到数据仓库的映射关系,包括ETL过程中的转换规则。
- 作用:帮助用户理解数据如何从源系统流入数据仓库。
5. 关于数据仓库使用的元数据
- 定义:描述数据仓库中数据的使用情况,如数据的访问频率、使用者等。
- 作用:帮助管理者优化数据仓库的性能和使用效率。
六、数据仓库与元数据的关系:
1.关系阐述:
整个数据仓库的组织结构是由元数据来组织的,它不包含任何业务数据库中的实际数据信息。元数据在数据仓库中扮演了重要角色,它包括如下信息:
(1)数据仓库的目录信息(数据字典);
(2)数据从数据库环境先数据仓库环境转换时对应的说明;
(3)知道从当前基本数据到综合数据的综合方式的说明;
(4)指导用户使用数据仓库
2.关系理解:
-
元数据的定义:
- 元数据是描述数据的数据,它提供了关于数据的上下文和结构信息。在数据仓库中,元数据并不包含实际的数据,而是描述数据的特性、来源、结构和使用方式。它告诉我们数据是什么、从哪里来、怎么用。
-
元数据的组织结构:
- 数据仓库的组织结构依赖于元数据来定义和管理。元数据帮助用户理解数据仓库中的数据是如何组织的,如何访问和使用这些数据。
-
元数据的内容:
- 数据仓库的目录信息(数据字典):提供数据仓库中所有数据对象的定义和描述,包括表、字段、数据类型等信息。
- 数据转换说明:描述数据从源数据库到数据仓库的转换过程,包括数据清洗、格式转换等。
- 综合方式的说明:指明如何将基本数据(详细数据)转换为综合数据(汇总数据),例如通过聚合、计算等方式。
- 用户指导:提供用户如何使用数据仓库的说明,包括查询方法、数据访问权限等。
3.举例:
- 假设你有一个数据仓库,里面存储了销售数据。元数据可能包括:
- 数据字典:告诉你“销售额”这个字段是指什么,数据类型是数字,单位是美元。
- 数据转换说明:说明如何将原始的销售记录(比如从不同的商店)转换成统一的格式。
- 综合方式的说明:比如,如何从每天的销售数据计算出每月的销售总额。
- 用户指导:提供如何查询销售数据的说明,比如“要查看某个产品的销售情况,请使用‘销售查询’工具”。
4.大白话理解:
- 想象你在图书馆找书,元数据就像是书架上的标签,告诉你每本书的内容、作者和位置。没有这些标签,你就很难找到你想要的书。
七、数据库和数据仓库之间的关系
1.定义
- 数据库:
- 数据库是一个结构化的数据存储系统,主要用于存储和管理日常事务数据。它支持快速的插入、更新、删除和查询操作,通常用于支持在线事务处理(OLTP)。
- 数据仓库:
- 数据仓库是一个集成的、面向主题的数据存储系统,主要用于支持决策分析和业务智能。它整合了来自不同数据源的数据,经过清洗和转换后存储在这里,以便进行复杂的查询和分析,通常用于支持在线分析处理(OLAP)。
2.功能
-
数据库的功能:
- 主要用于日常事务处理,如订单管理、客户信息管理等。
- 支持实时数据的插入、更新和查询,确保数据的一致性和完整性。
-
数据仓库的功能:
- 主要用于数据分析和决策支持,帮助企业从历史数据中提取洞察。
- 支持复杂的查询和报表生成,通常涉及大量的历史数据和汇总数据。
3.结构
-
数据库的结构:
- 通常采用规范化设计,以减少数据冗余,确保数据的一致性。
- 数据库中的数据通常是实时的,强调事务的完整性。
-
数据仓库的结构:
- 通常采用去规范化设计(如星形模型、雪花模型),以提高查询性能。
- 数据仓库中的数据主要是历史数据,强调数据的整合和分析。
4.用途
-
数据库的用途:
- 用于支持日常业务操作,如处理客户订单、管理库存、记录交易等。
- 适合需要快速响应的应用场景。
-
数据仓库的用途:
- 用于支持业务分析、趋势预测和决策制定。
- 适合需要对历史数据进行深入分析的场景。
5.关系总结
-
数据来源:
- 数据仓库通常从一个或多个数据库中提取数据。数据库提供了实时的操作数据,而数据仓库则整合了这些数据以支持分析。
-
数据流动:
- 数据从数据库流入数据仓库的过程通常涉及ETL(抽取、转换、装载)过程。数据在进入数据仓库之前会经过清洗和转换,以确保数据的质量和一致性。
-
互补关系:
- 数据库和数据仓库在企业数据管理中是互补的。数据库处理日常事务,而数据仓库则用于分析和决策支持。两者共同构成了企业的数据管理体系。
6.实际例子
-
例子1:假设一家零售公司使用数据库来管理客户订单。每当客户下单时,订单信息会被实时写入数据库中。这个数据库支持快速查询和更新,以确保客户能够及时收到订单信息。
-
例子2:同一家零售公司还建立了一个数据仓库,用于分析销售趋势。每个月,数据库中的订单数据会被提取到数据仓库中,经过清洗和汇总,生成每月的销售报告。管理层可以通过数据仓库查看不同产品的销售趋势,以便做出更好的决策。
7.总结
- 数据库是用于日常事务处理的系统,强调实时性和数据一致性。
- 数据仓库是用于数据分析和决策支持的系统,强调数据整合和历史数据分析。
- 两者之间通过ETL过程相互连接,数据库为数据仓库提供数据支持,数据仓库则为决策提供分析基础。
八、数据仓库里的综合数据的存储与计算
1.来自课本的一段话:
在数据库中只存储当前的详细数据。而数据仓库除了存储按主题组织起来的当前详细数据外,还需要存储综合数据,这是为适应决策需求而增加的。在数据库中需要得到综合数据时,采用数据立方体方法对详细数据进行综合。在数据仓库中并不采取临时计算的方式得到综合数据,而是在用户提出需要综合数据之前,就预先将可能需要的综合数据利用数据立方体计算好,存入综合数据层中,这种综合数据曾在用户查询时,能迅速提供给用户。为此,在建数据仓库时,要分析好各类用户可能需要哪些综合数据,并将这些综合数据都存储在综合数据层中。
2.如何理解这段话:
2.1 综合数据的定义:
- 综合数据是将详细数据汇总后得到的信息,通常用于支持决策。
2.2 数据库与数据仓库的区别:
- 数据库:主要存储当前的详细数据,适合日常事务处理。
- 数据仓库:除了存储当前的详细数据外,还存储综合数据(汇总数据),以支持决策分析。
2.3 综合数据的存储:
- 数据仓库中的综合数据是为了满足决策需求而预先计算和存储的。这意味着在用户提出查询之前,数据仓库已经将可能需要的综合数据计算好,并存储在综合数据层中。
2.4 数据立方体的概念:
- 数据立方体是一种多维数据模型,用于存储和分析数据。它允许用户从多个维度(如时间、地点、产品)对数据进行汇总和分析。
- 在数据仓库中,综合数据通常是通过数据立方体的方式进行计算和存储的,这样用户在查询时可以快速获取所需的汇总信息。
- 数据立方体是一种多维数据模型,可以让你从不同的角度查看数据。例如,你可以查看:
- 按产品(咖啡、茶)分类的销售额
- 按地区(北区、南区)分类的销售额
- 按时间(按月、按季度)分类的销售额
2.5 预计算的优势:
- 预先计算综合数据的方式可以提高查询效率,因为用户在查询时不需要实时计算,而是直接从存储的综合数据中获取结果。这种方法适合于决策支持系统,因为决策者通常需要快速获取信息。
2.6 用户需求分析:
- 在构建数据仓库时,分析用户可能需要的综合数据是非常重要的。这有助于确定哪些数据需要预先计算和存储,以便在用户查询时能够迅速提供所需的信息。
2.7 举例:
- 在数据库中,如果你想知道某个产品的总销售额,你可能需要实时计算所有相关的交易记录。
- 在数据仓库中,综合数据会提前计算好,比如每个月的销售总额,并存储在一个专门的表中。
2.8 大白话理解:
- 想象你在餐厅点菜。数据库就像是厨师在你点菜时才开始准备食材,而数据仓库就像是餐厅提前准备好了一些常见的菜品,顾客点的时候可以快速上菜。
九、总结
1.数据仓库结构体系
- 定义:数据仓库是集成的、面向主题的、相对稳定的数据集合,用于支持决策分析。
- 层次结构:
- 数据源层:包括操作数据库、外部数据、文件等。
- 数据仓库层:整合、清洗和转换后的数据存储。
- 数据访问层:用户通过BI工具等访问数据。
2.数据集市及其结构
- 定义:数据集市是数据仓库的子集,针对特定业务领域或部门。
- 结构:
- 主题导向:围绕特定主题组织数据。
- 简化:数据量小,查询和分析速度快。
- 示例:销售数据集市,包含销售数量、销售额、销售时间和客户信息。
3.数据仓库系统结构
- 组件:
- ETL:抽取、转换和装载数据。
- 数据存储:使用关系型数据库或专门的数据仓库技术。
- 数据访问工具:用于访问和分析数据的工具。
4.数据仓库的运行结构
- 数据流:数据从源流入数据仓库,经过ETL处理。
- 用户访问:通过BI工具进行数据分析和决策支持。
- 维护和管理:定期维护和更新数据,确保准确性和一致性。
5.数据仓库中的粒度概念
- 定义:粒度是数据的详细程度,越细越详细,越粗越汇总。
- 类型:
- 详细粒度:存储每个交易的具体信息。
- 汇总粒度:存储经过聚合的数据。
- 选择:根据业务需求选择合适的粒度。
6.数据仓库模型
- 事实表:存储业务事件或交易数据,包含数值型数据和外键。
- 维度表:描述事实表数据的上下文信息,如产品、时间、客户等。
- 关系:事实表通过外键与维度表关联,提供数据分析的上下文。
7.数据仓库模型类型
- 星形模型:中心是事实表,周围是维度表,查询性能好。
- 雪花模型:维度表进一步规范化,减少冗余,但查询复杂。
- 星网模型:多个星形模型的组合,适合复杂业务场景。
8.ETL过程
- 数据抽取:从各种数据源提取数据。
- 数据转换:清洗、格式化和整合数据。
- 数据装载:将转换后的数据加载到数据仓库。
9.元数据
- 重要性:描述数据的上下文和结构,帮助理解和管理数据。
- 类型:
- 数据源元数据:描述数据源的信息。
- 数据模型元数据:描述数据模型的结构和关系。
- 数据仓库映射元数据:描述数据从源到仓库的映射关系。
10.数据库与数据仓库的关系
- 定义:
- 数据库:用于日常事务处理,强调实时性和一致性。
- 数据仓库:用于数据分析和决策支持,强调数据整合和历史数据分析。
- 功能:数据库支持实时操作,数据仓库支持复杂查询和报表生成。
- 结构:数据库通常采用规范化设计,数据仓库采用去规范化设计以提高查询性能。
11.综合数据的存储与计算
- 综合数据定义:将详细数据汇总后得到的信息,用于支持决策。
- 存储方式:数据仓库预先计算并存储综合数据,以提高查询效率。
- 数据立方体:多维数据模型,用于存储和分析数据,支持从多个维度进行汇总和分析。