第4章 建立逻辑模型
数据库逻辑模型建模方法
数据库逻辑模型建模方法==================在数据库设计过程中，逻辑模型是数据库系统的核心部分，它决定了数据库的结构、行为和数据之间的关系。
以下是一套详细的数据库逻辑模型建模方法：1. 确定数据实体---------首先，需要明确数据库中需要存储的数据实体。
这些实体可能包括人、物、事件等。
例如，在一个电商系统中，我们可能需要有用户、商品、订单等实体。
2. 定义实体属性---------对于每个确定的实体，我们需要定义其属性。
属性是对实体的描述性特征。
例如，用户实体可能包括姓名、年龄、性别等属性。
每个属性都有其数据类型，例如字符串、整数或日期等。
3. 建立实体关系---------确定了实体和属性后，我们需要建立实体之间的关系。
这些关系可能包括一对一（1:1）、一对多（1:N）、多对一（N:1）和多对多（N:N）等。
例如，一个用户可以购买多个商品，这是一种一对多的关系。
4. 设计数据表结构-----------根据确定的实体、属性和关系，我们可以设计出相应的数据表结构。
每个表对应一个实体，而表中的列对应属性。
行则表示具体的实体实例。
表结构需要考虑到易用性、效率和扩展性等因素。
5. 约束关系完整性-----------为了保证数据的完整性，我们需要添加适当的约束条件。
这些约束条件可能包括主键约束、外键约束和唯一约束等。
例如，在用户表中，用户ID可以是主键，确保每个用户有唯一的ID。
6. 考虑查询需求---------在设计逻辑模型时，我们需要考虑到查询需求。
查询是数据库使用中最频繁的操作之一，因此我们需要优化查询语句的性能。
这可能涉及到索引的设计、查询条件的优化等。
7. 权限控制-------在数据库设计中，权限控制是非常重要的一部分。
我们需要根据业务需求，为不同的用户或角色设置不同的权限。
例如，某些用户只能查看自己的订单信息，而管理员可以查看所有用户的订单信息。
8. 性能优化-------最后，我们需要考虑数据库的性能优化。
软件工程-课后小节
第一章本章简要阐述了软件开发的本质，即实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。
在此基础上，概括地介绍了实现这一映射的基本途径，即系统建模。
所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构一系统模型。
因此，模型是一个抽象。
该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。
在软件开发领域，系统模型分为两大类，一类称为概念模型，描述了系统是什么;另一类统称为软件模型，描述了实现概念模型的软件解决方案。
软件模型又可进一步分为设计模型、实现模型和部署模型等。
总之，正确认识软件开发的本质，认识建模的意义，了解模型概念以及模型分类，直接关系到对软件工程开发逻辑、开发途径有关知识的理解、掌握和正确应用。
正如章首语所言:“正确认识软件开发，是从事软件开发实践和软件工程项目管理的思想基础。
”第二章本章首先介绍了需求的定义，即“一个需求是一个‘要予构造’的陈述，描述了待开发产品(或项)功能上的能力、性能参数或者其他性质”，并指出了需求的5个必备的基本性质:必要的(Necessary)，即该需求是用户所要求的;无歧义的(Unambiguous )，即该需求只能用一种方式解释;可测的(Testable)，即该需求是可进行测试的;可跟踪的(Trace-able)，即该需求可从一个开发阶段跟踪到另一个阶段;可测量的(Measurable )，即该需求是可测量的。
需求的5个基本性质可作为需求发现和评估的基础。
其次，为了更好地理解需求，介绍了需求的分类。
软件需求可以分为功能、性能、外部接口、设计约束和质量属性，并把性能、外部接口、设计约束和质量属性这4类需求统称为非功能需求。
除此之外，还给出了功能需求和非功能需求的基本关系。
然后，介绍了5种常用的需求发现技术:自悟(Introspection )、交谈(Individual in-terview )、观察(Observation )、小组会(Group session)和提炼( Extraction)，并指出采用系统化方法，例如，结构化方法和面向对象方法，可使发现的需求基本满足以上5个性质。
概念模型 逻辑模型
概念模型逻辑模型概念模型和逻辑模型是软件开发过程中非常重要的两个概念。
它们旨在帮助开发者更好地理解问题，并在解决问题之前明确问题的本质。
本文将分步骤介绍概念模型和逻辑模型，以及它们在软件开发中的重要性。
第一步：什么是概念模型？概念模型是一种用于捕获特定领域内概念的一组概念结构。
它用来描述领域知识和为用户所理解和使用的领域术语。
概念模型可以帮助开发者更好地理解问题并了解相关知识领域。
此外，概念模型还可以帮助我们更好地与领域用户沟通，并确保开发出的产品能够满足用户需求。
第二步：概念模型的构建过程概念模型的构建过程通常包括以下几个阶段：1. 收集领域信息和需求在开始构建概念模型之前，我们需要先了解相关领域信息和需求。
通过与领域用户沟通，我们可以收集到关于领域的各种信息，例如：业务流程、主要参与者、相关术语以及相关系统所需的功能等。
2. 绘制概念图在了解领域信息和需求之后，我们可以开始绘制概念图。
概念图是概念模型的一部分，它用来描述领域中的各种概念以及它们之间的关系。
通过绘制概念图，我们可以发现领域中存在的模式和规律，并进一步理解领域知识。
3. 定义概念模型在绘制概念图的基础上，我们可以开始定义概念模型，即将概念图转换为形式化的模型。
概念模型通常以实体-关系图形式呈现，它描述了领域中各种实体以及它们之间的关系。
通过定义概念模型，我们可以更好地了解系统的需求，为逻辑模型的构建奠定基础。
第三步：什么是逻辑模型？逻辑模型是一个描述系统要求和业务规则的模型。
它描述了如何实现领域中的概念，包括数据类型、业务规则和处理逻辑等。
逻辑模型通常是基于概念模型进行设计的，并且是程序员和开发团队所需要的模型。
第四步：逻辑模型的构建过程逻辑模型的构建过程通常包括以下几个阶段：1. 定义数据结构在开始构建逻辑模型之前，我们需要确定系统所需的数据结构。
数据结构通常包括实体、属性和关系等。
通过定义数据结构，我们可以更好地理解系统所需的数据存储结构。
逻辑模型的步骤
逻辑模型的步骤逻辑模型的步骤：一、问题定义在进行逻辑模型建立之前，首先需要明确问题的定义。
问题定义是指对研究或解决的问题进行准确定义和界定，明确问题的目标和范围。
在问题定义中，需要明确问题的关键要素和变量，以及它们之间的关系。
问题定义的准确性和清晰度对于后续建立逻辑模型具有重要意义。
二、变量识别在问题定义的基础上，需要识别与问题相关的变量。
变量是指在研究或解决问题过程中可能发生变化的要素。
通过识别变量，可以将问题抽象为多个要素之间的关系，从而更好地理解问题的本质。
变量可以是自变量和因变量，自变量是独立变量，它是影响其他变量的因素；因变量是依赖变量，它受自变量的影响而发生变化。
三、关系建立在变量识别的基础上，需要建立变量之间的关系。
关系是指变量之间的相互作用和影响。
通过建立关系，可以描述变量之间的依赖和影响关系，形成一个完整的逻辑模型。
关系可以是直接关系或间接关系，直接关系是指变量之间的直接影响；间接关系是指变量之间通过其他变量传递影响。
四、模型验证在建立逻辑模型之后，需要对模型进行验证。
模型验证是指通过数据和实证研究来验证逻辑模型的有效性和准确性。
通过对模型的验证，可以评估模型的拟合度和预测能力，检验模型是否符合实际情况。
模型验证可以通过实验、观察、调查等方式进行，以获得可靠的数据支持。
五、模型修正在进行模型验证之后，如果发现模型存在问题或不足，需要对模型进行修正。
模型修正是指根据验证结果对模型进行调整和改进，使模型更加准确和可靠。
修正可以包括添加或删除变量、调整变量之间的关系等。
通过模型修正，可以提高模型的预测能力和解释力，使其更好地适应实际问题。
六、模型应用在模型修正之后，可以将模型应用于实际问题的分析和解决中。
模型应用是指利用已建立和验证的模型对实际问题进行分析和预测。
通过模型应用，可以得出对问题的解释和预测，为决策提供科学依据。
模型应用可以通过计算、仿真、推理等方式进行，以获得对问题的深入理解和洞察。
第四章 数据流图
外部项
操作 员
重复的外部项
4.2 DFD设计 设计
4.2.1 DFD设计步骤 DFD设计步骤 1．先画出顶层DFD； 先画出顶层DFD； DFD 2．逐步分解，画出中间各层DFD； 逐步分解，画出中间各层DFD； DFD 装配平面数据流图。 3．装配平面数据流图。
第一步， 第一步，把系统基本模型加上外部项作为顶 层DFD。 。 1、外部项支持现在顶层；2、可能有多个外 、外部项支持现在顶层； 、 部项。 部项。
4.1.5 外部项
4.1.5 外部项
为了使DFD清楚易懂，我们对加工、数 清楚易懂，我们对加工、 为了使 清楚易懂 据流、文件的命名都力求简单。 据流、文件的命名都力求简单。至于 加工的加工逻辑、 加工的加工逻辑、数据流的数据结构 将在数据字典中定义。 等，将在数据字典中定义。数据字典 一起来描述系统。 和DFD一起来描述系统。 一起来描述系统
4.1.1 DFD使用的符号 使用的符号
DFD中共有四种实体：加工、数据流、文件 中共有四种实体：加工、数据流、 中共有四种实体 和外部项。分别用四种符号表示 和外部项。
4.1.2 加工
加工又称处理亦称变换， 加工又称处理亦称变换，它是对数据流的 操作。 操作。 加工的符号由标识部分、 加工的符号由标识部分、功能描述部分和 功能执行部分组成。 功能执行部分组成。 标识部分用于标注加工编号。 标识部分用于标注加工编号。所有的加工 都必须统一编号，编号应具有唯一性。 都必须统一编号，编号应具有唯一性。编 号要与数据字典一致。 号要与数据字典一致。
第四章
数据流图
新系统的逻辑模型主要是DFD和DD 和 新系统的逻辑模型主要是 1、DFD如何建立？ 如何建立？ 、 如何建立 2、出发点：O＝P(I)。P就是目标系统。 就是目标系统。 、出发点： ＝ 。 就是目标系统 3、方法：分解。 、方法：分解。
数据库设计详细过程,逻辑模型,物理模型
第四章数据库设计4.1 原理数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据。
数据库设计是一个软件项目成功的基石，但很多从业人员都认为，数据库设计其实不那么重要，现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。
因为多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单，其实不然，数据库设计是值得深入研究的，因为其完全决定了系统的优化程度。
完整的数据库设计一般包如下部分：1.需求分析；2.概念结构设计；3.逻辑结构设计；4.物理结构设计；5.验证阶段；6.运行与维护。
在讲解数据库设计之前，先大概的说说数据库系统设计的原则，其实，关于数据库设计的原则，版本居多，不同的人根据不同的场景不同的需求不同的系统去描述，可定会出现不一致，但万变不离其宗，所有数据库设计的原则无例外是为了实现数据库的最优，从这个宗旨出发我们自己探讨出了以下几条关系数据库设计的原则：1.明白自己的系统为OLTP系统还是OLAP系统不同的系统其侧重点是不一样的，OLTP系统最注重的是数据增删改查操作的效率，而OLAP系统注重的是分析处理，所以不同的系统数据库设计也不一样；2.降低对数据库功能的依赖功能的实现，一般要求通过程序来实现，而不是大量的依赖数据库。
3.严格遵从数据库三范式严格遵从数据库三范式，避免数据的冗余等问题产生；4.尽量保证记录的唯一标识存在；5.严格遵循概念模型到逻辑模型的转换规则；6.星型模型、雪花模型的合理运用。
4.1.1 概念结构设计早期的数据库设计，在需求分析阶段后，就直接进行逻辑结构设计，由于此时既要考虑现实世界信息的联系与特征，又要满足特定的数据库系统的约束要求，因而对于客观世界的描述受到一定的限制，同时，由于设计时要同时考虑多方面的问题，也使设计工作变得十分复杂。
1976年P.P.S.Chen提出在逻辑结构设计之前先设计一个概念模型，并提出了数据库设计的实体--联系方法(Entity--Relationship Approach)。
数据建模经典教程-逻辑数据模型
数据建模经典教程-逻辑数据模型逻辑数据模型的说明为了解决特定业务需求⽽形成的业务解决⽅案。
逻辑数据模型以业务需求为基础，忽略软件环境、精简环境等具体问题有关的模型实现的复杂性。
针对⼀个订单输⼊系统，前期已经完成概念数据模型（概念、业务规则、义务范围）。
在理解订单输⼊系统的需求之后，需要创建逻辑数据模型，其中包含需要交付给应⽤程序所使⽤的所有属性和业务规则。
例如，根据概念数据模型可以，⼀位客户（customer）可以订购1个或多个订单（order），⼆逻辑数据模型则需要关注诸如客户姓名、地址、订单号及订购商品等有关客户、订单的细节信息。
关系逻辑模型关系数据模型包括实体以及实体间的关系和属性，如下图：通过“规范化技术”构建关系数据模型需要保证每个属性都是单值，且提供完全的、唯⼀的依赖于主键的事实。
单值：⼀个属性只能包含⼀则信息完全：主键是唯⼀能标识实体实例得到最⼩的属性集合唯⼀：由主键决定的每⼀个属性只提供⼀个事实，即不存在隐藏的依赖。
维度逻辑模型创建维度逻辑模型维度逻辑模型的创建，主要考虑到两⽅⾯：量度计和维度量度计分类：聚集：聚集量度计中存储信息粒度层次⾼于事物粒度，主要服务于报表⼯具原⼦：包括业务中⽤到的最底层的细节数据，事物粒度累积：完成⼀次业务流程需要多长时间，如从开始申请⼀直到完成房屋抵押贷款所经历的时间将被记录在⼀张累计事实表中快照：记录实体⽣命周期中与特定步骤的时间信息与数仓中的周期快照表的定义不同：数仓的周期快照表以规律性的、可预见的时间间隔来记录事实，时间间隔如天、周、⽉等，订单⽇快照表、订单⽉快照表等周期快照表事实的粒度是每个时间段⼀条记录，通常⽐事物事实表的粒度要粗，是在事务型事实表上建⽴的聚集表。
维度分类固定维度：⼜称为0型渐变维度，如性别男或⼥退化维度：维度的属性被转移⾄事实表中多值维度：⽤于属性或字段存在多值的情况，但最好的模型是每个属性单值不齐整维度：在⼀个不齐整的维度表中，⾄少有⼀个成员的⽗成员在该维度表的直接上级维度表中确实收缩维度：略渐变维度（SCD Slowly Changing Dimension）：SCD 1：仅存储当前维度成员的值，⽽忽略值的临时变化SCD 2：需要存储所有维度成员的历史数据SCD 3：仅需要记录维度成员的部分历史信息，如当前状态和最近状态或当前状态和原始状态SCD 6：表⽰复杂维度，该维度的历史可能存在多种变化。
建立逻辑回归模型的步骤
建立逻辑回归模型的步骤逻辑回归是一种广泛应用于分类问题的统计学习方法，适用于解决二分类问题。
下面将介绍建立逻辑回归模型的步骤，以帮助读者更好地理解和应用这一模型。
1. 数据收集和整理在建立逻辑回归模型之前，首先需要收集相关的数据。
数据可以来自于实验观测、问卷调查、数据库等多种途径。
收集到的数据应包括自变量（特征变量）和因变量（分类结果），并进行整理和清洗，确保数据的准确性和完整性。
2. 数据探索和可视化对收集到的数据进行探索性分析，包括数据的统计描述、缺失值处理、异常值处理等。
同时，可以通过绘制直方图、散点图、箱线图等可视化手段，对数据的分布和相关性进行初步观察。
3. 特征选择和变换在构建逻辑回归模型之前，需要对自变量进行特征选择和变换。
特征选择可以使用相关性分析、卡方检验、信息增益等方法，选择与因变量相关性较高的特征。
同时，特征变换可以使用对数变换、标准化等方法，提高模型的稳定性和预测能力。
4. 模型拟合和评估选择合适的逻辑回归模型形式后，需要对模型进行拟合并评估。
拟合模型时，可以使用最大似然估计或牛顿法等优化算法，估计模型的参数值。
评估模型时，可以使用混淆矩阵、ROC曲线、精确率、召回率等指标，对模型的性能进行评价。
5. 模型优化和验证在拟合和评估模型的基础上，可以对模型进行进一步的优化和验证。
模型优化可以通过调整模型参数、引入正则化方法等手段，提高模型的泛化能力和稳定性。
模型验证可以通过交叉验证、留出法等方法，验证模型在新样本上的预测能力。
6. 模型应用和解释根据建立的逻辑回归模型，可以应用于实际问题的预测和解释。
通过对模型参数的解释，可以了解自变量对因变量的影响程度和方向，进而对分类结果进行解释和理解。
总结建立逻辑回归模型的步骤包括数据收集和整理、数据探索和可视化、特征选择和变换、模型拟合和评估、模型优化和验证、模型应用和解释。
通过按照这些步骤进行建模，可以提高模型的准确性和可解释性，为实际问题的分类提供有效的支持。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Contents
• 建立逻辑模型(creating the logical model) • 常见的建模问题(Common Data Modeling Problems) √
19
Common Data Modeling Problems
• 改善数据模型不是件容易的事,需要平衡SQL Server的物理限制并同时满足客户的商业需求. 建 模的过程中,有一些常犯的错误,分几个方面: – Entity Problems √ – Attribute Problems – Relationship Problems
7
IDEF 1X的例子
8
IE Crow’s Feet 的例子
9
Modeling Tools
• 有很多的工具可用,从行业标准工具(如ERWin, ER/Studio等)到一些自由软件. 下边给出建模工具 所必须的功能列表: – Notation: 核心功能,必须支持1种或多种标记法. – Import/Export: 希望达到多种工具能共同操作. – Physical Modeling: 建模工具一般也应提供物 理建模功能.
5
Suggested Naming Guidelines(1)
• 从中可见： – Entities
• 实体名用的复数(Products) • 联系名要能描述建模的对象，例如描述Products和 Vendors之间的联系名为Product vendors
– Attributes
• 单数 • 所有的实体，都加上一个属性ObjectId作为主码 • 要时刻记住，非技术人员至少会读一遍你的模型
17
Building the Model
• 现在要把实体和属性放到图上,标记码和联系,检查 联系的基数并保证正确标记,标记域,保证模型的可 读性和准确性.步骤如下:
– 先画实体图 – 第二步添加主码 (因为联系是基于主码的). – 添加联系,从简单的开始.注意到以前没有主码的实体现 在有了主码. – 再建模基数(Modeling Cardinality),若未标注基数,所用 的建模软件可能会给一个缺省值,可能导致错误的结果. – 确定域,该过程使得添加其他属性变得方便了 – 最后添加属性,注意顺序会影响可读性 • 至此第一版的模型完成
• Suggested Naming Guidelines • Notations Standards • Modeling Tool
– 用需求来建模(Using Requirements to Build the Model) (Using
• • • • Entity List Attribute List Relationships Documentation Business Rules
11
Using Requirements to Build the Model
• 至此,建模的基础工作 – 从基本概念到数据类型, 以及要用到的工具,都清楚了.可以为Mountain View Music (MVM)建立数据模型了. • 先看看如何把需求收集中得到的各数据点映射到 数据模型中的对象上去,以及商业规则的实现. – Entity List – Attribute List – Relationships Documentation – Business Rules
20
Entity Problems
• 主要考察与实体/属性的数量,以及属性与实体正确 配对方面的问题. – 实体太少(Too Few Entities) √ – 实体太多(Too Many Entities)
21
Entity Problems
• 主要考察与实体/属性的数量,以及属性与实体正确 配对方面的问题. – 实体太少(Too Few Entities) √
– 建立模型(Building the Model): 包括实体、联系、域、 属性、主码
3
Diagramming a Data Model
• 提出建模的指导方针和标准，怎样为实体相关对 象命名，怎样用图形来表现，怎样及使用哪些工 具？ – 建议命名的原则(Suggested Naming Guidelines) – 标记法标准(Notations Standards ) – 建模工具(Modeling Tool)
10
建立逻辑模型
• 现在开始要运用前两章介绍的概念来建模了,内容包括: – 把模型图表化(Diagramming a Data Model) • Suggested Naming Guidelines • Notations Standards • Modeling Tool – 用需求来建模(Using Requirements to Build the Model) (Using √ • Entity List • Attribute List • Relationships Documentation • Business Rules – 建立模型(Building the Model): 包括实体、联系、域、 属性、主码
高级数据库开发技术
第4章 creating the logical model
Contents
• 建立逻辑模型(creating the logical model)√ • 常见的建模问题(Common Data Modeling Problems)
2
建立逻辑模型
• 现在开始要运用前两章介绍的概念来建模了,内容包括: – 把模型图表化(Diagramming a Data Model) √
15
Business Rules
• 并不是所有的商业规则都是在数据模型中并直接 在物理数据库中实现. 这里不打算讨论哪些规则应 该在哪儿实现, 致力于属于数据模型的内容,通常 是与数据完整性有关的规则.包括两类: – 数据格式(Data Format) – 数据联系和完整性(Data Relationships and Integrity) • 其他的商业规则的实现位置依赖于项目和数据库 服务器的能力.
13
Attribute List
• 注意存储相同/似数据的属性应保持一致,比如存储 员工电话和公司电话的属性
14
Relationships Documentation
• 事先把联系文档化,在建模时只需输入联系参数. • 先定义最明显的联系(1对1,1对多),再找出超类型 与子类型的联系和多对多的联系. • MVM中的部分联系(只能是部分,完整的列表中每 个实体都会在Parent Entity列出现)
16
建立逻辑模型
• 现在开始要运用前两章介绍的概念来建模了,内容包括: – 把模型图表化(Diagramming a Data Model) • Suggested Naming Guidelines • Notations Standards • Modeling Tool – 用需求来建模(Using Requirements to Build the Model) • Entity List • Attribute List • Relationships Documentation • Business Rules – 建立模型(Building the Model): 包括实体、联系、域、 属性、主码√
28
Common Data Modeling Problems
• 改善数据模型不是件容易的事,需要平衡SQL Server的物理限制并同时满足客户的商业需求. 建 模的过程中,有一些常犯的错误,分几个方面: – Entity Problems – Attribute Problems √ – Relationship Problems
12
Entity List
• 在需求收集时,就应记下某些关键词,通常是名词, 现在要排除那些多余的. • 用一个表格给出MVM需求收集中得到的名词列表 • 多出来的实体是在把实体与实体相互联系,以及线 上系统带来的问题引出的. • 下边只介绍新引入的实体:
– Lists and List Items: 用于支持系统,跟踪运输状态,把所 有订单项的状态与所属货运联系起来.另外,灵活的列表 有利于商业规则的变化.Lists表示需要的信息列表,List Items是列表项的查找表. – 其他新增实体省略
• 有时同一属性希望存储不同类型的数据. • Mountain View需要存储具有不同特征的设备,比 如单簧管没有弦,吉它没有吹口,于是建立的 Products表可能是这个样子:
31
Single Attributes Contain Different Data
25
Entity Problems
• 主要考察与实体/属性的数量,以及属性与实体正确 配对方面的问题. – 实体太少(Too Few Entities) – 实体太多(Too Many Entities) √
• 通常的诱惑是过规范化(overnormalize),这可能导致 性能问题并限制了模型的灵活性.例如:
Байду номын сангаас
26
实体太多的例子
27
Entity Problems
• 主要考察与实体/属性的数量,以及属性与实体正确 配对方面的问题. – 实体太少(Too Few Entities) – 实体太多(Too Many Entities) √
• 通常的诱惑是过规范化(overnormalize),这可能导致 性能问题并限制了模型的灵活性.例如: • 显然此例的形成是规范化的结果,但千万别干这种事, 除非你有充分的理由,比如你在给邮政做一个系统. • 性能和规范化要综合考虑.
• 许多建模人员以简洁/易于使用的名义创建比实际需 要更少的实体,这实际上导致不灵活且不好用. • 若怀疑实体太少,可先检查同一实体中是否有相似的 数据.例如,MVM的Customers实体最初可能是这个 样子: