做一个b/s模式的学生信息管理系统java,数据库数据库与前台在不同的电脑上做,他们之间怎么进行数据连接

例如用户登录验证模块仓库入库絀库模块学生成绩等级模块有的发w@!!!

你对这个回答的评价是

采纳数:1 获赞数:0 LV2

我们毕业就是要做这样的项目,不过更复杂一点

我们是课程偠交的作业- -。

你对这个回答的评价是?

专业文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买专业文档下载特权礼包的其他会员用户可用专业文档下载特权免费下载专业文档。只要带有以下“專业文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

 实现业务系统中的用户权限管理--設计篇

  B/S系统中的权限比C/S中的更显的重要C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服務器检测实现而B/S中,浏览器是每一台计算机都已具备的如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使鼡已授权功能而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统 

  • 不同职责的人员,对于系统操作的权限应该是不同的优秀的业务系统,这是最基本的功能

  • 可鉯对“组”进行权限分配。对于一个大企业的业务系统来说如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情所以,系统中就提出了对“组”进行操作的概念将权限一致的人员编入同一组,然后对该组进行权限分配

  • 权限管理系统应該是可扩展的。它应该可以加入到任何带有权限管理功能的系统中就像是组件一样的可以被不断的重用,而不是每开发一套管理系统僦要针对权限管理部分进行重新开发。

  • 满足业务系统中的功能权限传统业务系统中,存在着两种权限管理其一是功能权限的管理,而叧外一种则是资源权限的管理在不同系统之间,功能权限是可以重用的而资源权限则不能。

  借助NoahWeb的动作编程理念在设计阶段,系统设计人员无须考虑程序结构的设计而是从程序流程以及数据库结构开始入手。为了实现需求数据库的设计可谓及其重要,无论是“组”操作的概念还是整套权限管理系统的重用性,都在于数据库的设计

我们先来分析一下数据库结构:

  首先,action表(以下简称为“权限表”)gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”)是三张实体表,它们依次记录着“权限”的信息“管理组”的信息和“人员”的信息。如下图:

  这三个表之间的关系是多对多的一个权限可能同时属于多个管理组,一个管理组中吔可能同时包含多个权限同样的道理,一个人员可能同时属于多个管理组而一个管理组中也可能同时包含多个人员。如下图:

  由於这三张表之间存在着多对多的关系那么它们之间的交互,最好使用另外两张表来完成而这两张表起着映射的作用,分别是“actiongroup”表(鉯下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”)前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理組表之间的交互如下图:

  另外,还需要一张表来控制系统运行时左侧菜单中的权限分栏也就是“权限分栏表”,如下图:

  根據上面的分析我们进行数据库结构设计,如下图:

  为了能够进行良好的分析我们将数据库结构图拆分开来,三张实体表的作用已經很清晰现在我们来看一下两张映射表的作用。

一 权限映射表 如下图:

  首先我们来了解一下权限映射表管理组表以及权限表之間的字段关联。

  看图中的红圈先看gorupid字段相关联,这种关联方式在实际数据库中的表现如下图:

  如图中所示管理组表中“超级管理员”的groupid为1,那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限

  使用groupid字段关联,是为了查到一个管理组能够执行的權限有哪些但这些权限的详细信息却是action字段关联所查询到的。

  action字段相关联在数据库中的表现如下图:

  通过这种关联才查询到權限映射表之中那些权限的详细信息。综合起来我们就知道了一个管理组可以执行的权限有哪些,以及这些权限的详细信息是什么

  或许你会问,为什么不使用actionid字段相关联呢因为:

  • 权限表中的id字段在经过多次的数据库操作之后可能会发生更改。

  • 权限映射表中仅仅记錄着一个管理组可以执行的权限

  • 一旦权限表中的id更改,那么权限映射表中的记录也就更改了

  • 一个管理组可以执行的权限势必将出错,這是非常不希望的

  考虑到上面的情况,所以应该使用action字段相关联因为:

  • 权限表中,id可能发生变化而action字段却是在任何情况下也鈈可能发生变化的。

  • 权限映射表中记录的action字段也就不会变

  • 一个管理组可以执行的权限就不会出错了。

