用户空气设备数据处理云平台

目录

摘要I

AbstractII

1绪论1

1.1背景与意义1

1.2现状和发展趋势2

1.3研究方案2

2需求分析4

2.1经济可行性4

2.2技术可行性4

2.3社会可行性6

3系统需求分析7

3.1系统目标7

3.2系统功能分析7

3.2.1用户注册和用户信息管理7

3.2.2设备注册7

3.2.3设备管理8

3.2.4接入数据查看8

3.3系统功能结构8

3.4系统功能描述和用例分析9

3.4.1系统的总用例图9

3.4.2用户信息管理9

3.4.3设备管理10

4云平台数据库设计12

4.1关系数据库的选择12

4.2缓存数据库Redis的使用12

4.3数据库E-R联系图13

4.4数据库表的设计14

4.4.1概要说明14

4.4.2用户表t_users15

4.4.3设备类型表t_device_type15

4.4.4设备表t_device15

4.4.5消息记录表t_message_info16

4.5数据库实体类抽象17

5云平台系统详细设计18

5.1系统总体架构的设计18

5.2系统开发工具22

5.3系争项目结构的搭建23

6项目展示26

6.1登录界面展示26

6.2个人信息展示页26

6.3设备管理模块展示27

6.4数据中心模块界面展示29

7系统测试31

7.1可靠性测试31

7.2兼容性测试32

7.3测试用例32

7.3.1测试框架JUnit32

7.3.2DeviceServer消息收发测试33

参考文献37

致谢38

摘要

当今，环境问题和居家安全越来越受到人们的关注。在工业或者民用建筑中

例如学校，酒店，小区，工厂，甚至是每个家庭都会装有空气检测的物联网设备,

例如烟雾报警器，空气净化器，空气质量检测仪等，让人们能够及时的对危急情

况作出处理，上述设备虽然能够不间断的检测空气中的状况，但还是存在很多无

法忽视的缺点。

首先，这些设备一般都是单节点的，彼此之间相互独立，因为设备可能会出

现各种故障，如果没有一个好的系统能够直接定位到出故障的设备，那么势必会

带来管理上的不便，严重的甚至可能影响到对灾情的及时警报。其次就是预警的

及时性，常规的烟雾报警器都是通过发出刺耳的响铃声来引起周围人的注意。但

是对于家庭式的，很有可能出现当警报响起时家中无人，这就使得烟雾报警器失

去了其本有的意义。最后只基于硬件设备本身功能而言，已经远远不能够满足用

户日常的生活需求，且有着许多使用上的不便。

针对以上传统空气硬件设备存在的问题，搭建一个用户空气设备数据处理云

平台。该平台拥有设备状态监测，设备数据可视化分析，消息及时预警等功能。

用户可以直接通过云平台系统查看其所有设备的运行状态，这样就可以及时定位

故障设备。空气质检将检测数据上传至云平台进行存储，云平台对原始数据进行

二次处理，并将分析结果以更加人性化的方式展现给用户。云平台拥有消息通知

模块，用户可以根据设备检测到的不同危机情况等级，设置相应的处理事件。例

如当质检设备检测到火灾发生时，云平台接受到此类事件，将自动通过电话、短

信、邮件等方式对用户进行提醒。再例如当空气中PM2.5含量过高时，提醒用

户出门记得带口罩，对于装配有智能家居系统的用户，甚至可以联动空气净化器

工作，维持空气质量的稳定。

关键词：空气质检；云平台；设备管理；及时预警

Abstract

Today,environmentalissuesandhomesecurityaregettingmoreandmore

attention.Inindustrialorcivilbuildingssuchas.schools,hotels,communities,

factories,andeveneveryfamily,air-testedInternetofThings(IoT)devices(e.g.smoke

alarms,airpurifiers,airqualitydetectors,etc.)areinstalledsothatpeoplecanbe

timelydealingwithcriticalsituations,althoughtheaboveequipmentcancontinuously

detecttheconditionsintheair,therearestillmanyshortcomingsthatcannotbe

ignored.

Firstofall,thesedevicesaregenerallysingle-nodeandindependentfromeach

other,becausethedevicemayhavevariousfailures.Ifthereisnotagoodsystemthat

candirectlylocatethefaileddevice,itwillinevitablybringaboutmanagement

