在MYSQL数据库里如何建立两个表的关联

1、首先我们打开Workbench创一个建数据库（这里都使用闪电1执行选定命令行)。

2、先创建Student学生表。

3、再创建course课程表。

4、然后就可以创建sc关联表了我们先写上Student的主键和course的主键,并写上sc自己的属性成绩。

5、再写上主键约束，以及把sc表的学号属性和Studnet的学号关联、课程号属性和course的课程号关联。

6、再次运行就可以看到我们成功创建了学生表和课程表的关联表sc。

是两两关联还是一表关联所有表，这不是凭空乱猜的。楼主连最基本的概念都没弄清楚，首先，你问问自己为什么需要这些表？如果这些表是凭着感觉构建出来的，那么结局注定是乱，甚至是出错更进一步的话可能出现灾难。

正确的做法是：

进行需求分析；

对分析结果画数据流图；

根据数据流图各部分构造出一个个子E-R图；

将各个子E-R图合并成全局E-R图。这个全局E-R图就是构造数据库的基石。

这个全局E-R图是业务模型的抽象，对这个图建表有以下四种情况：

1.给其上的每个实体建一张表；

2.实体与实体之间的联系，如果是一对一（很少会这样做）的，则将该联系的属性并入随便哪头的实体表；

3.如果联系是1对多的，则可以给该联系单独建表，也可以将其属性并入多的这一头。如果是单独建表，则可取多的这头表的主键为其主键，也可单独开主键，并引入多的这头主键为其外键；

4.如果联系是多对多的，则必须单独建表（这就是你上面提到的中间表），这个表最好自己开辟主键，且必须把两头实体的主键拿来当外键，以建立他们之间的联系。

回到你的问题，你给了这些表，我们并不清楚你的具体业务是什么，并不清楚你已建的这些表是否合理，也不清楚这些表在业务上的相互关系，所以外人难以给你建中间表。建议楼主先学习掌握数据库原理，然后自行分析并勾勒出E-R图，接着建表是一目了然的事了。

这个问题问的好，要弄一个表很容易，关键是表设计出来是否合理！

如果表设计的好，则会相当清晰，易于理解，后续开发上事半功倍，维护也方便；如果设计的不好，则难以理解，维护困难，代价大。

表与表之间的关系有三种：1.一对一，2.一对多，3.多对多

一对一的表，两表的属性实际上完全可以合并成一个表，共用一个主键即可；

一对多的表，可以设中间关联表，也可以将关联表并入“多”这头；若设独立关联表，则可引入“多”这头的主键作为其主键，也可另立主键，并将“一”和“多”两表的主键作为关联表的外键；

多对多的表，则必须设中间关联表，关联表设独立主键，并引入两个“多”头的表的主键作为关联表的外键。

这是上述三种关系表在键处理上的基本原则。

范式还是要遵循的，这套理论还是科学合理的。不要相信反范式设计，反范式设计在规模庞大时，数据冗余多，编码及维护会变得困难，万一考虑漏掉的将导致数据不一致，甚至酿成灾难。严格按照范式理论来设计数据库，将使你编码及维护时少 *** 很多心。

一般来说，先进行需求分析，然后画出数据流图，然后再根据数据流图画出ER图，然后再根据ER图创建各种表。表是根据ER图来创建的，表设计的合不合理，关键是ER图抽像的合不合理。在抽像ER图时，一般遵循这样的原则：

能用1对1的，就不用1对多；能用1对多的，就不用多对多，往简单化方向靠；

能当属性处理的，尽量当属性，而不是当实体处理去另立新表，这样可使问题简化。

把意义相近联系紧密的属性放在一张表内，而不是拆在多张表中。

看了一下你上述几张表，我认为不合理，户主是人，家庭成员也是人，把他们分在户主表和家庭成员表中不合理，他们是同一类的，宜合在一张家庭成员表中，并增加一个标志性字段，以指明哪个人是户主。另外，宜建立一张地址表，以取代户主表，地址表中宜指明乡场镇、村巷道、几区、门牌号等与地址关系紧密的属性，把户籍、联系方式、户主等字段拿走，他们不是地址属性，这几个宜放在成员关系表中，户籍是人的属性，并非地址的属性，联系方式就更明显了，要联系的是人，而不是地址。

很明显，地址和家庭成员是一对多关系，一个地址同时可以住着多个成员，而一个成员同时只能住一个地址，这样，设计成地址表和家庭成员表之后，要在家庭成员表中再加一个地址外键字段，把地址表的主键当作家庭成员表的外键填入，这样，成员表中的每个人都可以通过地址外键字段到地址表中找到其所住地址。另外，成员表中也指明了哪个人是户主，也指明了每个人的户籍和联系方式，这些信息你都可以找得到。

---