天线参数数据库设计论文范文

本站小编为你精心准备了天线参数数据库设计论文参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

1数据库模型设计

本文以面向文档的NoSQL作为数据持久层，面向文档的NoSQL数据库的数据结构设计相对于关系型数据库来说容易许多，在对数据进行查询、数据库操作接口方面都有很大的优势］。因为面向文档的NoSQL数据库不支持多张表的JOIN操作，因此在对面向文档的NoSQL数据集合进行设计的时候需要考虑到这方面的因素。本监测系统主要的业务功能可以分为3个模块，分别是小区信息查询模块、报表统计模块和用户、终端管理模块，因此，数据集合的设计同样从这三个方面进行设计。各个数据集合之间的关系如图1所示。考虑到在对数据表进行设计所依据的原则基本一致，因此以下仅对小区信息查询模块的数据表设计进行着重分析。设计数据模型需要结合系统的特点进行分析。此系统主要实现的功能是对小区天线参数信息进行保存、管理，并以友好的界面展示给用户，并响应用户的各种操作。因此，在大部分的操作中，存储天线实时参数的ANTENNAARGS表会产生大量的插入操作，本文根据各个表的不同读写比进行了设计，如图2所示。本文将天线表、区域表以内嵌的形式放入了小区表，将天线参数表设计成单独的集合，并以引用的方式指向了小区表主要是考虑到天线参数集合是被访问最频繁的表，会产生大量的读写操作，因此在小区集合与天线参数集合之间采用的是范式化的模式。其中，天线工参表(ANTENANARGS表)用来存储从各个采集终端传输至管理系统的小区天线实时数据信息，具体如表1所示。小区信息表(CELL表)用来存储各个小区的地址、天线相关参数详细信息，如表2所示。除了上述表之外还有采集终端表(TERMI-NAL)、天线信息表(ANTENNA)和告警表(ALARM-REPORT)等。数据库运行时，自动将所对应的数据存入相应表中。

2数据库自动分片设计

管理系统在运行中会产生大量的写操作，进而带来频繁的磁盘I/O操作，在大数据下，最好采用将数据库分布在多台服务器上，即分片［7］。本文采用Auto-Sharding(自动分片)及Replic-Set(复本集)相结合的方式来减轻单个数据库服务器的负载，即在每台Server上各自运行一个实例，组成一个Replic-Set，最后再各运行一个实例，组成ConfigServer。直接执行Addshard操作即可增加分片以缓解服务器的压力，实现动态扩展。分片的实现重点在于片键设计。本文将保存天线参数信息的集合声明了一个复合片键{Lacci:1，Day:1}。当来自不同的小区(可以根据Lacci进行判断)向集群系统插入数据时，可以预计到在大部分情况下，同一小区的数据会落在单个块或片上。

3数据库查询的实现

数据查询功能为本数据库设计的重要功能之一。数据库将小区信息、天线参数等相关的数据信息根据用户的要求，以界面或报表的形式全部或部分的显示给用户。基于本数据库的设计，用户通过数据查询菜单进入相应查询界面，获取小区信息、终端信息及告警信息等。实现“天线工程参数查询”功能的工作流程如图3所示。为了实现小区天线参数查询功能，客户端需要向数据库发送2次请求，用户根据需求，向控制器发送查询请求，控制器处理查询命令，对相应的小区进行信息查询，待小区返回信息后，将用户的查询命令发送至对应小区，根据需求读取有用信息，并返回给用户。跟关系型数据库相比，由于省去了大量的多表连接操作，实际上查询的效率要高于基于关系型数据库的多表连接查询。查询工作的SQL语句如下。

4数据库备份与恢复

数据安全在数据库设计中有很重要的地位。在各种意外情况下，如计算机硬件故障等，对数据库进行备份和恢复能够保障数据的完整性和安全性，使得数据损失降到最小［8］。本数据库设计的备份选用的是副本集的方式［7］:在主节点上进行操作，写入的数据被一步地同步到所有的从节点上，并从主节点或从节点上读取数据，如果主节点由于某些原因断线，会自动将一个从节点提升为主节点。在查询分析器中运用SQL语句完成数据库的备份和恢复。在数据库管理界面中，用户通过数据库备份与恢复功能进行相应操作，确保数据的正确行和完整性。

5结束语

与传统的管理系统基于关系型数据库相比，基站参数管理终端采用的面向文档的NoSQL具有很大的优势:采用副本集方式进行数据库备份与恢复，保证数据的完整性和安全性;Auto-Sharding的机制，实现了数据的分布式存储，同时也可以方便地实现系统的水平扩展。本文从数据库表的设计，各个表之间的关联以及其中涉及的关键技术都做了描述，最终能够实现对基站参数的有效存储与查询，为移动通信基站的管理与维护提供了重要依据。

作者：张锡娜张治中邓炳光单位：重庆邮电大学通信网与测试技术重点实验室