您的位置：首页 > 数据库

业务系统中，报表统计功能如何组织--统计分析模块参考

2009-10-23 15:30 926 查看
http://topic.csdn.net/u/20090701/11/2599adb6-32ef-4688-9235-5015461a4a65.html

 

 

 

 

 不显示删除回复显示所有回复显示星级回复显示得分回复 [推荐]

讨论下：你碰到的业务系统中，报表统计功能如何组织





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


结帖率：100.00%

2

楼主发表于：2009-07-01 11:50:13
    在很多业务系统中，往往涉及报表数据统计的功能，这些统计功能往往根据不同的行业、不同的分析角度而进行，不过，其相同点都是对业务明细数据根据需求进行各种统计汇总组合。这些功能在业务数据量较少的前期，一般没什么性能问题，但随着时间、业务的发展，数据量越来越多，而之前的一些速度很快的报表功能会变得越来越慢。这些现象估计有比较多人员在实际中碰到，所以，现在想看看各位日常中是如何解决这种问题的，最好包括从明细数据的组织、报表结果的数据如何组织、功能架构的原理逻辑等一系列的角度说明下。
    另外，在数据仓库、数据挖掘等领域，数据量那么大，类似上述的现象问题又是如何解决的？

    欢迎大家将实际中的上述类似问题的解决方案分享下，谢谢！

ps:
  可用分不多，倾我所能了。
 
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

回复次数：41
 





ACMAIN_CHM

(acmain)

等　级：


2

9

#1楼 得分：5回复于：2009-07-01 11:58:05

建议网上搜索一下 OLTP, OTAP, ETL， 数据仓库的知识。 数据仓库和你所说的现在这种事务的操作数据库数据理今不同。

 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

精华推荐：如何使圆与矩形相交七点（益智游戏）





kjhzls

(kjhzls)

等　级：


#2楼 得分：4回复于：2009-07-01 20:42:24

是否能够再建立一个数据库。专门用于查询方面的工作。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

精华推荐：MySQL中进行树所有子节点的查询





hitexam

(威海的风)

等　级：


#3楼 得分：3回复于：2009-07-02 14:57:49

关注中~~~
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

精华推荐：还是上次那个问题（ACMAIN_CHM wwwwA, wwwwb等请进）





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#4楼 得分：0回复于：2009-07-07 16:40:39

1楼你误解我的意思了

我的意思是：
目前很多公司的业务系统，肯定有相关报表统计功能需求的，我想问的一般像这些功能大家平时都怎么去设计的。例如，某公司一个产品系统，一般都会在这个产品系统里附有按多个角度去“统计产品销售汇总”的统计分析功能，当产品记录、销售明细记录少时，直接对明细表进行统计，那肯定是没问题的，假如随着业务的发展，后来产品去到了几百万中，销售记录每天都有几千万条，这时，如果再像业务系统刚建立时直接对源明细表来进行统计的话，那这时肯定会大大影响这个产品系统的性能。

类似上面的案例，大家平时应该碰到很多，我就是想看看大家的解决方案？为什么要这样处理？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

精华推荐：★[其他数据库]大版版服(T恤)投票。投票截止时间2009-6-12 15点(至少80人投票才有效)★





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#5楼 得分：0回复于：2009-07-09 11:38:05

up
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP

精华推荐：如何使表中的某个域的值唯一？





hitexam

(威海的风)

等　级：


#6楼 得分：2回复于：2009-07-09 11:45:13

up！~
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ACMAIN_CHM

(acmain)

等　级：


2

9

#7楼 得分：1回复于：2009-07-09 11:50:08

引用1楼你误解我的意思了

我的意思是：
目前很多公司的业务系统，肯定有相关报表统计功能需求的，我想问的一般像这些功能大家平时都怎么去设计的。例如，某公司一个产品系统，一般都会在这个产品系统里附有按多个角度去“统计产品销售汇总”的统计分析功能，当产品记录、销售明细记录少时，直接对明细表进行统计，那肯定是没问题的，假如随着业务的发展，后来产品去到了几百万中，销售记录每天都有几千万条，这时，如果再像业务系统刚建立时直接对源明细表来进行统计的话，那这时肯定会大大影响这个产品系统的性能。

