Rya*_*yan 17 business-intelligence
我真的不明白商业智能是什么。如果我从拥有公司数据库开始,那么 BI 人员会做什么?我在网上找到了很多资料,但通常有点太复杂了。我想要一个简单的例子,让我了解 BI 的全部内容,以及 BI 人员会产生什么对我的组织有价值的东西。
Tho*_*ger 19
商业智能通常与数据库管理和数据库开发完全分开。最高级别的商业智能包括三个主要方面:
报告
报告是报告的创建、部署和管理以及用户动态自定义报告的附加功能。
一体化
数据集成和转换解决方案。在非常简单的水平,这是提取,转换和加载数据到数据源,从数据源(其可以是任何东西一样简单平面文件)的装置。集成是一英里深,但这是它最基本的功能。
分析
在线分析处理 (OLAP) 用于设计、创建和管理包含从源数据存储聚合的数据的结构。对此的一个口号是数据挖掘。
这些是对商业智能所包含内容的极其简化的描述。BI 以及这些方面的每一个背后都有一门科学。数据库专业人员将他们的时间和职业奉献给掌握这些。
Con*_*lls 12
该值在很大程度上取决于单个组织及其要求。根据所需的复杂程度,BI 角色可能分为几个不同的类别:
电子表格工作人员 - 从直接从操作系统中提取的数据集工作,此角色将使用 Excel 或 Access 等桌面工具生成报告和分析。通常,这个角色不是 IT 专家,或者可能由某人兼职。根据他们的技术水平和对底层数据库的访问,他们可能依赖其他人员(例如数据库管理员)来生成数据提取。
当捆绑的报告不满足要求并且需要额外的工作来从数据库中获取管理信息但专门的 BI 开发团队成本太高时,这个角色会带来价值。通常这个角色在所有情况下都是必要的,尽管在小型站点上可能没有全职要求。
BI Developer - 如果数据提取很复杂或需要从多个来源集成,则可能需要构建数据仓库或其他报告系统以集成可用于报告的格式呈现数据。担任此角色的人员通常或多或少具有技术开发技能。
通常,这种类型的团队会被分为 ETL 和报告功能,但情况并非总是如此。报告开发人员、“电子表格 Jock”类型和其他高级用户可以通过各种工具使用来自报告系统的数据。
当数据过于复杂而无法使用临时方法进行管理并且需要专门的报告系统时,该角色的组织价值就会实现。在这种情况下,具有技术技能和适当工具的小型 BI 团队可以自动化大量工作,否则这些工作将使用桌面工具和临时提取手动执行。数据仓库系统还可以填充自助式报告工具,例如 OLAP 多维数据集,允许企业内的最终用户生成和维护他们自己的报告。
数据架构师- 一个成熟的数据仓库系统将提示来自业务的数据需求,而这些需求无法用源系统中的可用数据来满足。可能有必要协调由这些要求驱动的对操作系统的更改,以便捕获额外的数据或清理在源头不一致或错误记录的数据。
数据架构师可以担任跨多个操作和报告系统的角色,以协调需要跨多个系统进行更改的数据需求的实现。
对这个角色的需求通常不被认可,但它在较大的站点上变得很重要。通常,操作系统不能很好地满足报告要求,并且数据仓库团队的权限不会扩展到对操作系统进行更改。在这种情况下,数据架构师根据角色的权限级别充当协调员或主管。主要价值是对不满足数据要求的操作系统进行更改。
数据治理- 监管或业务要求可能会规定数据的正确性或治理标准。如果操作系统容易出现数据错误(通常是这种情况),则可以设置数据治理功能来管理数据的验证和更正。
出于多种原因,数据质量可能很重要,通常与会计或监管要求有关。数据治理或数据质量官通常是由业务主导的角色,负责安排对系统中已记录数据的修复。
分析师- 电子表格 jock 角色的一种变体,用户实际上以某种身份工作,对数据进行分析工作(例如保险精算师)。
出于各种原因,分析师可能对业务很重要,具体取决于角色。就精算师而言,他们的作用是估计未来索赔的准备金,维护保险产品的定价模型或为各种金融交易提供估值。
大多数 BI 员工往往属于这些类别中的一个或多个。对组织的价值因个人情况而异。我观察到的一个普遍现象是,负责操作系统的人大大低估了这些角色实际发生的工作量。我见过一家保险公司,仅在其欧洲业务的会计部门就有 170 名员工。他们的大部分时间都花在处理电子表格中的数据提取以及操作手动对帐和控制流程上。
在业务线应用程序的开发和操作过程中,管理信息在优先级方面常常是一个糟糕的表亲。协调不善或不存在的数据架构策略可能会花费大量时间和金钱。默认行为是将系统视为孤岛,没有人有权直接修复跨系统数据问题。将其保留足够长的时间,最终结果是后台操作雇用了数百名文员(通常是合格的财务人员),他们将大部分时间花在处理一些存储过程的工作上。
BI 人员会生产哪些对我的组织有价值的产品。
我将尝试解决问题的这一部分,因为我认为其他人已经很好地解释了 BI 是什么。我在一家有很多客户的公司工作,我知道关于我们为这些客户提供的功能的大量信息。
我们的应用程序非常以数据为中心;我们的行业受政府监管,因此遵守联邦和州法律至关重要。我们的 BI 专家为公司带来了什么,使他们变得有价值?
首先,我们从客户端导入数百万条记录,以便他们拥有完成工作所需的信息。使他们数据库中的数据适合我们的数据库是一项关键工作,而且不是很简单;您缺少必填字段的信息、数据类型不匹配、数据完整性问题(例如,我无法放入02/30/2012日期字段)。我们也进行定制,所以我必须设计一个地方来放置我们不会为其他客户端存储的数据,然后创建导入以获取数据。没有客户端的数据,应用程序将无法运行。数据量太大,无法手动输入。
接下来,客户的经理需要以有助于他们管理业务的方式查看数据。所以他们请求报告,大量的报告,预算报告,费用报告,合规报告等。这些报告非常复杂,它们背后的查询可能超过一千行。编写这种报告代码可能需要 SQL 专家。
此外,商业智能人员通常比许多应用程序开发人员更深入地了解业务细节,因此他们也是评估需求的第一线。我们是那些指出缺少的必要信息和相互冲突的业务规则的人,因为我们非常熟悉数据及其存储方式和用途。
一旦报告到了某个点,我们需要将其与事务数据库分离并构建数据仓库,以便对数据进行复杂分析的人不会导致正在输入数据的人被阻止。为分析构建数据结构的方法通常不是为交易构建数据的最佳方法,因此我们再次将数据从一种数据结构转换为另一种非常不同的数据结构。通过分析几年的数据来深入研究数据的能力对我们的客户来说是一个巨大的卖点。因此,我们再次通过生产客户管理业务所需的产品来增加价值。
如果您的数据需求都是内部的,您仍然可能有需要这种级别分析的内部客户。在这种情况下,与将数据导入交易系统相比,您可能更关心数据仓库的报告方面。但对于大多数组织而言,使用您收集的数据来制定管理决策的能力仍然是无价的。
您是否需要 BI 专家往往取决于您的数据需求有多广泛以及系统有多复杂。较小的企业可能没有足够的工作供这种性质的人使用,并且可能会聘请顾问来创建他们需要的报告。BI 专家往往只在大中型企业工作。
如果您是创建COTS 软件的企业,您可能需要 BI 专家作为顾问,他们了解您的产品,并从中为您的客户创建定制的产品。
虽然它们不是最佳实践的好例子,但 SQL Server 示例数据库将是一个很好的起点。它们包括用于虚构组织的 OLTP、数据仓库和分析服务数据库。研究它们之间的差异应该有助于您理解 OLTP(事务)和 OLAP(分析/BI)数据库的不同之处以及原因。
http://msftdbprodsamples.codeplex.com/
AdventureWorks OLTP 数据库支持虚构自行车制造商 (Adventure Works Cycles) 的标准联机事务处理方案。场景包括制造、销售、采购、产品管理、联系人管理和人力资源。
Adventure Works DW 数据库演示了如何构建数据仓库。
Adventure Works AS 项目可用于为商业智能场景构建 AS 数据库。
| 归档时间: |
|
| 查看次数: |
24855 次 |
| 最近记录: |