javaEE 用户、部门、角色、权限实体的关系设计与hibernate映射配置文件关系总结

文章中的项目文件已经放到Github上,欢迎大家Follow,star,

地址:https://github.com/lawlite19/SmartEducation

一:设计实体,我这里通过uml设计,然后直接可以生成java实体类(方便查看各个类的关系)

(1)用户登录类User与用户详细信息类UserDetails为一对一关系;

(2)用户详细信息类UserDetails与部门为多对一关系;(一个部门有多个用户)

(3)部门类是自关联的,有上级部门;

(3)用户详细类UserDetails与角色类Role为多对多的关系;(一个用户可有多个角色,一个角色也可对应多个用
户)

(4)角色类Role与权限类Privilege类为多对多关系;(一个角色可有多个权限,一个权限也可对应多个角色)

(5)权限类是自关联的,因为分为若干级权限。

然后直接可以到处java实体类,

然后拷贝到MyEclipse中,生成get、set方法

二:写hibernate的hbm.xml映射文件,普通的属性切分两屏对着写就行了,主要说下实体之间对应的关系

(1)用户类与用户信息类为一对一,我用的外键关联(即用户表中存有用户信息表的主键Id)

在用户信息类中有user属性:(cascade是级联)

在用户表中有userDetails属性,指明创建数据库表时列名colum="UserDetails_Id"

(2)部门类和用户信息类是多对一

在用户信息类中有department属性,对应表中存储部门的Id:

在部门类中有userDetails属性,key为指明对应的列:

(3)用户信息类与角色类为多对多

用户信息类中有roles属性,指明中间表为T_UserDetails_Role:(多对多关系需要创建一个中间表,分别存储两个表的主键Id)

key指明对应的列,

角色类中有userDetails属性

(4)也是多对多,与上相同

(5)部门自关联,上级部门为多对一,下级部门则为一对多

(6)权限自关联,与上相同

三:测试,在创建sessionFactory的时候创建表,写个JUnit测试执行

(1)发现表自动创建成功,下面我们主要检查一下关系对应的是否正确

(2)正确

(3)正确

(4)正确

(5)正确

(6)正确

(7)正确

(8)正确

四、总结

主要总结一下关系的对应:

(1)一对一(外键)

主表

<many-to-one name="" class="" column="" unique="true">

副表

<one-to-one name="" class="" cascade="all"></one-to-one>

(2)一对多

<set name="">

<key column=""></key>

<one-to-many class="" />

</set>

(3)多对一

<many-to-one name="" class="" column="">

</many-to-one>

(4)多对多

<set name="" table="">

<key column=""></key>

<many-to-many class="" column=""></many-to-many>

</set>

一对多和多对多要有set,多对多中要多table和column属性

步骤:

1、写注释对应关系

即:xx属性,本类与yy类的zz关系

2、将上面的模板拷贝

3、填写:(1)name---->xx

 (2)class---->yy

 (3)

1)many-to-one中column---->yy_Id(看个人习惯)

2)one-to-many中key----->对方many-to-one中的column属性

3)many-to-many中key---->本对象_Id(看个人习惯)

     many-to-many中column---->yy_Id

 

时间: 2024-12-22 08:48:43

javaEE 用户、部门、角色、权限实体的关系设计与hibernate映射配置文件关系总结的相关文章

hibernate 映射组成关系

