通讯计费系统设计Word下载.docx
《通讯计费系统设计Word下载.docx》由会员分享，可在线阅读，更多相关《通讯计费系统设计Word下载.docx（46页珍藏版）》请在冰豆网上搜索。
为了使读取的数据量不至于过大，采集系统会每小时定时执行一次，每次只采集上一个小时时间段之内的数据。
采集系统定时将用户使用效劳器的数据存入到了数据库中，但这些数据都是流水帐的数据，是用户每次使用UNI*操作系统的用时。
如果用户量大，用户频繁地登入/出，将产生大量的数据，不便于将来生成用户的月账单使用情况进展月统计和年统计，因此，出现了整合系统，整合系统的出现提高了用户查询账单的速度。
1.2为什么要大力开发电信计费系统：
电信计费系统已不再是被动的后台系统，而其作为整个电信行业的核心竞争力所在的地位日益稳固，已经成为整个电信系统的灵魂。
它能有效地提供效劳，降低运营本钱，提高运营效率。
无论是运营商、内容提供商还是各分销商必须给予它足够的重视，才能在群雄逐鹿中占居有利地位。
1.3电信计费系统的主要应用系统：
电信计费系统是BOSS〔业务运营支撑系统〕的一局部。
目前国内还处在BOSS建立的初级阶段，首先能做到的是将业务流程中*个环节中的不同业务进展纵向整合，如帐务管理中的长话、市话、数据各局部的整合，以及效劳不同业务的综合客服系统。
智能网上开发的业务、IP业务等，根底网络本身能够实现计费功能，这时就需要系统具有很强的整合能力，将各项使用费汇总计算出用户应支付的费用。
2系统分析
2.1可行性分析：
在电信市场竞争的环境下，计费系统是电信运营商进展市场竞争的最重要的核心支撑系统，是电信公司进展市场运作的神经中枢。
电信公司都把计费系统的建立和有效运
行作为提高效劳质量、增强自身竞争实力、刺激业务量上升的重要手段；
“提高效劳质量、参与市场竞争〞需要计费系统的有力支持。
目前看来，电信营运提供电信效劳所产生的效劳质量问题，越来越集中在电信计费系统领域。
现在用户关注和投诉的热点，如资费政策的执行、话费争议、查询难等问题都与计费系统息息相关；
“维护电信运营商自身利益和效益〞需要计费系统的有力支持。
作为计费系统，不但要做到准确地完成各项业务的费用计算，还要及时回收资金、最大程度地减少欠费，提高企业资金的利用率。
在目前竞争环境下，互联互通普遍存在，保证网间结算费用及时回收、不发生流失，成为计费系统一项很重要的任务。
每一个电信运营商的计费系统都应该有足够的手段判定结算费用的实际数目、判断互联对方结算报表的客观性、合理性，确保网间结算“以我为主〞而不能“以对方为主〞，并能够提供充分有力的结算依据；
“市场经营决策〞需要计费系统的有力支持。
电信市场竞争的不断加剧，要求电信运营商的市场经营决策必须科学化、理性化。
一个决策的失误，可能给电信公司带来难以弥补的损失、甚至危及企业的生存。
计费系统掌握着电信公司运作的大多数企业数据，其中蕴涵着企业经营态势、客户群分布特征及消费习惯、各项业务开展状况等非常有价值的信息，应该尽快着手加以挖掘和利用，辅助电信市场经营决策。
2.2用户需求分析：
电信运营商新增一项OpenLab〔开放实验室〕出租业务，即该电信运营商提供基于Uni*平台的实验室环境，选择使用这种业务的用户能够远程登录到实验室中做基于这个实验室环境的一些工作和实验。
运营商希望借助先进的计算机技术对实验室的用户进展管理和计费，由此实现对此项业务运营的支持与管理。
本系统主要涉及的是后台的数据挖掘和前台的用户账单查询。
用户成功登录账单查询系统后可以快速查询月账单以及详细账单。
由于后台的数据采集到的数据是流水账的数据〔用户1小时内每次使用UNI*操作系统的用时〕。
如果用户量大，用户频繁登录登出，将产生大量的数据，当用户需要查询账单时，查询速度会大大降低，为了提高查询效率出现了数据整合系统，数据整合系统是对原始数据进展时整合，天整合，月整合。
2.3需求详细说明
图2.1数据挖掘部署图
2.3.1数据采集客户端模块：
采集系统:
由系统定时启动扫描系统的登录历史文件〔wtmp*〕,并且分解此文件，把用户登录/登出实验室的数据发送到效劳器端。
由于系统本身分散的特点,采集点与数据存储点是分散的，数据是用Socket进展传输的，此传输方式的优点是：
数据库平安；
缺点是：
面向底层开发，需要处理多线程、数据传输失败等细节。
图2.2数据采集用例图
2.3.2数据采集效劳端模块：
数据采集效劳端负责承受客户端发送过来的数据，并且将这些数据存储到数据库效劳器中。
图2.3数据采集存储点说明图
2.3.3数据整合模块：
把采集的原始数据按用户或按实验室进展统计整合,便于实验室和用户快速查询个人的应交费情况。
整合分为按实验室整合与按用户在不同实验室上的整合。
不同用户在不同实验室上的数据整合规则：
一小时内的数据整合成一条记录。
单独存放在一*表中-天表（detaildays_*）。
一天内的数据整合成一条记录。
单独存放在一*表中-月表（detailmonths_*）。
一个月内的数据整合成一条记录。
单独存放在一*表中-年表（detailyears_*）。
〔这三*表构造完全一样，除时间*围具体的值不同.因为该表查询的频繁度很高，在设计的时候设计成天表31*，月表12*，年表根据年份一年一*。
〕
按不同实验室的数据整合：
单独存放在一*表中-天表（detaildays）。
单独存放在一*表中-月表（detailmonths）。
单独存放在一*表中-年表（detailyears）。
注意：
该表的查询主要是运营商在统计运营情况的时候使用，使用频率相对较低。
设计的时候采用每种表各一*。
图2.4整合系统用例图
2.3.4用户账单查询模块：
用户可以通过该系统修改个人的信息资料,或查询个人的交费情况.
用户应该交纳的费用公式：
交纳费用=登录时长*资费单位费用+资费根本费用.
用户使用实验室的时长公式:
：
登录时长=用户登出时间-用户登录的时间.
2.4模型分析
获取用户使用实验室的准确记录有三种情况：
1.利用操作系统自身的记录日志的功能；
2.利用开放式实验室的个人web主页功能；
3.使用开放实验室的email功能。
本系统中只对操作系统自身的功能进展处理。
本系统是一个java+JDBC+Hibernate+Struts1+MySQL数据库开发的电信计费系统，由前台的账单查询于后台的数据采集、整合两个局部组成。
2.5开发环境分析
2.5.1.集成开发工具MyEclipse:
，
Eclipse是一个开放源代码的、基于JAVA的、可扩展的软件开发平台。
它专注于为高度集成的工具开发提供一个全功能的、具有商业品质的工业平台。
它不仅仅是一个JAVA的IDE，更通过插件的形式提供其他集成软件开发工具的根底。
它能扩展到任何语言的开发，甚至能成为图片绘制的工具。
MyEclipse企业级工作平台〔MyEclipseEnterpriseWorkbench，简称MyEclipse〕是对EclipseIDE的扩展，利用它我们可以在数据库和J2EE的开发、发布，以及应用程序效劳器的整合方面极大的提高工作效率。
它是功能丰富的J2EE集成开发环境，包括了完备的编码、调试、测试和发布功能，完整支持HTML,Struts,JSF,CSS,Javascript,SQL,Hibernate。
MyEclipse是一款功能强大的J2EE集成开发环境，支持代码编写、配置、测试以及除错。
2.5.2.数据库MySQL：
本系统采用MySQL，MySQL是一个高性能、多线程、多用户、建立在客户—效劳器构造上的RDBMS，专门为了速度和稳定性而设计。
相对于像Oracle和MicrosoftSQLServer一样的更商业化、非开放源代码的系统来说，快速、强健和友好的数据库引擎、高级的数据管理和恢复工具、不断改良的特性集合、遵守现有的SQL标准、友好的商业许可原则，都是促成MySQL成为可实施的选择因素。
MySQL的较低总体拥有本钱和更稳定、更平安的系统特性，使越来越多的企业把他们的系统移植到MySQL，并且收获着MySQL开放源代码带来的效益。
MySQL的特征：
高性能、可靠性、可扩展性、可移植性、开放源代码、还有容易使用，遵循现有标准，国际化，广泛的应用程序支持等特征[2]。
2.5.3应用效劳器Tomcat：
Tomcat效劳器是Apache组织开发的一种JSP引擎，本身具有WEB效劳器的功能，可作为独立的WEB效劳器来使用。
但在作为WEB效劳器方面，Tomcat处理静态网页时不如Apache迅速，也没有Apache强健，所以一般将Tomcat与Apache配合使用，让Apache对网页的静态页面请求提供效劳，而Tomcat专为JSP做引擎，提供JSP解析，以得到更好的性能。
并且Tomcat本身就是Apache的一子工程，所以Tomcat对Apache提供了强有力的支持。
本设计采用的是：
3系统设计
3.1设计目标
对于典型的数据库管理系统，尤其是对电信这样的数据流量特大的系统，必须要满足快速查询、操作灵活等设计。
本系统在设计时应该满足以下几个目标。
a.要对Uni*产生的日志文件wtmp*进展备份；
b.采集数据时：
客户端向效劳端发送数据失败或者效劳端承受数据失败时要把这些数据存起来，以便下次重新发送这些失败数据；
c.采集系统定时将用户使用效劳器的数据存入到了数据库中，但这些数据都是流水帐的数据，是用户每次使用UNI*操作系统的用时。
如果用户量大，用户频繁地登入/出，将产生大量的数据，不便于将来生成用户的月账单和对开放实验室的使用情况进展月统计和年统计，因此，要对这些数据进展整合即按实验室和用户的时整合、天整合、月整合。
d.本系统的前台用到了StrutsMVC模式，用Struts框架提高了开发速度，使得业务层与视图层别离开来，便于系统的可维护性；
3.2系统功能模块划分
1〕后台模块划分
后台是一个C/S架构，有3个模块，分别是数据采集、数据整合、数据模拟：
数据采集模块：
由系统定时启动扫描系统的登录历史文件,把用户登录/登出实验室的数据采集并分析处理后存储到数据库效劳器.
整合系统:
把采集的原始数据按用户或按实验室进展统计整合,便于管理员统计查询或便于用户查询个人的应交费情况.
2〕前台模块划分
前台是用户所使用的界面，用户可以通过此界面进展登录、查看个人信息、修改个人信息以及查询业务账单：
用户登陆模块。
个人信息维护模块：
可以查看和更改个人根本信息；
账单查询模块：
可以查看业务月账单以及月详细账单。
3.3系统用例图
图3.1后台模型图
图3.2前台流程图
4数据库设计
数据库在一个信息管理系统中占有非常重要的地位，数据库构造设计的好坏将直接对应用系统的效率及实现的效果产生影响。
合理的数据库构造设计可以提高数据存储的效率，保证数据的完整和一致。
这里我采用了MySQL来实现电信后台数据挖掘系统和电信前台的用户自效劳系统数据库。
我的数据库设计包括如下几个步骤。
4.1数据库需求分析
收集根本数据、数据构造及数据处理的流程，组成一份详尽的数据字典，为后面的具体设计打下根底。
通过对系统功能的分析,总结出如下的需求信息。
1、用户信息表〔users〕
2、资费信息表〔pricings〕
3、用户业务**信息表〔userservices〕
4、数据原始表〔details_*〕
5、用户时整合表〔detaildays_*〕
6、用户天整合表〔detailmonths_*〕
7、用户月整合表〔detailyears_*〕
8、实验室时整合表（detaildays）
9、实验室天整合表（detailmonths）
10、实验室月整合表〔detailyears〕
4.2数据库的建立
数据库的方式：
JDBC和Hibernate：
Java提供了数据库的应用程序接口Jdbc，通过这些接口可以操作后台的强大的数据库，另外开源框架Hibernate对JDBC进展了轻量级的封装，可以使程序员用面向对象的思维方式来操作后台的数据库，本系统用JDBC实现了数据采集，数据整合，费用查询的数据库，用Hibernate实现了用户登陆，修改个人信息，查看个人信息的数据库操作。
本系统采用的数据库为MySQL。
4.3数据库系统体系构造
数据库系统体系构造是指数据库系统的组成构件〔ponent〕、各构件的功能及各构件间的协同工作方式。
数据库的体系构造主要包括外模式，模式，内模式三级体系构造。
三个模式中：
模式是内模式的逻辑表示；
内模式是模式的物理实现；
外模式则是模式的局部抽取。
三个模式反映了三种不同的观点：
模式表示了概念级数据库，表达对数据库的总体观；
内模式表示物理数据库，表达对数据库的存储观；
外模式表示用户数据库，表达了数据库的用户观。
总体观和存储观只有一个，而用户观可能有多个，有一个应用就有一个用户观。
两种映射：
在三个模式之间存在着两种映射。
模式-外模式的映射的作用是保证数据的概念模式发生变化时，只需要改变映射关系，从而保持外模式不变，而应用程序根据外模式编写，这种外模式独立于模式的特性，即逻辑数据独立性；
模式-内模式映射的作用是当存储模式发生改变时，只需要改变映射关系，从而保持模式和子模式不变，这种逻辑数据独立于物理数据的特性，即物理数据独立性。
4.4数据库系统的组成
数据库系统是指实际可运行的按照数据库方式存储和维护并向应用程序提供数据或者信息支持的系统。
一个完整的数据库系统由数据库，数据库管理系统，数据库应用程序，支持数据库运行的计算机软硬件环境以及数据库管理员等组成。
4.5数据库设计理念
数据库设计是从用户对数据的需求出发，创立一个性能良好，能满足不同用户需求，又能被选定的DBMS所承受的数据模式，进而构造出数据库构造的过程。
这里所说的数据库构造包括数据库的逻辑构造和物理构造。
数据库设计有两个最重要的目标：
满足应用功能需求和良好的数据库性能。
满足应用功能需求，主要是能把用户当前应用以及可预知的将来应用所需要的数据以及其联系全部准确的存放与数据库中，并能根据用户的需求对数据进展合理的修改操作。
4.6数据库设计内容
数据设计的内容主要有：
数据库构造特性设计，数据库行为特性设计和数据库物理模式设计。
数据库的构造特性设计是确定数据库的框架和数据构造。
他是汇总各用户试图产生的全局逻辑构造。
它反映了现实世界及其联系，能数据共享。
数据库行为特性的设计是确定用户的行为和操作，并根据其行为特性设计出数据库的子模式。
在数据库系统中，数据库的行为和动作反映在数据库应用程序中，这些行为和动作主要包括数据库的记录的添加，删除，修改，数据库的查询和统计，事务处理和报表处理等。
数据库物理模式设计要求是：
根据数据库构造的动态特性，在特定的关系数据库系统中，把数据库的逻辑构造模型加以物理实现，从而得出数据库的存储模式和存取方法。
4.7数据库构造设计
在采集数据的存储方式，根据客户需求与系统性能的考虑，设计是把数据库存储表构造分为3类：
采集的原始登录数据记录表
按不同用户在不同实验室上的数据整合表。
按不同实验室的数据整合表。
按实验室整合与按用户在不同实验室上整合的存储因为数据量的问题在设计上有区别。
其中前者的表按天，月，年各一*，后者的天表31*，月表12*，年表根据年份一年一*。
原始采集用户登录时长明细表（details_*）其中*是1-31
图4.1原始记录ER图
表4.1原始数据表
字段英文名
字段汉字名
类型
是否为空
loginname
登录名
Varchar（20）
否
loginip
登录IP
Varchar（24）
logintime
登录时间
Timestamp
logouttime
登出时间
labip
实验室IP
否
duration
登录时长
long
这31*表是采集效劳端所用，效劳端每小时从客户端承受到的用户登出记录都将存入表details_*〔*为用户的登出日期〕
〔二〕按用户统计整合的时记录表detaildays_*（其中*为1-31）
图4.2用户时整合记录的ER图
表4.2用户时整合记录表
这31*表是整合端所用，整合端每小时按用户业务整合一次用户登录时间数据，把同一用户上一小时的所有记录整合成一条记录，并存入表detaildays_*中（*为用户的登出日期）
〔三〕按用户统计整合的天记录detailmonths_*（其中*为1-12）
图4.3用户天整合记录的ER图
表4.3用户天整合记录表
这12*表是整合端所用，整合端每天按用户业务整合一次用户登录时间数据，把同一用户上一天的所有记录整合成一条记录，并存入表detailmonths_*中（*为用户的登出月份）
〔四〕按用户统计整合的月记录detailyears_*（其中*为年）
图4.4用户月整合记录的ER图
表4.4用户月整合记录表
Loginip
Labip
Duration
这几*表是整合端所用，整合端每月按用户业务整合一次用户登录时间数据，把同一用户上一月的所有记录整合成一条记录，并存入表detailyears_*中（*为用户的登出年份）
〔五〕按实验室整合的时记录表detaildays
图4.5实验室时整合记录的ER图
表4.5实验室时整合记录表
整合端每小时按实验室效劳器整合一次用户使用的时间数据。
把实验室上一小时的所有记录整合成一条记录，并存入表detaildays中
（六）按效劳器整合的天记录表degtailmonths
图4.6实验室天整合记录的ER图
表4.6实验室天整合记录表
Long
整合端每天按实验室效劳器整合一次用户使用的时间数据。
把实验室上一天的所有记录整合成一条记录，并存入表detailmonths中
（七）按实验室整合的月记录表detailyears
图4.7实验室月整合记录的ER图
表4.7实验室月整合记录表
整合端每月按实验室效劳器整合一次用户使用的时间数据。
把实验室上一月的所有记录整合成一条记录，并存入表detailyears中
（八）用户帐务**、用户业务账号、资费的实体—联系图如下：
图4.8用户帐务**、用户业务账号、资费ER图
表4.8用户表Users
约束条件
说明
id
用户ID
Int
PK
name
用户名
非空
用户登录名
UNI
loginpassword
用户登录密码
status
用户状态
默认1，0：
开通1：
停用2〔删除〕
phone
用户
email
用户电邮
enrolldate
用户开户日期
Date
closedate
用户注销日期
paymenttype
支付方式
career
职业
nationality
民族
升级会员 