摘 要

随着城市化的进行，越来越多的社区建立起来，社区已逐渐成为政府与公民之间联系的重要媒介，如何更便捷更有效的进行社区管理现实意义凸显。
本系统使用Java、Html、CSS、JS等成熟技术，搭建SpringBoot框架对后台进行开发，因此可以大幅减少开发难度，同时在数据存储方面采用开源的轻量级数据库MySQL，使用户数据存储更加稳定。
本系统实现了对社区、业主、车辆、基础设施以及相关社区服务的信息化管理。进一步的提高社区管理人员的工作效率和社区治理能力，并在一定程度上降低成本。管理者采用本系统对社区进行智能化建设，能进一步的满足客户的方便快捷需求。在当今传统的社区服务管理系统的发展受到人力物力等诸多因素的影响，信息化管理是未来物业行业发展的另一种途径。

3 社区服务管理系统的设计

3.1 系统设计概述

本系统采用MVC软件设计模式进行设计，MVC全名Model View Controller，即模型—视图—控制台，这是一种现如今被技术人员广泛使用软件设计模式，在开发群体中有着很好的受众面。为了更好的实现开发，现在常在设计系统时常采用前后端分离的方法将Model和View实现代码分离，分离之后可以大大减少开发流程的复杂程度。社区服务系统的设计流程中采用了MVC软件的设计模型，通过这个模式可把应用程序分成三种主体:模型(Model)、视图(View)、控制器(Controller)。模型可以用来描述企业数据和行业规划并为视图中提取相关数据，而这么做的主要目的之一就是为了能够降低系统中代码的复杂性;视图是指用户所见到的并能够与其实现互动的用户界面，并作为一个输出数据允许用户进行运算;而控制器的主要功能则是接收用户所提供的命令，并按照用户输入的命令调用相关的模型和视图去响应用户的命令，从而进行操作。用通俗的语言来描述MVC应用过程那就是，最先开始由控制器接收来自应用端的请求，然后选择并使用相应的模块层对接受的请求进行处理，然后在模块层上利用业务逻辑来处理对应用的请求和反馈数据，接下来控制器再利用相应的视图层对模型所反馈的结果进行格式化处理，然后再通过表示层提交到应用。本系统中使用MVC主要有三个好处：
（1）MVC模式在开发职责上有着清楚的划分。它可以使前后端开发人员的职责清晰，前端开发工作在浏览器端进行，而后端开发工作在服务器端进行，两者互不影响，可并行的进行系统开发，大幅减少开发的复杂性。
（2）前端的开发的复杂程度可控。
（3）可快速针对需求进行对代码的更新迭代。

3.2 数据库概念设计

在进行产品设计时会通过概念模型对信息世界的模拟，把实际世界反映到了信息世界。概念模式作为第一层抽象化，可以帮助使用者与数据库的设计人员间实现有效地沟通，是面对使用者、面对现实世界的资料模式，它与数据库系统管理部门(DBMS)完全没关系，重点是为了说明每一单元的概念化架构。简单来说就是将现实世界中的客观对象抽象化表示，也就是将现实世界中的各种客观对象的一种抽象化后的资料构成，它和数据库管理部门(DBMS)没关系，一般是用来表述某个单元的概念化构成。简单来讲是把实际世界中的客观事物抽象化表示，是对实际世界中的客观事物的一种抽象化后的信息架构，而这个信息架构并不取决于具体实施的电子计算机操作系统或者具体实施的信息库管理，只是一个定义的资料模式，然后再将模型转化为由电子计算机操作系统上某一种信息库管理所提供的资料模式。于是，也可以说概念模型是真实世界过渡到机器化真实世界的过程中的一种中间阶段。在信息系统研究前期，如果数据库的系统设计与技术人员通过概念数据模型对系统数据进行构建，就能够在设计工作开始的初期阶段，把设计数据库时所必须面临的技术性问题全部按下不表，把大部分精力用来理解和描述在实际世界中所需的数据类型，在实际世界的场景中提出相应概念用以实现对信息系统世界的模拟建设，而关于数据库系统设计中的关键技术问题也可以放在信息系统的总体设计与实现阶段中加以考虑。在信息世界中，存在有实体和联系这两种基本概念。
（1）实体（entity）
实体就是实际世界中客观存在并且可以相互区别的事物，它可以是具体的人，也可以是物，还可能是抽象的概念或者联系，在社区中的实体如，一个小区，一栋楼，一辆车等。
（2）联系（relationship）
在实际社会中，事物本身内部结构与事件本身内部结构都是存在着密切联系的，而这种密切联系在资讯社会中的主要表现就是实物内的密切联系与实物外相互之间的密切联系。实物内在的紧密联系通常是指构成实物的不同属性相互之间的紧密联系，而实物间的联系则是指二种或以上实物之间共同产生的关联。当前，人们可以把二种实体间的联系分成三种：一对一联系；一对多联系；多对多联系。
当今世界上，人们最常采用的概念模型表示方法，是以联系方法（Entity-Relationship Approach）建成的E-R表示法，使用这种方法可以描述真实世界的概念模型，从而形成实体-联系模式，并建成E-R模型。
日常活动和通知，需要保存相关信息，因此建立一张活动表对日常活动和通知的信息进行存储，同时方便管理。活动信息实体E-R图，如图3-1所示。