建立域模型和关系数据模型有着不同的出发点: 域模型: 由程序代码组成, 通过细化持久化类的的粒度可提高代码的可重用性, 简化编程 在没有数据冗余的情况下, 应该尽可能减少表的数目, 简化表之间的参照关系, 以便提高数据的访问速度 Hibernate 把持久化类的属性分为两种: 值(value)类型: 没有 OID, 不能被单独持久化, 生命周期依赖于所属的持久化类的对象的生命周期 实体(entity)类型: 有 OID, 可以被单独持久化, 有独立的生命周期(如果实体类型包含值类型,这个值类型就

mongodb之用户/认证/角色/权限管理

前言 用户权限管理很重要,只给需要的权限,防止应用系统漏洞导致脱库 认证和授权 Authentication 认证识别,解决我是谁 Authorization 操作授权,我能做什么 认证机制 MONGODB-CR 官方自定义实现认证机制,通过用户名和密码,通过challenge-response方式,来识别和验证授权.SCRAM-SHA-1认证机制有更好的安全性,新版本默认使用SCRAM-SHA-1.不建议使用MONGODB-CR模式. SCRAM-SHA-1 3.0版本新加功能,Mongodb

精通Hibernate——映射组成关系

建立域模型与关系型数据模型有着不同的出发点.域模型是由程序代码组成,通过细化持久化类的粒度提供代码可重用度,简化编程.关系数据模型由关系数据组成.存在数据冗余的情况下,需要把粗粒度的表拆分为具有外键参照关系的几个细粒度表,从而节省表的存储空间:另一方面在没有数据冗余的前提下,应尽可能减少表的数量,简化表之间的参照关系,以便提高数据库的访问速度. 由于建立域模型和关系型数据的原则不一样,使得持久化类的数目往往比数据库中表的数量要多,而且持久化类的属性并不和表字段一一对应,下面Customer类的h

hibernate映射组成关系

目录结构 类 package com.hibernate.helloworld; public class School { private String name; private String address; public String getName() { return name; } public void setName(String name) { this.name = name; } public String getAddress() { return address; }

hibernate 映射继承关系

实现方式一般有三种: 1. 继承关系树每个具体类对应一张表(不介绍) 2. 继承关系树的根类对应一张表 3. 继承关系树的每个类对应一张表 先介绍关系: DayEmployee和MonthEmploy是Employee的子类,并且Company和Employee是一对多关系: 具体代码如下: Company.java import java.util.HashSet; import java.util.Set; public class Company { private Integer id;

maven + Struts2 + Spring + Hibernate 整合 &gt;&gt;&gt; 配置文件关系图

SSH 配置比较多,有很多地方一直都很模糊,这次整理一下思路. 所有源文件都在文末. XML 文件:链接:https://pan.baidu.com/s/1kUHjhAJ 密码:b4b3 图片超清版本:链接:https://pan.baidu.com/s/1nvdzMfn 密码:z8my Xmind 格式原件:链接:https://pan.baidu.com/s/1jH7HE1C 密码:f4bb

spring-boot-plus V1.4.0发布 集成用户角色权限部门管理

RBAC用户角色权限 用户角色权限部门管理核心接口介绍 Shiro权限配置 ?? Shiro权限配置 数据库模型图 ?? spring-boot-plus初始化SQL下载 获取验证码 可配置是否启用验证码 默认未启用 如已启用验证码校验,登陆时,需传入verifyToken和code 验证码演示 spring-boot-plus: # 是否启用ansi控制台输出有颜色的字体 enable-ansi: true # 是否启用验证码 enable-verify-code: true enable-v

用户和角色:通用权限管理系统数据库表结构如何设计?

一,前言 权限管理系统的应用者应该有三种不同性质上的使用,A,使用权限B,分配权限C,授权权限 本文只从<使用权限>和<分配权限>这两种应用层面分析,暂时不考虑<授权权限>这种.二,初步分析用户和角色 说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表.这样就决定了一个人有什么样的权限.做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情.因此再添加一个角色表,把某些人归为一类,然后再把权限分配给角色.

[数据库设计]用户和角色:通用权限管理系统数据库表结构如何设计?

一,前言 权限管理系统的应用者应该有三种不同性质上的使用, A,使用权限 B,分配权限 C,授权权限  本文只从<使用权限>和<分配权限>这两种应用层面分析,暂时不考虑<授权权限>这种. 二,初步分析用户和角色 说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表.这样就决定了一个人有什么样的权限. 做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情.因此再添加一个角色表,把某些人归为一类,然后再把权限