第六章 数据库计划

打印 上一主题 下一主题

主题 843|帖子 843|积分 2531

1 数据库计划概述

 1.1 引言

        在当今这个信息爆炸的时代,数据已经成为了一种极其紧张的资源。无论是大型企业还是小型创业公司,有效的数据管理都是成功的关键之一。随着信息技能的发展,我们收集、存储和分析的数据量正在以亘古未有的速率增长。这就要求我们必须采用更加科学的方法来计划和管理数据库体系,以确保数据的正确性、完整性和安全性,同时也要考虑到体系的性能和可扩展性。
        数据库计划是软件开发过程中至关紧张的一步,它不但涉及到如何构造和存储数据,还关系到如何有效地访问这些数据以及维护其完整性。一个好的数据库计划可以大概极大地提高应用程序的性能,减少数据冗余,简化数据维护工作,并为未来的体系扩展打下精良的基础。
1.2 数据库计划的特点

        数据库计划是一个复杂且体系的过程,其特点可以从数据库建设的基本规律和数据建模与需求分析相结合两个方面来阐述。这两个方面共同决定了数据库计划的科学性、实用性和可扩展性。
  1.2.1 数据库建设的基本规律

        数据库计划遵循一定的基本规律,这些规律是数据库体系高效运行的基础。以下是数据库建设的基本规律及其特点:


  • 数据独立性

    • 特点:数据库计划强调数据的逻辑独立性和物理独立性。
    • 逻辑独立性:应用程序与数据库的逻辑布局(如表布局)分离,逻辑布局的改变不会影相应用程序。
    • 物理独立性:应用程序与数据库的物理存储布局分离,物理存储的改变(如索引、分区)不会影响逻辑布局。
    • 意义:这种独立性使得数据库体系更易于维护和扩展。

  • 数据规范化

    • 特点:通过规范化过程(如1NF、2NF、3NF等)消除数据冗余和不一致性,确保数据的完整性和一致性。
    • 意义:规范化计划提高了数据的存储服从,减少了数据更新异常,但可能增加查询的复杂性。

  • 数据完整性约束

    • 特点:通过主键、外键、唯一性约束、查抄约束等手段,确保数据的正确性和一致性。
    • 意义:完整性约束是数据库计划的紧张组成部门,可以大概有效防止数据错误和逻辑混乱。

  • 性能与存储均衡

    • 特点:数据库计划必要在性能和存储空间之间找到均衡。比方,索引可以提高查询性能,但会增加存储开销。
    • 意义:合理的计划可以大概在满足性能需求的同时,优化资源使用。

  • 可扩展性与灵活性

    • 特点:数据库计划必要考虑未来的业务增长和数据量增加,支持体系的扩展和调整。
    • 意义:可扩展的计划可以大概低落体系重构的成本,适应业务需求的变革。

  1.2.2 数据建模与需求分析相结合      

          数据库计划的另一个紧张特点是数据建模与需求分析的紧密结合。需求分析是数据库计划的基础,而数据建模是将需求转化为数据库布局的关键步骤。以下是这一特点的详细体现:


  • 需求分析驱动计划

    • 特点:数据库计划始于对业务需求的深入分析。需求分析明确了数据的种类、关系、使用场景以及性能要求。
    • 意义:只有充实理解业务需求,才能计划出满足实际应用的数据库体系。

  • 数据建模作为桥梁

    • 特点:数据建模(如实体-关系模型)是将需求分析结果转化为数据库布局的关键步骤。它通过实体、属性、关系等概念,抽象出数据的逻辑布局。
    • 意义:数据建模是需求分析与数据库实现之间的桥梁,确保计划结果可以大概正确反映业务需求。

  • 迭代与反馈

    • 特点:数据库计划是一个迭代过程,需求分析和数据建模必要不断调整和优化。计划过程中可能会发现新的需求或题目,必要反馈到需求分析阶段。
    • 意义:这种迭代过程确保了数据库计划的科学性和实用性。

  • 业务规则与数据规则结合

    • 特点:需求分析中的业务规则(如业务流程、约束条件)必要转化为数据库中的数据规则(如约束、触发器)。
    • 意义:这种结合确保了数据库体系不但可以大概存储数据,还可以大概支持复杂的业务逻辑。

  • 用户视角与技能视角融合

    • 特点:需求分析从用户视角出发,关注业务需求;数据建模从技能视角出发,关注数据布局。两者的融合是数据库计划成功的关键。
    • 意义:这种融合确保了数据库体系既满足业务需求,又具备高效的技能实现。

