精华内容
下载资源
问答
  • 给定用户一个职位,当用户登录的时候通过Session存储该职位所具有的操作权限。当用户执行操作时,逻辑层通过遍历判断用户是否具有这个操作的权限,若为空则显示警告信息。 第一种:每行存储一个操作权限  优点...

    方法一职位(角色)的角度出发,指定职位拥有那些操作权限。给定用户一个职位,当用户登录的时候通过Session存储该职位所具有的操作权限。当用户执行操作时,逻辑层通过遍历判断用户是否具有这个操作的权限,若为空则显示警告信息。

    第一种:每行存储一个操作权限

           优点:存储方便

           缺点:读取困难、执行效率低

    第二种:一行显示所有的所作权限,通过0和1来标识是否具有该操作的权限

           优点:读取方便、执行效率高

           缺点:存储困难、弹性差

     

     

    方法二权限的角度出发,指定用户拥有那些操作权限。当用户登录的时候通过Session存储该职位所具有的操作权限。当用户执行操作时,逻辑层通过遍历判断用户是否具有这个操作的权限,若为空则显示警告信息。

    第一种:每行存储一个操作权限

           优点:存储方便

           缺点:读取困难、执行效率低

    第二种:一行显示所有的所作权限,通过0和1来标识是否具有该操作的权限

           优点:读取方便、执行效率高

           缺点:存储困难、弹性差

     

     

    改进方法:权限等级的角度出发,权限等级为1~10,越高权限越大。超级管理员为每个模块下的每个功能设定相应的权限等级。在设置职员的职位时,指定该职位的权限等级,并为每个模块每个功能设定相应的权限等级。

    优点:开发方便、读取方便、执行效率高

    缺点:对刚上手的用户操作和理解上不友好、需要额外的页面

    展开全文
  • 数据库设计模式

    千次阅读 2009-12-29 15:39:00
    转自:http://www.cnblogs.com/zping/archive/2008/08/04/1260403.html一)主扩展模式 主扩展模式,通常用来将几个相似的对象的共有属性抽取出来,形成一个“公共属性表”;其余属性则分别形成“专有属性表”,且...

    转自:http://www.cnblogs.com/zping/archive/2008/08/04/1260403.html

    一)主扩展模式

     

     

    主扩展模式,通常用来将几个相似的对象的共有属性抽取出来,形成一个“公共属性表”;其余属性则分别形成“专有属性表”,且“公共属性表”与“专有属性表”都是“一对一”的关系。
    “专有属性表”可以看作是对“公共属性表”的扩展,两者合在一起就是对一个特定对象的完整描述,故此得名“主扩展模式”。
    举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解“主扩展模式”这个概念来使用的,请大家注意)。
    假设某公司包括如下6种类型的工作人员:采购员、营销员、库房管理员、收银员、财务人员和咨询专家,采用主扩展模式进行设计,如下图所示。
    无论哪种类型的工作人员,都要访问公司的办公软件,所以都有“登陆代码”和“登录密码”;并且作为一般属性,“姓名”、“性别”、“身份证号”、“入职时间”、“离职时间”等属性,都与个人所从事的工作岗位无关,所以可以抽取出来作为公共属性,创建“公司员工”表。
    很显然,公司委派员工采购哪些商品是“采购员”的专有属性,这是由公司的实际业务特点决定的。换句话说,公司不可能把采购任务放到“营销员”身上,也不可能放到“库房管理员”身上,“采购商品”属性就是“采购员”的专用属性。
    “采购员”表的主键与“公司员工”表的主键是相同的,包括字段名称和字段的实际取值;“采购员”表的主键同时是“公司员工”表主键的外键。在PDM图里可以看到“采购员”表中的“员工ID”字段后面有一个“<pk,fk>”标记,这个标记就说明“员工ID”字段既是“采购员”表的主键,同时也是该表的外键。
    “公司员工”表是主表,“采购员”表是扩展表,二者是“一对一”的关系,两个表的字段合起来就是对“采购员”这个对象的完整说明。同理,“公司员工”表和其他5个表之间也都分别构成了“一对一”的关系。

    对于主表来说,从表既可以没有记录,也可以有唯一一条记录来对主表进行扩展说明,这就是“主扩展模式”。


    二)主从模式

     

    主从模式,是数据库设计模式中最常见、也是大家日常设计工作中用的最多的一种模式,它描述了两个表之间的主从关系,是典型的“一对多”关系。
    举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解“主从模式”这个概念来使用的,请大家注意)。
    比如论坛程序。一个论坛通常都会有若干“板块”,在每个板块里面,大家可以发布很多的新帖。这时候“板块”和“发帖”就是主从模式,主表是“板块”,从表是“发帖”,二者是“一对多”的关系。

    多个潜水员也可以对感兴趣的同一份发帖进行回复,以表达各自的意见,这时候,一个“发帖”就有了多份“回复”,又构成了一个“主从模式”。

     

     

    三)名值模式
    通常用来描述在系统设计阶段不能完全确定属性的对象,这些对象的属性在系统运行时会有很大的变更,或者是多个对象之间的属性存在很大的差异。
    举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解“名值模式”这个概念来使用的,请大家注意)。
    1.  使用名值模式进行设计时,如果对“其他属性”仅作浏览保存、不作其它任何特殊处理,则通常会设计一个“属性模板”表,该表的数据记录在系统运行时动态维护。
    系统运行时,如需维护“产品其他属性”,可先从“属性模板”中选择一个属性名称,然后填写“属性值”保存,系统会将对应的产品ID、属性模板ID及刚刚填 写的“属性值”一起保存在“产品其他属性”里,这样就完成了相关设置。无论产品的其他属性需求发生怎样的变化、怎样增删改属性,都可以在运行时实现,而不必修改数据库设计和程序代码。
    2. 使用名值模式进行设计时,如果对“其他属性”有特殊处理,比如统计汇总,那么这个属性名称需要在程序代码中作“硬编码”,即该属性名称需要在程序代码中有所体现,此时可以在“产品其他属性”表中直接记录“属性名称”,不再需要“属性模板”表。

    系统运行时,如需维护“产品其他属性”,程序直接列出“属性名称”,然后填写“属性值”保存,系统会将对应的产品ID、属性名称及刚刚填写的“属性值”一起保存在“产品其他属性”里,这样就完成了相关设置。以后如果需求发生变更,则只需修改相应的程序代码即可,不必修改数据库设计。

     

     

    四)多对多模式
    也是比较常见的一种数据库设计模式,它所描述的两个对象不分主次、地位对等、互为一对多的关系。对于A表来说,一条记录对应着B表的多条记录,反过来对于B表来说,一条记录也对应着A表的多条记录,这种情况就是“多对多模式”。
    “多对多模式”需要在A表和B表之间有一个关联表,这个关联表也是“多对多模式”的核心所在。根据关联表是否有独立的业务处理需求,可将其划分为两种细分情况。
    1.  关联表有独立的业务处理需求。
    举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解“多对多模式”这个概念来使用的,请大家注意)。
    比如网上书店,通常都会有“书目信息”和“批发单”。一条“书目信息”面对不同的购买客户、可以存在多张“批发单”,反过来,一张“批发单”也可以批发多条书目,这就是多对多模式。中间的“批发单明细”表就是两者的关联表,具备独立的业务处理需求,是一个业务实体对象,因此它具备一些特有的属性,比如针对每一条明细记录而言的“累计退货次数”、“累计退货数量”、“累计结算次数”、“累计结算数量”;由于批发单明细在数据产生后已经打印出纸质清单提供给客户,因此在“批发单明细”表里对纸质清单中打印的书目信息属性作了冗余(逆标准化),这样在将来即使修改了“书目信息”表中的属性,也不会影响跟客户核对批发单明细,不会影响未来的财务结算业务。
    2. 关联表没有独立的业务处理需求
    举例如下(注:这个例子已经作了相当程度的简化,仅仅是用来帮助大家理解“多对多模式”这个概念来使用的,请大家注意)。

    比如用户与角色之间的关系,一般系统在做权限控制方面的程序时都会涉及到“系统用户表”和“系统角色表”。一个用户可以从属于多个角色,反过来一个角色里面也可以包含多个用户,两者也是典型的“多对多关系”。其中的关联表“用户角色关联表”在绝大多数情况下都是仅仅用作表示用户与角色之间的关联关系,本身不具备独立的业务处理需求,所以也就没有什么特殊的属性。

     

    五)使用上述四种模式的一般原则
    1. 什么时候用“主扩展模式”?

    对象的个数不多;各个对象之间的属性有一定差别;各个对象的属性在数据库设计阶段能够完全确定;各个扩展对象有独立的、相对比较复杂的业务处理需求,此时用“主扩展模式”。将各个对象的共有属性抽取出来设计为“主表”,将各个对象的剩余属性分别设计为相应的“扩展表”,“主表”与各个“扩展表”分别建立一对一的关系。
    2.  什么时候用“主从模式”?
    对象的个数较多且不固定;各个对象之间的属性几乎没有差异;对象的属性在数据库设计阶段能够完全确定;各个对象没有独立的业务处理需求,此时用“主从模式”。将各个对象设计为“从表”的记录,与“主表”对象建立一对多的关系。
    3.  什么时候用“名值模式”?
    对象的个数极多;各个对象之间的属性有较大差异;对象属性在数据库设计阶段不能确定,或者在系统运行时有较大变更;各个对象没有相互独立的业务处理需求,此时用“名值模式”。
    4.  什么时候用“多对多模式”?

    两个对象之间互为一对多关系,则使用“多对多模式”。

     

     

    除了上面提到的四种主要设计模式,还有一些其他模式,在某些项目中可能会用到,在这里先简单做个说明,暂不做深入讨论,等到以后的项目用到这些模式的时候,再结合实际需求详细解说。
    六)继承模式
    继承模式,可以看作是“主从模式”的一种特殊情况(或者说是“变形”),它所代表的两个对象也是“一对多”的关系。它与“主从模式”的区别是,“继承模式”中从表的主键是复合主键,并且复合主键中必定包含主表的主键列。
    根据从表继承主表的列的数量,继承模式又分以下两种情况:
    1.  从表继承主表的全部列
    在这种情况下,从表除了代表自身的专用字段以外,还冗余了主表的全部字段。这种设计方式的缺点显而易见:
    • 数据冗余度大
    • 一致性差
    • 磁盘存储量大
    它的优点也显而易见:
    • 正因为它的冗余度大、所以它不易丢失数据。假设主表数据丢失、或者被误操作删改,也能依据从表数据重新生成主表数据;这种设计方式,可以在发生数据损坏的时候从应用的角度进行一定程度的数据恢复,等于是在SQL Server数据库级别的数据恢复功能之上又加了一道保险。
    • 正因为它一致性差、主表数据被重复存储,所以可依据外键关系进行数据验证。将主从表记录作关联比较,如果数据不一致,就可以得知数据要么被人为改动,或者要么程序代码中存在bug。
    • 尽管磁盘存储量大,但是数据在查询统计的时候,只需针对从表进行搜索即可,无需关联操作,可以加快检索的速度。这就是数据库模型设计中经常提到的“以空间换时间”。
    2.  从表只继承主表的主键列
    这种设计方式,从表只继承了主表的主键列,这种方式的优缺点与前面刚好相反。
    优点:
    • 数据冗余度小
    • 一致性高
    • 磁盘存储量小
    缺点:
    • 正因为它的冗余度小、所以它易丢失数据。假设主表数据丢失、或者被误操作删改,就只能通过SQL Server数据库级别的数据恢复操作来找回丢失的数据了。
    • 正因为它一致性高,所以无法进行应用程序级的数据验证。
    • 由于采用了一致性设计,磁盘存储量较小,但是数据在查询统计的时候,必须要对两个表进行内连接(INNER JOIN)操作,才能搜索到相关数据。而内连接操作时需要耗费一定的时间的。这就是数据库模型设计中经常提到的“以时间换空间”。

    当然,在实际的数据库模型设计过程中,还会有介于上述两者之间的第3种情况出现,那就是从表继承了主表的主键列以及部分其他列。这就要求我们设计人员要依据实际的业务需求进行综合分析、权衡、折中,给出最符合业务需求的设计结果。

     

     

    七)自联结模式
    自联结模式,也可以看作是“主从模式”的一种特殊情况(或者说是“变形”),它在一张表内实现了“一对多关系”,并且可以根据业务需要实现“有限层”或者“无限层”的主从嵌套。
    这种模式用得最多的情况就是实现“树形结构”数据的存储,比如各大网站上常见的细分类别、应用系统的组织结构、Web系统的菜单树等都能用到这种模式。
    自联结模式有很多变体,且每种变体的优缺点同样鲜明。由于本连载的重点在于对跨行业通用数据库模型设计进行分析,所以对每种具体模式的细节方面的设计技巧不能作详细论述,请大家原谅。这里仅举两个例子说明:
    1.   简单自联结
    简单自联结,就是在一个表里设置当前类ID、父类ID,同时规定最顶层类的父类ID为一个固定值(比如0),在生成树的时候使用递归算法,记录的前后顺序通过“排序号”字段来确定。
    图9
    这个表用来存储菜单树很方便。首先会有一个主菜单,主菜单下有子菜单,子菜单下面又有孙菜单……菜单的数量不确定、层级不确定,用户可以在任意菜单下增加新的子菜单,或者删除某个子菜单及其下的所有孙菜单……这种设计方式很多人都会用到,短小精悍、维护方便、且完全满足用户需求,而且树的层次不限,扩展起来非常容易。这些都是它的优点。
    它的缺点就是树结构的生成由于使用了递归算法,必然要对该表进行多次读取(读取的次数 = 表内的记录数 – 最深层级的记录数),多次读取就来了比较低的运行效率,当表里的记录很多的时候,这个缺点可以称得上是致命的。
    于是就有了下面的这种设计模式。
    2.   扩展自联结
    扩展自联结,与简单自联结的最大区别就是通过附加冗余字段来避免递归运算,所要实现的主要目标就是一次读取就能生成整个树,一次提高树的生成效率。
    但是,鱼与熊掌不可兼得,凡事都有两面性。
    生成树的效率提高了,增删改表内记录的算法就会相应复杂,并且树的层数也变为有限的了。
    所以在此类设计的时候,大家还是要认真分析业务需求,看看实际业务的重点在什么地方,然后再作具体设计。比如一些门户网站在首页显示产品类别是业务重点,那么我们在设计的时候就要尽可能的提高生成树的效率,采取扩展自联结模式;相反,一些基于Web的业务系统,要求对菜单树的增删改维护操作尽量简单,由于菜单的数目不多,所以菜单树的生成效率不是瓶颈,那么我们设计的时候就可以采取简单自联结模式。
    关于附加冗余字段实现扩展自联结的方法很多,网上也有很多这方面的帖子,大家可以到Google上搜一下。
    在这里仅举一个例子如下:
    图10
    这个设计与前面的设计最大的区别就是排序字段,前面的简单自联结用了一个整数型的字段来实现排序,这里用了一个Varchar20型的字段“层级代码”来实现大排序。这个字段的取值两位一组,代表一层,假定最深为5层,初始值为0000000000。
    按照这样的设计,表内的数据记录可能就是这样的:
    ID            TypeName           ParentID            TypeLevel
    1             根类别               0                 000000
    2             类别1                1                 010000
    3             类别1.1               2                 010100
    4             类别1.2              2                 010200
    5             类别2                1                 020000
    6             类别2.1              5                 020100
    7             类别3                1                 030000
    8             类别3.1              7                 030100
    9             类别3.2              7                 030200
    10            类别1.1.1            3                 010101
    ……
    现在按TypeLevel字段进行排序,执行如下SQL语句:SELECT * FROM TMP_Type ORDER BY TypeLevel
    列出记录集如下:
    ID            TypeName            ParentID             TypeLevel
    1             总类别               0                 000000
    2             类别1                1                 010000
    3             类别1.1              2                 010100
    10            类别1.1.1            3                 010101
    4             类别1.2              2                 010200
    5             类别2                1                 020000
    6             类别2.1              5                 020100
    7             类别3                1                 030000
    8             类别3.1              7                 030100
    9              类别3.2              7                 030200
    ……

    在控制显示类别的层次时,只要对“层级代码”字段中的数值进行判断,每2位一组,如大于0则向右移2个空格。

     

     

     

     

     

     

     

    展开全文
  • 数据库题目之数据库设计

    千次阅读 2019-01-10 15:21:25
    一、选择题 ...2、在关系数据库设计中,设计关系模式是 的任务。 A.需求分析阶段 B.概念设计阶段 C.逻辑设计阶段 D.物理设计阶段 【答案:】C 3、数据库物理设计完成后,进入数据库实施阶...

    一、选择题

    1、在数据库设计中,用E-R来描述信息结构但不涉及信息在计算机中的表示,它是数据库设计的     阶段。

    A.需求分析 B概念设计 C.逻辑设计 D.物理设计    

    【答案:】B

    2、在关系数据库设计中,设计关系模式    的任务。

    A.需求分析阶段 B.概念设计阶段 C逻辑设计阶段 D.物理设计阶段  

    【答案:】C

    3、数据库物理设计完成后,进入数据库实施阶段,下列各项中属于实施阶段的工作是    

    A.建立库结构 B扩充功能 C.加载数据 D.系统调试      

    【答案:】B

    4、在数据库的概念设计中,最常用的数据模型    

    A.形象模型 B.物理模型 C.逻辑模型 D实体联系模型     

    【答案:】D

    5、E-R模型关系向关系模型转换时,一个MN联系转换为关系模型时,该关系模式的关键字是    

    AM端实体的关键字  BN端实体的关键字 CM端实体关键字与N端实体关键字组合 D.重新选取其他属性

    【答案:】C

    6、当局部E-R图合并成全局E-R图时可能出现冲突,不属于合并冲突的是   

    A.属性冲突 B.语法冲突 C.结构冲突 D.命名冲突      

    【答案:】B

    7、概念模型独立于      

    AE-R模型 B硬件设备和DBMS C.操作系统和DBMS DDBMS    

    【答案:】B

    8、数据流程图(DFD是用于描述结构化方法中    阶段的工具。

    A.可行性分析 B.详细设计 C.需求分析 D.程序编码

    【答案:】C

    9、下图所示的E-R图转换成关系模型,可以转换为    关系模式。

    A1 B2  C3   D4

    【答案:】C

    二、填空题

    1、数据库设计的几个步骤            

    【答案:】需求分析,概念设计,逻辑设计,物理设计,系统实施,系统运行和维护

    2、“为哪些表,在哪些字段上,建立什么样的索引”这一设计内容应该属于数据库   设计阶段。

    【答案:】物理

    3、在数据库设计中,把数据需求写成文档,它是各类数据描述的集合,包括数据项、数据结构、数据流、数据存储和数据加工过程等的描述,通常称为   

    【答案:】数据字典

    4、在设计分E-R时,由于各个子系统分别有不同的应用,而且往往是由不同的设计人员设计的,所以各个分E-R图之间难免有不一致的地方,这些冲突主要有       三类。

    【答案:】属性冲突 命名冲突 结构冲突

    三、简答题

    数据库设计一般分为哪几个阶段,每个阶段的主要任务是什么?

    解答:(1)数据库设计分为6个阶段:需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。

    (2)各阶段任务如下:①需求分析:准确了解与分析用户需求(包括数据与处理)。②概念结构设计:通过对用户需求进行综合、归纳与抽象,形成一个独立于具体 DBMS 的概念模型。③逻辑结构设计:将概念结构转换为某个 DBMS 所支持的数据模型,并对其进行优化。④数据库物理设计:为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。⑤数据库实施:设计人员运用 DBMS 提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。 ⑥数据库运行和维护:在数据库系统运行过程中对其进行评价、调整与修改。

    一、假设教学管理规定:

    ①一个学生可选修多门课,一门课有若干学生选修;

    ②一个教师可讲授多门课,一门课只有一个教师讲授;

    ③一个学生选修一门课,仅有一个成绩。

    学生的属性有学号、学生姓名;教师的属性有教师编号,教师姓名;课程的属性有课程号、课程名。

    要求:根据上述语义画出ER图,要求在图中画出实体的属性并注明联系的类型;

     

     

    解答:

     

     

     

    二、某企业集团有若干工厂,每个工厂生产多种产品,且每一种产品可以在多个工厂生产,每个工厂按照固定的计划数量生产产品;每个工厂聘用多名职工,且每名职工只能在一个工厂工作,工厂聘用职工有聘期和工资。工厂的属性有工厂编号、厂名、地址,产品的属性有产品编号、产品名、规格,职工的属性有职工号、姓名。

    (1)根据上述语义画出E-R图;

    (2)将该E-R模型转换为关系模型; (要求:1:1和1:n的联系进行合并)

    (3)指出转换结果中每个关系模式的主码和外码。

    答案:

    (1)本题的E-R图如下图所示。

     

     

    (2)转化后的关系模式如下:

    工厂(工厂编号,厂名,地址)

           产品(产品编号,产品名,规格)

             职工(职工号,姓名,工厂编号,聘期,工资)

             生产(工厂编号,产品编号,计划数量)

        (3)每个关系模式的主码、外码如下:

           工厂:主码是工厂编号,无外码;

             产品:主码是产品编号,无外码;

             职工:主码职工号,外码是工厂编号;

             生产:主码是(工厂编号,产品编号),

                   外码是工厂编号、产品编号。

    展开全文
  • 数据库模式

    万次阅读 多人点赞 2019-07-01 16:47:00
    定义:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。 理解: ① 一个数据库只有一个模式; ② 是数据库数据在逻辑级上的视图; ③ 数据库模式以某一种数据模型为基础; ④ ...

    模式(Schema)

    定义:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。

    理解:

    ① 一个数据库只有一个模式;

    ② 是数据库数据在逻辑级上的视图;

    ③ 数据库模式以某一种数据模型为基础;

    ④ 定义模式时不仅要定义数据的逻辑结构(如数据记录由哪些数据项构成,数据项的名字、类型、取值范围等),而且要定义与数据有关的安全性、完整性要求,定义这些数据之间的联系。

    又称概念模式或逻辑模式。是对所有用户数据逻辑结构和特征的所有描述。主要由数据库设计者进行DDL语言进行描述和定义。体现了数据库的整体观。

    外模式(External Schema)

    定义:也称子模式(Subschema)或用户模式,是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示。

    理解:

    ① 一个数据库可以有多个外模式;

    ② 外模式就是用户视图;

    ③ 外模式是保证数据安全性的一个有力措施。

    对应于用户级,是某个或某几个用户所能看到的数据库的数据视图,是从模式导出的一个子集,故又称子模式。用户主要通过DML语言对外模式数据进行操作。外反应了数据库的用户观。

    内模式(Internal Schema)

    定义:也称存储模式(Storage Schema),它是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式(例如,记录的存储方式是顺序存储、按照B树结构存储还是按hash方法存储;索引按照什么方式组织;数据是否压缩存储,是否加密;数据的存储记录结构有何规定)。

    理解:

    ① 一个数据库只有一个内模式;

    ② 一个表可能由多个文件组成,如:数据文件、索引文件。

    它是数据库管理系统(DBMS)对数据库中数据进行有效组织和管理的方法下一题

    其目的有:

    ② 为了减少数据冗余,实现数据共享;

    ② 为了提高存取效率,改善性能。

    又称存储模式,对应于物理级。描述了数据在物理介质上的存储方式和物理结构。体现了数据库的存储观。

    展开全文
  • 浅谈数据库用户表结构设计,第三方登录 转载于: https://www.cnblogs.com/jiqing9006/p/5937733.html 这篇文章比较不错,很有借鉴和应用的价值   说起用户表,大概是每个应用/网站立项动工(码农们)考虑的...
  • 数据库——数据库结构设计

    千次阅读 2020-03-08 22:21:25
    概念设计数据库设计的 核心环节,通过对用户需求进行综合;归纳;与抽象,形成一个独立于DBMS 的概念模型 数据库概念设计的目标 1 定义与描述应用领域设计的数据范围 2 获取信息模型 3 描述数据的属性特征 4 描述...
  • 数据库三级模式

    万次阅读 2018-01-04 22:09:26
    用户级对应外模式,概念级对应模式,物理级对应内模式,使不同级别的用户数据库形成不同的视图。所谓视图,就是指观察、认识和理解数据的范围、角度和方法,是数据库用户“眼中"的反映,很显然,不同层次(级别...
  • 数据库关系模式

    千次阅读 2019-11-08 19:28:42
    1.数据库关系模式中三级两映像结构知识...外模式也称子模式或用户模式,是数据库用户(包括程序员和最终端用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,外模式主要描述用户视图...
  • 数据库设计

    千次阅读 2018-07-11 18:33:50
    数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库极其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计的步骤 ⒈需求分析阶段 收集和分析用户需求,结果得到数据...
  • 数据库数据库设计

    千次阅读 2020-11-16 16:47:49
    1,数据库设计概述 1.1,数据库设计的基本...数据库设计的基本任务:是根据用户的信息需求、处理需求和数据库的支持环境(包括硬件、操作系统和DBMS),设计数据库模式(包括外模式、逻辑模式和内模式)及其典型的应用程
  • 数据库模式的意义

    2020-12-14 20:01:20
     外模式又称子模式用户模式,属于用户级别。它是某个或某几个用户所看到的数据视图,类似于命名空间,是与某一应用有关的数据的逻辑模式。外模式反应了数据库用户观。  概念模式  概念模式又称逻辑模式,...
  • 浅谈数据库三大模式:外模式、概念模式和内模式

    万次阅读 多人点赞 2019-09-17 09:45:56
    对应数据库的升级、外模式包括(子模式 用户模式) 用来描述用户看到或者使用那部分的数据的逻辑结构,用户根据外模式用户数据操作语句或者程序去操作数据库中的数据,外模式的主要特点用来描述组成用户视图各个记录...
  • 数据库 -DataBase设计

    千次阅读 2015-05-07 10:02:41
    数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。...
  • 数据库 - 逻辑结构设计

    万次阅读 2015-05-08 10:22:24
    逻辑结构设计逻辑结构设计的任务 把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构 逻辑结构设计的步骤 ...如何将实体型和实体间的联系转换为关系模式 如何确
  • 数据库系统的模式结构

    千次阅读 2019-04-08 17:37:57
    有关数据库三级模式,两级映像功能以及数据独立性的简单介绍
  • 数据库三级模式两级映像

    千次阅读 2019-12-19 23:18:47
    2.如果从数据库最终用户角度来看,数据库的结构可分为:单用户结构,分布式结构,客户端/服务器,浏览器/应用服务器/数据库服务器多层结构等。这是数据库系统外部体系结构。 DBMS系统种类很多,他们支持的数据模式...
  • 数据库三级模式介绍

    千次阅读 2015-08-29 12:03:20
    数据库管理系统中,其模式是指数据模式(data schema),是数据抽象的结果表示,如用关系模型抽象学生的基本信息表示为:学生(学号,姓名,性别,出生年月,入校年月,专业编号),此表示即为一种数据模式。  在...
  • 数据库设计方法 数据库系统的设计过程...满足各种用户的应 用需求包括 数据库的结构设计:静态的数据模型设计(模式和 子模式设计) 数据设计:应用程序设计(在模型上的动态操作) 一般地:数据库设计是以一个现成的DBMS为 基
  • 数据库课程设计 ——酒店管理系统

    万次阅读 多人点赞 2019-05-31 10:36:11
    (3) 数据库模式的定义 根据上述关系模式和转换原则,可得到数据库模式和用户子模式。为了方便理解和使用,表明和列名采用驼峰命名法,数据库的模式如表1-3~~表1-9所示,用户子模式如表1-10~1-14表所示。 表1-3 房间...
  • 数据库模式

    千次阅读 2014-12-11 20:30:29
    数据库模式
  • 教材:王珊 萨师煊 编著 数据库系统概论(第5版) 高等教育出版社 注:文档高清截图在后 第7章 数据库设计 7.1 数据库设计概述 1、数据库应用系统,通常...狭义来讲是设计数据库本身,即设计数据库的各级模式并建立...
  • 数据库系统的三级模式:外模式、模式、内模式。模式(逻辑模式、概念模式):实际上是...外模式(子模式、用户模式):数据库用户能够看见和使用的局部数据的逻辑结构和特征,是数据库用户的数据视图。描述的是...
  • 数据库设计——评论回复功能

    万次阅读 多人点赞 2017-05-03 02:43:48
    本文主要介绍评论功能的数据库设计。评论功能最主要的是发表评论和回复评论(删除功能在后台)。评论功能的拓展功能体现有以下几方面: (1)单篇文章的评论数量和信息展示; (2)从时间维度,按照时间倒
  • 数据库系统模式的概念;模式(Schema);实例(Instance);“型” 和“值” 的概念;型(Type);值(Value);数据库系统的三级模式结构;模式/逻辑模式;外模式;内模式;两级映射与数据独立性;外模式/模式映像;内...
  • 数据库模式理解

    万次阅读 2016-07-14 10:12:26
     定义:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。  理解:  ① 一个数据库只有一个模式;  ② 是数据库数据在逻辑级上的视图;  ③ 数据库模式以某一种数据模型...
  • 数据库设计(Database Redesign)

    千次阅读 2014-04-05 20:38:18
    数据库设计有三个来源:(1)可以从现有数据开始设计数据库,例如从excel表格等,这种模式下需要考虑的问题是数据的normalization,最终通常将数据转化为BCNF范式;(2)设计新的数据库,这种模式需要从构建E-R图...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 180,778
精华内容 72,311
关键字:

数据库用户子模式设计