这是 BI 工作流程的正确想法吗？
我是商业智能的新手。
我刚刚被一家公司雇用，以完成他们的网络解决方案，实施 BI 模块。经过大量阅读后，我想我可以了解 BI 流程是什么样子，您会发现附上我对 BI 流程的想法。
您能告诉我这是否是所有工作流程的正确愿景吗？如果不是请纠正我。另一个问题，我在模式中看不到数据挖掘的位置，如果需要我应该在哪里使用它？
非常感谢，
I am new to Business Intelligence.
I just got hired by a company in order to complete their websolution, implementing a BI Module. After lot of reading, I think I could get an idea of what a BI Process looks like, you'll find enclose my idea of a BI process.
Can you please tell me if this is a correct vision of the all workflow ? If not please correct me. Another question, I can't see the place of data mining in the schema, where should I use it if needed ?
Thanks a lot,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
以下是您可能需要考虑的几点：
表示层是 Excel 或 Web 服务而不是其他内容，这正确吗？如果您想部署 SSRS、Cognos、Business Objects、Microstrategy 等 Web 报告平台该怎么办？这些平台通常直接访问数据，无需 Web 服务。
您可能需要将其他数据输出到平面文件和下游数据库。数据可能基于 OLAP 多维数据集或原始源数据。因此，您可能希望将这些作为目标包含在主数据仓库级别和 OLAP 级别。
如果您实现 Web 表示层，它可能不仅仅位于 OLAP 多维数据集上。您可能会收到报告 OLAP 多维数据集中未包含的数据的请求，并且可能不值得仅仅为了支持一些报告而添加它。如果是这种情况，那么您可能需要注意，主数据仓库可能是 Web 报告平台的源 - 而不仅仅是 OLAP。
数据集市通常不包含聚合数据——它们通常包含详细级别的数据。 OLAP 多维数据集对详细数据执行聚合，但底层数据集市本身包含事务级事实。
您可以拥有由 ETL 流程导入的其他数据源，例如 Web 服务。您可能还想强调有多个数据库和平面文件，就像您强调可以有多个数据集市和 OLAP 多维数据集一样。
您不一定需要为 OLAP 多维数据集提供单独的数据集市。如果您正在构建一个中央数据仓库，则可以创建一个中央 OLAP 多维数据集，并根据多维数据集安全角色限制对维度和数据切片的访问。
您可能希望表明您需要在加载数据仓库之前加载临时数据库。也许情况并非如此，但通常我建议使用单独的临时数据库，以便在合并到数据仓库之前有一个加载位置。一些 ETL 流程可以直接进入数据仓库，因为它们可以在进入的过程中进行合并，但在很多情况下，在将数据合并到最终目标之前将数据加载到临时数据库中可能是有意义的。这也意味着 ETL/存储过程可能应该是图中自己的实体，因为它是一种移动数据的方法，而不是目的地或对象。如果您查看图表，您会发现所有实体都是实际对象，而不是像 MDX 这样的进程。
您可能希望表明数据是通过 ETL 流程加载到数据集市的。 ETL 不仅仅是加载数据仓库——它还涉及在任何阶段移动数据。即使处理多维数据集也需要 ETL 过程。
您的 OLAP 服务器不一定必须位于另一台物理服务器上——它可以是数据库服务器上的一项服务。这仅取决于您是否通过纵向扩展或横向扩展来解决性能问题，或者您是否打算因地理性能问题而将多维数据集发布到多个 OLAP 服务器。
Below are a couple points you may want to consider:
Is it correct that the presentation layer is either Excel or a web service and nothing else? What if you wanted to deploy a web reporting platform such as SSRS, Cognos, Business Objects, Microstrategy, etc.? These platforms generally access the data directly without web services.
You may need to output additional data to flat files and downstream databases. The data may be based off either the OLAP cube or the raw source data. Therefore, you may want to include these as destinations at the main data warehouse level and the OLAP level.
If you implement a web presentation layer, it may not only be over an OLAP cube. It is likely you will receive a request to report on data that isn't contained in an OLAP cube and it may not be worth the effort to add it just to support a few reports. If this is the case, then you will probably want to note that the main data warehouse could be a source for a web reporting platform -- not just OLAP.
Data marts don't generally contain aggregated data -- they generally contain detail-level data. The OLAP cube performs aggregations over the detailed data, but the underlying data mart itself contains transaction-level facts.
You could have additional data sources that are imported by the ETL process such as web services. You may also want to stress that there are multiple databases and flat files just as you stressed there can be multiple data marts and OLAP cubes.
You don't necessarily need separate data marts for the OLAP cubes. If you are building one central data warehouse, you may be able to create one central OLAP cube and limit access to dimensions and slices of data based on cube security roles.
You may want to indicate that you need to load a staging database prior to loading the data warehouse. Perhaps that isn't the case, but generally I recommend having a separate staging database so that you have a place to load before you merge into the data warehouse. Some ETL processes can go directly into the data warehouse since they can merge on the way in, but there are plenty of instances where it probably makes sense to load the data in a staging database before merging it into the final destination. This also means ETL / Stored Procedures probably should be its own entity in the diagram since it is a method for moving data more than it is a destination or object. If you look at your diagram, all your entities are actual objects and not processes like MDX.
You may want to indicate data is loaded into data marts via an ETL process. ETL isn't just about loading the data warehouse -- it is about moving data at any stage. Even processing cubes requires an ETL process.
Your OLAP server doesn't necessarily have to be on another physical server -- it could be a service on the database server. It just depends on whether you tackle performance issues by scaling up or scaling out or if you intend to publish cubes to multiple OLAP servers because of geographic performance issues.