关系数据库协同模型分析

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

3，2关系数据库模型
    当今的企业为了更好地组织、存储基本的面向事务的信息(直至较终用于构建电子商务智能)，都在运用数据库技术。实际中，有四种用于建立数据库的主要模型。面向对象的数据库模型是较新且较具发展前景的一种，在扩展学习模块G中我们将更多、更全面地讨论面向对象技术。本节我们集中讨论目前使用较广泛的数据库模型——关系模型。
    一般而言，我们说数据库是信息的集合，它能按照信息的逻辑结构对其进行组织与存取。关系数据库利用一系列存在着逻辑关系的二维表或文件来存储信息。术语关系用来描述关系模型中的每张：维表或文件(因此这种模型被命名为关系数据库模型)。一个关系模型的数据库实际上由两个独立部分组成：(1)信息的具体内容，它们被存储在一系列的二维表、文件或关系中(人们可以交替使用这三种存储方式)；(2)信息的逻辑结构。我们来看Solomon公司数据库的一个具体部分，并进一步研究关系数据库模型的特征。
3，2．1信息的收集
    在图3—2中，我们建立了Solomon数据库的一个局部视图。注意，该数据库包含有五个文件(也可以称为表或关系)：订单文件、客户文件、混凝土类型文件、雇员文件和卡车文件(实际上，数据库还可能包含更多的文件，在扩展学习模块C中我们将继续开发它)。这些文件因各种原因关联在—…起一客户下订单，雇员开卡车送货，每笔订单都包含一种混凝土类型，等等。公司需要所有这些文件来管理它的客户关系和订单。

    在每个文件中，我们都可以看到一些特定的数据项(通常被称为属性)，例如，订单文件中包含有：Order Number(订单编码)、Order Date(订单日期)、Customer Number(客户编码)，DeliveryAddress(发货地址)、ConcreteType(混凝土类型)、Amount(数量，以立方码尺度量)、TruckNumber(卡车编码)、DriverID(司机号)。在客户文件中，也可以看到一些特定信息，包括：CustomerNumber(客户编码)，CustomerName(客户姓名)、Customer Phone(客户联系电话)和CustomerPrimaryContact(客户主要联系人)。这些都是Solomon数据库中需要包含的重要信息。此外，Solomon3&司还需要利用这些(也可能更多的)信息有效地管理订单和客户关系。
3，2．2创建逻辑结构
    在运用关系数据库模型时，对信息的组织与存取是根据信息的逻辑结构而非物理结构进行的。因此，我们根本没必要关心“Allison Smithson”应该在雇员文件的哪一行出现，只要知道它的EmployeeID(雇员号)是“984568756”，或者她的姓名是“Allison Smithson"’就可以了。在关系模型中，数据字典包含了信息的逻辑结构。在建立数据库时，首先要建立数据字典。数据字典中包含有数据的重要信息或逻辑特征。例如数据字典要求客户文件中的客户联系电话为10位数字，而要求雇员文件中的雇用日期包括年月日。
这是一种完全有别于其他方式的信息组织方法。例如，在大多数电子表格中，如果想存取其中某十单元格中的信息，就必须知道该信息的物理存放位置，即行与列的标号。然而，在关系数据模型中，只要知道信息所在列的字段名称(如：Amount)及其逻辑行的位置，不必关心信息所在的物理行即可。正是基于这一原理，在上面的Solomon数据库中，很容易修改某个订单的订货数量，而无须知道这一信息的实际存放位置(通常存放位置是通过行、列标号确定的)。
在使用电子表格协同软件时，你可以直接输入信息、建立列标题，也能处理信息，但这不是数据库的I作方式。若运用数据库，首先必须在建立的数据字典中清晰地定义每个字段的特征。因此，在向数据库中添加信息之前，必须认真设计数据库的结构。
3．2．3信息内部的逻辑联系
    在关系数据库模型中，为了表达相互关联的文件之间是怎样建立联系的，必须建立信息的关联规则。在建立这些相关文件之间的联系之前，首先要确定每个文件的主关键字。主关键宇是文件中的一个字段(有时也可能是字段组)，它能唯一地表示一条记录。在上面的Solomon数据库中，OrderNumber就是订单文件的主关键字，CustomerNumber是客户文件的主关键字。这就意味着，订单文件中的每笔订单都必须拥有唯一的订单编码(OrderNumber)，客户文件中的每位客户也必须拥有唯一的客户编码(CustomerNumber)。
    另外，在指定某个字段为文件的主关键字时，还需强调该字段不能取空值。也就是说，向雇员文件中输入一个新的雇员信息时，不允许EmployeeID字段为空。否则，将会有多个雇员同时拥有同‘个主关键宇(空值)，即意味着允许‘个特定的主关键字(空值)对应多个雇员，在数据库环境中这种情况是不允许的。
    这一点有别于一般的电子表格工作流模式。运用电子表格，几乎不可能确保在给定的列中每个字段值都是唯一的。这一概念强调的是，利用电子表格处理信息时，要根据信息的物理位置来处理，而数据库则是根据信息的逻辑位置进行处理。
    如果观察一下图3—2就可以看出，CustomerNumber字段同时出现在客户文件和订单文件中，这样，通过该共有的字段就能够建立了两个文件之间的逻辑关联，这是外部关键字的一个实例。外部关键宇是取自另一个文件的主关键字。现在我们来看看图3—3，这里我们已经在五个文件之间建立了逻辑关系。例如，注意卡车文件中的TruckNumber(卡车编码)是该文件的主关键字，它同时还出现在了订单文件中，它使Solomon公司能够追踪到订单都是由哪些卡车运送的。因此，TruckNumber字段在雇员文件中是主关键字，同时它还作为外部关键字出现在订单文件中。在图3-3中还有很多类似的例子。

