2Oracle中各个用户的区别,实质权限,角色的区别

scott 是个演示用户,是让你学习Oracle用的


hr用户是个示例用户,是在创建数据库时选中“示例数据库”后产生的,实际就是模拟一个人力资源部的数据库。


SYSDBA 不是用户,可以认为是个权限,超级权限。默认中sys就拥有这种超级权限,是权限最高的用户。
详细点说吧
超级用户分两种 SYSDBA和SYSOPT
SYSOPT 后面3个字母是operator的意思,也就是操作数据库的人,而SYSDBA 则是管理数据库的人
SYSDBA比SYSOPT的权限还要大,而SYS用户就完全是个SYSDBA,但SYSTEM用户默认是SYSOPT,不过它也能以SYSDBA的权限登陆


sys和system用户区别


最重要的区别,存储的数据的重要性不同


sys所有oracle的数据字典的基表和视图都存放在sys用户中,这些基表和视图对于oracle的运行是至关重要的,由数据库自己维护,任何用户都不能手动更改。sys用户拥有dba,sysdba,sysoper等角色或权限,是oracle权限最高的用户。


system用户用于存放次一级的内部数据,如oracle的一些特性或工具的管理信息。system用户拥有普通dba角色权限。


system用户只能用normal身份登陆em,除非你对它授予了sysdba的系统权限或者syspoer系统权限。
sys用户具有“SYSDBA”或者“SYSOPER”系统权限,登陆em也只能用这两个身份,不能用normal。


以sys用户登陆Oracle,执行select * from V_$PWFILE_USERS;可查询到具有sysdba权限的用户,如:


SQL> select * from V_$PWFILE_USERS; 
USERNAME SYSDBA SYSOPER
SYS TRUE TRUE


Sysdba和sysoper两个系统权限区别


normal 、sysdba、 sysoper有什么区别
normal 是普通用户 
另外两个,你考察他们所具有的权限就知道了
sysdba拥有最高的系统权限,登陆后是 sys
sysoper主要用来启动、关闭数据库,sysoper 登陆后用户是 public




sysdba和sysoper属于system privilege,也称为administrative privilege,拥有例如数据库开启关闭之类一些系统管理级别的权限sysdba和sysoper具体的权限可以看下表:


可以让用户作为sys用户连接
 可以进行一些基本的操作,但不能查看用户数据
 
登录之后用户是sys
登录之后用户是public 


system如果正常登录,它其实就是一个普通的dba用户,但是如果以as sysdba登录,其结果实际上它是作为sys用户登录的,这一点类似Linux里面的sudo的感觉,从登录信息里面我们可以看出来。因此在as sysdba连接数据库后,创建的对象实际上都是生成在sys中的。其他用户也是一样,如果 as sysdba登录,也是作为sys用户登录的,看以下实验:


SQL> create user strong identified by strong;


用户已创建。


SQL> conn strong/strong@magick as sysdba;


已连接。


SQL> show user;


USER 为 "SYS"


SYS 


dba和sysdba的区别


dba、sysdba这两个系统角色有什么区别呢


在说明这一点之前我需要说一下oracle服务的创建过程


创建实例→·启动实例→·创建数据库(system表空间是必须的)


启动过程


实例启动→·装载数据库→·打开数据库


sysdba,是管理oracle实例的,它的存在不依赖于整个数据库完全启动,只要实例启动了,他就已经存在,以sysdba身份登陆,装载数据库、打开数据库。只有数据库打开了,或者说整个数据库完全启动后,dba角色才有了存在的基础

展开阅读全文

管理软件中的用户角色权限

09-05