inconvenience.Serious,itmayevenaffectthetimelywarningofthedisaster.The

secondisthetimelinessofearlywarning.Conventionalsmokealarmsarecausedby

harshringingsoundstoattractpeople'sattention.Butforfamily-style,itisverylikely

thatnooneisathomewhenthealarmsounds,whichmakesthesmokealarmloseits

originalmeaning.Intheend,basedonlyonthefunctionofthehardwaredeviceitself,

itisfarfrombeingabletomeetthedailylifeneedsoftheuser,andtherearemany

inconveniencesinuse.

Aimingattheproblemsexistingintheabovetraditionalairhardwaredevices,a

user-friendlyairqualityprocessingcloudplatformbasedontheInternetofThings

wasconstructed.Theplatformhasthefunctionsofequipmentstatusmonitoring,

equipmentdatavisualizationanalysis,Userscandirectlychecktherunningstatusof

alltheirdevicesthroughthecloudplatformsystem,sothatfaultydevicescanbe

locatedintime.Theairqualityinspectionuploadstheinspectiondatatothecloud

platformforstorage.Thecloudplatformperformssecondaiyprocessingonthe

originaldataandpresentstheanalysisresultstotheuserinamorehumanemanner.

Thecloudplatformhasamessagenotificationmodule.Whenthedevicedetectsa

criticalsituation,itautomaticallyinformstheuserthroughinstantmessaging.

Keywords：AirQualityInspection;CloudPlatfbrm;EquipmentManagement

用户空气设备数据处理云平台

1绪论

1.1背景与意义

随着社会经济的日趋发展和人们对生活品质的不断追求，环境问题和居家安

全越来越受到人们的关注。现如今，在工业或者民用建筑中例如学校，酒店，小

区，工厂，甚至是每个家庭都会装有空气检测的物联网设备，例如烟雾报警器，

空气净化器，空气质量检测仪等，让人们能够及时的对危急情况作出处理，特别

是火灾，煤气泄漏，有毒气体等严重威胁到人们健康安全的情况。上述设备虽然

能够不间断的检测空气中的状况，但还是存在很多无法忽视的缺点。

首先，这些设备一般都是单节点的，彼此之间相互独立，假设一个小区装有

数百的烟雾报警器，就需要耗费大量的人力定期对这些设备进行检查，因为设备

可能会出现各种故障，如果没有一个好的系统能够直接定位到出故障的设备，那

么势必会带来管理上的不便，严重的甚至可能影响到及时对灾情进行警报。

其次就是预警的及时性，常规的烟雾报警器都是通过发出刺耳的响铃声来引

起周围人的注意。但是对于家庭式的，很有可能出现当警报响起时家中无人，这

就使得烟雾报警器失去了其本有的意义。

最后只基于硬件设备本身功能而言，已经远远不能够满足用户日常的生活需

求，且有着许多使用上的不便。随着互联网技术的不断发展以及处理器性能的不

断强大，人们对产品的要求已经不仅仅局限在其功能，而是深入到产品背后的服

务了。在以前处理器性能远不如现在强大，网络带宽资源昂贵且网络延迟高的年

代，想要在设备本身的功能上进行服务的扩展显得不太现实，并且将大大提高生

产成本，这是企业所不能够承受的。

针对以上传统空气硬件设备存在的这些问题，提出搭建一个用户空气设备数

据处理云平台。首先，该平台支持海量空气质检设备的的同时接入，云平台系统

可以查看所有设备的运行状态，能够及时定位故障设备，从此远离人工定时检查

这种低效的方式。其次空气质检可以将检测数据上传至云平台进行存储，利用云

服务器强大的计算性能，对原始数据进行二次处理，并将分析结果以更加人性化

的方式展现给用户，给用户带来管理和使用上的方便。再者，云平台拥有消息队

列模块，用户可以根据设备检测到的不同危机情况等级，设置相应的处理事件。

例如当质检设备检测到火灾发生时，云平台接受到此类事件，将自动通过电话、

用户空气设备数据处理云平台

短信、邮件等方式对用户进行提醒。再例如当空气中PM2.5含量过高时，提醒

用户出门记得带口罩，对于装配有智能家居系统的用户，甚至可以联动空气净化

器工作，维持空气质量的稳定。

1.2现状和发展趋势

物联网云平台山已经不是一个特别新奇的概念了。国内几大BAT对于物联网

