项目设计的规划从哪儿做起

本文以某银行项目为例，浅谈项目设计规划。

1. 底层数据库的规划

系统涉及两种数据库：DB2数据库和Netezza数据库。

DB2：BI系统资源库，即银行所谓的知识库，用于存储BI系统表；

Netezza：分析库(视图库)，即BI系统的主题维度等多维数据模型库；

下面是某银行系统架构图：

 

可能大家会想，BI默认的数据库连接池，为何不直接指向分析库？

原因有二：

 a)规范的管理，将分析库和系统配置库分开管理；

 b)Netezza不支持大字段；

【小科普】 Netezza是一家数据仓库设备提供商，现在已经被IBM收购，其产品是真正的，专门为数据仓库设计的一体机，将、数据处理和数据储存集成在一个紧凑的、优化的系统中，以满足数据分析处理和数据灵活增长的需要。 Netezza一体机与传统数据仓库的一个很大区别在于它的简单性。这种简单性体现在方方面面。 安装与部署的简单性 :从外部来看 Netezza一体机就是一个大盒子，给这个大盒子插上电配置好服务 IP那它就可以对外提供服务了。而传统的数据仓库往往需要花很大的心思在物理规划设计上。这包括规划存储、配置网络以及安装所需要的软件等等。 管理和维护的简单性 :听起来似乎有点不可思议，但事实确实如此，Netezza几乎不需要执行任何传统数据仓库 DBA所执行的任务： 没有索引(index)； 不需要性能调优(tuning)； 不需要存储管理：没有 dbspace/tablespace规划和配置，没有 redo/physical log规划和配置，没有表的 page/block/extent规划和配置，无需临时表空间的分配与监控，无需 RAID级别的选择，无需逻辑卷的规划与创建时间； 无需配置操作系统内核参数以及维护建议的操作系统补丁级别； 简单的数据分区策略：哈希或者随机。

2. 主题表的分类和设计

某银行这个项目的定位是比较高的，要将这个系统打造成某银行的数据仓库系统，其涵盖的业务面非常广，几乎囊括了某银行的所有业务部门。那么多部门、那么多表、那么多数据，如何"整理、摆放"才不会乱套呢？

2.1 主题表分类管理

某银行所有主题表按照业务部门归类，根据各部门业务不同，建设了一个个的BI分析主题。

 

2.2 字段一致命名

只要是相同业务含义的字段，一致命名。某银行主题表非常多，根据业务不同进行分类，凡是出现相同业务含义的字段，全部统一命名，例如，大多数主题表都有机构代码，这个字段的命名统一为ORG_ID。 

2.3 一致性维度

某银行虽然主题表很多，但是他们分析的维度相对较少，常用维度就只有4个，他们建立了一致性维度，所有主题表都是关联着四个维表。 大家都知道维度建模理论中的基本原则：维度和事实一致性；落实到模型中的字段就是要求同名同义，或同义同名；即数据仓库模型中所有主题和维度中凡是业务含义相同的字段命名要相同，凡是命名相同的一定意味着业务含义一致。 虽然大家都知道这个理，但在实际项目实施中，我们还是会经常见到不规范，同名不同义或同义不同名的模型，有的是最终用户的现有模型，有的是中间代理商做的模型，有的甚至是我们自己项目工程师做的建模，真正能遵循这个规范的还真不多，伙伴实施厂商却能严格地遵守这个原则，很了不起。

3. 报表样式和风格的统一

某银行综合报表平台，分析的对象主要是银行各业务系统的数据。 用户要求该模块的报表样式和风格整齐统一、严肃认真。 基于此，伙伴实施厂商设计了一整套报表制作规范：

【规范】 大标题宋体、16号、加粗、居中； 小标题宋体、9号、加粗、居左/居右； 表体标题行与合计行宋体、9号、加粗、文字居中/数字居右； 表体浮动区域宋体、9号、文字居左/数字居右； 报表风格：黑白； 【效果展示】

4. 分析表名与标题的规划

在整个系统中，不仅主题表按部门规划的，分析表也是按部门进行分组管理的。每个业务部门都有若干分析报表，每张报表的代码都按照一定的规则进行编码，如：001、002、003......，报表的名称即按照业务内容进行命名，如下图所示：

5. 报表参数的命名规划

整个系统几百张BI分析表，每张表都会有N个参数，有些参数还是公用的，某银行项目中对参数有什么统一规划吗？ 确实，我们先看看参数举例： 【计算参数例举】