1.3 常用的数据库计划方法

1.3.1 基于E-R模型的数据库计划方法

        由P.P.S.Chen于1976年提出,其基本思想是在需求分析的基础上,用E-R图构造一个反映现实天下实体之间接洽的企业模式,然后再将此企业模式转换为基于某一特定的DBMS的概念模式。


  • 描述:通过实体(Entity)、属性(Attribute)和关系(Relationship)来描述数据的布局和关系。
  • 步骤:

    • 识别实体和属性。
    • 定义实体之间的关系(一对一、一对多、多对多)。
    • 绘制实体-关系图(ER图)。

  • 长处:直观易懂,恰当复杂的数据关系建模。
  • 适用场景:适用于需求分析阶段和概念计划阶段。
  1.3.2 基于3NF的数据库计划方法

        以关系数据理论为指导来计划数据库的逻辑布局,是逻辑计划阶段可采用的有效方法。


  • 描述:通过一系列规范化步骤(如1NF、2NF、3NF等)消除数据冗余和不一致性,确保数据的完整性和一致性。
  • 步骤:

    • 将数据分解为多个表。
    • 应用规范化规则,逐步消除冗余和依赖。

  • 长处:减少数据冗余,提高数据完整性。
  • 适用场景:适用于逻辑计划阶段,特殊是关系型数据库计划。
1.3.3 维度建模计划

        维度建模是一种专门用于数据仓库计划的数据建模技能,其主要目标是为了支持高效的查询性能和易于理解的报告布局。它特殊适用于必要快速相应复杂查询并生成报表的商业智能(BI)应用中。维度模型通常以星型模式或雪花模式构造。


  • 描述:主要用于数据仓库计划,通过事实表(Fact Table)和维度表(Dimension Table)来描述数据。
  • 步骤:

    • 识别事实(如销售金额)和维度(如时间、所在)。
    • 构建星型模式(Star Schema)或雪花模式(Snowflake Schema)。

  • 长处:简化查询,提高数据仓库的查询性能。
  • 适用场景:适用于数据仓库和商业智能体系。
1.4 数据库计划的基本步骤

        数据库计划是一个体系化的过程,旨在创建一个有效的数据库布局来满足特定的业务需求。整个过程通常分为几个关键阶段:需求分析、概念模型计划、逻辑模型计划、物理模型计划、数据库实行和数据库运维。下面是对每个阶段的概述:



  • 需求分析
        需求分析是数据库计划的第一步,主要目标是理解并明确用户的需求。这个阶段涉及到与长处相关者进行沟通,以收集有关数据存储、访问模式、性能要求、安全性和其他约束条件的信息。通过需求分析,计划师可以大概确定必要存储的数据类型以及如何有效地构造这些数据。


  • 概念模型计划
        在概念模型计划阶段,基于需求分析的结果,计划师将抽象出体系的高层次视图。这一步通常使用实体-关系(ER)图来表示,其中包含实体(现实天下中的对象)、属性(描述实体的特征)以及实体之间的关系。概念模型强调信息布局而不涉及技能细节,它提供了对整个体系的一个全面概览,并为后续的计划步骤奠定了基础。


  • 逻辑模型计划
        逻辑模型计划阶段将概念模型转换成详细的数据库管理体系(DBMS)无关的情势。此阶段的主要任务是定义表布局、字段、数据类型、主键、外键等元素。此外,还必要考虑规范化原则,以减少数据冗余并提高数据完整性。逻辑模型应该详细到足以指导数据库的详细实现,但仍旧不依赖于任何特定的数据库技能。


  • 物理模型计划
        物理模型计划涉及到选择合适的数据库技能和优化数据库性能的详细措施。在这个阶段,计划师会决定索引策略、分区方案、视图定义等,同时也会考虑到硬件限定和预期的工作负载。物理模型直接关联到所选的DBMS,而且会根据该体系的特性和能力进行调整,以确保最佳性能和可扩展性。


  • 数据库实行
        实行阶段包括在选定的DBMS上实际创建数据库布局,并添补初始数据。这一过程可能涉及编写SQL脚本、使用数据库管理工具大概主动化部署工具。此外,还必要设置用户权限、配置备份策略以及其他安全管理措施。


  • 数据库运维
        数据库运维涵盖数据库上线后的所有活动,如监控性能、实行维护任务(如备份、规复)、应用软件更新、调整配置参数等。运维的目标是确保数据库体系的稳固运行、高效相应查询哀求,并可以大概随着业务需求的变革而灵活扩展。
        每个阶段都有其独特的挑战和重点,但它们共同构成了一个完整的数据库计划流程。正确地遵循这些步骤可以帮助确保最终的数据库体系既满足当前的业务需求,又能适应未来的增长和发展。

