数据库性能优化方案

数据库性能优化方案

目录

L前言...........................................................................2

2.为什么数据库会慢？..........................................................2

3.应该站在哪个层面思考优化？..................................................3

3.1.概述......................................................................3

3.2.八大方案总结..............................................................4

3.3.减少数据量................................................................5

3.4.数据归档..................................................................5

3.5.中间表（结果表）............................................................6

3.6.数据序列化存储...........................................................7

3.7.分库分表..................................................................8

3.8.分库分表•拆分方式.........................................................8

3.9.路由方式..................................................................9

3.10.分布式缓存.............................................................11

3.11.避免滥用缓存............................................................12

3.12.避免缓存击穿............................................................12

3.13.不是所有慢查询都适用...................................................13

3.14.一主多从............................................................13

3.15.选择合适的存储系统.....................................................14

3.16.命令查询分离............................................................15

3.17.数据同步方式............................................................16

3.18.替换（选择）存储系统......................................................17

4.合理的数据模型设计...........................................................17

4.1.10种主数据模型设计示例................................................18

4.1.1.人员主数据璞型.....................................................18

4.1.2.账户主数据碳型.....................................................20

4.1.3.组织主数据膜型.....................................................21

4.1.4.客商主数据续型.....................................................23

4.1.5.客户主数据模型.....................................................23

4.1.6.供应商主数据模型...................................................24

4.1.7.渠道主数据模型.....................................................25

4.1.8.产品主数据碳型.....................................................26

第1页共31页

4.1.9.物料主数据♦型.....................................................28

1.前言

毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个

系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套

成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够

快速准备解决咱么日常遇到的80%甚至90%的性能问题。

从解决问题的角度出发，我们得先了解到问题的原因；其次我们得有一套

思考、判断问题的流程方式，让我们合理的站在哪个层面选择方窠；最后从众

多的方案里面选择一个适合的方案进行解决问题，找到一个合适的方案的前提

是我们自己对各种方案之间的优缺点、场景有足畛的了解，没有一个方案是完

全可以通吃通用的，软件工程没有银弹。

下文的我工作多年以来，曾经使用过的八大方窠，结合了平常自己学习收

集的一些资料，以系统、全面的方式整理成了这篇博文，也希望能让一些有需

耍的同行在工作上、成长上提供一定的帮助。

2.为什么数据库会慢？

慢的本质

查找的时间复杂度查找算法

存储数据结构

数据总量数据拆分

高负载CPU、磁盘繁忙

无论是关系型数据库还是NoSQL,任何存储系统决定于其查询性能的主要

有三种：

1）查找的时间复杂度

2）数据总量

3）高负载

而决定于查找时间复杂度主要有两个因素:

1）查找算法

第2页共31页

2）存储数据结构

无论是哪种存储，数据量越少，自然查询性能就越高，随着数据量增多，

资源的消耗（CPU、磁盘读写繁忙）、耗时也会越来越高。

从关系型数据库角度出发，索引结构基本固定是B+Tree,时间复杂度是

O（logn）,存储结构是行式存储。因此咱们对于关系数据库能优化的一般只有

数据量。

而高负载造成原因有高并发请求、复杂查询等，导致CPU、磁盘繁忙等，

而服务器资源不足则会导致慢查询等问题。该类型问题一般会选择集群、数据

冗余的方式分担压力。

3.应该站在哪个层面思考优化?

3.1.概述

第3页共31页

从下图可见，自顶向下的一共有四层，分别是硬件、存储系统、存储结

构、具体实现。层与层之间是紧密联系的，每一层的上层是该层的载体；因此

越往顶层越能决定性能的上限，同时优化的成本也相对会比较高，性价比也随

之越低。以最底层的具体实现为例，那么索引的优化的成本应该是最小的，可

以说加了索引后无论是CPU消耗还是响应时间都是立竿见影降低；然而一个简

单的语句，无论如何优化加索引也是有局限的，当在具体实现这层没有任何优

化空间的时候就得往上一层【存储结构】思考，思考是否从物理表设计的层面

出发优化（如分库分表、压缩数据量等），如果是文档型数据库得思考下文档聚

