189 8069 5689
SAP BI 是SAP的智能商务(Business Intelligence)部分。2007年10月，SAP以68亿美元收购Business Object(BO)后，其BI部分较前有了很大的进步。
在仙游等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站制作、成都网站建设 网站设计制作定制网站开发,公司网站建设,企业网站建设,品牌网站建设,成都营销网站建设,成都外贸网站制作,仙游网站建设费用合理。
BI的主要功能是对积累的业务数据的分析挖掘。
BI包含以下一些编辑器和平台工具：
水晶报表-Crystal Report
水晶易表-Crystal Xcelsius
报表服务器-Web Intelligence
等。
BI的高级应用，会涉及到数据建模(DM-Data Modeling)和数据仓库(BW Business Information Warehouse)，这两方面网上有很多开放的资料。
随着SAP软件在企业的应用比重不断扩大，如何将SAP后台Oracle数据库中的数据信息导入到AO软件中供审计人员进行分析筛选是我们经常需要面对的问题。由于目前AO软件提供的数据导入模板无法覆盖到全部财务软件，使得在现场审计时经常遇到无法导入数据或导入数据需要做大量数据转换整理的情况，这严重影响了审计人员查处违法违纪问题及案件线索的效率。如何解决数据导入问题就显得尤其重要。
在某公司审计中，笔者所在的审计组在向AO软件导入企业财务数据备份文件时，由于内置财务数据模板与SAP系统备份不匹配，导致无法将该公司的财务数据导入AO软件供审计人员分析筛选。
经过分析研究，审计人员先将SAP系统备份导入到鼎信诺审计软件中进行财务数据整理，然后再将整理后的财务数据导出到excel表格中，最后将所得的excel文件导入AO软件完成财务数据重建。具体过程如下：
第一步：提取财务数据备份文件。利用鼎信诺前端取数工具dataget.exe，进入取数界面之后，点击确认进入SAP系统取数工具界面（如图1所示）。以SAP客户端的方式登录，并连接SAP服务器，选择所需的账套以及相应的会计年度，按照提示操作，将取得的财务数据保存到指定目录下，例如：C：\Documents and Settings\gwzhangjing\桌面\SAP（如图2所示）。
图1为鼎信诺前端取数工具界面。
图2为SAP系统取数工具界面。
第二步：将取得的财务数据导入鼎信诺审计软件。先创建对应的项目，并且登录该项目。然后，点击主界面右侧区域准备阶段中的“前端数据导入”，选择保存到指定目录中对应的财务数据备份文件，将数据导入到建好的项目中，完成账表重建（如图3所示）。
图3为前端数据导入界面。
第三步：导出excel数据表。对导入到鼎信诺审计软件中的数据进行整理，使审计人员能够对所需数据进行初步筛选，将有价值的财务数据导出生成excel表（如图4所示）。
图4为将数据导出生成excel表。
第四步：编制生成财务数据采集标准表。将从鼎信诺审计软件中导出的excel表，按照AO软件自带模板的格式进行转换，调整对应的科目名称生成科目表、科目余额表、记账凭证表、辅助余额表、辅助余额期初表等标准表，以便将其导入AO时顺利完成账表重建（如图5所示）。
图5为财务数据采集标准表。
第五步：将生成的数据采集标准表导入AO软件。在得到财务数据标准表后，依照AO软件的数据采集向导，逐步完成财务信息的重建，从而满足了审计人员对财务数据分析筛选的要求（如图6所示）。
图6为将标准表导入AO软件。
审计人员利用上述方法，对导入的财务数据进行分析，发现该公司向其下属公司违规出借资金问题，提高了审计效率，扩大了审计成果。
你说的这个问题有点难。根据你的描述，可以推知你的BADI的接口没有相应的你要取得地这些屏幕内容。
屏幕上的这些内容是用户在运行VL02N的时候手动输入的么？还是这些内容是系统根据某些条件自动显示出来的。如果是后者，那么你可以找到这些条件，根据相同的条件在你的BADI里通过Select或者FM取得这些数据。
36氪企服点评专家团——吕品
————正文————
BI 工具不是可以直接拖拉拽取数吗 ？为什么还要写 SQL 取数 ? 这是很多初次接触商业智能 BI 的朋友会提到的一个问题，因为在他们接触到一些 BI 市场或者产品宣传的时候，很多人就是这么来介绍BI 的。
简单来说，这个问题背后的逻辑等同于： 拿着碗和筷子不是可以直接吃饭吗 ？为什么还要自己动手做饭 ？有没有想过，即使是直接吃饭，饭总是要有人来做的吧，无论这个人是自己还是别人，“做饭”这个过程并不会少。
所以，从这个问题背后能看出来还是有很多人对于 BI 的理解还是存在一定的误区，我们可以从以下这几个角度来分析讲解一下。
可视化 BI
很多人对于 BI 的印象就停留在数据的可视化图表，但可视化图表只是 BI 的最终呈现，可视化的拖拉拽并不是 BI 的全部。
一个完整的商业智能 BI 解决的应该是端到端（ End to End ) 的问题，需要从各个业务系统的数据源取数，通过 ETL （ Extract 抽取、Transformation 转换、Loading 加载 ）的过程 将要分析的数据从规范的不可分析的、或不规范不可分析的数据最终变为规范的、可分析的形式 ，最终通过 BI 可视化拖拉拽的方式将数据进行有效的、带有逻辑性的组织形成可视化分析报表。
派可数据大屏可视化分析
而大部分的 BI 工具如果重在强调前端可视化的能力，这类 BI 工具的定位就是解决数据可视化分析展现的问题，属于 BI 前端可视化报表工具，但并不能代表 BI 的全部。
如何形象的理解 BI
如果把 BI 可视化实现的过程比作到餐厅出菜的过程，那就是：
数据源环节 vs 菜市场
从各个业务系统取数 —— 按照餐厅营业需求准备所需菜品的原材料，就需要到各个市场买菜。不同的业务系统对应不同的菜市场，不同的菜市场有不同的摊位对应的就是业务系统数据库中不同的数据表。摊位上的菜就可以理解为数据表中的数据，要分析什么就取什么样的基础数据。
数据仓库 vs 后厨仓库
数据仓库环节 —— 从各个市场买回来的菜堆在哪里呢？后厨仓库。有的菜是今天要用的，有的菜是明天要用的，所以先买回来堆起来。从各个系统抽取上来的数据也是如此，这些数据有的来源于 Oracle 系统，有的来源于 MySQL 或者 SQL Server，按照分析需求从不同的数据库抽取之后放到自己的数据仓库中集中管理起来。
ETL 过程 —— 厨师做个猪肉炖粉条不可能把整扇猪肉、一颗一颗的大白菜扔到锅里，一定是猪肉切片，大白菜去除坏掉的叶子，菜该切切，肉该剁剁剁。同时，还会备好一些辅助的佐料等原材料，最后把所有的原材料放到操作台上，这个就是备菜（ 择菜、洗菜、切菜 ）的过程。
数据也是如此，把数据从各个业务系统先 抽取（ Extract ） 上来，等同于把放在不同仓库格子的菜拿过来。数据要做 转换（ Transformation ） ，比如一些脏数据的处理、格式的转换、数据计算口径的统一、指标的计算等等，就如同洗菜、择菜、切菜的过程。最后将处理之后的数据按照一定的模型或者格式 加载（ Loading ） 到指定的可被前端调用的数据表中，就如同把所有备好的菜放到一起准备下锅。
报表可视化 Reporting vs 上菜
Reporting 报表可视化就是最后的呈现，也通常视为 BI 的前端，所以也叫做 BI 前端可视化。用户需要什么样的可视化报表，就如同用户点菜一样可以高度定制化，前提是基于已有的原材料（数据）。
派可数据大屏可视化分析
所以，大家可以看到从业务系统数据取数到最后的报表呈现实际上经历了很多的阶段。 在商业智能 BI 开发过程中，80% 的时间在处理底层数据（ 跑菜市场、买菜、运菜、择菜、洗菜、切菜到备好菜 ），20% 的时间在做可视化分析报表（ 做菜 ）。 底层数据的处理重点就是 ETL 过程，而实现 ETL 过程的主要方式就是通过 ETL 工具（ 例如：Kettle、Informatica、Pentaho、IBM DataStage、Microsoft SSIS 等 ）或其它 ETL 框架结合 SQL 查询语句、Stored Procedure 存储过程等方式来组织和管理数据处理的先后顺序。
特别是企业级 BI 项目建设，不仅仅是简单的 ETL 过程还需要涉及非常专业的数据架构设计、数据仓库建模、分层设计等数据仓库的构建，这里面最常用的开发语言就是 SQL。
BI 直接取数分析并不可行
很多 BI 工具会经常强调直连取数，这样就不需要写 SQL，直接通过表与表之间的关系进行表间建模，形成一个大宽表，文本类型的就是维度 Dimension，数值类型的变成度量 Measure，通过 BI 前端可视化进行拖拉拽操作形成很多 Ad-hoc Report 即席报表。
在实际演示案例的时候也是如此，最常见的就是一个标准的、数据格式极为标准规范的 EXCEL 表上传一下按照上面的方式来一遍；要么就是销售订单表和销售明细表关联一下，算算订单数量、订单金额等等。
其实验证一下 BI 工具的这种直连且拖拉拽的能力到底有多强非常简单，让业务部门提几个实际的分析需求，现场拿 BI 产品从实际的业务系统中取数来验证一下是否那么容易就明白了。
以下面一个小 DEMO 为例，可以使用任意的国内外 BI 可视化分析工具尝试一下当直连到这张表的时候，是不是就可以直接、任意的进行拖拉拽分析。
案例：统计外包业务的人工效率（时长）
背景：某金融公司把一部分贷款业务外包出去给第三方公司，第三方公司业务人员每与客户联系一次，就会根据沟通的状态记录一下，形成了以下的业务数据表 DurationTime，有以下三个核心字段：
ID - 客户的身份证号，唯一标识 ID
Operation - 一个操作记录，重点节点有 0034、0036、0048
Date - 一个操作记录的时间日期（实际上是时间，为了简化用日期表示）
业务系统中的原始数据表
计算规则如下：
1) 计算0034-0036，0036-0048，0034-0048的时间间隔。
2) 如0036之前没有0034，不可单独计算0036-0048的时间间隔。
3) 如0036后跟着多个0048，则取到最晚的一个0048的时间间隔。
4) 如0034后跟着多个0048，则取到最早的一个0048的时间间隔。
5) ....
实际的计算规则多达 20 多种，就以上面 4 条计算规则为例，最后的计算结果是：
Transformation 表
为了得到上面的最终结果，通常往往会创建一些中间转换表，用来记录转换的过程，便于检查和纠正逻辑，这种表我们通常叫做 Transformation 表。
业务系统中的原始数据表的数据规范吗 ？非常规范。但是适合分析吗 ？并不适合。所以在 BI 分析之前要做什么？ 那就是写 SQL、ETL 取数，把这种在业务系统中规范的不可分析的、或不规范的不可分析的变成规范的、可分析的数据格式 —— 结果表。
在实际的 BI 项目开发过程中，来自各个业务系统数据源的数据大部分情况下就是一种不可直接分析的状态，与分析思维不同，他们是描述业务过程的。
还会有一种说法是：可以直连业务数据源，通过写 SQL 查询一个数据集再通过前端 BI 可视化分析工具来呈现做可视化分析报表行不行？ 我们的建议是，除了以下几种情况，不要这样做：
第一，这类可视化分析报表基本上就是一次性的，一年可能就改不了几回。
第二，本身数据量不大，使用频率也不会非常的高。
原因在于： 没有合理的建模、指标计算复用性太差、影响业务系统性能、无法应对后续日益增长和不断变化的业务分析需求，按照这种方式做的 BI 基本上不会超过两年就会面临推翻重做的风险。
所以，在使用 BI 的时候，不管是直连业务系统数据源的表进行表间关系建模，还是通过写 SQL 查询数据结果集的方式直连业务系统，在大多数情况下都不合理，BI 开发人员应极力避免采用这样的数据操作方式，这些还都是在没有涉及到多异构数据源取数、主数据档案不一致、组织架构缺失补位、缓慢渐变维度等问题的前提下。
BI 直接取数分析什么样的情况下是可行的 ？
也有朋友说到，我们公司就是直连数据库取数做可视化分析的。我们让朋友回去问了一下，原来连接的是企业已经构建好的数据仓库。在这种情况下，底层的数据模型相对比较标准，数据也经过了非常良好的格式转换，可以直接使用一些前端 BI 可视化分析工具进行快速的分析，这样的一种搭配就非常好。
所以，BI 直连数据库不是不可行，但得分清楚直连的是业务系统的数据源数据库，还是直连的是已经通过 SQL 从业务系统的数据源取数和建模处理后的数据仓库、数据集市。
派可数据自助开发平台包括数据仓库与BI可视化分析
IT 和业务的边界就在这里，IT 负责底层数据建模、数据仓库的构建，业务基于已经建好的基础分析模型通过 BI 前端可视化分析工具来进行拖拉拽的可视化分析操作。 倘若是这样，也确实实现了不通过 SQL 取数使用 BI 前端工具就可以做报表的目标。但绝对不能认为，不通过 SQL 取数就可以对接任何业务系统数据源做任何 BI 可视化分析。
所以，当一家企业底层已经有架构非常良好的数据仓库，这个时候使用一个轻量的 BI前端可视化分析工具基本上就够用了。但如果所在企业底层还没有良好的数据仓库系统，只寄希望单纯的使用一个 BI 前端可视化报表工具解决一切分析问题，这个时候就需要认真思考一下是否可行。
原文标题：《BI 不是可以拖拉拽取数吗？为什么还要 SQL 取数 ? | 专家视角》
作者： 吕品
本文来源于36氪企服点评