图3-1 活动信息实体E-R图

每新管理一个楼栋，需要管理人员对添加楼栋信息，因此需要建立一张楼栋表对楼栋信息进行管理，楼栋信息实体E-R图，如图3-2所示。

图3-2 楼栋信息实体E-R图

当有陌生车辆或者社区业主车辆进入社区，需要将该车辆的信息进行登记，因此在数据库当中建立一张车辆表进行管理。车辆信息实体E-R图，如图3-3所示。

图3-3 车辆信息实体E-R图

社区表用于存放所管理社区的基本信息，建立一张社区表存储该信息，社区信息实体E-R图，如图3-4所示。

图3-4 社区信息实体E-R图

社区内每间房屋的基本信息必须清楚明了，方便管理者更好的了解社区房屋使用情况，因此在数据库中建立一张房屋表存储相关信息。房屋信息实体E-R图，如图3-5所示。

图3-5 房屋信息实体E-R图
业主信息是每个社区必须要存储的，在数据库中建立一张业主表来管理信息。业主信息实体E-R图，如图3-6所示。

图3-6 业主信息实体E-R图
社区内设有私人停车位，因此需要记录停车位的租赁状况，建立一张停车位表来存储停车位信息。停车位信息实体E-R图，如图3-7所示。

图3-7 停车位信息实体E-R图

社区设备需要维修的信息，都需要及时传给后台，同时设备状态也需要修改，建立一张维修表存储设备信息以及维修信息。维修信息实体E-R图，如图3-8所示。

图3-8 维修信息实体E-R图
管理员管理模块用于维护系统并且对数据进行修改，因此需要建立一个数据表来存储与管理员有关的信息。管理员信息实体E-R图，如图3-9所示。

图3-9 管理员信息实体E-R图

3.3 数据库表设计

数据库表设计的核心工作是在对其进行概念结构设计的过程中，把已经设计好的基本E-R图转化为一个逻辑架构，而这个逻辑架构又是和你所选用的资料库系统产品所支撑的统计模式相适应的，因此，在之后的使用中能够让你更轻松地使用。数据库的设计流程，一般包含了数据信息项安全和统一性制约、数据库系统的安全和统一性制约，以及记录与记录之间安全和一致性约束等范式问题。在表上所引用的逻辑结构要求与数据库概念模型一致，以及在实际功能上和使用性能上是否可以实现的要求，并且最后还必须经过对该数据库表的实现模式评价。
本系统数据库表如下：
(1)活动表TB_ACTIVITY用于记录社区活动，该表中属性包括活动id、所属社区名称、所属社区ID、活动标题、活动地点、举办单位等相关信息，活动表的具体逻辑结构如表3-1所示。
表3-1 活动表
Field Type Comment
id int (11) NOT NULL 活动id
community_name varchar (50) NULL 所属社区名称
community_id int (11) NULL 所属社区ID
title varchar (50) NULL 活动标题
address varchar (100) NULL 活动地点
organizer varchar (20) NULL 举办单位
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间
start_time varchar (50) NULL 活动开始时间
end_time varchar (50) NULL 活动截止时间
status char (1) NULL 状态:0-活动未开始（默认），1-活动进行中，2-活动已结束

(2)楼栋表TB_BUILDING存储社区楼栋信息。该表中包含的属性有所属社区名称、楼栋编号、栋数名称、总户数、描述、创建时间、更新时间、所属社区id。楼栋表的逻辑结构如表3-2所示。

表3-2 楼栋表
Field Type Comment
id int (11) NOT NULL ID
community_name varchar (50) NULL 所属社区名称
building_id varchar (50) NULL 楼栋编号
NAME varchar (50) NULL 栋数名称
total_households int (11) NULL 总户数
description varchar(500) NULL 描述
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间
community_id int (11) NULL 所属社区id