小组讨论
主关键字、外部关键字和完整性约束
现在我们考虑一下这组信息：学校要跟踪某节课的情况。在这个例子中，一节课安排一门课程。例如，学校可能有一门课程：FINA 2100——国际金融市场导论。如果学校将在秋季开设该课程，那么它变成一类课程。在下面的表格中，我们提供了一些学校考察该类课程所涉及的信息。首先，请确定主关键宇是什么(请在第2列上打叉“x”)?接下来，对每条信息标出它的外部关键字(它应是另一文件的主关键字)。如果是外部关键字，就在第3列中写下该文件名。较后，在每条信息的第4列上写下你能想到的完整性约束。例如，可否置空值，还是必须包含一些具体内容?可否存在多条记录的重复?如果它是数值型的，是否有限定的取值范围?还有没有其他约束?
    外部关键字在关系数据库模型中是必不可少的，没有外部关键字就不可能在各类文件之间建立逻辑关联。正如读者想到的，我们正是利用这些关系的外延性建立B2B商务智能的，因为它们能够保证我们追踪各种信息之间的逻辑关联。
3．2．4内在的完整性约束
    在定义关系数据库信息逻辑结构的同时，还要定义完整性约束，这些约束有利于保证信息的合理性。例如，前面已经说明CustomerNumber字段是客户文件的主关键字，在订单文件中它是外部关键字，由此得出这样的结论：(1)不可能有两个客户具有相同的客户编码；(2)订单文件中的客户编码必然存在于客户文件中。因此，当Solomon创建一个新订单并向订单文件中输入客户编码时，数据库管理系统必然会在客户文件中找到一个与之对应的唯一的客户编码。这就是内在的完整性约束，它保证“新建一笔订单记录，而该订单所对应的客户却在客户文件中找不到”这样的事情不会发生。
    《消费者报告》(ConsumerReport)杂志第一次在众多的豪华饭店中点名提到Ritz-Carlton。为什么呢?很简单，Ritz-Carlton已经建立起来强大的“宿客偏好”数据库，以便为在该集团所属任意饭店住宿的客人提供定制化、个人化和高水准服务。例如，客人给Ritz-Carlton的前台留言，告知习惯晚上9点睡觉、不希望在枕头上放薄荷巧克力点心，并准备在早上7点参加特级飞行训练班，那么这个信息不仅会转给客房服务员，还要存储在“客人习惯”数据库中。该数据库供应链管理系统为每位客人分配一个唯一的顾客编码，用以保存该顾客的各种偏好，并把这些个人信息传送到Ritz-Carlton集团下属的各个宾馆。下次客人再住进Ritz-Carlton所属的宾馆，例如是PalmBeach宾馆，客人的个人信息已经存储在宾馆的管理系统中，工作人员立即就可以知道客人的习惯是什么。
    对Ritz-Carlton集团的管理来说，培养顾客忠诚度首先是从了解每位顾客的个人习惯开始的，其中包括顾客运动的习惯，顾客在快餐店的消费倾向是什么，一天之中习惯使用几条毛巾，是否喜欢在枕头上放巧克力。Ritz-Carlton集团利用关系数据库存储和管理着这些信息，他们的员工运用数据’库系统来满足顾客的各种愿望(或幻想)。