类似上面的案例，大家平时应该碰到很多，我就是想看看大家的解决方案？为什么要这样处理？

你的这个问题，已经是数据仓库的概念了。
我们是把数据从在线事务数据库中提取出来，形成data warehouse, 以供报表分析工具使用。在提取中设置不同的维度来实现。

所以仍建议你先看一下数据仓库的概念。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#8楼 得分：0回复于：2009-07-09 16:19:17

DW这个我弄过一段时间，是比较独立出来的了，
而我现在要问的，只是一些业务应用系统中一些业务简单的汇总统计功能罢了，难道一个小业务系统，也要专门去搞一个DW来处理，有点太过了吧？
奇怪了，难道你们平时的系统都没有统计功能模块的(例如一些统计报表之类的）？我只是想了解下你们平时在这方面怎么处理的，不会是为了一个系统中某个小统计功能而去搞个DW吧？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ACMAIN_CHM

(acmain)

等　级：


2

9

#9楼 得分：1回复于：2009-07-09 16:24:27

看你的系统有多小了。
如果你的客户不能忍受效率上的问题，则只能把数据预先提出来。

每天晚上跑个脚本，按照事先确定的颗度把数据整理出来，放到另外一个表中。这样早上用户上班的时候就可以进行分析了。

视情况而定，是否需要放到另外一个数据库中，分离的数据库会减小对在线事务数据的影响。
(以上的数据仓库中的一小部分概念，并不是让你去建一个真正的数据仓库)

至于，如果你的系统很小，直接在你的事务表中做查询用户可接受的话，那你当然可以什么都不用做。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#10楼 得分：0回复于：2009-07-09 16:30:15

呵，这样的回复才贴切嘛

你上面说了2种方案

但现在问题时，如果要考虑基于这个报表的汇总数据易于扩展呢（即从这个报表的汇总数据，很容易满足给其它一些统计功能利用）？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ACMAIN_CHM

(acmain)

等　级：


2

9

#11楼 得分：1回复于：2009-07-09 16:34:45

你上面说了2种方案


只说了一种方案啊。第二种是什么？

但现在问题时，如果要考虑基于这个报表的汇总数据易于扩展呢（即从这个报表的汇总数据，很容易满足给其它一些统计功能利用）？

这个问题在数据仓库中有提到，如何规则你的数据粒度。总之是要找一个平衡。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#12楼 得分：0回复于：2009-07-09 16:45:33

哈，你自己说了都不知道？

1、中间表保存

2、直接在事物表进行查询

但现在问题时，如果要考虑基于这个报表的汇总数据易于扩展呢（即从这个报表的汇总数据，很容易满足给其它一些统计功能利用）？

这个问题在数据仓库中有提到，如何规则你的数据粒度。总之是要找一个平衡。

这样的话，如果要考虑易于扩展的话，那粒度上来说，是不是选择最小粒度来进行保存比较合适？但这样的话，那数据记录数可能就很多（跟明细记录差别不是太大了）。

你认为呢？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ACMAIN_CHM

(acmain)

等　级：


2

9

#13楼 得分：1回复于：2009-07-09 17:19:43

引用
这样的话，如果要考虑易于扩展的话，那粒度上来说，是不是选择最小粒度来进行保存比较合适？但这样的话，那数据记录数可能就很多（跟明细记录差别不是太大了）。

当然最小的粒度就是原表的每条记录。但基本上没有这种需求。
这个你要先自己了解需要哪些维度，然后进行规划。
比如维度有 分店，日期，产品， 数据为数量， 则最小粒度为  (分店，日期，产品)

这个不可能靠一个贴子这种交流来完成设计，需要你的的用户来决定，有经验的BI设计师，会帮助用户考虑到一些东西并提出自己的建议，新手，则只能根据用户要求的来设计，一旦用户半年后提出新的需求要求更细的粒度，则会出现麻烦。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#14楼 得分：0回复于：2009-07-09 17:32:59

当然最小的粒度就是原表的每条记录。但基本上没有这种需求。

一般也不会这样做啦，肯定经过一定的转换的嘛
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#15楼 得分：0回复于：2009-07-09 17:35:13

比如维度有 分店，日期，产品， 数据为数量， 则最小粒度为  (分店，日期，产品)

这个不可能靠一个贴子这种交流来完成设计，需要你的的用户来决定，有经验的BI设计师，会帮助用户考虑到一些东西并提出自己的建议，新手，则只能根据用户要求的来设计，一旦用户半年后提出新的需求要求更细的粒度，则会出现麻烦。

这样看来的话，如果考虑到扩展性，则开始根据业务实际情况定义合适的最小粒度是很重要的咯？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





hitexam

(威海的风)

等　级：


#16楼 得分：1回复于：2009-07-09 18:04:48

版主~此贴可以设为推荐，让更多人参与讨论哦！
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ACMAIN_CHM

(acmain)

等　级：


2

9

#17楼 得分：1回复于：2009-07-09 18:47:10

应人民群众要求，推荐！
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





small_well

(小井(偶是菜鸟!))

等　级：


#18楼 得分：1回复于：2009-07-09 22:40:49

mark
听听大家的看法!
楼主所提出的问题,也是我所困惑的
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





gahyyai

(冰岛男孩)

等　级：


#19楼 得分：1回复于：2009-07-10 08:35:03

mark
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





soupred

(soupred)

等　级：


#20楼 得分：1回复于：2009-07-10 08:51:42

很经典 值得学习
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





why796056

(why796056)

等　级：


#21楼 得分：1回复于：2009-07-10 11:50:08

关注中~~~
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





xuejie09242

(散人)

等　级：


#22楼 得分：1回复于：2009-07-10 14:08:57

根据报表所需要的查询，首先要对数据库进行优化，如建立索引什么的。
对大型的表，可根据需要定时将数据从表中取出，放到另外一个表中，专门供查询用，不影响事务的进行。
数据量再大的话，可以定期从数据库备份数据到另外一个数据库，查询这个数据库了。
如果再大的话，那就用DM和DW，用专门的DTS工具抽取数据，进行重新组织和处理了，就是所谓的数据仓库系统了。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





czl923

(czl923)

等　级：


#23楼 得分：1回复于：2009-07-10 14:50:19

1、这些业务系统大多是分年度进行分析统计的
2、可以用动态表的方式，表名+年度 形式，每年一套；这样可以解决你性能的问题
3、如果表数据量过大的话，可以考虑下采取表分区的形式，这样性能问题可解决部分
希望对你有帮助！！！
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





liuya1985liuya

等　级：


#24楼 得分：1回复于：2009-07-10 23:39:14

你不会是想用别的解决吧，数据仓库这里数据量大，有几个是在业务层解决的，都是在DB层。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





trainee

(春泥)

等　级：


#25楼 得分：1回复于：2009-07-11 10:09:48

具体的项目,具体的分析
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





crskyp

(孤舟)

等　级：


#26楼 得分：1回复于：2009-07-11 18:10:26

mark
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





jiahehao

(风林火山)

等　级：


#27楼 得分：1回复于：2009-07-13 08:46:55

只能具体问题具体分析，没有一定之规。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





hbhgsy

(QQ熊)

等　级：


#28楼 得分：0回复于：2009-07-13 11:39:39

我倒是觉得现在要是有一种系统的解决问题的方法就好了。这个系统要具备这样几个功能：
1、收集数据。能够根据需要，方便的生成收集数据的页面。（带导出excel表格）（当然要有用户管理、授权的功能）
2、储存数据。
3、分析数据。

 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





xshlife

(D-J)

等　级：


#29楼 得分：0回复于：2009-07-13 12:07:52

该回复于2009-07-13 12:10:28被版主删除
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





marskbt

(marskbt)

等　级：


#30楼 得分：0回复于：2009-07-13 13:05:00

没研究过数据仓库，被迫把原来公司做的报表都改成PROCEDURE了，哎，改了我几个月…… -_-b
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ljf_ljf

(Mark Liang)

等　级：


#31楼 得分：0回复于：2009-07-13 13:53:10

引用楼主 vinsonshen 的帖子:
在很多业务系统中，往往涉及报表数据统计的功能，这些统计功能往往根据不同的行业、不同的分析角度而进行，不过，其相同点都是对业务明细数据根据需求进行各种统计汇总组合。这些功能在业务数据量较少的前期，一般没什么性能问题，但随着时间、业务的发展，数据量越来越多，而之前的一些速度很快的报表功能会变得越来越慢。这些现象估计有比较多人员在实际中碰到，所以，现在想看看各位日常中是如何解决这种问题的，最好包括从明…

楼主 看你讲内容就知道你走入了一个误区；
一个系统肯定有它能承受能力设计，在设计系统时候就应该对业务量和数据量有所评估。
当业务量和数据量开始飙升或者差不多超过系统能承受压力时候，我们必须改善或者修改系统架构来解决，不是增加一两个表就可以解决了。

当报表速度慢了，我们首先是检查问题出现原因。是SQL 不优化？还是系统数据量太大超过我们估算？是否服务器配置不好等等。
若SQL 不好，可以优化；若数据量太大，之前没有考虑数据量到，只能临时增加一些机制来快速解决，如：每个月对某些特定数据进行统计；若服务器不好，就要求买；出现问题原因很多；但可以总结为：系统使用初中期出现的问题，一般都是SQL不优化 和 对系统数据量评估不足。到了系统使用后期就是数据量爆炸性增加，系统需要修改架构。
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#32楼 得分：0回复于：2009-07-13 15:38:15

引用 31 楼 ljf_ljf 的回复:
楼主 看你讲内容就知道你走入了一个误区......

其实你后面提到的那些点，都是在我前面问的解决方案的一部分，你这些方面都是从大的角度去论述。
如果要细一点，我觉得可以如下：
1、物理组织上：
  分表（区）、同库、分库、分服务器等；
2、处理逻辑上：
  直接查询、采用一般固定式的中间表、采用基于数据仓库的数据中间表（易扩展）等；
3、其它：
  表字段数据类型优化、数据表关系设计优化、索引优化、SQL写法优化、硬件资源的优化、任务调度的资源均衡等;
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





vinsonshen

(阿呢陀佛,一切皆空)

等　级：


2

#33楼 得分：0回复于：2009-07-13 15:50:34

欢迎大家继续指点！

 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





hitexam

(威海的风)

等　级：


#34楼 得分：0回复于：2009-07-15 09:39:05

哎，目前我做的一个系统初期数据量不是很大，但日积月累那数据也是相当的庞大，系统如何设计好呢？
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





flairsky

(随便逛逛)

等　级：


#35楼 得分：0回复于：2009-07-15 10:41:38

一般按某一用户可变粒度在闲时生成报表，一般不会是即时生成。

报表嘛，肯定是落后于实际的。你如果要及时报表，那统计的数据是不完全的
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





cuijian0987

(cuijian0987)

等　级：


#36楼 得分：0回复于：2009-07-15 11:18:19

该回复于2009-07-15 11:29:17被版主删除
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





ljf_ljf

(Mark Liang)

等　级：


#37楼 得分：0回复于：2009-07-16 22:22:28

引用 32 楼 vinsonshen 的回复:
1、物理组织上：
分表（区）、同库、分库、分服务器等；
2、处理逻辑上：
直接查询、采用一般固定式的中间表、采用基于数据仓库的数据中间表（易扩展）等；
3、其它：
表字段数据类型优化、数据表关系设计优…

楼主：
这些内容都是一些固定的手法，具体方案选择要多方面来决定没有一个固定形式。

 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





mnyh11

(mnyh11)

等　级：


#38楼 得分：0回复于：2009-07-17 11:12:56

不错，学习了
 
对我有用[0]

丢个板砖[0]

引用

举报

管理

TOP





kisler

(kisler)

等　级：


#39楼 得分：0回复于：2009-07-31 07:48:35

我也遇到过相似的问题，其实我的解决方式很简单，楼主可以参考一下：以前的陈年老数据可以做一个数据库归档，归档方法很多，我是建立另一个库，将陈年数据放到新库里面，再在相关数据表上建一个分区视图，这样不影响用户的数据查询，报表统计的性能也提升了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签：  报表 数据仓库 数据库 chm 产品 优化
相关文章推荐
新的分享
章节导航