rnrn一、问题的提出rn对一套企业管理软件系统从软件人员调研、设计到交付用户使用一个主要环节是:管理软件所具有的针对用户处理业务操作模块划分;系统如何进行管理与维护。这就软件管理设计中的“用户”、“角色”、“权限”,即系统所具有的用户有哪些;每个用户所扮演什么角色;不同角色所具有的管理权限,这三个概念(“用户”、“角色”、“权限”)及相互关联关系在许多文档资料叙述甚多,软件研发人员在整个设计过程中无不关注,每个管理软件系统的使用者也在关注“我以什么角色身份”登录系统;我的角色身份登录后可以在管理软件中操作哪些具体业务。这是一个问题所对应来源于两个方面的关注。rn如何把可以操作的各类业务(包含系统管理、维护)模块授权与可以登录的操作人员(角色划分及角色所获取的权限)软件开发人员一般是依据用户需求而确定,即:用户提出“根据业务性质划分确定角色”、“针对各类角色予以授权操作”。早期(上世纪70、80年代)的企业管理软件一般对可以使用“操作权限”设置方法,即一个单独的“人员操作权限”模块授权于登录系统人员可以使用的模块。rnRBAC(Role-Based Access Control,基于角色的访问控制)是现在软件设计者普遍采用的角色划分及角色所具有权限分配方法。这种方法的基本思路是:一个可以登录系统的用户→确定该用户所扮演的角色→该角色对管理系统所具有的操作权限,这是一种三层架构的设计模式,由以下三个方面关联构成。rn1、登录用户rn具体登录管理软件的操作人员。rn2、用户角色rn登录操作人员所扮演角色,诸如:“系统管理”、“账务管理”、“库房管理”等等。rn3、角色具有权限rn不同用户即便其角色一样,其操作权限也可能不尽相同。例如同样是“库房管理”角色,有的角色具有“材料采购订单管理”、“材料入库制单”权限,某些角色切具有“材料入库制单”权限。rn其实际基础业务环节有多少就应该有多少种权限可以对各类角色进行授权rn以数据库管理系统为例,需要建立“登录用户(人员)”、“角色划分”、“登录用户角色分配、授权”三个数据表进行管理,形成一(个用户)对多(角色、权限)的数据关系。rn如何划分登录用户→用户所扮演角色→具体用户角色的权限分配是管理软件开发人员所关注、探讨的一个问题,因为它关联牵扯到企业管理框架(管理体制【企业负责制】、企业部门划分乃至职责范围及权限范围)rn这种三层架构的设计方法存在如下弊端:rn1、交付企业用户使用不是一目了然,操作比较麻烦rn2、管理体制变更后原有用户、角色、权限需要重新定义分配rn3、企业下属部门重新设置后某些操作页面程序对面需要重新编写rn4、系统维护工作量相应增加rn如下两个框架图形,是一个典型的RBAC设计框架从设计思路到数据表关联过程,其繁琐的操作页面、操作过程不具有一定逻辑思维的人比较难以掌握。rnA、围绕组织架构设计管理图rn [img=https://img-bbs.csdn.net/upload/201609/05/1473065679_132948.png][/img]rn图1-1 围绕企业组织架构逻辑框架rn软件设计和用户关注的组织框架包含:企业管理体制、管理权限划分、各个管理人员的角色、每种管理角色所具有的操作权限。rnB、数据表关联图rn软件开发设计人员从图1-1中归纳为数据表的描述有:“用户表”、“角色表”、“权限表”而后关联出“用户角色”表与“角色权限”表,如图1-2.rn [img=https://img-bbs.csdn.net/upload/201609/05/1473065712_885518.jpg][/img]rn图1-2 用户、角色及权限数据关系rn上述处理关联着企业的企业框架中的职能结构、层次结构、部门结构、职权结构这四种结构,无论结构中任何一个发生变化,仅仅靠上述处理难以凑效。大家熟知“财务科(部)”、“供应科(部)”等部门一般企业均应设置,但机构精简后可以把这两个部室合并为一个后,原有的“财务科(部)”、“供应科(部)”不复存在,那么原有的用户、角色将也随之消失不可再用,原有系统操作模块都得重新改写维护,其工作量可想而知。rn随着大数据时代的到来,企业管理信息的重要性已经被人们所重视,管理中的数据信息不在仅仅是算算账、出几张报表的事情,而是及时精准、最小化的基础数据信息,为提供各个管理层面的管理人员提供真实可信决策信息依据。rn譬如:如下如何企业、(行政、事业)部门都所使用到的“账务管理”软件系统,这里归纳出客户需求的业务模块将达到上百个之多(包含系统管理维护),如图1-3。rn账务管理常用功能模块rn [img=https://img-bbs.csdn.net/upload/201609/05/1473065841_170676.png][/img]rn[img=https://img-bbs.csdn.net/upload/201609/05/1473065850_904590.png][/img]rn[img=https://img-bbs.csdn.net/upload/201609/05/1473065861_199341.png][/img]rn[img=https://img-bbs.csdn.net/upload/201609/05/1473065871_639468.png][/img]rn[img=https://img-bbs.csdn.net/upload/201609/05/1473065880_596999.png][/img]rn[img=https://img-bbs.csdn.net/upload/201609/05/1473065891_209989.png][/img]rn rn图1-3 账务管理部分功能模块rn如果按照“RBAC”处理方法即便假定企业管理框架不发生变化也是麻烦之事。围绕账务管理中描述数据最小属性的“编码”管理就包括18个编码类型类。不可能“编码管理”作为一个类型的角色,因为它涉及到不同的管理层面;试想如果把其中任意组合的“编码”作为一个角色,这种组合有多少种,你可以用组合公式计算一下。rnrnrnrn二、业务对象层面阶梯化、最小化rn上述的图RBAC(Role-Based Access Control)角色划分权限设置是建立职能结构、层次结构、部门结构、职权结构这四种结构之上,即与企业的管理层次、部门结构、管理者的管辖范围权限相关,不同的职能、层次、企业部门设置、权限划分管理软件的总体框架结构势必不同,一旦某个层面发生改变系统框架、数据框架、软件代码也将随之发生改变。这种RBAC方法使得软件的生命周期并不十分长久,软件的维护成本与企业所负担的成本势必大大增加。rn怎么办呢?我们不妨这样去考虑。在任何一个企业(可以包括政府部门、事业单位)无论其职能结构、层次结构、部门结构、职权结构如何划分,但需要处理的工作对象业务是一致的,所得到的管理结果目标完全相同。譬如财务账务管理、库房材料管理,这些工作业务任何企业都会有人去做,至于它由谁去做不应该受到企业是否部门结构的限制,即便没有财务管理部门或材料管理部门,企业总的有人去管理账务,总的去管理库房材料,只要安排胜任此项业务人员去做就可以。rn图1-3 账务管理功能模块以表格形式给出了业务对象层面阶梯化、最小化的设计思路基础,描述了把所需处理的账务管理业务阶梯化(层次化),把每一项要处理的业务最小化。譬如“编码管理”下属的18种类型编码“记账科目”、“部门编码”等编码是编码管理中的最小化业务层面;“记账凭证”下属的“凭证制证”、“记账凭证审核”、“凭证登账”、“凭证查询”等是“凭证管理”业务中的最小化业务层面。这里“编码管理”、“凭证管理”作为管理层面的父节点,而下属具体业务则为这些父节点下属的子节点。rn软件开发人员在调研中的一个主要任务就是把需求客户的每一个业务层面(管理什么,如何管理、管理过程、管理方法)完全清楚,而不是就事论事,由业务层面的“父”节点逐步确定下属“子”节点,这就是这里提出来的“业务对象层面阶梯化、最小化”最终归结为如图1-3的线性发生描述方式,随着这种描述的产生管理软件框架也就成型,也为登录界面的树形结构和模块设计奠定基础。rn这里最小层面的工作业务是构成软件框架内的一个具体操作页面。至于页面布置、页面上各种功能需求(按钮或菜单)代码就是程序代码编写人员的主要工作。rnrnrnrn三、业务对象授权于登录用户的具体操作人员rn1、基本思想rnA、至下向上归纳法rn先确定最基础全部业务子节点→逐级归纳各个子节点归属的父节点。rn譬如:在账务管理先把应该有哪些最小(不能再往下细分)需要管理的工作业务并予以冠名,“凭证录入”、“凭证审核”、“凭证登账”、“凭证查询”、“科目明细账”、“现金日记账”、“银行日记账”、“科目编码”、“部门编码”、“产品商品编码”等等属于最基础的业务工作层面,有了这些基础业务层面,而后逐级向上确定它们各自所属的上级父节点(某级父节点还可能具有上级父节点)。rnB、由上向下归纳法rn从大类业务环节开始确定各个业务管理环节(父节点)→把各个基础业务层面的子节点归类于相应的父节点。rn譬如:在账务管理中首先从大的业务环节层面认定要做哪些管理业务(父节点),而后逐级乡下归纳属于某父节点之内的业务管理环节,图1-3中的“账务基础”、“产品商品销售”、“资金控制”都属于一级父节点,在这些节点下确认下属包含业务层面的子节点,直到每个子节点最小化。rn [img=https://img-bbs.csdn.net/upload/201609/05/1473065934_398896.png][/img]rn图2-1 账务基础业务环节层次结构rn无论是至下向上还是由上向下归纳都会归纳、抽象出类如图1-3的“业务对象层面阶梯化、最小化”管理模块结构图。rn2、模块、用户、操作授权数据及数据关系rn一个管理系统所应具有的逐级管理模块已然确定,那么这些模块如何让可以登录系统人员进入实施他们具体的操作,这是人们关注的事情。这里给出记录这三个信息的数据表,“模块表”记录如图1-3的全部数据记录;“用户表”记录可以登录管理系统的全部操作人员(包含系统管理员);“操作授权表”记录“用户表”内人员已经授权的“模块表”中局部数据记录,这里需要指出,最基础子节点具有N个,只要授权其中之一那么上级父节点也一并授权,目的在于满足操作界面完整的树形结构显示。图2-2通过“操作人员表”与“模块表”的关联确定了“操作人员表”的数据记录。rn [img=https://img-bbs.csdn.net/upload/201609/05/1473066016_942652.png][/img]rn图2-2 操作权限表关联获取rn这一设计思路具有如下优点:rnA、和图1-2(用户、角色及权限数据关系)比较由五个数据表表的关联简化成为三个数据表,简化后的管理方法便于理解;rnB、减少了程序代码编写;rnC、“业务模块”便于添加、修改、删除而不影响原有管理系统的整体代码;rnD、突破了制约于“企业管理体制”的框架思路,即不受你的企业管理权限如何分配,也不受你的企业行政管理体系如何更变。rnrnrnrn四、管理实例rn以前述的“账务管理”为实例,下面叙述如何实现“业务对象层面阶梯化、最小化”设计企业管理系统。rn1、假定rn假定已经考虑到的各个层面的管理模块已经保存在“模块编码表”内;已经建立了“操作人员(登录用户)数据表”,该表至少具有一条具有系统管理权的操作人员,其登录特征为账户序号=0,人员序号=0;已经建立了“操作授权表”(如图2-1),且已经具有了系统管理人员的权限记录;已经建立了一套具有独立管理的“账务管理”账户。rn2、操作人员授权管理rnA、系统操作人员登录rn对可以登录“账务管理”账户的每一操作人员,他们可以哪些页面,做些什么业务处理必须由“系统管理人员”完成。在操作界面图4-1下登录后予以授权rn [img=https://img-bbs.csdn.net/upload/201609/05/1473066055_50270.png][/img]rn图4-1 账务管理操作人员登录rnrn以账务人员登录后页面中以树形菜单显示了“系统管理人员”所具有的操作页面。如图4-2rn [img=https://img-bbs.csdn.net/upload/201609/05/1473066098_622663.png][/img] rn图4-2 系统管理人员具有的操作树形菜单rnB、操作人员授权rn在图4-2操作菜单下点击“人员操作授权”后进入如图4-3的授权页面。rn [img=https://img-bbs.csdn.net/upload/201609/05/1473066131_62612.png][/img]rn图4-3 人员授权管理页面rn在授权页面下在全部操作模块列表中的选择框予以选择,以决定某操作人员的操作模块,这些模块既是操作人员的处理业务。rn在图4-3中显示了被授权人的“登录账户序号”及“登录人员序号”,授权后告知相应人员,该操作人员就可以以这个“登录特征”在图4-1的登录页面下登录。rnC、已经授权的操作人员登录rn“登录账户序号”=4、“登录人员序号”=5登录后所具有的操作树形菜单如图4-4.rn [img=https://img-bbs.csdn.net/upload/201609/05/1473066165_486536.png][/img] rn图4-2 具有账务处理基础操作人员登录后的树形菜单rn在图4-2的树形菜单下给这里出了“账务基础”的全部业务模块,但并非对每一个涉及“账务基础”的操作人员对这些模块全部授权,在图4-3人员授权管理页面下可以有选择的进行授权,可以是一种业务模块,也可以是任意业务模块的各种组合。对已经授权的业务工作模块还可以重新授权,予以取消或增补新的授权。rn仅仅从登录操作人员登录后他们可以做什么,这里给出的思路、方法与前述的“RBAC(Role-Based Access Control)角色划分权限”从页面管理、具体操作要简化明了了许多,rn本文给出了C/S(客户服务器管理方式)下的的处理方式,实事上流行的B/S(浏览器管理方式)也完全的可行,只要改变一下浏览器具体页面的布置就完全可以。其授权所管理的数据表,具体的关联方式的程序流程、代码基本一致。rn 论坛

没有更多推荐了,返回首页