数据库表设计(一对多,多对多)

做一个项目,必然是少不了数据库设计的!在学习阶段,基本都是单表。然而在实际开发过程中,一对多,多对多的表处处都是!简单整理一下,一对多,多对多表如何设计整理一下思路:

    数据库实体间有三种对应关系:一对一,一对多,多对多。

一对一关系示例:

      • 一个学生对应一个学生档案材料,或者每个人都有唯一的身份证编号。

一对多关系示例:

      • 一个学生只属于一个班,但是一个班级有多名学生。

多对多关系示例:

      • 一个学生可以选择多门课,一门课也有多名学生。

1.一对多关系处理:

       通过学生和班级问题了解一对多:

设计数据库表:只需在 学生表 中多添加一个班级号的ID;

注:在数据库中表中初学时,还是通过添加主外键约束,避免删除数据时造成数据混乱!

2.多对多关系处理:

    通过学生选课了解多对多问题的处理:

       在多对多中在一个表中添加一个字段就行不通了,所以处理多对多表问题时,就要考虑建立关系表了

例:

 学生表:     课程表:   关系表:

注:所以对于多对多表,通过关系表就建立起了两张表的联系!多对多表时建立主外键后,要先删除约束表内容再删除主表内容

时间: 2024-10-11 00:36:01

数据库表设计(一对多,多对多)的相关文章

20170105数据库表设计知识点

20170105数据库表设计知识点 ------指导老师    星哥 1.PHP(MYSQL)擅长单表操作,不要做过多无谓的连接查询 2.表字段名不要使用大驼峰命名方式,最好采用下划线,命名要和团队习惯一致,通俗易懂. 3.表级.字段都要有注释 4.MyISAM 适合于一些需要大量查询的应用,但其对于有大量写操作并不是很好.甚至你只是需要update一个字段,整个表都会被锁起来,而别的进程,就算是读进程都无法操作直到读操作完成.另外,MyISAM 对于 SELECT COUNT(*) 这类的计算

无限树形结构的数据库表设计

前言: 无限树形结构的数据库表设计的是否合理,直接影响到UI层是否方便根据树来查询关联的数据. 1.表字段: F_BtEd2kTypeId int Unchecked F_Name nvarchar(50) Checked F_ParentTypeId nvarchar(50) Checked F_Code nvarchar(50) Checked F_RecordStatus int Checked 2.表数据: 3.说明: 如2所示, 1)如果上表的数据关联上了一张表A,通过BtEd2kTy

数据库表设计三范式

数据库设计三范式(nomorlization) 1NF:原子性,即每个字段都不可以在分割了. 2NF:唯一性,即每个表只描述一个实体,这个实体要有主键,非主关键字要完全依赖主键,正因为说是完全依赖,是因为在组合主键存在的情况下,非主关键字不能只依赖部分关键字. 3NF:一个表中不能包含其他表中已经存在的非主键字段信息,也就是说只可以包含其他表的主键信息,这样就是主外键,通过主外键就可以进行表之间的连接(join),3NF主要是减少数据冗余. 数据库表设计三范式,布布扣,bubuko.com

Innodb IO优化 — 数据库表设计 转

数据库表设计这块学问比较多,我这里单从互联网角度出发同时结合Innodb的特性给出一些设计方法供大家参考.本文构建大概分两分部分:Innodb的特性及设计中如何利用这种特性. Innodb特性: Innodb是索引聚集表, 存储结构是BTREE Innodb的表的数据存储是有顺序的,默认是以主建排序,主建即是数据本身,不单独存放. 如果没有主建,Innodb以第一个唯一索引排序,如果连唯一索引也没,Innodb内部会产生一个6字节的字段排序(这个也是性能杀手,所以对这块如果不想花太多时间去想这个

Oracle数据库表设计时的注意事项

表是Oracle数据库中最基本的对象之一.万丈高楼从平地起,这个基础对象对于数据库来说,非常重要.因为其设计是否合理,直接跟数据库的性能相关.从Oracle数据库菜鸟到数据库专家这个过程中,在表设计与管理上,或多或少,会犯一些错误.笔者今天就谈谈自己在这方面的经验与教训,或许能够给大家一些警示作用. 表是Oracle数据库中最基本的对象之一.万丈高楼从平地起,这个基础对象对于数据库来说,非常重要.因为其设计是否合理,直接跟数据库的性能相关.从Oracle数据库菜鸟到数据库专家这个过程中,在表设计

数据库表设计的很灵活,是否做SQL语句也那么容易呢

由于项目需要,我们把一些不经常变的常数通过数据字段配置好,系统初始化的时候通过数据库字段去更新数据.下面就实例说明. 我有一张这样的表 ,你会发现meterkindid和measureid是代码,只有通过数据配置的数据字典才能解析出我们要的值,下面为数据字典表结构 ,这样设计就很灵活,FieldID为列名称,ID为上面表的值,value为解析值,也就是代码对应的名称,下面再发一张字典的数据图 MK001和MK002对应数据字典的水表跟电表,MS001和MS002对应数据字典的计量单位分别为吨还是

用户权限管理数据库表设计思想

用户权限管理数据库表设计思想 表:(1)用户表(user) (2)权限表(power) (3)部门表(group) (4)角色表(role) (5)用户部门角色表(user_group_role)存放用户id,部门id,角色id (6)权限部门角色表(power_group_role)存放权限id,部门id,角色id 设计理念: a用户可以(绑定)属于m部门n角色   z权限可以(绑定)属于m部门n角色 由此:a就拥有z权限 设计扩展:一个用户可以同时属于多个部门下的多个角色 每个部门下的每个角

数据库设计:用户登录系统数据库表设计

用户登录系统数据库表设计 最近看了看公司后台用户登录系统的设计, 比较混乱, 主要还是因为URS和Oauth以及URS第三方这三个登录形式各不相同导致的. 下面着重介绍一下涉及到第三方登录中需要注意的问题 在一个新项目中, 如果是要建立自己的登录体系的话, 那么直接创建一个Users表,包含username和password两列,这样,就可以实现登录了: id | username | password | name等其他字段 ----+----------+----------+-------

数据库表设计五大范式所解决的问题

上学时学得<数据库系统概念>,一致似懂非懂,停留在定义和证明层面.最近在做项目,认真的了解了下数据库的范式问题,只有潜意识懂得了其原理和应用场合才能较快设计出合理的表. 首先,明确概念如下: 主码 也就是主键 候选码 若关系中的某一属性组的值能唯一的标识一个元组,而其任何真子集都不能再标识,则称该属性组为候选码.候选码不唯一,主码是其中一个而已. 主属性 包含在任一候选关键字中的属性称主属性 其次,也是本文重头戏,结合例子,讲一下各大范式对前者的改进和应用场景. 范式在现实中解决的问题 1.数