BOSS经营分析系统——ORACLE PL/SQL细节技术浅析

本篇BLOG结合目前实施的经营分析项目，针对在网上ORACLE PL/SQL探讨比较多的几个技术，总结一点自己的心得。
一、行列转置——站着进来，横着出去
1、Case When的方式；

2、Decode的方式；
以上的两种方式只能对固定值或者固定值区间来进行行列转置，不能很灵活的对不定列的处理。虽然也可以通过动态SQL语句使用CASE WHEN/DECODE来实现不定列的处理，但是代码会很糟糕。

3、不定列的实现；
这种方式需要采用OCI或者通过过程的封装来实现。

二、删除重复记录——煮豆萁燃豆，萁在釜中泣，本是同根生，相煎何太急

三、字符串合并——缘需而发，一线连珠
1、OCI的方式实现

2、自定义函数/过程实现

四、满页尽是FTP


上面有待完善，此BLOG平台不能上传文件，郁闷。

近期读书计划（3月15日——5月）

1、Introduction to Algoritms；


3、3G网络核心技术；

4、Patterns of Enterprise Application Architecture(MARTIN FOWLER)；

5、OLAP解决方案：创建多维信息系统；

6、The Data Warehouse Lifecycle Toolkit:Expert Methods for Designing,Developing,and
Deploying Data Warehouse；


7、Introduction in Data Mining。

BOSS经营分析系统——系统开源架构

全省集中话务网管接口的实现

一、DATABASE方式
1、HuaWei G6 switch NRR数据接口
G6/G3都是从SQL SERVER7.0中STAT库中取数。对于用户关心的主要是trunk、n7l、cpu、ecp的性能数据。取其中stat库下的表tbl_StatsResult***进行解析。

2、Huawei Wireless NPR数据接口
Wireless NPR从ASE11.9 SYBASE中取数。

3、Siemens Switch ALARM数据接口
从ORACLE中取数，主要涉及的表有：ADS_ALARMOBJECT，ADS_ALARMHISTORY，ADS_ORIGINALALARM，
ADS_ADDITIONALINFOMATION。

二、File方式
1、Siemens Wireless NPR数据接口
通过提供的指令取文本文件进行parse，load入库。指令格式如：getexp TH 010704 10 10，发完指令后生成数据文本文件。

2、Siemens Switch NPR数据接口
spots上文本文件。文件存放目录：两种文件格式分别为.spf (每15分钟产生一次文件) 和.trf (每天产生一次文件)。

三、Stream方式
1、motorola wireless Alarm数据
通过指令sld实时接收OMC故障管理模块的故障，并把故障以ASCII 格式写入 stdout 文件中。 Stream流结构为：

四、Third-party方式
这种方式如果有条件，是最集中的最方便的方式，从Third-Party获取转换过的数据，主要可以从全省集中维护网管系统、Metrica NPR等系统中获取所需要的数据。但是前提条件是要全面理解Third-party库表结构。

五、Pre-make方式
通过OMC的功能预先生成定制需要的数据，以文件格式进行保存，然后FTP，load到数据库进行转换层现。优点：可以进行较少的数据transition，parse，calculate，更多用于直接给用户做报表呈现。

六、CORBA、Q3接口
此乃集大成者，所有接口的最终标准。

BOSS经营分析系统——维度建模（一）

一、维度的类型（相互之间有特性重叠）：
1）常规维：基础的维度，如：城市维度、日期维度、时间维度；
2）共享维：用于多个事实表的维；
3）私有维：用于单一事实表的维；
4）代理维：也有叫法为虚拟维，主要根据事实表的属性自定义映射的值；
5）退化维：仅仅是事实表中的一列，这个维的相关信息都在这一列中，没有维表与之相关联；
6）渐变维：维度属性随时间发生变化的。

二、具体建立维度需要注意的几个地方
1、日期/时间维度
对于用户入网、业务办理、用户话务量等的分析中，都需要考虑日期/时间维度。 几乎所有的事实表中都要考虑到日期维度，在日期维度中需要建立特殊日期的维护。对于忙闲时的分析需要按照小时的时间维度。

2、既是事实表，也是维度表。
在业务建模中，对于用户入网资料表，对于用户入网分析中，此表作为fact table；但对于做用户的话务量分析，此表作为dimension table。此表承担了两种role。

3、会设计到星系模式，网系模式的建模。
对于承担了事实表和维度表两种角色一般都会是网系模式，以及共享维度的事实。

4、fact table需要考虑不同类型的处理
需要考虑事务型事实表、累积型事实表、周期型事实表的正确选择。
对于需要按截止日期的用户资料事实表，采用周期快照型事实表。有周期快照型的事实表同时承担了维度表的角色，需要采用手段防止作为维度表的数据量扩张。
可以采用的手段主要有：
1）周期快照的分区处理；
2）建立不同分区的物化视图作为维度；
3）按照周期建表独立管理，如：subscriber200610,subscriber200611,subscriber200612，但是这样管理难度没有分区表容易。
对于话务量、业务量办理的事实表，采用累积快照事实表，这部分的数据量膨胀会相对比较大。需要控制好表分区的设计。

5、由事实表维护维度表存在维度表中的记录需要通过事实表来确定。
在竞争对手的分析中，作为本方不清楚对方的新号段，对于后台需要自动提取对方的新增号段更新到维度表中。