最初由 lodge 发布
[B]哦, 经你一说去看了看那篇论文, 论文的内容和楼主说的又是另外, 一回事啦. 那篇论文是说分散数据库中, 一样性质的数据, 可能因为设计和实装方式不同无法统一处理, 打个比方信息产业部想统计各地IT的经营状况, 可是大家用的系统都不一样, 字段名称可能不同, 关系结构也可能不同, 如何进行整合就是一个大问题啦.
当然啦, 那篇论文似乎很古董啦, 利用META信息(就是说一些对于数据本身和环境的描述信息)做数据库统合的方法可是有年头啦, 只少有十五年的历史吧, 论文的参考文献都是上个世纪的古董, 就能看出这篇论文应该早以过时啦. [/B]
最初由 fanyzidb 发布
[B]
互联网时代对数据库的要求与局域网时代有着本质的不同。局域网中的数据的内部结构是都是可知的、基本上是固定的，而互联网中的数据的结构是未知的（对用户而言），数据的结构也是无穷的。
关系数据库在局域网中可以很好地满足用户的需求，然而在互联网时代，它难以解决供应链上下游企业之间的信息共享和交换问题。
就你所说的信息产业部想统计各地IT的经营状况问题,该如何解决,这正是我所关心的问题.这也是关系数据库所难以解决的问题. [/B]
最初由 lodge 发布
[B]
呵呵, 本质的不同就是通信和信息共享呗.
互联网时代, 如果数据库的内部结构都不能知道那还共享什么捏. 数据库结构未知是不可能地, 问题在于, 你如何把两个结构完全不同的数据库整合到一起, 比如说, 把IT的营业额和纺织业的营业额相加算算总营业额什么的. 这件事情手工操作是能够解决地, 可是如果有成千上万个系统, 并且不断出现新系统的时候这问题不靠程序自动完成是根本不行地.
欧美在这一方面是非常领先地, 你在欧洲的ATM上可以直接从自己在美国银行的户头上取钱, 这就是一个最为典型的这类技术的应用, 因为, 这中间不知道要跨过多少个数据库系统, 多少个银行, 才能完成这样一个操作, 而这个操作只需几秒钟. 欧美人最为骄傲的就是, 他们可以用信用卡在小卖部买小吃, 可见起数据库系统的发达程度啦.
中国目前是很落后地, 异地取个钱不还是挺麻烦的吗?
这项技术欧美基本上在二十年前就已经开始研究, 并派生出很多分枝, 其中最为著名的就是数据仓库了吧. 如果感兴趣可以去查查欧美近年来的技术文献, 至少五年前的杂志上这类文章简直就是铺天盖地的.
最初由 fanyzidb 发布
[B]
一家大企业，其客户和供应商有成百上千个，甚至更多。在电子商务中，一家大企业要想与其客户和供应商完成电子商务交易，它需要与成百上千个系统进行信息共享和交换，对它而言，其客户和供应商的数据库系统的数据结构就是未知的。
我所提出的解决方案可以把所有的异构数据源变成同构的信息源，从而解决异构信息源和信息孤岛问题。也许你未看俺所写的文章。
正如你所说“可是如果有成千上万个系统, 并且不断出现新系统的时候这问题不靠程序自动完成是根本不行地”，这些问题就是现在与将来所要解决的问题。这也是俺所真正关心的。互联网中的确是成千上万个系统，且不断出现新系统。 [/B]
最初由 lodge 发布
[B]
不能同意未知的说法, 如果做调查是能够知道地, 只是结构上不能统一而已, 不过偶以为在标准化上动脑筋是不可行地, 在通信协议这一层次上作文章还差不多.
偶理解信息孤岛问题, 也并非仅仅是数据库的问题, 网络通信协议上的问题更大.
至于数据库不统一的问题, 完全可以利用OO的概念统一通信协议来解决. 实施上可以考虑, 为需要统合的数据库开发GATEWAY程序按照协议标准把数据库接到网络上去就可以啦.
BTW, 上面的思路并非是偶的想法, 而且已经相当成熟, 具体案例可参见EDI 技术. [/B]
最初由 fanyzidb 发布
[B]
通过调查是可以知道的,问题是面对成千上万个数据库系统,所涉及到的表的数量是非常惊人的!面对结构各不相同的几十万、几百万个表,要了解其结构,是相当困难的.
从通信协议的角度解决不了问题,因为这并未解决异构数据源问题.信息孤岛是同异构数据源而引起的.EDI 和 XML 所解决的只是数据交换问题，而未能解决最根本的异构数据源问题。 [/B]
最初由 lodge 发布
[B]偶看了这篇文章, 偶觉得它比较落伍的地方是万能的准一维数据结构只考虑了数据库的逻辑结构, 把表名, 字段名, 类型之类的所谓META信息, 写到了一张标准结构的表里(它把内部结构写到了自己的结构里), 它并没有对原来的信息做任何提高通用性的改进, 无法令系统理解的表名, 字段名等等, 都是老样子, 数据库依然无法整合. [/B]
最初由 lodge 发布
[B]偶看了这篇文章, 偶觉得它比较落伍的地方是万能的准一维数据结构只考虑了数据库的逻辑结构, 把表名, 字段名, 类型之类的所谓META信息, 写到了一张标准结构的表里(它把内部结构写到了自己的结构里), 它并没有对原来的信息做任何提高通用性的改进, 无法令系统理解的表名, 字段名等等, 都是老样子, 数据库依然无法整合. [/B]
最初由 fanyzidb 发布
[B]
如果所有数据库都是用\"准一维数据结构\"来建立,信息孤岛异构数据源问题就可以比较容易地解决.
而整合目前的关系数据库则是非常非常困难的,问题的根源就在于关系数据库不能解决异构数据源问题. [/B]
最初由 lodge 发布
[B]
如果所有的数据库都按照同样的方法建立, 也就没有了异构的问题了嘛. 可是这是不可能地,
而独特的数据结构只能加剧异构的矛盾, 是无法解决这一矛盾地. 试想你如何能让一个关系型的数据库从你的准一维数据结构数据库中得到数据捏, 如果你无法做到这一点, 你的数据库只是增加了一座孤岛而已. [/B]
最初由 fanyzidb 发布
[B]
目前,关系数据库在市场上占据着统治地位,人们都习惯于用关系数据库的思维方式来处理问题,在心理学上这叫做心理定势.
您老兄现在是用关系数据库的思维方式来考虑问题.
日本的一个禅师曾经这样说过：人的思想好比一个茶杯，只有把原来的茶倒掉，才能接收新的茶水．
你若对准一维数据结构感趣，不妨就彻底＂抛弃＂关系数据库的＂茶水＂，然后再用准一维数据结构来考虑问题． [/B]
最初由 lodge 发布
[B]
如果所有的数据库都按照同样的方法建立, 也就没有了异构的问题了嘛. 可是这是不可能地, [/B]
最初由 lodge 发布
[B]
呵呵, 偶的思维方式, 受到所学专业的影响, 更接近于网络信息共享和知识管理的思考方法, 比较概括和抽象, 对于数据结构等具体实现手法考虑的很少啦.
偶对异构数据库的整合问题比较感兴趣, 几年前写过一篇关于使用AGENT技术整合异构数据库的文章, 现在想想当初的想法还很不成熟, 甚至有些可笑捏.
讨论一下, 偶也有所收获, 希望偶的胡言乱语对你的研究能有所帮助.
最初由 fanyzidb 发布
[B]
与其说对异构数据库的整合，还不如彻底抛弃它．准一维数据结构从根本上保证了不会出现异构数据源． [/B]
最初由 lodge 发布
[B]
统一标准是不可能的, 前面说啦, 微软, IBM这些巨头们又何尝不想统一, 和垄断, 他们都无法做到, 谁还能做到捏. 而且要是能统一就算是关系型数据库也就没有异构问题啦.
你的准一维数据结构, 仍然使用表名字段这样的概念, 是不可能不出现异构地, 试问, 法语的表名和中文的表名如何对应啊. 偶的观点仍然是, 要彻底抛弃逻辑的结构和算法, 用纯粹的业务概念来构筑商用数据模型才有可能具备通用性 [/B]
最初由 lodge 发布
[B]
统一标准是不可能的, 前面说啦, 微软, IBM这些巨头们又何尝不想统一, 和垄断, 他们都无法做到, 谁还能做到捏. 而且要是能统一就算是关系型数据库也就没有异构问题啦.
你的准一维数据结构, 仍然使用表名字段这样的概念, 是不可能不出现异构地, 试问, 法语的表名和中文的表名如何对应啊. 偶的观点仍然是, 要彻底抛弃逻辑的结构和算法, 用纯粹的业务概念来构筑商用数据模型才有可能具备通用性 [/B]
最初由 fanyzidb 发布
[B]
具体是如何实现的？
在准一维数据结构中,表名、数据库名只是一个对象的属性。字段是对象的属性。
在准一维数据结构中之所以还用表名和数据库名是为了与关系数据库兼容。
准一维数据结构其独特之处。要对其深入了解，需要对大脑的联想有一定的了解。大脑是用类似准一维数据结构来存放信息的。 [/B]
最初由 lodge 发布
[B]
呵呵, 这回该偶劝你忘记数据库忘记数据结构啦, 仅仅按照商业的方式来做描述, 比如说你可以把商业行为定义成为不同ACTION, 再为它配上语气, 和信息, 举个例子,
ACTION(行动): 送信
语气: 请求
内容: 价格
作为回答:
ACTION(行动): 送信
语气: 回答
内容: 2000 [/B]
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) | Powered by Discuz! X3.2 |