1.5 数据库计划过程的各级模式

        各级模式之间的关系


  • 概念模式:是面向用户和计划职员的,它描述了数据的团体布局和关系,是数据库计划的核心。
  • 逻辑模式:是DBMS支持的数据模型,它描述了数据在数据库中的逻辑构造方式,是概念模式在DBMS中的详细实现。
  • 外模式:是逻辑模式的一个子集,它描述了用户可以大概访问的数据部门和访问权限,是用户视图和访问权限的会合体现。
  • 内模式:是数据库物理存储布局的直接体现,它描述了数据在存储介质上的存储方式和存取方法。


2 需求分析

        需求分析阶段是数据库计划的起点,其主要目标是全面理解用户的需求,并将这些需求转化为详细的技能要求。这个阶段的工作质量直接影响到后续各个计划阶段的有效性和最终数据库体系的成功与否。以下是需求分析阶段的主要工作内容和常用方法:
2.1  工作内容



  • 业务需求收集:

    •   与长处相关者(如最终用户、业务分析师、项目经理等)进行深入交流,相识业务流程、操作模式以及数据处置处罚需求。
    •    确定体系的目标和功能,明确哪些数据必要被存储、处置处罚和报告。

  • 数据需求定义:

    •     收集关于数据来源、类型、格式和量的信息。
    •     分析数据之间的关系,包括实体间的关系及其属性。
    •     定义数据的质量要求,比方正确性、完整性和时效性。

  • 性能和约束条件识别:

    •     评估预期的数据访问模式和查询复杂度,以确定性能要求。
    •     识别任何技能或业务上的限定条件,比如预算、时间框架、法规遵从性等。

  • 用户交互和安全需求:

    •     明确用户对界面友好性、易用性的期望。
    •     列出安全性需求,包括访问控制、隐私保护措施等。

  • 现有体系评估:

    •     如果是在已有体系基础上进行改进,则需评估当前体系的优缺点,特殊是数据管理方面的题目。
    •     理解现有体系的架构、数据模型和技能栈,为迁徙规划提供依据。

2.2  方法



  •  访谈和问卷调查:通过面临面的攀谈或书面情势询问,直接从关键人物那边获取第一手资料。
  •  文档检察:仔细研究现有的业务流程手册、体系文档和其他相关信息源。
  •  观察法:实地考察用户的日常工作流程,直观感受数据如安在实际中被使用。
  •  原型开发:对于复杂或模糊的需求,可以先构建一个简朴的原型供用户试用并反馈意见。
  •  联合应用开发(JAD):构造跨职能团队共同参与需求讨论集会,加速需求澄清过程。
  •  用例分析:描述用户与体系之间的交互场景,帮助界定体系界限和功能范围。
        在整个需求分析过程中,保持精良的沟通至关紧张,确保所有参与者都能清晰地理解项目目标及各自的角色。此外,记录下所有的发现和决议,并定期更新需求文档,以便作为后续计划工作的参考。

3 概念模型计划

3.1 概述

        概念模型是对现实天下中的实体、属性及其相互关系的抽象表示。它主要用于描述体系的概念化数据布局,帮助开发职员理解业务范畴,并确定必要管理的数据对象及其之间的关系。概念模型是数据库计划过程中的一个关键阶段,为后续的逻辑计划和物理计划提供了基础。
        概念模型是从普通用户的视角来描述数据的,使用简朴的符号来描述信息,没有严格的规定,只要能清晰反映现实天下的信息就行。常用的就是E-R图,如下图:

上面的E-R图就可以简朴描述了一个门生的信息,是一张最简朴的E-R图,不涉及数据关系,普通用户都可以清晰地理解这张图,这张图就是概念模型,几个箭头和椭圆就刻画了一个门生的数据信息,可以大概很好体现现实中的事物信息。
3.2  示例说明

