目录
- 四、数据仓库的设计
- (一)需求分析
- (二)概念设计
- (三)逻辑设计
- (四)物理设计
四、数据仓库的设计
数据仓库的设计包括需求分析、概念设计、逻辑设计和物理设计四个阶段,其设计工作一般由项目中标的软件企业负责完成。项目的投资方和用户通常需要密切配合软件企业的需求调查和设计工作,以确保设计结果符合投资方和用户的决策分析需求。
(一)需求分析
1、需求调查
- 需求调查目的:了解企业决策的主题需求以及支持这些主题的数据来
- 需求调查对象:企业或事业单位的中高层管理者以及决策分析人员。
- 需求调查过程:围绕数据仓库的开发目标,实施范围,询问或征集他在管理决策中最关心问题:你每天(周/月)最需要知道哪些统计数据,是否还需要客户、城市等其它统计数据;你经常参阅或使用的统计分析图表有哪些,每张图表通常在什么时间使用,所有这些统计图表需要哪些部门的数据等,同时把企业工作中使用的这些统计分析图表收集起来,作为需求分析的原始资料。
- 需求调查方法:个别交谈,也可以是小型会议,还可以预先设计一份调查问卷,并分发给有关人员填写后收回。
2、分析整理
(1)确定主题
明确哪些主题对于企业决策是最有价值的?用户希望从哪些角度(维度)观察每一个主题?每个维度有哪些维层次?每个维层次又有哪些维成员?各个地区需要哪些信息来制定决策?
(2)确定数据源
哪些数据源(操作型)与决策主题有关?数据源中哪些数据列与决策主题有关?决策主题需要怎样的数据细节程度?
(3)估计数据量
根据主题需要的数据源行数、属性列数来估计数据仓库的数据总量大概有多少。
(4)确定抽取频率
决策支持所需的数据增量抽取的频率是多少,是每小时、每天还是每周?数据仓库中保留数据的时间区间要多长,是5年还是10年?过期数据如何处理,直接删除还是转到其它存储介质?
(5)确定关键性能指标
数据仓库查询分析有哪些关键的性能指标?如何评价和监控这些关键指标?数据仓库的预期用途在哪些方面?对规划中的数据仓库重点要考虑什么?
3、需求说明
在需求调查和分析整理基础上,依据一定的规范撰写需求分析说明书。其主要内容有
(1)数据源:包括数据源的数据结构,数据源的位置,数据源的计算机环境,可用的历史数据,数据抽取方案;
(2)数据转换:数据仓库中的数据为决策分析服务,而数据源所在系统的数据为业务处理服务,因此,需求说明书需要描述如何正确地将这些数据源转换成适合数据仓库存储的数据;
(3)数据存储:数据仓库所需数据的详细程度,即数据所在维的最低层次,还包括关于存储需求足够的信息,估计数据仓库需要多少历史和存档数据。
例3-1 以 “某市警务数据仓库系统” 实例为背景,简单介绍需求分析所做的主要工作。
需求调查:
通过与公安派出所等有关领导、治安管理负责人等进行需求调查后发现,他们经常,特别是在重大节假日期间,希望了解并掌握如下一些与决策主题相关的统计分析数据。
(1)最近几天或者一周,在指定派出所或公安分局辖区内宾馆住宿的旅客主要从哪些地区而来;
(2)最近几天或者一周,在指定派出所或公安分局辖区内宾馆住宿的人中有没有犯罪前科人员,他们所犯前科类型是什么(大类、小类还是子类)?
(3)最近几天或者一周,在指定派出所辖区宾馆住宿的人次,平均住宿天数等;
(4)以上问题还可能是以小时为单位的查询,比如周六晚上11点至凌晨2点之间辖区内的宾馆入住人员数量等。
(5)数据来源于6个不同的数据库应用管理系统:户籍管理系统(称为常住人口),暂住人口管理系统,酒店客房管理系统、治安管理应用系统、辖区旅馆基本信息管理系统等。
分析整理:
(1)确定主题
警务数据仓库的首个主题,并将其命名为 “入住”,并用 Hotel 作为别名。
① 主题涉及的事实有 “入住人次” 和 “入住天数” 等。相关的维度主要是入住宾馆的 “人员”,“时间” 和所入住的 “宾馆”。
② 旅客的来源地,可以从人员的户口所在地或籍贯信息获得,而旅馆所属治安管理的辖区从旅馆基本信息的所属派出所地址信息中找到。
(2)确定数据源
根据确定的主题和警务信息管理处提供的可用原始数据库,我们确定了主题所需的数据源有8张基本表。虽然它们分别来自不同的应用系统,但为了方便,我们将它们统一放在一个名为 OLTPHotel 的数据库中。
① 旅馆数据源表 LGXX,共有65个属性描述旅馆的名称、电话、地址等基本信息。
② 常住人口数据源表 CZRK,共有128个属性描述常住人口的身份证号、姓名、性别等公民基本信息。
③ 宾馆入住数据源表 LGRZ,共有34个属性描述旅客身份证号、姓名、性别、入住时间、离店时间等入住宾馆的基本信息。
④ 暂住人口数据源表 ZZRK,共有98个属性描述暂住人口的暂住证号、身份证号、姓名、性别等暂住人员基本信息。
⑤ 犯罪类型数据源表 FZLX,共有18属性描述我国刑法规定的犯罪类型,有大类、小类、子类和具体罪行名称等。
⑥ 所属辖区数据源表 SSXQ,共有12个属性描述了旅客或暂住人口户口所在的省市县名称等基本信息。
⑦ 派出所数据源表 PCS,共有10个属性描述了派出所的名称、编码、地址等基本信息。
⑧ 人员前科数据源表 SSXQ,共有8个属性描述了犯罪人员的身份证号、犯罪类型和时间等基本信息。
由此可知,事务处理数据库系统中记录的旅馆信息、人员信息非常细致,比如旅馆数据源表有65个属性,常住人口数据源表有128个属性,暂住人口数据源表也有98个属性。许多属性并不是决策分析需要的数据属性或观察数据的维度,我们从各个数据源表中筛选出与主题可能有关的属性(表3-1至3-4)。
(3)确定抽取频率
由于决策分析查询经常需要最近几天或一周的统计数据,因此,我们将旅客宾馆入住数据的抽取工作,设计为每天执行一次抽取。
(二)概念设计
概念模型设计任务:将需求分析阶段确定的各个主题,转换为概念数据模型表示,并为这些主题的逻辑数据模型设计奠定基础。主要有如下3个步骤。
(1)设计每个主题的多维数据模型,包括事实和维度名称;
(2)设计每个维的层次及其名称;
(3)设计每个主题的元数据,包括事实、维度等的类型、长度等。
例3-2 请根据例 3-1需求分析结果,完成警务数据仓库 “入住” 主题的概念设计。
解: 按照概念设计的步骤分别设计如下。
1、设计多维数据模型
根据例 3-1的需求调查和分析结果,我们可以设计 “入住” 主题的多维数据模型如下:
- “入住” 主题的多维数据模型有人员、时间和宾馆3个维度和入住人次和入住天数两个宾馆入住的事实
- 因入住人次可以通过入住天数计算获得,即只要入住天数非零,入住人次的计数为1。得 “入住” 主题的最终多维数据模型:
2、确定维度层次
(1)人员维的层次
人员维度本质上是户口所辖这个地址维度上最底层的维成员,故层次关系设计为:人员→区县→地市→省份→国家。
(2)时间维的层次
警务查询需要指定小时区间的入住统计,因此时间维度最底层的维成员以小时为单位,这样时间维度的层次有两种情况:
① 小时→天→月→季→年。
② 小时→天→周→年。
(3)宾馆维的层次
旅馆维度是地址所属辖区这个治安维度的最底层维成员,因此,旅馆维度的层次为:旅馆→区县→地市→省份→国家。宾馆维是治安管理的对象,因此,旅馆维也称为治安维。另外,宾馆是地理位置上的具体单位,也是一种地理维度。
3、元数据设计
多维数据模型的元数据,主要是多维数据模型中描述维度和事实的属性类型、长度以及取值范围等。
在设计时应尽可能的参照数据源中对应属性的类型、长度和取值范围。在一些特别情况下,就需要重新确定属性的类型或长度。
例如,人员的性别,它的数据源包括常住人口中的性别(长度为2,取值{男、女})和暂住人口(长度为1,取值{1,0})和其它地方来本市辖区旅行的人员。虽然性别属性都是字符型,但因为长度不一致,最后将多维数据模型中人员的性别属性设计为字符型,且统一规定长度为1,取值范围 {1,0}。
(三)逻辑设计
将数据仓库的逻辑模型转化成具体计算机系统能够支持的逻辑模型,与具体的 DWMS 所支持的数据模型。概念数据模型表示的数据一般可以方便地转换为逻辑数据模型表示。当前数据仓库大都建立在关系数据仓库管理系统(RDWMS,如 SQL Server 等)之上,下面介绍 RDWMS 中的数据仓库逻辑设计。
1、选定逻辑模型
每个主题的概念模型为多维数据集,而多维数据集在关系数据库管理系统中可用星形模型或雪花模型表示。逻辑模型设计的第一步:采用星形模型/雪花模型???
2、设计维度表的关系模式
- 设计任务:每个维度表需要的属性(包括主键和外键),属性的类型、长度和取值范围等。
- 雪花模型:就要增加详细类别表的设计,以及这些维度表、详细类别表中属性与数据源中对应属性之间的关系和转换方法。
3、设计事实表的关系模式
同样是设计事实表需要的属性、类型、长度和取值范围等,以及它们与数据源中属性之间的对应关系和转换方法。
4、设计详细类别表
如果某个主题的逻辑模型选用雪花模型,则还需要设计详细类别表需要的属性(包括主键),属性的类型、长度和取值范围等,也包括这些属性与数据源中对应表的属性之间的对应关系和转换方法。
例 3-3 请用例 3-2的概念设计结果,完成 “入住” 主题的逻辑设计。
解:
(1)选定逻辑模型
由于 “入住” 主题的概念模型为如下的三维数组,即
因此,其对应的逻辑模型有1个事实为入住天数;3个维度:宾馆、人员、时间。即 “入住” 主题需要1个事实表,至少需要宾馆、人员和时间3个维度表。
① 人员维度表的户口属辖是地址信息,宾馆的治安所辖地由派出所地址信息决定,因此可将其从人员维度表和派出所信息表中分解出来形成一个详细类别表,即地址表,并通过 “主键-外键” 实现地址表与人员维度表的联系,而宾馆则通过与派出所信息表与地址表联系起来。
② 通过以上分析讨论可知,我们选定雪花模型作为 “入住” 主题的逻辑模型为宜。
(2)设计维度表
① 旅馆维度表:
② 人员维度表-暂住人口:
③ 时间维度表:
从时间维度表可知,时间维表只有原始时间属性与旅馆入住数据源表的入住时间和离店时间有对应关系,其它属性都由入住时间和离店时间派生而得。
派生方法就是利用函数 DATEPART(”Year”,RZSJ)
在入住时间 RZSJ 中取出年 (Year) 作为 CYear 属性,同理取出季(Quarter)、月(Month)、周(Week)、日(Day)、时(Hour)等,分别作为 CQuarter、CMonth、CWeek、CDay、CHour 属性。
同时将 CQuarter、CMonth、CWeek、CDay、CHour 分别作为 T_CQuarter、T_CMonth、T_CWeek、T_CDay、T_CHour 变量,由它们派生出:DateKey = T_CYear+RIGHT(“0”+T_Month,2) + RIGHT(“0”+T_Day,2) + RIGHT(“0”+T_Hour,2)
(3)设计住宿事实表
居住天数可由入住时间、离店时间计算得到,而入住时间键和离店时间键分别由入住时间、离店时间派生而得。
InDateKey = RZ_CYearB + RIGHT("0"+RZ_CMonthB,2) + RIGHT("0"+RZ_CDayB,2) + RIGHT("0"+RZ_CHourB,2)
OutDateKey = LD_CYearB + RIGHT("0"+LD_CMonthB,2) + RIGHT("0"+LD_CDayB,2) ++ RIGHT("0"+LD_CHourB,2)
(4)设计详细类别表
① 派出所维度表:
② 地址维度表:
“入住” 主题的逻辑模型——雪花模型表示:
(四)物理设计
数据仓库在物理设备上的存储结构和存取方法就称为数据仓库的物理结构或物理数据模型(Physical Data Model),它是描述数据仓库在存储介质上组织结构的数据模型,不但与具体的 DWMS 有关,而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。
设计人员必须全面了解所选用的数据仓库管理系统,特别是存储结构和存取方法,了解数据环境,数据的使用频度、使用方式、数据规模以及响应时间要求等,它们都是对时间和空间效率进行平衡和优化的重要依据。设计人员还要了解外部存储设备的特性,如分块原则,块大小的规定,设备的 I/O 特性等。
商品化关系数据仓库管理系统(RDWMS)作为数据仓库的管理平台,数据仓库的大量内部物理结构都由 RDBMS 自动完成,只留有少量的、用户可参与的物理结构设计内容。
主要介绍如下几种物理设计内容。
1、数据存储结构设计
通常,DWMS 提供了多种存储结构供设计人员选用。不同的存储结构有不同的实现方式,各有各的适用范围和优缺点,设计人员应该在综合考虑存取时间、存储空间和维护代价等因素的基础上,确定并选择合适的存储结构。
2、数据索引策略设计
设计人员可以考虑对各个数据存储建立专用的、复杂的索引,如位图索引、广义索引、链接索引等,以获得最高的存取效率。数据仓库中的数据很少更新的,每个索引结构都是比较稳定的,一旦建立就几乎不需要再对这些索引进行维护。
数据仓库是只读数据环境,建立索引可以获得更好的灵活性,对提高查询性能极为有利。但一张表建立的索引过多,可能导致数据加载时间的延长,因此,建立索引的数量也需要进行综合的权衡。应按照索引使用的频率由高到低的顺序逐步建立,直到某一索引建立后反而使数据加载的时间更长时,就结束索引的添加,即不再建立新的索引。
开始一般是对主键和外键建立索引,通常不需要添加更多的其它索引。在DW使用过程中如果发现响应时间太长,则按照实际需要逐步建立其它索引,这样就会避免一次建立大量索引带来的不利后果。
如果某个事实表占用空间过大,而且又需要另外增加索引,则可以考虑将该表进行分割处理。如果一个事实表中所用到的属性都在索引文件中,就不必访问事实表,只要访问索引就可以达到访问数据的目的,以此来减少 I/O 操作。如果事实表太大,并且经常要对它进行长时间的扫描查询,那么就要考虑添加一张概括表(粒度粗一些的表)以减少数据的扫描任务。
3、数据存放位置设计
数据仓库中,同一个主题的数据并不要求存放在相同的介质上。常常需要按照数据的重要性、使用频率以及对响应时间的要求,将不同类型的数据分别存储在不同的存储设备中。
高速——硬盘;低速——磁带/光盘;镜像/冗余存储提高效率?
总的来说,在确定数据存放位置时一般应遵循以下几个原则。
(1)应该把经常需要连接操作的几张表存放在不同的存储设备上,这样可以利用存储设备的并行操作功能加快数据查询的速度。
(2)如果几台服务器之间的连接可能造成严重的网络数据传输负担,则可以考虑在服务器之间复制表格,以减少不同服务器之间因数据连接导致的网络数据传输负担。
(3)考虑把整个企业共享的细节数据放在主机或其它集中式服务器上,以提高这些共享数据的使用速度。
(4)不要把表格和它们的索引放在同一设备上。可将索引存放在高速存储设备上,表格存放在一般存储设备上,以加快查询速度。
4、数据存储分配设计
商品化数据仓库管理系统提供了一些存储分配的参数供设计者进行物理优化处理,比如块的尺寸、缓冲区的大小和个数等。