SAP BusinessObjects 是否需要关系数据库的 Universe？

Question

目标：我希望用户能够直接连接到 RDBMS（例如 MS SQL Server）并通过可能的交叉引用进行一些查询。

工具： SAP BusinessObjects XI Enterprise

描述：

主要原因是 Universe 创建非常需要技术。想象一下 SQL DB 结构经常发生变化，甚至可能每天都发生变化。因此存在同步问题。

BO 是否能够使用 BO 查询 GUI 进行交叉引用，非技术人员可以使用它生成如下请求：

SELECT
    Classroom.Location
FROM
    Student,
    Classroom
WHERE
    Student.Name = 'Foo' AND
    Student.ClassroomName = Classroom.Name

...仅使用 ODBC 连接和 没有宇宙（或自动生成的宇宙）？

如果是，是否需要定义外键？

如果没有，是否有一种简单的方法可以直接从数据库结构创建和更新（同步）BO Universe？可能正在使用他们的新 XML 格式？

Answer 1

好问题。

背景

我已经实现了一个非常大且“复杂”的银行数据库，有 500 多个表，客户为其购买了 BO。 “复杂”用引号引起来，因为虽然我创建了一个纯 5NF（正确标准化为 5NF）RDB，并且大多数开发人员和高级用户并不认为它“复杂”，但一些开发人员和用户发现它“复杂”。第一个 BO 顾问甚至无法创建一个可用的宇宙，并超出了他一个月的预算。第二位 BO 顾问在 10 天内创建了整个宇宙。整个结构（1 个 5NF RDB；5 个应用程序；1 个 Universe；网络报告）都运行良好。

但通过这次练习，我很清楚，尽管宇宙非常强大，但它只需要克服非规范化数据库或包含来自许多不同源数据库的表的数据仓库的障碍，这些障碍那么需要将它们一起视为一个逻辑表。第一个顾问只是重复他习惯的事情，做他的技术事情，并且不理解规范化数据库的含义。第二个认识是，真正的（规范化的）RDB 根本不需要 BO Universe。

因此，在下一个大型银行项目中，RDB几乎是之前RDB的120%，我建议不要使用BO，而是购买了便宜得多的Crystal Reports。它提供了用户需要的所有报告，但它不具备“切片和切块”功能或本地PC上的数据立方体。我唯一需要做的额外工作是提供一些视图来简化 RDB 的“复杂”部分，所有这些都在一天内完成。

从那时起，我一直参与使用BO的作业，并修复了问题，但我没有使用XI（及其自动生成的Universe）。当然，我们倾向于使用简单的报告工具，并完全避开宇宙，这一点已被多次证明。

一般来说，是的，BO Query GUI（甚至是 XI 之前的版本）绝对会直接读取 RDB 目录，您可以从中创建和执行您想要的任何报告，无需 Universe。你的例子一点也不费劲。 “交叉引用”根本不是什么难事。非技术用户可以自己创建和运行此类报告。我已经完成了很多这样的事情，只需几分钟。有时（例如，对于超类型-子类型结构），创建视图可以进一步简化此操作。

您的问题

暴露了阻碍实现这一目标的问题。

1. 遇到的问题是您没有关系数据库。将一些数据倒入名为“关系 DBMS”的容器中不会将该内容转换为关系数据库。

   • 真正的 RDB 的一个方面是所有定义都位于 ISO/IEC/ANSI 标准 SQL 目录中。
   • 如果我们的“外键”不在目录中，那么您就没有外键，也就没有服务器定义和维护的引用完整性。
   • 您可能也没有规则和检查约束；因此，您不具备服务器定义和维护的数据完整性。

2. 注意到您关于更改“db”结构的评论。显然，您还没有标准化数据。

   • 如果数据已正确标准化，则结构不会改变。
   • 当然，结构将会扩展（添加列；添加新表），但实体和属性的现有结构不会改变，因为它们已经 (a) 正确建模并 (b) 标准化
   • 因此，编写的任何应用程序代码或构建的任何 BO Universe（以及由此创建的报告）都不易受到此类 RDB 扩展的影响；他们继续快乐地奔跑。
   • 是的，他们当然无法获取新列和新表，但前提是这是扩展的一部分；关键是现有的结构以及依赖于它的一切都是稳定的。
   • 注意您的示例查询。这是完全缺乏规范化的表面证据：Student.ClassroomName 是一个非规范化列。它不应该为每个学生存在一次，而应该为每个教室存在一次。
   • 我只是回答你的问题，但需要注意的是，缺乏规范化会导致许多其他问题，与你的问题没有直接关系：大量数据重复；更新异常； “数据库”和“应用程序”之间缺乏独立性（其中一个的更改会影响另一个）；缺乏完整性（数据和参考）；缺乏稳定性，因此是一个永无止境的项目。

3. 因此，你不仅有一些几乎每天都在变化的“结构”，而且在“结构”中你没有任何不会改变的结构。这种程度的持续变化对于项目的原型阶段来说是典型的；尚未进入开发阶段。