以学校信息管理体系为例,可以创建如下概念模型:
实体:门生、西席、课程。
属性:


  • 门生:学号、姓名、年岁、班级等。
  • 西席:西席编号、姓名、职称等。
  • 课程:课程编号、课程名称、学分等。
关系:


  • 门生与课程之间存在选课关系(1:N)。
  • 西席与课程之间存在授课关系(1:N或M:N,取决于是否答应一个西席教授多门课程以及一门课程由多个西席共同教授)。
        在E-R图中,可以使用矩形表示实体(如门生、西席、课程),使用椭圆形表示属性(如学号、姓名、课程编号等),并使用连线表示关系(如门生与课程之间的选课关系)。
        完整的E-R图示比方下:

        概念模型(Conceptual data models,CDM)的核心任务是综合和概括业务范畴中的各个概念实体。该过程的重点在于分析概念实体及其相互关系,而不是详细描述各个概念实体的各种属性。通过以概念实体为线索,对需求分析结果进行检察,确定建模的范围,分别建模主题,梳理主要业务关系,构建逻辑数据模型的框架。
        概念数据模型是一个布局化的业务视图,用于支持业务流程、记录业务变乱和跟踪相关绩效指标所需的数据。该模型侧重于识别业务中使用的数据,而不是其处置处罚流程或物理特征。该模型的视角独立于任何底层的业务应用程序。
        概念数据模型代表了支持业务需求所需数据的团体布局,独立于任何软件或数据存储布局。其特点包括:


  • 业务背景下数据布局的团体视图。
  • 不依赖于任何数据库或物理存储布局。
  • 可能永远不会在物理数据库中实现的对象。有些概念和流程可能不会出现在模型中,但它们对企业理解和解释业务非常紧张。
  • 支持实行业务流程或企业运营所需的数据。
          综上所述,概念模型是数据库计划过程中的一个紧张阶段,它通过对现实天下中的实体、属性及其相互关系的抽象表示,为后续的逻辑计划和物理计划提供了基础。创建概念模型必要遵循一定的步骤和方法,包括需求分析、确定实体、定义属性、建立关系、构建E-R模型图以及验证和完善模型等。
4 逻辑模型计划

4.1 概述

        逻辑模型是数据库计划过程中的一个关键步骤,它介于概念模型和物理模型之间,用于详细描述数据的布局、关系和约束,而不涉及详细的数据库实现细节,因此不依赖于详细的数据库管理体系(DBMS)或物理存储细节。逻辑模型是数据库计划的蓝图,逻辑模型是概念模型(如实体-关系模型)的进一步细化,它为数据库的实现提供了更详细的规范,能更好的帮助开发职员和业务职员理解数据的构造方式。
逻辑模型是对数据的抽象表示,主要关注:


  • 实体(Entity):表示业务中的核心对象,如“用户”、“订单”。
  • 属性(Attribute):实体的特征,如“用户”的姓名、邮箱。
  • 关系(Relationship):实体之间的关联,如“用户”和“订单”之间的一对多关系。
  • 约束(Constraint):数据的规则,如主键、外键、唯一性、非空等。
逻辑模型通常用“实体-关系图(ER图)”表示,它是一种图形化工具,用于展示实体、属性和关系。
常见的逻辑模型类型包括:


  • 关系模型:以表格情势构造数据,每个表代表一个实体,行代表记录,列代表属性。
  • 层次模型:通过树状布局来表示数据,恰当描述具有明显上下级关系的数据。
  • 网络模型:答应一个记录有多个父记录,比层次模型更加灵活,但复杂度也更高。
在现代数据库计划中,最常用的逻辑模型是关系模型
4.2 逻辑模型的特点

独立于详细技能:逻辑模型不依赖于详细的数据库管理体系(如MySQL、Oracle),只关注数据的逻辑布局。
面向业务:逻辑模型直接反映业务需求,帮助业务职员和技能职员沟通。
详细且规范化:逻辑模型通常遵循规范化原则(如3NF),以减少数据冗余和提高数据一致性。
4.3 创建逻辑模型步骤

创建逻辑模型通常遵循以下步骤:
1. 确定实体和属性


  • 实体识别:首先必要识别体系中所有的实体。实体是指现实天下中可以区分的对象或概念。比方,在图书馆管理体系中,可能的实体包括“册本”、“读者”、“借阅记录”等。
  • 属性定义:为每个实体定义属性,并确定数据类型和可能的约束。属性是用来描述实体特征的详细信息。比方,“册本”实体可能包含“书名”、“作者”、“ISBN”等属性。