(3)车辆表TB_CAR用于存储进入社区的车辆信息。车辆表中包含的属性有车辆ID、车辆照片、所属成员（业主）、车辆颜色、车牌号等。车辆表的具体逻辑结构如表3-3所示。
表3-3 车辆表
Field Type Comment
id int (11) NOT NULL 车辆ID
picture varchar (100) NULL 车辆照片
owner_id int (11) NULL 所属成员（业主）
color varchar (10) NULL 车辆颜色
car_number varchar (20) NULL 车牌号
remark varchar (500) NULL 描述
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间

(4)社区表TB_COMMUNITY用于存储所管理社区的基本信息。社区表包含的属性有社区id、社区编号、社区名称、坐落地址等信息。社区表的逻辑结构如表3-4所示。

表3-4社区表
Field Type Comment
id int (11) NOT NULL 社区id
code varchar (20) NOT NULL 社区编号
name varchar (50) NOT NULL 社区名称
address varchar (200) NULL 坐落地址
area double NULL 占地面积（m2）
total_buildings int (11) NULL 总栋数
total_households int (11) NULL 总户数
greening_rate int (11) NULL 绿化率（%）
thumbnail varchar (200) NULL 缩略图
developer varchar (100) NULL 开发商名称
estate_company varchar (100) NULL 物业公司名称
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间
status char (1) NULL 状态:0-启用（默认），1-不启用

(5)房屋表TB_HOUSE用于存储社区房屋的信息。房屋表包含的属性有房屋ID、所属社区名称、所属社区ID、所属栋数名称等。房屋表的逻辑结构如表3-5所示

表3-5房屋表
Field Type Comment
id int (11) NOT NULL 房屋ID
community_name varchar (50) NULL 所属社区名称
community_id int (11) NULL 所属社区ID
building_name varchar (50) NULL 所属栋数名称
building_id int (11) NULL 所属栋数ID
code varchar (50) NULL 房产编码
name varchar (100) NULL 房产名称
owner_id int (11) NULL 户主（业主）ID
owner_name varchar (50) NULL 户主（业主）名称
telephone int (20) NULL 联系方式
room_num int (11) NULL 房间数
unit int (2) NULL 单元
floor int (3) NULL 楼层
description varchar (500) NULL 描述
live_time timestamp NOT NULL 入住时间

（6）业主表TB_OWNER用于存储业主信息。该表包括社区id、房子id、名字、身份证、照片、电话号等。业主表的逻辑结构如表3-6所示。

表3-6业主表
Field Type Comment
id int (11) NOT NULL Id
community_id varchar (50) NULL 社区id
house_id varchar (50) NULL 房子id
name varchar (50) NULL 名字
picture varchar (50) NULL 照片
idcard varchar (50) NULL 身份证
telephone int (11) NULL 电话号
profession varchar (50) NULL 职业
sex varchar (11) NULL 性别
type varchar (50) NULL
remark varchar (50) NULL 说明
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间

(7)停车位表 TB_PARKING用于存储社区停车位的信息。该表包括车位ID、位置ID、所属小区名称、车牌号、车主姓名、车主电话等。业主表的逻辑结构如表3-7所示。
表3-7停车位表
Field Type Comment
id int (11) NOT NULL 车位ID
address_id int (11) NOT NULL 位置ID
community_name varchar (50) NULL 所属小区名称
car_number varchar (50) NULL 车牌号
owner_name varchar (50) NULL 车主姓名
owner_telephone int (11) NOT NULL 车主电话
money varchar (50) NULL 车位价格
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间
status char (1) NULL 状态

(8)维修表TB_REPAIR用于存储社区维修服务的信息。维修表属性包括维修ID、所属小区名称、设备地址、维修人员电话、设备名称等。维修表的逻辑结构如表3-8所示。
表3-8维修表
Field Type Comment
id int (11) NOT NULL 维修ID
community_name varchar (50) NULL 所属小区名称
address varchar (50) NULL 设备地址
telephone int (50) NULL 维修人员电话
device_name varchar(50) NULL 设备名称
description varchar (500) NULL 报修描述
create_time timestamp NOT NULL 创建时间
update_time timestamp NOT NULL 更新时间
status char (1) NULL 状态：0-待受理，1-已受理，2-修理完毕

(9)管理员表TB_USER用于存储社区管理员的信息。管理员表中包括管理员管理员id、管理员名字、管理员电话、管理员工作id。管理员表的逻辑结构如表3-9所示。
表3-9管理员表
Field Type Comment
Id int (11) NOT NULL 管理员id
username varchar (50) NULL 管理员名字
user telephone int (50) NULL 管理员电话
userid int (50) NULL 管理员工作id