本发明专利技术的各实施例针对一种存储平台（图２０），包括：数据存储，其中储存的数据是按照项目、元素和关系（图２０，２０１４）来定义的，其中，项目是可储存在数据存储中的数据单元且包括一个或多个元素，元素是包括一个或多个字段的类型（图２０，２０１６）的实例，而关系是至少两个项目之间的链接；定义不同类型项目、元素和关系（图２０，２０１６）的模式组（图２０，２０１４）以及应用程序编程接口（图２０，３５０ａ、２５０ｂ或３５０ｃ），它对模式组中定义的不同项目、元素和关系的每一个包括一个类（图２０，２００８）。数据也可以用对现有项目类型的扩展的形式储存在数据存储中，且其中，应用程序编程接口对每一不同的项目扩展包括一个类（图２０，２００６）。（*该技术在2023年保护过期，可自由使用*）
【技术实现步骤摘要】
本专利技术一般涉及信息存储和检索领域，尤其涉及用于在计算机化系统中组织、搜索和共享不同类型的数据的活动存储平台。
技术介绍
在最近十年中，单个盘的容量每年增长约百分之70(70％)。摩尔(Moore)定律精确地预测了在过去数年中中央处理单元(CPU)能力的惊人增长。有线和无线技术已经提供了数量上巨大的连接和带宽。假设当前趋势持续，在数年内一般的膝上计算机将具有约万亿字节(TB)的存储并包含数百万个文件，而5千亿字节(500GB)的驱动器成为常见的。消费者使用他们的计算机主要用于通信和组织个人信息，不论它们是传统的个人信息管理器(PIM)风格的数据还是如数字音乐或照片那样的媒体。数字内容的量和存储原始字节的能力已经大量地增长；然而消费者可用于组织和统一此数据的方法却跟不上步伐。知识工人花费大量时间来管理和共享信息，某些研究估计，知识工人花费15-25％的时间在与无效信息有关的活动上。另外研究估计，典型的知识工人每天约花费2.5小时搜索信息。开发者与信息技术(IT)部门投资大量的时间与金钱来构建他们自己的用于公用存储抽象的数据存储，以表示如人、地方、时间和事件等事项。这不仅导致重复的工作，还形成公用数据的孤岛，没有共同搜索或共享那些数据的机制。仅考虑当今在运行Microsoft Windows操作系统的计算机上有多少地址簿。如电子邮件客户端和个人财务程序那样的许多应用程序保留各自的地址簿，且在每个那样的程序分别维护的地址簿数据应用程序之间只有很少共享。因而，财务程序(如MicrosoftMoney)不与在电子邮件联系人文件夹(如Microsoft Outlook中的联系人文件夹)中维护的地址共享支付人的地址。确实，许多用户具有多个设备，在这些设备之间和包括到如MSN和AOL等商业服务的手机电话号码的各种附加来源之间应该在逻辑上同步它们的个人数据；然而共享文档的协作大部分是通过将文档附到电子邮件消息来完成的-这是手动的且低效的。缺乏协作的一个原因是组织计算机系统中的信息的传统方法集中在使用基于文件-文件夹-目录的系统(“文件系统”)，来基于用于存储文件的存储介质的物理组织的抽象将多个文件组织到文件夹的目录分层结构中。在1960年代开发的Multics操作系统被认为是在操作系统级上使用文件、文件夹和目录来管理可存储数据单元的先驱。具体而言，Multics在文件的分层结构中使用符号地址(从而引入文件路径的概念)，其中文件的物理地址对用户(应用程序和最终用户)是不透明的。此文件系统完全不考虑任何单个文件的文件格式，且在文件中及文件之间的关系在操作系统级上被认为是无关的(即，与分层结构中文件的位置不同)。由于Multics的出现，在操作系统级上可存储的数据被组织成文件、文件夹和目录。这些文件一般包括放在由文件系统维护的一特定文件中的文件分层结构本身(“目录”)。此目录进而维护对应于该目录中所有其它文件和那些文件在分层结构(这里指文件夹)中的节点位置的条目的列表。这是本领域中近40年的状态。然而，虽然提供了驻留在计算机的物理存储系统中的信息的合理表示，但是文件系统是物理存储系统的抽象，因而文件的利用需要在用户处理什么(具有上下文、特征以及与其它单元的关系的单元)和操作系统提供什么(文件、文件夹和目录)之间的间接(解释)层。结果，用户(应用程序和/或最终用户)只好强制把信息单元放入文件系统结构，即使这样做是低效的、不一致的、或不希望的。此外，现有的文件系统关于在各个文件中存储的数据的结构知之甚少，因此，大多数信息在文件中保持封闭，只能被写那些数据的应用程序访问(和可理解)。因此，缺乏信息的模式描述和管理信息的机制，导致形成数据的先进先出存储缓冲区(silo)，只有很少数据能在各先进先出存储缓冲区之间共享。例如，许多个人计算机(PC)用户具有5个以上各异的存储，它们包含有关他们在某一层上交互的人的信息-如Outlook联系人、在线账户地址、Windows地址簿、Quicken受款人和即时消息(IM)伙伴列表-因为组织文件向这些PC用户提出重要的挑战。由于大多数现有的文件系统利用嵌套的文件夹隐喻来组织文件和文件夹，因此当文件数量增加时，为维持灵活且有效的组织模式所必需的努力变得十分惊人。在这些情况下，具有单个文件的多重分类是非常有用的；然而使用现有文件系统中的硬和软链接是麻烦且难以维护的。过去已作了若干不成功的尝试来克服文件系统的缺点。这些以前尝试中的某一些已经涉及使用内容可定址的存储器来提供可以通过内容而不是通过物理地址来访问数据的机制。然而，这些努力被证明是不成功的，因而虽然内容可定址的存储器对由如高速缓存和存储器管理单元等设备的小规模使用被证明是有用的，但对如物理存储介质等设备的大规模使用由于各种原因尚不可能，因此那样的解决方案简直不存在。已作出使用面向对象的数据库(OODB)系统的其它尝试，但是这些尝试虽然带有强烈的数据库的特征，且良好的非文件表示，但在处理文件表示方面并不有效，并不能重现在硬件/软件接口系统级上基于分层结构的文件及文件夹的速度、效率和简单性。诸如试图使用SmallTalk(和其它派生方法)的其它尝试在处理文件和非文件表示方面被证明相当有效，但缺乏有效地组织和利用在各种数据文件之间存在的关系所必需的数据库特征，因此那种系统的整体有效性是不可接受的。使用BeOS(和其它那样操作系统研究)的又一种尝试尽管能够胜任适当地表示文件的同时又提供某些必要的数据库特征，在处理非文件的表示上被证明是不够的，这是传统文件系统同样的核心缺点。数据库技术是存在类似挑战的另一专业领域。例如，虽然关系型数据库模型已取得很大的商业上的成功，实际上独立软件分销商(ISV)一般运用了关系型数据库软件产品(如Microsoft SQL Server)中可得到的功能一小部分。相反，应用程序与那样产品的大多数交互是以简单的“gets”和“puts”的形式。对此虽然有若干容易明白的原因(如作为平台或数据库的不可知)，一个常被忽略的关键的原因是数据库没有必要提供主要商业应用程序分销商确实需要的精确抽象。例如，虽然真实世界具有如“客户”或“订单”等“项目”的概念(以及订单的嵌入的“行式项目”作为其中的项目和项目本身)，而关系型数据库只在表和行的方面来谈论。结果，虽然应用程序可能希望具有在项目级上的一致性、锁定、安全和/或触发器的方面(只列出一些)，通常数据库只在表/行级上提供这些特征。尽管若每个项目映射到数据库某个表的单个行也能工作得很好，但在带多个行式项目的订单的情况下，存在一个项目实际上要映射到多个表的原因，且在此情况下，单个关系型数据库系统不能确切地提供正确的抽象。因此，应用程序必须在数据库的顶层构建逻辑以提供这些基本抽象。换言之，基本关系模型不提供在其上容易开发高级应用程序的存储数据的足够平台，因为基本关系模型需要在应用程序和存储系统之间的间接层，其中只在某些情况的应用程序中可以看到数据的语义结构。尽管某些数据库分销商正将高级功能构建到他们的产品中(如提供对象关系能力，新的组织模型等)，至今尚没有哪个提供需要的全面解决方案，其中真正的全面解决方案是为有用的域抽象(如“个人”、“位置”、“事件”等)提供有用的数据模型抽象本文档来自技高网...
【技术保护点】
一种存储平台，包括：数据平台，其中所储存的数据是按照项目、元素和关系来定义的，其中，项目是可储存在所述数据存储中的数据单元且包括一个或多个元素，元素是包括一个或多个字段的类型的实例，而关系是至少两个项目之间的链接；定义不同类 型的项目、元素和关系的模式组；以及应用程序编程接口，它对所述模式组中定义的不同项目、元素和关系的每一个包括一个类。
【技术特征摘要】
1.一种存储平台，包括数据平台，其中所储存的数据是按照项目、元素和关系来定义的，其中，项目是可储存在所述数据存储中的数据单元且包括一个或多个元素，元素是包括一个或多个字段的类型的实例，而关系是至少两个项目之间的链接；定义不同类型的项目、元素和关系的模式组；以及应用程序编程接口，它对所述模式组中定义的不同项目、元素和关系的每一个包括一个类。2.如权利要求1所述的存储平台，其特征在于，数据也可以用对现有项目类型的扩展的形式被储存在所述数据存储中，且其中，所述应用程序编程接口对每一不同的项目扩展包括一个类。3.如权利要求1所述的存储平台，其特征在于，对每一类型的项目、元素和关系的类是基于定义每一类型的项目、元素和关系的所述模式组自动生成的。4.如权利要求1所述的存储平台，其特征在于，对每一类型的项目、元素和关系的类定义了一组数据类，且其中，所述应用程序编程接口还包括为所述数据类定义一组公共行为的第二组类。5.如权利要求4所述的存储平台，其特征在于，所述第二组类包括表示存储平台范围且为所述数据存储上的查询提供上下文的第一类，以及表示所述数据存储上的查询的结果的第二类。6.如权利要求1所述的存储平台，其特征在于，还包括其上实现所述数据存储的数据库引擎，且其中，所述数据存储中不同类型的项目、元素和关系在所述数据库引擎中被实现为用户定义类型(UDT)。7.如权利要求6所述的存储平台，其特征在于，所述应用程序编程接口提供了一查询模型，所述查询模型使得应用程序员能够以将所述应用程序员与所述数据库引擎的查询语言的细节隔离的方式，基于所述数据存储中的项目的各种属性来形成查询。8.一种用于提供应用程序和用于储存、组织、共享和搜索数据的存储平台之间的应用程序编程接口的方法，其中所述存储平台包括数据存储，其中所储存的数据是按照项目、元素和关系来定义的，其中项目是可储存在所述数据存储中的数据单元且包括一个或多个元素，元素是包括一个或多个字段的类型的实例，而关系是至少两个项目之间的链接，所述方法包括以下步骤提供定义不同类型的项目、元素和关系的模式组；以及为所述模式组中定义的不...
【专利技术属性】
技术研发人员：WC吴，ME迪姆，EG谢帕德，方黎江，J李，MB泰勒，
申请(专利权)人：微软公司，
类型：发明
国别省市：US[美国]
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。