2. 建立实体间的关系


  • 确定实体之间的关系:确定实体之间的关系,并明确这些关系的类型(一对一、一对多或多对多)。比方,“借阅记录”与“读者”之间是一对多的关系(一个读者可以有多条借阅记录),而“借阅记录”与“册本”之间也是多对多的关系(一本书可以被多名读者借阅)。
  • 关系规范化:将关系分解到第三范式(3NF)或更高范式,以消除数据冗余和更新异常。
3. 应用规范化原则


  • 为了减少数据冗余并确保数据的一致性,逻辑模型应该遵循一定的规范化规则,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。这一步骤涉及到分解过于复杂的表格,确保每个表格只处置处罚单一主题的信息。
4. 添加完整性约束


  • 定义各种完整性约束条件,如主键、外键、唯一性约束等,以保证数据的正确性和一致性。比方,设置“读者ID”作为“读者”表的主键,并在“借阅记录”表中作为外键引用。
  • 主键:为每个表确定一个唯一标识记录的主键。
  • 外键:在相关表之间建立引用关系,实现参照完整性。
5. 定义索引


  • 设置索引:为了提高查询服从,为常常查询的列创建索引。
6. 评审和优化
        最后,对构建好的逻辑模型进行全面查抄,确保所有需求都被正确地反映出来,并根据反馈进行必要的调整和完善


  • 逻辑模型评审:与业务分析师、数据库管理员和最终用户一起评审逻辑模型,确保它满足所有业务需求。
  • 性能优化:分析模型可能存在的性能瓶颈,并进行优化。
7. 过程文档化


  • 详细记录逻辑模型的计划过程、数据布局、关系和约束。
4.3 建模工具

        创建逻辑模型可以使用各种工具,如PowerDesigner、ER/Studio、Microsoft Visio、Lucidchart等,这些工具提供了可视化的界面来帮助计划者构建和展示数据模型。
1 PowerDesigner


  • 功能:数据建模业界的领头羊,支持完整的集成模型、面向对象的建模、数据建模等。
  • 适用场景:适用于企业级数据建模、业务过程建模和数据库计划等任务。
2 ER/Studio


  • 功能:数据建模业界的领头羊,支持完整的集成模型、面向对象的建模、数据建模等。
  • 适用场景:适用于企业级数据建模、业务过程建模和数据库计划等任务。
3 PDMan


  • 功能:开源免费的数据库模型建模工具,支持多种数据库体系。
  • 适用场景:适用于数据库建模、代码主动生成和数据库版本管理等任务。
4 其他辅助工具
        Visio


  • 功能:主要用于绘制流程图和示意图。
  • 适用场景:在数学建模过程中,可用于绘制模型流程图和数据流图等
4.4 示例说明

        以商品订单管理体系为例,可以创建如下逻辑模型:


  • 实体:会员、商品、品牌、订单。
  • 实体及属性

    • 会员 (Member)
    • 会员ID (MemberID, 主键)
    • 姓名 (Name)
    • 性别 (Gender)
    • 出生日期 (DateOfBirth)
    • 接洽方式 (ContactInfo)

  • 商品类型 (ProductType)

    • 类型ID (TypeID, 主键)
    • 类型名称 (TypeName)

  • 品牌 (Brand)

    • 品牌ID (BrandID, 主键)
    • 品牌名称 (BrandName)

  • 商品 (Product)

    • 商品ID (ProductID, 主键)
    • 商品名称 (ProductName)
    • 类型ID (TypeID, 外键 -> ProductType.TypeID)
    • 品牌ID (BrandID, 外键 -> Brand.BrandID)
    • 价格 (Price)
    • 库存数目 (StockQuantity)

  • 订单 (Order)

    • 订单ID (OrderID, 主键)
    • 会员ID (MemberID, 外键 -> Member.MemberID)
    • 下单时间 (OrderTime)
    • 总金额 (TotalAmount)
    • 订单详情 (OrderDetail)
    • 订单详情ID (OrderDetailID, 主键)
    • 订单ID (OrderID, 外键 -> Order.OrderID)
    • 商品ID (ProductID, 外键 -> Product.ProductID)
    • 数目 (Quantity)
    • 单价 (UnitPrice)

  • 关系描述

    • 会员与订单:一对多关系,一位会员可以有多个订单,但每个订单仅属于一位会员。
    • 商品类型与商品:一对多关系,一种商品类型可以包含多种商品,但每种商品只能属于一种商品类型。
    • 品牌与商品:一对多关系,一个品牌可以拥有多种商品,但每种商品只能归属于一个品牌。
    • 订单与订单详情:一对多关系,一份订单可以包含多项商品详情记录,但每条订单详情记录只对应于一个订单。
    • 商品与订单详情:多对多关系通过订单详情表实现,一种商品可以在多个订单中出现,一份订单也可以包含多种商品。

  • 创建逻辑模型的关键步骤

    • 确定实体和属性:如上所述,明确每个实体应包含哪些属性,并为每个实体定义一个主键。
    • 建立实体间的关系:使用外键来表示实体间的关联,确保这些关系符合业务逻辑。
    • 应用规范化原则:查抄模型是否遵循了数据库计划的基本范式(如第一范式、第二范式、第三范式),以减少冗余并提高数据的一致性和完整性。
    • 添加约束条件:比方,设置主键、外键约束,以及任何须要的唯一性或查抄约束。

        以上就是一个基于给定实体的完整逻辑数据模型的计划思路。这个模型可以帮助你有效地构造和管剖析员、商品、品牌等相关信息,并支持复杂的查询需求,比如查找特定会员的所有订单或统计某个品牌的销售情况等。E-R图如下:
        


