（转摘）_《数据库设计入门经典》:通过分析进行规划与准备_9.3 理论应用于实践
9.3 理论应用于实践
作为本章(以及后3章)的提示，您需要努力地建立一个案例分析示例从而使理论应用到实践中。回忆一下本章开始的内容：案例分析包括一个虚拟的联机拍卖行。本节将完成案例分析的分析阶段。包括数据库模型所需要的内容及其包含的内容。
9.3.1 将分析应用于实践
正如您在本章开始所了解的那样，将数据库建模过程应用于实践的第一步是分析。分析是发现并限定公司所能做的收支相抵的行为。为了完成正确的分析，您需要记住以下内容：
● 公司目标
● 公司运作
● 业务规则
● 规划和时间表
● 预算
通过逐一检查列表中的选项，您已完成案例分析的分析阶段。下面的讨论将从联机拍卖行的公司目标开始；但是，这些目标一旦建立，很难再对它们进行修改。您需要在两个独立的上下文中对公司的操作和业务规则进行检查：一种上下文针对OLTP数据库，另一种则是针对数据仓库模型。在本节的最后，将会回到针对整个案例分析示例的规划、时间表和预算的讨论中。
因此，让我们找出联机拍卖行的真正目标。
9.3.2 公司目标
公司最重要的目标实际上是获取利润。毕竟，没有利润公司将无法生存！另外，软件的总体目标是为消费者提供服务。就联机拍卖行而言，消费者是指卖家和投标者。卖家为拍卖列出选项。投标者为了赢得拍卖，会对列出的项进行出价。
如果商业创意具有可行性，那么当给予用户合适的服务之后，在商业市场中的获胜机会将会变大。计算机系统应该为公司提供竞争中的优势。与脱机拍卖行相比，通过Internet，联机拍卖行很有可能获得更多的潜在用户。这样使拍卖网站有可能卖出大量的更为便宜的产品。很明显，佣金也会随之降低。毕竟，
Sotheby之类的世界知名拍卖行只拍卖百万美元以上的商品，例如：珍贵的艺术作品。联机拍卖行能够获得较好的收益，但是，与商品庞大的数量相比，它们的价格都很便宜。
因此，在卖家和买家之间，联机拍卖行具有很大的潜在市场。从技术上来说，这样做使多个用户能够分享数据库的可用容量。因此，OLTP数据库模型的结构是符合要求的。同样，这种结构对拍卖行(包括对许多销售委托人)明确未来的趋势也是有价值的。通过对归档数据集合的预测和预计，我们可以建立下一步的趋势和预测。采用专门的数据仓库数据库可以方便高效地存放归档数据。
公司的技术目标是为高度并发的OLTP数据库提供数据模型，并为I/O读写频繁的数据仓库提供数据模型。
另一个因素关注的是已经存在的软件和数据库模型，例如：已由联机拍卖行所使用的模型。如果公司已经计算机化，那么现有的软件和模型可以作为创建新软件的基础。
提示：
再次需要提醒的是：如果正在重写某个软件，那么现有在的软件是否是不合适的？如果是这样，原因何在？利用已存在软件的特性是否仅仅会将存在的问题带给新软件？
在处理两个不同的数据库模型之前，先让我们考虑联机拍卖行操作的定义方法。
追踪书面文档并与人交谈
分析某个公司的操作有很多方法：观察现有的系统(计算机化的或者其他形式的)并与它的员工进行交谈。
过去，大多数公司都没有计算机化，公司的员工需要把大量的时间花在简单的记录、装订和存放上。某些记录的内容可以提供公司操作的内部信息——
甚至包括表和字段、数据类型和特定表中特定字段的默认值。例如图9-1所示的发票。
图9-1 简单的纸质发票可以显示公司的行为
图9-1是购买某个联机零售商所提供商品的发票。这张发票非常基本，并且通过电子邮件发给买家。很明显，如果将该发票打印出来，将是内容一致的对等物(即为一张纸质发票)。从这张发票中可以分析出以下信息：
(1) 每张发票均有编号。
(2) 发票编号并不是数字的形式。它可能包含两个独立的编码，第一个编码是字母，另一个则是连续的数字。
(3) 根据特定的地址(图9-1的黑体所示)，该发票将会寄给某位客户。这里的地址是某位购买该商品的客户地址。
(4) QTY栏表明每张发票可以针对多个在同一时刻购买的同样商品。从逻辑上说，这种做法遵循的是每张发票可能包含多个不同项目的原则。
(5) 单个或多个QTY条目包含一个总共的数量。
(6) 销售税或者价值附加税(VAT)并不是永远适用的，但它却隐含在国际贸易和运输，或者是美国两个州之间的运输中。
(7) POSTAGE & HANDLING表示卖家运输的货物。卖家也可能从货物运输中获得小额利润，但这不在考虑范围之内。
(8) 在Web上快速搜索“D’ADDARIO ECB81-5 BASS
FLATWOUND”条目可以发现该联机零售商销售的是乐器的部分组件。当然，这个特定的零售商可以销售其他所有的商品，但是该特定的商品是一套五弦电吉他的直弦。
如图9-1所示的发票可以告诉我们关于该公司的8条信息。它甚至可以告诉我们公司所从事的业务或者主要的利润来源。这家公司销售的是乐器。关键在于：仅仅通过一张发票，就可以大体地猜测出公司的业务。我们甚至不需要与员工进行交谈、参观公司或是在Internet上搜索公司的业务。
与纸质信息一样，和人们进行交谈也很重要。通常，这些交谈会变成员工对所从事工作的长篇大论。我们需要让他们畅所欲言，并且他们最终会将自己做的每件事、其他人做的事情以及办公室政治和流言蜚语(您也许并不想听，但是某天这一信息也许会派上用场)都告诉我们。与这些人进行交谈同样会给我们带来许多书面信息，如图9-2所示。图9-2是另一种形式的发票，只是这一次有两项而不是一项。
图9-2 与联机零售商进行交易时，Internet上的可用发票
9.3.3 案例分析：OLTP数据库模型
本节将从针对联机拍卖行的OLTP数据库模型的分析和展示开始。
1. 建立公司运作
建立公司运作功能是对公司谋生手段的理解过程。例如，纸浆工厂需要从已经长成的森林里获取木材。这些木材被运输到附近的加工厂。然后由加工厂将木材加工成纸浆，最终生成纸张。
拍卖行的类别
由于联机拍卖行不能提供实物而是扮演销售代理人的角色,因此它只是一种媒介。卖家通过为拍卖行提供商品从而将该商品卖给任意的潜在买家。买家在特定的时间段内投标，直到产生最后的中标者。拍卖行通过对卖家收取列出拍卖商品的佣金来获取利润。
现在，分析的目的仅仅是建立联机拍卖行的运作过程。数据库模型的组成信息(静态数据)和数据库模型中流动的信息(事务数据)均没有确定。请注意这一阶段我们使用的是“信息”(而不是“数据”)。
分析联机拍卖行数据库模型的运作方面。我们可以获得许多类别层次：
● 主类别层次将所有列出的商品分成几种主类别，例如：乐器、图书、古董、收藏品、玩具和爱好。其他的类别将在稍后阶段进行详细说明。
提示：
到目前为止，您还没有关注到细节。换言之，现在还不需要深入考虑细节。让我们把注意力放到事实上来。
● 第二级类别层次是每种主类的子类别。例如，乐器类中可以包含二级类别项，即：铜管乐器、木管乐器以及弦乐器。
● 第三种或者第三级的类别层次是二级类别层次中的隐含的子类别。例如，铜管乐器可可以包含小号、长号和法国号等。
图9-3显示的是联机拍卖行的类别信息结构的简单图表。请注意第三层次的每种类别元素均有第二层次的类别元素作为父类，而第二层次类别都有主层次类别作为父类。另一个需要注意的方面是，并非所有的第二层次的类别元素都需要包含第三层次的项。
图9-3 作为数据库模型静态部分的静态类别信息
拍卖行的卖家列表
从本质上来说，拍卖行列表列出的是卖家正在拍卖站点上销售的商品。每一张列表都必须包含第二级和第三级类别：
●
每一张拍卖列表均包含可以获得卖家(出售该商品的个人或者组织)详细信息的链接。这些信息包括卖家的姓名和地址、商品的起始价以及运输细节(当完成拍卖列表后，联机拍卖行需要通过运输信息决定货物应该送达的接收人和地点)。
● 拍卖列表必须含有卖家，但不一定含有最终的买家。如果商品没有投标价格，那么表示没有买家购买此商品。
● 拍卖列表也包含获得其他子集的链接，这些子集是主要信息一对多的集合：
· 每一次的拍卖都需要有卖家的历史记录。该卖家的声誉是否良好？这部分内容由买家对与特定卖家进行交易时的感受组成。
· 每个拍卖选项需要包含特定拍卖物品的历史投标。对于每张拍卖列表而言，卖家和买家都需要查看某种拍卖商品过去的所有投标。
图9-4显示的是卖家和拍卖列表之间的关系以及与买家的历史交易记录。卖家不仅在一段时间内可以有一张或多张列表，在同一时刻也可以列出多个商品。根据投标者所希望购买的商品数目，存在着特殊的拍卖形式，使单个列表能够为多个可能的投标者列出多种商品。
图9-4 卖家、列表以及卖家历史(在数据模型中流动的动态信息)
拍卖行的买家
买家包含各种信息项：
● 买家应该拥有投标记录，以便让卖家判断自己是否在与声誉好的买家进行交易。对于卖家来说，谨慎的做法是避免接受过去有未付款记录的买家的投标。
● 拍卖站点需要存储买家的信息，例如姓名、地址、信用卡信息和信用价值。
图9-5显示的是买家、现有列表上的投标记录以及历史交易记录之间的关系。在列表的生存期中，任何列表都可以包含一个或多个投标。当拍卖完成并产生拍卖获胜者之后，就不再允许任何投标。列表可能不含有任何投标，在这一阶段可以将它再次列出。
图9-5 买家、列表、投标和买家历史(在数据库模型中流动的动态信息)
提示：
任何在拍卖中列出商品的个人和组织都可以购买商品。换句话说，个人或组织不仅能够列出需要拍卖的商品，也可以为商品投标(作为买家)。但是，数据库模型不能允许卖家对自己的商品进行投标。
拍卖行的总体结构
图9-6展示的是某个公司完整的运作结构的总体图。
图9-6 简单的联机拍卖行完整运作结构
最后需要注意的是：我们应该记住对联机拍卖行的公司运作活动的概要分析并不是必须要完成的任务。在任何软件开发项目中，需要记住的主要一点是：方法论中的步骤是重复的，甚至这些步骤的执行顺序也不用严格地遵守。例如，在分析的中期和业务规则的定义阶段，您完全可以返回去重新设计公司的运作部分，如图9-7所示。
图9-7 在分析方法中的重复步骤
2. 发现业务规则
因此，在开发商业应用程序之前，我们应该首先了解业务规则的内容。简而言之，针对商业的业务规则是一套功能规则，这些规则可用于描述业务的内容和运作过程，从本质上说，这些规则是对业务运作过程的半数学化的解释。正如前一节中为联机拍卖行所建立的规则那样，业务规则的实质内容是对公司操作活动的更精确的解释。
当把公司的业务规则应用到数据库模型中后，这些规则即成为数据库模型。业务规则可以是表、表之间的关系、甚至是数据库中的约束条件(除参照完整性约束之外)。事实上，与将业务规则应用到公司数据环境中相比，在初始的公司数据表中应用规范化操作是一种更加复杂的应用程序。规范化是业务规则的应用。
图9-8显示的是一些非常简单的业务规则示例。在图9-8中，针对拍卖列出许多乐器的类别。每种单独的乐器类别(例如：铜管乐器或者铜管项)都包含不同的乐器(例如：小号、长号或大号)。
图9-8 一对多的关系是一种业务规则
在图9-8中，通过表和表之间的关系，将多种乐器组成的项划分为单独表的行为正是一种创建业务规则的简单的表示方法。图9-8中的ERD不是标准的规范化，而是显示在不同表之间所创建的关系创建业务规则，或者公司运作功能的方法。在本例中，公司指的是为了联机拍卖行的销售，允许为乐器的销售进行列表的联机拍卖公司。
拍卖行的类别
图9-9显示的是图9-8中部分结构化的表元素的数据图。Guitar(吉他)类别包含两种乐器：Acoustic Guitar(原声吉他)和Electric
Guitar(电吉他)。Wind(管乐器)类别包含多种乐器。
图9-9 图9-8中的一些数据
在这一阶段，您可以采用在图9-3和图9-6中所建立的联机拍卖行的操作，并创建针对这些结构的ERD。正如在本章前面所提到的那样，业务规则是整个分析阶段的核心，它对已分析的内容和针对数据库模型设计所必须创建的内容均进行描述。数据库模型中业务规则的部分分析需要创建表及表之间的基本关系。
提示：
分析的总体目标仅仅是定义而不是精确地指明；例如，分析并不能描述地址需要的字段数，或是这些字段的数据类型。分析仅仅确定地址字段确实存在，以及需要地址信息的表。
从图9-3中所示的类别静态结构开始，图9-10中的ERD部分有效地符合类别层次结构，并且链接到包含拍卖列表的表。LISTING表包含主表的主要方面的所有细节——
即描述设计的明细表，包括对列表号的引用(LISTING#)、日期、价格、投标以及中标者的详细信息。
图9-10 图9-3的类别层次结构的ERD版本
正如在图9-10中所看到的那样，分析过程正在成为一种部分定义过程，该过程可以在不指定细节的条件下，为特定操作的不同属性定义字段。图9-11和图9-12显示的是在图9-10的ERD中表示的一些示例数据(包括代理键字段)。
图9-11 图9-10的ERD中的数据简图
图9-11显示的是左边数据的主要类别列表，包括Automotive(汽车)、Collectibles(收藏品)、以及Musical
Instrument(乐器)等条目。该表仅对名为Musical Instrument的二级类别进行扩展，图9-12中的模糊部分突出显示了对二级类别更详细的描述。
图9-12 图9-10的ERD中的数据简图
图9-12显示的是图9-11中所示的部分二级类别列表，突出显示的项通过三级类别和拍卖列表条目相联系。
拍卖行卖家列表
图9-13显示的是与拍卖列表有关的基本表结构——
卖家(在拍卖行销售物品的个人或组织)列表。请注意：本章并没有包含索引。索引与其说是分析问题，不如说是设计问题。在分析阶段所需的内容是基本表和它们之间的关系，包括每张表的初始字段结构。在数据库模型创建过程的早期阶段并不需要主键、外键以及辅助索引。
在图9-13中，通过在不同的字段条目中添加卖家和卖家历史信息可以显示二者的细节。图9-14显示的是卖家和卖家历史数据的简图。可以从图中看到这些数据在实际应用中的情况。图9-14显示了卖家及其链接的不同列表，包括诸如卖家的姓名、当加入联机拍卖行后(卖家创建自己的首张拍卖列表)，卖家在买家中的受欢迎程度以及其他的相关信息。
图9-13 在图9-10的类别结构中添加卖家信息
图9-15通过在卖家历史图中添加卖家历史细节对卖家信息进行扩展。卖家历史信息包括买家身份、购买商品(拍卖项目编号)以及买家对卖家的评论等细节。
图9-14 图9-13所示的卖家细节数据简图
图9-15 图9-13所示的卖家历史细节数据简图
历史信息使拍卖行可以给予卖家相应的受欢迎级别，并使以后的买家可以对他们希望或者不希望交易的卖家进行声誉评价。
拍卖行的买家
图9-16将买家添加到已建立的表结构中。买家明细表和买家历史表均已添加。买家表比卖家明细表减少3个信息字段。这3个删除的信息字段分别为：政治、国际销售和运输以及支付方法。买家历史表与卖家历史表的字段信息相同。
两张买家表中的信息和图9-14和图9-15显示的结构看起来很相似；但是，在为目前介绍的所有表建立简单的ERD之前，以下几点需要注意和详述：
● 区别买家和卖家——
在拍卖模型中，买家也可以成为卖家(但需要禁止他们为自己的商品投标)。看起来似乎可以将买家表与卖家表进行合并，同时将两张历史表也进行合并。传统上，在许多数据库模型中，通常需要区别客户和供应者的类型。这是由于从内容的角度而不是结构的角度上看，两者并不一致。在拍卖数据库模型中，区分买家和卖家很有可能是最明智的选择，原因仅仅在于：一般情况下(但不总是如此)，买家不可能成为卖家，反之亦然。很明显，在设计阶段(将在第10章对该阶段进行讨论)应用规范化操作之后，将买家、卖家、既是买家也是卖家的人(既卖又买的拍卖者)分成3张独立的表是明智的做法。
图9-16 将买家信息添加到表9-10中的类别结构(包括投标信息)
● 参照完整性主键—— 所有的基本关系都建立在不同的表之间。标识合适的主键和外键与其说是设计问题，不如说是分析问题。在关于设计的第10章将建立键。
● 类别层次结构——
在某些情况中，区分静态表(例如3种类别的表)并不一定是最有效的选择。也许会存在将所有的类别合并为一张表的情况。通过专门的父字段和子字段可以在一张表中为每种类别记录包含所有的3种类别层次。由于这也是设计问题而不是分析问题，因此将在第10章作更详细的说明。
注意：
也许您想知道这些内容(刚才提到的3点)的应用场合，这些因素都是设计问题而不是分析问题。本章涉及的是为拍卖数据库模型发现基本内容的分析过程。第10章讨论的是设计问题。这些案例分析的目的是通过对每个概念的逐步深入的方式来介绍数据模型，从而使知识更容易理解和吸收。
试一试 分析OLTP数据模型
为某个Web站点建立简单的分析层次的OLTP数据库模型。该Web站点允许为音乐家和乐队创建免费的分类广告。以下是简化的方法：
(1) 标识公司的运作。
(2) 绘制基本表的图示。
(3) 建立简单的关系。
(4) 在每张表中创建基本字段。
操作回顾
图9-17显示的是基本信息类别，从本质上说包括静态的和事务型两种。乐器和技能描述的是相对静态的音乐家信息(音乐家来来往往，但是技能和乐器分类却是不变的)。这使音乐家成为动态的事务型信息。每个乐队都拥有某种特定的流派，例如演奏摇滚乐、朋克乐、古典摇滚等。因此，乐队是动态的，而流派是静态的。从本质上来说，分类广告本身显然是动态的。
图9-17 标识基本运作
图9-18通过在图9-17描述的不同运作之间建立关系，从而更进了一步。换言之，音乐家演奏乐器并具有技能。乐队通常具有特定的流派。音乐家和乐队都通过分类广告宣传自身。
图9-18 链接基本运作
图9-19显示的是根据业务规则为图9-18中运作图所构造的ERD。有几点需要注意：
● 音乐家可以演奏多种乐器。
● 音乐家可以有多种技能。
● 乐队可以有多种流派。
●
乐队表中的MEMBERS字段考虑的是BAND和MUSICIAN之间一对多的关系。换言之，在一个乐队中通常含有多名音乐家；但是一名音乐家不一定必须在一个乐队中，乐队可以解散从而不再包含音乐家，并且乐队和音乐家都可以做广告。
● 音乐家和乐队可以做广告。
图9-19 创建业务规则的基本分析ERD
9.3.4 案例分析：数据仓库模型
规划和分析数据仓库数据库模型主要是关于静态信息和事务信息的区分。静态信息由描述事实的细节组成。事实是失去价值时可以销毁或者归档的变量或者动态细节。对于联机拍卖行来说，所有买家和卖家的细节(例如地址)都是静态信息，因为它们不会有大的改变。
事务信息由添加到数据库并在一段时间后从数据库删除的内容组成。为了保证数据库的规模不至于过大，需要从数据库中删除事务信息；但是，当试图完成预测报告时，所有的历史信息(例如过去的投标记录和过去的列表)都是有价值的信息。例如，联机拍卖行希望得到宣传。如果拍卖玩具比销售50年代的老唱片要流行100倍，那么更好地利用广告资金的方法是与玩具商做买卖。执行预测报告和从过去5年的信息中进行推断可以有效地发现特定的市场目标。旧的、过时的和归档的数据可以十分有用。
与OLTP数据库不同，数据仓库可用于包含归档信息，从而不会造成OLTP数据库的性能问题。
1. 建立公司运作
当为OLTP数据库结构分析数据库模型时，已经建立公司运作。数据仓库数据库模型所需的内容是建立事实的内容(事务信息)和维度的内容(静态数据)。通过图9-20、图9-21和图9-22所示的阶段可以获得这些内容。
图9-20 数据仓库数据建模将层次静态表非规范化为单个的静态结构
图9-21 联机拍卖行的数据仓库星型数据库模式
在图9-20中，OLTP数据库模型中的3种类别可以合并为单一的层次结构的类别表。通过将父类的引用包含到新类别表中，并允许从三级类别到二级类别以及二级类别到主类别的链接，可以完成3张表的合并。主类别没有父类别。同样，二级类别也可以不包含任何三级类别(即不含有三级子类别)。如果没有需求，那么三级类别的记录可以不存在。
图9-22 分析数据仓库数据库模型中的事实
图9-21显示的是针对联机拍卖公司数据仓库数据库模型的星型模式。在星型模式中，所有的维度(静态数据容器)围绕着事实(事务信息)。
图9-21同样显示的是新添加的维度：LOCATION、TIME和PRODUCT。许多数据仓库的数据库模型包含附加维度。这些维度含有从事实表中收集的信息，有时也可以是维度。当在数据仓库的数据库模型中分隔信息时，这些附加的特定数据仓库类型的维度提供一种更好的和更有效的结构。
● 位置——
位置通常根据地址细节建立，目的是当投标者和卖家(针对的是联机拍卖行)在某个特定的城市、州、国家、洲、星球、星系、银河和宇宙中时，可以建立他们的位置信息。看起来这样做似乎有些愚蠢，但是却是很重要的。根据不同的区域，位置维度使对数据仓库的分析成为报表。例如：在某个区域内的某个城市畅销的某种商品等。
● 时间标记——
时间标记信息将信息的维度划分成时间段。这样做的结果是可以评估特定的时间段内公司执行情况的数据仓库报表。例如：报表能够对不同年份的同一月份或季度的收益率进行比较。这种报表有助于评估业务的健壮性和其他特性(例如业务获利的时间)。如果某公司有圣诞节的促销计划，那么可以更好地为圣诞节销售的商品、这些商品的制造费用以及需要分派产品的场合做准备。
● 产品—— 产品维度信息允许根据不同的产品对报表进行划分，这一做法与根据位置和时间标记进行信息和报表的划分类似。
提示：
这里也存在许多其他数据仓库特有的静态信息。位置、时间和产品只是最常添加的维度。
从本质上来说，在数据仓库中的数据库模型中普遍使用的维度(例如：位置、时间和产品)通常会用在同一报表的同一时刻中。同样，数据仓库数据库可以非常庞大，以至于需要通过位置、时间和产品信息对报表进行筛选，从而获得较好的性能增益。
图9-22显示的是针对联机拍卖公司数据仓库数据库模型更细化的星型模式。在图9-22中，可以发现所有的维度仍然分别直接指向所有的事实(事务信息)。通常，在数据仓库中，与事实表的规模相比，数据库维度表的记录数非常少。事实表经常会有数百万条甚至数十亿乃至数兆的记录。维度表包含几十条，几百条或者几千条记录，记录数目相对事实表来说要少很多。这就是我们的想法！
注意：
数据仓库中的事实表通常比维度表的规模要大很多(从记录数目上来说)。这也是在建立有效的数据仓库数据库模型时使用星型模式的目的。在规模较小的表(含有较少记录的维度)和规模较大的表之间(含有较多记录的事实)进行SQL代码的连接查询是最有效率的连接。连接两张规模较大的表或者规模相等的表(假定两张表均含有几千条记录)的效率都会降低很多。
请注意图9-22中的LISTING和BID表合并为单独的LISTING_BIDS表的过程。同样，SELLER_HISTORY表和BIDDER_HISTORY表也可以合并为单独的HISTORY表。图9-23显示的是针对联机拍卖公司的数据仓库数据库模型的结构。
图9-23所示的数据仓库模型事实上包含两种星型模型。
图9-23 数据仓库可以包含多个星型模式(连接到同一维度的多张事实表)
数据仓库数据库模型可以包含多个星型模式(多张事实表)。事实表之间并不链接。如果需要通过SQL代码查询连接多张事实表，那么多张事实表可以构造为一个事实表(单独的星型模式)，如图9-24所示。
图9-24 多个星型模式(事实表)可以合并为一个事实表
2. 发现业务规则
在这一阶段，数据仓库模型已经为业务规则的分析和应用做好准备。正如本章前面所描述的那样，业务规则的应用包括表的建立、表之间最基本关系的确立和添加粗略的表字段内容。
在本章的前面，联机拍卖行的OLTP数据库模型已经经历过业务规则应用和ERD构造过程。数据仓库模型所需要的是一个简单的ERD。通过该ERD可以开始用数学方法表示数据仓库数据库模型的过程。图9-25显示的就是这种类型的ERD。
图9-25 联机拍卖行的数据仓库数据库模型ERD
图9-25所示的表中大部分字段已经在OLTP数据库模型的分析中讨论过。没有说明的字段是附加的位置维度、时间标记维度和产品内容维度。
● 位置—— 位置是区域、国家、州和城市组成的层次结构。如图9-26所示。
图9-26 一些示例的位置记录
● 时间——
时间是月份、季度和年的组合，如图9-27所示。时间标记维度可以包含日期、小时、甚至是分钟；但是，细化的层次会产生庞大的时间维度，并且通常没有价值。过多的记录会影响SQL代码的连接查询效率。
图9-27 一些示例的时间标记记录
● 产品——
产品与联机拍卖行的数据仓库数据库模型有些不相称。产品在本质上与联机拍卖行的类别相同。同样，由于每种列表类别的价格都不固定，因此价格与PRODUCT表中的PRICE字段是不相关的。价格由不同的卖家和最终中标的买家决定，因此它是灵活的。因此，PRODUCT表与联机拍卖行的数据仓库数据库无关。图9-25所示的ERD应调整为如图9-28所示。
图9-28 调整联机拍卖行的数据仓库数据库模型ERD
注意：
图9-24描述的是迭代的数据库模型的设计和分析过程。这些步骤可以按照任意的顺序重复，并且在整个过程中都可以进行调整。分析和设计时，最好在数据库的建模阶段进行调整。在通过某些方法(例如：规范化和非规范化)进行的重写应用到数据库模型之前进行修改要好在编写应用程序代码之前进行修改。
试一试：分析数据仓库中的数据库模型
为同一个Web站点创建简单分析层次的数据仓库数据库模型的步骤如图9-19所示。我们再次通过简单的方法解决简单的问题：
(1) 标识维度(静态内容)。
(2) 标识事实(动态内容)。
(3) 建立简单的关系。
(4) 在每张表中创建基本字段。
操作回顾
在“试一试”部分中的所有细节都在OLTP数据库模型中进行过讨论。“试一试”中所需要的内容是如图9-29所示的数据仓库数据库模型。
图9-29 基本的数据仓库ERD业务规则数据模型
ADVERTISEMENT表作为事实表。MUSICIAN表是单层事实表。BAND表、MERCHANDISE表、SHOWS表和DISCOGRAPHY表组成二维层次结构。
提示：
在本情况中，在静态信息和动态信息之间存在某些灰色区域。通过其他的方法也可以建立该数据仓库数据库模型。
