Informatica开发规范1.0.doc

informatica开发规范版本：1.0日期：2011年10月25日单位：康时信息系统有限公司 目录1.前言42.简介53.应用架构63.1.overview63.2.architecture63.3.体系架构74.物理部署114.1.准备工作114.2.安装与配置124.3.资源库管理125.命名规范(name citerion)145.1.database connections 命名规范145.2.目录(folder)命名规范155.3.源/目标(source/target)命名规范155.3.1.数据表155.3.2.平面文件165.4.组件命名165.5.其他命名176.开发规范186.1.etl需求分析196.1.1.业务需求分析196.1.2.功能需求分析216.1.3.性能需求分析236.1.4.运行需求分析236.2.源(source)设计236.3.目标(target)设计246.4.mapping设计256.4.1.注意事项256.4.2.源对目标的映射266.4.3.mapping功能设计276.4.4.mapping 组件设计276.4.4.1.lookups276.4.4.2.filter286.4.4.3.aggregator286.4.4.4.joiner296.4.4.5.其他组件296.5.workflow流程设计306.5.1.主要工作306.5.2.workflow 设计306.5.3.workflow monitor316.6.测试336.6.1.测试点分析336.6.2.etl测试方法346.7.系统管理356.7.1.用户管理356.7.2.系统调优366.7.2.1.target调优376.7.2.2.source调优376.7.2.3.mapping调优376.7.2.4.session调优386.7.2.5.系统调优396.7.3.环境发布406.7.4.系统迁移备份406.8.etl问题处理417.附录431. 前言文档控制 本文件的目的仅为提供信息，并不构成任何合同或具法律约束力的文件的基础。康时公司发布的这份文件并不保证内含信息是否正确或者是否将保持正确，也不保证使用其中的信息将确保对相关服务或设备的操作正确无误。文件内容如有改动，恕不另行通知。修订历史版本号日期作者说明1.02011-10-25隆玉玲informatica开发规范初稿参考文档文档目录版本说明oracle standardsoracle standardshp9000 setuphp9000 server安装说明informatica powercenter7基础培训informatica安装指南与简单操作informatica 开发过程描述informatica 开发描述2. 简介本文档用于定义数据仓库中informatica应用开发过程所作的规范要求。它详细阐述了开发人员所涉及的informatica任务与管理，包括物理部署、资料库管理、开发过程、流程设计、性能优化等。数据仓库开发人员在开发过程中需要按照这些要求来规范自己的开发操作，加速技术实施，实现多个项目开发人员之间协同合作，保证开发出高质量的开发成果。我希望在这里给大家抛砖引玉，大家总结出dw项目的更多管理规范、更多产品的开发方法以提高你我。3. 应用架构3.1. overview这节将概述informatica一般的应用架构，架设在unix 操作系统上的应用。informatica etl（extract transaction and load）可以分为三部分，即抽取（extract）、转换（transcation）和加载（load） 客户端服务器 unix 应用架构类型n 应用通过shell脚本发送请求到informatica 服务器n informatica 服务器接受应用请求，并返回执行日志 应用maestro计划发起批处理，优于informatica计划3.2. architectureinformatica可有多种架构方式：informatica运行在相同server上，或应用服务分布在远程服务器，或应用数据库分布在远程服务器上。建议： 一个server主部署informatica,repository server 和应用系统环境.应用数据库可以部署在本地或远程服务器上3.3. 体系架构此部分介绍了 informatica etl 工具包括的主要内容。(informatica powercenter 体系结构图) client informatica client 主要有五个部分。 client 可以和 repository 分离，通过 tcp/ip 连接，连接到远程的 repository server 。 repository manager 主要用于进行一个 repository 库的管理，当用户使用 client 工具登录一个 repository 服务器之后，进行文件夹权限的创建，用户权限、密码的管理等。 designer 主要是进行数据抽取的转换工具的设计，主要是 mapping 的设计、设计源数据库的结构，目标数据库的结构，然后设计把源数据导入到目标数据库中，所需要进行的转换操作（ transformation ）。 同一个 repository 的 folder 之间可以建立 shortcut 方式，多个 repository 的 folder 之间只能做拷贝。 workflow manager 主要用于流程任务（ workflow task ）的设计。 进行任务流程的设计、每一个 tast 针对一个 session ，一个 session 针对一个 mapping ，其中 workflow 中的 folder 和 designer 中的 folder 相对应的关系。一版来说，用户都是建立自己的 folder 。 workflow monitor 主要进行流程运行、及任务运行时的流程运行情况跟踪。可以跟踪日志。包括 session 日志和 workflow 日志，可以设置生成日志的循环个数。分析 session 运行是对源数据库的数据抽出信息和对目标数据库的更新信息。 repository server application console 主要进行 repository 的管理，包括 repository server 的 start ， shutdown 操作。进行 repository 库的 backup 、 restore 等操作，进行 repository 库级别的管理，级别较高。 repository server repository server 是为客户端服务的，客户端可以和各种 client 不在一台服务器上。关于数据抽取的设计成果转换成为 xml 格式的源数据，都是通过 repository server 存放到 repository database server 上的。 repository database server 用于存放的是进行 etl 设计的元数据。可以支持各类的数据库。方式为数据库中用户的一个表目录和用户关系即可。 repository database 可以和 repository server 不安装在一台服务器。如果在一台机器上， server 通过 native 方式连接到 database ，如果不在一台及其上，需要在 database 上安装一个 repository agent ，用户通过 agent ，以 native 方式连接到 repository 数据库，然后 repository agent 再以 tcp/ip 方式连接到 repository server 。 informatica server informatica server 是实际执行数据抽取任务的运行环境。即 workflows 、 task 、 sessions 等。它是根据定义的 workflow 元数据库，然后在自己的实际环境中，执行数据抽取操作。4. 物理部署 系统部署时要准备的文档主要包括informatica 硬件安装配置手册、informatica软件安装与配置手册、informatica系统移植手册、informatica系统操作规范与维护手册等。4.1. 准备工作安装环境要求 ：powercenter clientrepository serverpowercenter repository databasepowercenter server操作系统windows(98, 2000,2003, xp)windows(2000,2003)unix(aix,hp-ux,linux,solaris)windows(2000,2003)unix(aix,hp-ux,linux,solaris)windows(2000,2003)unix(aix,hp-ux,linux,solaris)磁盘空间200mb80mb150mb70mb内存256 mb256 mb128 mb256 mbi数据库连接odbc驱动native驱动i native驱动native,odbc驱动数据库要求：1. 在安装informatica服务的主机上，要提供连接到关系型数据库的native driver（数据库的客户端）。2. 在对应数据库中，创建一个数据库用户用来保存informatica repository。分配给该用户适当的权限，例如：针对oracle数据库，创建一个新用户，分配connect, resource权限即可；针对sql server，创建一个新的数据库和用户，用户的密码不能为空。4.2. 安装与配置主要工作：详细参考informatica安装配置手册1. 创建和配置unix客户2. 安装informatica两个服务3. 配置powercenter server 4. 更新license file 5. 在unix下启动repository server： 6. 关于客户端操作和配置7. 在unix下启动powercenter server：4.3. 资源库管理通过客户端 repository server administration console 创建资料库，整个资源库的维护操作，如资源库的创建，备份，恢复，升级等。 注意事项： 在资料库的管理过程中，由于各种原因，需要重起资料库服务时，需要通知各位相关人员并在重起时同时重起informatica服务。 启动某一reposotory时，确保它所连接的数据库服务也是启动状态。 folder的建立，由管理员根据业务需求建立，并对其进行授权。建立与用户同名文件夹，并设置该文件夹的owner为该用户，且设置其它用户及组只有读权限。主要操作： 添加、编辑，删除知识库配置信息 导出和导入知识库配置信息 创建知识库 拷贝知识库 从数据库中删除知识库 备份和恢复知识库(backup, restore) 启动、停止、启用和禁用知识库 发送知识库通告信息(notify users) 查看知识库连接以及对象锁信息 关闭知识库连接 注册和删除知识库插件 升级知识库(upgrade) 将local知识库升级到global知识库(make global) 注册到global知识库中或者取消注册(register, unregister) 更新知识库主域连接信息(propagate)5. 命名规范(name citerion)命名规范设定了informatica开发过程中各个阶段或者模块所产生信息的命名标准。5.1. database connections 命名规范在项目开始阶段，将使用这个规则定义源数据库和目标数据库的连接。命名规则与数据库的类型相关： 通用数据库源源数据库管理员提供唯一的限制权限（select）用户操作所有客户端应用 客户化数据库源源数据库管理员提供一个客户化的限制权限（select）用户来操作一种客户端应用和数据权限 源/目标数据库源命名规则：类型命名db 用户权限通用源_read_read or db user provider by dba for all applicationsselect客户化源_read or db user provider by dba for one application needsselect源/目标_mgrselect, update, insert, delete注意事项：多层应用（eg.ods数据库和 dw数据库），则应使用源/目标 方式命名。5.2. 目录(folder)命名规范命名一般根据其业务和技术应用命名规则：_. 除此参考则为_ref；维度为_dimtechnical / functionalrevenueshipmentfunneldata hubalz_hub_revalz_hub_shpalz_hub_fundata storealz_ods_revalz_ods_shpalz_ods_fundata warehousealz_dwh_revalz_dwh_shpalz_dwh_fundata martalz_dtm_revalz_dtm_shpalz_dtm_funreferentialalz_refdimensionalz_dwh_dim注意事项：取消目录的默认属性选项：allow shortcut，如果不关闭它，在目录中会产生很多关联，不利于以后的交付5.3. 源/目标(source/target)命名规范5.3.1. 数据表数据库表的结构和命名都根据其导入的数据库的结构注意事项： 如果mapping导入几个表则命名规则根据业务描述而非数据库表名。operation typenamedeletedel_tablenameinsertins_tablename5.3.2. 平面文件 命名规则：file_例如 ： file_xp2revenue5.4. 组件命名组件命名规则 aggregatoragg_transformationnameapplication source qualifierasq_transformationnamecustomct_transformationnameexpressionexp_transformationnameexternal procedureext_transformationnamefilterfil_transformationnamejavajtx_transformationnamejoinerjnr_transformationnamelookuplkp_transformationnamemq source qualifiersq_mq_transformationnamenormalizernrm_transformationnamerankrnk_transformationnamerouterrtr_transformationnamesequence generatorseq_transformationnamesortersrt_transformationnamestored proceduresp_transformationnamesource qualifiersq_transformationnametransaction controltc_transformationnameunionun_transformationnameupdate strategyupd_transformationnamexml generatorxg_transformationnamexml parserxp_transformationnamexml source qualifierxsq_transformationname5.5. 其他命名组件命名规则 mappingm_transformationnamemappletmpl_transformationnameworkfloww_transformationnameworkletwkl_transformationnamesessions_transformationnametaskt_transformationname6. 开发规范数据仓库informatica开发规范定义了整个etl的开发流程，流程图如下：目标（target）设计源（source）设计正式加载上线及每日检查workflow 流程设计系统管理开发事务管理etl需求分析mapping设计6.1. etl需求分析作为技术的重要部分，第一要务就是清晰和侧重客户的业务需求，对于决策和业务流程这需要决定哪些信息是重要的和必须的，这也是项目成功的关键。6.1.1. 业务需求分析主要工作： 定义业务规则 数据范围 约束依赖条件 输入输出 业务分析矩阵建议需求分析使用模板如下 etl业务需求矩阵business requirementfunctional requirementpriority1.data from log files and the application database will be extracted and distributed into central repository.11a.the central repository will be a flat file database.11bthe data in the central repository will be partitioned by cluster, time period, portal and merchant such that the data will be readily accessible by reading the fewest number of rows.11c.data from the log files will be gathered from each cluster machine and distributed into central repository.1 etl业务详细需求模板business requirementdata from log files and the application database will be extracted and distributed into central repository.constraints1. the log files will be transported from each cluster machine and placed in the repository. 2. the application server must be available for data extract.inputshourly log files from the cluster processing machines.tables from the application database server.outputsflat file database built from the log files and tables using a hierarchical directory/file structure.dependencies1. each processing machine in each cluster will correctly generate the log files.2. the log files will be transferred to the repository machine intact.3. the database is operational.hardware / software requirementscentral repository machine: sun e4500, 4 cpu, 4gb ram, 70 gb hdd. sun solaris 2.6powercenter will be used to extract data from the application database.perl scripts will be used to extract data from the log files. etl主题需求分析模板net revenue revenue after subtracting operating costsdimensional views: below are the views in which net revenue can be analyzedtime- year- quarter -month -fiscal year -fiscal qtrgeography- region- district- citycustomersubject areadimension setmetricssales analysistimegeographycustomernet revenuegross margin6.1.2. 功能需求分析extraction 需求： 数据源的支持：支持目前市场主流数据库，如oracle、db2、mysql、sqlserver等和greenplum的数据源配置和数据抽取 抽取规则：对源数据可进行规则清洗配置，可以按条件抽取数据transformation需求： 数据流程的控制：具有可视化的流程编辑工具，提供流程定义和流程监控功能。 流程定义：具有可视化编辑工具，支持数据流的拖拽，目标表的数据结构可根据源表和对应关系自动生成 流程定义扩展：提供接口可进行扩展开发，支持系统日期、规则名称等变量传递，按规则自动生成流程定义 转换规则定义；提供函数集支持常用规则传唤方法：1、 直接映射，数据源与目标数据一致，如果数据源字段和目标字段长度或精度不符，需要注意看是否真的可以直接映射还是需要做一些简单运算。2、 字段运算，数值型字段，数据源的一个或多个字段进行数学运算得到的目标字段，如sql标准中的sum,count,avg,min,max等3、 参照转换，在转换中通常要用数据源的一个或多个字段作为key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。4、 字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。5、 空值判断，对于空值的处理是数据仓库中一个常见问题，对于可能有null值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，建议是将它转换成特定的值。6、 日期转换，在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。7、 日期运算，基于日期，我们通常会计算日差、月差、时长等。8、 聚集运算，对于事实表中的字段，他们通常要进行join、union、filter等操作，9、 既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值。loading需求： 支持常见数据库的导入工具方式上载数据，主要一定要支持greenplum的gpfdist方式并行导入 gpfdist方式导入数据的参数输入可以手工指定 流程控制：具有可视化控制工具，支持工作流程开发，定时执行，错误重试等 流程监控：具有可视化监控工具，错误报警etl业务需求矩阵模板：functional requirementprioritypage reference1a.the central repository will be a flat file database.11bthe data in the central repository will be partitioned by cluster, time period, portal and merchant such that the data will be readily accessible by reading the fewest number of rows.16.1.3. 性能需求分析 整体etl性能，千兆网支持，硬件配置足够的情况下(瓶颈不在cpu、内存、磁盘i/o)，数据etl到greenplum至少达到10m/s 整体etl性能，数据从greenplum到其他数据库，保证瓶颈在对方数据库上，即gp的reader性能大于其它数据库的writer性能6.1.4. 运行需求分析 操作系统环境至少支持linux redhat5.4或以上，suse linux 10.2或以上版本6.2. 源(source)设计主要文档：数据源分析文档（前期的分析） 源的表 每个表字段属性 记录数 数据质量分析source设计模板tableschema/ownerselect/filterfieldsdatatypepkis nullsource导入 关系数据库：采用odbc方式读入元数据，且元数据放置位置与odbc命名有关，本地odbc命名需与服务器相同。对于各用户，odbc命名采用：用户名_source（例：mm_source）。odbc须采用与服务器相同的版本。oracle客户端也须与服务器采用相同版本。 文本文件：采用flat文件导入方式，flat文件的规范为，第一行为各字段名，第二行开始为数据，各数据间的分隔符为tab键。一个通常的做法为，在excel表格中填入所有数据，直接拷贝至文本中，此时分隔符自动为tab键。文本文件的服务器位置，在服务器上分别建立各模块文件夹，各文本文件按模块放置于相应的文件夹内。文本文件命名为目标表名6.3. 目标(target)设计主要内容：目标设计文档 源的表 每个表字段属性 建议采用建模工具sybase powerdesigner 或ca erwin dba 参与目标表的设计：目标表的设计： 维表和事实表的开始时间和结束时间。 事实表的约束 索引影响性能： disable delete enable create loader注意事项： 维表是否要保留所有的历史记录？ 要历史数据：主键，开始和结束时间。 不要的：保持最近的 缓慢变化维目标设计模板tableschema/ownerupdate/delete/insertfieldsdatatypepkis null目标表导入 存在同样的三种方式：关系数据库、文本文件、xml文件。 target的元数据管理与source方式有所不同，其统一放置于targets下，与本地odbc命名无关，需要导入的目标表名唯一。6.4. mapping设计mapping 是etl 设计的开始，是具体的etl 规则设计，它包含三方面的信息：数据源信息、转换信息、目标信息。在mapping 中，主要工作就是转换。informatica powercenter 提供了20 多种组件，100 多个转换函数，基本上能够满足正常的需求；另外还可以调用外部的存储过程等。6.4.1. 注意事项 开发易使用性。 避免个性化的发挥及过于复杂的组件设计。 制定并遵守开发规范： 模块中尽量不要有多余的字段，没有向下流出的字段尽量删除。 只属于input型的字段，应去除其o选项；同样只属于output型的字段，去除其i选项。 模块中出现需计算的数值字段，其输入默认值设为0（default value）。这些字段类型大小统一改为decimal （206），由于计算的精度不同会造成数值得高精度误差，故统一计算精度大小，可以避免该错误发生。 用户在模块中手动添加的字段，input型的字段，添加前缀input_，output型的字段添加前缀output_。 seq模块在作为公用模块时，即make reusable时，设置其number of cached values为1。 汇总模块的数据输入最好在之前放一个排序模块对数据进行先排序，并选中汇总模块的sorted input选项。 由于建缓慢变化维产生的temp表，应在完成后及时删除。6.4.2. 源对目标的映射首先在设计时我们要明确每个mapping的源、目标，指定对应文档target attributetarget datatypedefault valuemapped to data source file/field namesource datatypecomments/detailed transformation rulesdate changed (if not in orig. load)6.4.3. mapping功能设计明确每一mapping 的详细功能设计mapping名称mapping描述源类型目标类型抽出记录数入库记录数etl执行周期etl前处理工作etl后处理工作错误处理机制重新装载机制源主键6.4.4. mapping 组件设计6.4.4.1. lookupslookups 设计模板：lookup nametablelocationmatch condition(s)persistent / dynamicfilter/sql override lookups 设计建议： 对lookup对应的字段增加索引，特别大型的lookup表能有效提高效率 lookup条件首先应用(=)运算符，再应用其他运算符 当lookup数据量小的表时使用缓存 尽量在数据库级别关联表 静态lookup数据表可应用固定lookup缓存6.4.4.2. filter执行条件过滤filter 设计建议： 在从源到目标的mapping数据流程中，尽早使用filter组件，把不需要的列过滤掉 尽量使用source qualifier过滤数据，因为source qualifier是当读取source数据时就过滤掉，而filter组件是对target数据时过滤数据 当非关系型数据过滤时，需要使用filter组件6.4.4.3. aggregator aggregator: aggregator组件：基于多行记录的汇总计算，如：取平均值或总和。用该组件可实现 增量汇总(incremental aggregation)、条件汇总(condition aggregation)等特殊的汇总功能。aggregator 设计建议： 首先应用sorted端口，以降低aggregator缓存的需要 尽量限制输入/输出端口数，减少无用字段的选入 aggregator之前进行filter操作6.4.4.4. joiner joiner: 关联异构数据源joiner 设计建议： 实施数据库级的joins 指派源时，以较小的数据表作为主表 选择最好的运算规则，从两种方式中试选择6.4.4.5. 其他组件 expression: informatica提供了转换语言来编写表达式，该语言类似于sql，功能丰富。expression组件：实现基于单行记录的表达式计算。 router: 按照条件分组来过滤数据 sorter: 基于键字段进行排序 update strategy: 允许逻辑的插入, 更新, 删除, 或拒绝 sequence generator: 产生一组唯一的序列编号6.5. workflow流程设计6.5.1. 主要工作 session建立 如果mapping中存在数值计算，则需要在其session的属性页选中enable high precision（允许高精度计算）。 worklet建立 应尽量把业务相关的几个session建为一个worklet，统一调度。 workflow建立 workflow中应尽量少的出现直接的session，把一些相关性的session统一作为worklet，在workflow中调用。 workflow monitor监控监控workflow和session运行情况，生成详细的工作日志及统计报告。整体流程设计建议： 知道哪个 folder 的作业量情况。（见数据量的估算文档） 根据系统资源，合理规则大小作业的串或并行。 共享的 session session 都是共享的，供专门的整体流程的管理员来调用。 可复用的 session 拖拽到workflow 中是实例，也可以有自己的属性。 便于测试，建立各自的 workflow 便于使用参数文件：folder.session6.5.2. workflow 设计workflow名称workflow描述itemitem namemapping namesource nametarget nametaskssessions6.5.3. workflow monitor 创建workflow并运行 调出workflow monitor 客户端工具 . gantt chart 显示模式(gantt chart 显示模式) 任务显示模式(任务显示模式) session 组件运行统计报告(组件运行统计) 获得session日志(session日志)6.6. 测试6.6.1. 测试点分析etl常规检查： etl脚本是否有运行错误，脚本运行时间(看执行计划) etl脚本的错误处理机制是否完整(代码review) etl脚本是否支持回滚 业务逻辑检查： 数据量的检查。核对记录数是否和预期一致 唯一性检查。主键是否重复(cookie_id,member_id是否重复) 业务字段转换正确性检查。指标计算是否正确.抽样检查。 源表和目标表各取一定数量记录，判断字段映射是否正确(映射字段)。 指标计算是否正确(指标计算字段) 随机性验证(随机取几条数据，看是否有乱码，异常数据等。 测试重点 项目中的关键业务，复杂逻辑部分作为测试重点 用例划分说明: 按每个指标设计用例。 测试策略： 测试策略：增量测试(逐步提交测试) 测试方法：有代码review（如procedure 中的where条件检查等），边界值测试，错误猜测方法，etl的粒度和任务调度检测，特殊值测试，空值的处理、异常数据，异常数据可以从下面几个方面进行考虑：字段类型、字段长度、空值、业务异常值、唯一约束值等等。 6.6.2. etl测试方法我认为测试工作可以分为四步，但是这个方法有一个前提，需要一个完善的指标逻辑etl mapping文档：1、 自测：顾名思义，这个工作就是自己对所开发的etl程序进行测试，选取一定的测试数据，这部分测试数据一般都是自定义的数据，然后根据这些数据运行etl程序，看是否能得出想要的结果，这个测试一般是伴随着程序开发工作进行的，也就是说，在开发工作完成后这个自测工作也应该同时完成，如果没有通过自测的开发在我认为是没有完成的开发，这部分的测试主要是以特例数据为主，挑选一些特例数据，比如特定维度下的数据。2、 单元测试：这个测试是一个大数据量的测试，需要一个完整的测试环境数据，这样，既能验证程序逻辑的正确性，同时，还能找出一些数据质量的问题，这部分的工作需要客户的配合，需要客户提供一个完整的测试环境，最后形成单元测试测试文档，将指标的逻辑描述清楚，并且将源数据和结果数据保存文档，如果数据量太大，可以挑选其中的一定数据量，如10000条3、 交叉测试：交叉测试的工作跟单元测试是一致的，只不过是交换测试人员而已，比如说，让开发人员a来测试b的程序，让b来测试c的程序等等，这样的测试有一个好处，就是可以思维的发散，避免同一个人既开发又测试造成对指标逻辑理解的局限性，最后也保留测试文档，但是这个测试并不是必须的，具体看项目情况，如果时间和资源允许的话可以进行，能找出一些bug，对程序的健壮性和最后的集成测试有帮助4、 集成测试：这个测试实际上是作为最后交付给客户的测试依据，etl测试工作是否完成是以这个测试来作为判断依据的。集成测试又可以分为两步：第一、与前端报表组的集成测试，主要是由etl开发人员根据前端需要的逻辑编写sql语句，直接到后端表中查询的结果，然后跟前端报表产生的结果进行核对，看看前端报表展示是否存在问题，这个工作可以跟报表组共同完成。第二、让客户提供一个完整的测试数据，并且提供根据测试数据他们需要得出的结果数据，这个工作可以由客户来做也可以由项目组成员来做，具体有谁进行测试需要看数据的保密程度和客户的需求来看，建议由客户跟项目组成员一起完成。6.7. 系统管理6.7.1. 用户管理 informatica开发分为2类用户组administrator和public即可，虽然权限很多，划分用户组很灵活，但2类用户组已经够用，具体分组标准视项目开发复杂程度而定。administrator用户不宜多，2个足矣。系统成功移植后public用户组最好disable掉。用户组个数建议执行功能分配备注administrator2个workflow operatorbrowse repositoryuser designeruse repository manageruse workflow manageradmin repositoryadmin integration servicesuper usermanage connectionmanage labelmanage folderdeploymanage deployment groupadmin用户建议只进行infor