合的结果；如果在存储结构这层优化得没效果，得继续往再上一次进行考虑，

是否关系型数据库应该不适合用在现在得业务场景？如果要换存储，那么得换

怎样得NoSQL?

所以咱们优化的思路，出于性价比的优先考虑具体实现，实在没有优化空

间了再往上一层考虑。当然如果公司有钱，直接使用钞能力，绕过了前面三

层，这也是一种便捷的应急处理方式。

该篇文章不讨论顶与底的两个层面的优化，主要从存储结构、存储系统中

间两层的角度出发进行探讨。

性能匕限

3.2.八大方案总结

第4页共31页

方案总览

数据类

方案类型方案描述收益类型应对场景

型

数据序列化存静态数

减少数据量短期收益大数据量

储据

中期收

数据归档动态数据大数据量

益

长期收大数据量、高负

中间表生成静态数据

益载

长期收大数据量、高负

分库分表动态数据

益载

静态数

用空间换性能分布式缓存短期收益高负载

据

中期收

一主多从动态数据高负载

益

选择合适的存储系动态数大数据量、高负

CQRS长期收益

统据载

数据库的优化方案核心本质有三种：减少数据量、用空间换性能、选择合

适的存储系统，这也对应了开篇讲解的慢的三个原因：数据总量、高负载、查

找的时间复杂度。

这里大概解释下收益类型：短期收益，处理成本低，能紧急应对，久了则

会有技术债务；长期收益则跟短期收益相反，短期内处理成本高，但是效果能

长久使用，扩展性会更好。

静态数据意思是，相对改动频率比较低的，也无需过多联表的，where过

滤比较少。动态数据与之相反，更新频率高，通过动态条件筛选过滤。

3.3.减少数据量

减少数据量类型共有四种方案：数据序列化存储、数据归档、中间表生

成、分库分表。

就如上面所说的，无论是哪种存储，数据量越少，自然查询性能就越高，

随着数据量增多，资源的消耗（CPU、磁盘读写繁忙）、耗时也会越来越高。目

前市面上的NoSQL基本上都支持分片存储，所以其天然分布式写的能力从数

据量上能得到非常的解决方案。而关系型数据库，查找算法与存储结构是可以

优化的空间比较少，因此咱们一般思考出发点只有从如何减少数据量的这个角

度进行选择优化，因此本类型的优化方案主要针对关系型数据库进行处理。

3.4.数据归档

第5页共31页

做法场景优点缺点

利用数据库作业，定时把历史局部的热结构无需改热点数据过多仍

数据移到历史表或者库点数据动，少侵入性会导致性能问题

注意点：别一次性迁移数量过多，建议低频率多次限量迁移。像MySQL

由于删除数据后是不会释放空间的，可以执行命令OPTIMIZETABLE释放存储

空间，但是会锁表，如果存储空间还满足，可以不执行。

建议优先考虑该方案，主要通过数据库作业把非热点数据迁移到历史表,

如果需要查历史数据，可新增业务入口路由到对应的历史表（库卜

Order

OrderlDUserIDMoneyCreateDateTime

1125108.552022-3-18

212599.52022-1-5

312561992021-12-15

优化前

Order

OrderlDUserIDMoneyCreateDateTime

II108.552022-3-18

OrderHistory（三个月前）

OrderlDUserIDMoneyCreateDateTime

212599.52022-1-5

312561992021-12-15

优化后判子国山后为

x_J

3.5.中间表（结果表）

做法场景优点缺点

压缩

通过调度任务定时，把某个业务报表型、排行需要开发人员针对

比率

以多个维度进行聚合分组榜等静态数据场景业务进行开发

大

中间表（结果表）其实就是利用调度任务把复杂查询的结果跑出来存储到一

张额外的物理表，闪为这张物理表存放的是通过跑批汇总后的数据，囚此可以

第6页共31页

理解成根据原有的业务进行了高度的数据压缩。以报表为例，如果一个月的源

数据有数十万，我们通过调度任务以月的维度生成，那么等于把原有的数据压

缩了几十万分之一；接下来的季报和年报可以根据月报*N来进行统计，以这种

方式处理的数据，就算三年、五年甚至十年数据量都可以在接受范围之内，而