5 物理模型计划

5.1 概述

        物理数据模型是数据库计划的最终阶段,它基于逻辑数据模型,结合详细的数据库管理体系(DBMS)的特性详细特性和存储机制,定义数据库的实际存储布局、索引、分区、数据类型等细节的模型,详细描述了数据如安在特定的数据库管理体系(DBMS)中存储。物理数据模型不但包括逻辑数据模型中的实体、属性和关系,还包括详细的数据库对象如表、列、索引、视图、触发器、存储过程等,并考虑了性能优化、存储服从和访问模式等因素。
        简而言之,物理数据模型是将逻辑数据模型映射到实际数据库技能的详细实现。
物理数据模型是对数据库的物理实现细节的描述,主要包括:


  • 表布局:定义表名、字段名、字段数据类型、约束(如主键、外键、唯一性、非空等)。
  • 索引:为提高查询性能而创建的索引。
  • 分区:对大表进行分区存储,以提高查询服从。
  • 存储参数:如表空间、存储引擎、文件组等。
  • 视图:基于表的虚拟表,用于简化查询。
  • 触发器:在特定变乱(如插入、更新、删除)发生时主动实行的存储过程。
  • 存储过程和函数:预定义的SQL代码块,用于实现复杂业务逻辑。
物理数据模型是逻辑数据模型的详细化,它考虑了数据库管理体系的特性和性能优化需求。
5.2 物理模型的特点

依赖于详细DBMS:物理数据模型与详细的数据库管理体系(如MySQL、Oracle、SQL Server)相关,不同DBMS的实现细节可能不同。
关注性能:物理数据模型会考虑查询性能、存储服从等因素,通过索引、分区等技能优化数据库。
可操作性强:物理数据模型可以直接用于生成数据库脚本(DDL),创建实际的数据库对象。
5.3 创建物理模型的步骤:

        创建物理数据模型的步骤通常包括以下几个阶段:
1. 基于逻辑数据模型


  • 物理数据模型是在逻辑数据模型的基础上创建的,因此首先必要有一个完整的逻辑数据模型。
  • 逻辑数据模型定义了实体、属性、关系以及约束。
2. 选择数据库管理体系(DBMS)


  • 首先确定使用哪个DBMS(比方MySQL、PostgreSQL、Oracle等)。不同的DBMS有不同的特性和限定,这些都会影响物理模型的计划。
3. 转换逻辑模型为物理模型


  • 表:将逻辑模型中的每个实体转换为一个或多个物理表。
  • 列:逻辑模型中的属性转换为物理表中的列。必要定义每列的数据类型、长度、是否答应NULL值等属性。
  • 主键:为每个表定义主键,确保每一行都是唯一的。
  • 外键:根据逻辑模型中的关系,在相应的表之间设置外键约束,以维护数据的参照完整性。
  • 索引:为了提高查询服从,可能必要在某些列上创建索引,特殊是那些常常用于搜索条件的列。