4. 如果您使用 BO 或自动生成的 Universe，则必须每天自动生成 Universe。然后每天重新创建报告定义。用户可能不喜欢重新开发宇宙以及每日报告的想法。通常，他们会等待项目的 UAT 阶段，甚至不是生产阶段。

   • 如果您有外键，因为它们位于标准 SQL 目录中，BO 会找到它们
   • 如果您没有外键，但文件之间有某种“关系”，并且可以推断出这种“关系”的某种命名约定，BO 有一个检查自动生成窗口中某处的框，这将“从列名推断外键”。当然，它会发现您可能没有想到的“关系”。
   • 如果您没有命名约定，那么 BO 就无法使用任何东西来推断此类“关系”。产品所能发挥的魔力是有限的
   • 而且你仍然面临着“结构”一直在变化的问题，所以无论你今天依赖什么魔法，明天都可能不起作用。

答案

业务对象、Crystal 报表以及所有高端到低端的报表工具主要是为关系数据库编写的，这些数据库驻留在 ISO/IEC/ANSI 标准 SQL DBMS 中。这意味着，如果定义在目录中，他们就会找到它。高端工具有各种附加选项（这就是你所付出的代价）来帮助克服 RDBMS 不合标准内容的限制，最终在 Universe 中达到顶峰；但如您所知，需要付出相当多的努力和技术资格才能实施。

因此，我能给您的最好建议是找一位合格的建模师并为您的数据建模；这样它是稳定的，没有重复，并且你的代码是稳定的，等等；这样，简单（或重型）报告工具可用于（a）轻松定义报告以及（b）运行这些报告定义而无需每天更改它们。你会发现每天都在变化的“结构”却没有。每天都在变化的是您对数据的理解。

然后，您的愿望就会实现，报告可以由用户轻松定义一次，“交叉引用”等等，无需宇宙，并且可以随时运行它们。

相关材料

您的大学或项目并不是世界上第一个尝试（a）对其数据建模或（b）实现数据库（无论是否关系）的大学或项目。您可能对其他人在该领域已经完成的工作感兴趣，因为通常有很多信息是免费提供的，以避免重新发明轮子，特别是如果您的项目没有合格的员工。这是我最近为当地一所大学所做的一个项目的简化版本（他们很高兴我发布通用版本，但不是完整的客户特定版本）；我写了 RDB，他们写了应用程序。

简化的大学数据模型< /strong>

不熟悉关系建模标准的读者可能会发现 IDEF1X 表示法很有用。

对评论的回应

那就说清楚吧。首先是一个定义。

1. 关系数据库按时间顺序，在 2010 年最后几天的背景下，拥有超过 25 年的普遍可用的真正关系技术[超过 35 年的难以使用的关系技术] ，有许多适用的标准，并使用这样的定义（维基百科不适合提供所述定义，因为贡献者缺乏技术资格）：

• 坚持关系模型作为原则

• 规范化到至少第三范式（您需要 5NF 才能完全避免数据重复和更新异常）

• 符合各种现有标准（适用于每个特定领域）

• 由合格且有能力的建模者建模

• 以 ISO/IEC/ANSI 标准 SQL 实现（即声明性引用完整性、外键定义、规则和检查约束、域、数据类型）

• 是开放架构（可供任何应用程序使用）

• 被视为具有重大价值的公司资产

• ，因此可以合理地防止未经授权的访问；数据和引用完整性；不受控制的更改（影响其他用户的计划外更改等）。

否则，您将无法享受关系数据库的强大功能、性能、易于更改和易用性。

2. 它不是 RDBMS 平台的内容。将非结构化或无组织的数据倒入标有“关系数据库引擎”的容器中并不会神奇地将内容转换为容器的标签。

因此，如果它是一个合理的（不完美的，不是100%符合标准的）关系数据库，那么BO Universe绝对不需要访问和使用它的全部功能（仅受报告工具的功能限制）。

如果它没有 DRI（FK 定义），并且没有旧式“定义的键”并且没有命名约定（从中可以导出“关系”）并且< /strong> 没有匹配的数据类型，那么任何报告工具（或人类）都无法找到任何内容，

这不仅仅是 FK 定义，

具体取决于数据堆中已实现的关系数据库的哪些位 。 > 以及 报告工具的功能（许可证费用是多少）， 范围两端的某些功能，在没有 Universe 的情况下是可能的。报告工具的种类；他们的 Crystal Reports 项目大约是为非数据库提供数据库定义所需的一半。

想象一下用户发现这一点时会有什么感受。 3 个月后，他们最终获得的数据结果是重复的，没有人保持最新的

“数据库”对象定义（

如果您实施的开发人员或最终用户不合格） 。 “数据库”中的“表”，那么它们给自己带来的障碍和矛盾就没有限制。 （“在这里，我有一个 RDBMS，但内容不是；我有 BO，但它不能；我有加密，但我已将工资单数据复制到五个地方，以便人们可以获取每当我认为我已经看到了疯狂的极限时，就会有人在 SO 上发布一个问题，并再次告诉我疯狂是没有极限的。

只要定义了正确的 FK，通过 ODBC 连接的 BO 就能够在没有 Universe 的情况下进行 JOIN（交叉引用）？

（ODBC 与之无关；它将通过本机进行相同的操作）连接或通过浏览器。）

这一次，重新正确定义了 FK，是的。但我长篇大论的目的是为了找出许多其他因素。

这不是一个 BO 或 BO Universe 的问题，而是“用户的定义和重复是多么疯狂”。 FK 有时可以工作，但有时则不行；今天可以工作，明天就不行了。