数据模型设计要点
数据模型设计原则
数据模型设计原则数据模型设计原则是数据库设计的基础，它直接决定了数据库的稳定性、可靠性和性能。
在数据模型设计过程中，需要遵循以下原则：1. 数据库应该符合实际业务需求，而不是数据库技术本身的限制。
因此，在设计数据库之前应该认真分析业务需求和业务流程，了解业务数据的属性、关系及其使用规律。
2. 数据库表之间的关系要符合实际业务逻辑，保证数据的完整性和一致性。
在确定表间关系时，需要根据业务实际情况进行合理设计，如使用外键、触发器等技术手段保证数据一致性。
3. 数据库表结构要尽量简化，避免过于复杂的关系和字段。
一般来说，数据库表的设计应遵循最小化原则，字段尽量与业务相关联，避免冗余字段。
4. 数据库的设计应考虑数据量的估算和增长，保证数据库的扩展性和可维护性。
需要考虑定期维护和备份数据，以保证数据安全和可靠性。
5. 数据库设计中，应尽量避免使用模糊字段和模糊查询，避免数据冗余、不一致、重复等问题。
应该选择符合数据规范、数据类型、数据精度的字段，保证数据准确性和完整性。
6. 数据库表的设计应遵循规范，采用统一标准的表名、字段名、数据类型、索引等属性，避免重复名称、拼写错误、数据类型不一致等问题。
7. 在设计数据库时，应该避免过度设计，不过度使用技术手段。
数据库设计要符合业务需求和业务规模的实际情况，不应该因为技术而过度复杂，导致难以维护或系统性能下降。
总之，数据库设计是一项系统复杂的工作，需要遵循以上原则和经验，经过精心设计和提前测试，确保数据库的高效运行和数据的稳定性。
一位优秀的内容创作者，应该了解和掌握数据库设计原则，为读者提供高质量的有关数据库的内容。
数据库数据模型设计与规范
数据库数据模型设计与规范数据库是组织和存储数据的重要工具，而数据模型则是数据库设计的核心部分。
一个好的数据模型设计可以提高数据库的性能和可扩展性，并确保数据的完整性和一致性。
本文将介绍数据库数据模型设计的原则和规范，并提供一些实用的技巧和建议。
一、概述数据库数据模型是描述数据库中数据结构和关系的图形化表示。
它通过定义实体、属性和关系的方式，帮助我们理解和组织数据。
一个合理的数据模型应该满足以下几个基本要求：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.1.数据模型设计1.1.1模型设计思路数据模型是指用实体、属性及其关系对企业运营和管理过程中涉及的所有业务概念和逻辑规则进行统一定义、命名和编码。
数据模型是业务人员、IT人员和开发商之间进行沟通的一套语言。
概念模型、逻辑模型、物理模型在设计过程中的主要关注点如下：概念数据模型是高阶的数据模型，主要展现数据主题之下的数据实体，并展现数据实体之间的关联关系。
逻辑数据模型是对数据实体的分解细化成为逻辑实体，对数据实体的属性、属性类型、长度和主外键关系等做了定义，遵从“第三范式”以达到最小的数据冗余。
物理数据模型是结合数据存储的物理实现，定义物理实体，描述数据模型的细节，需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素，并对数据冗余与性能进行平衡。
1.1.2模型设计规范1.1.2.1.表名命名规范1.数据库表的命名以是名词的复数形式且都为小写，如cities, categories, friends等等2.如果表名由几个单词组成，则单词间用下划线(“_”)分割，如subscribed_pois,poi_categories等3.表名尽量用全名4.表名限制在30个字符内。
当表的全名超过30字符时，可用缩写来减少表名的长度，如description –>desc；information –> info；address –> addr等1.1.2.2.表字段命名规范1.字段名为小写2.字段名为有意义的单词，或单词的缩写3.如果字段由几个单词组成，则单词间用下划线(“_”)分割，如client_id，post_code等4.字段名限制在30个字符内。
当字段名超过30字符时，可用缩写来减少字段名的长度，如description –>desc；information –> info；address –> addr等1.1.2.3.索引命名规范1.索引须按照IDX_table_<column>_<column>,其中<table>是建立索引的表名，<column>是建立索引的字段名2.索引名限制在30个字符内。
数据模型设计的思路
数据模型设计的思路数据模型设计是指在构建数据库系统时，对数据进行结构化和组织的过程。
一个好的数据模型设计能够确保数据库系统的高效性、可靠性和易用性。
在进行数据模型设计时，需要考虑到数据的存储、查询和更新等方面，以及数据之间的关系和约束。
在进行数据模型设计之前，需要对系统的需求进行分析。
了解系统的功能、业务流程和数据的特点，明确系统需要存储哪些数据以及数据之间的关系。
在进行数据模型设计时，常用的方法是采用实体关系模型（Entity-Relationship Model）或面向对象模型（Object-Oriented Model）。
实体关系模型通过实体、属性和关系来描述数据，面向对象模型则通过类、属性和关联来描述数据。
根据具体需求和技术选型，选择合适的模型进行设计。
在进行实体关系模型设计时，首先需要确定实体和实体之间的关系。
实体可以是现实世界中的人、物、事件等，通过属性来描述实体的特征。
关系可以是实体之间的联系，通过关系类型和关系约束来描述关系的性质和限制。
在进行面向对象模型设计时，需要确定类和类之间的关联。
类是具有相同属性和方法的对象的集合，通过属性来描述类的特征。
关联是类之间的关系，通过关联类型和关联约束来描述关联的性质和限制。
在进行数据模型设计时，需要考虑到数据的完整性和一致性。
通过定义各种约束条件来确保数据的正确性，例如主键约束、外键约束、唯一约束和检查约束等。
同时，还需要考虑到数据的性能和扩展性。
通过合理地分解数据和优化查询，提高系统的性能和可扩展性。
在进行数据模型设计时，需要慎重考虑数据的冗余和范式化。
冗余是指在不同的地方存储相同的数据，范式化是指将数据分解成更小的单元。
冗余可以提高查询性能，但会增加数据更新的复杂性和数据一致性的难度。
范式化可以提高数据的一致性和更新的简便性，但会增加数据的查询复杂性。
在进行数据模型设计时，还需要考虑到数据的安全性和隐私保护。
通过合理地定义用户角色和权限，限制用户对数据的访问和操作。
系统数据库概念模型设计
系统数据库概念模型设计介绍在计算机系统中，数据库是一种用于储存和组织数据的系统。
概念模型设计是数据库设计过程中的一环，它用于描述数据库的结构、组织和数据的关系。
本文将详细讨论系统数据库概念模型设计的过程和要点。
数据库概念模型数据库概念模型是用于描述数据库中数据存储和结构的方式。
它不依赖于任何特定的数据库管理系统或实现细节，而是提供了一种抽象的视图。
数据库概念模型通常包括实体-关系模型（Entity-Relationship Model）和层次模型（Hierarchical Model）等。
实体-关系模型实体-关系模型是一种用于描述实体之间关系的数据模型。
在实体-关系模型中，实体可以表示具体的对象，例如人、产品等，它们具有各自的属性，比如姓名、价格等。
关系表示实体之间的联系，例如人和产品之间的购买关系。
实体-关系模型使用图形符号来表示实体和关系，其中矩形表示实体，椭圆形表示属性，菱形表示关系。
层次模型层次模型是一种以树状结构组织数据的数据模型。
在层次模型中，数据按照父子关系进行组织，每个节点可以有多个子节点。
根节点表示顶级数据，叶节点表示最底层的数据。
层次模型适合描述具有明确层级关系的数据，例如文件系统中的文件夹和文件。
系统数据库概念模型设计的步骤系统数据库概念模型设计过程通常包括以下步骤：需求分析、概念模型设计、验证和修改。
需求分析在需求分析阶段，设计人员与用户讨论并确定数据库所需的功能和数据要求。
设计人员需要了解业务流程、数据流转和数据关系，以便能够准确理解用户需求和设计数据库的结构。
概念模型设计在概念模型设计阶段，设计人员使用合适的数据模型来描述数据库的结构和关系。
设计人员可以使用实体-关系模型等工具来绘制概念模型的图示，以便更好地展示实体、属性和关系之间的关系。
实体识别和属性设计在设计实体时，设计人员需要确定具体的实体类型，并为每个实体类型定义属性。
属性是实体具有的特征或性质，例如人的属性可以包括姓名、性别、年龄等。
数据库的数据模型设计与规范
数据库的数据模型设计与规范随着信息技术的不断发展，数据库的应用越来越广泛，并且成为了现代企事业单位信息系统的核心组成部分。
而数据库的数据模型设计与规范则是数据库设计与开发的重要环节，在保证数据一致性、完整性和可靠性的基础上，合理地组织和管理数据。
一、数据模型的概念与分类数据模型是数据库设计的基础，它是对现实世界中的问题和实体之间关系的抽象表达。
根据数据模型的实际应用需求，目前主要有以下几种数据模型：1. 层次模型：层次模型是现代数据库系统的起源，它使用树形结构描述数据的组织方式。
2. 网状模型：网状模型在层次模型的基础上进行扩展，通过使用“指针”来描述数据之间的关系，解决了层次模型无法处理多对多关系的问题。
3. 关系模型：关系模型是目前最常用和成熟的数据模型，它通过使用二维表格的形式，用行代表记录，用列代表属性，通过主键和外键来建立表与表之间的关系，实现数据的组织和管理。
4. 面向对象模型：面向对象模型是在关系模型的基础上发展起来的，它将概念和行为进行封装，通过类、对象和继承等概念来解决实体间的关联和继承关系。
在实际应用中，关系模型是最常用的一种数据模型，其简洁直观、易于理解和操作的特点，使其成为了数据库设计的首选。
二、数据库设计的步骤及规范数据库设计是指将现实世界中的数据转化为数据库系统中的数据结构和操作规则的过程。
一个合理的数据库设计应该具备以下步骤和规范：1. 需求分析与概念设计：在进行具体的数据库设计之前，需要对实际应用需求进行全面的分析，明确数据库系统的目标和功能。
然后通过E-R图等工具对数据进行抽象和建模，从而获取数据库的概念设计。
2. 逻辑设计：逻辑设计是在概念设计的基础上进行的，通过使用实体关系图（ER图）来描述数据之间的逻辑关系，确定各个实体的属性、类别及其之间的关系。
3. 物理设计：物理设计是根据逻辑设计的结果，进一步确定数据库的具体实施方法和技术手段，包括数据库的键的选择、索引设计、存储过程和触发器的设计等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据模型设计要点目录1. 数据模型设计的输入 (4)2. 数据模型设计必须的几个阶段 (4)2.1. 概念数据模型设计（Conceptual Data Model） (5)2.2. 逻辑数据模型设计（Logical Data Model） (6)2.2.1. 设计式要求 (7)2.2.1.1. 第一式 (7)2.2.1.2. 第二式 (7)2.2.1.3. 第三式 (8)2.2.1.4. 逆第三式 (9)2.2.2. 其他要求 (10)2.2.2.1. 数据类型定义 (10)2.2.2.2. 实体名称定义 (10)2.2.2.3. 主键定义 (10)2.2.2.4. 实体关系定义 (10)2.2.2.5. 数据量估算 (11)2.2.2.6. 索引定义 (11)2.3. 物理数据模型（Physical Data Model） (11)2.3.1. 物理库设计 (12)2.3.1.1. 数据库Server设计 (12)2.3.1.2. 表空间设计 (12)2.3.1.3. 用户及权限设计 (12)2.3.2. 物理表设计 (13)2.3.2.1. 数据类型设计 (13)2.3.2.2. 存储设计 (13)2.3.2.3. 主外键设计 (13)2.3.2.4. 索引设计 (13)2.3.2.5. 生成建表语句 (14)3. 数据模型设计相关工具软件 (14)4. 数据模型设计的产出及规格要求 (14)4.1. 概念数据模型设计阶段 (14)4.2. 逻辑数据模型设计阶段 (14)4.3. 物理数据模型设计阶段 (15)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.数据模型设计相关工具软件数据模型设计相关的工具软件很多，选择余地很大，但工具再强大，也需要人去用，工具本身并不能帮助进行数据模型设计，甚至在方法不当的情况下还会起反作用。