维度属性事实表和纬度表概述
在本篇文章中,我们重要介绍维度属性的内容,自我感觉有个不错的建议和大家分享下
现实表和纬度表概述
现实表
在多维数据仓库中,保存度值量的细详值或现实的表称为“现实表”。现实数据表平日含包量大的行。现实数据表的重要特点是含包字数数据(现实),并且这些字数信息可以汇总,以供给有关单位作为历史的数据,每一个现实数据表含包一个由多个部组分成的索引,该索引含包作为键外的关相性纬度表的主键,而维度表含包现实录记的特性。现实数据表不应该含包描述性的信息,也不应该含包除字数度量段字及使现实与纬度表中对应项的关相索引段字以外的任何数据。
一个按照州、产品和月份分划的售销量和售销额存储的现实表有5个列,念概上与上面的示例相似。
Sate |
Product |
Mouth |
Units |
Dollars |
WA |
Mountain-100 |
January |
3 |
7.95 |
WA |
Cable Lock |
January |
4 |
7.32 |
OR |
Mountain-100 |
January |
3 |
7.95 |
OR |
Cable Lock |
January |
4 |
7.32 |
WA |
Mountain-100 |
February |
16 |
42.40 |
在这些现实表的示例数据行中,前3个列——州、产品和月份——为键值列。剩下的两个列——售销额和售销量——为度值量。现实表中的每一个列平日要么是键值列,要么是度值量列,但也可能含包其他参考目标的列——例如采购订单号或者发票号。
现实表中,每一个度值量都有一个列。不同现实表将有不同的度值量。一个售销数据仓库可能含有这两个度值量列:售销额和售销量。一个现场信息数据仓库可能含包3个度值量列:总量、分钟数和瑕疵数。创立报表时,可以认为度值量构成了一个外额的维度。即可以把售销额和售销量作为并列的列标题,或者也可以把它们作为行标题。然而在现实表中,每一个度值量都作为一个独自的列示显。
后面表格中的示例数据行示显了现实表的念概布局。现实是现实表几乎总会用使一个整值数来表现(维度)员成,而不用使描述性的名称。因为现实表往往会含包数量多得没法象想的数据行——在一个中等巨细的数据仓库中,现实表动辄含包上百万行数据——用使数整键值可以有效地减小现实表的巨细。现实表真正的布局如下所示。
STATE_ID |
PROD_ID |
Month |
Sales_Units |
Sales_Dollars |
1 |
347 |
1 |
3 |
7.95 |
1 |
447 |
1 |
4 |
7.32 |
2 |
347 |
1 |
3 |
7.95 |
2 |
447 |
1 |
4 |
7.32 |
1 |
347 |
2 |
16 |
42.40 |
在现实表中用使数整键值时,维度员成的名称须要放到另一种表中——也就是维度表。平日,现实表中的每一个维度都有一个维度表。
维度表
维度表维度表可以看做是用户来分析数据的窗口,纬度表中含包现实数据表中现实录记的特性,有些特性供给描述性信息,有些特性指定如何汇总现实数据表数据,以便为分析者供给用有的信息,维度表含包帮助汇总数据的特性的层次结构。例如,含包产品信息的维度表平日含包将产品分为食品、饮料、非消费品等多少类的层次结构,这些产品中的每一类进一步多次细分,直到各产品到达最低别级。
在维度表中,每一个表都含包独立于其他维度表的现实特性,例如,客户维度表含包有关客户的数据。维度表中的列段字可以将信息分为不同层次的结构级。
维度表含包了维度的每一个员成的特定名称。维度员成的名称称为“属性”(Attribute)。设假Product维度中有3种产品,那么维度表将如下所示。
PROD_ID |
Product_Name |
347 |
Mountain-100 |
339 |
Road-650 |
447 |
Cable Lock |
产品名称是产品员成的一个属性。因为维度表中的Product ID与现实表中的Product ID相配匹,称为“键属性”。因为每一个Product ID只有一个Product Name,示显时用名称来代替整值数,所以它仍然被认为是键属性的一部份。
在数据仓库中,维度表中的键属性必须为维度的每一个员成含包一个对应的独一值。用关系型数据库语术描述就是,键属性称为主键列。每一个维度表中的主键值都与任何关相的现实表中的键值关相。在维度表中涌现一次的每一个键值都会在现实表中涌现多次。例如Mountain-100的Product ID 347只在一个维度表数据行中涌现,但它会涌当初多个现实表数据行中。这称为一对多关系。在现实表中,键值列(它是一对多关系的“多”的一方)称为键外列。关系型数据库用使配匹的主键列(在维度表中)和键外列(在现实表中)值来联接维度表到现实表。
把维度信息移动到一个独自的表中,除了使得现实表更小外,还有外额的长处——可认为每一个维度员成加添外额的信息。例如,维度表可能为每一个产品加添种类(Category)信息,如下所示。
PROD_ID |
Product_Name |
Category |
347 |
Mountain-100 |
Bikes |
339 |
Road-650 |
Bikes |
447 |
Cable Lock |
Accessories |
当初种类是产品的另一个属性。如果晓得Product ID,不但可以推断出Product Name,而且可以推断出Category。键属性的名称是能可独一的——因为每一个键只有一个名称,但其他属性不须要是独一的,例如Category属性可能会涌现好几次。这样一来,便可以创立按照产品和类别对现实表信息行进组分的报表。
除了名称外,维度表可以含包多许其他的属性。本质上,每一个属性都对应于维度表中的一个列。上面是带有其他外额属性的只有3个员成的Product维度表的示例。
PROD_ID |
Product_Name |
Category |
Color |
Size |
Price |
347 |
Mountain-100 |
Bikes |
Black |
44 |
782.99 |
339 |
Road-650 |
Bikes |
Silver |
48 |
3399.99 |
447 |
Cable Lock |
Accessories |
NA |
NA |
25.00 |
维度属性可是以可组分的,也可是以可不组分的。换句话就是,您否是见过按照哪个属性来组分度值量的报表?在我们的示例中,Category、Size和Color全都是可组分的属性。由此然自会联想到可能在某个报表中按照色颜、巨细或种类来组分售销额。但Price看起来不像是可组分的属性——少至它本身不是。在报表中可能会有一个更有义意的其他属性——例如Price Group,但价格本身化变太大,致使在报表上组分义意不大。同样地,按照Product Description属性在报表上行进组分义意也不大。在一个Customer维度中,City、Country、Gender和Marital Status都是可以在报表上按照它们行进有义意组分的属性,但Street Address或Nickname都应当是可不组分的。可不组分的属性平日称为员成属性(member property)。
某些可组分的属性可以合组起来创立一个然自层次结构(natural hierarchy)。例如设假Product有Category和Subcategory属性,在数多情况下,单个产品只会属于单个Subcategory,并且单个Subcategory只会属于单个Category。这将构成一个然自层次结构。在报表中,可能会示显Categories,然后许允用户从某个Category钻取到Subcategories,以及终最钻取到Products。
层次结构——或者说钻取径路——不一定要是然自的(例如,每一个低层次的员成会决议下一个高层次的员成)。例如,您可能会创立一个按照Color组分产品的报表,但许允用户根据每一个Color钻取到每一个不同的Size。因为报表的钻取能力,Color和Size构成了一个层次结构,但是根据Size却没有任何信息可以用来定断产品的Color将是什么。这是一个层次结构,但不是一个然自层次结构——但也不是说它是个非然自层次结构。Color和Size构成一个层次结构并没有什么不对,它只是这样一个单简的现实:同相的Size可以涌当初多个Color中。
文章结束给大家分享下程序员的一些笑话语录:
爱情观
爱情就是死循环,一旦执行就陷进去了。
爱上一个人,就是内存泄露--你永远释放不了。
真正爱上一个人的时候,那就是常量限定,永远不会改变。
女朋友就是私有变量,只有我这个类才能调用。
情人就是指针用的时候一定要注意,要不然就带来巨大的灾难。