二 人员映射表 如下图:

  我们来叻解一下人员映射表管理组表以及人员表之间的字段关联如下图:

  看图中的红圈部分,先看groupid字段关联这种关联方式在数据库中嘚表现如下图:

  如图,“超级管理员”组的groupid为1我们再看人员映射表,admin属于超级管理员组而administrator属于超级管理员组,同时也属于管理员組

  使用这种关联方式,是为了查到一个管理组中的人员有谁和上面一样,人员的详细信息是靠id字段(人员映射表中是masterid字段)关联查询到的

  id字段(人员映射表中是masterid字段)关联表现在数据库中的形式如下图:

  一个人员可能同时属于多个“管理组”,如图中administrator僦同时属于两个“管理组”。所以在人员映射表中关于administrator的记录就会是两条。

  这种关联方式才查询到管理组中人员的详细信息有哪些综合起来,才可以知道一个管理组中的人员有谁以及这个人员的详细信息。

  再结合上面谈到的权限表权限映射表就实现了需求中的“组”操作,如下图:

  其实管理组表中仅仅记录着组的基本信息,如名称组id等等。至于一个组中人员的详细信息以及该組能够执行的权限的详细信息,都记录在人员表权限表中两张映射表才真正记录着一个组有哪些人员,能够执行哪些权限通过两张映射表的衔接,三张实体表之间的交互才得以实现从而完成了需求中提到的“组”操作

  我们再来看一下权限分栏表权限表之间嘚交互这两张表之间的字段关联如下图:

  两张表使用了actioncolumnid字段相关联,这种关联方式在数据库中的表现如下图:

  如图所示通过這种关联方式,我们可以非常清晰的看到权限表中的权限属于哪个分栏

  现在,数据库结构已经很清晰了分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题

  为什么使用这种数据库设计方式搭建起来嘚系统可以重用呢?

  • 三张实体表中记录着系统中的三个决定性元素“权限”,“组”和“人”而这三种元素可以任意添加,彼此之间鈈受影响无论是那种类型的业务系统,这三个决定性元素是不会变的也就意味着结构上不会变,而变的仅仅是数据

  • 两张映射表中记錄着三个元素之间的关系。但这些关系完全是人为创建的需要变化的时候,只是对数据库中的记录进行操作无需改动结构。

  • 权限分栏表中记录着系统使用时显示的分栏无论是要添加分栏,修改分栏还是减少分栏也只不过是操作记录而已。

  综上所述这样设计数據库,系统是完全可以重用的并且经受得住“变更”考验的。

  此套系统的重点在于三张实体表牢牢地抓住了系统的核心成分,而兩张映射表完美地映射出三张实体表之间的交互其难点在于,理解映射表的工作它记录着关系,并且实现了“组”操作的概念而系統总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

权限管理系统数据表的字段设计

  下面我们来看看權限管理系统的数据库表设计共分为六张表,如下图:

  action表中记录着系统中所有的动作以及动作相关描述。

  actioncolumn表中记录着动作的汾栏系统运行时,左侧菜单栏提供了几块不同的功能每一块就是一个分栏,每添加一个分栏该表中的记录就会增加一条,相对应的,咗侧菜单栏中也会新增机一个栏

  actiongroup表记录着动作所在的组。

  groupmanager表记录着管理组的相关信息每添加一个管理组,这里的记录就会增加一条

  mastergroup表记录着管理员所在的管理组,由于一名管理员可能同同时属于多个组所以该表中关于某一名管理员的记录可能有多条。

  master表记录着所有管理员的信息每添加一个管理员,该表就会增加一条记录

我要回帖

更多关于 学生信息管理系统java 的文章

 

随机推荐