云平台的建设早已经有了战略性的布局。基于云、大数据、硬件管理平台等自身

传统优势，百度、阿里、腾讯发挥数据采集后的价值，以及大数据分析下的各种

衍生价值，成立QQ物联、微信硬件平台、阿里云IoT、百度云一天工一智能物

联网平台。BAT搭建的云平台不特别针对某一种特定类型的物联网设备，而是

作为一种中介平台，简化了一些开发上的复杂度，比如制定了统一的数据传输协

议，屏蔽硬件设备和云应用之间通信的复杂度等。但是企业依旧需要在开发了物

联网设备的基础上独立开发云应用来处理和管理自己的设备，只不过物联网设备

和云应用之间的通信通过统一的中介云平台转发而已。这样也就导致了一个问

题，对于很多功能不是特别复杂的物联网设备来说，也需要企业独立开发云管理

平台，增加了开发成本。本论文研究的物联网云处理平台只针对空气质检领域，

对空气质量检测仪、烟雾报警器等物联网设备提供通用的云服务，例如设备管理，

空气检测数据云端展示，全国天气和空气质量数据的推送，消息订阅等等。

1.3研究方案

空气设备云平台的系统总架构图如图1-1所示。其中硬件设备指的是NB-IoT

Device,也就是空气质量检测器，负责采集室内烟雾、PM2.5、CO等数据，并

通过NB-IoT⑶网络将数据上传到云平台。同时接收云平台下发的指令，并对其指

令进行相应的响应。硬件设备和云平台之间通过Internet进行连接，硬件设备和

云平台想要进行数据的交换，必须要制定统一的通信方式和数据交换格式。考虑

到硬件设备要高响应、低延迟、低功耗的特点。我们暂时选定TCP传输协议进

行通信。自定义数据交换格式，通过DES对称加密算法来对传输数据加密，保

证了传输的安全性。最后是本论文的主要研究部分云系统的架构，也就是用户空

气质量数据处理云平台。

用户空气设备数据处理云平台

硬件API接口WEB展示层

消

权Redisg爰存日

息

限志

队

控记

列

录

数

数

制设

据

据

备

其

处

爬

管

它

取

理

理

模

模

模

模

块

块

块

块

图1-1云平台架构图

用户空气设备数据处理云平台

2需求分析

2.1经济可行性

在做任何一件事之前，我们都会考虑其投入产出比、效率、效力等，这个项

目消耗资源的成本以及其后期带来的回报决定了项目意义。

开发一个空气设备处理云平台也以下简称空气云。空气云开发目的明确，

旨在为空气质检相关物联网设备开发一个具有通用性和可扩展性的物联网云平

台。空气云提供以用户为核心的设备管理解决方案，该平台为每个用户都提供设

备注册、设备管理、数据监控、空气数据爬取、消息预警等通用功能。其开发成

本主要体在几台高性能服务器的租赁，而项目相关的开发技术都是开源且成熟

的，不需要成本。在开发初期，只需要一台服务器即可，可以随着平台并发量需

求的提高增加服务器数量，将数据库、缓存、应用部署在不同的服务器上，逐渐

升级系统架构。所以其成本是宏观可控的。

2.2技术可行性

从开发的角度来说，技术可行性可以理解为技术选型和系统架构。我们目标

是开发一个具有通用性和可扩展性的空气云，那么在做技术选型和系统架构设计

时也应该选择一种主流的的编程语言，并且该编程语言的开源社区拥有许多成熟

的项目和技术能够帮助我们更加高效的开发网站。云平台使用Java作为开发语

言，其版本为1.8。在TIOBE编程语言排行榜中，Java长期位居榜首，Java生态

圈如图2-1所示，在安卓开发和Web领域中，它都有着举足轻重的地位。

4

用户空气设备数据处理云平台

JavaLanciuaae

Tools&

ToolAPIs

PeDlOYment

UserInterface

Intearahon

Llbranes

OtherBase

Libraries

lanaandutil

BaseLibraries

JavaVirtualMachineJavaHotSpotClientandServerVM

图2-1DescriptionofJavaConceptualDiagram

来源：ORACLEWEBSITEhttps://docs.oracle.eom/javase/8/docs/

云平台采用的是当前极为流行的MVC架构设计⑷的，MVC将整个云平台系

