下载文档原格式
数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151:.概念模型设计;.逻辑模型设计;.物理模型设计;下面就从这三个层面分别介绍数据仓库模型的设计。
2.5.1概念模型设计进行概念模型设计所要完成的工作是:<1>界定系统边界<2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。
因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。
一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:. 要做的决策类型有哪些?. 决策者感兴趣的是什么问题?. 这些问题需要什么样的信息?. 要得到这些信息需要包含原有数据库系统的哪些部分的数据?这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。
因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括:. 主题域的公共码键;. 主题域之间的联系:. 充分代表主题的属性组。
数据库建设规范数据库作为存储、管理和处理数据的重要工具，在现代信息化建设中起着至关重要的作用。
为了提高数据库的质量和效率，确保数据的安全性和准确性，需要制定一套数据库建设规范。
本文将从数据库设计、数据规范、性能优化和安全保障四个方面详细介绍数据库建设规范。
一、数据库设计在数据库建设的初期阶段，良好的数据库设计能够为后期的开发和维护工作奠定基础。
数据库设计应遵循以下几点规范：1. 数据库表命名规范表名应具有具体的描述性，能够准确表达其所存储的数据内容，并采用小写字母与下划线组合的方式命名，例如"order_info"。
2. 字段命名规范字段名应有明确的含义，避免使用缩写和数字等模糊的命名方式。
同时，字段名也应采用小写字母与下划线组合的方式命名，例如"create_time"。
3. 主键和外键规范每个表应有主键，并使用自增长或唯一性约束来保证主键的唯一性。
同时，在设计关联表时，外键应与关联的主键类型一致。
4. 索引规范为常用作查询条件的字段创建索引，以提高查询效率。
在创建索引时，需要根据实际情况进行选择，避免过多的索引对性能造成负面影响。
二、数据规范数据库中的数据质量对于后续的数据分析和决策产生重要影响。
为了保证数据的一致性和准确性，需要制定以下数据规范：1. 数据类型规范在对字段进行设计时，需要选择合适的数据类型，以节省存储空间，并确保数据的正确性。
例如，对于存储日期时间的字段，应选择合适的日期时间类型。
2. 数据录入规范为了避免数据录入错误，需要制定数据录入规范。
规定数据录入格式、校验规则和必填字段，同时提供数据录入的帮助文档和提示信息，以减少错误的发生。
3. 数据清洗规范对于已有的大规模数据，需要进行数据清洗，剔除重复、错误、缺失和异常数据，以保证数据库中的数据质量。
三、性能优化数据库的性能直接关系到系统的响应速度和用户体验。
为了提高数据库的性能，需要进行以下优化措施：1. 查询优化使用合适的查询方式、优化复杂查询语句、减少不必要的连接和子查询，以提高查询效率。
《数据仓库建设指南》数据仓库建设指南随着企业信息化的趋势不断发展，数据化已经成为企业成长的必经之路。
数据成为了企业在竞争中的筹码，企业数据分析的能力也成为了企业成功的关键。
更多的企业意识到，要想在市场上占有一席之地，精细管理企业，就必须建立一个合理的数据仓库。
那么，数据仓库建设需要考虑哪些要素和步骤呢？本文将一一为您解析。
一、数据仓库简介数据仓库是一种长期积淀和管理数据的系统，它可以帮助企业集中存储和管理来自各种渠道的数据，为企业提供分析支持。
它可以将内部和外部的数据整合、加工之后建立一个统一的数据层用于分析，这样企业就可以在分析过程中减少对数据来源的依赖，加快数据分析过程。
二、数据仓库建设步骤1.规划和准备数据仓库建设是需要投入大量的时间和精力的，因此，首先需要确定需求，明确数据仓库的建设目标，并确保团队中所有成员都清楚地理解目标和业务需求。
同时，团队还需要了解企业的业务流程。
在规划和准备阶段，团队需要对企业业务进行分析和评估，确定数据仓库中需要的信息和数据以及其来源；需要制定数据建设计划，分步骤地完成数据仓库的各个环境的建设和测试，以确保其稳定性和数据可靠性。
2.设计在设计阶段，需要确定数据仓库的基本结构和架构等。
从不同的维度来考虑数据仓库的数据设计，面向业务时的数据设计包括事实表和维度表的设计，以及定义关系型数据模式。
面向数据仓库的设计要考虑数据的存储形式和数据的管理：如何利用索引快速查找数据，如何存储不同的数据格式或类型等。
3.实施实施是数据仓库建设中最为繁琐的环节，这个过程需要投入大量的人力和物力资源。
需要与各种数据源进行连接和整合，然后将这些数据存储到数据仓库中，来适应变化的数据分析需求。
在实施过程中，需要考虑数据清洗、转换和加工等过程。
数据清洗的目的是过滤掉不必要的数据，转换是将数据从一种格式转换为另一种；加工就是从原数据中提取关键信息。
4.测试和验证测试与验证是数据仓库建设过程中很重要的步骤，通过测试可以验证数据仓库所设计的模型和工具是否能够适应实际的业务需求，同时也可以提供一些有益的改进建议。
数仓模型设计原则
1. 明确业务需求：数仓模型应该紧密关联业务，准确反映业务现状和要求，满足业务分析需求。
2. 清晰数据架构：数仓模型应该按照一定的规则、约束和标准，由基础数据、汇总数据、指标数据和其他数据层次组成，使得数据能够在不同层次之间流转和分析。
3. 有效维度建模：数仓模型需要将业务中复杂的概念和关系抽象为可重用的维度，使得维度成为数据分析和查询的基础。
4. 模块化可维护：数仓模型需要采用模块化的设计，方便模型的维护和升级，并且具有可扩展性和可重用性。
5. 数据质量保证：数仓模型需要在设计阶段考虑数据质量问题，包括数据来源、数据清洗、数据同步等，确保数据准确性和一致性。
6. 保证数据安全：数仓模型中的数据需要根据不同的角色和权限进行访问控制，保证数据的安全性和隐私性。
7. 可操作性和易用性：数仓模型需要保证数据的操作性和易用性，同时需要具备数据可视化和数据分析的能力，方便用户进行数据挖掘和分析。
数据仓库规范一．数据仓库层次结构规范1.1 基本分层结构系统的信息模型从存储的内容方面可以分为，STAGE接口信息模型、ODS/DWD信息模型，MID信息模型、DM信息模型、元数据信息模型。
在各个信息模型中存储的内容如下描述：1) SRC接口层信息模型：提供业务系统数据文件的临时存储，数据稽核，数据质量保证，屏蔽对业务系统的干扰，对于主动数据采集方式，以文件的方式描述系统与各个专业子系统之间数据接口的内容、格式等信息。
与该模型对应的数据是各个专业系统按照该模型的定义传送来的数据文件。
STAGE是生产系统数据源的直接拷贝，由ETL过程对数据源进行直接抽取，在格式和数据定义上不作任何改变。
与生产系统数据的唯一不同是，STAGE层数据具有时间戳。
STAGE层存在的意义在于两点：（1）对数据源作统一的一次性获取，数据仓库中其他部分都依赖于STAGE层的数据，不再重复进行抽取，也不在生产系统上作运算，减小生产系统的压力；（2）在生产系统数据已经刷新的情况下，保存一定量的生产系统的历史数据，以便在二次抽取过程中运算出错的情况下可以进行回溯。
2) ODS/DWD层（对应原模型的ODS和DW层）信息模型：简称DWD层是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中。
为企业进行经营数据的分析，系统将数据按分析的主题的形式存放，跟STAGE层的粒度一致，属于分析的公共资源。
3) MID 信息模型：轻度综合层是新模型增加的数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计。
轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并为满足一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。
4) DM信息模型：为专题经营分析服务，系统将数据按分析的专题组织成多维库表的形式存放，属于分析目标范畴的数据组织与汇总，属于分析的专有资源。
XX数据仓库建设规范版本号V1.0修订历史1概述本文档制定了XX数据仓库中数据库对象的命名规范（用户、表、视图、存储过程、函数、表分区、主键、索引、序列等）、数据库编程规范，JAVA编程规范为系统设计和开发工作提供统一的命名标准，提高系统的规整性和代码的可读性，减轻维护工作量，提高工作效率。
2数据库对象命名规范2.1层次划分数据层级按照自己数据仓库规划的命名即可~2.2表、视图、存储过程、函数命名规范<对象类型><_模型层次><_主题><_对象描述>[_汇总类型][_存储类型]说明：<> 尖括号中的内容为必须项，适用于所有用户层对象[] 方括号中的内容为可选项，会因用户层及对象的不同而不同命名约束：数据库对象命名可能受最大长度限制,因此在实际命名中如果按照规范约定的命名方式存在超长的现象，需要开发人员灵活控制。
2.2.1对象类型<对象类型><_模型层次><_主题域><_对象描述>[_汇总类型][_存储类型]。
适用范围：所有用户层对象。
2.2.2模型层次<对象类型><_模型层次><_主题域><_对象描述>[_汇总类型][_存储类型]说明：对象属性一般为对象归属用户的简写。
适用范围：所有用户层对象。
可以参照自己的对象属性命名规范，对此不要求统一。
2.2.3主题域<对象类型><_模型层次><_主题域><_对象描述>[_汇总类型][_存储类型][_][序号或描述]说明：主题域是对数据进行大类划分，不同用户下的分类有所不同。
适用所有业务层；每个新增的业务主题均需到该规范备案登记。
2.2.4对象描述<对象类型><_模型层次><_主题域><_对象描述>[_汇总类型][_存储类型]◼适用范围：所有用户层对象；◼对象描述要求简洁准确，尽可能的直观表达对象的含义,通常包含业务+功能；如果是通用命名规则：<对象类型><_模型层次><_主题域><_对象描述>[_汇总类型][_存储类型]，这里的对象描述是多业务的合成体，这时不加业务。
第1章数据仓库建设方案（DOC32页）1.1 数据仓库总体架构专家系统接收增购项目车辆TCMS或者其他子系统通过车地通信传输的实时或者离线数据，通过一系列综合诊断分析，以各类报表图形或者信息推送的形式向用户展示分析结果。
针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。
根据专家系统数据仓库建设目标，结合系统数据业务规范，包含数据采集频率、数据采集量等有关因素，设计专家系统数据仓库架构如下：数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容：数据采集：负责从各业务自系统中汇合信息数据，系统支撑Kafka、Storm、Flume 及传统的ETL采集工具。
数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。
数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。
数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理与调度，并对外提供数据服务。
1.2 数据采集专家系统数据仓库数据采集包含两个部分内容：外部数据汇合、内部各层数据的提取与加载。
外部数据汇合是指从TCMS、车载子系统等外部信息系统汇合数据到专家数据仓库的操作型存储层（ODS）；内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。
1.2.1外部数据汇合专家数据仓库数据源包含列车监控与检测系统（TCMS）、车载子系统等有关子系统，数据采集的内容分为实时数据采集与定时数据采集两大类，实时数据采集要紧关于各项检测指标数据；非实时采集包含日检修数据等。
根据项目信息汇合要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。
本方案在数据采集架构使用Flume+Kafka+Storm的组合架构，使用Flume与ETL 工具作为Kafka的Producer，使用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。
dwd构建规则DWD构建规则随着互联网技术的发展，数据已经成为人们日常生活中不可或缺的一部分。
为了更好地管理和利用数据，数据仓库成为了企业和组织中的重要组成部分。
而数据仓库的构建规则被称为DWD（Data Warehouse Design）构建规则。
DWD构建规则是指在进行数据仓库设计和构建过程中需要遵循的一系列规则和原则。
这些规则旨在确保数据仓库的可靠性、可扩展性和易用性。
下面将介绍几个重要的DWD构建规则。
1. 高度冗余的数据模型：在数据仓库中，数据的冗余是被允许的。
通过将数据冗余存储，可以减少数据的访问时间，提高数据查询的性能。
同时，数据冗余还可以降低关联查询的复杂性，简化数据分析过程。
2. 维度建模：维度建模是数据仓库中最常用的建模技术之一。
维度建模以业务维度为核心，将数据按照业务维度进行划分和组织。
通过维度建模，可以更好地支持数据分析和决策支持系统的构建。
3. 规范化的事实表：事实表是数据仓库中存储事实数据的表格。
为了提高数据查询和分析的效率，事实表通常需要进行规范化处理。
规范化的事实表可以减少数据的冗余存储，提高数据的更新和维护效率。
4. 易于理解的命名规则：为了方便数据仓库的使用和维护，需要制定一个易于理解的命名规则。
命名规则应该能够清晰地表达数据的含义和用途，避免出现歧义和混淆。
5. 数据质量控制：数据仓库中的数据质量是非常重要的。
为了保证数据质量，需要进行数据清洗、去重和校验等工作。
同时，还需要建立数据质量监控机制，及时发现和修复数据质量问题。
6. 安全性和权限管理：数据仓库中存储着大量的敏感数据，因此安全性和权限管理非常重要。
需要建立合理的权限体系，限制对数据的访问和操作权限，确保数据的安全性和隐私保护。
7. 数据备份和恢复：数据仓库中的数据是企业的重要资产，需要进行定期的数据备份和恢复工作。
通过数据备份，可以保证数据的安全性和可靠性，防止数据丢失或损坏。
8. 性能调优和优化：数据仓库的性能对于数据分析和决策支持至关重要。
数据仓库国家标准规范最新随着信息技术的快速发展，数据仓库作为企业数据管理和分析的核心工具，其标准化建设对于确保数据的一致性、安全性和可扩展性至关重要。
以下是关于数据仓库国家标准规范的最新概述：# 数据仓库国家标准规范最新引言数据仓库国家标准规范旨在为企业提供一个统一的数据管理框架，以支持数据的集成、存储、管理和分析。
这些规范有助于提升数据处理的效率，降低运营成本，并确保数据的准确性和可靠性。
1. 数据定义和分类- 明确数据的定义，包括结构化数据和非结构化数据。
- 根据业务需求和数据特性，对数据进行合理分类。
2. 数据集成- 规定数据集成的方法和流程，确保数据源的多样性和数据的一致性。
- 采用ETL（Extract, Transform, Load）等技术实现数据的抽取、清洗和加载。
3. 数据存储- 规定数据存储的格式和结构，支持关系型数据库和非关系型数据库的存储需求。
- 确保数据存储的安全性，包括数据备份和灾难恢复机制。
4. 数据质量管理- 制定数据质量标准，包括数据的准确性、完整性、一致性和时效性。
- 实施数据质量监控和评估机制，及时发现并纠正数据问题。
5. 数据安全与隐私保护- 规定数据访问控制和权限管理，确保数据的安全性。
- 遵守相关的数据保护法规，保护个人隐私和敏感信息。
6. 数据分析与报告- 规定数据分析的方法和工具，支持高级分析和数据挖掘。
- 制定报告生成的标准格式，确保报告的一致性和可读性。
7. 数据治理- 明确数据治理的职责和流程，包括数据的所有权、使用权和责任。
- 建立数据治理委员会，负责监督和指导数据仓库的建设和维护。
8. 技术标准和接口规范- 规定数据仓库的技术架构和接口标准，确保系统的兼容性和扩展性。
- 支持开放标准和API，促进数据的共享和互操作。
结语数据仓库国家标准规范的最新发展，为企业提供了一个坚实的数据管理基础。
通过遵循这些规范，企业能够更有效地利用数据资源，提升决策质量和业务竞争力。
数据仓库模型建设规范1.概述数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。
物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。
数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。
为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。
2.数聚模型架构在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。
2.1.数据架构图2.2.架构工作方法规范2.3.准备层L02.3.1.主要数据结构临时表：从数据源抽取，直接落地到临时表。
临时表总是保存这次抽取的数据，不保留历史数据。
也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话，就是自从上次修改后的数据。
接口表：从临时表，经过清洗、转换到达接口表。
接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。
接口表里面也是源系统整个表的数据。
转换表：为了进行清洗和转换建立的中间辅助表。
2.3.2.命名规范临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER接口表：L0_DCI_业务主题_具体业务表举例：L0_DCI_SALES_SALESORDER转换表：L0_MAP_具体业务表举例：L0_MAP_SALES2.3.3.开发工作●开发数据抽取接口，落地TMP区●开发数据清洗转换程序，落地DCI区，多源系统进行合并●开发数据装载程序，装载到L1层2.4.原子层L12.4.1.主要数据结构维度表：整个数据仓库一致的维度代码表：维度属性，非维度代码等。
原子事实表：根据业务主题，形成原子事实表汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。
2.4.2.命名规范维度表：DW_DIM_维度。
举例：组织维 DW_DIM_ORG 日期维 DW_DIM_DATE.代码表：DW_CODE_代码。
举例：性别 DW_CODE_GENDER原子事实表：L1_DW_FACT_分析主题_具体分析汇总事实表：L1_DM_FACT_分析主题_具体分析2.4.3.开发工作●维护聚集。
●衍生计算，二次指标计算。
2.5.应用层L22.5.1.主要数据结构宽表：根据需求，从L1层抽取成宽表，表现形式为固定报表，仪表盘等等。
立方体：根据分析主题，从L1生成OLAP立方体。
视图：根据需要，从L1，L0层产生L2层的视图。
前端应用，不仅仅可以利用L2层的数据结构，还可以利用L1层的数据结构。
对于源系统，还可以利用L0层的DCI区数据，可以做详单和明细查询。
2.5.2.命名规范宽表： L2_FACT_【应用主题】_【分析主题】_应用。
举例：L2_FACT_FIN_ZCFZB (财务->资产负债表)立方体：根据分析主题，从L1生成OLAP立方体。
视图：根据需要，从L1，L0层产生L2层的视图。
如明细单。
举例：L2_VIEW_原L1层表。
2.5.3.开发工作数据从L1层经过计算，汇总，根据前端分析需求，形成可以有效支撑前端应用查询的结构。
3.建模方法要成功地建立一个数据仓库，必须有一个合理的数据模型。
数据仓库建模在业务需求分析之后开始，是数据仓库构造的正式开始。
在创建数据仓库的数据模型时应考虑: 满足不同层次、用户的需求;兼顾查询效率与数据粒度的需求;支持用户需求变化;避免业务运营系统性能影响;提供可扩展性。
数据模型的可扩展性决定了数据仓库对新的需求的适应能力，建模既要考虑眼前的信息需求，也要考虑未来的需求。
目前两类主流的数据仓库模型分别是由Inmon提出的企业级数据仓库模型和由Kimball提出的多维模型。
Inmon提出的企业级数据仓库模型采用第三范式（3NF），先建立企业级数据仓库，再在其上开发具体的应用。
企业级数据仓库固然是我们所追求的目标，但在缺乏足够的技术力量和数据仓库建设经验的情况下，按照这种模型设计的系统建设过程长，周期长，难度大，风险大，容易失败。
这种模型的优点是信息全面、系统灵活。
由于采用了第三范式，数据存储冗余度低、数据组织结构性好、反映的业务主题能力强以及具有较好的业务扩展性等，但同时会存在大量的数据表，表之间的联系比较多，也比较复杂，跨表操作多，查询效率较低，对数据仓库系统的硬件性能要求高等问题。
另一方面，数据模式复杂，不容易理解，对于一般计算机用户来说，增加了理解数据表的困难。
Kimball提出的多维模型降低了范式化，以分析主题为基本框架来组织数据。
以维模型开发分析主题，这样能够快速实施，迅速获得投资回报，在取得实际效果的基础上，再逐渐增加应用主题，循序渐进，积累经验，逐步建成企业级数据仓库。
这也可以说是采用总线型结构先建立数据集市，使所有的数据集市具有统一的维定义和一致的业务事实，这种方法融合了自下而上和自上而下两种设计方法的思想。
这种模型的优点是查询速度快，做报表也快;缺点是由于存在大量的预处理，其建模过程相对来说就比较慢。
当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。
由于事实表的主码由所有维表的主码组成，所以这种维的变动将是非常复杂、非常耗时的。
而且信息不够全面、系统欠灵活、数据冗余多。
本规范我们主要针对维度建模的方法来阐述规范。
3.1.维度建模多维数据建模以直观的方式组织数据，并支持高性能的数据访问。
每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。
多维模型最常见的是星形模式。
在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。
位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。
每个指标实体代表一系列相关事实，完成一项指定的功能。
位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。
每个维表有自己的属性，维表和事实表通过关键字相关联。
使用星形模式主要有两方面的原因:提高查询的效率。
采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。
同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。
对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。
3.2.建模步骤第一步：选取建模的业务过程设计过程的第一步是确定要建模的业务过程或者度量事件。
业务过程是在业务需求收集过程明确下来。
在很多的生产活动中，存在着很多价值链，这些价值链就是有一系列的业务过程来组成的。
比如在供应链管理中。
存在着下面的业务过程：原材料购买原材料交货原材料库存材料账单生产制造将产品运到仓库制成品库存客户订单为客户送货货品计价付款退货第二步：定义模型的粒度业务过程被确定下来后，就建模师就必须声明事实表的粒度。
清楚地定义事实表的行到底代表什么在提出业务过程维度模型的过程至关重要。
如果没有在事实表的粒度上达成一致，那么设计过程就不可能成功地向前推进。
第三步：选定维度一旦事实表的粒度已经稳固地确定下来，对维的选择就相当简单了。
也正是在此时，就可以开始考虑外键的问题了。
一般来说，粒度本身就能够确定一个基本或者最小的维度集合，设计过程就是在此基础上添加其他维。
这些维在已经声明的事实表粒度都有一个唯一对应的值。
第四步：确定事实四步设计过程的最后一步是仔细选择适用于业务过程的事实和指标。
事实可以从度量事件中采用物理手段捕捉，或者也可以从这些度量中导出。
对于事实表粒度来说，每个事实都是必须设计存在的，不要将那些明确声明的粒度不相匹配的其他时间段的事实或者其他细节层次的事实混杂进来。
4.维度表设计维度表包含内容：1)代理键：整型，不可重复，唯一标识每一条记录，不包含任何商业信息。
（必选）2)代理键有效开始时间和结束时间。
（必选）3)当前有效标志。
（必选）4)主键：传统意义的业务键，包含相应的商业信息，如员工编号。
（必选）5)名称：数据分析时显示的内容，如员工名称等；（必选）6)排序键：自定义序列。
（可选）7)自定义汇总：利用自定义表达式进行特定的数据运算。
可选）8)父键：父子维度中用来标识主键的上级。
（可选）9)一元运算符：在父子维度中用来定义上下级的汇总关系。
（可选）(详细)10)属性：属性包含有关维度的信息。
例如，Customer 维度可以包含 Name、PhoneNumber、Gender、City、State 等属性。
属性通过属性层次结构显示出来。
维度中的属性层次结构同时包含可选的 (All) 级别和该属性的非重复成员。
例如，Customer 维度可以包含具有两个级别的 Name 属性层次结构：(All) 级别以及为每个姓名包含一个成员的级别。
父子层次结构的处理方式有所不同。
属性不一定要具有属性层次结构。
如果未创建属性层次结构，多维数据集的空间将与属性无关。
例如，通常不会为 Phone Number 属性创建属性层次结构，因为通常不会按电话号码导航维度。
如果没有为属性创建属性层次结构，则该属性可用作成员属性，但不能用作用户层次结构中的级别。
属性可以通过前端展示软件进行展现。
（可选）11)属性层次结构：属性层次结构完全定义多维数据集的空间。
多维数据集是由多维数据集的属性层次结构的交集产生的多维空间。
（可选）4.1.时间维度时间维度是必不可少的一个维度，可以参考如下的模板：4.2.层级维度层级维度也是我们模型设计最常遇见的维度，比如组织结构，区域，产品树，行业结构等等。
在设计时，可以采用如下模板：针对数据存储时，采用自关联的结构：针对数据展现时，将自关联的结构展开，以列存储层次：根据需要可以把组织层级具体化。
4.3.缓慢变化维缓慢变化维定义数据会发生缓慢变化的维度就叫”缓慢变化维”。
