精华内容
下载资源
问答
  • 数据库——关系模型设计

    千次阅读 2019-10-04 21:48:33
    目前公司内部主流数据库是关系型数据库MySQL,数据库设计是对数据进行组织化和结构化的过程,即关系模型的设计。 对于项目规模小、用户数量少的情况,处理数据库中的表结构相对轻松;目前公司的发展速度快、用户数量...

    数据库关系模型设计

    背景

    目前公司内部主流数据库是关系型数据库MySQL,数据库设计是对数据进行组织化和结构化的过程,即关系模型的设计。
    对于项目规模小、用户数量少的情况,处理数据库中的表结构相对轻松;目前公司的发展速度快、用户数量多、项目规模大、业务逻辑极其复杂;
    相应的数据库架构、关系模型表结构越来越复杂,这时我们往往会发现我们写出来的SQL语句是很笨拙并且效率低下的。更可怕的是,由于表结构定义不合理,会导致对数据的增删改查不方便不高效;最致命的是,扩展性极差,不能应对业务的变化。

    此时对我们开发人员关系模式设计能力要求提高了,我们要学习和掌握数据库的规范化流程,以指导我们更好的设计数据库的表结构,减少冗余的数据,借此可以提高数据库的存储效率,数据完整性和可扩展性。

    简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计,在以后的数据维护中,不会发生插入(insert)、删除(delete)和更新(update)时的异常。反之,数据库表结构设计不合理,不仅会给数据库的使用和维护带来各种各样的问题,而且可能存储了大量不需要的冗余信息,浪费系统资源。

    关于数据库关系模型设计的问题,就是在实际项目中,我们应该构造几个关系模型,每个关系(表)由哪些属性(列)组成,不同关系之间有什么关联。

    规范化

    一个低级范式的关系模型通过模式分解可以转为若干个高一级别范式的关系模型的集合,这个过程就叫规范化。

    为了说明方便,我们用一个订单场景,来一步一步分析规范化的过程

    如下只是为了演示,关系模型规范化的过程,存在不规范的地方

    create table order_info (
        order_no varchar(10) not null comment '订单编号',
        account_name varchar(10) not null comment '会员姓名',
        account_address varchar(10) not null comment '会员地址',
        product_name varchar(10) not null comment '商品',
        product_address varchar(10) not null comment '产地',
        product_num int unsigned not null default 0 comment '数量',
        product_price double not null comment '单价',
        sum_price double not null comment '总价',
        primary key(order_no,account_name,product_name)
    ) engine=innodb default character set=utf8;
    
    order_noaccount_nameaccount_addressproduct_nameproduct_addressproduct_numproduct_pricesum_price
    201907080001小明北京bose降噪耳机美国120002000
    201907080001小明北京华为p20中国110001000
    201907080002小刚上海bose降噪耳机美国120002000
    201907080003小明北京iphone X美国120002000
    201907080004小丽唐山华为p20中国110001000

    这张表一共有8个字段,分析每个字段都有重复的值出现,也就是说,存在数据冗余问题。这将潜在地造成数据操作(比如删除、更新等操作)时的异常情况,因此,需要进行规范化。

    第一范式

    参照范式的定义,我们发现,这张表已经满足了第一范式的要求。

    事实上在当前所有的关系数据库管理系统(DBMS)中,都已经在建表的时候强制满足第一范式,即关系型数据库原生满足第一范式,1NF是所有关系型数据库的最基本要求。
    从业务的角度分析可能认为这张表不满足第一方式,因为地址可以再细化。

    缺点

    1. 数据冗余:每一个字段都有值重复
    2. 更新复杂:更新用户或商品的地址时需要更新多条记录,即数据的一致性增加了成本

    第二范式

    参照范式的定义,我们发现,这张表不满足第二范式的要求。

    • 存在依赖部分主键
      • (order_no,account_name,product_name) -> account_address
        • (account_name) -> account_address
      • (order_no,account_name,product_name) -> product_price
        • (product_name) -> product_price

    我们按照范式对该关系模式进行分解转化:

    account_info(用户表)

    create table account_info(
        id int unsigned auto_increment comment '主键',
        account_name varchar(10) comment '用户姓名',
        account_address varchar(10) comment '地址',
        primary key(id)
    )engine=innodb default charset=utf8
    idaccount_nameaccount_address
    1小明北京
    2小刚上海
    3小丽唐山

    product_info(商品表)

    create table product_info(
        id int unsigned auto_increment comment '主键',
        product_name varchar(10) comment '商品名称',
        product_address varchar(10) comment '产址',
        product_price double comment '单价',
        primary key(id)
    )engine=innodb default charset=utf8
    idproduct_nameproduct_addressproduct_price
    1bose降噪耳机美国2000
    2华为p20中国1000
    3iphone X美国2000

    order_info(订单表)

    create table order_info(
        id int unsigned auto_increment comment '主键',
        order_no varchar(10) comment '订单号',
        account_id int comment '用户id',
        primary key(id)
    )engine=innodb default charset=utf8
    idorder_noaccount_id
    12019070800011
    22019070800022
    32019070800033
    42019070800041

    order_detial_info(订单商品表)

    create table order_detial_info(
        id int unsigned auto_increment comment '主键',
        order_id int comment '订单id',
        product_id int comment '商品id',
        product_num int comment '商品数量',
        sum_price double comment '商品合计',
        primary key(id)
    )engine=innodb default charset=utf8
    idorder_idproduct_idproduct_numsum_price
    11112000
    21211000
    32112000
    43112000
    54311000

    从第一范式到第二范式,一个订单关系表衍生了多个关系表。

    第三范式

    参照范式的定义,我们发现,存在传递依赖
    order_detial_info

    • id -> product_id
    • id -> product_num
    • id -> sum_price
    • (product_id,product_num) -> sum_price

    order_info(订单表)

    create table order_info(
        id int unsigned auto_increment comment '主键',
        order_no varchar(10) comment '订单号',
        account_id int comment '用户id',
        sum_price double comment '商品合计',
        primary key(id)
    )engine=innodb default charset=utf8
    idorder_noaccount_idsum_price
    120190708000113000
    220190708000222000
    320190708000332000
    420190708000411000

    order_detial_info(订单商品表)

    create table order_detial_info(
        id int unsigned auto_increment comment '主键',
        order_id int comment '订单id',
        product_id int comment '商品id',
        product_num int comment '商品数量',
        primary key(id)
    )engine=innodb default charset=utf8
    idorder_idproduct_idproduct_num
    1111
    2121
    3211
    4311
    5431

    我们通过进一步转换,消除传递依赖,使之满足第三范式。

    总结

    在本文描述的过程中,我们通过结合实例的方法,通俗地演绎了数据表规范化的过程,并展示了在此过程中数据冗余、数据库操作异常等问题是如何得到解决的,但对于订单信息的汇总,报表的形成增加了难度。

    规范化的过程就是,一步步提升关系范式级别的过程;三大范式只是一般设计数据库的基本理念,可是实际工作中我们根据业务场景(OLAP/OLTP)出于性能或扩展的考虑,出发点不一样,在空间和时间上做的取舍不一样,关系模型设计只满足2NF或1NF,也就是反范式;但作为开发人员一定要了解关系模式设计规范化的过程。

    范式

    • 第一范式:当关系模式R的所有属性都不能在分解为更基本的数据单位时,称R是满足第一范式的,简记为1NF(列不可再分,无重复的列);
    • 第二范式:如果关系模式R满足第一范式,并且R得所有非主属性都完全依赖于R的每一个候选关键属性,称R满足- 第二范式,简记为2NF(属性依赖完全主键(主键/所有复合主键),不能依赖主键的一部分,消除部分依赖);
    • 第三范式:设R是一个满足第一范式条件的关系模式,X是R的任意属性集,如果X非传递依赖于R的任意一个候选关键字,称R满足第三范式,简记为3NF(属性不依赖于其他非主属性,消除传递依赖);
    • 数据库范式除了上述三个范式还有BCNF、4NF等,这里不再一一讲解

    知识拓展

    第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。

    候选码:若关系(表)中某一属性(列)组的值能唯一标识一个元组(行),而其子集不能,则称该属性组为候选码(一个关系中可能存在多个候选码,则选定其中一个作为主码(主键 primary key))。

    候选码的各个属性成为主属性。不包含在任何候选码中的属性成为非主属性非码属性

    最简单的情况下,候选码只包含一个属性;在最极端情况下,关系模式中的所有属性是这个关系模型的属性码,成为全码

    转载于:https://www.cnblogs.com/sunjingwu/p/11213545.html

    展开全文
  • 关系数据库模型设计

    千次阅读 2020-05-19 17:13:17
    本文从现实世界-概念世界(信息世界)-机器世界(数据世界)逐级抽象,旨在以浅显易懂的语言描述关系数据库应该如何建模,最后用简单名了的描述给出关系模型设计范式的含义。

    目录

     

    三个世界的划分

    1.现实世界

    2.概念世界(信息世界)

    3.机器世界(数据世界)

    模型

    一、概念模型(信息世界)

    (一)E-R图的三要素

    (二)E-R图的设计方法

    (三)E-R模型到关系模型的转换

    (四)小结

    二、数据模型(数据世界)

    (一)层次模型

    (二)网状模型

    (三)关系模型


    三个世界的划分

    人们把客观存在的事物以数据的形式存储到计算机中,经历了对现实生活中事物特性的认识、概念化到计算机数据库里的具体表示的逐级抽象过程,即现实世界-概念世界-机器世界三个领域。有时也将概念世界称为信息世界;将机器世界称为存储或数据世界。

     

    1.现实世界

    人们管理的对象存于现实世界中。现实世界的事物及事物之间存在着联系,这种联系是客观存在的,是由事物本身的性质决定的。例如学校的教学系统中有教师、学生、课程,教师为学生授课,学生选修课程并取得成绩。

     

    2.概念世界(信息世界)

    概念世界是现实世界在人们头脑中的反映,是对客观事物及其联系的一种抽象描述,从而产生概念模型。概念模型是现实世界到机器世界必然经过的中间层次。涉及到下面几个术语:
    实体:我们把客观存在并且可以相互区别的事物称为实体。实体可以是实际事物,也可以是抽象事件。如一个职工、一场比赛等。
    实体集:同一类实体的集合称为实体集。如全体职工。注意区分"型"与"值"的概念。如每个职工是职工实体"型"的一个具体"值。
    属性:描述实体的特性称为属性。如职工的职工号,姓名,性别,出生日期,职称等。
    联系:实体集之间的对应关系称为联系,它反映现实世界事物之间的相互关联。联系分为两种,一种是实体内部各属性之间的联系。另一种是实体之间的联系。

     

    3.机器世界(数据世界)

    存入计算机系统里的数据是将概念世界中的事物数据化的结果。为了准确地反映事物本身及事物之间的各种联系,数据库中的数据必须有一定的结构,这种结构用数据模型来表示。数据模型将概念世界中的实体,及实体间的联系进一步抽象成便于计算机处理的方式。三个世界中的术语对照关系如下:

     

    模型

    模型就是对不能直接观察的事物进行形象的描述和模拟。即模型是对现实世界中复杂事物的抽象描述。

    模型分为信息世界的概念模型和数据世界的数据模型:

    概念模型:把现实世界转换为信息世界的模型,例如E-R模型。

    数据模型:把信息世界转化为数据世界的模型,例如关系模型。

     

    一、概念模型(信息世界)

    实体联系模型,亦称实体关系模型,它是由美籍华裔计算机科学家陈品山(Peter Chen)发明,该模型直接从现实世界中抽象出实体类型和实体间联系,然后用实体联系图(E-R图)表示数据模型,是描述概念世界,建立概念模型的实用工具。所以,在信息世界中使用E-R图建立的数据模型称为E-R模型。

    实体关系模型是现实世界到概念世界的第一层抽象,是数据库设计人员进行数据库设计的有利的数据建模工具,也是数据库设计人员和用户之间进行交流的语言。

     

    (一)E-R图的三要素

    实体(Entity):在E-R图中用矩形表示,矩形框内标注实体名称。实体表示一个离散对象。实体可以被(粗略地)认为是名词,如计算机、雇员、歌曲、数学定理等。


    属性(Attribute):在E-R图中用椭圆形表示,并用无向连线将其与相应的实体连接起来,同时在无向连线旁标上联系的类型(1 : 1,1 : n或m : n)。属性描述实体的特性(特征性质),例如学生的姓名、学号、性别、都是属性。

     

    联系(Relationship):在E-R图中用菱形框表示,框内标注联系名称,并用连线将菱形框分别与有关实体相连,并在连线上注明联系类型。联系可以被(粗略地)认为是动词,如:在公司和计算机之间的拥有关联,在雇员和部门之间的管理关联,在演员和歌曲之间的表演关联,在数学家和定理之间的证明关联等等。联系有三种类型:


    ① 一对一联系(1:1)
    设A、B为两个实体集。若A中的每个实体至多和B中的一个实体有联系,反过来,B中的每个实体至多和A中的一个实体有联系,称A对B或B对A是1:1联系。注意,1:1联系不一定都是一一对应的关系。可能存在着无对应。例如,一个部门有一个经理,而每个经理只在一个部门任职,则部门与经理的联系是一对一的,但经理也可能暂缺。


    ② 一对多联系(1:n)
    如果A实体集中的每个实体可以和B中的几个实体有联系,而B中的每个实体至少和A中的一个实体有联系,那么A对B属于1:n联系。例如,一个部门有多名职工,而一名职工只在一个部门就职,则部门与职工的联系是一对多的。


    ③ 多对多联系(m:n)
    若实体集A中的每个实体可与和B中的多个实体有联系,反过来,B中的每个实体也可以与A中的多个实体有联系,称A对B或B对A是m:n联系。例如,一个学生可以选修多门课程,一门课程由多个学生选修,学生和课程间的联系是多对多的。
     

    (二)E-R图的设计方法

    E-R图通常都应经过以下两个阶段:

    (1)针对每一用户画出该用户信息的局部E-R图,确定该用户视图的实体、属性和联系。需注意的是:能作为属性的就不要作为实体,这有利于E-R图的简化。

     

    (2)综合局部E-R图,生成总体E-R图。在综合过程中,同名实体只能出现一次,还要去掉不必要的联系,以便消除冗余。一般来说,从总体E-R图必须能导出原来的所有局部视图,包括实体、属性和联系。

     

    案例:工厂(包括厂名和厂长名)需要建立一个数据库系统,有以下情况:

     

    1、该工厂生产若干产品,每种产品由不同的零件组成

    2、有的零件可以用在不同的产品,这些零件由不同的原材料组成,不同的零件所用的原材料可以相同。

    3、零件按照所属的不同产品分别放在仓库中,原材料按照类别分别放在若干仓库中。

     

    相关性质如下:

    工厂:长号,长名,长址,厂长名

    车间:车间号,车间名,电话

    产品:产品名,品种号,性能

    零件:零件号,零件名,生产日期

    原材料:材料号,产地,等级

    仓库:库号,电话

     

    (三)E-R模型到关系模型的转换

    把E-R图转换为关系模型可遵循如下原则:

    (1)对于E—R图中每个实体集,都应转换为一个关系,该关系应包括对应实体的全部属性,并应根据关系所表达的语义确定哪个属性或哪几个属性组作为“主关键字”,主关键字用来标识实体。

     

    (2)对于E—R图中的联系,情况比较复杂,要根据实体联系方式的不同,采取不同的手段加以实现。下面着重讨论联系的转换方法。

    A、两实体集间1:n联系

    两实体集间1:n联系,可将“一方”实体的主关键字纳入“n方”实体集对应的关系中作为“外部关键字”,同时把联系的属性也一并纳入“n方”对应的关系中。

     

    B、两实体集间m:n联系

    对于两实体集间m:n联系,必须对“联系”单独建立一个关系,用来联系双方实体集。该关系的属性中至少要包括被它所联系的双方实体集的“主关键字”,并且如果联系有属性,也要归入这个关系中。

     

    C、两实体集间的1:1的联系

    假设A实体集与B实体集是1:1的联系,联系的转换有三种方法:

    ①把A实体集的主关键字加入到B实体集对应的关系中,如果联系有属性也一并加入;

    ②把B实体集的主关键字加入到A实体集对应的关系中,如果联系有属性也一并加入;

    ③建立第三个关系,关系中包含两个实体集的主关键字,如果联系有属性也一并加入。

     

    (四)小结

    (1)把现实世界转换成为计算机能够处理的数据世界,需经过两个阶段:

             第一个阶段需使用概念模型把现实世界抽象成信息世界,最常用的概念模型是E-R模型,E-R模型的三个基本要素是实体、

             属性和联系。

             第二阶段是使用数据模型把信息世界转换为数据世界,最常用的数据模型是关系模型。

     

    (2)设计E-R图一般经过两个步骤,

            第一步是抽象出各相关对象的局部E-R图,

            第二步是把局部E-R图组合成全局E-R图。E-R图只是信息的一种抽象表示,还需把它转化成相应的实施数据模型才能转化为

            数据库中的数据。把E-R图转化为关系模型,不但要把实体转化成关系,而且在关系中还应反映出E-R图中各实体集之间的

            联系。

     

    3E-R数据模型作为语义数据模型,是软件工程和数据库设计的有力工具,综合E-R数据模型的特点如下:
          (1) 有丰富的语义表达能力,能充分反映现实世界,包括实体和实体间的联系,能满足用户对数据对象的处理要求。
          (2) 易于交流和理解,因为它不依赖于计算机系统和具体的DBMS,所以,它是DBA、系统开发人员和用户之间的桥梁。
          (3) 易于修改和扩充。
          (4) 易于向其他各种数据模型(层次,网状,关系模型)转换。
          (5) 实体、属性和联系这三个概念是有明确区分的,但对于某个具体的数据对象,究竟是作为实体,还是作为属性或联系,

                  则是相对的。这取决于应用背景和用户的观点。

     

    二、数据模型(数据世界)

    在用计算机处理信息世界的信息时,必须抽取局部范围的主要特征,模拟和抽象出一个能反映信息世界中实体和实体之间联系的模型,即数据模型。也就是说,数据模型是抽象描述信息世界的一种工具和方法,是概念模型在数据世界中的表示形式。

    数据模型的三要素:模型结构、数据操作、完整性规则。

    数据模型模型结构分为:层次模型、网状模型、关系模型、面向对象模型。

     

    (一)层次模型

    在现实世界中,许多实体集之间的联系就是一个自然的层次关系。例如,行政机构、家族关系等都是层次关系。下图就是学校中系的层次模型。

    层次模型是最早用于商品数据库管理系统的数据模型。其典型代表是于1969问世、由IBM公司开发的数据库管理系统

    IMS(Information Management System)。

    (1) 层次模型的定义:用树形结构表示实体之间联系的模型叫层次模型。

    (2)层次模型的表示方法:树的结点表示记录(实体),每个记录可包含若干个字段(实体的属性),结点之间的连线表示相连两记录(实体)之间的关系,这种关系只能是“1-M”的。通常把表示1的实体集放在上方,称为父结点,表示M的实体集放在下方,称为子结点。

    (3)层次模型的特点:①有且仅有一个根结点。②根结点以外的其它结点有且仅有一个父结点。

    在层次模型中,记录的组织不再是一张杂乱无章的图,而是一棵树。例如,系记录型有:计算机系、电信系等记录值。而计算机系的下层记录值有软件、结构、应用等研究室和数据结构、操作系统、数据库等课程,软件研究室下层又有员工和项目记录值,如下图所示:

    根据层次模型的特点可知,层次模型只能表示“1-M”关系,而不能直接表示“M-M”关系。因此对于层次模型中实体集之间多对多的联系的处理,解决的方法是引入冗余结点。例如,学生和课程之间的多对多的联系,引入学生和课程的冗余结点,即转换为两棵树:一棵树的根是学生,子结点是课程,它表现了一个学生可以选多门课程;一棵树的根是课程,子结点是学生,它反映了一门课程可以被多个学生选。至于冗余结点可以用虚拟结点实现:在冗余结点处仅存放一个指针,指向实际结点。

     

    (4)层次模型的优点

    ① 层次数据库模型比较简单。

    ② 层次模型对具有一对多的层次关系(例如部门和职员的关系)的描述非常自然、直观,容易理解。

    ③ 层次数据库模型提供了良好的完整性支持。

     

    (5)层次模型的缺点

    ① 在现实世界中有很多的非层次性的联系,如多对多的联系,一个结点具有多个父结点等,层次模型表示这类联系的方法

    很笨拙。

    ② 难以实现系统扩充,对于插入和删除操作时,限制比较多,涉及到大量链接指针的调整。

    ③ 查询子结点必须经过父结点。

    ④ 由于结构严密,层次命令趋于程序化。

     

    (二)网状模型

    在现实世界中,事物之间的联系更多的是非层次关系的,用层次模型表示非树型结构是很不直接的,网状模型则可以克服这一弊病。层次模型中的记录只能组织成树的集合而不能是任意图的集合,而网状模型则可以。

    (1) 网状模型的定义:用网状结构表示实体之间联系的模型叫网状模型。

    (2) 网状模型的表示方法:网的结点表示记录(实体),每个记录可包含若干个字段(实体的属性),结点之间的连线表示相连两记录(实体)之间的关系,这种关系可以是“1-M”的,也可以是“M-M”的。

    (3) 网状模型的特点:①允许一个以上的结点无父亲结点。②一个结点可以有多于一个的父亲结点。

    网状模型是一种比层次模型更具普遍性的结构,它去掉了层次模型的两个限制,允许多个结点没有父亲结点,允许结点有多个父亲结点,此外它还允许两个结点之间有多种联系。因此网状模型可以更直接地去描述现实世界,而层次模型实际上是网状模型的一个特例。网状模型示例如下:

     

    (4) 网状数据模型的优点

    ①能够更为直接地描述现实世界,如一个结点可以有多个父亲节点。

    ②具有良好的性能,存取效率较高。

     

    (5) 网状数据模型的缺点

    ①结构比较复杂,而且随着应用环境的扩大,数据库的结构就变得越来越复杂,不利于最终用户掌握。

    ②难以实现系统扩充,对于插入和删除操作时,限制比较多,涉及到大量链接指针的调整。

    ③其DDL,DML语言复杂,用户不容易使用。由于记录之间联系是通过存取路径实现的,应用程序在访问数据时必须选择

    适当的存取路径,因此,用户必须了解系统结构的细节,加重了编写应用程序的负担。

     

    (三)关系模型

     

    (1) 关系模型的定义:用二维表格数据来表示实体及实体之间联系的模型叫关系模型。

    (2) 关系模型的特点:

    ① 每个表有多个列,每一列中的字段(属性)唯一且是类型相同的数据;

    ② 列的顺序可以是任意的;

    ③ 行的顺序可以是任意的;

    ④ 表中的字段(属性)是不可再分割的最小数据项,即表中不允许有子表;

    ⑤ 表中的任意两行不能完全相同。

    在关系模型中,无论是从客观事物中抽象出的实体,还是实体之间的联系,都用单一的结构类型—关系(表)来表示。在对关系进行各种处理之后,得到的还是关系—一张新的二维表。如图所示:

    关系数据库采用关系模型作为数据的组织方式。关系数据库因其严格的数学理论、使用简单灵活、数据独立性强等特点,而被公认为最有前途的一种数据库管理系统。它的发展十分迅速,目前已成为占据主导地位的数据库管理系统。自20世纪80

    年代以来,作为商品推出的数据库管理系统几乎都是关系型的,例如,Oracle,Sybase,Informix,Visual FoxPro,Mysql,Sqlserver等。

     

    (3) 关系模型的设计范式

    只有满足一定条件的关系模式,才能避免操作(例如插入、删除、修改)异常和数据异常(例如数据冗余),关系模式要满足的条件称为规范化形式,简称范式。 

     

    ① 第一范式(1NF)

    第一范式是对表属性的原子性约束,要求属性具有原子性,不可再分解成其它属性;其目的是消除重复字段(列)。

     

    ②  第二范式(2NF)

    第二范式是对表记录的惟一性约束,要求记录有惟一标识,能唯一地区分其它记录;其目的是消除重复记录(行)。

     

    ③ 第三范式(3NF)

    第三范式是对表字段冗余性的约束,要求字段没有冗余,任何字段都不能由其他字段派生出来;其目的是消除字段冗余。

     

    ④  第四范式(4NF)

    第四范式是对表记录冗余性的约束,要求记录没有冗余,同一表不存在一对多或多对多关系;其目的是消除记录冗余。

     

    ⑤  第五范式(5NF)

    第五范式是将表分割成尽可能小的块,目的是消除表中所有的冗余。

     

    在设计关系数据库表的时候,你应该总是要遵循这五大范式。

     

     

    展开全文
  • 数据库关系模型基本介绍

    万次阅读 2018-04-24 18:13:57
    关系模型研究什么?关系模型就是处理Table的,它由三个部分组成:1:描述DB各种数据的基本结构形式2:描述Table与Table之间所可能发生的各种操作(关系运算)3:描述这些操作所应遵循的约束条件(完整性约束)就是要...
    关系模型研究什么?

    关系模型就是处理Table的,它由三个部分组成:

    1:描述DB各种数据的基本结构形式

    2:描述Table与Table之间所可能发生的各种操作(关系运算)

    3:描述这些操作所应遵循的约束条件(完整性约束)

    就是要学习:Table如何描述,有哪些操作,结果是什么,有哪些约束等.

    关系模型的三个要素

    1 基本结构:Relation/Table

    2 基本操作:Relation Operator(各种运算操作)

    3 完整性约束:实现完整性,参照完整性和用户自定义完整性

    候选码/候选键

    关系中的一个属性组,其值能唯一标识一个元组,若从该属性组中去掉任何一个属性吗,它就不具有这一性质了,这样的属性组称为候选码

    例如:"学生(S#,Sname,Sage,Sclass)",S#就是一个候选码,在此关系中,任何两个元组的S#是一定不同的,而这两个元组的Sname,Sage,Sclass都可能相同,所有S#是候选码。

    有时,关系中有很多组候选码,例如:

        学生(S#,Sname,Sage,Sclass,Saddress)

    其中属性S#是候选码,属性组(Sname,Saddress)也是候选码(同名同地址的两个同学是不存在的)

    主码/主键

    当有多个候选码是,可以选定一个作为主码

    当DBMS以主码为主要线索管理关系中的各个元组

    主属性与非主属性

    包含在任何一个候选码中的属性被称作主属性,二其他属性被称作非主属性

    最简单的,候选码只包含一个属性

    最极端的,所有属性构成这个关系的候选码,称为全码

         例如:关系“教师授课”(T#,C#)中的候选码(T#,C#)就是全码

    外码/外键

    关系R中的一个属性组,它不是R的候选码,但它与另一个关系S的候选码相对应,则称这个属性组为R的外码或外键。

    例如:“合同”关系中的客户号不是候选码,但确实外码。因它与“客户”关系中的候选码“客户号”相对应。

    两个关系通常是靠外码连接起来的。

    关系模型中的完整性
    实体完整性

    关系的主码中的属性值不能为空值;

    意义:关系中的元组对应到现实世界相互之间可区分的一个个个体,这些个体是通过主码来唯一标识的;若主码为空。则出现不可标识的个体,这是不容许的

    空值的含义

    空值:不知道、不存在或无意义的值;

    在进行关系操作是,有时关系中的某属性值是当前填不上的,比如档案中有“生日不详”、“下落不明”、“日程尚待公布”等,需要空值来代替,关系模型中用"?"来表征。

    数据库中有了空值,会影响许多方面,如影响聚集函数运算的正确性,不能参与算数、比较或逻辑运算等。

    有空值的时候是需要特殊处理的,要特别注意。

    参照完整性

    如果关系R1的外码Fk与关系R2的主码Pk相对应,则R1中的每一个元组的Fk值或者等于R2中的某个元组的Pk值,或者为空值、

    意义:如果关系R1的年某个元组t1参照了关系R2的某个元组t2,则t2必须存在。

    用户自定义完整性

    用户针对具体应用环境定义的完整性约束条件

    如S#要求是10为整数,其中前四位为年度,当前年度与他们的差必须在4以内。

    DBMS对关系完整性的支持

    实体完整性和参照完整性有由DBMS系统自动支持

    DBMS系统通常提供如下机制:

    1 它使用户可以自定义有关完整性约束条件

    2 当有更新操作发生是,DBMS将自动按照完整性约束条件检验更新操作的正确,即是否符合用户自定义的完整性

    展开全文
  • 掌握概念模型(ER模型和UML模型)到关系模型的转化。 对于ER模型和UML模型不是很熟悉的小伙伴和烦恼于如何设计项目的数据库的小伙伴可以看看本文。 数据库设计(DBD):构造最优的数据模型,建立数据库及其应用系统...

    本文根据b站鲁老师的教学视频整理而来,可能会偏理论化,有点枯燥,但是如果认真看完,还是会有所收获哒。
    从本文可以学习到:
    对于一个即将展开的项目,我们应该怎么设计及实现数据库。
    掌握概念模型(ER模型和UML模型)到关系模型的转化。

    对于ER模型和UML模型不是很熟悉的小伙伴和烦恼于如何设计项目的数据库的小伙伴可以看看本文。

    想画出ER模型和UML模型的朋友们可以看看这篇博客(PowerDesigner(CDM)画ER图并导出且在DBMS中运行),里面用到的PowerDesigner还可以直接帮你实现概念模型(ER图)到关系模型(代码)的转化十分方便。两篇博客结合起来,相信你能对数据库的模型设计更加得心应手。

    数据库设计(DBD):构造最优的数据模型,建立数据库及其应用系统的过程。

    一、数据库设计步骤

    1.数据分析
    2.数据建模
    3.关系数据库模型
    4.关系数据库管理
    在这里插入图片描述
    注释:概念模型(ER Model/UML Model)
    上面这个图是我们设计数据库及实现的流程图,大家最好熟悉一下。

    下面这个7个步骤了解就好,编写项目的小伙伴可以试着遵循下面步骤来完成项目的有关数据库设计。

    1.1 规划阶段

    (1)系统调查
    (2)可行性分析
    (3)确定数据库系统的总目标

    1.2 需求分析阶段

    (1)分析用户活动,产生业务流程图
    (2)确定系统范围,产生系统关联图
    (3)分析用户活动范围涉及的数据,产生数据流图
    (4)分析系统数据,参数数据字典

    1.3 概念设计阶段

    目标:产生反映用户需求的数据库概念结构,即概念模型
    (1)进行数据抽象,设计局部概念模型
    (2)将局部概念模型综合成全局概念模型(消除冲突)
    (3)评审(用户评审and 应用开发人员评审)
    方法:实体联系法(ER模型)(与DBMS无关的概念模型)

    1.4 逻辑设计阶段

    目的:将设计好的概念模型转换成与DBMS所支持的数据模型相符合的逻辑结构(包括数据库逻辑模型和外模型)
    步骤:
    (1)把概念模型转化为逻辑模型
    (2)设计外模型
    (3)设计应用程序与数据库的接口
    (4)评价模型
    (5)修正模型

    1.5 物理设计阶段

    物理设计:对于给定的基本数据模型选取一个最合适应用环境的物理结构的过程。
    步骤:
    (1)存储记录结构设计
    (2)确定数据存放的位置
    (3)存取方法的设计
    (以上三个为物理结构设计)
    (4)完整性和安全性考虑
    (5)程序设计

    1.6 数据库的实现

    (1)用DDL定义数据库结构
    (2)组织数据入库
    (3)编制与调试应用程序
    (4)数据库试运行

    1.7 数据库的运行与维护

    由DBA完成
    数据库的转储和恢复
    数据库的安全性、完整性控制
    数据库性能的监督、分析和改进
    数据库的重组织和重构造

    二、ER模型

    2.1 re图的基本元素(略)(这个大家从课本或者很多博客都可以迅速掌握,这里就不在多说明。)
    2.2 联系的设计

    一个联系涉及到的实体集个体,称为该联系的元数度数
    一元联系(递归联系),二元联系,三元联系。
    联系类型:限制参与联系的实体的数目(如二元联系的一对多,一对一等)
    例:
    一元联系的1对1:运动员的顺序联系(每个运动员都有1对1的顺序)
    一元联系的1对n:职工的领导联系(每个领导都有1对n的职工)
    一元联系的m对n:零件的组成联系(多个零件可以组合)

    2.3 采用ER模型的概念设计

    (1)首先设计局部ER模型
    (2)然后把各局部ER模型综合成一个全局ER模型
    (3)最后对全局ER模型进行优化,得到最终的ER模型,即概念模型
    两个准则:
    属性不能再具有需要描述的性质
    属性不能与其他实体具有联系
    主体都要有一个标识符。(独特的)

    设计全局ER模型
    优化原则:
    (1)合并实体类型
    (2)消除冗余属性
    (3)消除冗余联系

    三、ER模型向关系模型的转化

    3.1 ER图转化为关系模式集的算法

    (1)实体类型的转换:将每个实体类型转换成一个关系模式,实体的属性即为关系模式的属性,实体标识符即为关系模式的键。
    (2)转换联系
    不同的情况做不同的处理

    3.2.二元的转换关系:重重点

    (1)若实体间的联系是1:1,可以再两个实体类型转换成的两个关系模式中任意的一个关系模式的属性加入另一个关系模式的键和联系类型的属性。
    (2)若实体间的联系是1:n,则在n端的实体类型转换成的关系模式中加入1端实体类型的键和联系类型的属性。
    (3)若实体间的联系是m:n,则将联系类型也转换成关系模式,其属性为两端实体类型的键加上联系类型的属性,而键为两端实体键的组合。

    实例:(例子更好的加快我们了解概念模型向关系模型转换的公式)

    如三个关系模式
    系(系编号,系名,电话)
    教师(教工号,姓名,性别,学分)
    课程(课程号,课程名,学分)

    联系1: 教师(主管)系(1:1)
    这时候联系转换可以把任意一个的主键作为其中一个的外键,加入关系模式中。
    但是这里我们,系是比教师少的,所以如果我们在教工号里加入一个‘系主任教工号’的话,不是每一个教师都是系主任,所以这里我们要加在系里,因为每一个系都有一个系主任。
    (下面所有的关系模式中,加深代表主键,变红代表外键,加深且变红代表既是主键又是外键。)
    系(系编号,系名,电话,系主任教工号)
    教师(教工号,姓名,性别,学分)
    课程(课程号,课程名,学分)

    联系2: 系(聘用 属性:聘期)教师(1:n)
    1对多关系,所以把一方的主键加到多方去
    系(系编号,系名,电话,系主任教工号)
    教师(教工号,姓名,性别,学分,所在系编号,聘期)
    课程(课程号,课程名,学分)

    联系3: 系(开设)课程(1:n)
    系(系编号,系名,电话,系主任教工号)
    教师(教工号,姓名,性别,学分,所在系编号,聘期)
    课程(课程号,课程名,学分,所在系编号

    联系4: 教师(任教 属性:教材)课程(m:n)
    多对多就要将这个联系自己转化为一个新的关系模式。联系的名字就是关系模式的名字。属性是:联系双方的主键以及本身的属性。且联系双方的主键作为一个联合主键。同时这两个联合主键又是外键。通过教工号,建立起和教工之间的联系,通过课程号,建立起和课程之间的联系。
    系(系编号,系名,电话,系主任教工号)
    教师(教工号,姓名,性别,学分,所在系编号,聘期)
    课程(课程号,课程名,学分,所在系编号
    任教(教工号,课程号,教材)

    二元关系的转换大家一定要掌握!!!

    3.3.三元的转换关系:

    (1)若实体间联系是 1 : 1 : 1 1:1:1 1:1:1,可以在转换成的三个关系模式中任意一个关系模式的属性中加入另外两个关系模式的键(作为外键)和联系类型的属性。
    (2)若实体间联系是 1 : 1 : n 1:1:n 1:1:n,则在n端实体类型转换成的关系模式中加入两个1端实体类型的键(作为外键)和联系类型的属性。
    (3)若实体间联系是 1 : m : n 1:m:n 1:m:n,则将联系关系也转化成关系模式,其属性为三端实体类型的键加上联系类型的属性,而键位m端和n端实体键的组合。
    (4)若实体间联系是 m : n : p m:n:p m:n:p,则将联系类型也转化为关系模式,其属性为三端实体类型的键加上联系类型的属性。而键位三端实体键的组合。

    总结:(这是我总结出的公式)

    1.如果没有n的情况,就在所有的1中挑选一个最合理的关系模式中加入其他的主键作为外键,同时加入联系类型的属性。
    2.如果有n没m的情况,就在n的关系模式中加入所有1的主键作为外键,同时加上联系类型的属性。
    3.如果有m的情况,就生成一个新的关系模式,模式名为联系名,主键为m和n的主键的联合主键,同时若有1则1的主键作为外键,同时加上联系类型的属性。同时主键作为外键。

    其实看完上面的规则,大家就可以总结出各种各样形式的联系转换了。

    3.4.一元联系转换为关系模式


    运动员(编号,姓名,性别,名次)
    联系:运动员(顺序)运动员(1:1)
    运动员(编号,姓名,性别,名次,上一名次编号)

    职工(工号,姓名,年龄,性别)
    联系:职工(领导)职工(1:n)
    职工(工号,姓名,年龄,性别,经理工号)

    零件(零件号,零件名,规格)
    联系:零件(组成 属性:数量)零件(n:m)
    零件(零件号,零件名,规格)
    组成(零件号,子零件号,数量)

    3.5 采用ER模型的逻辑设计的步骤

    (1)导出初始关系模式集
    (2)规范化处理
    逐一考察关系模式
    判断他们是否满足规范要求
    (3)模式评价
    (4)模式修正
    (5)设计子模式

    四、UML模型(面向对象)

    数据建模:对于一个特定的应用程序,如何在数据库中表示数据

    4.1 设计关系模型方法:

    (1)关系模型设计理论
    (2)概念设计模型
    E/R–传统的
    UML子集–目前常用的

    4.2 UML(Unified Modeling Language)统一建模语言

    UML用于面向对象建模,但现在也用于数据库建模
    UML与ER模型类似,但是不提供多元的联系。

    UMLE/R
    Class(类)Entity(实体集)
    Association(关联)Binary relationship(二元联系)
    Association Class(关联类)Attributes on a relationship(联系的属性)
    Subclass(子类)Isa hierarchy(Isa层次关系)
    Aggregation(聚集)Many-one relationship(多对一联系)
    Composition(组成)Many-one relationship with referential integrity(带参照完整性的多对一联系)
    4.3 UML类

    Class Name类名、Attributes属性、Methods方法(封装)

    Movies
    titile:string PK
    year: int PK
    length:int
    genre:string
    <place for methods>

    类是具有相同属性和方法的对象的集合
    属性是静态的,是状态,具有数据类型
    PK表示主键
    方法是动态的,是行为,包括参数的声明和返回值的声明

    当UML用于数据建模时,删除方法,增加主键,属性类型可选。

    4.4 UML关联

    关联:两个类间对象的联系
    表示方法
    两个类间用直线(箭头可选)连接
    连接名字通常写在直线下方
    在这里插入图片描述

    m…n 表示与C2类中一个对象有关的C1类对象的个数最少为m,最多为n
    *表示无上限
    在这里插入图片描述
    每个学生最多能在5个校园申请课程
    每个校园容纳学生数为10000到20000之间

    关联类型的简写和默认值:
    * 是 0…* 的简写
    1 是 1…1 的简写
    默认值为 1…1

    关联也可以有属性称为关联类
    与E/R图中联系的属性类似
    在这里插入图片描述
    也可以有自身关联。

    4.5 子类(Subclasses):

    在这里插入图片描述

    (1)UML类都可以包含下级子类
    (2)子类用连线连接父类,与父类连接除空心三角指向父类
    (3)主键来自父类
    (4)子类继承父类的属性(包括attributes and associations)
    (5)子类可以有子类自己的属性以及与其他类的关联

    UML 允许4种类型的子类
    (1)Complete(完全)(父类中的每个对象都是某个子类的成员)或者partial(部分)
    (2)Disjoint(分散)(一个对象不能包含在两个子类中)或overlapping(重叠)。

    在Object-Oriented系统中,子类dijoint-即两个子类中不存在同一对象
    E/R模型自动允许overlapping子类
    E/R模型和00系统都运行complete或partial子类

    4.6 聚集(Aggregations)组成(Compositions)

    有两种类型的多对一(n:1)关联(many-one associations)
    (1)聚集(Aggregations)
    聚集用连线连接两个类,一方以空心菱形箭头结束
    空心菱形箭头指向一方参与对象的个数必须为0…1,不需要另外标注
    在这里插入图片描述
    一个电影公司可以生产很多电影。(0…*)
    但是一个电影不一定是电影公司生产。(0…1)

    (2)组成(Compositions)
    菱形箭头一方参与对象必须为1…1
    菱形箭头相反一方类的每个对象必须与菱形箭头方的一个对象关联
    组成以实心菱形表示
    在这里插入图片描述

    4.7 UML 转化为关系

    1.类的转换
    2.关联的转换

    E/R风格:每个子类关系只存储其自身属性和码
    OO风格(面向对象):子类关系存储其自身和其父类的所有属性
    基本规则ER模型一样,这里就不再重复了。

    希望这篇博客能让大家更加了解数据库在整个项目的位置和提高数据库建模的能力。

    展开全文
  • 数据库关系模型ppt

    2013-07-08 21:28:22
    数据库关系模型ppt
  • 数据库关系模型

    千次阅读 2019-04-17 14:46:06
    关系模型的数据结构:以二维表的形式表示实体和实体之间联系的数据模型。其是一张规范化的二维表,它由表名,表头和表体三部分构成。 2.关系模型:分量:每一行对应的列的属性值,即为元组中的一个属性值。 候选码:...
  • 数据库关系模型介绍

    千次阅读 2020-04-01 00:39:24
    本篇文章是数据库系列的第一篇文章,本系列文章是笔者在学习《数据库系统概念》这本书总结的内容,使用的数据库是mysql。 关系数据库的结构 ...在关系模型的术语中,关系(relation)用来指代表,元组...
  • 数据库设计】逻辑设计-ER模型转换为关系模型

    万次阅读 多人点赞 2017-09-26 16:06:05
    如何把ER模型转换为关系模型这是数据库工程设计进行到逻辑设计的一重大环节,简单的说,如果概念设计是用ER模型, 整合为全局的ER模型,那么在逻辑设计这块, 主要任务就是把ER模型转换为关系模型。转换只需知道三个...
  • 数据库-关系模型

    千次阅读 2019-05-04 16:58:43
    最近开始做数据库的大实验,其中有一条实验要求如下: 通过网络查找相关文献并参考所给资料进行需求分析,画出系统的 E-R 图,给出实体或联系的属性,标明联系的种类,并写出关系模式。 画ER图没有什么问题,但是...
  • 关系数据库设计

    2021-01-19 21:53:25
    本文讨论关系数据库设计相关的一些内容,涉及关系模型,表结构设计等内容,以学生选修课程讲述设计过程,在尽量讲清楚设计要领的前提下,简化设计内容。本文基于MySQL数据库为基础,适合有一定关系型数据库基础的人...
  • 数据库设计——概念模型

    千次阅读 2019-10-21 15:56:28
    概念模型是用于信息世界的建模,是现实世界的第一层抽象。 1.基本概念 (1)实体(entity) 客观存在并可相互区别的实物称为实体。实体可以是具体的人、事、物,也可以是抽象的概念或联系,例如:一个职工、一个学生...
  • “成功的路上并不挤,只是你淘汰了你自己”,你好,我是梦阳辰,未来我陪你一起成长。...数据操作:对数据库的查询与更新。 完整性约束:对数据施加规则和限制。 数据模型的类型: 1)概念模型 概念模型是对真实.
  • 关系模型关系是使用最为广泛的逻辑数据模型,如今绝大多数数据库系统都是关系型的,称为 关系数据库。 关系模型涉及关系结构、关系操作和完整性约束三个方面。关系与表关系数据库是使用一系列表来表达数据库以及...
  • 关系数据库模型关系数据库设计.ppt
  • 数据库MySQL关系模型之基本概念

    万次阅读 多人点赞 2019-01-31 16:11:44
    1.什么是关系模型 1.1关系模型研究什么 一个关系(relation)就是一个Table 关系模型就是处理Table的,它由三个部分组成: 描述DB各种数据的基本结构形式(Table/Relation) 描述Table与Table之间所有可能发生的...
  • 网上商城设计(数据库设计_UML建模).
  • 数据库实体联系模型与关系模型

    千次阅读 2020-03-02 19:11:33
    数据库设计是指根据用户的需求,在某一具体的数据库管理系统上,设计数据库的结构和建立数据库的过程。例如,编程微课是在线编程教育项目,该项目涉及到课程、学生、老师、学习资料等数据,这些数据都要被存储下来,...
  • 1.概念模型:也称信息模型,它是按用户的观点来对数据和信息建模,主要用于数据库设计。 2.逻辑模型和物理模型 逻辑模型 物理模型 层次模型、网状模型、关系模型、面向对象数据模型、对象关系数据模型、半...
  • 数据库系统原理ER模型与关系模型

    千次阅读 2021-03-04 02:02:44
    数据库系统是软件的一种,数据库系统自然而然也有他自己的生命周期生存期。它的生存期从规划开始,一直到将它卸载不用了。它的中间过程很复杂,为了实现用户的想法,数据库有关人员将现实生活中的数据进行抽象,然后...
  • 数据库设计关系规范化理论总结

    千次阅读 多人点赞 2020-07-31 11:08:14
    关系数据库设计过程中,最重要的莫过于对数据库的逻辑设计,即针对一个具体的问题,我们应该如何去构造一个适合它的数据库模式。经过科学家的讨论研究,最终形成我们今天所看到的关系数据库的规范化理论。本文...
  • 后经深入的研究形成了系统的设计理论 关系数据库系统中关系模型包括一组关系模式各个关系模式相互有联系 一个合适的关系数据库系统的设计关键是关系数据库模式的设计 ;关系数据库设计理论-前言;关系数据库设计...
  • 数据模型数据库设计中用来对现实世界进行抽象的工具,是数据库中用于提供信息表示和操作手段的形式构架。 数据模型是数据库系统的核心和基础。 其实就是一种E-R图的表现形式。 常见的数据模型有层次模型、...
  • 找出条件中的实体(矩形),属性(椭圆),关系(菱形)关系分为1:1,1:N,M:N,列出ER图 1:1联系的转换方法 -两个实体分别转化为一个关系模式,属性即是本来的属性 -关系可以与任意一个实体合并,关系的属性,以及...
  • 数据库模型设计 数据库建表语句 mysql建表语句  核心引擎activiti.mysql.create.engine.sql  历史数据activiti.mysql.create.history.sql  身份信息activiti.mysql.create.identity.sql mysql 删表语句  核心...
  • 理解数据库与数据模型的概念

    千次阅读 2020-03-02 19:07:15
    本篇首先引入编程微课项目作为数据库的应用...● 数据库的基本原理及数据模型关系数据库 1、编程微课 编程微课项目使用图文,语言,视频等方式进行内容教学,再附加各种训练题,帮助练习和巩固知识。 微课...
  • 教学单元2.2 第3章 关系模型数据库逻辑设计 (关系规范化) ;单元2.2 关系模型数据库逻辑设计;单元2.2 关系模型数据库逻辑设计;一IDEF1X概念模型到关系模型的转换;不规范产生数据冗余带来很多问题 规范提高数据...
  • 数据模型是指数据库的组织形式,它决定了数据库中数据之间联系的表达方式,即把在计算机中表示...1、传统数据模型(层次模型、网状模型、关系模型) 2、面向对象模型 3、时态GIS模型 4、三维数据模型 二、传统数据模...
  • 这是数据库工程设计进行到逻辑设计的一重大环节,简单的说,如果概念设计是用ER模型, 整合为全局的ER模型,那么在逻辑设计这块, 主要任务就是把ER模型转换为关系模型。 转换只需知道三个转换准则: 1...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 290,235
精华内容 116,094
关键字:

数据库设计关系模型