医药采购系统第2天01：用户管理模块实体表之间的分析&实体间的管理关系&用户查询功能实现&mybatis逆向工程的使用&自定义扩展类和包装类&mapper动态代理的方式开发&datagrid的使用

如果想要获取相关的源码，笔记，和相关工具，增加需求，代码重构，关注我并私信！！！

---

一 用户管理模块的分析

1 用户模型分析

业务是什么？业务就是用户的所有需求。

用户角色：卫生局、卫生院、卫生室、供货商，

系统管理员属于后台.

用户：登陆系统进行业务操作

2 模型图

3 主要实体表关系的分析

3.1 系统用户表SYSUSER

该表记录了系统中所有的用户信息（模型图中的小人就表示用户），包括：卫生局，卫生院，卫生室（医院），供应商，系统管理员。

表中的主要字段包括：

1	id	主键，没有任何业务意义的主键。
2	USERID	账号.
3	USERNAME	名称.
4	GROUPID（重要）	用户类型字段，数值是:0,1,2,3,4. 其中： 0:系统管理员 , 1：卫生局  , 2:卫生院 , 3：卫生室 , 4:供应商. 可以根据GROUPID的值判断所对应的单位. 如果想要查询groupid所对应的类别名称，就需要查询数据字典中的字段（可以查看day03中的内容）！如下图：
5	USERSTATE	用户状态字段，数值是：0,1，这两个数值所对应的名称也要通过查询数据字典中的字段才可知（需查看day03   中的内容）！
6	SYSID（重要，非外键）	该字段很重要，表示用户所属的单位的id。sysid字段关联监督表userjd的主键id，关联医院表userjj的主键id，关联供应商表usergys的主键id。但这种关联不是数据库级别的表与表之间的关联关系，而只是业务之间的关联关系！！！ 注意：该字段并不是一个外键字段，因为如果有一个用户是系统管理员，而系统用户不属于任何一个单位，那么其值必定为null。所以该字段不能也必须不是一个外键字段！

3.2 监督单位表USERJD

（JD是监督二字的首字母大写，这也是一种命名规范，下同）:

该表记录了市卫生局和其下属的所有卫生院的单位信息，这两个机构都属于监督机构，分别管理着不同的地区：

卫生局管理的是全市的多个卫生院，而卫生院管理的是下面的乡镇一级的多个卫生所（医院）。

表中的主要字段：

1) Id：主键，该主键是与SYSUER表中干的sysid相关联的，但这种关联关系是业务级别的，而不是数据库级别之间的关联关系!

2) MC（名称）: 监督单位的名称mc.

3) DQ（地区）：表示管理区域，记录了该监督单位所管理的下级的地区信息。

地区字段id，该字段是外键，关联于行政区域表BSS_SYS_AREA的主键AREAID字段，属于数据库级别的关联关系。如下图：

该字段的值的规则只有两种：XX.XX.或者XX.

这样的命名规则是为了方便管理其行政管理关系.

该字段命名为XX.：则表示是市（一级）卫生局，属于一级级行政单位（参考“行政管理关系”）。

该字段命名为XX.XX.：表示县/乡/镇卫生院(二级)，属于二级行政单位（参考“行政管理关系”）

通过在监督单位表userjd和医院单位表useryy（下面会介绍到）中都添加的一个DQ字段，来管理其行政管理关系（参考“行政区域表”）。

例如下面介绍的医院单位表useryy中的DQ字段。

3.3 医院单位表USERYY

（YY是医院两字的拼音大写，这是命名规范，下同）：

记录了本市所有的卫生室，卫生室就是医院单位，因为与市卫生局和卫生院不同，因此单独建立一张表，主要字段如下：

1) Id：主键，该主键是与SYSUER表中的sysid相关联的，但这种关联关系是业务级别的，不是数据库级别之间的关联关系!

2) MC: 医院单位的名称.

3) LB：医院所属的类别（类型）。该字段关联数据字典明细表dictinfo（在明天的文档中会讲到）的主键id字段。这种关

联关系不是数据库级别的关系，只是业务级别的关系！

4) DQ：所属区域的id。该字段记录了该医院单位所属的上级的监督单位的地区信息，因为医院是最小的行政单位了。

该字段是外键，关联于BSS_SYS_AREA表的主键AREAID字段，属于数据库级别的关联关系。如下图：

该字段的值的规则是：XX.XX.XX.  这样的规则是为了查询方便.

这样的命名规则表示村卫生所（医院），属于三级行政管理单位（参考“行政管理关系”）

例如：