且可以精确计算得到。

那么数据的压缩比率是否越低越好？下面有一段口诀：

字段越多，粒度越细，灵活性越高，可以以中间表进行不同业务联表处

理。

字段越少，粒度越粗，灵活性越低，一般作为结果表查询出来。

3.6.数据序列化存储

做法场景优点缺点

把一对多的数据，通过序不需要要求所有字段作压缩比序列化的字段

列化字符串存储为结构化存储率高无法联表

UserBuyChapter

RecordIDUserIDChapterlDMoneyCreateDateTime

110513002022-3-18

210526002022-2-2

优化前

UserBuyChapter(自定义)

RecordIDUserIDChapterinfo

11051,300,1647532800|2,600,1643731200

UserBuyChapter(JSON)

RecordIDUserIDChapterinfo

({chapterid:1,monery:300,createdatetime:

11051647532800),(chapterid:1Jmonery:

300,createdatetime:1647532800}]

在数据库以序列化存储的方式，对于一些不需要结构化存储的业务来说是

一种很好减少数据量的方式，特别是对于一些M*N的数据量的业务场景，如

果以M作为主表优化，那么就可以把数据量维持最多是M的量级。另外像订

第7页共31页

单的地址信息，这种业务一般是不需要根据里面的字段检索出来，也比较适

合。

这种方案我认为属于一种临时性的优化方案，无论是从序列化后丢失了部

份字段的查询能力，还是这方案的可优化性都是有限的。

3.7.分库分表

分库分表作为数据库优化的一种非常经典的优化方案，特别是在以前

NoSQL还不是很成熟的年代，这个方案就如救命草一般的存在。

如今也有不少同行也会选择这种优化方式，但是从我角度来看，分库分表

是一种优化成本很大的方案。这里我有几个建议：

分库分表是实在没有办法的办法，应放到最后选择。

优先选择NoSQL代替，因为NoSQL诞生基本上为了扩展性与高性能。

究竟分库还是分表？量大则分表，并发高则分库

不考虑扩容，一部做到位。因为技术更新太快了，每3-5年一大变。

3.8.分库分表■拆分方式

拆分方式角度优点

垂直拆分按照业务拆分降低业务耦合度

减少字段，物理页所拥有的行数则变多

水平拆分从物理层面分片从根本上减少数据量

只要涉及到这个拆，那么无论是微服务也好，分库分表也好，拆分的方式

主要分两种：垂直拆分、水平拆分。

垂直拆分更多是从业务角度进行拆分，主要是为了降低业务耦合度；此外

以SQLServer为例，一页是8KB存储，如果在一张表里字段越多，一行数据

自然占的空间就越大，那么一页数据所存储的行数就自然越少，那么每次查询

所需要10则越高因此性能自然也越慢；因此反之，减少字段也能很好提高性

能。之前我听说某些同行的表有80个字段，几百万的数据就开始慢了。

水平拆分更多是从技术角度进行拆分，拆分后每张表的结构是一模一样

的，简而言之就是把原有一张表的数据，通过技术手段进行分片到多张表存

储，从根本上解决了数据量的问题。

第8页共31页

User

UserIDNickNamePhonePointVipLV

11898856158410003

2得小贞189885615335002

1-------------------

Usei>ember

UserIDNickNamcPhoneUwrlDPointVipLV

118988561S84110003

2号J'贞1898856153325002

知乎@blnesky

User

UserIDNickNamePhonePointVipLV

r—1除埃1898856158410003

2取、贞189885615335002

User1

UserIDNickNamePhonePointVipLV

11898856158410003

User2

UserIDNickNamePhonePointVipLV

2现'贞189885615335002

水平拆分知乎@i>E”ky

3.9.路由方式

算法优点缺点

查询定位比较容

区间范围容易造成数据不平均(热点数据)

易

容易忘记创建新

表

必须带分区键，不带分区键则会所有表都扫描

Hash分片均匀

一遍

进行水平拆分后，根据分区键(shardingkey)原来应该在同一张表的数据拆

解写到不同的物理表里，那么查询也得根据分区键进行定位到对应的物理表从