统分为三层，并加入了穿插于各层的权限控制、日志记录、消息队列功能。其中

硬件API接口和WEB展示层为控制层(Controller),Redis缓存和一些功能模块

为服务层，最底层是系统的持久层，也就是数据的本地存储。其中服务层和持久

层统称为模型层(Model),层与层之间通过接口连接，保证了系统功能的高内聚、

低耦合，方便以后进行功能的扩展。云平台的技术栈如图2-2所示。

系统技术栈

项目构建MVC框架数据爬取框架数据库曰志工具视图层技术

GitSpringMVCGeccoMySQLLog4jHTML

MavenSpringRedisSlf4jCSS

MybatisJavaScript

Thymeleaf

图2-2云平台系统技术栈

其架构的简要技术选型如下：

1.项目构建和版本控制工具：采用Maven做项目构建和依赖管理工具，使

用Git做版本控制。

用户空气设备数据处理云平台

2.MVC框架选择：本平台整体架构采用SSM框架搭建，也就是JavaWeb

开发中常用的SpringMVC+Spring+Mybatis组合。为了加快云平台的响应速度和

支持更高的并发数，本平台加入了数据缓冲层，采用了基于内存的键值型数据库

RediSo

3.数据爬取框架：为了给空气质量检测仪推送全国天气和空气数据，需要

空气云定时从其它天气网站中实时爬取天气和空气数据存储到本地数据库，硬件

设备可以通过硬件API接口来获取这些数据。本平台采取的数据爬取框架为

WebMagic,它能够简化数据的爬取的过程。对于爬取一些简单页面来说，它拥

有体积小，爬取迅速的优点。

2.3社会可行性

针对传统空气检测设备管理不便、及时性差、功能单一等现象，结合物联网

和互联网技术，基于一种NB-IoT的空气质量检测仪开发的空气设备数据处理云

平台。能够让用户方便的管理硬件设备，随时随地掌握消息动态，将“被动”转

化为“主动”。

对于一个没有拥有自己云平台的空气质检设备制造商来说，在如今都讲究

“万物互联，服务为王”的时代，必然会逐渐丧失自己的核心竞争力，但是一个

中小型企业如果需要培养自己的技术团队和运营团队去开发和维护一个自己的

云平台，那么必然需要投入巨大的人力物力财力以及时间，这是很多小企业都无

法承受的代价，如果拥有一个开源的云平台，那么既可以大大减少预期投入，同

样也能大大降低风险。

用户空气设备数据处理云平台

3系统需求分析

3.1系统目标

用户空气设备数据处理云平台，基于用户来对各个空气质检设备来进行管

理，这里的用户一般指质检设备的使用者，可能是个人、小区的管理者，因为平

台的设计初衷就是为了满足多用户同时在线对多种不同的设备进行管理。他们可

以通过云平台进行设备注册、设备查看、设备数据上传等操作，此外，云平台还

提供全国各区域的空气和天气数据的ResultfulAPI查看接口，对于可以通过

Internet连接到的云平台的物联网设备，可以在不用添加硬件相关模块的基础上，

直接获取到相关空气质量和天气数据，可以进一步降低成本。我们期望能够搭建

一个高并发低延迟的系统，能同时支持大量用户和硬件设备的连接。用户可以通

过人性化的后台管理界面，随时随地掌握设备动态。

3.2系统功能分析

3.2.1用户注册和用户信息管理

几乎任何后台管理类系统都需要基于用户来对于整个系统进行操作，只有拥

有相应角色的用户才能够对相应功能菜单进行操作。用户注册需要系统使用者提

供一些个人基本信息，云平台将会根据这些信息为其生成一个仅供个人使用的账

号，密码可由账号使用者指定。

用户信息管理模块提供用户对之前注册的信息进行修改和账号密码更改等

功能，因为网站所有的功能都是基于用户来进行展示的，每个用户只能查看和管

理个人注册的设备相关信息。

3.2.2设备注册

云平台的功能核心就是设备管理。在进行设备管理之前我们需要设计一个安

全验证模块，只有被云平台授权的设备类型才能够连接云平台并被云平台所管

理。设备注册就是安全验证模块的一部分，设备类型注册需要用户通过系统手动

填写设备相关的一些基础信息，例如设备名称、设备类型、数据push方式、数

据pull方式等等，系统最后会根据该注册信息为该设备类型生成唯一的设备类型

