数据模型设计要点
数据库数据模型设计与规范
数据库数据模型设计与规范数据库是组织和存储数据的重要工具，而数据模型则是数据库设计的核心部分。
一个好的数据模型设计可以提高数据库的性能和可扩展性，并确保数据的完整性和一致性。
本文将介绍数据库数据模型设计的原则和规范，并提供一些实用的技巧和建议。
一、概述数据库数据模型是描述数据库中数据结构和关系的图形化表示。
它通过定义实体、属性和关系的方式，帮助我们理解和组织数据。
一个合理的数据模型应该满足以下几个基本要求：1. 数据完整性：确保数据的准确性和一致性，避免数据冗余和不一致的情况。
2. 数据访问性能：优化数据库的读写操作，提高数据库的响应速度。
3. 数据扩展性：便于数据库的升级和扩展，适应业务的变化和发展。
4. 数据安全性：确保数据库的数据不会被非法访问、篡改或丢失。
二、数据模型设计原则在进行数据库数据模型设计时，需要遵循以下几个原则：1. 规范化：通过规范化设计，将数据库中的数据分解成更小的表，减少数据冗余，提高数据的一致性。
2. 实体和属性的定义：确定数据库中的实体和属性，并为它们分配适当的数据类型和长度。
3. 主外键关系：通过定义主外键关系，建立不同表之间的连接，确保数据之间的一致性和完整性。
4. 索引的使用：为数据库中的常用查询字段添加索引，加快查询的速度。
5. 数据安全性：在数据库设计中考虑数据的安全性，包括用户权限管理、数据加密等。
三、数据库数据模型设计规范在实际进行数据库数据模型设计时，还需要遵守一些规范和约定，以确保数据库的可读性和可维护性。
1. 表和字段命名规范：使用有意义的表和字段名称，避免使用过长或过于复杂的名称。
可以使用下划线或驼峰命名法。
2. 主键设计：每个表都应该有一个主键来唯一标识每条记录。
常见的主键设计方式包括自增主键、GUID、业务相关的唯一标识等。
3. 字段类型和长度的选择：根据具体业务需求，选择合适的字段类型和长度。
避免使用过大或过小的字段长度，浪费存储空间或导致数据溢出。
数据模型构建步骤
数据模型构建步骤数据模型是一个描述现实世界中的事物和关系的抽象工具，它在数据库设计和管理中扮演着重要的角色。
本文将介绍数据模型构建的基本步骤，包括需求分析、概念设计、逻辑设计和物理设计等。
一、需求分析在进行数据模型构建之前，我们首先需要进行需求分析。
需求分析旨在明确用户的需求和业务规则，为后续的数据建模提供基础。
在需求分析阶段，我们可以采用各种方法，如面谈、观察和文档分析等，以获取尽可能全面的需求信息。
二、概念设计概念设计是数据模型构建的第二个步骤，它的目的是建立实体、关系和约束等概念模型。
在概念设计阶段，我们可以使用实体关系图（ER图）等工具来描述现实世界中的事物及其之间的关系。
此外，还可以使用实体属性关系图（EER图）来扩展ER图的表达能力。
在进行概念设计时，我们要注意以下几点：1. 确定实体：通过分析需求，识别出现实世界中的实体，如人、物、事件等。
2. 确定关系：确定实体之间的关系，包括一对一、一对多和多对多等。
3. 定义属性：为实体和关系定义属性，用于描述其特征和行为。
4. 确定约束：确定实体和关系之间的约束条件，如主键、外键和参照完整性约束等。
三、逻辑设计逻辑设计是数据模型构建的第三个步骤，它的目的是将概念模型转化为与具体数据库管理系统（DBMS）相关的数据模型，如关系模型或面向对象模型等。
在逻辑设计阶段，我们需要根据实际情况选择适合的数据模型，并进行细化和优化。
在进行逻辑设计时，我们要注意以下几点：1. 选择数据模型：根据项目需求和技术要求，选择适合的数据模型，如关系模型、面向对象模型或者面向文档模型等。
2. 划分表结构：将概念模型中的实体和关系转化为具体的表结构，并确定字段的数据类型、长度和约束等。
3. 确定索引：根据查询需求和性能要求，确定表的索引策略，并创建相应的索引。
4. 规范化设计：对表结构进行规范化，以保证数据的一致性和完整性。
四、物理设计物理设计是数据模型构建的最后一个步骤，它的目的是确定数据库的物理存储结构，包括表空间、数据文件和日志文件等。
新的数据模型注意事项
新的数据模型注意事项在构建新的数据模型时，需要注意以下几点：数据来源和质量：确保所使用的数据来自可靠的来源，并且数据质量高，包括准确性、完整性和一致性。
避免使用噪声、异常值和缺失数据，因为它们可能会影响模型的性能。
数据理解：在构建模型之前，需要充分了解数据的特征、分布和潜在的偏差。
这包括数据的来源、类型、结构以及它们之间的关系。
培养数据敏感性是非常重要的。
选择合适的模型：基于数据的特性和分析目标，选择恰当的模型。
不同的模型有不同的假设，例如线性关系、分布形式等。
理解模型的适用范围和限制，以确保所选模型能够准确地描述数据。
考虑数据性能和效率：在设计数据模型时，需要关注数据的处理性能和效率。
合理地选择索引、优化查询语句，并使用合适的数据类型和存储方式来提高数据处理效率。
避免过度冗余和不必要的数据存储，以减小系统负担，提高系统的响应速度和运行效率。
文档和说明：为数据模型编写详细的文档和说明，包括模型结构、属性定义、关系图、命名约定等。
这有助于开发人员、管理员和用户更好地理解和使用数据模型。
验证和测试：在部署新的数据模型之前，需要进行充分的验证和测试。
这包括检查模型的准确性、稳定性和性能等方面。
确保模型在实际应用中能够达到预期的效果。
监控和维护：在数据模型投入使用后，需要定期监控其性能和稳定性，并根据实际情况进行调整和优化。
同时，需要对数据模型进行维护，包括更新、修复和扩展等，以确保其长期稳定运行。
总之，构建新的数据模型需要综合考虑多个方面，包括数据来源、质量、特性、模型选择、性能效率、文档说明、验证测试以及监控维护等。
只有充分考虑这些因素，才能构建出准确、高效、稳定的数据模型，为业务决策提供有力支持。
数据库中的数据模型与设计
数据库中的数据模型与设计摘要本文将介绍数据库中的数据模型与设计，包括概念模型、逻辑模型和物理模型，以及如何进行数据库设计。
数据模型是数据库设计的基础，它可以帮助我们理解数据的结构、关系和用途。
1.数据模型的定义数据模型是一种描述系统中数据组织、存储和处理方式的形式化表示。
它是数据库设计的基础，用于描述数据模式和数据结构，以及数据之间的关系。
其中，数据模式是指数据在数据库中的存储方式，包括实体、属性和关系，而数据结构则是指数据的组织方式，包括表、字段和索引等。
数据之间的关系包括一对一、一对多和多对多等。
2.数据模型的分类数据模型可以分为三个层次：概念模型、逻辑模型和物理模型。
其中，概念模型是最高层次的数据模型，用于描述数据的概念和业务规则；逻辑模型是中间层次的数据模型，用于描述数据的结构和关系；而物理模型则是最低层次的模型，用于描述数据在计算机系统中的存储和表示方式。
3.概念模型概念模型是数据库设计的第一步，它用于描述问题域中的概念和业务规则，不涉及到具体的数据库管理系统。
概念模型通常用E-R图表示，其中，E-R图基于实体-关系模型，用于描述实体、属性和关系之间的联系。
实体指问题域中的某个对象，例如学生、教师和课程等；属性指实体所具有的某个特征，例如学生的姓名、年龄和性别等；而关系指实体之间的某种联系，例如学生和课程之间的选课关系等。
4.逻辑模型逻辑模型是在概念模型基础上进一步精细化的数据模型，可以转化为具体的数据库管理系统。
逻辑模型通常用关系模型表示，其中，关系模型基于关系代数和谓词逻辑，用于描述数据的结构和关系。
关系模型由表、字段和索引组成，其中，表用于存储数据，字段用于定义数据的属性，索引用于优化数据的访问。
5.物理模型物理模型是数据库设计的最后一步，用于确定数据在计算机系统中的存储和表示方式。
物理模型通常用DDL语言表示，其中DDL是数据定义语言的缩写，用于定义数据库中的表、字段、索引和约束等。
数据模型设计方法
数据模型设计方法数据模型指的是抽象意义上的数据结构，在这个结构中可以描述数据的各个方面，包括数据的类型、属性、关系等等。
在设计数据模型的过程中，关键问题是如何有效地描述数据的本质特征，并且为数据构建可靠的结构，以使得数据的存储和管理变得更加容易和高效。
下面将介绍一些常用的数据模型设计方法。
1. 实体-关系模型实体-关系（ER）模型是最常见的数据模型之一，它描述了一个系统中的实体和实体之间的关系。
实体可以是现实中的人、物、事物等，也可以是计算机系统中的实体，如文件、用户等；而关系则定义了这些实体之间的联系，可以是一对一、一对多或多对多的关系。
实体-关系模型有助于描述数据的本质特征，可以在数据的不同方面建立一个模型，使得数据之间的关系更加清晰。
同时，它也提供了一个面向对象的数据模型，可以为对象的属性和方法提供一个良好的定义，实现了数据和应用程序的分离。
2. 第一范式模型第一范式模型是关系数据库模型的一种基本形式，它强制要求每个表中的所有数据都是原子性的，也就是说每个表中只能存储一个单一值的数据，不能包含复杂数据结构。
第一范式模型的优点在于保持了数据的简洁性和一致性，并且可以避免数据冗余和不必要的重复。
但缺点是无法处理复杂的数据结构，可能需要多个表才能刻画一个实体。
第二范式模型继承了第一范式模型的特点，同时要求所有的非主属性都必须完全依赖于主键（也就是键的全部属性），而不是部分属性。
如果某个非主属性仅仅依赖于部分主键，那么它就会存在数据冗余，违背了第二范式模型的要求。
第二范式模型的优点是保证了数据之间的高度一致性，并且消除了重复数据，方便了数据的管理和维护。
但它可能产生了更多的表，需要消耗更多的数据和存储空间。
第三范式模型要求每个非主属性都必须完全依赖于主键，而不是依赖于其他非主属性。
也就是说，每个字段都只存储一种数据，避免了数据的重复和冗余。
第三范式模型的优点是数据的条目很明确，表中每个字段只有一个含义，避免歧义并方便数据的管理和维护。
系统数据库概念模型设计
系统数据库概念模型设计介绍在计算机系统中，数据库是一种用于储存和组织数据的系统。
概念模型设计是数据库设计过程中的一环，它用于描述数据库的结构、组织和数据的关系。
本文将详细讨论系统数据库概念模型设计的过程和要点。
数据库概念模型数据库概念模型是用于描述数据库中数据存储和结构的方式。
它不依赖于任何特定的数据库管理系统或实现细节，而是提供了一种抽象的视图。
数据库概念模型通常包括实体-关系模型（Entity-Relationship Model）和层次模型（Hierarchical Model）等。
实体-关系模型实体-关系模型是一种用于描述实体之间关系的数据模型。
在实体-关系模型中，实体可以表示具体的对象，例如人、产品等，它们具有各自的属性，比如姓名、价格等。
关系表示实体之间的联系，例如人和产品之间的购买关系。
实体-关系模型使用图形符号来表示实体和关系，其中矩形表示实体，椭圆形表示属性，菱形表示关系。
层次模型层次模型是一种以树状结构组织数据的数据模型。
在层次模型中，数据按照父子关系进行组织，每个节点可以有多个子节点。
根节点表示顶级数据，叶节点表示最底层的数据。
层次模型适合描述具有明确层级关系的数据，例如文件系统中的文件夹和文件。
系统数据库概念模型设计的步骤系统数据库概念模型设计过程通常包括以下步骤：需求分析、概念模型设计、验证和修改。
需求分析在需求分析阶段，设计人员与用户讨论并确定数据库所需的功能和数据要求。
设计人员需要了解业务流程、数据流转和数据关系，以便能够准确理解用户需求和设计数据库的结构。
概念模型设计在概念模型设计阶段，设计人员使用合适的数据模型来描述数据库的结构和关系。
设计人员可以使用实体-关系模型等工具来绘制概念模型的图示，以便更好地展示实体、属性和关系之间的关系。
实体识别和属性设计在设计实体时，设计人员需要确定具体的实体类型，并为每个实体类型定义属性。
属性是实体具有的特征或性质，例如人的属性可以包括姓名、性别、年龄等。
数据库的数据模型设计与规范
数据库的数据模型设计与规范随着信息技术的不断发展，数据库的应用越来越广泛，并且成为了现代企事业单位信息系统的核心组成部分。
而数据库的数据模型设计与规范则是数据库设计与开发的重要环节，在保证数据一致性、完整性和可靠性的基础上，合理地组织和管理数据。
一、数据模型的概念与分类数据模型是数据库设计的基础，它是对现实世界中的问题和实体之间关系的抽象表达。
根据数据模型的实际应用需求，目前主要有以下几种数据模型：1. 层次模型：层次模型是现代数据库系统的起源，它使用树形结构描述数据的组织方式。
2. 网状模型：网状模型在层次模型的基础上进行扩展，通过使用“指针”来描述数据之间的关系，解决了层次模型无法处理多对多关系的问题。
3. 关系模型：关系模型是目前最常用和成熟的数据模型，它通过使用二维表格的形式，用行代表记录，用列代表属性，通过主键和外键来建立表与表之间的关系，实现数据的组织和管理。
4. 面向对象模型：面向对象模型是在关系模型的基础上发展起来的，它将概念和行为进行封装，通过类、对象和继承等概念来解决实体间的关联和继承关系。
在实际应用中，关系模型是最常用的一种数据模型，其简洁直观、易于理解和操作的特点，使其成为了数据库设计的首选。
二、数据库设计的步骤及规范数据库设计是指将现实世界中的数据转化为数据库系统中的数据结构和操作规则的过程。
一个合理的数据库设计应该具备以下步骤和规范：1. 需求分析与概念设计：在进行具体的数据库设计之前，需要对实际应用需求进行全面的分析，明确数据库系统的目标和功能。
然后通过E-R图等工具对数据进行抽象和建模，从而获取数据库的概念设计。
2. 逻辑设计：逻辑设计是在概念设计的基础上进行的，通过使用实体关系图（ER图）来描述数据之间的逻辑关系，确定各个实体的属性、类别及其之间的关系。
3. 物理设计：物理设计是根据逻辑设计的结果，进一步确定数据库的具体实施方法和技术手段，包括数据库的键的选择、索引设计、存储过程和触发器的设计等。
数据库设计时如何合理规划数据模型
数据库设计时如何合理规划数据模型在当今数字化的时代，数据库成为了各类应用系统的核心组成部分。
一个良好的数据库设计不仅能够提高数据的存储和检索效率，还能确保数据的完整性、一致性和安全性。
而在数据库设计中，合理规划数据模型是至关重要的一步。
首先，我们要明确业务需求。
这就好比在建造房屋之前，需要清楚知道房屋的用途、居住人数以及功能要求等。
在数据库设计中，我们需要与业务部门深入沟通，了解他们的业务流程、数据操作方式以及对数据的使用需求。
例如，一个电商平台需要存储商品信息、用户信息、订单信息等，而一个医院管理系统则需要存储患者信息、病历信息、医疗设备信息等。
只有明确了这些业务需求，我们才能为后续的数据模型规划提供准确的方向。
接下来，进行概念模型设计。
概念模型是对现实世界的抽象描述，它不涉及具体的数据库实现技术，而是专注于描述实体、属性以及它们之间的关系。
以一个学校管理系统为例，实体可以是学生、教师、课程、班级等，属性则是每个实体所具有的特征，如学生的姓名、年龄、学号等。
关系则包括学生与课程的选课关系、教师与班级的授课关系等。
通过绘制 ER 图（实体关系图）等工具，可以清晰地展现概念模型。
在完成概念模型设计后，就可以进入逻辑模型设计阶段。
逻辑模型是概念模型在具体数据库管理系统中的实现，常见的逻辑模型有关系模型、层次模型和网状模型等，目前关系模型应用最为广泛。
在关系模型中，我们将概念模型中的实体转化为表，属性转化为列，关系则通过外键来实现。
例如，在上述学校管理系统中，学生表可能包含学号、姓名、年龄等列，课程表可能包含课程号、课程名、学分等列，而选课表则通过学生的学号和课程的课程号作为外键来建立学生与课程之间的选课关系。
在设计数据表时，需要合理确定字段的数据类型。
数据类型的选择不仅影响数据的存储效率，还可能影响数据的查询和更新性能。
例如，对于整数类型，如果存储的值范围较小，可以选择 tinyint 或 smallint 类型，而如果值范围较大，则需要选择 int 或 bigint 类型。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据模型设计要点目录1.数据模型设计的输入42.数据模型设计必须的几个阶段42.1.概念数据模型设计（Conceptual Data Model） (4)2.2.逻辑数据模型设计（Logical Data Model） (6)2.2.1.设计范式要求62.2.1.1.第一范式62.2.1.2.第二范式72.2.1.3.第三范式82.2.1.4.逆第三范式102.2.2.其他要求102.2.2.1.数据类型定义102.2.2.2.实体名称定义102.2.2.3.主键定义102.2.2.4.实体关系定义112.2.2.5.数据量估算112.2.2.6.索引定义112.3.物理数据模型（Physical Data Model） (11)2.3.1.物理库设计122.3.1.1.数据库Server设计122.3.1.2.表空间设计122.3.1.3.用户及权限设计122.3.2.物理表设计122.3.2.1.数据类型设计122.3.2.2.存储设计132.3.2.3.主外键设计132.3.2.4.索引设计132.3.2.5.生成建表语句133.数据模型设计相关工具软件134.数据模型设计的产出及规格要求144.1.概念数据模型设计阶段 (14)4.2.逻辑数据模型设计阶段 (14)4.3.物理数据模型设计阶段 (14)1.数据模型设计的输入传统的瀑布型的开发模型下，其特点是需求驱动。
相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。
分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。
但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。
其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。
2.数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。
其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。
这三个阶段并不是完全单向的，而是可以反向调整。
假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。
但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。
2.1.概念数据模型设计（Conceptual Data Model）本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。
该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。
该阶段工作非常重要，是进行其他阶段工作的基础。
各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索，但不应该需求中提到什么名词就在模型中设计什么实体，更不应该需求中没有提到某些名词之间的关系，模型中就根本不考虑对应实体之间的关系。
概念模型设计过程，实际上是以概念实体为线索，对需求分析结果进行测试的过程。
需求分析工作的质量好不好，在此工作中基本能得到初步验证。
概念模型设计过程中提取的概念实体，可能比业务领域中的多，也可能比业务领域中的少，关键看归纳和抽象的粒度。
并且，这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。
完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。
比如一个OCRM 系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词，据此可以提取出以下业务实体和实体间的关系：Relationship_1Relationship_2Relationship_3Relationship_4年度营销任务日常营销任务（例行）计划营销任务营销方案营销团队虽然用户可能没有提出日常营销任务是否需要营销方案，但通过分析，这种情况是有可能的，所以可以在设计概念模型时，可以将日常营销任务与营销方案的关系设置为1-0,1。
这样，即便是未来发生需求的变化，数据模型也可以迅速提供支持。
2.2.逻辑数据模型设计（Logical Data Model）此阶段开始关注概念实体的各项属性。
该阶段还不必更多考虑实现时的物理数据库方面的要求。
设计逻辑数据模型时，需注意参考必要的设计范式要求。
常用的设计范式简单列举其要点并举例如下（以学生选课为例）：2.2.1.设计范式要求2.2.1.1.第一范式目的：实现属性的原子性——属性不可再分，属性不能重复；不符合第一范式的设计：符合第一范式的设计：2.2.1.2.第二范式目的：实现属性的完全依赖——属性唯一依赖于主键，不能依赖于主键的一部分。
基于第一范式结果进行修改，使其符合第二范式：1）定义SNO+CNO为主键；2）将不完全依赖这个主键的属性剥离到独立的表中；新创建学生表：新创建教师表：新创建课程表：2.2.1.3.第三范式目的：消除传递依赖。
属性不依赖于其他非主属性。
基于第二范式结果进行修改，将涉及传递依赖的属性也剥离出去，使其符合第三范式：学生表：教师表：课程表：新创建成绩表：由上例子可以看出，为使设计成本和收益达到平衡，具体使用时不可能全部符合第三范式，一般大部分表能够符合第二范式就可以。
2.2.1.4.逆第三范式特别在统计分析系统的数据模型设计过程中，还会有针对性的特别进行大量的“逆第三范式”的处理。
在传统的OLTP系统中，同样也也会存在逆第三范式的处理。
典型的例子是核心业务系统中的交易流水表。
之前该表一般设计为只记录经办柜员的柜员号，但后来随着交易量大幅增加，为提高查询效率，后来在新的核心业务系统设计中，一般把柜员名称冗余在此表中。
在数据分析应用中，这种情况就更多了，只要设计比较清晰，并购清楚知道哪些字段是冗余过来的，并且与来源表的数据类型严格保持一致即可。
2.2.2.其他要求2.2.2.1.数据类型定义逻辑数据模型中需明确数据类型和精度，对使用较多的数据类型，必要时可定义Domain来进行元数据的统一。
2.2.2.2.实体名称定义需明确逻辑实体的中文名称和英文名称，需建立必要的命名规范。
2.2.2.3.主键定义需明确定义各逻辑实体的主键和唯一索引。
从之前各范式的目的和使用描述来看，定义主键和唯一索引是必须的过程，否则谈不上进行第二、第三范式处理。
尽量采用属性或属性的组合做为主键，至少为其指定唯一索引。
物理设计时，根据效率等各方面要求进行取舍，决定到底是用有业务含义的属性做为主键还是用无业务含义的序列号字段做主键。
2.2.2.4.实体关系定义逻辑数据模型中需明确各逻辑实体之间的关系。
该工作是概念数据模型设计工作的延续，还是以业务领域的业务实体间的关系为线索对关联关系进行细化定义，而不是无原则地乱去分析，或者从程序查询角度分析，甚至仅从数据加工处理角度分析。
该工作包括两层含义：1）定义逻辑实体之间的关联类型明确定义各表之间的关联关系：1-1、1-多，多-1，多-多。
假设存在孤立，毫无关联的表，则需仔细分析其存在的必要性。
2）定义逻辑实体之间的主外键对照关系具体进行物理设计时可斟酌是否真正以外键的范式实现，但此阶段必须先定义，否则极易出现该关联的字段数据类型不一致，至少会造成关联查询的问题。
2.2.2.5.数据量估算分析各逻辑实体的存储量和每日记录增长量。
2.2.2.6.索引定义设计逻辑实体的目的就是为了查询，所以为提高查询效率，为逻辑实体指定索引是必须的设计步骤。
在此阶段，可基于各表的使用特点为其指定索引，指定的索引如果是组合索引，需明确其字段顺序。
由于索引的设置方法与最终物理数据库的设计方法有关，所以也可将索引定义的工作移到物理设计时再进行。
2.3.物理数据模型（Physical Data Model）物理数据模型设计是在逻辑数据模型设计的基础上，结合具体使用的物理数据库平台，对物理实体的存储特性进行特别设计，同时包括对索引的优化工作。
物理数据模型设计需进行的工作分别描述如下。
2.3.1.物理库设计2.3.1.1.数据库Server设计数据库server的标识。
是独立server还是共用server，是独立instance还是共用instance。
数据库必须进行哪些特殊设置：需修改哪些数据库级参数，哪些instance级参数，哪些session级参数。
可能的参数包括：查询堆参数、共享内存参数、优化级别、锁个数、buffer size、buffer number，等等。
如果手工修改，需给出操作手册；如果程序修改，需提供程序。
2.3.1.2.表空间设计数据库涉及哪些表空间（tablespace/dbs），其用途如何？每个表空间由哪些物理文件（Datafile/Chunk）组成？其大小，所属用户/用户组，权限，操作系统绝对路径如何？系统默认临时表空间为哪个？索引表空间应该与数据表空间分别使用不同的硬盘。
如何创建表空间，手工方式下需提供操作手册；程序方式下需提供程序。
2.3.1.3.用户及权限设计数据库中设计哪些用户？其权限如何，密码如何，密码是否存在定期修改的要求？如何创建用户，手工方式下需提供操作手册；程序方式下需提供程序。
2.3.2.物理表设计2.3.2.1.数据类型设计明确定义各物理实体属性字段的数据类型，同类的数据类型可考虑在数据库平台中建立必要的Domain或别名，以进行统一。
将数据类型固定在几个有限的取值范围内，避免随便定义新的类型或新的精度。
2.3.2.2.存储设计设计物理表存储在哪个表空间内。
设计物理表的初始化块和后续块大小。
根据需要，对物理表进行分区设计。
根据修改动作的多少，为物理表设计适合的水位线（WaterMark），以减少存储碎片的产生。
2.3.2.3.主外键设计定义物理表的主键，若是组合主键，定义字段的先后顺序。
定义表的外键。
2.3.2.4.索引设计设计需要的索引，若是组合索引，定义字段的先后顺序。
若设计了索引数据表空间，将索引定义到该空间内。
为提高查询效率，可为单个表设计多个索引。
2.3.2.5.生成建表语句物理设计完成，需生成建表语句。
3.数据模型设计相关工具软件数据模型设计相关的工具软件很多，选择余地很大，但工具再强大，也需要人去用，工具本身并不能帮助进行数据模型设计，甚至在方法不当的情况下还会起反作用。
需明确工具的使用规范，以最终统一和提高产出工件的标准化和质量。