而把数据给查询出来。

路由方式一般有三种区间范围、Hash、分片映射表，每种路由方式都有自

第9页共31页

己的优点和缺点，可以根据对应的业务场景进行选择。

区间范围根据某个元素的区间的进行拆分，以时间为例子，假如有个业务

我们希望以月为单位拆分那么表就会拆分像table_2022-04,这种对于文档

型、ElasticSearch这类型的NoSQL也适用，无论是定位查询，还是日后清理维

护都是非常的方便的。那么缺点也明显，会因为业务独特性导致数据不平均，

甚至不同区间范围之间的数据量差异很大。

Hash也是一种常用的路由方式，根据Hash算法取模以数据量均匀分别存

储在物理表里，缺点是对于带分区键的查询依赖特别强，如果不带分区键就无

法定位到具体的物理表导致相关所有表都查询一次，而且在分库的情况下对于

Join、聚合计算、分页等一些RDBMS的特性功能还无法使用。

Order

OrderlDUserIDMoneyCrcatcDatcTimc

1105108.552022-3-18

212599.52022-1-5

32161992021-12-15

Hash(Userid)%2

OrderUseri

OrderlDUserIDMoneyCreateDateTime

1105108.552022-3-18

22161992021-12-15

Order_User2

OrderlDUserIDMoneyCreateDateTime

I99.5，*202215

125

一般分区键就一个，假如有时候业务场景得用不是分区键的字段进行查

询，那么难道就必须得全部扫描一遍？其实可以使用分片映射表的方式，简单

来说就是额外有一张表记录额外字段与分区键的映射关系。举个例子，有张订

单表，原本是以UserID作为分I乂键拆分的，现在希望用OrdeHD进行查询,

那么得有额外得一张物理表记录了OrderlD与UserID的映射关系。因此得先

查询一次映射表拿到分区键，再根据分区键的值路由到对应的物理表查询出

来。可能有些朋友会问，那这映射表是否多一个映射关系就多一张表，还是多

第10页共31页

个映射关系在同一张表。我优先建议单独处理，如果说映射表字段过多，那跟

不进行水平拆分时的状态其实就是一致的，这又跑回去的老问题。

用空间换性能

该类型的两个方窠都是用来应对高负载的场景，方案有以下两种：分方式

缓存、一主多从。

与其说这个方案叫用空间换性能，我认为用空间换资源更加贴切一些。因

此两个方案的本质主要通数据冗余、集群等方式分担负载压力。

对于关系型数据库而言，因为他的ACID特性让它天生不支持写的分布式

存储，但是它依然天然的支持分布式读。

3.10.分布式缓存

做法场景缺点

动态条件比较多的业务场

CacheAside应对高并发读

景，缓存命中低

伪静态数据（业务配置、低实时性要求高的数据场景，

时效的数据）处理起来比较花功夫

缓存层级可以分好几种：客户端缓存、API服务本地缓存和分布式缓存，

咱们这次只聊分布式缓存。一般我们选择分布式缓存系统都会优先选择NoSQL

的键值型数据库，例如Memcached、Redis,如今Redis的数据结构多样性，

第11页共31页

高性能，易扩展性也逐渐占据了分布式缓存的主导地位。

缓存策略也主要有很多种：Cache-Aside、Read/Wirte-Through^Write-

缓存应该是按需使用，从28法则来看，80%的性能问题由主要的20%的

功能引起。滥用缓存的后果会导致维护成本增大，而且有一些数据一致性的问

题也不好定位。特别像一些动态条件的查询或者分页，key的组装是多样化

的，量大又不好用keys指令去处理，当然我们可以用额外的一个key把记录

数据的key以集合方式存储，删除时候做两次查询，先查Key的集合，然后再

遍历Key集合把对应的内容删除。这一顿操作下来无疑是非常废功夫的，谁弄

谁知道。

ValueI

KeyValueKey

