维度表
维度表（Dimension Table）是数据仓库中描述业务过程中各种维度信息的表，用于提供上下文和描述性信息，以丰富事实数据的分析
维度表是维度建模的灵魂所在，在维度表设计中碰到的问题（比如维度变化、维度层次、维度一致性、维度整合和拆分等）都会直接关系到维度建模的好坏，因此良好的维表设计就显得至关重要，今天就让我们就一起来探究下关于维表设计的相关概念和一些技术。
前面我们介绍了数仓建模中的事实表，具体可以见数仓建模—事实表,除了事实表之外，我们也提到了宽表，可以看数仓建模—宽表的设计,今天我们介绍一下数仓中的维度表，以及在维度表设计和开发过程中，容易遇到的一些问题，开始之前我们先看一下如何识别维度，也就是什么是维度，只有正确的识别出维度，我们才能设计出维度表。
识别维度
在实际维度建模过程中，我们首选需要解决的问题就是到底哪些是维度或者什么事维度，维度的定义是什么，其实维度的定义很见到就是我们看待事物的角度，或者是我们衡量事实的粒度。
其实关于什么是维度，每个人都能回答出几个答案
-
维度是描述事实的场景
-
维度是字符串，事实是数字
-
维度是数据分析的入口
-
维度是数据的灵魂
-
维度是描述事实的上下文
-
维度是可group by的分组的
-
维度是可写where限制条件的
-
…
在实际维度建模过程，清晰识别维度是非常关键，维度是数据分析的入口，保证数据仓库模型通用性、易用性和回答业务用户范围前提条件之一。
kimball认为，维度建模首先会将现实情况划分为测量和上下文开始，通常将指标的度量称之为“事实”，将产生度量的环境称之为“维度”。
度量离开了维度或上下文也没有意义的，如给一个数字 960，我们是无法知道这个数字的意义。
但是，一旦给这个度量添加了上下文，其就有了意义，例如我国的国土面积是960万平方公里，其实这里还反映了一个问题那就是单位，既然是度量那就会有度量单位，所以我们在数据分析的时候要做一些操作例如单位的转换。
维度是事实的上下文，没有维度的事实是没有意义的，或者说是维度是我们看待数据的视角，下面我们还是通过一个小的例子，来看一下
“昨天早上张三在京东花费200元买了一个书包”, 这里时间维度(昨天早上)、地点维度(京东)、商品维度(书包)
维度是数字的主体，例如这里什么是960，中国的国土面积是960万平方公里，数字是维度的度量。
维度表
前面了解了如何识别维度，下面我们看一下维度表。
维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的描述性属性，属性一般为文本性、描述性的，这里的客观存在的事物和它的描述就是维度，这也就是为什么维度本身也会带有度量的原因，例如我们的用户的年龄是存放在维度表中的，而不是事实表，虽然它是一个度量。
维度建模的核心是数据可以抽象为事实和维度，维度即观察事物的角度，事实某一粒度下的度量词。
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，维度表通常比较宽，是扁平型非规范表，包含大量的稳定的文本属性和数值属性。
维度表设计
维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成维度属性的优劣，决定了维度是用的方便性，成为数据仓库易用性的关键。
数据仓库的能力直接与维度属性的质量和深度成正比，其实这句话说明了维度表的重要性，维度设计的不好，数仓的数据服务能力就不好，具体表现为数据不准确、