ID以及设备验证token,这样当该类型的设备连接云平台时，只需要根据该验证

7

用户空气设备数据处理云平台

token就可以证明其身份。

3.2.3设备管理

设备管理是用来查看该用户已经注册的设备类型列表，可以查看和修改设备

的基本类型信息，除此之外，还能查看已经接入平台的设备列表，可以直接查看

到设备的当前状态，上次状态更新时间，设备消息预警级别等等。

3.2.4接入数据查看

已经接入平台的设备可以随时向云平台上传其设备检测数据，云平台会将其

组织化的存入数据库，设备上传的数据需要符合平台与设备通信约定的数据格

式，这样云平台才能对数据进行正确的解析和最终展示。

3.3系统功能结构

根据以上我们对云平台主要功能的分析，我们可以得出系统的主要功能结

构，如图3-1所示，云平台主要包含了用户管理、设备管理、数据爬取、数据接

设备消息直看

图3-1系统功能结构图

用户空气设备数据处理云平台

3.4系统功能描述和用例分析

用例描述用来说明一个功能的大概处理流程，可以较为准确的去描述一个业

务功能。是客户和开发者之间良好的沟通桥梁。

3.4.1系统的总用例图

本系统开发初期会基于某一个用户进行开发，该用户拥有系统所有功能模块

的访问权限，其角色相当于管理员，系统的总用例图如图3-2所示。

图3-2云平台系统总用例图

3.4.2用户信息管理

(1)功能描述

用户信息查看：管理员或者用户登录云平台进入个人中心主页可以看到个人

信息。

用户信息修改：当用户注册信息变化时，用户可以通过此功能进行修改个人

信息。

密码修改：当密码泄露或者系统账号安全预警时，用户可以修改登录密码，

保障账号的安全。

(2)用例描述

用户信息管理用例的参与者是用户或者管理员，其详细用例描述如表3-1所

示

用户空气设备数据处理云平台

表3-1用户信息管理用例

内容说明

用例编号UserinfoManagement

用例名称云平台用户个人信息管理

用例说明对个人信息进行查看、编辑、修改个人密码

参与者用户或者管理员

前置条件用户登录云平台的个人中心页面

基本事件流1.用户点击个人信息页面，这时会显示用户个人信息。如果没

有显示，跳至al。

2.用户点击修改按钮，这时会弹出消息模态框，用户可以修改

自己的相关信息，点击保存按钮，模态框消失，弹框提示保

存成功，否则跳至a2。

3.用户点击修改密码按钮，这时会弹出修改密码模态框，按照

流程进行密码更改。点击确认，原密码输入正确密码修改成

功，自动提示重登，否则跳至a3。

异常事故流al.提示框：功能异常，请刷新页面重试。

a2.提示框：保存失败，提示失败原因。

a3.提示框：修改失败，提示失败原因。

后置条件用户成功完成相关操作

3.4.3设备管理

（1）功能描述

设备类型注册：用户需要添加连接云平台设备基本信息，云平台会为此生成

唯一的验证token,空气质检设备可以根据此token通过验证，连接云平台。

设备列表：显示曾连接过云平台的空气质检设备列表，会显示设备的基本信

息，同时还可以修改预警级别，开启下线预警，加入设备黑名单等等功能。

设备数据查看：空气质检设备和云平台机建立稳定连接后，就可以向云平台

上传自己的设备数据，用户可以在云平台上查看设备数据。

（2）用例描述

用例描述主要包含了参与者、前置条件、基本事件流的说明，设备类型注册

的用例描述如表3-2所示，设备列表的用例描述如表3-3所示。

表3-2设备类型注册用例

内容说明

用例编号DeviceTypeRegister

用例名称设备类型注册

用例说明用户添加被管理的设备的基本类型信息

参与者用户或者管理员

前置条件进入设备类型管理页面

10

用户空气设备数据处理云平台

基本事件流1.用户点击列表右上角的添加按钮，弹出设备注册模态框，用户

填写要注册设备类型的基本信息。

2.用户填写设备基本信息完成后，点击确认添加按钮，模态框消

失，弹框提醒，设备类型添加成功，然后刷新列表。否则跳至

3.1o

3.用户点击列表任何设备类型记录中的修改按钮，触发设备类型

信息修改功能。弹出修改模态框，模块框会加载之前设备注册

