1、实体
员工（工号，部门编号，姓名，性别，电话，住址，入职时间，职位,薪酬）
staff(SNO,DNO,BNO,Sname,Ssex,Sphone,Saddress,Stime,Spost,Ssalary)
主键：工号SNO
分解前：
(SNO→DNO,SNO→Sname,SNO→Ssex,SNO→Sphone,SNO→Saddress,SNO→Stime,SNO→Spost,SNO→Ssalary,Spost→Ssalary)
原表候选码：SNO
所属范式及理由：2NF 存在传递依赖
分解后:
Staff1(SNO,DNO,Sname,Ssex,Sphone,Sadress,Stime,Spost)
Fmin(SNO→DNO,SNO→Sname,SNO→Ssex,SNO→Sphone,SNO→Saddress,SNO→Stime,SNO→Spost)
候选码：SNO
所属范式及理由：3NF
Staff2(Spost,Ssalary)
Fmin(Spost→Ssalary)
候选码：Spost
所属范式及理由：3NF
结算账单（账单编号，房号，住店费用，住店天数）
bill(BNO,RNO,Bcost,Bdays)
主键：账单编号BNO
Fmin(BNO→RNO,BNO→Bcost,BNO→Bdays)
候选码：BNO
所属范式及理由：3NF
客户（身份证号，姓名，性别，电话）
client(CNO,Cname,Csex,Cphone)
主键：身份证号CNO
Fmin(CNO→Cname,CNO→Csex,CNO→Cphone)
候选码：CNO,(Cname,Csex)
所属范式及理由：3NF
客房（房号，床位，客房价格，客房状态）
room(RNO,Rbed,Rprice,Rcondition)
主键：房号RNO
Fmin(RNO→Rbed,RNO→Rcondition,RNO→Rprice)
候选码：RNO
所属范式及理由：3NF
房间类型（床位，类型名称，客房价格，额定人数，有无空调，有无电脑）
roomtype(Rbed,Rtype,Rprice,Rpeonum,Rair,Rcomputer)
主键：类型名称Rtype
Fmin(Rtype→Rprice,Rtype→Rair,Rtype→Rcomputer,Rtype→Rpeonum,Rtype→Rbed)
候选码：Rtype
所属范式及理由：3NF
2. 联系
入住（房号，身份证号，入住时间，退房时间）
checkin（RNO,CNO,Intime,Outtime）
F(CNO→RNO,CNO→Intime,CNO→Outtime)
候选码：CNO
换房（身份证号，房号，新换房号，换房时间）
changeroom（CNO,RNO,Cnewroom,Ctime）
F(CNO→RNO,CNO→Cnewroom,CNO→Ctime)
候选码：CNO
预定（房号，身份证号，预定入住时间，住店天数）
book（RNO，CNO，Btime,Bdays）
F(CNO→RNO,CNO→Btime,CNO→Bdays)
候选码：CNO
内务整理（房号，工号，整理时间，用品消耗）
arrange（RNO,SNO,Time,Consumption）
F(RNO→SNO,RNO→Time,RNO→Comsumption)
候选码：RNO
这是老师给我们关系模型转化的意见：许多主键不合理，比如入住的cno。客房和房价类型关系没联系吗？
请各数据库大神指点一下，到底应该是是怎样的，帮忙改一下，给点意见
也可根据自己的建议来修改，函数依赖可以重新确定，但对不合理的关系要分解为3NF，是最小依赖，如果觉得我的关系模型太差，可以问我要er图来修改关系模型。麻烦了
不好意思，看晚了，我想问一下，为什么入住、预定、内务整理等联系都要加XX编号这个属性?
追答原则上一个表都必须标识主键。每个表加上xx编号是为了更好的标识每条记录，更加简介明了，推荐选择其它的可以作为主键的具有实际意义属性列。
追问但联系建表时，不是需要实体的主码吗？比如预定联系是一对多（客人——客房）的联系，主码不是应该由多的一方实体的主码作为联系建表时的主码吗？
还有，我想问一下，如果是多对多，联系的主码是由双方的主码构成，如果联合主码还不能唯一标识，用不用加上联系自己的部分码？
多对多关系是要转化成一对多关系的，其中需要一个第三者关系表来构成。而双方实体与此关系表构成一对多关系，双方实体多对过关系通过此表反应出来。如果联合主码不能唯一标识，就添加一个属性列比如ID，来唯一标识。
本回答被提问者采纳