@Data_Dt：日期，日期下拉框，默认值为数据最大日期<#=ardb()#>； @Org_Id：机构，维下拉框，默认值1000000000； @Currency_Cd：币种，维下拉框，默认值999(人民币)； @Org_Level：机构级别，枚举下拉框，枚举机构的几个级次； @Start_Dt：开始日期，日期下拉框； @End_Dt：结束日期，日期下拉框；

某银行中的参数有这么几个特点：

（1）命名有规则

有"@"，有"_"，有业务含义，最重要的还是得有业务含义。

某银行计算参数，一般情况下看到参数名就能知道参数是什么意思。

例如@Org_Level，Org是机构的意思，Level是级次，这个参数就是用来选择机构展现级次的。

（2）与主题表字段名一致

如果计算参数跟主题表的字段有关联，那么计算参数用主题表字段名来命名，例如主题表的机构代码字段ORG_ID，关联的维表是，报表的计算参数@Org_Id。

（3）参数有默认值

所有计算参数都设置了默认值。

原因，某银行对门户中所有的报表都设置了自动计算，每张表都必须根据默认值自动计算出结果。

不了解这个系统和业务规则的人会肯定会觉得，这个参数写起来很麻烦，不仅需要区分大小写，还得带"@"、"_"等。但若你了解业务规则，Org=机构、Data=日期、Level=级次、Currency=币种......就不会觉得它的名称有多复杂，反而能让你感觉到这才是"专业"，这才是"标杆"。 如此定义，每个参数的命名都统一规范了，每个参数也有了自己唯一的业务含义。

6. 结果显示的统一规划

对于计算结果的展示，某银行的客户有着严格的标准： 表内所有数值右对齐，并且带千分符，如果是金额，保留小数点后2位。 除此之外，银行项目中对于最后结果表的展示，有两个显示需求：

6.1 空值显示为0

显示的格式与表元设置的类型一致，并且导出excel保持数值类型。这个需求需要配合服务器端计算后脚本实现：

6.2 图片温馨提示

所有分析表，如果计算没有任何结果，就显示一个图片温馨提示用户"无数据，请重新选择！

 

7. 钻取方式的统一和增强

萝卜青菜各有所爱，不同的用户，看数据的习惯也大有不同，有些用户喜欢形形色色变化多样的数据查看方式，还有些用户对于下钻的数据喜欢上看、下看、左看、右看。

某银行项目中的钻取有什么特点呢？

某银行项目中主要的分析维度是机构代码，客户希望各种业务指标按机构代码这个维表进行展开分析。

钻取函数zr()是某银行综合报表平台几百张分析表所用到的唯一钻取函数，几乎每张表都用。 虽然所有报表的钻取都只用zr()，但客户对zr()的函数要求特别地高：

7.1 【zr支持双向浮动】

通用版本的BI包，zr()函数是不支持双向浮动分析表的，为此开发增强了程序。

7.2 【支持展开全部】

既要支持层层展开，也要支持展开全部。 zr()是点击加号层层展开看下级数据，如何可以让所有加号瞬间展开直至叶子节点？通过脚本可以轻松实现。

7.3 【行列锁定的表也zr】

行列锁定的表也能zr支持层层展开。

8. 管理驾驶舱的各种规划

管理驾驶舱是整个某银行项目的"东方明珠"，分析的内容是领导关注的重要行业指标分析。管理驾驶舱，从分析的指标到最后展现形式，都是经过精心策划的，所以最后才能造成一定的视觉上的冲击。接下来，带领大家了解一下"追求BI之美"的道路吧！

8.1 感受页面的变迁

【登录页的风云变幻】 项目初期，界面设计的需求还处于一片混沌，客户自己也不知道具体要设计成什么样子，当时客户能提供的信息只有三个字"中国风"，这个范围非常广泛，是中国水墨？中国祥云？中国红？于是就开始了一条漫长的探索的道路： 水墨系列的设计稿

 

祥云系列的设计稿

 

最终版的设计稿： 右图就是现在某银行项目正在使用的登录页面，红色为主题，背景为某银行(总行)大楼

【欢迎页的一波三折】 设计元素"红"：登录页的设计经验，某银行的经典三色：红、白、灰某银行的logo设计、某银行的装修风格、某银行的官方网站，无不都是红白灰三色搭配。那么欢迎页的设计方向相对明朗了许多，至少在色调的选择上，不会再走那么多岔路。 红色为基调的初稿：