的相关信息。否则调至a2。用户修改相关信息，点击保存完成

修改，模态框消失，提示保存成功，否则跳至a3。

异常事故流al.提示框：设备注册失败，提示失败原因。

a2.提示框：加载信息失败，请刷新页面重试。

a3.提示框：修改失败，提示失败原因。

后置条件用户成功完成相关操作

表3-3设备列表用例

内容说明

用例编号DeviceList

用例名称设备列表

用例说明用户通过设备列表管理设备

参与者用户或者管理员

前置条件进入设备列表页面

基本事件流1.用户可以根据查询条件筛选设备，点击查询按钮，列表刷新，

显示筛选结果。否则跳至al。

2.在线设备可以查看其实时数据，对于在线设备，右侧有查看按

钮，点击查看按钮，进入数据详情页。否则跳至a2。

3.点击加入黑名单按钮，云平台将会禁止该设备连接云平台，

设备状态之前如果为在线状态，这时会变为已下线。

异常事故流al.提示框：查询失败，请刷新页面后重试。

a2.提示框：实时数据加载失败，请检查设备状态。

后置条件用户成功完成相关操作

用户空气设备数据处理云平台

4云平台数据库设计

4.1关系数据库的选择

空气云选用的是MySQL数据库，MySQL是一个小型关系型数据库管理系

统以其体积小，速度快，应用成本较低，是开发中小型项目的首选。相比其它

类型的数据库，它有以下几个特点：

1.功能强大，能够满足几乎所有的开发需求，并且开源免费。

2.支持多种存储引擎，可根据开发场景的不同为表选用合适的存储引擎，提

高数据库的性能。

3.安装简单，扩展容易，迎合了企业敏捷开发产品快速迭代的需求，可根据

业务量的逐渐提升逐渐改变数据库的架构，从数据库分区、分表到主从搭

建、读写分离，都可以用比较小的成本去实现。

在真正的企业级开发中一般都是搭建数据库主从集群，开发阶段使用两台云

数据库，一主一从，读写分离，这样能够有效提高数据库的读写性能，避免产生

10性能瓶颈。云平台的数据库架构是单机架构，这也是根据目前系统大小和并

发量来决定的，如果对小系统使用数据库集群，不仅不会提高网站的并发量，还

有可能增加网站的响应时间。因为只有在网站并发量极大，数据库成为瓶颈的情

况下升级数据库架构才会有意义，否则只会增加应用服务器的压力（数据库架构

越复杂，业务层所做的处理就越多），反而降低了网站的并发量。

4.2缓存数据库Redis的使用

为了避免数据库压力过大，云平台引入当下十分流行的Key-Value缓存数据

库⑹Redis,对于一些页面可以极大降低访问延迟。

用户每浏览一个页面，浏览器可能需要向应用服务器发起几十个请求。除去

一些静态资源，如CSS、JS、图片等，其它的请求每次都需要连接数据库去读写

数据。网站并发量比较小的时候，应用服务器和数据库都够很快的处理请求并将

响应结果返回给用户。但随着用户并发量的增大，数据库表记录的快速增长，数

据库的查询时间会逐渐变长，查询性能越来越差，每个用户请求的处理时间越来

越长，并发的请求数又在增加，在这种情况下，应用服务器可能因为大量请求的

堆积而被压垮宕机。

12

用户空气设备数据处理云平台

［请求返回J

图4-1缓存命中流程图

如图4-1所示，开发的最佳实践是减少对数据库的访问，将短时间内不会改

变的数据进行缓存，用户第一次请求该数据时访问数据库获取，然后将该数据进

行缓存。用户下次获取该数据时直接命中缓冲，避免了查询数据库。一次请求使

用缓冲和不使用缓存其性能可以相差十多倍。

4.3数据库E-R联系图

数据库E-R图可以很好的用来表示现实世界的概念模型。可以让开发人员

在不熟悉数据库的情况下更快了解业务中的各实体对象的相关联系，是软件开发

数据库设计中不可或缺的一个阶段，开发者根据总体E-R联系图在代码中建立

对应的Entity对象，云平台的主要实体-联系图如图4-2所示。

图4-2系统主要关系E-R图

用户空气设备数据处理云平台

4.4数据库表的设计

4.4.1概要说明

