阅读以下说明，回答问题。
[说明]
某公司拟开发一套小区物业收费管理系统。初步的需求分析结果如下。
(1)业主信息主要包括：业主编号，姓名，房号，房屋面积，工作单位，联系电话等。房号可唯一标识一条业主信息，且一个房号仅对应一套房屋；一个业主可以有一套或多套的房屋。
(2)部门信息主要包括：部门号，部门名称，部门负责人，部门电话等；一个员工只能属于一个部门，一个部门只有一位负责人。
(3)员工信息主要包括：员工号，姓名，出生年月，性别，住址，联系电话，所在部门号，职务和密码等。根据职务不同员工可以有不同的权限，职务为“经理”的员工具有更改(添加、删除和修改)员工表中本部门员工信息的操作权限；职务为“收费”的员工只具有收费的操作权限。
(4)收费信息包括：房号，业主编号，收费日期，收费类型，数量，收费金额，员工号等。收费类型包括物业费、卫生费、水费和电费，并按月收取，收费标准如表7.7所示。其中：物业费=房屋面积(平方米)×每平方米单价，卫生费=套房数量(套)×每套单价，水费=用水数量(吨)×每吨水单价，电费=用电数量(度)×每度电单价。
(5)收费完毕应为业主生成收费单，收费单示例如表2-2所示。
[概念模型设计]
根据需求阶段收集的信息，设计的实体联系图(不完整)如图2-1所示。图2-1中收费员和经理是员工的子实体。
[逻辑结构设计]
根据概念模型设计阶段完成的实体联系图，得出如下关系模式(不完整)。
业主( (1) ，姓名，房屋面积，工作单位，联系电话)
员工( (2) ，姓名，出生年月，性别，住址，联系电话，职务，密码)
部门( (3) ，部门名称，部门电话)
权限(职务，操作权限)
收费标准( (4) )
收费信息( (5) ，收费类型，收费金额，员工号)
业主关系属于第几范式？请说明存在的问题。
参考答案：
业主关系是2NF。
存在的问题：
(1)数据冗余，当一个业主有多套房时，重复存储多份姓名、工作单位、联系电话。
(2)可能产生更新不一致，比如更新业主个人信息时，需同时更新多处，可能漏了某处，造成不一致。
解析：
[要点解析]
[问题1]
房号可唯一标识一条业主信息，且一个房号仅对应一套房屋，所以房号是业主的主键。
员工信息包括员工号、姓名、出生年月、性别、住址、联系电话、所在部门号、职务和密码等。员工号可唯一标识一名员工，是关系模式“员工”的主键，部门号是关系模式“部门”的主键，因此为关系模式“员工”的外键。
由表7.7可知，收费关系模式包括属性收费类型、单位、单价，其中收费类型是主键。
收费信息包括：房号、业主编号、收费日期、收费类型、数量、收费金额、员工号等。房号、收费日期、收费类型是主键；房号、收费类型、员工号都是外键。
[问题2]
一个员工只能属于一个部门，一个部门可以有多个员工，因此部门和员工之间的关系为一对多。根据职务不同员工可以有不同的权限，每个员工只有一种权限，多个员工可拥有相同的权限，如职务为“经理”的员工具有更改的操作权限，职务为“收费”的员工只具有收费的操作权限，所以职务和员工之间是一对多的关系。
[问题3]
首先没有非主属性对码的部分依赖，满足2NF，但存在传递依赖，故达不到3NF。
传递依赖例如：房号→业主编号→(姓名，工作单位，联系电话)。
把原“业主”关系分解成两个关系的，这样就解决了冗余问题，成为第三范式了，即：
房屋(房号，业主编号，房屋面积)
业主信息(业主编号，姓名，工作单位，联系电话)；
这样分解，“房屋”关系的主键还是房号，外键就是业主编号了。