--查询某个乡镇（崔庙镇）下所有的医院的单位信息 select * from useryy where dq like '1.1.%' --查询卫生局下的所有医院的单位信息 select * from useryy where dq like '1.%'

3.4 供应商单位表USERGYS

1) ID：供应商单位主键。该主键是与SYSUER表中干的sysid相关联的，这种关联关系是业务级别的，不是数据库级别之间的关联关系!

2) MC：供应商的单位名称!

3.5 供应商供货区域表USERGYSAREA

记录了供应商所供货的二级（二级就是乡镇一级，参考下面的行政区域表）区域的信息。

因为是医药行业，有很强的行业性：即必须由卫生局来指定供货商所供货的二级区域（即县/乡/镇，关于区域的划分参考下面的行政区域表bss_sys_area）。简单说：一个供货商只能供应一个区域！

主要有以下两个重要字段：

1) USERGYSID：供货商的id，该字段不仅是主键，也是该表的外键，该外键指向了供应商单位表usergys的id主键。属于数据库级别 的关联关 系！！

2) AREAID：区域（地区）的id，是该表的外键，指向了行政区域表BSS_SYS_AREA的AREAID主键.属于数据库级别的关联关系！！

如图：

因此，这两个字段字段都是数据库级别的关联关系！

3.6 行政区域表BSS_SYS_AREA

行政区域表BSS_SYS_AREA也称为基础表，记录了系统中用到的所有的行政区域。

该表的区域划分为3级（当然也可以划分更多的级）：市（一级）卫生局、县/乡/镇卫生院(二级)、村卫生所(三级)。

该表是一个树型结构，如下图：

表中主要字段：

1) AREAID：主键，表示区域id，该字段是该表的主键字段，关联于USERGYSAREA供应商供货区表中的外键AREAID。该字段的值的规

则是：

XX.：表示市（一级）卫生局。例如，上图中1.就表示荥阳市卫生局，其中parentid字段就是它的上级，parentid为0 表示它  的上级是区域根目录。

XX.XX： 表示县/乡/镇卫生院(二级)。例如，上图中1.1.表示崔庙镇，其中parentid字段的上级为1.，说明它的上级 是荥 阳市卫生 局。

XX.XX.XX ：表示村卫生所(三级)。以此类推.......

这样的规则是为了查询方便。

2) AREALEVEL：行政区域的等级，有3个可选值，分别是：1（市）,2（县/乡/镇）,3（村），分别对应于3个行政区域等级.

3) Parentid：所属上级的区域。

例如，需求是：查询崔庙镇下的所有村的区域信息：

因为村的等级arealevel的等级是3，sql语句如下：

select * from BSS_SYS_AREA t where areaid like '1.1.%' and t.arealevel='3'

4 实体间的管理关系

4.1行政管理关系

根据行政区域来划分管理关系，可以参考“行政区域表BSS_SYS_AREA”！

市卫生局管理本市所有的卫生院。卫生院管理本辖区的所有的卫生室.

通过在监督单位(即卫生局和卫生院的总称)USERJD表中和医院单位USERYY表中都添加的DQ（地区）字段，从而实现了行政管理关系，并在行政区域表BSS_SYS_AREA中记录了这两者之间的关系！

比如：查询某镇（崔庙镇）下的所有的医院，SQL语句如下：

select * from USERYY t where t.dq like '1.1.%'

4.2 供货管理关系

由卫生局来指定供货商所供货的区域（一个或者多个供货的区域）.可以参考“供应商供货区域表USERGYSAREA”！

注意：比如某个医院的用户登录该系统下了一个采购单表（也可以称为业务表），那么就要和医院单位USERYY表进行关联，用

来记录某单位所采购的药品，而不是记录某个用户所采购的药品，因为用户会变化的。

用户登陆系统如何找到用户所属的单位？

根据用户账号查询用户表SYSUSER，得到sysid(单位id)

5 用户管理模型总结（重点）

在经过了用户模型分析之后，再对其表结构进一步的分析和总结，如图：

二 用户查询功能实现

1. 用户查询列表的功能实现需要按照前后顺序完成两个功能：

第1个：先在页面中查询出符合条件的所有用户的列表。（也是本章所要实现的功能）

第2个：然后在其基础之上再实现分页！！！（参考下节--->“用户查询列表的分页实现”）

2. 关于用户查询页面的原型：

美工主要做CSS（样式），美工将某一类页面做成一个样式页面(静态html页面)，再由程序员在开发表现层时将html（静态页面）改为动态的jsp。

也就是说，美工不会给你做所有的页面原型，他只是做某一类的页面！！！