b»ok:pag«2:sizc1OJastcstbook：dag«2:sizc10:hstcst(0.01

bookkeysbookbock:p>9<2:slz«10:updaUbook：pag«2:»iMl0:update知乎

b»ok:p»g«1book:OiUfteft(O.UJ

3.12.避免缓存击穿

当缓存没有数据，就得跑去数据库查询出来，这就是缓存穿透。假如某个

时间临界点数据是空的例如周排行榜，穿透过去的无论查找多少次数据库仍然

第12页共31页

是空，而且该查询消耗CPU相对比较高，并发一进来因为缺少了缓存层的对高

并发的应对，这个时候就会因为并发导致数据库资源消耗过高，这就是缓存击

穿。数据库资源消耗过高就会导致其他查询超时等问题。

该问题的解决方窠也简单，对于查询到数据库的空结果也缓存起来，但是

给一个相对快过期的时间。有些同行可能又会问，这样不就会造成了数据不一

致了么？一般有数据同步的方案像分布式缓存、后续会说的一主多从、CQRS,

只要存在数据同步这兀个字，那就意味着会存在数据一致性的问题，因此如果

使用上述方案，对应的业务场景应允许容忍一定的数据不一致。

3.13.不是所有慢查询都适用

一般来说，慢的查询都意味着比较吃资源的〔CPU、磁盘I/O）。举个例子，

假如某个查询功能需要3秒时间，串行查询的时候并没什么问题，我们继续假

设这功能每秒大概QPS为100,那么在第一次查询结果返回之前，接下来的所

有查询都应该穿透到数据库，也就意味着这几秒时间有300个请求到数据库，

如果这个时候数据库CPU达到了100%,那么接下来的所有查询都会超时，也

就是无法有第一个查询结果缓存起来，从而还是形成了缓存击穿。

3.14.一主多从

场景优点缺点

应急调整方便，单以运维直接解高硬件成

分担数据库读压力

决。本

还没找到更好的降低数据库负载的临

扩展性有限

时方案

常用的分担数据库压力还有一种常用做法，就是读写分离、一主多从。咱

们都是知道关系型数据库天生是不具备分布式分片存储的，也就是不支持分布

式写，但是它天然的支持分布式读。一主多从是部署多台从库只读实例，通过

冗余主库的数据来分担读请求的压力，路由算法可有代码实现或者中间件解

决，具体可以根据团队的运维能力与代码组件支持视情况选择。

一主多从在还没找到根治方案前是一个非常好的应急解决方案，特别是在

现在云服务的年代，扩展从库是一件非常方便的事情，而且一般情况只需要运

维或者DBA解决就行，无需开发人员接入。当然这方案也有缺点，因为数据

无法分片，所以主从的数据量完全冗余过去，也会导致高的硬件成本。从库也

有其上限，从库过多了会主库的多线程同步数据的压力。

第13页共31页

数据库集群中间件

一三

MySQL-Slaver-1

§®

MySQL-MasterMySQL-Slaver-2MyCatWebAPI

MySQL-Slaver-3如手@bluesh

3.15.选择合适的存储系统

NoSQL主要以下五种类型：键值型、文档型、列型、图型、搜素引擎，不

同的存储系统直接决定了查找算法、存储数据结构，也应对了需要解决的不同

的业务场景。NoSQL的出现也解决了关系型数据库之前面临的难题（性能、高

并发、扩展性等）。

例如，ElasticSearch的查找算法是倒排索引，可以用来代替关系型数据库

的低性能、高消耗的Like搜索（全表扫描）。而Redis的Hash结构决定了时间

复杂度为0（1），还有它的内存存储，结合分片集群存储方式以至于可以支撑数

十万QPSo

因此本类型的方案主要有两种：CQRS、替换（选择）存储，这两种方案的最

终本质基本是一样的主要使用合适存储来弥补关系型数据库的缺点，只不过切

换过渡的方式会有点不样。

第14页共31页

3.16.命令查询分离

CQS（命令查询分离）指同一个对象中作为查询或者命令的方法，每个方法

或者返回的状态，要么改变状态，但不能两者兼备

场景优点缺点

高

需要保留关系型数据库的使用，又硬

成

原应用改动范围比较小，兼容旧业件

要使用的高性能与可扩展

NoSQL本

务，只需要替我读的底层。

性

数

即保留了关系型数据库的ACID特据

同

允许非实时的数据场景性，又使用NoSQL的可扩展性与高步

性能

讲解CQRS前得了解CQS,有些小伙伴看了估计还没不是很清晰，我这里

第15页共31页

用通俗的话解释：某个对象的数据访问的方法里，要么只是查询，要么只是写

入（更新）。而CQRS（命令查询职责分离）基于CQS的基础上，用物理数据库来写

入（更新），而用另外的存储系统来查询数据。因比我们在某些业务场景进行存

储架构设计时，可以通过关系型数据库的ACID特性进行数据的更新与写入，

用NoSQL的高性能与扩展性进行数据的查询处理，这样的好处就是关系型数

据库和NoSQL的优点都可以兼得，同时对于某些业务不适于一刀切的替换存

储的也可以有一个平滑的过渡。

从代码实现角度来看，不同的存储系统只是调用对应的接口API,因此

CQRS的难点主要在于如何进行数据同步。

3.17.数据同步方式

CQRS实现方式

方式实时性方案类型优点缺点

CDC［变更数据捕无业务侵入，解决多

推高额外中间件

获）业务入口

领域事可读性需要在框架代码层

件心面处理

物理删除无法识别，

拉低调度任务定时同步同CDC

只能全量

一般讨论到数据同步的方式主要是分推和拉:

推指的是由数据变更端通过直接或者间接的方式把数据变更的记录发送到

接收端，从而进行数据的一致性处理，这种主动的方式优点是实时性高。

拉指的是接收端定时的轮询数据库检查是否有数据需要进行同步，这种被

动的方式从实现角度来看比推简单，因为推是需要数据变更端支持变更日志的

推送的。

而推的方式又分两种：CDC（变更数据捕获）和领域事件。对于一些旧的项

目来说，某些业务的数据入口非常多，无法完整清晰的梳理清楚，这个时候

CDC就是一种非常好的方式，只要从最底层数据库层面把变更记录取到就可。

对于己经服务化的项目来说领域事件是一种比较舒服的方式，因为CDC是

需要数据库额外开启功能或者部署额外的中间件，而领域事件则不需要，从代

码可读性来看会更高，也比较开发人员的维护思维模式。

第16页共31页

3.18.替换（选择）存储系统

因为从本质来看该模式与CQRS的核心本质是一样的，主要是要对NoSQL

的优缺点有一个全面认识，这样才能在对应业务场景选择与判断出一个合适的

存储系统。这里我像大家介绍一本书马丁•福勒《NoSQL精粹》,这本书我重

复看了好几遍，也很好全面介绍各种NoSQL优缺点和使用场景。

当然替换存储的时候，我这里也有个建议：加入一个中间版本，该版本做

好数据同步与业务开关，数据同步要保证全量与增加的处理.，随时可以重来，

业务开关主要是为了后续版本的更新做的一个临时型的功能，主要避免后续版

本更新不顺利或者因为版本更新时导致的数据不一致的情况出现。在跑了一段

时间后，验证了两个不同的存储系统数据是一致的后，接卜来就M以把数据访

问层的底层调用替换了。如此一来就可以平滑的更新切换。

4.合理的数据模型设计

确定业务需求：在设计数据仓库之前，深入了解企业的业务需求和数据分

析目标，明确需要支持的查询和报表。这有助于构建合理的数据模型，满足实

际的业务需求。

规范化设计：采用规范化的设计可以消除数据冗余，并保持数据一致性。

通过合理地划分表和定义关系，避免数据更新异常和不一致问题。

考虑性能需求：在设计数据模型时，需要预估数据量和查询复杂度，并根

据业务需求进行适当的优化。例如，选择合适的索引和分区策略，提高查询效

率。

第17页共31页

4.1.10种主数据模型设计示例

主数据模型是主数据管理的基础，一个完整的、可扩展的、相对稳定的主

数据模型对于主数据管理的成功起着重要的作用。规划、创建主数据模型的过

程，是梳理主数据管理体系的过程，目的是建立一个良好的资源目录结构，划

分合理的资源粒度。

4.1.1.人员主数据模型

人员主数据是企业基础和核心的主数据之一，我们在人力资源管理系统及

相关的模块中都要使用，如招聘、培训、考核、薪资等模块。另外，OA系

统、业务系统也会使用人员主数据。

第18页共31页

序号属性名称数据类型维护方式属性类型填写说明

编码方案参照

1人员编码（工号）字符W填写用础属性人力资源管理部

门相关规定

2姓名字符型填写基础屈性

参照选项为

3性别参照型卜•拉选项盛础属性

男、女、其他

4出生日期字符型填写基础属性

参照选项为身

5证件类型参照理卜拉选项基础属性份证、军官证、

护照

按照证件上的

6证件号码字符型填写基础屈件

号码进行填写

7手机号码字符型填写基础属性

8办公电话字符型填写基础属性

9电子邮件字符型填写基础屈性

参照选项为在

10人员状态参照型卜.拉选项业务属性职、离职、退休、

实习生、临时匚

11岗位信息字符理填写业务属性对照岗位档案

12职级参照型卜.拉选项业务属性对照职级档案

对照企业人员

13人员类别参照型下拉选项业务属性类别档案（如管

理类、技术类等）

对应管理组织

14所属管理组织马照型下拉选项业务屈件

主数据

对应管理部门

15所属管理部门参照型卜拉选项业务属性

主数据

16—

表1人员主数据模型示例

表1是人员主数据的常规模型，基本上包含了人员档案的相关信息。这个

人员主数据模型包含了人员档案的基木属性信息［第一项至第九项），业务属性

第19页共31页

信息（第十项至第十五项），对应着参照数据、枚举数据，以及引用的其他主数

据。

4.1.2.账户主数据模型

账户的定义是「企业信息系统的使用者」，同时我们希望能够从企业视角

进行统一的账户主数据管理。

序号属性名称数据类型维护方式填写说明

用户身份认证时所需要输入

1用户名字符型填写

的名称

2■M字符利9s

3密级

4密码策略

5用户所属管理组织参照型下拉选项对应管理组织主数据

6用户所属管理部门参照型下拉选项对应管理部门主数据

参照选项为1.本企业人员

7用户类别参照型卜一拉选项账户；2.本企业角色账户；3.非

本企业人员账户

8对应人员编码参照型下拉选项

9对应人员姓名字符型填写

10证件类型参照型F拉选项

当用户类型为“1”时.字

11证件号码字符型填写

段信息与人员主数据的信息

12不机号码字符型填写

保持一致

13办公电话字符型填写

14电子邮件字符型填写

15岗位信息字符型填写

16白定义项।字符型填写

17—4**.1-/Y■；、・

表2账户主数据模型示例

账户主数据的常规模型，基本上包含了系统中「账户」档案的主要属性字

段。企业在构建账户主数据模型时可以以此为参考。

在账户主数据模型中，我们可以看到「对应人员编码」一对应人员姓

第20页共31页

名」，以及一些对应人员的其他相关字段，这些字段的内容来源于对应的人员

主数据。此种设计没有完全遵循数据库设计的三范式，因为在数据模型中冗余

了部分人员主数据的属性。而在很多应用系统中，账户模型和人员模型被构建

在同一个表中，这是为了让各个系统能够很好地使用账户主数据模型才采用的

折中设计方法，当然也可以根据企业实际情况进行针对性设计。

4.1.3.组织主数据模型

企业中的组织是指企'也为了实现一定的目标，互相协作结合而成的团体。

通常组织既包含公司层级的内容又包含公司里的多级部门甚至小组的内容。而

这样的组织也会由于视角的不同产生多个版本，如行政组织、财务组织、股权

组织、法人组织等。

行政组织是从企业管理的视角进行划分的组织结构；财务组织是完全以财

务的视角进行核算、统计、考核，从而建立的组织结构；其他组织则是从各自

的视角进行划分的组织结构。大型集团型企业的组织主数据较多，单体型企业

的组织主数据相对少一些。

第21页共31页

序号属性名称数据类型维护方式填写说明

用户身份认证时所需要输入

1组织编码字符型填写

的名称

2组织名称字符型填写

3上级组织字符暨填写

4组织类别字符型填写1.单位；2.部门

5组织负责人编码字符型填写

6地址字符型填写

7电话字符型填写

8邮箱