精华内容
下载资源
问答
  • 数据库设计模式

    千次阅读 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个空格。

     

     

     

     

     

     

     

    展开全文
  • XXXX大学 XX学院 数据库设计说明书 课程 数据库课程设计 课题 毕业设计管理系统 班级 学号 姓名 指导教师 课题发给日期 2014 年 6 月 16 日 课题完成日期 2014 年 6 月 27 日 评语 评分 摘 要 随着计算机及计算机...
  • 数据库课程设计 课题 毕业设计管理系统 班级 学号 姓名 指导教师 课题发给日期 2014年6月16日 课题完成日期 2014年6月27日 评语 评分 摘 要 随着计算机及计算机网络的普及和全国各院校的校园网络的日益完善健全...
  • 数据库关系模式

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

    1.数据库关系模式中三级两映像结构知识点

    ( 1)模式(基本表)

    模式即逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。一个数据库只有一个概念模式,即对应数据库中设计的基本表。

    ( 2)外模式(视图)

    外模式也称子模式或用户模式,是数据库用户(包括程序员和最终端用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,外模式主要描述用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束性条件。是与某一应用有关的数据逻辑表示。一个数据库可以有多个外模式。但一个应用只能使用一个外模式。

    ( 3)内模式(存储文件)

    内模式是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式。一个数据库只有一个内模式。内模式定义的是存储记录的类型、存储域的表示、存储记录的物理顺序指引元、索引和存储路径等数据的存储组织,即指数据库在存储设备上的存储文件。

    2.数据库:π表示关系代数投影操作,δ表示关系代数选择操作

    3.分布式数据库基本概念。

    • 分片透明是指用户或应用程序不需要知道逻辑上访问的表具体是怎么分块储存的。
    • 复制透明是指采用复制技术的分布方法,用户不需要知道数据是复制到哪些节点,如何复制的。
    • 位置透明是指用户无需知道数据存放的物理位置;
    • 逻辑透明局部数据模型透明,是指用户或应用程序无需知道局部场地使用的是哪种数据模型

    展开全文
  • 数据库模式

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

    模式(Schema)

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

    理解:

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

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

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

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

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

    外模式(External Schema)

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

    理解:

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

    ② 外模式就是用户视图;

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

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

    内模式(Internal Schema)

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

    理解:

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

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

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

    其目的有:

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

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

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

    展开全文
  • 数据库模式的意义

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

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

    1,数据库设计概述

    1.1,数据库设计的基本概念

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

    数据库设计的目标:是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境

    数据库设计的基本任务:是根据用户的信息需求、处理需求和数据库的支持环境(包括硬件、操作系统和DBMS),设计出数据库模式(包括外模式、逻辑模式和内模式)及其典型的应用程序

    1.2,数据库设计的方法

    直观设计法(手工试凑发):数据库设计只是一种经验的反复实施,而不能称为是一门科学,缺乏科学分析理论基础和工程手段的支持,因为设计质量与设计人员的经验和水平有直接关系,所以设计质量很难保证。具有周期短、效率高、操作简便、易于实现等优点。主要是用于简单小型系统。

    规范设计法:数据库设计分为若干阶段,明确规定各阶段的任务,采用“自顶向下、分层实现、逐步求精”的设计原则,结合数据库理论和软件工程设计方法,实现设计过程的每一细节,最终完成整个设计任务。(新奥尔良方法、基于E-R模型的数据库设计方法、基于3NF(第三范式)的设计方法、面向对象的数据库设计方法、统一建模语言(UML方法)。

    计算机辅助设计法:在数据库设计的某些过程中,利用计算机和一些辅助设计工具,模拟某一规范设计方法,并以人的知识或经验为主导,通过人机交互方式实现设计中的某些部分。 (Oracle 公司开发的 Designer、Sybase公司开发的 PowerDesigner)。

    1.3,数据库设计的基本步骤

    需求分析:通过详细调查现实世界要处理的对象(组织、部门、企业等),充分了解原系统(手工系统或计算机系统)工作概况,明确用户的各种需求。

    概念结构设计:通过对用户需求进行综合、归纳与抽象,形成一个独立于具体数据库管理系统的概念模型。

    逻辑结构设计:概念结构转换为某个数据库管理系统所支持的数据模型,并对其进行优化。

    物理结构设计:逻辑数据结构选取一个最适合应用环境的物理结构,包括存储结构和存取方法。

    数据库实施:根据逻辑设计和物理设计的结果构建数据库,编写与调试应用程序,组织数据入库并进行试运行。

    数据库运行和维护:经过试运行后即可投入正式运行,运行过程中必须不断对其进行评估、调整与修改。

    ★需求分析和概念设计独立于任何数据库管理系统

    ★逻辑设计和物理设计与选用的数据库管理系统密切相关

    设计阶段

    设计描述

    数据

    处理

    需求分析

    数据字典、数据项、数据流、数据存储的描述

    数据流图和判定树、数据字典中处理过程的描述

    概念结构设计

    概念模型(ER)、数据字典

    系统说明书 (系统要求、方案、概图、数据流图)

    逻辑结构设计

    某种数据模型(如关系)

    系统结构图(模块结构)

    物理设计

    存储安排、方法选择、存取路径建立

    模块设计

    实施阶段

    编写模式、装入数据、数据库试运行

    程序编码、编译联结、测试

    运行维护

    性能监测、转储/恢复、数据库重组和重构

    新旧系统转换、运行、维护

    2,需求分析

    2.1,需求分析及其任务

    需求分析就是分析用户的需求:设计数据库的起点,结果是否准确地反映了用户的实际要求,将直接影响到后面各个阶段的设计,并影响到设计结果是否合理和实用。

    需求分析的任务:数据库设计人员和用户双方共同收集信息需求和处理需求;通过仔细分析;将这些需求按一定的规范要求以用户和设计人员都能理解接受的文档形式确定下来。

    2.2,需求分析的方法

    需求分析的三个步骤:

    需求调查: 收集需求信息, 调查清楚用户的实际要求, 与用户达成共识。

    分析、整理和表达这些需求信息,形成需求说明书(例如,包括DFD和DD等)。

    评审:由主管部门和专家评价、审批。

    需求调查

    需求调查的目的:主要是了解企业的组织机构设置, 各个组织机构的职能、工作目标、职责范围,主要业务活动及大致工作流程,获得各个组织机构的业务数据及其相互联系的信息,为分析整理工作做好前期基础工作

    需求调查的内容:组织机构的情况组成, 职责, 作用, 现状, 问题,哪些业务适合计算机管理, 哪些不适合各个部门的业务活动现状(调查的重点):  输入和使用的数据, 加工处理方法, 数据的流程, 输出的数据及格式, 注意收集原始数据资料, 如台帐、单据、发票、收据、统计报表、文档、档案等。外部要求:调查数据处理的响应时间、频度和如何发生的规则,以及经济效益的要求,安全性和完整性的要求。协助用户明确对新系统的各种要求(调查的又一个重点): 信息要求, 处理要求, 安全性要求, 完整性要求, 未来规划中对数据的应用需求等。确定新系统的边界: 哪些由计算机完成, 哪些由人工完成。

    需求调查的步骤:调查组织机构情况。②调查各部门的业务活动情况。③协助用户明确对新系统的各种要求,包括信息要求、处理要求、完全性与完整性要求。④确定新系统的边界。

    需求调查的方式:跟班作业:通过亲身参加业务工作了解业务活动的情况。开调查会:通过与用户座谈来了解业务活动情况及用户需求。专人介绍。询问:某些调查中的问题,可以找专人询问。设计调查表请用户填写:调查表设计合理,则很有效。查阅记录:查阅与原系统有关的数据记录。

    需求调查策略:

    • 对高层负责人的调查: 一般采用个别交谈方式, 先给一份详细的调查提纲, 以便有所准备。
    • 对中层管理人员的调查: 可采用开座谈会, 个别交谈, 发调查表, 查阅记录的调查方式。
    • 对基层业务人员的调查: 主要采用发调查表, 个别交谈或跟班作业的调查方式。

    分析整理

    分析整理的工作:

    业务流程分析和表示

    • 目的是获得业务流程及业务与数据联系的形式描述。
    • 采用数据流层次结构分析法(SA)
    • 分析结果以数据流图(DFD)表示, 再辅以数据字典(DD)作补充描述

    需求信息的补充描述

    • 数据字典: 主要用于概念结构设计。
    • 业务活动清单: 列出每一部门中最基本的工作任务。
    • 其他需求清单: 如完整性、安全性、一致性要求

    撰写需求分析说明书

    分析整理的方法:结构化分析方法(SA方法)

    SA方法从最上层的系统组织机构入手,采用自顶向下、逐层分解的方式分析系统。

    SA步骤:a)先把任何一个系统都抽象为DFD图形式。b)然后从最上层的系统组织机构入手,采用自顶向下,逐步分解,逐步求精的方式分析系统,获得多层DFD图。

    数据流图(DFD)

    https://shao12138.blog.csdn.net/article/details/109103706#t2

    数据字典(DD)

    https://shao12138.blog.csdn.net/article/details/109103706#t4

    3,概念结构设计

    3.1,概念模型

    概念结构设计:需求分析得到的用户需求抽象为信息结构(即概念模型)的过程。

    目前应用最普遍的是实体关系(E-R)模型,它将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述

    3.2,E-R概念模型

    https://shao12138.blog.csdn.net/article/details/103659528

    3.3,概念结构设计

    实体与属性的划分

    为了简化E-R图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待

    两条准则:作为属性,不能再具有需要描述的性质。属性必须是不可分的数据项,不能包含其他属性。属性不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。

    4,逻辑结构设计

    4.1,逻辑结构设计概述

    逻辑结构设计的任务:概念结构转换成特定DBMS所支持的数据模型的过程。关系数据库逻辑设计的结果是一组关系模式的定义

    逻辑结构设计的步骤:

    概念结构转换为一般的关系、网状、层次模型;

    转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换;

    数据模型进行优化

    关系数据库逻辑设计的步骤

    概念模型(例如基本E-R)转换为关系模式的集合 --- 得到关系数据库模式;

    运用关系数据理论对关系数据库模式进行规范化处理;

    关系数据库模式进行评价;

    关系数据库模式进行修正;

    设计关系子模式 --- 视图

    4.2,ER图向关系模型的转换

    一个实体转换为一个关系模式

    原则:关系的属性=实体型的属性;关系的码=实体型的码;关系模式的码(用下横线标出) = 实体型的码

    转换为:学生(学号,姓名,系别)

    每个联系类型转换为独立的关系模式

    原则:关系模式的属性 = 与该联系相连的各实体型的+该联系自身的属性;关系模式的码(用下划线标出) = 各实体型的码;

    一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并

    转换为一个独立的关系模式,原则关系模式的属性 = 与该联系相连的各实体型的码  联系自身的属性;关系模式的码(用下划线标出) = 各实体型的码;

    与某一端实体对应的关系模式合并,原则:合并后关系的属性=加入对应关系的码和联系本身的属性;合并后关系的码不变;

    ②一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。

    转换为一个独立的关系模式,原则关系模式的属性 = 与该联系相连的各实体型的码  联系自身的属性;关系模式的码(用下划线标出) = n端实体的码;

    与某一端实体对应的关系模式合并,原则:合并后关系的属性=n端关系中加入1端关系的码和联系本身的属性;合并后关系的码不变;

    ③一个m:n联系必须转换为一个独立的关系模式

    转换为一个独立的关系模式,原则关系模式的属性 = 与该联系相连的各实体型的码  联系自身的属性;关系模式的码(用下划线标出) =各实体码的组合;

    三个或三个以上实体间的一个多元联系转换为一个关系模式,原则关系模式的属性 = 与该联系相连的各实体型的码  联系自身的属性;关系模式的码(用下划线标出) =各实体码的组合;

    具有相同码的关系模式可合并

    目的:减少系统中的关系个数

    合并方法:

    • 将其中一个关系模式的全部属性加入到另一个关系模式中
    • 然后去掉其中的同义属性(可能同名也可能不同名)
    •  适当调整属性的次序

    把每一个实体装换为一个关系

    首先分析各实体的属性,从中确定其主键,然后分别用关系模式表示。

    实体:学生	对应的关系:学生(学号,姓名,性别,年龄)
    实体:课程	对应的关系:课程(课程号,课程名)
    实体:教师	对应的关系:教师(教师号,姓名,性别,职称)
    实体:系		对应的关系:系(系名,电话)

    把每一个联系装换为关系模式

    4个联系转换为关系模式,其中2个多对多类型的联系转换为独立关系模式,2个一对多的联系也转换为独立的关系模式。

    联系:属于	对应的关系:属于(教师号,系名)
    联系:讲授	对应的关系:讲授(教师号,课程号)
    联系:选修	对应的关系:选修(学号,课程号,成绩)
    联系:拥有	对应的关系:拥有(学号,系名)
    

    画出关系图

    4.3,数据模型的优化

    数据库逻辑设计的结果不是唯一的,得到初步数据模型后,还应该适当地修改、调整数据模型的结构,以进一步提高数据库应用系统的性能,这就是数据模型的优化。

    规范化过程可分为两个步骤:确定范式级别,实施规范化处理

    确定数据依赖写出每个关系模式内部各属性之间的数据依赖;写出不同关系模式的属性(外码和主码)之间的数据依赖;

    对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。

    按照数据依赖的理论对关系模式进行分析,考察是否存在部分函数依赖、传递函数依赖、多值依赖等,确定各关系模式分别属于第几范式。

    按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进行合并或分解。(并不是规范化程度越高的关系就越优。当一个应用的查询中经常涉及到两个或多个关系模式的属性时,系统必须经常地进行连接运算,而连接运算的代价是相当高的,可以说关系模型低效的主要原因就是做连接运算引起的,因此在这种情况下,第二范式甚至第一范式也许是最好的。

    对关系模式进行必要的分解,提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解垂直分解

    • 水平分解:(基本)关系的元组分为若干子集合,定义每个子集合为一个子关系,以提高系统的效率。
    • 垂直分解:把关系模式R的属性分解为若干子集合,形成若干子关系模式。

    4.4,设计用户子模式(外模式)

    概念模型转换为逻辑模型(数据库模式), 还应根据局部应用的需求, 结合具体DBMS的特点, 设计用户的外()模式 。利用RDBMS提供的视图(View)功能设计

    定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面:使用更符合用户习惯的别名。针对不同级别的用户定义不同的视图,以保证系统的安全性。简化用户对系统的使用。

    视图:https://shao12138.blog.csdn.net/article/details/109584275#t23

    5,物理结构设计

    数据库的物理结构:数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统。

    数据库的物理设计:一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程,就是数据库的物理设计。

    数据库物理设计的步骤:确定数据库的物理结构,在关系数据库中主要指存取方法和存储结构;物理结构进行评价,评价的重点是时间和空间效率;若评价结果满足原设计要求,则可进入到物理实施阶段。否则,就需要重新设计或修改物理结构,有时甚至要返回逻辑设计阶段修改数据模型

    5.1,数据库物理设计的内容和方法

    准备工作:要充分了解应用环境,详细分析要运行的事务。以获得选择物理数据库设计所需要的参数。分析数据库查询事务需要的信息、数据更新事务需要的信息、每个事务在各关系上运行的频率和性能要求等。要充分了解所用的 DBMS的内部特征, 特别是系统提供的存取方法和存储结构。

    内容:为关系模式选择存取方法,即要确定选择哪些存取方法,建立哪些存取路径。设计关系()、聚簇、索引、日志、备份等数据的物理存储结构。

    5.2,关系模式存取方法选择

    数据库系统是多用户共享的系统,对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。

    数据库关系系统:B+树索引存取方法;②Hash索引存取方法;③聚簇存取方法;

    B+树索引

    选择索引存取方法 就是根据应用要求确定对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要设计为唯一索引。

    选贼索引存取方法的一般规则:

    • 如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索引(或组合索引
    • 如果一个属性经常作为最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引
    • 如果一个(或一组)属性经常在连接操作的连接条件中 出现,则考虑在这个(或这组)属性上建立索引

    关系上定义的索引数过多会带来较多的额外开销,无论是维护还是查找

    HASH存取方法

    选择Hash存取方法的规则:如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中,而且满足下列两个条件之一

    • 该关系的大小可预知,而且不变;
    • 该关系的大小动态改变,但所选用的数据库管理系统提供了动态Hash存取方法。

    聚簇存取方法

    为了提高某个属性(或属性组)的查询速度,把这个或这些属性(称为聚簇码)上具有相同值的元组集中存放在连续的物理块上,称为聚簇。该属性(或属性组)称为聚簇码。许多关系型数据库管理系统都提供了聚簇功能。

    聚簇索引:建立聚簇索引后,基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中元组的物理顺序一致。一个数据库可以建立多个聚簇,一个关系只能加入一个聚簇。

    聚簇索引的适用条件:很少对基表进行增删操作;很少对其中的变长列进行修改操作;

    聚簇索引的用图:

    • 大大提高按聚簇属性进行查询的效率
    • 节省存储空间:聚簇以后,聚簇码相同的元组集中在一起了,因而聚簇码值不必在每个元组中重复存储,只要在一组中存一次就行了。

    聚簇索引的局限性:

    • 聚簇只能提高某些特定应用的性能
    • 建立与维护聚簇的开销相当大;已有关系建立聚簇,将导致关系中元组的物理存储位置移动,并使此关系上原有的索引无效,必须重建。当一个元组的聚簇码改变时,该元组的存储位置也要做相应改变

    聚簇索引的适用范围:

    • 既适用于单个关系独立聚簇,也适用于多个关系组合聚簇
    • 通过聚簇码进行访问或连接是该关系的主要应用,与聚簇码无关的其他访问很少或者是次要的时,可以使用聚簇。尤其SQL语句中包含有与聚簇码有关的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短语时,使用聚簇特别有利,可以省去或减化对结果集的排序操作

    设计候选聚簇:在一起进行连接操作的关系可以建立组合聚簇;

    如果一个关系的一组属性经常出现在相等比较条件中,则该单个关系可建立聚簇;

    如果一个关系的一个(或一组)属性上的值重复率很高,则此单个关系可建立聚簇

    检查候选聚簇索引中的关系,取消不必要的关系

    聚簇中删除经常进行全表扫描的关系

    从聚簇中删除更新操作远多于连接操作的关系

    聚簇中删除重复出现的关系

    5.3,确定数据库的存储结构

    确定数据库物理结构主要指确定数据的存放位置和存储结构,包括:确定关系、索引、聚簇、日志、备份等的存储安排和存储结构,确定系统配置等。

    影响数据存放位置和存储结构的因素:硬件环境和应用需求;要综合考虑存取时间、存储空间利用率和维护代价(这三个方面常常是相互矛盾的。比如:消除一切冗余数据虽能够节约存储空间和减少维护代价,但往往会导致检索代价的增加。必须进行权衡,选择一个折中方案。

    确定数据的存放位置

    原则:根据应用情况将易变部分与稳定部分分开存放,经常存取部分与存取频率较低部分分开存放。

    可以将日志文件与数据库对象(表、索引等)放在不同的磁盘以改进系统的性能。

    可以将比较大的表分别放在两个磁盘上,以加快存取速度,这在多用户环境下特别有效。

    数据库数据备份、日志文件备份等由于只在故障恢复时才使用,而且数据量很大,可以考虑存放在磁带上。

    确定系统配置

    ①系统都为这些变量(同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数(使用的缓冲区长度、个数)、存储分配参数 、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等)赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值,以使系统性能最优。

    ②在物理设计时对系统配置变量的调整只是初步的,要根据系统实际运行情况做进一步的调整,以切实改进系统性能。

    5.4,评价物理结构

    评价物理数据库的方法完全依赖于所选用的DBMS

    评价内容:

    • 对数据库物理设计过程中产生的多种方案进行细致的评价;
    • 定量估算各种方案的存储空间、存取时间、维护代价;
    • 对估算结果进行权衡、比较,从中选择一个较优的合理的方案作为数据库的物理结构。

    6,数据库的实施和维护

    6.1,数据的载入和应用程序的调试

    数据库实施阶段主要工作:

    ①建立实际的数据库结构。DDL定义数据库:定义基本表、索引、约束、视图等;

    ②装入数据,组织数据入库(又称数据库加载),组织数据入库是数据库实施阶段最主要的工作。

    • 数据装载方法:人工方法;计算机辅助方法
    • 数据筛选、输入、转换(工具)、校验,确保正确

    ③编制和调试数据库应用程序。数据库应用程序的设计应该与数据库设计并行进行。数据库结构建立好后,就可以开始编制与调试数据库的应用程序。

    6.2,数据库的试运行

    数据库的试运行:应用程序调试完成,并且已有一小部分数据入库后,就可以开始对数据库系统进行联合调试,也称数据库的试运行。

    主要工作包括

    功能测试:实际运行应用程序,执行对数据库的各种操作,测试应用程序的各种功能。

    性能测试:测量系统的性能指标,分析是否符合设计目标。

    数据库性能指标的测量

    数据库物理设计阶段在评价数据库结构估算时间、空间指标时,作了许多简化和假设,忽略了许多次要因素,因此结果必然很粗糙。

    数据库试运行则是要实际测量系统的各种性能指标(不仅是时间、空间指标),如果结果不符合设计目标,则需要返回物理设计阶段,调整物理结构,修改参数;有时甚至需要返回逻辑设计阶段,调整逻辑结构。

    数据的分期入库

    重新设计物理结构甚至逻辑结构,会导致数据重新入库

    由于数据入库工作量实在太大,所以可以采用分期输入数据的方法

    • 先输入小批量数据供先期联合调试使用
    • 待试运行基本合格后再输入大批量数据
    • 逐步增加数据量,逐步完成运行评价

    数据库的转储和恢复

    在数据库试运行阶段,系统还不稳定,硬、软件故障随时都可能发生

    系统的操作人员对新系统还不熟悉,误操作也不可避免

    因此必须做好数据库的转储和恢复工作,尽量减少对数据库的破坏

    6.3,数据库的运行和维护

    在数据库运行阶段,对数据库经常性的维护工作主要是由数据库管理员完成的,包括:

    数据库的转储和恢复

    • 数据库管理员要针对不同的应用要求制定不同的转储计划,定期对数据库和日志文件进行备份。
    • 一旦发生介质故障,即利用数据库备份及日志文件备份,尽快将数据库恢复到某种一致性状态

    数据库的安全性、完整性控制

    初始定义

    • 数据库管理员根据用户的实际需要授予不同的操作权限
    • 根据应用环境定义不同的完整性约束条件

    修改定义

    • 当应用环境发生变化,对安全性的要求也会发生变化,数据库管理员需要根据实际情况修改原有的安全性控制
    • 由于应用环境发生变化,数据库的完整性约束条件也会变化,也需要数据库管理员不断修正,以满足用户要求

    数据库性能的监督、分析和改进

    在数据库运行过程中,数据库管理员必须监督系统运行,对监测数据进行分析,找出改进系统性能的方法。

    • 利用监测工具获取系统运行过程中一系列性能参数的值
    • 通过仔细分析这些数据,判断当前系统是否处于最佳运行状态
    • 如果不是,则需要通过调整某些参数来进一步改进数据库性能

    数据库的重组织与重构造

    数据库的重组织

    • 为什么要重组织数据库   数据库运行一段时间后,由于记录的不断增、删、改,会使数据库的物理存储变坏,从而降低数据库存储空间的利用率和数据的存取效率,使数据库的性能下降
    • 重组织的形式:全部组织和部分组织,只对频繁增、删的表进行重组织
    • 重组织的目标:提高系统性能

    数据库的重构造

    • 为什么要重构造数据库  数据库应用环境发生变化,会导致实体及实体间的联系也发生相应的变化,使原有的数据库设计不能很好地满足新的需求。
    • 重构造的主要工作  根据新环境调整数据库的模式和内模式增加或删除某些数据项改变数据项的类型、增加或删除某个表、改变数据库的容量、增加或删除某些索引。
    • 重构造数据库的程度是有限的  应用变化太大,已无法通过重构数据库来满足新的需求,或重构数据库的代价太大  表明现有数据库应用系统的生命周期已经结束,应该重新设计新的数据库应用系统了。
    展开全文
  • 数据库题目之数据库设计

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

    千次阅读 2014-12-11 20:30:29
    数据库模式
  • 数据库 -DataBase设计

    千次阅读 2015-05-07 10:02:41
    数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。...
  • 数据库中存储树形结构...此文以存储树形结构数据为需求,分别描述了利用关系型数据库和文档型数据库作为存储的几种设计模式。 A.关系型数据库设计模式1 id name parent_id 1 A NULL
  • 数据库设计

    千次阅读 2018-07-11 18:33:50
    数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库极其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计的步骤 ⒈需求分析阶段 收集和分析用户需求,结果得到数据...
  • 数据库系统模式的概念;模式(Schema);实例(Instance);“型” 和“值” 的概念;型(Type);值(Value);数据库系统的三级模式结构;模式/逻辑模式;外模式;内模式;两级映射与数据独立性;外模式/模式映像;内...
  • 1 数据库概念模式设计 写出由基本项构思ERD的四条原则及根据这些原则相应得出的实体、联系及其属性,并确定主实体的主标识,画出ERD;用原则4检查改正错误;对其中复杂的多元联系进行分析,必要则改进。 2 数据库...
  • 数据库——数据库结构设计

    千次阅读 2020-03-08 22:21:25
    1 数据库概念设计 2 数据库逻辑设计 3 数据库物理设计 数据库概念设计 概念设计数据库设计的 核心环节,通过对用户需求进行综合;归纳;与抽象,形成一个独立于DBMS 的概念模型 数据库概念设计的目标 1 定义与...
  • 数据库课程设计 ——酒店管理系统

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

    千次阅读 2020-06-13 00:26:18
    数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构, 并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。...
  • 此文以存储树形结构数据为需求,分别描述了利用关系型数据库和文档型数据库作为存储的几种设计模式。 A.关系型数据库设计模式1 id name parent_id 1 A NULL 2 B
  • 1、外模式 外模式又称子模式,对应于用户级。它是某个或某几个用户所看到的数据库的数据视图,是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集,包含模式中允许特定用户使用的那部分数据。用户可以...
  • 数据库设计方法 数据库系统的设计过程...满足各种用户的应 用需求包括 数据库的结构设计:静态的数据模型设计(模式和 子模式设计) 数据设计:应用程序设计(在模型上的动态操作) 一般地:数据库设计是以一个现成的DBMS为 基
  • 连载之8原创:胖子刘(转载请注明作者和出处,谢谢)(二)自联结模式自联结模式,也可以看作是“主从模式”的一种特殊情况(或者说是“变形”),它在一张表内实现了“一对多关系”,并且可以根据业务需要实现...
  • 数据库模式理解

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

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

    万次阅读 多人点赞 2017-05-03 02:43:48
    本文主要介绍评论功能的数据库设计。评论功能最主要的是发表评论和回复评论(删除功能在后台)。评论功能的拓展功能体现有以下几方面: (1)单篇文章的评论数量和信息展示; (2)从时间维度,按照时间倒
  • 数据库 模式 视图 索引

    千次阅读 2018-10-02 16:24:46
     从数据库管理系统角度看,数据库系统通常采用三级模式结构:外模式模式、内模式,这是数据库管理系统内部的系统结构。在数据模型中有“型”(Type)和“值”(Value)的概念。型是指对某一类数据的结构和属性的...
  • 方法一:从职位(角色)的角度出发,指定职位拥有那些操作权限。给定用户一个职位,当用户登录的时候通过Session存储该职位所具有的操作权限。当用户执行操作时,逻辑层通过遍历判断用户是否具有这个操作的权限,若...
  • 数据库系统原理 - - (3)数据库设计

    万次阅读 2020-07-03 08:55:25
    数据库设计概念1)数据库的生命周期2)数据库设计的目标3)数据库设计的内容4)数据库设计的方法a. 直观设计法b.规范设计法c.计算机辅助设计法5)数据库设计的过程2.数据库设计的基本步骤1)需求分析需求分析的四个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 220,989
精华内容 88,395
关键字:

数据库子模式设计