Atitit db model 数据库快速建模法 开发效率 目录 1. 结构（数据）设计 行为（处理）设计： 1 2. 业务建模阶段 1 2.1. Ui建模法，根据表单字段建立表字段 2 2.2.

Atitit db model 数据库快速建模法  开发效率

 

目录

1. 结构（数据）设计 行为（处理）设计： 1

2. 业务建模阶段 1

2.1. Ui建模法，根据表单字段建立表字段 2

2.2. 3. 实体建模法  根据现实中的表单建模 2

3. 设计方法推荐 具体物理建模 2

3.1. 2） 用约束而非商务规则强制数据完整性 3

3.2. 5） 采用视图 3

3.3. Free scheme  多用json字段 3

3.4. 数据适当冗余 反范式设计 3

3.5. 定义数据（如数据类型、大小和默认值）。 3

3.6. 确保数据的完整性（使用业务规则和验证检查）。 3

4. 表设计原则 4

4.1. 1） 标准化和规范化 4

4.2. 2） 数据驱动 4

4.3. 3） 考虑各种变化  json字段多使用， 4

4.4. 4） 每个表中都应该添加的3 个有用的字段 时间 版本 任务 4

4.5. 7） 选择数字类型和文本类型尽量充足 5

4.6. 8） 增加删除标记字段 5

5. 流程建模 5

5.1. Sp n Edd trigger 5

6. Ref 5

 

1.  结构（数据）设计 行为（处理）设计：

数据库设计应该与应用系统设计相结合

结构（数据）设计：设计数据库框架或数据库结构

行为（处理）设计：设计应用程序、事务处理等

1.  业务建模阶段

在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。

因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。

同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。

 

 

 

业务建模一般是view group报表组合表

也可能是单表模式

 

 

1. 1. Ui建模法，根据表单字段建立表字段
   2. 3. 实体建模法  根据现实中的表单建模

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法

 

 

 

1. 设计方法推荐 具体物理建模

 

1. 1. 2） 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

1. 1. 5） 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

 

1. 1. Free scheme  多用json字段

只有索引的字段独立处理啊，其他都用json ext

 

 

1. 1. 数据适当冗余 反范式设计

相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余

 

1. 1. 定义数据（如数据类型、大小和默认值）。
   2. 确保数据的完整性（使用业务规则和验证检查）。

定义操作过程（如安全检查和备份）。

选择数据存储技术（如关系、分层或索引存储技术）。

 

 

 

2. 表和字段的设计（数据库逻辑设计）

1. 表设计原则
   1. 1） 标准化和规范化

 事实上，为了效率的缘故，对表不进行标准化有时也是必要的。

1. 1. 2） 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

1. 1. 3） 考虑各种变化  json字段多使用，

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则

1. 1. 4） 每个表中都应该添加的3 个有用的字段 时间 版本 任务

dRecordCreationDate，在VB 下默认是Now（），而在SQL Server · 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT · USER

nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因 　·

1. 1.  7） 选择数字类型和文本类型尽量充足

在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。

而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

1. 1. 8） 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

1. 流程建模
   1. Sp n Edd trigger

 

1. Ref

Atitit 数据建模的技术总结

 

Atitit 数据建模的技术总结

 

目录

1. 数据建模 1

2. 常见建模技术 2

2.1. 电子表格程序 计算机辅助设计 (CAD)  2

2.2. Er图 2

3. 建模方法 2

3.1. . 范式建模法（Third Normal Form，3NF） 2

3.2. 2. 维度建模法 2

3.3. 3. 实体建模法 3

4. 建模过程中的主要活动包括： 3

4.1. 确定数据及其相关过程（如实地销售人员需要查看在线产品目录并提交新客户订单）。 3

4.2. 定义数据（如数据类型、大小和默认值）。 3

4.3. 确保数据的完整性（使用业务规则和验证检查）。 3

4.4. 定义操作过程（如安全检查和备份）。 3

4.5. 选择数据存储技术（如关系、分层或索引存储技术）。 3

5. 建模过程中，我们需要经历一般四个过程： 3

5.1. 业务建模领域建模逻辑建模物理建模 3

6. 数据仓库的发展大致经历了这样的三个过程： 4

6.1. 简单报表阶段： 4

6.2. 数据集市阶段： 4

6.3. 数据仓库阶段： 4

7. 问题注意 4

7.1. Fremmschame 4

7.2. 数据适当冗余 反范式设计 4

8. 图 8. 业务建模阶段 4

8.1. 业务建模一般是view group报表组合表 5