传递依赖违反了数据库设计范式，但有时允许传递依赖，可以获得比较好的直观性
比如， <公司，部门，员工>这种关系，可以设计两张表：
<company-id, department-id, employee-id>
和 <company-id, department-id>
是的，这样会有冗余：<公司，部门>关系在两张表里都存在。
这样会不会出问题？ 如果一个部门永远跳不出它所属的公司，其实这种冗余就无所谓。否则，第二张表里的re-match会引发第一张表的批量改动。
那这样做又有什么好处？好处就是避免一次表连接。如果消除了传递依赖，那么查询员工所属部门时就得连接两张表： <company-id, department-id> 和 <department-id, employee-id>。
如果你的业务中，“部门”的概念非常弱，弱到只相当于一个标签的话，你就可以采取这种反范式的设计。
如果“部门”下面还分“子部门”，并且组织架构重整经常发生的话，那你还是不要这样玩了。老老实实按范式走，可以使编码更优雅更干净。