4. 考虑性能优化


  • 分区:对于大型表,可以考虑使用表分区来提高查询性能和管理服从。
  • 索引策略:除了基本的索引之外,还可以使用复合索引、全文索引等高级索引策略。
  • 规范化与反规范化:虽然逻辑模型强调规范化以减少冗余,但在物理模型中,有时必要进行恰当的反规范化来提高读取性能。
5. 生成DDL脚本


  • 使用建模工具(如MySQL Workbench、ER/Studio、PowerDesigner)生成数据库的DDL(Data Definition Language)脚本。
  • DDL脚本包括创建表、索引、视图、触发器等对象的SQL语句。
6. 验证和优化


  • 在测试情况中运行DDL脚本,创建数据库对象。
  • 通过性能测试验证模型的合理性,并根据测试结果进行优化(如调整索引、分区策略)。
 5.4 示例说明

  以房产经纪管理体系为例,可以创建如下物理数据模型:


  • 实体:用户、登录日志、浏览记录、房源、户型、地区、楼盘、经纪人。
  • 实体及属性

    • 用户 (User)

      • 用户ID (UserID, 主键)
      • 用户名 (Username)
      • 密码 (Password)
      • 注册时间 (RegistrationTime)

    • 用户登录日志 (UserLoginLog)

      • 日志ID (LogID, 主键)
      • 用户ID (UserID, 外键 -> User.UserID)
      • 登录时间 (LoginTime)
      • IP地址 (IPAddress)

    • 浏览记录 (BrowseRecord)

      • 记录ID (RecordID, 主键)
      • 用户ID (UserID, 外键 -> User.UserID)
      • 房源ID (PropertyID, 外键 -> Property.PropertyID)
      • 浏览时间 (BrowseTime)

    • 房源 (Property)

      • 房源ID (PropertyID, 主键)
      • 楼盘ID (BuildingID, 外键 -> Building.BuildingID)
      • 标题 (Title)
      • 描述 (Description)
      • 价格 (Price)
      • 面积 (Area)
      • 户型ID (LayoutID, 外键 -> PropertyLayout.LayoutID)
      • 经纪人编号(AgentID)

    • 房源标签 (PropertyTag)

      • 标签ID (TagID, 主键)
      • 标署名 (TagName)

    • 房源-标签关联表 (Property_Tag)

      • 关联ID (RelationID, 主键)
      • 房源ID (PropertyID, 外键 -> Property.PropertyID)
      • 标签ID (TagID, 外键 -> PropertyTag.TagID)

    • 房源户型 (PropertyLayout)

      • 户型ID (LayoutID, 主键)
      • 户型描述 (LayoutDescription)

    • 房源图片 (PropertyImage)

      • 图片ID (ImageID, 主键)
      • 房源ID (PropertyID, 外键 -> Property.PropertyID)
      • 图片路径 (ImagePath)

    • 地区 (Area)

      • 地区ID (AreaID, 主键)
      • 地区名称 (AreaName)

    • 楼盘 (Building)

      • 楼盘ID (BuildingID, 主键)
      • 地区ID (AreaID, 外键 -> Area.AreaID)
      • 楼盘名称 (BuildingName)
      • 地址 (Address)

    • 经纪人 (Agent)

      • 经纪人ID (AgentID, 主键)
      • 姓名 (Name)
      • 接洽方式 (ContactInfo)

    • 经纪人楼盘 (Agent_Building)

      • 关联ID (RelationID, 主键)
      • 经纪人ID (AgentID, 外键 -> Agent.AgentID)
      • 楼盘ID (BuildingID, 外键 -> Building.BuildingID)


  • 关系描述

    • 用户与用户登录日志:一对多关系,一位用户可以有多条登录日志。
    • 用户与浏览记录:一对多关系,一位用户可以有多个浏览记录。
    • 浏览记录与房源:多对一关系,一条浏览记录对应一个房源。
    • 房源与房源标签:多对多关系,通过Property_Tag关联表实现。
    • 房源与户型:多对一关系,一种户型可以对应多个房源。
    • 房源与图片:一对多关系,一个房源可以有多个图片。
    • 楼盘与地区:多对一关系,一个地区可以包含多个楼盘。
    • 经纪人与楼盘:多对多关系,通过Agent_Building关联表实现。

在这个物理数据模型中,我们定义了每个表的主键和外键,并指定了数据类型。物理数据模型如下图:




免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

tsx81428

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表