设计元素"企业文化"："好好工作，乐于奉献"是某银行行长的题字，也是某银行每一个成员的工作宗旨。系统欢迎页的设计，也不能少了这个文化元素，要抓住精髓。 企业文化指引下的"半成品"们：

设计元素"立体感、居中"：在多次交涉之后，客户不仅对系统的颜色、元素都有了明确的想法和要求，而且对每个按钮的设计都有了设计想法。欢迎页上通过各种按钮进入相应的系统或门户，每个按钮要突出显示，具有很强的立体感；不论欢迎页上有几个按钮，这些按钮永远是一字排开，并且居中对齐。 设计元素"权限"：大多数项目都会定制一个属于该项目的欢迎页(即，登录首页)，这些欢迎页主要是以静态页面方式实现，页面上的按钮个数、位置都是固定的。 某银行的欢迎页的设计思路有所不同，他们要将此平台打造成数据仓库系统，将多个系统的入口都集合到欢迎页，即欢迎页上有门户的按钮和其他系统的登录按钮。这个就涉及按钮的查看权限，每个登录用户可以看到的按钮的权限会有所不同，例如，系统维护人员有权限看到所有按钮；一般业务人员只能看到其中一个按钮。 欢迎页终于定稿：

【版面设计有样稿】 管理驾驶舱之所以能高效率的完成，这离不开明确的系统版面设计。管理驾驶舱系统版面设计已经明确到要几个按钮、每个按钮写什么文字。管理驾驶舱系统版面设计补充需求：TAB按钮居中、设计要有立体感、点击之后高亮显示。 Excel设计稿截图：

 

 Excel设计稿原件：见附件《某银行一期_管理驾驶仓.xlsx》

8.2 一致的规范 vs灵动的设计

看了某银行项目那么多的设计和规划之后，你的脑海是不是萌生了一丝顾虑？一致的规范是否会让分析表呆板而无趣？一致的规范是否会磨灭工程师们灵活设计的创意？ 非也！某银行的管理驾驶舱，就是伙伴实施厂商开发了他们精益求精的卓越设计。如图：

再看下图，是某银行管理驾驶舱的某分析表，你会发现他们巧妙的运用BI，实现了一个完美的报表呈现：

A：奇偶行间色 实现奇偶行间色方法有很多，配色方案也很多，但是设计一个合适而又漂亮的的配色方案，可不是那么简单的事情哦！ <#=CASE WHEN ROW()= EVEN (ROW()) THEN "#FFFFFF" ELSE "#EAEAEA" END#>； B：统计图排版 当我们还在为统计图的摆放排版发愁，他们想到了属性，不管报表编辑界面如何放置统计图，只要定义了精确的统计图位置坐标，计算后的统计图就可以放得整整齐齐，你想到了吗？

 

C：小标题下划线某银行管理驾驶舱的分析表，不管是表格还是统计图都有小标题，为了分析表的美观，标题下面需要设计红色粗线合适的下划线，他们想到了把表格的边框，画上了红色的粗粗的一笔，你想到了吗？

D：统一的预警方案 他们的预警简单、统一，预警的图片完全符合业务逻辑。三个不同颜色、不同方向的箭头，加上一个图片后缀的判断： <#=if(G7>=0,if(G7>0,"up.jpg","eq.jpg"),"down.jpg") #>

9. 总结

某银行项目，是项目设计与规划的缩影，没有高深的理论，没有奇特的妙招，有的只是脚踏实地，将规划落到实处的执行力。 项目设计的规划从哪儿做起？ 往大处说，需要对数据仓库进行规划，需要对BI分析表展示进行规划；往小处说，需要对每张数据库表的每个字段名进行规划，需要对每张BI分析表的计算参数名称进行规划。那么大致上，规划可以自底向上从以下几个方面着手： 底层数据库规划：规划数据仓库模型，创建一致性维度设计，建立数据字典。 主题规划：主题表的名称和标题，以及主题表的分类。 报表展现规划：报表风格（标题字体样式，表体字体样式，数据显示样式），报表代码和标题，报表的计算参数。 门户规划：门户展示内容、门户风格和样式的规划。 权限规划：设计机构和角色，设计统一可行的权限分配方案。 项目设计的规划，听起来很大，想起来却可以很细，项目设计的规划可以无处不在，应从点点滴滴做起。 同样手握一支笔，有人写出来的叫"书法"，有人写出来的只能称作"涂鸦"，问题的关键不在于那支笔，而是你拥有一双什么样的手。