Wer*_*ght 3 odbc business-objects foreign-keys relational-database
目标:我希望用户能够直接连接到RDBMS(例如,MS SQL Server)并使用可能的交叉引用进行一些查询.
工具: SAP BusinessObjects XI Enterprise
描述:
主要原因是宇宙的创造非常有技术性.想象一下,SQL DB结构经常变化,甚至可能每天都在变化.Hense同步问题.
BO是否能够使用非技术可用的BO查询GUI进行交叉引用确实生成如下请求:
SELECT
Classroom.Location
FROM
Student,
Classroom
WHERE
Student.Name = 'Foo' AND
Student.ClassroomName = Classroom.Name
...只有ODBC连接而且没有Universe(或自动生成的Universe)？
如果是,是否需要定义外键？
如果不是,是否有一种简单的方法可以直接从DB结构创建和更新(同步)BO Universe？可能正在使用他们的新XML格式？
好问题.
背景
我已经实现了一个非常大且"复杂"的银行数据库,500多个表,客户买了BO."复杂"是引号,因为虽然我创建了一个纯5NF(正确规范化为5NF)Rdb,并且大多数开发人员和高级用户都没有发现它"复杂,一些开发人员和用户发现它"复杂".第一个BO顾问甚至无法创建一个有效的宇宙,并且超过他预算的一个月.第二个BO顾问在10天内创建了整个宇宙.整个结构(一个5NF Rdb; 5个应用程序;一个Universe;网络报告)都运行得很漂亮.
但是作为这个练习的结果,我很清楚,尽管Universe非常强大,但它只需要克服非标准化数据库或具有来自许多不同源dbs的表的数据仓库的障碍,然后需要被视为一个逻辑表.第一位顾问只是重复他习惯的东西,做他的技术人员,并且不明白规范化的数据库是什么意思.第二个实现是真正的(标准化的)Rdb根本不需要BO Universe.
因此,对于下一个大型银行项目,其中Rdb几乎是之前Rdb的120%,我建议不要使用BO,而是购买Crystal Reports,要便宜得多.它提供了用户所需的所有报告,但它没有"切片和骰子"功能或本地PC上的数据立方体.我必须做的唯一额外工作是提供一些视图来缓解Rdb的"复杂"位,所有工作都在一天之内完成.
从那时起,我参与了使用BO和修复问题的任务,但我还没有使用过XI(及其自动生成的Universe).当然,这是对简单报告工具的优势,并且完全避开了宇宙,这已被多次证明.
一般情况下,是的,BO查询GUI(甚至是前XI)将绝对直接读取Rdb目录,您可以创建并执行任何您想要的报告,而无需 Universe.你的榜样根本没有汗水."交叉引用"根本就没有汗水.非技术用户可以自己创建和运行此类报告.我做了很多这些,需要几分钟.有时(例如,对于Supertype-Subtype结构),创建视图可以进一步简化此练习.
你的问题
揭露那些障碍的问题.
遇到的是你没有关系数据库.将一些数据倒入称为"关系DBMS"的容器中不会将该内容转换为关系数据库.
注意到你的评论改变了"db"结构.显然,您还没有规范化数据.
是的,当然他们无法进入新的列和新表,但提供这是扩展的一部分; 重点是现有结构,依赖于它的一切都是稳定的.
注意你的示例查询.这是完全缺乏规范化的初步证据:Student.ClassroomName是一个denoramlised列.而不是每个学生都存在一次,每个课堂应该存在一次.
因此,你不仅有一些几乎每天都在变化的"结构",你的"结构"中没有任何结构,这种结构不会改变.持续变化的水平对于项目中的Prototype阶段来说是经典的; 它还没有落到发展阶段.
如果您使用BO或自动生成的Universe,则必须每天自动生成Universe.然后每天重新创建报告定义.用户可能不喜欢每天重新开发Universe及其报告的想法.通常他们会等待项目的UAT阶段,如果不是生产阶段.
回答
Business Objects,Crystal报表和所有高端到低端报表工具主要是为关系数据库编写的,它们位于ISO/IEC/ANSI标准SQL DBMS中.这意味着,如果定义在目录中,他们会找到它.高端工具有各种附加选项(这就是你付出的代价),以帮助克服RDBMS的次标准内容的限制,最终在宇宙中; 但是你知道需要付出相当大的努力和技术资格来实施.
我能给你的最佳建议是获得一名合格的建模师并为你的数据建模; 这样它是稳定的,没有重复,你的代码是稳定的,等等; 这样简单(或重型)报告工具可用于(a)轻松定义报告,(b)运行这些报告定义而无需每天更改.你会发现每天变化的"结构"没有.每天变化的是您对数据的理解.
然后,您的愿望将成为现实,报告可以很容易地由用户,"交叉引用"和所有,没有Universe定义,并且可以随时运行它们.
相关材料
这个,你的学院或项目,并不是宇宙中第一个试图(a)模拟他们的数据或(b)实现数据库,关系与否.您可能对其他已经在该领域已经完成的工作感兴趣,因为通常可以免费获得大量信息,以避免重新发明轮子,特别是如果您的项目没有合格的工作人员.这是我为当地大学做的最近项目的简化版本(他们很高兴我发布通用版本,但不是完整的客户特定版本); 我写了Rdb,他们写了应用程序.
不熟悉关系建模标准的读者可能会发现IDEF1X表示法很有用.
要明确的话.首先是一个定义.
1)关系数据库按时间顺序排列在2010年的最后几天,具有超过25年的常用真正关系技术[超过35年的难以使用的相关技术],其中有许多适用的标准,并使用这些定义(由于贡献者缺乏技术资格,维基不适合提供所述定义):
坚持关系模型作为原则
归一化到至少第三范式(你需要5NF完全没有数据重复和更新异常)
符合各种现有标准(适用于每个特定区域)
由合格且有能力的建模者建模
在ISO/IEC/ANSI标准SQL中实现(这是外部键定义的声明性引用完整性;规则和检查约束;域;数据类型)
是开放式架构(供任何应用程序使用)
被视为具有重大价值的公司资产
因此,合理地防止未经授权的访问; 数据和参照完整性; 不受控制的变化(影响其他用户的计划外变更等).
如果没有它,您将无法享受关系数据库的强大功能,性能,易于更改和易用性.
2)它不是,是RDBMS平台的内容.将非结构化或无组织数据倒入标记为"关系数据库引擎"的容器中并不会将内容神奇地转换为容器的标签.
因此,如果它是一个合理的(不完美的,不是100%标准投诉),一个关系数据库,BO Universe绝对不需要访问并使用它的全部功能(仅受报告工具的功能限制).
如果它没有DRI(FK定义),并且没有旧样式"定义键" 且没有命名约定(可以从中导出"关系")并且没有匹配的数据类型,那么没有报告工具(或人类)可以找到任何东西.
它不仅仅是FK的定义.
根据到底是哪一个关系数据库的位已在数据堆实现,并在报告工具(多少许可费用)的能力,有些能力某处频谱的两端内,是可能的.没有宇宙的BO是报告工具中最好的; 他们的Crystal Reports项目大约是咕噜声的一半.Universe需要提供非数据库的数据库定义.
然后是重复问题.想象一下当用户发现3个月后他们最终获得的数据结果是没有人保持最新的重复时,用户会感觉如何.
"数据库"对象定义
如果您有不合格的开发人员或最终用户在"数据库"中实施"表格",那么他们对自己的障碍和矛盾没有限制.("在这里,我有一个RDBMS,但内容不是;我有BO但它不能;我有加密但我已经将工资单数据复制到五个地方,这样人们就可以得到在他们忘记加密密钥的时候"."每次我认为我已经看到了疯狂的极限,有人在SO上发布了一个问题,并再次教导我疯狂没有限制.
只要有正确的FK定义,通过ODBC连接的BO能够在没有Universe的情况下进行JOIN(交叉引用)吗？
(ODBC与它无关;它将通过本机连接或通过浏览器进行相同操作.)
对于那一次,重新FKs正确定义,是的.但我长期反应的目的是确定这是许多其他因素.
它不是BO或BO Universe的问题,而是"用户的定义和重复是多么疯狂".FK有时可以工作而不是其他工作; 今天可以工作,而不是明天.
| 归档时间： |
|
| 查看次数： |
2965 次 |
| 最近记录： |