精华内容
下载资源
问答
  • 通用权限管理设计数据权限

    万次阅读 2018-01-04 10:09:40
    本文将对这种设计思想作进一步的扩展,介绍数据权限设计方案。 权限控制可以理解,分为这几种 : 【功能权限】:能做什么的问题,如增加产品。 【数据权限】:能看到哪些数据的问题,如查看本人的所有订单。 ...

    前言

     

    前一篇文章《通用权限管理设计 之 数据库设计方案》介绍了【主体】- 【领域】 - 【权限】( who、what、how问题原型 ) 的设计思想

     

    本文将对这种设计思想作进一步的扩展,介绍数据权限的设计方案。

    权限控制可以理解,分为这几种 :

    【功能权限】:能做什么的问题,如增加产品。
    【数据权限】:能看到哪些数据的问题,如查看本人的所有订单。
    【字段权限】:能看到哪些信息的问题,如供应商账户,看不到角色、 部门等信息。

    上面提到的那种设计就是【功能权限】,这种设计有一定的局限性,对于主体,只能明确地指定。对于不明确的,在这里可能就没办法处理。比如下面这几种情况:

    数据仅当前部门及上级可见
    数据仅当前用户(本人)可见

    类似这样的就需要用到上面提的数据权限。

    上一篇文章我用一个表五个字段完成了【功能权限】的设计思路
    本文我将介绍如何利用一个表两个字段完成这个【数据权限】的设计思路

    初步分析

    【数据权限】是在【功能权限】的基础上面进一步的扩展,比如可以查看订单属于【功能权限】的范围,但是可以查看哪些订单就是【数据权限】的工作了。

    在设计中,我们规定好如果没有设置了数据权限规则,那么视为允许查看全部的数据。

    几个概念
    【资源】:数据权限的控制对象,业务系统中的各种资源。比如订单单据、销售单等。属于上面提到的【领域】中的一种
    【主体】:用户、部门、角色等。
    【条件规则】:用于检索数据的条件定义
    【数据规则】:用于【数据权限】的条件规则 

     
    应用场景
    1,订单,可以由本人查看 
    2,销售单,可以由本人或上级领导查看 
    3,销售单,销售人员可以查看自己的,销售经理只查看 销售金额大于100,000的。

    我们能想到直接的方法,在访问数据的入口加入SQL Where条件来实现,组织sql语句:

    1where UserID = {CurrentUserID}
    2where UserID = {CurrentUserID}  or {CurrentUserID} in (领导)
    3where UserID = {CurrentUserID}  or ({CurrentUserID} in (销售经理)  and 销售金额 > 100000)

    这些一个一个的"条件",本文简单理解为一个【数据规则】,通常会与原来我们前台的业务过滤条件合并再检索出数据。

    这是一种最直接的实现方式,在【资源】上面加一个【数据规则】(比如上面的三点)。这样设计就是

      【资源】 - 【数据规则】

    我又觉得不同的人应该对应不同的规则,那么也可以理解为,一个用户对应不同的角色,每一个角色有不一样的【数据规则】,那么设计就变成

      【资源】 - 【主体】 - 【数据规则】

    根据提供者的不同,准备不同的权限应对策略。

    这里可以简单地介绍一下,这个方案至少需要2张表,一个是  【资源,主体,规则关系表】、一个是【数据规则表】

    关系表不能直接保存角色,因为你不确定什么时候业务需要按照【部门】或者【分公司】来定义数据规则

    于是可以用  Master、MasterKey  类似这样的两个字段来确定一个【主体】

    用XML方式的话是这样配置的(放在数据库也类似):

    <?xml version="1.0" encoding="utf-8"?>
    <settings>
      <rule view="订单" role="销售人员">
          销售员 = {CurrentUserID}
      </rule>
      <rule view="订单" role="总销售经理">
         销售金额 > 100000
      </rule>
      <rule view="订单" role="区域销售经理">
        销售金额 > 100000  and 区域 = {当前用户所属区域}
      </rule>
    </settings>

    对于这种方式有兴趣的朋友也可以试一下,两种方式的【数据规则】是一样的,但是本文没有采用第二种设计方式,因为它多了一层处理逻辑,我以为应该设计越简单越好,就采用第一种方式:

      【资源】 - 【数据规则】

    当然,上面是用SQL的方式来确定条件规则的,我们当然不会这么做。SQL虽然灵活,但是我们很难去维护,也不知道SQL在我们的界面UI上面如何体现。难不成直接用一个文本框来显示。这样对应一个开发人员来说不是问题,可是对应系统管理员,很容易出问题。所以我们需要有另一方式来确定这一规则,并最终可以转换成我们的SQL语句。

    我们的设计关键在于如何规范好这些【数据规则】 ,这个规则必须是对前端友好的,而且是对后台友好的,JSON显然是很好的方式。

     规则说明:

    1,数据权限规则总是:{属性 条件 允许值}

    2,数据权限规则可以合并。比如 ( {当前用户 属于 销售人员} and {订单销售员 等于  当前用户} )   Or {当前用户  属于 销售经理}

    3,最终我们会用JSON格式

    在检索数据时会先判断有没有注册了某某【资源】的【条件规则】,如果有,那么加载这个【条件规则】并合并到我们前台的【搜索条件】(你的业务界面应该有一个搜索框吧)

     如下图定义了客户信息的搜索框,我们搜索客户ID包括AN,我们组织成的规则将会是:

    {"rules":[{"field":"CustomerID","op":"like","value":"AN","type":"string"}],"op":"and"}

    为了更好地理解【数据规则】,这里介绍一下【通用查询机制】 

    【通用查询机制】

    权限控制总离不开一些条件的限制(比如查看当前部门的单据),如果没有完善的通用查询规则机制,那么在做权限条件过滤的时候你会觉得很别扭。这里介绍一个通用查询方案,然后再介绍如何实现【数据规则】。

     

    早些时候我写过一篇关于ligerGrid结合.net设计通用处理类的文章《 jQuery liger ui ligerGrid 打造通用的分页排序查询表格(提供下载) 》。里面提到的过滤信息是直接的SQL语句。这是不可靠,而且不安全的。
    在前端传输给后台的过滤信息不应该是直接的SQL,而应该是一组过滤规则。在ligerui V1.1.8 已经加入了一个条件过滤器插件,这个插件组成的规则数据才是我受推荐的:
    比如如下

     

    {"rules":
    [
    {"field":"OrderDate","op":"less","value":"2012-01-01"},
    {"field":"CustomerID","op":"equal","value":"VINET"}
    ]
    ,"op":"and"}

     

    规则描述:
    查找顾客VINET所有订单时间小于2011-01-01的单据


    这样的数据是安全的,而且是通用的(你甚至可以再加一个OR子查询)。无论是在前端还是后台,无论你使用什么样的组件,都可以很好地利用。

    通用后台的翻译,就可以生成这样SQL的参数:

     

    Text:
    ([OrderDate] < @p1 and [CustomerID] = @p2)
    Parameters:
    p1:2012-01-01
    p2:VINET

     

    下面来点复杂的:查找 顾客VINET或者TOMSP,所有订单时间小于2011-01-01的单据

     

    {
    "rules":[{"field":"OrderDate","op":"less","value":"2012-01-01"}],
    "groups":[
    {"rules":[{"field":"CustomerID","op":"equal","value":"VINET"}, {"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
    ],
    "op":"and"
    }

     翻译结果:

     

    Text:([OrderDate] < @p1 and ([CustomerID] = @p2 or [CustomerID] = @p3))
    Parameters:
    p1:2012-01-01
    p2:VINET
    p3:TOMSP

     

    这个过滤规则分为三个部分:【分组】、【规则】(字段、值、操作符)、【操作符】(and or),而自身就是一个分组。
    这种简单的结构就可以满足全部的情况。

    当然,上面提到的这些条件都是在前台定义(可能是用户在搜索框自己输入的)的,而在后台,我们可能会定义一下【隐藏条件】,比如说 【员工只能查看自己的】,要怎么做呢,其实很简单,只需要在后台接收到这个过滤条件(前台toJSON,后台解析JSON)以后,再加上一个过滤规则(隐藏条件):

     

    {field:'EmployeeID',op:'equal',value:5}

     

    可以将原来的过滤规则当做一个分组加入进行:

     

     

    {op:'and',groups:[

     

    {"rules":[{"field":"OrderDate","op":"less","value":"2012-01-01"}],
    "groups":[
    {"rules":[{"field":"CustomerID","op":"equal","value":"VINET"},{"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
    ],"op":"and"}

     

    ],rules:[{field:'EmployeeID',op:'equal',value:5}]
    }


     

    翻译如下:

     

    Text:
    ([EmployeeID] = @p1 and ([OrderDate] < @p2 and ([CustomerID] = @p3 or [CustomerID] = @p4)))
    Parameters:
    p1:5
    p2:2012-01-01
    p3:VINET
    p4:TOMSP



     这样的【条件规则】才是我们想要的,不仅在前端可以很好地解析,也可以在后台进行处理。在后台我们会定义跟这种数据结构对应的类,那么再定义一个翻译成SQL的类:


    数据权限规则

    说了这些,可以开始介绍如何实现【数据规则】了:

    上面提到的【隐藏条件】,就是我介绍的【数据规则】
    试想一些,这样 前台的过滤规则,再加上我们之间定义好的 【数据权限】控制 过滤条件。不就达到目的了吗。
    先看看我们在数据库里保存的这些【数据规则】:

     看不明白?那来个清楚一点的:

    规则描述

    订单:【订单管理员和演示角色可以查看所有的】,【订单查看员】只能查看自己的

    产品:【基础信息录入员和演示角色可以查看所有的】,【供应商】只能查看自己的

    {CurrentEmployeeID}表示当前的员工。

    实质上,我们还可以根据当前用户信息定义需要的参数,比如:

    {CurrentUserID} 当前用户Id ,对应表【CF_User】

    {CurrentRoleID} 当前角色Id ,对应表 【CF_Role】 

    {CurrentDeptID} 当前用户部门Id,对应表【CF_Department】

    {CurrentEmployeeID} 当前用户员工Id,对应表【Employees】(CF_User.EmployeeID)

    {CurrentSupplierID} 当前用户供应商Id,对应表【Suppliers】(CF_User.SupplierID)

     在数据库中我们直接保存这些用户参数,在“翻译”规则成为SQL时,会替换掉:

    比如查看订单,我们得到的SQL,可能是这样的:

    Text:     SELECT * FROM (SELECT TOP 20 * FROM (SELECT TOP 40 * FROM [Orders] WHERE ( 1=1  and ((@p1 in (@p2,@p3)) or (@p4 = @p5 and [EmployeeID] = @p6))) ORDER BY OrderID ASC) AS tmptableinner ORDER BY OrderID DESC) AS tmptableouter ORDER BY OrderID ASC     
    Parameters:
    @p1[Int32] = 7
    @p2[Int32] = 2
    @p3[Int32] = 6
    @p4[Int32] = 7
    @p5[Int32] = 7
    @p6[Int32] = 1

    {CurrentRuleID} 替换为 7

    {CurrentEmployeeID} 替换为1

     下图是我们设计【数据权限】的界面,可以选择所有的字段,包括几个用户信息:

    这些字段不仅仅只是在文本框中输入值,那么可以自定义数据来源:

     

    var fieldEditors = {};
    fieldEditors['Orders'] = {
        'ShipCity': { type: 'combobox', 
            options: {
                width: 200,
                url: "../handler/select.ashx?view=Orders&idfield=ShipCity&textfield=ShipCity&distinct=true"
            }
        }
    };

    效果界面:

     


    实际应用

    既然是数据权限控制,如果有一个统一的数据接收入口,我们倒是可以利用这个入口做一些工作。

    比如【ligerRM权限管理系统】统一使用 grid.ashx 这个数据处理程序作为列表数据的接收入口。

    有了统一的接口,方便做权限的控制,使用过 ligerGrid Javascript表格,或者类似插件的朋友,应该比较清楚服务器的交互原理。 
    在grid.ashx中,我们会通过 
    【视图/表名 】、 【排序信息】、【分页信息】、【过滤信息】
    这几个指标来获取指定的数据。


    而在实际的业务中,可能会引入权限的控制。比如某某【资源】,只能由当前用户自身才能查看,或者只能由当前用户部门及上级部门才能查看。对于这些控制,我们采用对这些可能做权限控制的【资源】注册一组【条件规则】的方式来进行。

     我们将找到view定义好的【数据权限规则】,然后和用户在前台搜索框输入的【搜索规则】合并:

    上面的代码就是数据条件合并的例子,这样便得到了我们最终需要的 过滤规则。

    结语

    本文提出了数据权限的一种实现思路,只是本人在做一个web应用时构思的方案,谈不上规范,欢迎提出你的建议意见。

    可以在http://case.ligerui.com体验实际的应用效果。

    展开全文
  • 通过new产生一个对象需要非常繁琐的数据准备或访问权限,则可以使用原型模式 何时使用 当一个系统应该独立于它的产品创建,构成和表示时 当要实例化的类是在运行时刻指定时,例如,通过动态装载 为了避免创建一个...

    场景

    • 克隆技术的过程是怎么样的?克隆 的过程就叫做原型

    本质

    • 通过new产生一个对象需要非常繁琐的数据准备或访问权限,则可以使用原型模式

    何时使用

    1. 当一个系统应该独立于它的产品创建,构成和表示时
    2. 当要实例化的类是在运行时刻指定时,例如,通过动态装载
    3. 为了避免创建一个与产品类层次平行的工厂类层次时
    4. 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

    优点

    1. 性能提高
    2. 逃避构造函数的约束

    实例

    1. 浅复制

      测试代码
      public static void test1() throws Exception {
              //浅复制,因为复制过去内容如果有另外的对象的话也会跟着改变对象
              Sheep sh = new Sheep("多利", new Date(12512531253L));
              System.out.println(sh);
              System.out.println(sh.getName());
              System.out.println(sh.getBirthday());
              sh.setBirthday(new Date(1111111111111L));
              Sheep sh1 = (Sheep)sh.clone();
              sh1.setName("少利");
              sh1.setBirthday(new Date(1251253125312L));
              System.out.println(sh1);
              System.out.println(sh1.getName());
              System.out.println(sh1.getBirthday());
          }

       

    2. 深复制

      测试代码
      public static void test2() throws Exception {
              //深复制
              Sheep sh = new Sheep("多利", new Date(12512531253L));
              System.out.println(sh);
              System.out.println(sh.getName());
              System.out.println(sh.getBirthday());
              sh.setBirthday(new Date(1111111111111L));
              Sheep sh1 = (Sheep)sh.clone();
              sh1.setName("少利");
              System.out.println(sh1);
              System.out.println(sh1.getName());
              System.out.println(sh1.getBirthday());
          }

       

    3. 序列化复制

      测试代码
       
      public static void test3() throws Exception {
              //使用序列化和反序列化实现深复制
              Sheep sh = new Sheep("多利", new Date(12512531253L));
              System.out.println(sh);
              System.out.println(sh.getName());
              System.out.println(sh.getBirthday());
      
              ByteArrayOutputStream bos = new ByteArrayOutputStream();
              ObjectOutputStream oos = new ObjectOutputStream(bos);
              oos.writeObject(sh);
              byte[] bytes = bos.toByteArray();
      
              ByteArrayInputStream bis = new ByteArrayInputStream(bytes);
              ObjectInputStream ois = new ObjectInputStream(bis);
              Sheep sh1 = (Sheep) ois.readObject();
      
              sh1.setBirthday(new Date(1111111111111L));
      
              sh1.setName("少利");
              System.out.println(sh1);
              System.out.println(sh1.getName());
              System.out.println(sh1.getBirthday());
          }

       

    展开全文
  • 设计模式-源码

    2021-02-12 12:10:36
    设计模式 ...通过new产生一个对象需要非常繁琐的数据准备或访问权限,则可以使用原型模式 模版方法模式(模板模式) 结构 抽象类/抽象方法 一个模版方法 多个基本方法 抽象方法(抽象类声明,具体子
  • 2.主要特点一:细化到了权限分配阶段,功能模块齐全、基础架构完整、功能逻辑缜密、数据虽为假数据但是呈现的合理。 3.主要特点二:UI设计方面具有极高的立体高保真特点,动态交互效果多样全面且精...

    全部产品所在的店铺地址:https://www.axureshop.com/shop/3039

    本产品地址:https://www.axureshop.com/a/1471655.html

    用户名:11        密码:11

    1.尺寸:1920 x 1080(具有自适应以上浏览器尺寸的能力。)

    2.主要特点一:细化到了权限分配阶段,功能模块齐全、基础架构完整、功能逻辑缜密、数据虽为假数据但是呈现的合理。

    3.主要特点二:UI设计方面具有极高的立体高保真特点,动态交互效果多样全面且精致,另外整体加入了架构和结构的设计,并保持了整体的高保真设计。

    4.主要特点三:文本说明简介详细,有具体的操作业务的介绍,以及包括一些功能点儿的提示和操作注释。

    5.主要特点四:界面规范完整,不管是文本、图片、图标、元件,还是分割线,以及统计图都有统一的色系、大小、位置、样式的设定,并有相关的原型说明和操作描述。

    6.系统主功能(第一级)模块共包括:工程调度、证照管理、前期筹划、安全管理、质量管理、进度管理、风险管理、文明施工、图纸管理、技术管理、投资控制、物资设备、人员管理、验交管理、视频监控、系统管理等模块16个功能模块。

    7.系统主功能(第二级)模块共包括:通知公告、工程项目信息、通讯录、项目证照流程、项目证照信息、证照信息统计、征借地拆迁、房屋拆迁、市政配套、管线改迁、绿化移植、河道改移、应急预案、第三方监测、大型机械设备、安全巡检、标准化作业、质量巡检、质量验收、关键节点验收、第三方检测、创优规划、施工组织设计、计划进度、实时进度、进度分析、风险计划、风险清单、创建规划、施工场景、文明施工巡检、进度与计划、图纸审查、统计信息、设计方案、设计交底、测量管理、技术资料、项目概算、投资计划、用款计划、验工计价、资金拨付、系统物资库、甲供物资管理、甲供设备管理、乙供物资管理、乙供设备管理、考核管理、文档管理、人员信息、人员统计、工程验收、移交运营、监控窗口、视频信息、项目管理、模型管理、预警管理,59个功能大模块。

    8.系统副功能模块共包括:消息中心、系统日志,2个功能大模块。

    9.系统辅助功能模块共包括:个人信息、头像修改、清除缓存、修改密码、修改个人资料、记住密码、找回密码、返回首页,8个功能模块。

    10.主要动态效果:动态轮播图(支持分页和鼠标模拟手触滑动)、多态按钮、多层级弹窗、左右动态滑块、上滑滑块、动态水平导航菜单栏、动态tab切换菜单栏、下拉列表、变量赋值、动态单级查询、联动性多级动态查询、可视化窗口、动态列表、信息滑动通知,文本动态性切换。

    11. 里面也有内联框架,在这里特别声明一下,内联框架内的界面全部都是本人设计,且属于这个PC端(下载就可以看到)。

    12.里面所用到的统计图表解释本人用举行元件和标签画出,非动态组件。

    13.图片方面大部分为本人内部截图,非网上图片。

    14.里面的一些动态功能和通用性模块已经做成了用母版做成了组件化。

    15.这个平台也存在移动端,目前正在设计阶段,接下来就会上传,与其是一体的,两者彼此协同工作。

    16.建议使用1920x1080进行测试,低分辨率下预览,部分内容可能会影响体验。

    17.请路过的朋友们多多支持哈,卧枕江山在这里先谢谢了。

    18.以后会有更多优质的文章和产品在这个平台上进行发布,请尽请期待呦!

    展开全文
  • 需求分析与设计 第一章 大纲 1、整体需求分析 ...概念设计:明确需求问题、用户与使用场景,明确权限用户、功能点以及产品亮点(功能结构图) 逻辑设计:明确业务流程,完成页面流程与目录(页面流程图)

    • 第一章 大纲

    1、整体需求分析

    2、数据库设计

    需求分析:数据需求分析,明确功能需求与主体

    概念设计:系统流程图,数据流图,数据字典(Visio,UML等)

    逻辑设计:定义数据实体,绘制E-R图(Visio)

    物理设计:构建物理模型(PowerDesigner),

    检查优化:根据数据库设计原则与范式优化调整物理结构

    3、原型设计

    概念设计:明确需求问题、用户与使用场景,明确权限用户、功能点以及产品亮点(功能结构图)

    逻辑设计:明确业务流程,完成页面流程与目录(页面流程图)

    物理设计:确定页面框架,确定交互细节,UI设计迭代定稿。(手绘-低保真-高保真)


    • 第二章 工具与图形

    1、系统设计

    1. 系统架构图
    2. 用例图(U-C图User Case):明确系统面向用户和角色,确定各用户实体的核心功能,明确系统核心方向

    3.职权图:根据用例体现的角色用户,明确职权与用例之间关联关系。

    4.思维导图:具象化功能结构

    5.DFD图:粗粒度表现数据传递与加工过程

    6.系统流程图(Visio):核心业务与功能流程

    7.类图:描述系统中的类,以及各个类之间的关系的静态视图

    8.状态图/时序图:包括状态、转换、初始状态、终止状态(常用于OA与并发的部分)

    9.部署图:明确软件中各种组件驻留在什么硬件位置,以及这些硬件之间的相互关系

    2、数据库设计

    1. 数据来源图
    2. 数据流图
    3. 数据实体图E-R图(VISIO)
    4. 数据物理模型图(PowerDesigner/EA)

    3、工具

    Visio、PowerDesigner/EA、Xmind、Axure


    • 第三章 整体需求分析说明书

    1、引言

    1. 编写目的
    2. 适用范围
    3. 预期读者
    4. 参考资料

    2、概述

    1. 项目介绍(项目背景、目标、范围)
    2. 运行环境(软件环境、硬件环境、接口要求、网络要求)

    3、系统功能需求

    • 角色分析
    • 系统功能架构

    功能结构图

    主用例图

    模块用例图

    • 业务流程分析

    业务流程图

    • 功能需求细化

    功能描述

    功能要求

    功能流程图

    4、非功能需求

    1. 安全性要求
    2. 易用性要求
    3. 可靠性要求
    4. 系统响应时间要求
    5. 界面要求

    5、需求变更

    变更控制过程


    • 第四章 数据库设计
      1. 需求分析
        1. 项目背景
        2. 适用范围
        3. 预期读者
      2. 概念设计
        1. 功能需求
        2. 业务流图
        3. 数据环境
        4. 数据字典
        5. 命名规范
      3. 逻辑设计
        1. 数据来源与流向(图)
        2. 数据实体设计
        3. ETL规则设计
        4. 数据流图
        5. 数据逻辑实体设计
      4. 物理设计
        1. 数据库物理模型
      5. 检查优化

    • 第五章 原型设计
      1. 概念设计
        1. 项目背景
        2. 明确需求
        3. 用户与使用场景
        4. 权限用户
        5. 功能点(功能结构图)
        6. 产品亮点
      2. 逻辑设计
        1. 业务流图
        2. 页面目录
        3. 页面流程(页面流程图)
      3. 物理设计
        1. 页面框架
        2. 交互细节
        3. UI设计(手绘-低保真-高保真)
    展开全文
  • 创建者模型 设计模式 含义 类图 ...保证一个类只有一个实例,并且提供一个访问该实例的全局访问点 ...用来生产同一等级结构中的任意产品 ...通过new产生一个对象需要非常繁琐的数据准备或访问权限 结构模型
  • 二十三种设计模式【PDF版】

    热门讨论 2011-05-30 14:13:49
    1.设计模式更抽象,J2EE 是具体的产品代码,我们可以接触到,而设计模式在对每个应用时才会产生具体代码。 2.设计模式是比 J2EE 等框架软件更小的体系结构,J2EE 中许多具体程序都是应用设计模式来完成的,当你深入...
  • 经过分析,我使用BORLAND公司的Delphi开发工具,利用其提供的各种面向对象的开发工具,尤其是数据窗口这一能方便而简洁操纵数据库的智能化对象,首先在短时间内建立系统应用原型,然后,对初始原型系统进行需求迭代,不断...
  • 九、物联网云平台原型设计 9.1登录注册页面设计 9.2首页设计 9.3产品页面设计 9.4设备页面设计 9.5数据中心页面设计 十、数据库设计 10.1关系数据库表设计 10.1.1用户表 10.1.2角色表 10.1.3权限表 10.1.4用户角色...
  • 耐克在线销售系统

    2013-12-05 13:47:12
    耐克在线销售系统:原型+源码+设计概要+数据库 系统简介 耐克公司管理系统,为一款专门为耐克公司设计的ERP软件。每个耐克专卖店通过Internet连接到总公司的服务器,进行销售、进出货、库存查询等各项业务。 1、...
  • 浅谈后台管理系统

    2020-08-26 22:47:20
    后台是用来数据维护的,后台需要一个管理模块来对后台的权限、角色、密码和模块进行管理,如何设计这个模块是我们要学习的。 对于有经验的PM来说,当前台提出需求时,第一时间并不是去画原型设计功能、而是分析要...
  • asp.net知识库

    2015-06-18 08:45:45
    与DotNet数据对象结合的自定义数据对象设计 (二) 数据集合与DataTable 与DotNet数据对象结合的自定义数据对象设计 (一) 数据对象与DataRow ASP.NET中大结果集的分页[翻译] .net 2.0 访问Oracle --与Sql Server的...
  • java报告

    2012-01-02 20:55:45
    基于Java的制药企业进销存管理系统的设计与开发 一、主要任务与目标 1.掌握Java语言,能够学会使用JSP开发... 采用的关键技术和方法:如面向对象分析、设计与编程方法,UML设计方法,原型法,结构化分析与设计方法。
  • 实例146 数据统计方法的封装(用户登录功能设计) 实例147 SqlParameter参数方式操作数据库(存储过程) 5.5 以备后患:数据库的备份与恢复 实例148 数据库的备份操作 实例149 数据库的还原操作 实例150 ...
  • 实例146 数据统计方法的封装(用户登录功能设计) 实例147 SqlParameter参数方式操作数据库(存储过程) 5.5 以备后患:数据库的备份与恢复 实例148 数据库的备份操作 实例149 数据库的还原操作 实例150 ...
  • 15.2.2 数据丢失和数据破坏 15.2.3 数据修改 15.2.4 拒绝服务 15.2.5 软件错误 15.2.6 否认 15.3 易用性,性能、成本和安全性 15.4 建立一个安全政策 15.5 身份验证原则 15.6 加密技术基础 15.6.1 私有密钥...
  • PHP和MySQL Web开发第4版

    热门讨论 2014-08-13 15:32:15
    15.2.2 数据丢失和数据破坏 15.2.3 数据修改 15.2.4 拒绝服务 15.2.5 软件错误 15.2.6 否认 15.3 易用性,性能、成本和安全性 15.4 建立一个安全政策 15.5 身份验证原则 15.6 加密技术基础 15.6.1 私有密钥...
  • 15.2.2 数据丢失和数据破坏 15.2.3 数据修改 15.2.4 拒绝服务 15.2.5 软件错误 15.2.6 否认 15.3 易用性,性能、成本和安全性 15.4 建立一个安全政策 15.5 身份验证原则 15.6 加密技术基础 15.6.1 私有密钥加密 ...
  • 实例098 查询SQL Server数据表中的后3条数据 实例099 查询MySQL数据表中的前3条数据 实例100 查询MySQL数据表中的后3条数据 4.2 排序与分组函数的应用 实例101 按照字母顺序对留学生表进行排序 实例102 按姓氏笔画...
  • 实例098 查询SQL Server数据表中的后3条数据 实例099 查询MySQL数据表中的前3条数据 实例100 查询MySQL数据表中的后3条数据 4.2 排序与分组函数的应用 实例101 按照字母顺序对留学生表进行排序 实例102 按姓氏笔画...
  • 实例098 查询SQL Server数据表中的后3条数据 实例099 查询MySQL数据表中的前3条数据 实例100 查询MySQL数据表中的后3条数据 4.2 排序与分组函数的应用 实例101 按照字母顺序对留学生表进行排序 实例102 按姓氏笔画...
  • Java开发实战1200例.第2卷.part3

    热门讨论 2013-05-08 22:46:34
    实例097 查询SQL Server数据表中的前3条数据 174 实例098 查询SQL Server数据表中的后3条数据 175 实例099 查询MySQL数据表中的前3条数据 176 实例100 查询MySQL数据表中的后3条数据 177 4.2 排序与分组函数的应用 ...

空空如也

空空如也

1 2
收藏数 39
精华内容 15
关键字:

数据权限设计产品原型