• 阿波罗登月计划背后的功臣-IMS信息管理系统
  • 发布于 1周前
  • 75 热度
    0 评论
1962年,肯尼迪总统向美国人发起挑战,这十年结束前能把人送往月球,而一个英勇的工程计划将此推上顶峰,即尼尔·阿姆斯特朗迈出了探索月球表面的第一步。 

这一开拓性尝试可谓是硕果累累,清晰可见而又令人振奋——新型宇宙飞船,崭新太空服,月球车等等。然而阿波罗计划庞杂多样,不得不发明新技术,IBM的信息管理系统(IMS)就是这些技术之一。 

IMS是一个数据库管理系统,NASA(美国国家航空航天局)需要这样的系统来追踪了解所有建造土星五号运载火箭的部件,因为足足有两百万个零件,这肯定是一个巨大的挑战。  

1965年,NASA命IBM和北美航空公司以及卡特彼勒公司展开合作共建数据库。到1968年,IBM已在NASA安装有IMS的工作版本,尽管当时称其为ICS/DL/I,即信息控制系统和数据语言/接口。

两年后,IBM将ICS/DL/I重塑为“IMS”的形象,并开始出售给其他客户。这是最早的商业化的数据库管理系统之一。 

不可思议的是,IMS今天仍在使用,而且使用范围可不小,银行,保险公司,医院以及政府机构仍利用IMS执行各种各样的艰巨任务。超过95%的财富1000强公司使用IMS ,而美国五大银行也是如此。

不管何时从ATM中取钱,你有极大概率在交易过程中与IMS产生联系。在这个世界上,虽然IMS是使人“憎厌的”、1970年关系数据库发明之前的那一时代的遗留物,但仍然是负责重要数据的数据库。 

IMS基于层次模型工作,这意味着IMS不会将数据视为可以Join的二维表,而是将数据视为树。 

举个例子,假设你要存储银行客户的信息。你可能有一种类型的记录来表示客户(Customer),另一种类型的记录来表示该客户的帐户(Account)。 

关系数据库中每个表都有列,在层次数据库中,这些记录将有不同的字段; 例如给每个客户提供名字字段,姓氏字段和城市字段。  

然后,我们必须决定是首先查找Customer,然后查询有关该客户的Account信息,或者反过来。假设我们决定首先访问Customer,那么将使我们的Account成为Customer的子项。如图所示,我们的数据库模型看起来像这样:

实际的数据可能如下所示: 

每个父记录都包含指向其子节点的指针,这意味着我们可以从根节点向下移动。(实际上,每个父记录基本上只存储一个指向第一个子节点的指针。子节点们包含指向其他子节点的指针。这确保了记录的大小不会随着子节点的数量而变化。)  

只要我们以第一次构建数据库时预期的方式访问数据(先访问Customer,再访问Account),就可以非常快速地进行数据访问。 根据IBM的说法,IMS实例每秒可处理超过100,000个事务,这可能是IMS仍在使用的主要原因,特别是在银行。 

然而,缺点是我们失去了很多灵活性。 如果我们想要以未经预设的方式访问数据,可能会遭遇困难,比如,用户给出了一个Account Number, 然后想更新自己的地址(在Customer类型当中),怎么办呢? 所有的访问都是从树的根部(即Customer)开始,这个时候想要找到Account Number的记录,代价是非常高的。 

一种解决办法是引入使用重复的数据,比如新建一个层次模型,这个模型的根是Account,然后把Cutomer作为子节点。  

正是这种不灵活性和信息重复的问题促使E. F. Codd(埃德加·弗兰克·科德)在1970年的论文“大型共享数据库的数据关系模型”中提出了关系模型。使用这种模型,用户就不必关心数据的具体存储方式。 

从某种意义上看,分层模型是一种自下而上的模型,是对具体现实的表示。而关系模型是基于关系代数的抽象模型,并且是自上而下的,因为数据存储方案可以是任意的,只要它适应模型。  

不像MySQL,IMS并不是你可以自行下载并在计算机上随心使用的东西。首先,IMS不是免费的,因此你必须从IBM购买它。但更大的问题是IMS只能在像IBM z13这样的IBM大型机上运行,这是很遗憾的,因为尝试IMS将是一件乐事,还能确切了解到它与MySQL之类的区别。 

但即使没有这个机会,想到软件系统以我们意料之外或尚不习惯的方式工作,也很有趣。特别有趣的是,尽管这些系统看起来不为人知,实际上却是当地医院,整个金融部门甚至联邦政府的支柱。

用户评论