合理的表结构能够减少冗余数据的产生，提高数据库查询速度。一般来说数

据库表的设计需要满足第三范式，这样表数据的冗余会最少，但是在企业级开发

中很少会这样设计。因为严格按照三范式来设计表的话，那么一个数据的查询可

能要连接三张表以上，这样会导致严重的性能问题。云平台期望设计一个高可靠、

低延迟的后台系统，那么数据库的设计就显得十分重要，本平台数据库设计概要

规则如下：

1.每个表都设置ID字段用作主键，主键生成策略使用UUID,也就是全局

唯一ID,便于后期数据库架构进行升级，分区分表等等不会遇到主键不唯一的

问题。

2.数据库不设置外键，也不建立其它约束，如非空、唯一等。实体与实体

之间的关系通过业务层来保证。这样在开发初期能够避免因为数据约束问题导致

的各种数据库异常发生，而最重要的一点是，表的约束越多，那么每次CRUD

操作数据库都需要去检查数据是否满足约束条件，增加了数据库资源消耗，降低

了数据库性能。我们把约束性检查交给业务层，也就将压力给了应用服务器，但

往往数据库的性能瓶颈要比应用服务器来的快。

3.对于经常需要连表查询的字段进行适当冗余，这样可以只查询单表便能

得到需要的数据。

4.几乎每张表都需要设置表4-1中的通用数据库字段，以方便业务后期扩

展和权限控制，之后表详细设计中将不会列出该表中的通用字段。

表4-1通用数据库字段说明

字段名称类型长度字段说明

create_timedatetime默认创建时间

create_byvarchar36创建者ID

update_timedatetime默认更新时间

update_byvarchar36更新者ID

del_flagbit1删除标志，0未删除，1己删除

用户空气设备数据处理云平台

4.4.2用户表t_users

用户表可以说是系统最核心的一张表，任何业务和功能都需要基于用户细粒

度去开发。详细表结构设计如下：

表4-2用户表字段说明

字段名称类型长度字段说明

user__idvarchar36用户ID

user_namevarchar30用户昵称

sexbit1性别，0：男，1：女

organization_namevarchar50组织名称，（公司、小区）

4.4.3设备类型表t_device_type

设备类型表主要用于设备类型的注册，每个和云平台连接的设备都对应唯一

的设备类型，通过该表可以知道设备的一些约定配置。云平台凭借这些约定配置

来和设备进行通信。

表4-3设备类型表字段说明

字段名称类型长度字段说明

type_idvarchar36设备类型ID

设备验证token,设备连接安全验

access_tokenvarchar36

证

type_namevarchar10类型名称

connect_typeint1连接类型，0:TCP,l:UDP,2:HTTP

默认预警级别：0：无，1：下线预警，

warning_typeint1

2：数据异常预警

waming_keyvarchar30异常数据关键字

warning_wayint1预警方式：1：邮箱2：短信3：电话

4.4.4设备表t_device

设备表用作记录连接云平台设备的相关信息。通过这张表我们能够知道设备

的一些基本状态、连接记录、统计信息。

用户空气设备数据处理云平台

表格4-4设备表字段说明

字段名称类型长度字段说明

device_idvarchar36设备ID

device_typevarchar36业务逻辑中设备类型ID

设备名称，默认为类型名

device_namevarchar36

称+自动增长编号

connect_addressvarchar50记录设备连接IP

custom_warn_gradeint1自定义预警类型

last_connect_timedatetime默认最后一次连接时间

heartbeat_gapint1设备心跳间隔，单位秒

是否加入黑名单。0：false,1：

blacklistbit1

true

4.4.5消息记录表t_message_info

消息记录表用来存放设备的上传数据，数据异常消息记录，设备下线记录等

等。

表格4-5消息记录表字段说明

字段名称类型长度字段说明

msg_idvarchar36记录ID

device_idvarchar36设备id,业务逻辑上的外键

消息类型：1.上线2.异常下线3.

msg_typeint1

设备数据。

msg_bodyvarchar10000消息体，以json格式去存储。

用户空气设备数据处理云平台

4.5数据库实体类抽象

平台实体类及关系图如图4-3所示。

消息记泉表

msg_id

devlce_narr»edevice_id

connect_addressrrtsg_type

customwarngarde

rr»SRbody

last_conr»ect_time

heartbeatgap

改笛炎型表

Id