CN101960454A - 多维数据库体系 - Google Patents

多维数据库体系 Download PDF

Info

Publication number
CN101960454A
CN101960454A CN2009801071976A CN200980107197A CN101960454A CN 101960454 A CN101960454 A CN 101960454A CN 2009801071976 A CN2009801071976 A CN 2009801071976A CN 200980107197 A CN200980107197 A CN 200980107197A CN 101960454 A CN101960454 A CN 101960454A
Authority
CN
China
Prior art keywords
data
attribute
row
cluster
group
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN2009801071976A
Other languages
English (en)
Inventor
奥里·赫恩施塔特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CN101960454A publication Critical patent/CN101960454A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种数据库管理系统将来自多个逻辑表的数据存储为不同格式的独立副本。在一个特定示例中，所述系统将表组织为表群组并且对每个表群组中的表进行反规范化。其还以包括垂直列容器的第二格式对数据进行组织，所述垂直列容器存储一个属性的所有数据，每个表以及该表内的每个属性具有一个列容器。查询的接收使得系统制定能够与容器集合中的任一个或二者进行交互的查询计划。

Description

多维数据库体系
技术领域
本发明一般地涉及信息处理系统，更具体地涉及计算机实现的数据库和促进在数据库中存储数据以及从数据库检索数据的数据库管理系统(DBMS)。
背景技术
早期的简单数据库结构包括多行或元组(tuple)和列的单个文件或表。该格式在每行唯一时是特别有用的；也就是说，没有数据是冗余的。然而，数据库迅速地变得复杂起来。它们开始包括其中每行并不唯一的信息。例如，考虑包含与作者以及他们所写的书籍有关的信息的数据库。如果作者已经写了多本书籍，则简单数据库模式中的每一行将包括作者的姓名以及一本书籍的标识。从而如果一位作者写了“n”本书籍，则表将包括“n”行；并且该作者的姓名将在这“n”行中的每一行中出现。
诸如作者姓名的相同值在多行中的该重复被称作“冗余”。冗余带来了特定问题。例如，存储冗余数据不必要地消耗存储器，并且存储器在当时是有限且昂贵的。该问题已经随着时间而被最小化。然而，还没有被最小化的问题包括改变数据的更新以及保持一致数据的需要。如果数据库包括作者及其地址并且一个作者的地址有所改变，则必须要改变用于该作者所写的每本书籍的记录中的该地址。如果更新过程由于任何原因而中断，则该作者的一些地址可能已经改变而其它则没有。所产生的数据将是不一致的。保持数据一致性是当前数据库所必需的。
接着研发出了关系数据库管理系统(RDBMS或“关系模型”)。这些系统仍然作为现有数据库管理系统(DBMS)的规定的基础。在20世纪70年代引入的关系模型倡导数据独立，通过形式代数以及相关联的被称作结构查询语言(“SQL”)的描述查询语言支持。在该语言中，“SQL查询”或“查询”是与各种表中的数据进行交互的主要工具。
通常，RDBMS系统根据表中的关系存储模式存储数据。每个表在数据存储机构中被存储为行的序列集合，所述数据存储机构诸如盘、主存储器和其它存储器。许多系统还将索引实现为额外的数据结构以使得能够对特定的一行或多行进行快速的随机访问。索引以促进基于键值而导航到行的方式对一列或若干列(索引的键)进行编码。每个索引导致了在数据改变的情况下构造和维护索引数据结构的增加成本。然而，用户被呈现以作为表的数据的非冗余视图，并且通常意识不到这点和其它的潜在冗余。
两个其它概念也在该研发期间得以融合，即“规范化”和“关系”。“规范化”通过将数据划分为多个表而使得冗余最小化。在之前的示例中，对单个冗余的作者-书籍表进行规范化产生独立的作者和书籍表。作者表包括与一个时期的每个作者相关的信息；书籍表则包括与一个时期的每本书籍相关的信息。
图1以逻辑形式公开了简单的规范化数据库30，其记录了与每个作者和书籍相关的信息，以及与多个顾客、他们的订单和与每个订单相关联的书籍中的每一个相关的信息。该信息的组织将包括数据信息的分析以利用单独的表定义“规范化”数据库。一个或多个单独的表可以是相关的。例如，出于解释的目的，假设数据库设计者对图1中的该数据进行分析，并且任意定义了相关表的三个群组，诸如作者群组31、客户群组32和状态群组33。作者群组31包含与作者及其书籍相关的所有信息，并且包括作者表34和书籍表35。客户群组32与客户及其订单相关，并且包括客户表36、订单表37和项目表40。状态群组33与状态信息相关，并且包括状态表41。显而易见的是，状态群组能够包括多个表，并且项目表40可以是作者群组31的成员。
虽然图1描绘了这些单独的表之间的关系，但是所述关系不是明确定义的。相反，主键和外部键提供了能够根据其定义关系的信息。存在许多字段命名惯例，尤其是关于命名主键和外部键。该讨论假设在一个表中向主键名称添加前缀“fk”来形成另一相关表中的外部键名称。在该特定示例中，作者表34包括主键字段AUTHORID；书籍表35中外部键字段为fkAUTHORID。这样的关系通常被描述为一对多关系，原因在于书籍表35的多行中的相同外部键与每个作者相关。也就是说，单个或者“一个”作者链接到一个或多个该作者所写的书籍，例如“许多”书籍。图1中的链接42在逻辑等级表示了AUTHORID和fkAUTHORID字段所定义的关系。
图1中的客户群组32包括通过链接43和链接46所定义的类似一对多关系。两个链接44和45定义了不同群组中的表之间的关系。链接44将作者群组31中的表链接到客户群组32中的表。特别地，项目表40具有外部键fkORDERID和fkBOOKID。外部键fkORDERID将一个项目链接到一个订单。外部键fkBOOKID将一个项目链接到一本书。链接45利用客户表36中链接到状态表41中的STATEID字段的fkSTATEID字段定义了客户表36和状态表41之间的关系。
在图1利用一些也称作“属性”的代表性字段描绘了每个表的同时，图2利用行、列和代表性数据以数据图表描绘了所述表。每个表具有主键；一些具有外部键。更具体地，作者表34包含主键AUTHORID加上作者的姓氏、名字、出生日期和可选联系信息的属性。书籍表35包括主键BOOKID、外部键fkAUTHORID以及标题、定价(LIST)、出版日期(PUBLISHED)和描述的属性。出于该讨论的目的，假设每本书仅由一位作者所写。其余表和属性的组织对于本领域技术人员是显而易见的。
SQL查询从数据库请求信息并且创建所请求信息的“结果集合”。“结果集合”是在存储器中保存数据副本的对象并且与数据源断开连接。最为常见的SQL查询或命令检索数据并且利用声明性SELECT关键词以及若干可选关键词和从句来执行，包括FROM、WHERE、GROUP BY、HAVING和ORDER BY从句。对任意查询的响应必须从不同文件位置独立检索每个所识别的表，并接着根据关系对来自不同表的相应行进行匹配。
WHERE从句的内容明确定义了与请求相关的每个关系并且提供了作为“连接(join)”操作的基础的“反规范化”信息。WHERE从句尤其定义了所要连接的表以及提供关系的字段或属性。例如，要定义作者和书籍表34和35之间的关系的WHERE从句将识别作者表34和主键AUTHORID以及书籍表35和外部键fkAUTHORID。也就是说，WHERE从句的执行使用主键AUTHORID和外部键fkAUTHORID连接两个表以再生其中每行将包括作者的信息以及一本书籍的标识的原始数据。查询响应必须对所需要解决的每个关系执行一次连接操作。
有效执行连接操作是困难的。这样的低效性在诸如图1和2所示的相对小的数据库中是可以容忍的。然而，现实的数据库变得日益复杂。客户实体可以包括许多等级的信息，包括订单、项目、地址、电话、交互历史和到其它家庭成员的链接。规范化将每个等级的信息放置在专门的表中。在数据库具有许多具有复杂关系的表时所存在的关系增加了连接的数目。在大小和复杂度的量级高于如图1和2所示数据库的量级的数据库中，连接操作的低效性的累积效应是无法容忍的。
正常情况下，数据库在包括盘片、主存储器、缓存和其它存储器的数据存储设备中单独或组合存储和处理。每个这样的存储器具有反应时间特性。通常，“反应时间”是在对数据的请求和开始实际数据传输之间所流逝的时间。例如，盘片延迟具有三个分量，即查找时间、旋转反应时间和传输速度。查找时间是盘片头移动到正访问的盘片柱面所需时间的量度。旋转反应时间是特定盘片块到达盘片头所需时间的量度，而传输速度(“带宽”)是数据以其在盘片头下通过的速率的量度。对于顺序访问而言，查找和旋转时间的确定仅需要对于第一数据块发生。
对于读和写操作而言，盘片和存储器带宽随时间的改进已经使得能够进行非常高效的顺序访问。然而，盘片和存储器反应时间却没有相应得以改进，使得随机访问非常低效。带宽与反应时间相比的显著改进意味着顺序访问变得比随机访问更为“廉价”。此外，顺序访问优于随机访问的性能优势随时间呈指数增加。对各个表的访问可能需要广泛的随机盘片和存储器访问，尤其在连接操作期间更是如此。访问客户实体的所有部分要求大量的随机访问，所述客户实体每个存在于离散表中单独的行中。这进一步增加了有效执行连接操作以及其它查询操作的难度。
SQL查询在两组数据库交互应用中得以使用，也就是OLTP(联机事务处理)和OLAP(联机分析处理)，其最初被称作DSS(决策支持系统)应用。OLTP应用处理联机事务。使用传统的存储方案，与这样的事务相关联的信息能够被有效添加到单个表或者从单个表进行检索，诸如图1所示的那些表中的任意一个。然而，随着实体跨越来越多的表，所增加的连接操作和随机访问的成本使得这样的查询愈发低效。
对于具有简单关系的小型数据库而言，能够以合理的效率对针对信息的OLAP应用请求进行处理。在复杂数据库中，OLAP应用从包含许多行的表内的仅几列搜索、检索并整合数据。必须针对没有被索引的任意维度或者没有预先计算的任意聚合对每个表进行全面扫描。结果，针对相对复杂的关系数据库的任意分析查询不太可能都会在合理时间内产生结果数据集。
例如，图3A描绘了试图列出给定客户所预定的每本书的标题和销售价格的OLTP查询50。SELECT从句51以每个项目一行的方式定义了从客户表36所选择的客户的姓氏和名字、从书籍表35所选择的书籍标题以及从项目表40所选择的销售价格的最终结果数据集。
FROM从句52标识了要在SQL查询50的执行期间访问的每个表。在该特定示例中，所述表分别是客户、订单、项目和书籍表36、37、40和35。
WHERE从句53标识了要从每个表检索的行并且建立连接。在该示例中，第一条件54要求客户表36中的CUSTOMERID值等于订单表37中fkCUSTOMERID字段中的值。条件55和56在订单表37中的ORDERID字段和项目表40中fkORDERID字段中的值之间以及书籍表35中的BOOKID值和项目表40中的fkBOOKID字段之间建立类似的关系和连接。最后的条件57建立客户表36中的CUSTOMERID字段等于“20”的标准。
如图4中逻辑示出和已知的，数据处理系统58响应于SQL查询50的接收以通过对该SQL查询进行解析、优化和执行来产生最终的结果集合。查询解析器59使用数据字典60中的信息将每个SQL查询转换为一系列SQL类。查询优化器61响应于SQL查询以及来自查询解析器59和数据字典60的信息生成查询计划。执行单元62对所述查询计划以及来自数据字典60和数据存储63的信息进行处理以产生结果集合。
通常来说，数据字典包括具有数据元素的定义和表示的元数据。在DBMS的背景下，数据字典是表和视图的集合，并且保持与数据元素的定义相关的信息、用户名、行和特权、模式对象、完整性约束、存储过程和触发器、一般数据库结构和空间分配信息。在该实施例中，图4中的数据字典60包括表条目的集合64。集合64中的每个表条目包括属性或字段定义的集合65。集合65中的每个定义包含每个属性或字段的特性的集合66。
改变日志67促进了所有数据插入、删除和更新操作的持久性。如已知的，诸如改变日志67的改变日志记录诸如盘片或光驱的任意类型的非易失性存储装置中的任意改变。
数据库系统可以在任意处理系统中操作并且使用任意数量的计算机、进程、线程等。每个应用可以被多次复制或例示以满足性能或其它考虑。此外，不同系统可以以不同方式来处理SQL查询。图3B描绘了一种用于图3A中的SQL查询50的这样的查询计划70；并且图3C和3D描绘了在执行单元62对查询计划70进行处理时将产生的中间和最终结果集合。一起参见图3B和3C，最初的步骤71将定义第一中间结果集合71A，其包括客户表36中CUSTOMERID值为“20”的记录。在该特定示例中，该第一结果集合将仅包含来自客户表36的一条记录。将显而易见的是，这样的选择将响应于姓名信息来进行以包含CUSTOMERID值，所述姓名信息在该示例中为客户Adam Apple。
步骤72表示第一连接操作，其中订单表37将被扫描以识别与CUSTOMERID＝20相对应的任意订单。因此，步骤72产生第二中间结果集合72A，其将包含来自订单表37的与Adam Apple相关的每条记录以及客户数据。
第二连接操作73使用中间结果集合72A中的主键ORDERID值以及项目表40中的fkORDERID值来识别Adam Apple已经进行了预定的那些项目。将产生第三结果集合73A。第三连接操作74将在步骤73中把那些行进行合并以产生结果集合，其具有步骤73A的结果集合中的通过外部键fkBOOKID的值和书籍表35的主键BOOKID的值而来自书籍表35的相应书籍，以产生第四结果集合74A。投影操作75将该第四结果集合74A转换为最终的结果集合75A，其包括如SQL查询50所定义的客户的姓氏和名字以及Adam Apple所购买的每本书的销售价格和标题。
虽然图3A中SQL查询50的所需结果相对简单，但是系统必须访问四个不同的表并且处理三个连接操作以重新组合客户实体并且提取相应的书籍标题。此外，客户实体的每个部分存在于不同表中，使得必须利用低效的随机访问来独立访问每个订单和每个项目。
作为更具分析性的查询的示例，图5A描绘了假设书籍价格和项目价格不同的情况下用于按州获取书籍的平均现金折扣的SQL查询80。SQL查询80包括SELECT语句81，其识别两个要素，即州代码和所计算的现金折扣值。所述折扣值被建立为图2的书籍表35的LIST属性所记录的书籍定价和项目表40中的SALE属性所记录的实际销售价格之间的现金差值。在该特定的SQL查询中，FROM语句82识别客户表36、订单表37、书籍表35和州表41。WHERE语句83建立了四个条件，由此以与关于图3A所描述的相同方式建立了适当的关系。GROUPBY语句84涉及对所要分组的多个列的处理。这使得能够利用一条命令对多个列执行整合功能。最后的结果集合产生一个两列报告。一列包含州名；而另一列则包含针对该州客户的所有销售的平均现金折扣。
图5B描绘了与图3B所示类似的用于对图5A中的SQL查询80进行处理的过程。在该示例中，WHERE从句定义了产生所需结果所必需的四个连接。更具体地，查询计划90最初将识别客户表36。第一连接操作91将响应于图5A中WHERE从句83的第一元素关于在CUSTOMERID值将客户表36和订单表37连接起来。第二连接操作92将把操作91所产生的数据集合与项目表40连接起来。第三连接操作93接着将基于连接操作92的输出以及来自书籍表35的相应值产生结果集合。最后的连接操作94将把连接操作93所产生的结果集合与州表41中的数据相结合。投影操作95将生成州代码、书籍价格和项目价格的值。整合操作96将基于州代码生成折扣价格的平均值并且在97产生结果集合。如将显而易见的，一旦构建了查询计划90，执行单元63将处理查询计划90并生成指定的结果集合。
虽然图5A中SQL查询80的所需结果仅对三列进行运算并且似乎相对简单，但是系统必须处理四个连接操作，这是因为所需的数据存在于五个独立的表中。即使连接操作相对有效的实施方式也需要显著的系统资源。随着表的大小增加，连接实现也会受到影响。当必须处理大量连接操作时，处理延迟会增加，有时会达到不可接受的水平。尽管存在这些问题，但是大多数数据库继续在紧密遵循关系逻辑数据模型的规范化表中存储数据，作为由序列行和属性列构成的多个相关的表。表之间的逻辑关系通常不影响数据在表中实际存储的方式。数据库系统必须执行连接来为所有的表建立关系，并且需要大量的随机访问来匹配相关的部分。
另一种在诸如图1和2所示的各种表中存储数据的方法认识到了之前的问题，并且提出通过垂直定位表的所有列来存储数据库的表。当处理OLAP应用时，这优化了用于检索的数据。例如，French的美国专利No.5794229(1998)公开了这样的存储方案。该系统使用诸如图1所示的传统逻辑关系数据库管理系统表。相反，不同于如本说明书图2所示的以传统的行结构存储数据，所述系统仅通过属性名称以列存储数据。每一列包括以相邻的方式在数据页面上进行布置的多个单元(即，特定记录的列值)，在本公开中图1的背景下，表34至37、40和41中的每个表将以列配置进行存储。
响应于查询，该系统仅分析感兴趣数据的那些列并且使用优化器来选择表的连接顺序。所述系统不对由查询很不感兴趣的信息所构成的基于行的数据页面进行检索。如果不是完全包含，所检索的基于列的页面也将很大程度上包含查询所感兴趣的信息。这允许更大的块I/O传输以及由此更快的执行OLAP类型的查询。由于仅有主键和外部键列中的数据需要检索和连接，所以每个连接操作的执行都可以有所改善。然而，所有的列都需要被连接。因此，连接操作的数量根据属性的数量而不是表的数量进行增长。基于列的系统仅对于低投射性(projectivity)和低选择性的查询良好工作。换句话说，这些系统适用于仅有一些属性被投影，并且来自大比例的行的数据被使用的查询。执行每个表访问许多属性的查询将会是非常低效的，原因在于其需要对相同表中的所有属性执行许多连接。因此，即使处理最为简单的OLTP查询也会是非常低效的。例如，仅检索图1和2中的客户表36中的一行也需要取出均位于不同列中的7个属性值。
Sah等人的美国专利No.7024414(2006)也公开了列数据的存储。该系统将表的数据解析为值的列。每列被格式化为数据流以便作为数据的连续带传输到存储装置。公开了单列和多列存储结构。每列被存储为作为压缩数据的连续带的数据流而与存储装置的页面大小无关。
这些方法通过对关于使用模式的查询处理的存储进行优化而提供优势，所述使用模式诸如访问许多行的几个完整列的OLAP应用。然而，它们对OLTP查询进行处理时低效。此外，为了组合单个完整实体，必须利用随机访问从分立的二进制表检索每个属性。从而使用水平存储方案的系统处理OLAP查询低效，而使用垂直存储方案的系统处理OLTP查询低效。
题为“Weaving Relations for Cache Performance”(Ailamaki等人，Proc 27th VLDB Conf.Rome，2001)的文章描述了又一种可替选的数据存储方案。在传统的N元存储模型(NSM)中，数据表的行在存储器中跨页面分布。所描述的分区属性交叉(PAX)系统将每个页面中的数据转换为垂直分区以改善缓存利用和性能。然而，丢失了行格式的数据；仅存在数据的一个副本。为了重构行，需要在包含所述行的页面内的垂直分区之间执行“小型连接”。小型连接由于其并不必考虑超过一个页面而带来最少的成本。查询响应要求系统扫描每个页面，并且取出或者检索查询所定义的每个属性的垂直分区。满足条件的行或记录被识别并重构。虽然本文描述了由于这种改变而导致的性能提升，但是任何这样的系统仍然必须处理所有的连接，所有连接将利用根据NSM方案存储的数据库进行处理。此外，处理单个属性仍然需要取出并处理其中数据表的行所存在的页面的完整集合。
所提出的一种降低连接操作的成本是使用之前所定义的物化(materialized)视图而不是使用基础表来对查询进行应答。物化视图表示预先计算的查询结果，其被存储为具体的表并且可以随时间根据原始的基础表进行更新。Galindo-Legaria等人的美国专利No.6510422(2003)、Larson等人的美国专利No.6850933(2005)和Colby等人的美国专利No.6199063(2001)公开了使用物化视图以便对查询进行应答的类似方法，其也被称作“视图利用”问题。也就是说，所述方法是通过对已经以连接格式进行存储的物化视图进行处理来减少应答给定查询所需的连接操作的数量。Lohman等人的美国专利No.6356889(2002)和Tao的美国专利No.7191169(2007)给出了针对相关的“视图选择”问题的若干种方法，其中选择一组要物化的视图以使得估算给定查询集合的成本最低并且使得视图保持在预先定义的存储空间约束之内。物化视图方法能够针对所物化的这些连接削减连接操作成本。然而，这是以很大的确定、维护和存储视图集合的成本所实现的，并且将其应用仅局限于大多数资源密集的查询。此外，由于物化视图以高度非规范化的形式存储数据，所以它们趋于消耗大量的存储空间而使得问题甚至更加严重。
另一篇题为“A Case for Fractured Mirrors”的文章(Ramamurthy等，Proc.28th VLDB Conf.，Hong Kong，2002)描述了一种数据库镜像存储方案，其中数据依据NSM模型和分解存储模型(DSM)进行存储。对两个盘片进行镜像。在一种方法中，第一盘片以NSM格式存储数据的主要副本；第二盘片则根据DSM格式存储数据的主要副本。在另一种方法中，跨两个物理镜像存储数据的分段以在两个副本之间实现更好的负载平衡。例如，如果系统包括按照NSM和DSM模型存储的数据，则第一镜像盘片可以存储来自NSM模型的第一分段NSM0以及来自DSM模型的第二分段DSM1。相反，第二镜像盘片将存储来自DSM模型的第一分段DSM0和来自NSM模型的第二分段NSM1。虽然该系统提供了每个存储分段的复制副本，但是其主要目标是合并替代其它RAID镜像方案的镜像方案，并且其中针对不同的目的而使用不同的方案(一种用于OLAP类型的负载而另一种则用于OLTP负载)。该系统还必须对将利用根据NSM方案存储的数据库进行处理的所有连接进行处理。
需要一种数据库管理系统，其为复杂数据库产生高吞吐量并且对OLTP和OLAP查询两者的响应进行优化，并且能够处理针对信息的日益复杂的请求、日益复杂的数据模型以及日益大量的数据。还需要一种数据库管理系统，其使得存储器特别是盘片存储器中对连接的处理最小化、使得顺序访问最大化并且使得随机访问操作最小化，同时维持数据的两个完整副本。
发明内容
因此，本发明的目标是提供一种提供高吞吐量的数据库管理系统和方法。
本发明的另一个目标是提供一种数据库管理系统和方法，其以两个维度或存储方案存储表数据以便优化性能和吞吐量。
本发明的再一个目标是提供一种数据库管理系统和方法，表数据通过其被存储在沿两个维度组织的数据结构中。
本发明的又一个目标是提供一种数据库管理系统和方法，表数据通过其被存储在两个数据集合中，所述两个数据集合中的每一个以不同方式进行组织由此使得能够针对特定使用模式进行顺序访问。
本发明的再一个目标是提供一种数据库管理系统和方法，其中以经修改的行格式存储数据的第一副本，并且以列格式存储数据的另一副本。
本发明的再一个目标是提供一种数据库管理系统和方法，通过其传统查询被转换为查询计划，所述查询计划确定是访问以经修改的行格式的数据副本还是以列格式的数据副本。
本发明的再一个目标是提供一种数据库管理系统和方法，其中以嵌入连接信息的经修改的行格式存储数据副本。
实现本发明的最佳方式
依据本发明的第一方面，一种数据库管理系统包括用于逻辑数据库模型的数据的数据库存储，所述逻辑数据库模型包括至少一个表群组，其中每个表群组包括一个根表以及与其相关的至少一个其它表，并且其中每个逻辑表被表征为具有属性列和数据行。所述数据库存储包括第一和第二数据存储。所述第一数据存储以第一维度定位在多个存储器位置中的数据库中的所有数据，其中所述多个存储器位置中的每一个包括来自根表中一行的所有数据以及来自与那一个根表行的数据相关的该表群组中的其它表的所有相关数据。该存储方案允许对该根表行及其在其它相关表中的其相关行中的所有数据进行顺序访问。所述第二数据存储以第二维度在多个存储器位置中定位所述数据库中的所有数据，其中每个存储器位置包括来自数据库中的属性中的一个的所有数据以及所有的相应值，由此允许对每个属性中的数据进行顺序访问。
依据本发明的另一方面，对逻辑数据库模型中所包含的数据生成数据结构，所述逻辑数据库模型具有处于不同关系的表和数据字典。基于所述数据字典中的数据从逻辑数据库中的表形成表群组，对于每个表群组，包括根表和与其相关的表。为所有表群组创建第一数据存储单元，在其中以第一维度存储所述数据库的数据，其中多个存储器位置中的每一个包括来自所述根表中一行的所有数据以及来自相关表的相关数据，由此允许对该根表行和相关表行中的所有数据进行顺序访问。创建第二数据存储单元，用于以第二维度在多个存储器位置中存储数据库中的数据，其中每个存储器位置包括来自所述数据库中属性的所有数据以及所有的相应值，由此允许对每个属性存储器位置中的数据进行顺序访问。
依据本发明的又一个方面，对逻辑数据库进行查询，所述逻辑数据库具有处于不同关系的根表和相关表以及数据字典，所述数据字典识别数据库中的每个表以及该表的表群组。每个表包括列中的属性以及行中的数据。第一数据存储单元以第一维度存储数据库中的数据，其中多个存储器位置中的每一个包括来自所述根表的一行的所有数据以及来自所述相关表的相关数据。第二数据存储单元以第二维度在多个存储器位置中存储所述数据库中的数据，其中每个存储器位置包括来自所述数据库中的属性中的一个的所有数据以及所有的相应值。响应于所述查询，识别所述查询中的表群组和表。解析查询包括将数据字典所提供的表群组中的表与所识别的查询表相比较。提取所述查询中的包含在所述数据库和查询共用的表中的属性列表。该信息使得能够识别多种处理选项中的一个。在所选择的选项下进行处理的期间，获取满足与所述表群组相关的查询的那些部分的中间结果集合。通过组合中间结果集合获得最终结果集合。
附图说明
所附权利要求特别指出并清楚地要求本发明的主题。通过结合附图阅读以下详细描述，本发明的各种目标、优势和新颖特征将更为全面地变得显而易见，在附图中相同的附图标记指代相同的部分，其中：
图1描绘了现有技术的用于样本数据库的典型关系图，所述样本数据库包括作者、书籍、客户、订单、项目和州表；
图2呈现了现有技术中图1的每个表的数据图表，其具有一些代表性数据；
图3A描绘了用于从图1和2所示的系统检索感兴趣数据的特定SQL查询；图3B描绘了现有技术的系统通过其解释命令的查询计划；并且图3C和3D共同描绘了在执行图3B的查询计划期间所产生的中间结果集合和最终结果集合；
图4是公开用于实现根据现有技术的数据库的系统单元的典型配置的功能框图；
图5A描绘了用于从图1和2所示的系统检索感兴趣数据的另一特定SQL查询；并且图5B描绘了现有技术中用于图5A的SQL查询的查询计划；
图6是公开用于实现本发明的系统单元的一个实施例的功能框图；
图7是依据本发明的第一维度的数据库的存储方案的逻辑描绘；
图8是依据本发明的第二维度的数据库的存储方案的逻辑描绘；
图9是公开在使用本发明期间所生成的数据字典的功能框图；
图10A和10B是用于产生图7和8的存储方案的过程的流程图；
图11A至11E是理解图10A和10B的过程时有用的状态图；
图12至12F共同公开了具有图2所示的数据的图7的存储方案的实施方式；
图13公开了具有图2所示的数据的图8的存储方案的实施方式；
图14、14A、14B和14C描绘了用于开发和执行在本发明的数据库管理器中有用的查询计划的过程；
图15A描绘了图14的方法所开发的用于图3A的查询的查询计划；并且图15B描绘了在执行图3A的查询期间将生成的各种结果集合；
图16描绘了图14的方法所开发的用于图5A的查询的查询计划；
图17是用于更新数据库的流程图；
图18是表示用于产生本发明的存储方案的替选方式的XML文档；以及
图19是表示来自根据图18中的信息所组织的图2的数据库的实际数据的XML文档。
具体实施方式
以上对现有技术的数据库管理系统的组织和操作的描述将有助于理解本发明及其优势。通过首先描述基础体系和存储方案的逻辑表示，并接着通过描述特定数据库的方案以及通过其处理查询的过程，能够最好地理解本发明。更具体地，图6至11E以逻辑层面呈现了这样的系统。图12A至13描绘了整合图2中的数据的第一和第二存储方案的特定实施方式。图14至16描绘了系统通过其将图3A所示的SQL查询转换为查询计划的过程。随后在图17至19中对用于更新数据库中的信息的过程以及可替选的XML实施方式进行了描述。
基础体系
图6是合并本发明的数据库管理系统100的一种实施方式的功能框图。在该基本层面，系统100与图4的系统类似，并且包括作为组件的查询解析器101、数据字典102、查询处理器103和改变日志105。如将会显而易见的，这些系统组件中每一个的特定实施方式将随本发明的特定实施方式而改变。不同于图4中的系统，在该实施例中，查询处理器103根据其所开发的查询计划与第一维度的数据存储单元106、第二维度的数据存储单元107或其二者进行交互。第一和第二维度的数据存储单元106和107中的每一个存储所有数据，但是根据不同的存储方案进行存储。结果，虽然是根据不同的存储方案，但是本发明通过保持数据的两个副本而提供了数据冗余。
第一维度的数据存储单元106
第一维度的数据存储单元106以“水平”方案存储数据使得数据易于访问。如图7所示，第一或“水平”存储容器中的数据被表征为从最粗糙的“容器”通过“集群”和“集群行”到最精细的“属性”按粒度排列。这些术语和短语中的每一个对应于图1和2所示的逻辑数据库中的某个部分。“集群行”对应于逻辑表中的一行并且包含该行中的所有数据。“集群”包含相关的集群行。“容器”包含给定表群组的所有集群。
如应用到图1中的逻辑表示，图7描绘了用于与图2中的作者表群组31相对应的“作者集群”的第一容器110。第二容器111存储包括来自表群组32的数据的“客户集群”，所述表群组32包括客户表36、订单表37和项目表40。第三容器112存储保括来自表群组33的数据的“州集群”，所述表群组33包括州表41。
在容器110中，集群113包含一个或多个相关集群行115的集合114。单个集群行包含与相应表中的一行相对应的所有属性和值。在每个集群中，第一集群行取自“根表”，为了理解本发明，所述“根表”是其中数据独立于其它表的数据的表。在图1的逻辑数据库的实施方式中，作者表34、客户表36和州表41是“根表”。
每个集群行存储在诸如直接访问的物理存储装置之类的顺序存储器的连续或邻接的存储位置中。优选地，并且为了随后将变得显而易见的原因，每个集群还应当被相邻存储以便通过在一个顺序读取操作中获取彼此相邻定位的若干结果点而使得性能最大化。在一些情况下，将所有集群存储在容器中的相邻存储位置将是有益的。然而，假设所伴随的性能衰减是可接受的，则集群行、集群或容器不必以该方式进行存储。
仍然参见图7，诸如集群行115的每个集群行包括首部116和主体117。每个首部包括描述随后的主体的内容的信息。在该特定实施方式中，每个首部包括集群行标识符(RID)字段120、集群标识符(CID)字段121、行类型字段122、属性位图字段123和属性值位置矢量字段124。
在如通过将集群行标识符(RID)字段120与行类型字段122进行串接的组合中，字段唯一识别表群组的指定容器中的行。集群标识符(CID)字段121唯一识别容器中的集群。特别地，行类型字段122识别特定表，并且RID值的顺序对应于该表中行的顺序。典型地，任意表的RID值是表的行编号。当在表中自动增量的单个属性主键可用时，RID字段120可以存储该特定行的主键值。对于其它的主键实施方式而言，RID字段120可以由独立计数器实现为添加到所述表的伪列。
对于图1的数据库而言，假设每个表具有自动增量的主键，其被用作RID。典型地，CID字段121对应于根表中相应行的RID字段120中的值。结果，集群中的第一行在RID字段120和CID字段121中具有相同的值。然而，任何任意的值系统都能够为RID字段120和CID字段121提供唯一标识符。
行类型字段122定义了主体117的数据源的性质。也就是说，如果集群行的数据来自于表，则行类型字段122识别对象所对应的特定表。其它行类型值能够识别XML归档节点、图片、DNA分段、“二进制大对象(blob)”或其它行类型。
属性位图字段123指示集群行中的每个属性是否包含数据或空值。
属性值位置矢量字段124中的数据指向主体117中的属性值，诸如属性值A 125、属性值B 126和属性值C 127。如果集群行中的数据顺序存储，则矢量可以由地址或者从基准地址的偏移量来定义。
第一维度的数据存储106中数据的这种结构提供了较大的优势。特别地，表群组中的所有记录以关系进行存储而没有冗余，不需要系统执行连接操作来从特定的表群组获得数据。例如，作者集群将包含具有作者的姓氏、名字、出生日期和联系信息的作者集群行。RID和CID字段120和121包含相应作者的主键。下一个集群行将在CID字段121中具有相同值，但是在RID字段120中具有新的值，并且将存储fkAuthorID值、该作者所写的一本书的标题、定价、出版日期和描述。该集群将包含该作者所写的每本其它书籍的其它集群行。每个其它集群行将在CID字段121中包含相同值，但是在RID字段120中包含唯一值。正是这些RID和CID字段120和121允许数据根据图1所示的隐含关系进行存储，并且准备访问与作者及其书籍相关的所有信息，而不必执行连接操作。
如将变得显而易见的，如果图1中的表具有“自动增量”类型的主键，则主键值还识别表的行。结果，RID值129直接对应于主键值；也就是说，RID属性120等同于所述主键属性。因此，不必在任意集群行115的主体117中存储主键值。如果主键和RID值不同，例如主键是电子邮件地址且不被用作RID，则主键属性被存储在主体117中。。
第二维度的数据存储单元107
现在参见图8，第二维度的数据存储单元107也包括容器。在特定实施方式中，这些是“列容器”。对于根据图8的存储方案所存储的每个表属性组合存在一个列容器。
每个列容器130包括首部131，其具有列名称字段132、列类型字段133、数据类型字段134和附加索引字段135。列名称字段132唯一识别列容器。一种识别方法包括将表名称和属性进行串接。例如，列名称字段132中的AUTHOR:LASTNAME将其与另一属性的另一列区分开来，即使所述另一列具有相同的字段名，即CUSTOMER:LASTNAME列容器。图6中的数据字典102包含该信息。
列类型字段133指示该字段的数据的结构。各种构造的示例包括固定长度或可变长度的字段以及固定长度的代码表。图6中的数据字段102包含该信息。仍然参见图8，数据类型字段134也使用数据字典的信息来识别数据的性质，所述数据进而识别该字段的存储的性质。正常情况下，列中的所有值将是允许非常有效的压缩的相同数据类型。字符串和长整数是数据类型的示例。附加索引字段135识别针对该属性存在哪些索引，并且属性可以不具有索引，或者具有一个或多个索引。例如，日期数据字段可以具有被优化以便检索日期范围的一个索引以及被优化以便找出特定日期的另一个索引。
对于具有其中值范围相对较小的“性别”等属性的列而言，代码表137指示每个代码及其含义。例如，在性别代码表中，“0”可以指示男性而“1”则为女性。属性跨幅位置矢量140在正常情况下随可变长度的数据类型使用。所述矢量中的每个位置是指向实际数据的直接或间接指针。列数据字段141包含根据首部131中所定义的格式的数据。
列容器的主要特征在于其能够通过作为列邻接地存储每个属性的值集合而被优化以用于顺序访问。也就是说，字符串数据可以以一种配置进行存储，而代码数据可以以另一种配置进行存储以便改善访问。列容器的另一优势在于能够以高度压缩的格式在列容器中存储数据。特别地，列类型字段133定义了数据的不同结构，每种结构被设计为列中的容纳特定数据类型以及数据的某些特征。例如，固定长度数据的稀疏列可以利用定义了包括BITMAP的构造以识别哪些行包括非空值的列类型字段133以及仅存储这些行的非空值的列数据字段141。
第二维度的数据存储单元107中的列容器共同提供了数据库的副本，该副本独立于第一维度的数据存储单元106中的副本。也就是说，不同于基于如现有技术中的索引的某个标准检索特定的行，列被设计为有效检索能够作为查询的结果集合的一部分进行处理的原始表的垂直部分。
如之前所提到的，表的RID字段识别该表中的行。列结构要求RID始终识别相应的列位置。也就是说，如果客户-订单-项目群组中的根表的RID为“20”，则与客户表相关联的每个列容器中的第20行必须对应于客户表第20行中的数据。因此，如果RID属性120等同于主键属性，则不必为主键创建容器。如果主键和RID值不相同，则主键属性存储在相应的列容器中。对于图1的数据库而言，第二维度的数据存储单元107包括22列而不是28列，原因在于图2中的每个表具有被用作RID的自动增量的主键。
形成数据库
如之前所提到的，SQL是为数据库设计者提供到数据库管理系统前端的熟悉界面的已知和常用标准。存储数据并且处理查询的后端的任意实现方式对于数据库设计者必须是透明的。如将要论证的，本发明提供了这样的透明，由此数据库设计者能够利用传统的SQL查询与数据库管理系统进行交互，同时前端和后端定义并填充了根据图7和8所示方案的数据库，由此获得更好的吞吐量和响应。
与现有技术相似，数据库设计者通过定义表和属性与合并本发明的数据库管理系统进行交互。外部键和主键定义了如图1的逻辑表中所示的表之间的关系。随着诸如图1中的数据库的逻辑数据库被定义或更新，本领域中已知的处理构建或更新数据字典并且更新表中的数据。依据本发明的一个实施方式，诸如图9的数据字典102的数据字典接收如图4所示的相同的基本元数据。表和属性被识别，诸如与作者表34相关联的字典元数据部分34D中所示。
本发明还需要附加信息，所述附加信息识别“表群组”，并且对于每个表群组而言，其识别“根表”以及该表群组中的表之间的关系。该信息促进了诸如图1所示的逻辑数据库根据图6的第一和第二维度的数据存储单元106和107的各自方案的物理存储。图9、10A、10B和11A至11E描绘了将图1的逻辑表转换为这些各种存储方案的过程。
首先看图10A，在创建、删除或更新关系模型中的表、关系或属性的任意时刻，即“更新事件”，过程151在步骤152开始。根据图10B所示的步骤，子程序153响应于数据字典102中的信息定义表群组。现在参见图10B，其更为详细地描绘了子程序153，随后步骤154从图9中的字典102检索关系数据模型，步骤155使用已知方法和图9的数据字典中的信息构建如图11A所示的方向图，其中所述信息包括与主键和外部键相关联的关系。
在该图中，“表”等同于“节点”；而“链接”等同于“有向边”。图11A至11E中的节点由其在图1中的相应表的附图标记加上后缀“N”进行标识；并且有向边由图1中相应链接的附图标记加上后缀“E”进行标识。例如，图1中的作者表34成为了作者节点34N，而链接42成为了有向边42E。在标识了节点之后，有向边被定义为从主键延伸到外部键。例如，在图11A中，有向边42E从具有其AUTHORID属性的作者节点34N延伸到书籍节点35N，原因在于书籍表35包含外部键fkAUTHORID。
下一个步骤156删除了任意的查找边，诸如有向边45E，现在在图11B中被示为虚线。查找边的特征在于诸如州表41的查找表和诸如客户表36的非查找表之间的高平均基数。查找表是包含键属性值的基准表，所述键属性值能够链接到其它数据并且不频繁改变。
此后，步骤156定义“根节点”。“根节点”被定义为在任意的引导(leading)查找边被删除之后不具有指向它的边的节点。在该示例中，步骤156定义了三个根节点，即作者节点34N、客户节点36N和州节点41N。
步骤157根据其“重要性”对根结点进行排序。典型地，“重要性”依赖于对每个表群组所预期或测定的更新访问频率。出于这里解释的目的，在图11B的图中所示的结构中，假设客户节点36N将具有最高的活跃性；作者节点34N具有下一活跃性级别，而州节点41N具有最低活跃性。步骤160选择最为重要并且是进入循环的入口的根节点，所述循环包括步骤161至164，其对每个根节点以及其它相关联的节点和有向边进行处理。
步骤161沿着有向边到所有所连接的节点以创建表群组定义和“定义关系”。“定义关系”对应于每个群组的形成期间所沿着的有向边。如随后将显而易见的，每个定义关系还对应于在依据图10A进行处理时由于对表群组的构建而从进一步处理中消除的连接。
在第一次迭代期间，步骤161在客户节点36N开始并且沿着有向边43E到达订单节点37N，并且沿着有向边46E到达项目节点40N。步骤161然后终止，原因在于与项目节点40N相关联的仅有的有向边，即有向边43E，指向项目节点40N。所标识的节点为其相应的表定义群组或“表群组”。在这种情况下，客户节点36N、订单节点37N和项目节点40N定义了客户表群组165，其包括分别相应的客户、订单和项目表36、37和40。有向边43E和46E建立了两个定义关系，即
(1)存储在图9的订单表37D的属性中的fkCUSTOMERID＝CUSTOMER:CUSTOMERID，和
(2)存储在项目表40D中的fkORDERID＝OREDER.ORDERID。
接着如图11C中的虚线所表示的，从该图中移除与该表群组相关联的节点和有向边。因此，在第一次迭代期间完成步骤162之后，图中仅剩下作者、书籍和州表节点34N、35N和41N。
由于存在其它的根节点，所以步骤163将控制转换到步骤164，以在步骤164中选择重要性顺序中的下一个根节点，即作者根节点34N。在第二次迭代期间，在该示例中，步骤161在作者根节点34N开始并且沿着有向边42E到达书籍节点35N。有向边43E不再指向任何其它节点，项目表40N已经在形成第一或客户群组165期间被从图中移除。因此，当该迭代完成时，出现如图11D所示的有向图。作者节点34N和书籍节点35N现在定义了如图11D所示的第二或作者群组166，其包含具有定义关系fkAUTHORID＝AUTHOR.AUTHORID的作者表34和书籍表35。仅剩余州根节点41N。
在第三次迭代期间，步骤164选择州节点41N。由于州节点41N是独立的，所以步骤161创建如图11E中所示的如州节点41N所定义的第三个表或州群组167，其仅包括州表41。由于没有剩余的有向边，所以没有定义关系。图10B中的步骤163接着转移到步骤165，其将图11E所示的信息传送到图10A中的其余过程，特别地，所述信息是客户群组、作者群组和州群组的定义。
如果在图10B的步骤157中所确定的重要性顺序有所改变，则表群组定义也将发生改变。例如，如果步骤157确定作者表是最重要的根节点，则图10B中循环的第一次迭代将产生具有作者节点34N、有向边42E、书籍节点35N、有向边44E和项目节点40N的作者群组。将生成相应的定义关系。下一次迭代将会定义具有客户节点36N、有向边43E和订单节点27N以及单个定义关系的客户表群组。根节点的顺序的确定不是关键的。如果证明了重要性的顺序不是最优的，则可以响应于所累积的统计信息对所述顺序进行人工或自动调节。
接下来，控制回到图10A，由此来自一系列嵌套循环的步骤170至174系统地对子程序153所获得的信息进行处理。在多次迭代期间，所述嵌套循环为实现图7和8的数据结构的图6中第一和第二维度的数据存储单元106和107中的每一个生成容器。对于图1的特定示例而言，在单元106中为每一个表群组形成容器，而在单元107中为每个表以及该表中的属性生成容器。特别地，步骤170确定是否需要处理任意的更多表群组。最初，所有的表群组都要被处理，从而选择一个。顺序不重要。
步骤171使用相应的元数据为该群组创建新的水平容器数据结构，所述元数据包括利用例如“长度”的属性所存储的信息以及所定义的关系。也就是说，步骤171产生与图7所示的作者容器110、客户容器111和州容器112的数据结构类似的数据结构。
接下来，系统处理表及其属性。步骤172确定群组中是否有任意的更多表需要处理。如果没有，则控制回到步骤170。如果还有更多表，则步骤173确定该表中是否还有任意的更多属性需要处理。如果没有，则控制返回到步骤172。如果有，则步骤174为该表中的每个属性创建新的列容器数据结构，每个容器具有诸如图8所示的数据结构。如之前所指出的，对于图1所示的逻辑数据库而言，系统将为作者表34创建4个列容器，为书籍表和客户表35和36中的每一个创建5个列容器，为订单表37和项目表创建3个列容器，并且为州表41创建两个列容器。
以上对图10A和10B的描述特别针对于数据库的创建。如对本领域技术人员将显而易见的，过程151能够整体或部分适用于处理关系中的任意改变，或者表的添加、删除或修改以及属性的添加、删除或修改。
其现在将有助于描述依据本发明的图6中用于图1和2的数据库的第一维度的数据存储106中的容器的存储方案的特定实施方式。图12呈现了数据存储单元106的整体逻辑组织，在如之前所描述的连续迭代之后，所述数据存储单元106具有由图10A中的步骤171所产生的其所存储的容器110、111和112。作者容器110包括每个作者的一个集群。在图2中数据的特定实施方式中，集群180存储与作者Sam Jones相关的信息；集群181则存储与Barbara Smith相关的信息。
每个集群具有一个或多个集群行。在该示例中，每个集群包括作者集群行和两个书籍集群行。在特定应用中以及依据图11E的图，作者集群180包括作者集群行182、书籍集群行183和第二书籍集群行184，数据库中由该特定作者所写的每本书籍有一个书籍集群行。Barbara Smith的集群181也包括作者集群行185和两个书籍集群行186和187。
虽然图12A和12B描绘了两个集群的细节，但是以下描述集中于图12A中的集群180。作者集群行182包括RID字段、CID字段、集群行类型、属性位图、到如集群行中存在的列出属性的指针，所有这些都如图7所示。每个集群行上部的文本仅是出于解释的目的。仅存储下部的数据。在该集群行182中，RID和CID值是相同的，指定对应于图2中根作者表34中一行的根集群行。对于该作者而言，集群行位于列容器中相应列的第200行。在该示例中，所有属性都具有值，从而所有的属性位图都具有值“1”。指针(PTR)字段直接或间接指向所述属性位图所识别的四个属性中的每一个的值。如之前所描述的，主键属性不存在于集群行的主体中，这是因为其被用作RID值，并且其连同集群行类型字段一起识别唯一的表和行。
集群行182和183中的每一个都具有不同的RID值，其对应于书籍表35或作者表群组165中的书籍的唯一值。CID字段包括与作者集群行182中的CID字段相同的值。这将书籍建立为与作者相关联。PTR字段指向属性位图所识别的五个属性中的每一个。
图12B中的集群181的集群行185、186和187中的每一个都具有与图12A中的相应集群行182、183和184类似的结构。存在突出本发明另一特征的一个差异。根据图2中的数据，Adam Apple已经提供了联系信息；Barbara Smith则还没有。在现有技术中，Barbara Smith的联系属性将以“空字段”进行存储。如所示出的，集群182中属性位图190中的“联系(Contact)”条目包含“1”并且联系属性191包含数据。在集群行185中，属性位图中的联系条目192包含“0”，并且如193处的虚线所表示的，没有为联系属性分配存储器空间。该特征消除了存储和处理联系属性193的空值的需要。如显而易见的，该特征导致减少存储空间并且简化数据设计者的SQL查询的形成。
图12C、12D和12E呈现了容器111中客户表群组165的存储实施方式，所述容器111包括来自图1和2中客户、订单和项目表36、37和40的数据。如图12中所示，客户容器111对于每个客户包括一个集群。在图2的数据的特定实施方式中，集群194存储与Adam Apple相关的信息；集群195则存储与Bonnie Bird相关的信息。
参见作为代表性示例的图12C和12D，集群194包括客户集群行200和对应于Adam Apple的两个订单的两个订单集群行201和202。每个订单集群后跟有项目集群行。特别地，订单集群行201后跟有两个项目集群行203和204，而订单集群行202后跟有单个项目集群行205。Bonnie Bird的集群195的存储遵循该组织形式。由于Bonnie Bird已经为一本书作出了一个订单，所以集群195包含客户集群行206、订单集群207和项目集群208。
由于容器167中的州表群组仅具有一个表，所以存储如图12F所示，其中容器167存储每个周的一个州集群，示出了两个州集群210个211。由于图11E在州表群组中仅包括一个节点，所以每个集群由单个集群行形成。
如之前所指出的，图6中的第二维度的数据存储107对从图1的逻辑数据库中取得的每个表-属性组合存储一个容器。如果RID字段包含主键值，则不需要对主键属性存储列。
每个容器存储首部和数据。在以下讨论中，如上下文所容许的，“首部”和“数据”被用来定义诸如首部字段的特定字段或者该字段中所包含的信息。图13描绘了图1和2的数据库的列容器的三个例示，所述数据库具有如图8所示的一般结构。仍然参见图13，每个容器包括“首部”和“数据”部分。也就是说，容器220包括“首部223”和“数据”224；容器221包括首部225和数据227，所述首部225具有诸如图8所示的矢量140的属性跨幅位置矢量226；容器222包括具有代码表231的首部230和数据232。
每个列容器中的首部包括唯一标识以及与数据的特征相关的信息。在这些例示中，所述唯一标识包括表名称和该表中属性名称的连接。例如，列容器220的标识为BOOK_LIST。因此，列220包含书籍表35中所有书籍的定价。容器221和222中的每一个表示客户表36中的姓氏和性别属性，并且分别由CUST_LASTNAME和CUST_GENDER唯一标识。
每个首部定义数据特征的部分基于数据设计者所作出的最初选择使用来自图9中的数据字典的信息。容器220定义固定长度的长整数数据；容器221定义可变长度的字符串数据；并且容器222定义具有字符串数据的固定长度的代码表。
在该实施方式中，假设表的主键为自动增量的计数器，从而计数器值连续地识别该表中的每一行。例如，容器220的数据224中的值“17.00”是指该表中的行号“1”。在该实施例中，实质上存在与每个表相关联的计数器，其识别该表中的特定行。
必要的是，任意实施方式要求任意列容器中的数据的顺序与相同表的其它列容器以相同次序。对于相同表的属性，在列容器中的每一行中将主键用作该行中数据的指针。这种形式的标识的使用独立于容器中的数据。例如，容器221能够包括具有如“JONES”的共同姓氏的多个行。姓氏的每个实例将具有唯一的标识符，即客户表36的主键值。
查询处理
现在将参考图14中用于构建查询计划的迭代程序240来描述图6中的查询处理器103、第一和第二数据存储单元106和107以及图9中的数据字典102之间响应于查询的交互。查询处理器103首先在步骤241识别所述查询所涉及的所有表群组。接着，包括步骤和子程序242至245的迭代过程在242选择所识别的表群组。查询解析器101最初使用来自所述查询和数据库的信息来识别该表群组中的哪些表与分析相关。接下来为优化阶段，在子程序244中确定将针对所选择的表群组访问多少次数据库并且对其进行处理以获得中间结果集合，所述中间结果集合具有满足该表群组的查询标准的所有数据。当步骤245确定了已经对所有相关表群组进行了分析时，连接/处理阶段246将各个中间结果集合组合为正式的结果集合，其包含查询所请求的信息。
图14B公开了解析阶段101通过其确定相关表的步骤。
特别地，步骤250使用根节点和来自数据字典的定义关系边绘制所选择表群组的第一图，由此提供与图11C中的客户表群组165的图类似的图，包含客户节点36N、订单节点37N和项目节点40N以及相应有向边43E和46E。
步骤251基于查询中的信息绘制相应的第二图，所述信息诸如以下表1和2所示。在客户表群组的情况下，步骤251使用客户表T1、订单表T2和项目表T3以及查询中的连接谓项54和55。
更为详细地，假设图3A中的查询包括表“Ti”和属性“Aj”，其中“i”和“j”表示数字，使得Ti和Aj指定表和每个表中的属性，步骤251能够如下识别形成查询的表和属性：
表1
查询识别
记忆符号    定义          属性
C
记忆符号            定义
T1          客户表        A1        tblCustomer.FirstName
T2          订单表        A2        tblCustomer.LastName
T3          项目表        A3        tblBook.Title
T4          书籍表        A4        tblItem.Sale
A5          tblCustomer.CustomerID
A6          tblOrder.fkCustomerID
A7          tblOrder.OrderID
A8          tblItem.fkOrderID
A9          tblBook.BookID
A10         tblItem.fkBookID
属性A1至A4取自图3A中的“Select”语句51；表T1至T4取自“From”语句52；并且属性A5至A10取自“Where”语句53中定义谓项的行54至57。“Where”语句53中的行57为“选择性(selectivity)”谓项。来自行54至56的连接谓项被表示为：
表2
连接谓项识别
连接谓项54    T1.A5＝T2.A6
连接谓项55    T2.A7＝T3.A8
连接谓项56    T4.A9＝T3.A10
步骤252接着分析所述图以确定哪些表和关系是两个图所共用的。换句话说，步骤252识别表群组中在查询中被涉及并且使用数据字典102中的定义关系进行连接的那些表。在该示例中，客户表群组165的分析识别了客户表群组中的所有三个表以便进行检索。由于表群组中表的集合的数据可以利用其预先连接的集群从相应集群容器中检索得到，所以无需进行表间的群组连接操作来为客户表群组中各个表定义关系。可能一些表将不与表群组中的另一个表重叠或者不连接到所述另一个表，在这种情况下，所连接的表形成被独立处理的子群组。
在图14B中，步骤253提取查询所要访问的所有属性(OT_ATT)的列表，并且其包括在一个重叠的表(OT)中而且不是主键，所述主键还用作容器中给定集群的RID。在概念上，所提取的属性列表表示列的集合，所述集合应当被访问以便使用第二维度的数据存储单元107盘片反应时间和带宽、存储器反应时间和带宽。连接操作成本的评估是处理的一个示例。典型地，这些处理对一段时间的系统操作进行统计分析并且定期执行步骤253至255的分析。例如，所述阈值能够被计算为来自表群组的能够在一个随机操作期间顺序读取的数据百分比。如果带宽允许在执行一个随机读取所花费的时间读取所选择表群组的容器中30％的集群，则该表群组的阈值可以被设置在70％。该值接着能够基于可用统计进行人工和/或自动调节。
优化阶段244使用所提取列表中的属性的数目以及PIR值作为选择若干选项之一的初始标准。在该实施例中，存在五个选项。如果在所提取列表中仅存在单个属性，则步骤256转移到步骤257以处理第一选项。由于仅有一个属性，所以仅需要扫描单个垂直容器。步骤257接着为该表群组产生中间结果集合。如果存在多于一个的属性，则步骤258检查PIR值。如果PIR值大于预先设置的阈值，则步骤258将控制转换到表示第二选项的步骤259。特别地，该决定指示图7的相应容器110中高百分比的集群需要被扫描以便获得结果集合，并且所述表群组容器中所有集群的扫描将提供最好的结果。步骤259通过对容器中的集群行进行顺序扫描来执行该任务，并且基于该表群组中的信息获得结果集合。因此，步骤259的输出为具有表群组的满足该部分给定查询的数据行的中间结果集合。
随着选择性增加或者属性比率OT_ATT/OT下降，PIR值将落到阈值以下。步骤258转移到步骤260，其执行查询中的任意相关的非连接谓项由此对相应的垂直列进行过滤。其返回作为位图的中间结果集合，所述位图表示每个相关表中所要被访问的行。
步骤261对步骤260的结果进行分析并且对若干替选的成本进行统计分析，三种这样的替选在图14B中示出并且表示第三至第五种选项。本发明上下文中的“成本”是完成操作所需时间的估计。对存储器中集群或垂直列的顺序扫描的估计是读取该数据的时间。如果所述产生该表群组的结果集合。在客户表群组的情况下，所列出的属性(OT_ATT)的数目标识客户表36、订单表37和项目表40中所有的被访问属性。参见表1，所述列表将包括属性A1-A4以及A6、A8和A10中的每一个。由于属性A5和A7中的每一个均为用作RID的主键，所以不包括它们。属性A9由于其属于另一个表群组而未被包括。
在已经完成了步骤253的动作之后，开始选择所述表群组的处理方法，其中进行选择性的评估以及表群组中将被访问的数据的百分比。现在参见图14B，在步骤254中，系统评估涉及步骤253的所提取列表中的属性的非连接谓项的选择性。在一种方法中，所述系统检查所指定的列容器或者非连接谓项中的一个或多个属性的容器。接着，其评估由预期要被选择的行数与所述列容器中行的总数所确定的百分比。当存在多个非连接谓项时，对结果进行统计组合以获得整体的选择性评估。一种简单的方法是仅对一个表中的每个经过滤属性乘以所评估的选择性。选择性能够从高选择性的“0”到低选择性的“1”改变，“1”指示与该属性相关联的所有行都将被涉及。整体选择性趋于指示将要被访问的根表行或集群的数目。以不同方式来说，整体选择性值指示当前表群组中需要被访问的集群总数的百分比。
当已经在步骤254中确定了整体选择性时，步骤255计算总体信息的百分比(PIR)。PIR值趋于指示出自需要被访问的表群组的容器中数据总量的百分比。其被计算如下：
PIR.(ESTIMATED_SELECTIVITY)*    OT_ATT
TOTAL_ATTRIBUTES_IN_OT
在图3A的查询的情况下并且参见以上的表1，OT ATT＝7并且OT＝22。如果没有选择性，则PIR＝0.58。随着选择性增加，如图3A中仅有一个客户被非连接谓项57选择的情况，PIR降低为接近于零。
步骤258将PIR值与阈值进行比较。所述阈值根据本领域已知的多个因素和处理进行设置。所要考虑的因素的示例包括表群组大小、集群或垂直列仅处于一个盘片上，则所述时间取决于到达第一位置的时间加上处理该属性的序列值中的每一个的时间。对于诸如选项4所涉及的随机操作而言，将包括对属性的每个访问的时间。
特别地，选项3计算顺序扫描表群组的水平容器110中的所有数据的成本。选项4计算顺序扫描对应于步骤253中获得的所提取属性列表的每个垂直列容器中的数据，连接这些列的成本。选项5计算从水平容器110随机检索集群的成本。
步骤262从步骤261所提供的包括三个选项的所有选项中选择具有最低成本的选项。也可以考虑其它选项。
在该实施例中，步骤263立即开始定义中间结果集合。这在多处理系统中是尤其有益的，原因在于来自步骤262的信息能够立即开始操作，并且如果存在多个表群组，则步骤263的功能能够针对用于并行处理的不同处理系统。能够使用其它替选。例如，来自步骤262的数据对应于查询计划中的步骤。这些步骤能够被缓存。接着，如在查询计划中所公开的，系统能够顺序地处理每个表群组的信息。
这结束了对在图14中的步骤242所选择的表群组的分析。在图3A的特定查询中，图14中的步骤245将控制返回至步骤242以选择第二表群组，例如，包括作者表34、书籍表35和链接42的作者表群组。当图14A中的步骤252将这些图进行重叠时，仅剩下书籍表并且感兴趣的属性仅为标题属性。对于该表群组没有非连接谓项，从而步骤254不进行过滤。结果，在255中计算的PIR值小于预先设置的阈值并且OT_ATT＝1，从而控制再次从步骤258转换到步骤260。
由于没有与垂直列相关联的非连接谓项，所以结果识别书籍表中的每个标题。在这种情况下，步骤261中的分析选择选项3，由此对书籍：标题(Book：Title)垂直列进行扫描。一旦执行，来自该扫描的结果集合将包括所有的书籍标题并且由此产生所有书籍的中间结果集合。
当已经处理了所有表群组时，步骤245将控制传送至子程序246，其利用连接/处理过程246对所收集的数据进行分析并且完成查询计划从而提供最终结果集合。
参见图14C，步骤264确定在图14B的过程已经生成的集合中是否剩下多于一个的结果集合。如果剩下两个或更多结果集合，则步骤264转换至步骤265，其选择最小的剩余结果集合；也就是说，具有最少行数的结果集合。步骤267执行与对其具有连接谓项的下一个较小结果集合的连接。所组合的结果集合替代连接的结果集合。当仅剩下一个结果集合时，执行例如归类、整合的最终处理操作以完成查询。
特别是关于图3A中的查询，最小结果集合是客户表群组的结果集合，原因在于所述查询识别了特定的客户。对该信息的处理等同于图15A中的步骤271和272。如结果集合272A所示，中间结果集合将识别特定客户、该客户所作出的每个订单以及针对每个订单已经购买的一个或多个项目，所述结果集合272A对每个项目具有一行并且具有包括外部键fkBOOKID的来自客户表36、订单表37和项目表40的所有属性的列。通过将结果集合272A与来自步骤273的书籍标题结果集合273A进行连接所得到的下一个结果集合是产生结果集合274A的连接操作274。步骤275产生投影275A，其包含SELECT从句中的所有属性。该结果由步骤276进行显示。
能够通过将图3B和15A的查询计划进行比较而意识到该系统的优势。利用本发明，初始步骤271包括客户容器中的所有集群。在步骤272通过选项4选择具有CustomerID＝20的值提供第一中间结果集合272A。没有发生连接操作，而在图3B中，需要两次连接来产生相当的结果集合。如图3B中的步骤74中的相应连接，执行连接274以产生第二中间结果集合274A，区别在于仅有所需的标题(TITLE)列被处理而不是全部的书籍表。如之前所提到的，书籍表的RID值等同于主键BOOKID。因此，由于列容器中的书籍：标题的顺序对应于RID值，所以其在逻辑上能够被认为是一个两列的表，其中第一列是BOOKID属性而第二列是标题(TITLE)属性。由于第一中间结果集合272A中每一行中的fkBOOKID值对应于书籍表中的主键，所以系统基于每个项目中的fkBOOKID字段与书籍表中的主键BOOKID之间的链接执行传统连接。更具体地，连接操作274从第一中间结果集合272A中的每一行获取fkBOOKID值，并且针对该BOOKID值访问书籍数据273A以提供相应的标题。
然而，步骤274中的连接操作仅处理来自书籍表的标题属性列273，而不是如图3B中的步骤74那样，必须从包括所有五个其它属性的完整书籍表35中提取标题属性。因此，仅对第五个数据列进行处理，由此通过减少数据传输时间以及随机访问而降低了成本，从而允许更快的操作。如在比较了图3C和15B之后将显而易见的，本发明已经将结果集合的数目从五个减少为三个，原因在于图3B中的查询计划所需要的三次连接减少为图15A的查询计划中的一次连接操作。
图5A中的查询遵循关于图14的类似路径。步骤241识别所述查询中所涉及的所有三个表群组，即客户-订单-项目表群组、作者-书籍表群组和州表群组。假设步骤242首先选择客户-订单-项目表群组，则步骤250和251的图将再次相同，由此识别客户表、订单表和项目表要被重叠。参见图14B，在所述查询中所选择的属性为CustomerID和fkSTATEID字段。由于没有非连接谓项，所以不发生过滤。从而在第一次迭代中，步骤253提取7个属性的列表，即：
(1)tblITEM.SALE，
(2)tblCUSTOMER.CUSTOMERID，
(3)tblORDER.fkCUSTOMERID
(4)tblITEM.fkBOOKID
(5)tblORDER.ORDERID
(6)tblITEM.fkORDERID
(7)tblCUSTOMER.fkSTATEId
因此，(2)和(5)是被用作RID值的属性，并且在所述表群组中有5个属性没有被用作RID，所以PIR＝1*5/11，为通常将大于阈值的PIR值。步骤258转移到步骤259，其选择第二选项以使用客户水平容器的顺序扫描来生成客户-订单-项目表群组的结果集合。
在下一次迭代中，步骤242选择作者书籍表群组并且再次将书籍表定义为仅有的感兴趣的表。接着，步骤253提取包括tlbBOOK.BOOKID和tblBOOK.LIST的列表，从而仅有一个没有被用作RID的非主键属性，从而PIR＝1*1/9。
在第三次迭代中，步骤242选择州代码。步骤253提取两个属性的列表，即tblSTATE.STATECODE和tblSTATE.STATEID属性。在这种情况下，PIR＝1*1/2。
在没有选择性的情况下，用于每个分析的PIR值对于州表群组分析为0.5，对于客户表群组为0.11，并且对于作者表群组为0.45。假设阈值被设置为约0.4，则客户-订单-项目群组的分析产生具有CUSTOMERID、fkCUSTOMERID、ORDERID、fkBOOKID和fkSTATEID属性的值的结果集合。该结果集合将具有与项目表中的项目总数相等的多个行。
作者表群组中的PIR值小于阈值，并且步骤260没有影响，原因在于没有与书籍表相关联的非连接谓项，因此步骤261通过识别定价属性的垂直列容器的扫描而选择选项3，所述定价属性中的每一个将再次识别书籍表中的所有书籍。类似地，将从STATECODE属性的垂直列容器计算州代码结果集合，其将在逻辑上包括STATEID和STATECODE的值并且将对于每个州包含一行。
图16描绘了依据本发明所开发的用于图5A中的查询的查询计划280。步骤281从tblSTATE.STATECODE垂直容器产生结果集合。步骤282表示客户-订单-项目容器中所有集群的扫描，这产生包括来自客户表的fkSTATEID属性、来自项目表的fkBOOKID属性以及来自项目表的SALE属性的结果集合283。连接操作284产生结果集合，其中步骤283的投影的每一行包括州代码。
接下来，系统使用步骤285对具有其隐含的BOOKID属性的tblBOOK.LIST垂直容器进行检索。步骤286与步骤284中的中间结果集合中的项目表的fkBOOKID属性相连接。步骤287将所述结果集合转换为包括州代码、价格和销售属性的结果集合。与图5B中的步骤88类似，步骤288基于州代码提供整合并且生成步骤289的结果。
作为比较，使用图5B的现有技术方法处理图5A中所示的查询需要四个连接操作。依据本发明并且如图16所示，该数字被减少为两个连接操作，并且其通过使用列容器而被进一步改进，所述列容器适于使得所取得的数据的量以及随机访问的数量最小化。
这些示例允许理解使用多个数据存储单元时的优势。现有技术的方法使用谓项检索表结构的行或者过滤列。然而，仍然必须执行连接操作。为了过滤没有被索引的列，需要对整个表进行扫描。包括本发明的系统存储数据的多个副本。在该特定示例中，水平数据存储单元中的一个副本存储集群在一起的相关行，由此消除了表群组内的连接成本以及对不同行的随机访问。可能在第二数据存储单元中顺序地存储列，使得对特定列的检索高度有效。这些方法在诸如集群的单元中将尽可能多的相关数据进行组合以用于查询所进行的任意动作来优化查询处理。随着数据大小、数据模型复杂度以及查询复杂性的增加，该设计中所固有的优势愈加允许更为有效的实施方式。
数据库更新
本发明使用直接的方法以用于响应于更新事件对数据库进行更新。如图17所示，程序290处理每个更新事件。最初，与每个更新查询相关联的数据存储在图6中的改变日志105中。步骤291检索需要数据改变并且被指定为“数据改变x”的改变日志条目。步骤292检查其有效性。步骤293确定改变是否有效。如果无效，则控制转换至回滚程序284，其终止任何进一步的更新。
如果数据改变有效，则步骤293转换到步骤295以选择第一维度的数据存储单元106或第二维度的数据存储单元107。步骤296对所选择的数据存储单元应用数据改变。该过程再次与现有技术中的相类似，区别在于步骤296根据所选择的数据存储而有所变化。也就是说，如果选择第一维度的数据存储106并且这表示诸如新客户的新数据，则步骤296必须对该客户形成包括客户预定项目和任意项目条目在内的集群。
如果没用成功应用改变，则步骤300将控制转换到回滚程序294。如果其成功，则步骤301确定是否有任意的其它数据存储单元有待更新。因此，如果这是包括步骤295至301的循环的第一次迭代的结束，则控制转换回到步骤295以选择第二维度的数据存储单元107。在这种情况下，通过向每个适当列容器的结尾处进行添加来应用数据。而且，如果对第二维度的数据存储单元107的改变成功，则步骤300转换回到步骤301。
如果这是第二次迭代，则步骤301将控制转换到步骤302来确定在数据改变日志105中是否剩余有任意的其它改变。一旦所有数据改变都已经成功完成，则步骤303提交改变并且终止过程290。
XML方案
合并本发明的数据库系统易于适用于存储和检索XML数据，尤其是基于已知XML数据模型的XML数据，所述已知XML数据模型也被称作XML方案或XSD。图18公开了用于图9中的客户-订单-项目表群组165的这样的XML方案。如将变得显而易见的，所述XML方案定义了与客户相关联的所有信息，包括属性、订单和项目，并且可以直接从图9中的数据字典102中进行提取而不必进行映射。
对应于图7中的容器110的“客户容器”元素310后跟有分别对应于图9中的客户表36D、订单表37D和项目表40D的客户元素313、订单元素315和项目元素317以及它们各自的属性。所述XML方案中的元素顺序遵循使用根表和定义关系在图9中的数据字典102中所定义的顺序。更具体地，所述系统通过在313包括对客户表的引用而识别并建立了该结构。这之后为一系列元素名称操作314以及用来为图1中的客户表36定义属性的319。接下来，所述系统在315识别订单表并且建立对应于图1中订单表37的属性的各种元素316。随后的语句317定义了项目表及其属性318。如对于本领域技术人员将显而易见的，图18中的XML方案便于适用于整体或部分地处理任意关系改变、表的添加、删除或修改以及属性的添加、删除或修改。
图19描绘了根据图18的XML方案的用于客户-订单-项目表群组的图2中的数据样本。特别地，图19公开了对应于图12中如图12C和12D所详细示出的ADAM APPLE 194的水平集群的这种XML数据194A。块200A对应于包含客户数据的集群194中的集群行200；在这种情况下，客户是Adam Apple。随后是识别订单的另一个块201A，其对应于集群行201。块203A和204A识别属于201A中的订单的两个项目。
在这种情况下并且如图12所示，Adam Apple具有两个订单。因此，块202A识别第二个订单，并且块205A识别与该第二个订单相关的单个项目。随后为对应于集群195的客户集群Bonnie Bird 195A的XML数据，并且其仅通过参考而被示出。因此，图19中的XML数据等同于包含所有客户集群的容器110中的数据。类似地，其它表群组被使用得自数据字典150中的信息以及水平容器中的数据的XML数据文档和XML方案进行表示。
相反，给定XML方案，能够为数据存储单元构建相应的数据模型150和数据结构。在这样的情况下，图10A中的步骤153成为冗余的，原因在于分组层级被预先定义为XML方案的一部分。因此，将不需要在图11A-E中描绘的图10B中的算法。XML方案定义能够直接在集群中定义的结构。因此，由于它们包含等同结构，所以XML数据能够被直接加载到集群中。在运行时，使用为SQL查询所开发的方法并且使用两个数据存储单元对针对所述系统的XML查询进行内部处理，并且结果作为XML数据返回。
概况来讲，依据本发明构建的数据库管理系统与利用定义属性的列和存储值的行以及相关的主键与外部键和查询之间的链接所组织的传统逻辑表图相兼容，所述查询典型地为例如如图1所示的SQL查询。例如在图6中所示，所述数据库管理系统处理每个查询以向或从不同存储单元传送数据。第一存储单元根据第一方案存储完整数据库；第二存储单元则根据第二方案进行存储。因此，依据本发明的目标，虽然依据不同的方案，但是数据库具有该数据库的冗余副本。
利用第一存储单元传送数据包括将如图1所示的图的模型中的逻辑表转换为表群组。每个表群组将包括根表以及直接或间接链接到所述根表的其它逻辑表的阵列，例如图10B和11A至11E所示。第一存储单元根据容器中的一个使用模式存储数据，例如图7中所示。每个容器对于相应根表中的每一行以及直接或间接连接到该表群组的根表的表阵列中的所有行包括至少一个所标识的集群。每个集群中的数据包括一个或多个集群行，所述集群行存储来自根逻辑表的行的数据以及来自链接到根表行中的数据的表群组中其它逻辑表的所有数据。第二存储单元根据多个列容器中的第二使用模式存储数据，例如图8中所示。对于表和其属性之一的每个组合具有一个列容器。
每个集群行中的数据在第一存储单元中顺序地存储，并且逻辑表中相应列的每个列容器中的属性值顺序地存储。根据诸如这里所公开的方案而顺序地存储数据提供了两个优势。对第一存储单元中的数据进行优化以便基于OLTP查询所表示的第一使用模式传输数据，特别是在访问将被限制到根表中的单个行或有限数目的行的情况下。对第二存储单元中的数据进行优化以便基于与OLAP查询相关联的第二使用模式传输数据，所述OLAP查询在正常情况下仅选择几列。顺序地而不是随机地存储数据提高了吞吐量，原因在于所选择的数据能够被顺序地检索。
所述数据库管理系统还包括用于检索结果集合的多个过程，例如图14至14C中所示。控制基于针对每个表群组的请求信息以及将要访问的表群组的估计比例选择多个过程中使得结果集合的接收最大化的一个过程。这通过使得处理查询以获得最终结果集合所需的时间最小化而提高了吞吐量。在所述逻辑数据库中所表示的所有连接操作中，仅需要每个表群组的结果集合之间的连接。这大大减少了连接操作的数量并且进一步改善了响应时间和吞吐量。
本发明的其它特征提供了额外的吞吐量优势。例如，在查询的处理期间动态确定将要在查询计划中表示的确切序列。如图14B所示，获取结果集合的处理在完成对每个表群组的分析时立即开始。如图14C所示，所返回的中间结果集合按照大小进行排序。这优化了建立与不同表群组的关系的那些连接的执行。
所述数据库管理系统还适于处理高度复杂的逻辑数据库表示，并且适于与诸如SQL查询的标准查询语言进行交互。除此之外并且如图18和19所示，所述系统还与XML进行交互以定义数据结构和数据改变。
已经关于某些实施例公开了本发明。将显而易见的是，可以对所公开的设备进行许多修改而不会背离本发明。例如，该公开描述了用于两个特定存储单元的数据结构。本发明同样可应用于其它数据结构。如对本领域技术人员将显而易见的，对于需要每个或两个存储单元的数据结构发生改变的事件的响应能够被修改。对于SQL查询的响应的公开能够被修改以提供不同的内部处理，并且提供其中对各个查询进行处理的序列的改变以及通过添加、删除或修改一个或多个选项所进行的检索选项的修改中的改变。

Claims (22)

1.一种数据库管理系统，包括用于存储逻辑数据库模型的数据的数据库存储装置，所述逻辑数据库模型包括至少一个表群组，其中每个表群组包括一个根表以及与其相关的至少一个其它表，每个逻辑表被表征为具有属性列和数据行，所述数据库存储装置包括：
A)第一数据存储装置，用于以第一维度在多个存储器位置中存储数据库中的所有数据，其中所述多个存储器位置中的每一个包括来自根表中一行的所有数据以及来自与所述一个根表行的数据相关的表群组中的其它表的所有相关数据，由此允许对所述根表行及其在其它相关表中的相关行中的所有数据进行顺序访问，和
B)第二数据存储装置，用于以第二维度在多个存储器位置中存储所述数据库中的所有数据，其中每个存储器位置包括来自所述数据库中的属性中的一个的所有数据以及所有的相应值，由此允许对每个属性中的数据进行顺序访问。
2.如权利要求1所述的系统，所述第一和第二数据存储装置中的存储器位置中的每一个包括邻接的存储器位置。
3.如权利要求1所述的系统，还包括数据字典，所述数据字典填充有来自所述逻辑数据库模型字典的识别不同表群组中的表之间的关系的信息，所述第一数据存储装置中的所述存储器位置存储与所述关系中的根表的一行和其它表相关的数据，从而数据结构固有地依据所述关系来链接表，由此消除了每次访问这样的关系时处理连接操作的需要。
4.如权利要求1所述的系统，其中每个表群组的数据存储在容器中，所述容器包括集群和集群行，并且其中：
i)集群行包括具有集群行标识的首部以及用于所述表群组的表中每一行的数据的主体；
ii)集群包括所述根表中的一行以及所述表群组中的每个相关表中的相应行的集群行，并且
iii)容器包括所述表群组的所有集群。
5.如权利要求4所述的系统，其中所述集群行标识包括所述集群以及所述表群组中相应表的标识符。
6.如权利要求5所述的系统，其中每个表包括其中每行的唯一标识符，并且每个所述集群标识符包括根表的唯一标识符的值，并且每个集群行标识符包括所述表中的行的唯一标识符。
7.如权利要求5所述的系统，其中每个首部还识别与集群行相关联的逻辑数据库中的表。
8.如权利要求5所述的系统，其中每个首部还包括属性标识符，所述属性标识符用于识别集群行中的每个属性以及该集群行中是否存在所述属性。
9.如权利要求5所述的系统，其中每个首部还包括指向所述集群行的主体中的属性值的指针。
10.如权利要求5所述的系统，其中每个集群行中的信息存储在邻接的存储器位置中。
11.如权利要求10所述的系统，其中每个集群中的信息存储在邻接的存储器位置中。
12.如权利要求11所述的系统，其中每个容器中的信息存储在邻接的存储器位置中。
13.如权利要求2所述的系统，其中所述第二数据存储装置包括表和属性的每个组合的列容器，每个列容器包括首部和列数据。
14.如权利要求13所述的系统，其中每个首部包括逻辑表的标识和其中一个属性。
15.如权利要求14所述的系统，其中所述容器标识由表名称和属性名称的串接所构成。
16.如权利要求14所述的系统，其中每个首部还包括列类型值，所述列类型值识别所述属性的数据的结构。
17.如权利要求16所述的系统，其中所述列类型值识别代码表，并且所述首部还包括识别每个代码的值的代码表字段。
18.如每个权利要求所述的系统，所述列类型值识别具有可变长度的值，所述首部还包括属性跨幅位置矢量，所述属性跨幅位置矢量具有指向列数据的位置的指针。
19.如权利要求14所述的系统，其中每个首部还包括数据类型字段，所述数据类型字段指示所述列容器中的数据值的性质。
20.如权利要求14所述的系统，其中每个首部还包括属性跨幅位置矢量，所述属性跨幅位置矢量指向所述列数据中的特定位置。
21.一种用于对逻辑数据库中包含的数据生成数据结构的方法，所述逻辑数据库具有处于不同关系的表和数据字典，所述方法包括步骤：
A)基于所述数据字典中的数据从所述逻辑数据库中的表形成表群组，对于每个表群组，包括根表和与其相关的表，
B)为每个表群组创建数据存储单元，用于以第一维度存储所述数据库的数据，其中多个存储器位置中的每一个包括来自所述根表中一行的所有数据以及来自所述相关表的相关数据，由此允许对所述根表行和相关表行中的所有数据进行顺序访问，和
C)对所述表群组中的每个表和属性创建另一个数据存储单元，用于以第二维度在多个存储器位置中存储所述数据库，其中每个存储器位置包括来自所述数据库中的属性的所有数据以及所有的相应值，由此允许对每个属性存储器位置中的数据进行顺序访问。
22.一种对逻辑数据库的查询进行响应的方法，所述逻辑数据库具有处于不同关系的根表和相关表以及数据字典，所述数据字典识别数据库中的每个表以及该表的表群组，其中所述表中的每一个包括列中的属性以及行中的数据，并且所述数据库以第一维度存储在一个数据存储单元中，其中多个存储器位置中的每一个包括来自所述根表的一行的所有数据以及来自所述相关表的相关数据，并且以第二维度在多个存储器位置中存储在另一个数据存储单元中，其中每个存储器位置包括来自所述数据库中的属性中的一个的所有数据以及所有的相应值，对查询的所述响应对于每个表群组包括步骤：
A)识别所述查询中的表和表群组，
B)通过将由所述数据字典所提供的表群组中的表与所识别的查询表相比较来解析所述查询，
C)提取所述查询中包含在所述数据库和所述查询共用的表中的属性的列表，
D)响应于所提取的属性的列表识别多个处理选项中的一个，和
E)处理所选择的选项以从所述数据库获得满足与所述表群组相关的所述查询的那些部分的中间结果集合中的数据，和
F)组合所述中间结果集合以获得满足所述查询的最终结果集合。
CN2009801071976A 2008-01-07 2009-01-06 多维数据库体系 Pending CN101960454A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/970,251 US8150850B2 (en) 2008-01-07 2008-01-07 Multiple dimensioned database architecture
US11/970,251 2008-01-07
PCT/US2009/030169 WO2009089190A2 (en) 2008-01-07 2009-01-06 Multiple dimensioned database architecture

Publications (1)

Publication Number Publication Date
CN101960454A true CN101960454A (zh) 2011-01-26

Family

ID=40853734

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2009801071976A Pending CN101960454A (zh) 2008-01-07 2009-01-06 多维数据库体系

Country Status (6)

Country Link
US (5) US8150850B2 (zh)
EP (1) EP2250584A4 (zh)
JP (1) JP5271359B2 (zh)
CN (1) CN101960454A (zh)
AU (1) AU2009204319B2 (zh)
WO (1) WO2009089190A2 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103294678A (zh) * 2012-02-24 2013-09-11 深圳市腾讯计算机系统有限公司 基于长度内容格式的数据存储及访问方法和系统
CN103365883A (zh) * 2012-03-30 2013-10-23 华为技术有限公司 数据的索引查询方法、装置及系统
CN103425722A (zh) * 2012-04-30 2013-12-04 Sap股份公司 无日志的原子数据移动
CN103823850A (zh) * 2014-02-13 2014-05-28 南京梅山冶金发展有限公司 一种多层结构关系数据库的存储方法
CN104166666A (zh) * 2014-05-15 2014-11-26 杭州斯凯网络科技有限公司 PostgreSQL高并发流式大数据多维度准实时统计的方法
CN104572941A (zh) * 2014-12-30 2015-04-29 杭州华为数字技术有限公司 数据存储方法、装置和设备
CN104737162A (zh) * 2012-09-06 2015-06-24 甲骨文国际公司 用于大规模集群中的分析型查询处理的自动反规范化
CN103853818B (zh) * 2014-02-12 2017-04-12 博易智软（北京）技术股份有限公司 多维数据的处理方法和装置
CN107766494A (zh) * 2017-10-19 2018-03-06 北京科技大学 材料基因工程数据的存储方法及系统
CN108920519A (zh) * 2018-06-04 2018-11-30 贵州数据宝网络科技有限公司 一对多数据供应系统及方法
CN112740199A (zh) * 2018-09-21 2021-04-30 华为技术有限公司 用于数据库查询优化的物化视图
CN113641669A (zh) * 2021-06-30 2021-11-12 北京邮电大学 一种基于混合引擎的多维数据查询方法及装置

Families Citing this family (96)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9208186B2 (en) * 2008-03-26 2015-12-08 Teradata Us, Inc. Indexing technique to deal with data skew
US20090327036A1 (en) * 2008-06-26 2009-12-31 Bank Of America Decision support systems using multi-scale customer and transaction clustering and visualization
US8078638B2 (en) * 2008-07-09 2011-12-13 Yahoo! Inc. Operations of multi-level nested data structure
US8078645B2 (en) * 2008-07-09 2011-12-13 Yahoo! Inc. Operations on multi-level nested data structure
US8285710B2 (en) 2008-10-09 2012-10-09 International Business Machines Corporation Automated query path reporting in distributed databases
US9183260B2 (en) * 2008-10-09 2015-11-10 International Business Machines Corporation Node-level sub-queries in distributed databases
US8458166B2 (en) * 2008-10-09 2013-06-04 International Business Machines Corporation Dynamic context definitions in distributed databases
US8145652B2 (en) * 2008-10-09 2012-03-27 International Business Machines Corporation Automated propagation of non-conflicting queries in distributed databases
US8458208B2 (en) * 2008-10-09 2013-06-04 International Business Machines Corporation Automated data source assurance in distributed databases
US8301583B2 (en) * 2008-10-09 2012-10-30 International Business Machines Corporation Automated data conversion and route tracking in distributed databases
US8122066B2 (en) * 2008-10-14 2012-02-21 Hewlett-Packard Development Company, L.P. Database query profiler
US10152504B2 (en) 2009-03-11 2018-12-11 Actian Netherlands B.V. Column-store database architecture utilizing positional delta tree update system and methods
US8122038B2 (en) * 2009-06-15 2012-02-21 Microsoft Corporation Period to date functions for time intelligence functionality
US8706727B2 (en) * 2009-06-19 2014-04-22 Sybase, Inc. Data compression for reducing storage requirements in a database system
US8364722B2 (en) * 2010-01-19 2013-01-29 Microsoft Corporation Hosting multiple logical databases contained in physical database
US9195657B2 (en) 2010-03-08 2015-11-24 Microsoft Technology Licensing, Llc Columnar storage of a database index
US8954418B2 (en) * 2010-05-14 2015-02-10 Sap Se Performing complex operations in a database using a semantic layer
US9959325B2 (en) 2010-06-18 2018-05-01 Nokia Technologies Oy Method and apparatus for supporting distributed deductive closures using multidimensional result cursors
US8909796B2 (en) 2010-07-06 2014-12-09 International Business Machines Corporation Storage procedures for application server session persistence
WO2012035754A1 (ja) * 2010-09-13 2012-03-22 日本電気株式会社 データ統合処理装置、システム、方法及びプログラム
US9069830B2 (en) * 2011-03-29 2015-06-30 International Business Machines Corporation Retrieving data objects
US9009138B2 (en) * 2011-06-17 2015-04-14 International Business Machines Corporation Transparent analytical query accelerator
US9116968B2 (en) * 2011-06-30 2015-08-25 Bmc Software, Inc. Methods and apparatus related to graph transformation and synchronization
US9239871B2 (en) 2011-07-06 2016-01-19 Ca, Inc. System and method for analyzing sequential data access efficiency
US9064000B1 (en) * 2011-07-19 2015-06-23 Foundationdb, Llc Operations over nested relationships using operators
US8856085B2 (en) 2011-07-19 2014-10-07 International Business Machines Corporation Automatic consistent sampling for data analysis
TWI464695B (zh) * 2011-09-22 2014-12-11 Hon Hai Prec Ind Co Ltd 基於臉部表情播放文檔的電子裝置及方法
US10331664B2 (en) * 2011-09-23 2019-06-25 Hartford Fire Insurance Company System and method of insurance database optimization using social networking
JP5813458B2 (ja) * 2011-10-27 2015-11-17 株式会社東芝 データベース装置およびデータベース装置の制御方法
US8583678B2 (en) * 2011-11-21 2013-11-12 Sap Portals Israel Ltd Graphical exploration of a database
US8768927B2 (en) * 2011-12-22 2014-07-01 Sap Ag Hybrid database table stored as both row and column store
US20130185280A1 (en) * 2012-01-12 2013-07-18 Ding Ma Multi-join database query
WO2013116308A1 (en) * 2012-01-31 2013-08-08 Kent State University Systems, methods, and software for unified analytics environments
US9336246B2 (en) 2012-02-28 2016-05-10 International Business Machines Corporation Generating composite key relationships between database objects based on sampling
US8676788B2 (en) * 2012-03-13 2014-03-18 International Business Machines Corporation Structured large object (LOB) data
US9922090B1 (en) * 2012-03-27 2018-03-20 Actian Netherlands, B.V. System and method for automatic vertical decomposition of a table for improving input/output and memory utilization in a database
US20130262400A1 (en) * 2012-03-30 2013-10-03 Huawei Technologies Co., Ltd. Data index query method, apparatus and system
US9230008B2 (en) * 2012-04-12 2016-01-05 Ca, Inc. System and method for automated online reorganization of sequential access databases
US9785890B2 (en) * 2012-08-10 2017-10-10 Fair Isaac Corporation Data-driven product grouping
US9563658B2 (en) 2012-08-20 2017-02-07 Oracle International Corporation Hardware implementation of the aggregation/group by operation: hash-table method
US9727606B2 (en) * 2012-08-20 2017-08-08 Oracle International Corporation Hardware implementation of the filter/project operations
US9600522B2 (en) 2012-08-20 2017-03-21 Oracle International Corporation Hardware implementation of the aggregation/group by operation: filter method
US9177026B2 (en) * 2012-09-27 2015-11-03 LogicBlox, Inc. Leapfrog tree-join
US9430550B2 (en) 2012-09-28 2016-08-30 Oracle International Corporation Clustering a table in a relational database management system
US9507825B2 (en) 2012-09-28 2016-11-29 Oracle International Corporation Techniques for partition pruning based on aggregated zone map information
US8996544B2 (en) 2012-09-28 2015-03-31 Oracle International Corporation Pruning disk blocks of a clustered table in a relational database management system
US8849871B2 (en) 2012-10-04 2014-09-30 Oracle International Corporation Efficient pushdown of joins in a heterogeneous database system involving a large-scale low-power cluster
US9824127B2 (en) * 2012-10-22 2017-11-21 Workday, Inc. Systems and methods for interest-driven data visualization systems utilized in interest-driven business intelligence systems
US9361324B2 (en) * 2012-11-06 2016-06-07 SageTea Inc. System and method to transform a complex database into a simple, faster, and equivalent database
US10754877B2 (en) * 2013-01-15 2020-08-25 Datorama Technologies, Ltd. System and method for providing big data analytics on dynamically-changing data models
GB2510429A (en) 2013-02-05 2014-08-06 Ibm Assessing response routes in a network
US10204140B2 (en) 2013-03-14 2019-02-12 Oracle International Corporation Massively parallel and in-memory execution of grouping and aggregation in a heterogeneous system
US10642837B2 (en) 2013-03-15 2020-05-05 Oracle International Corporation Relocating derived cache during data rebalance to maintain application performance
CN103336792B (zh) * 2013-06-07 2016-11-23 华为技术有限公司 数据分区方法和装置
US20150006466A1 (en) * 2013-06-27 2015-01-01 Andreas Tonder Multiversion concurrency control for columnar database and mixed OLTP/OLAP workload
US9323825B2 (en) * 2013-08-14 2016-04-26 International Business Machines Corporation Method and apparatus for storing sparse graph data as multi-dimensional cluster
CN104376025B (zh) * 2013-08-16 2017-10-10 华为技术有限公司 分布式数据库的数据存储方法和装置
US9703825B2 (en) * 2013-10-17 2017-07-11 Sybase, Inc. Maintenance of a pre-computed result set
US10339133B2 (en) 2013-11-11 2019-07-02 International Business Machines Corporation Amorphous data preparation for efficient query formulation
US9569497B2 (en) * 2013-11-26 2017-02-14 Sap Se Lock-free generation of columns with minimal dictionaries after parallel aggregation
KR20150089544A (ko) * 2014-01-28 2015-08-05 한국전자통신연구원 혼용 워크로드 지원을 위한 데이터 관리 장치 및 데이터 관리 방법
US9411838B2 (en) * 2014-02-14 2016-08-09 International Business Machines Corporation Table organization using one or more queries
US9665633B2 (en) 2014-02-19 2017-05-30 Snowflake Computing, Inc. Data management systems and methods
US9633058B2 (en) 2014-06-16 2017-04-25 International Business Machines Corporation Predictive placement of columns during creation of a large database
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
CN104090954B (zh) * 2014-07-04 2019-02-05 用友网络科技股份有限公司 只读表的连接方法和只读表的连接系统
CN105573971B (zh) * 2014-10-10 2018-09-25 富士通株式会社 表格重构装置和方法
WO2016060693A1 (en) * 2014-10-17 2016-04-21 Halliburton Energy Services, Inc. Thermally-stable, non-precipitating, high-density wellbore fluids
US10223360B2 (en) 2014-12-02 2019-03-05 Ricoh Company, Ltd. Print job archives that are optimized for server hardware
US10459913B2 (en) * 2015-02-26 2019-10-29 Red Hat, Inc. Database query processing
US20160259825A1 (en) * 2015-03-06 2016-09-08 Dell Products L.P. Discovery of potential problematic execution plans in a bind-sensitive query statement
US9952808B2 (en) 2015-03-26 2018-04-24 International Business Machines Corporation File system block-level tiering and co-allocation
CN105404638A (zh) * 2015-09-28 2016-03-16 高新兴科技集团股份有限公司 一种解决分布式跨库分片表关联查询的方法
WO2017066808A1 (en) * 2015-10-15 2017-04-20 Oracle International Corporation Database-level automatic storage management
US11520760B2 (en) * 2015-10-23 2022-12-06 Oracle International Corporation System and method for providing bottom-up aggregation in a multidimensional database environment
US9465832B1 (en) * 2016-02-04 2016-10-11 International Business Machines Corporation Efficiently committing large transactions in a graph database
US11379416B1 (en) * 2016-03-17 2022-07-05 Jpmorgan Chase Bank, N.A. Systems and methods for common data ingestion
CN106056758B (zh) * 2016-06-08 2019-01-25 广州广电运通金融电子股份有限公司 有价文件信息编解码方法、装置、处理系统及金融自助设备
US10394805B2 (en) * 2016-06-28 2019-08-27 Sap Se Database management for mobile devices
WO2018058671A1 (zh) * 2016-09-30 2018-04-05 华为技术有限公司 执行多表连接操作的控制方法及对应装置
US11074235B2 (en) * 2017-08-10 2021-07-27 Io-Tahoe Llc Inclusion dependency determination in a large database for establishing primary key-foreign key relationships
US11216451B2 (en) * 2017-09-29 2022-01-04 Oracle International Corporation Dynamic dashboard with guided discovery
US11086876B2 (en) 2017-09-29 2021-08-10 Oracle International Corporation Storing derived summaries on persistent memory of a storage device
US11182369B2 (en) 2018-04-24 2021-11-23 International Business Machines Corporation Accessing data in a multi-level display for large data sets
CN112437916B (zh) 2018-07-17 2024-08-06 雪花公司 数据库表的增量群集
US11144518B2 (en) 2018-11-28 2021-10-12 International Business Machines Corporation Detecting data mapping relationship within database system and optimizing data operation
US11163756B2 (en) 2019-04-16 2021-11-02 Snowflake Inc. Querying over external tables in database systems
US10423662B1 (en) 2019-05-24 2019-09-24 Hydrolix Inc. Efficient and scalable time-series data storage and retrieval over a network
US12008456B2 (en) * 2019-06-28 2024-06-11 Intel Corporation Methods, apparatus, systems and articles of manufacture for providing query selection systems
CN111427885B (zh) * 2020-03-03 2023-06-09 中科驭数（北京）科技有限公司 基于查找表的数据库管理方法和装置
US11232084B2 (en) * 2020-06-26 2022-01-25 Microsoft Technology Licensing, Llc Schema agnostic migration of delineated data between relational databases
CN113297207B (zh) * 2020-08-24 2024-06-07 阿里巴巴集团控股有限公司 数据处理方法、装置及设备
US11321285B2 (en) 2020-10-01 2022-05-03 Bank Of America Corporation Automatic database script generation for copying data between relational databases
CN113792095A (zh) * 2021-08-31 2021-12-14 通号城市轨道交通技术有限公司 信号系统接口信息转换方法、装置、电子设备和存储介质
KR20230118269A (ko) * 2022-02-04 2023-08-11 주식회사 티맥스티베로 스키마 레벨로 메타 정보를 관리하기 위한 방법 및 장치
US11880365B2 (en) 2022-03-23 2024-01-23 Bank Of America Corporation Multimodal and distributed database system structured for dynamic latency reduction

Family Cites Families (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5303367A (en) 1990-12-04 1994-04-12 Applied Technical Systems, Inc. Computer driven systems and methods for managing data which use two generic data elements and a single ordered file
US5794229A (en) 1993-04-16 1998-08-11 Sybase, Inc. Database system with methodology for storing a database table by vertically partitioning all columns of the table
US5918225A (en) 1993-04-16 1999-06-29 Sybase, Inc. SQL-based database system with improved indexing methodology
US5504887A (en) 1993-09-10 1996-04-02 International Business Machines Corporation Storage clustering and packing of objects on the basis of query workload ranking
US5594898A (en) * 1994-03-25 1997-01-14 Microsoft Corporation Method and system for joining database tables using compact row mapping structures
US6078925A (en) 1995-05-01 2000-06-20 International Business Machines Corporation Computer program product for database relational extenders
US5864842A (en) * 1995-10-23 1999-01-26 Ncr Corporation Optimization of SQL queries using hash star join operations
US5778350A (en) * 1995-11-30 1998-07-07 Electronic Data Systems Corporation Data collection, processing, and reporting system
US5819251A (en) * 1996-02-06 1998-10-06 Oracle Corporation System and apparatus for storage retrieval and analysis of relational and non-relational data
US6182060B1 (en) 1997-04-15 2001-01-30 Robert Hedgcock Method and apparatus for storing, retrieving, and processing multi-dimensional customer-oriented data sets
US5983215A (en) 1997-05-08 1999-11-09 The Trustees Of Columbia University In The City Of New York System and method for performing joins and self-joins in a database system
US6115705A (en) 1997-05-19 2000-09-05 Microsoft Corporation Relational database system and method for query processing using early aggregation
US5943668A (en) 1997-06-30 1999-08-24 International Business Machines Corporation Relational emulation of a multi-dimensional database
GB2329044B (en) 1997-09-05 2002-10-09 Ibm Data retrieval system
US5974407A (en) 1997-09-29 1999-10-26 Sacks; Jerome E. Method and apparatus for implementing a hierarchical database management system (HDBMS) using a relational database management system (RDBMS) as the implementing apparatus
US6199063B1 (en) 1998-03-27 2001-03-06 Red Brick Systems, Inc. System and method for rewriting relational database queries
US6513041B2 (en) 1998-07-08 2003-01-28 Required Technologies, Inc. Value-instance-connectivity computer-implemented database
CA2249096C (en) 1998-09-30 2001-12-04 Ibm Canada Limited-Ibm Canada Limitee Method for determining optimal database materializations using a query optimizer
US6772139B1 (en) * 1998-10-05 2004-08-03 Smith, Iii Julius O. Method and apparatus for facilitating use of hypertext links on the world wide web
US6415283B1 (en) * 1998-10-13 2002-07-02 Orack Corporation Methods and apparatus for determining focal points of clusters in a tree structure
US6662237B1 (en) * 1999-06-24 2003-12-09 Contivo, Inc. System for documenting application interfaces and their mapping relationship
US6952741B1 (en) * 1999-06-30 2005-10-04 Computer Sciences Corporation System and method for synchronizing copies of data in a computer system
US6484179B1 (en) 1999-10-25 2002-11-19 Oracle Corporation Storing multidimensional data in a relational database management system
US6604100B1 (en) 2000-02-09 2003-08-05 At&T Corp. Method for converting relational data into a structured document
US6785673B1 (en) 2000-02-09 2004-08-31 At&T Corp. Method for converting relational data into XML
US6611837B2 (en) 2000-06-05 2003-08-26 International Business Machines Corporation System and method for managing hierarchical objects
US6977751B1 (en) 2000-06-30 2005-12-20 Silverbrook Research Pty Ltd Print engine/controller to work in multiples and a printhead driven by multiple print engine/controllers
US6567802B1 (en) 2000-09-06 2003-05-20 The Trustees Of The University Of Pennsylvania Systematic approach to query optimization
US6801921B2 (en) * 2000-09-08 2004-10-05 Hitachi, Ltd. Method and system for managing multiple database storage units
US6510422B1 (en) 2000-09-27 2003-01-21 Microsoft Corporation Cost based materialized view selection for query optimization
US7885981B2 (en) * 2000-10-31 2011-02-08 Michael Philip Kaufman System and method for generating automatic user interface for arbitrarily complex or large databases
US6732095B1 (en) 2001-04-13 2004-05-04 Siebel Systems, Inc. Method and apparatus for mapping between XML and relational representations
US6763350B2 (en) 2001-06-01 2004-07-13 International Business Machines Corporation System and method for generating horizontal view for SQL queries to vertical database
US6868528B2 (en) * 2001-06-15 2005-03-15 Microsoft Corporation Systems and methods for creating and displaying a user interface for displaying hierarchical data
US7107255B2 (en) * 2001-06-21 2006-09-12 International Business Machines Corporation Self join elimination through union
US7024414B2 (en) 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
US6757677B2 (en) * 2001-09-28 2004-06-29 Ncr Corporation Providing a join plan using group-by operator
US20030065650A1 (en) * 2001-10-03 2003-04-03 Annand Ritchie I. Method and query application tool for searching hierarchical databases
US6850933B2 (en) 2001-11-15 2005-02-01 Microsoft Corporation System and method for optimizing queries using materialized views and fast view matching
US7693917B2 (en) * 2001-11-30 2010-04-06 Intelligent Medical Objects, Inc. Method for adaptive data management
EP1349082A1 (en) * 2002-03-28 2003-10-01 LION Bioscience AG Method and apparatus for querying relational databases
US7080081B2 (en) * 2002-04-15 2006-07-18 International Business Machines Corporation Multidimensional data clustering scheme for query processing and maintenance in relational databases
US6944627B2 (en) * 2002-04-23 2005-09-13 International Business Machines Corporation Content management system and methodology employing a tree-based table hierarchy featuring arbitrary information retrieval from different locations in the hierarchy
US7103608B1 (en) * 2002-05-10 2006-09-05 Oracle International Corporation Method and mechanism for storing and accessing data
US7191169B1 (en) 2002-05-21 2007-03-13 Oracle International Corporation System and method for selection of materialized views
US7287022B2 (en) * 2002-07-19 2007-10-23 Microsoft Corporation System and method for analytically modeling data organized according to related attributes
JP3861044B2 (ja) * 2002-10-24 2006-12-20 株式会社ターボデータラボラトリー 連鎖したジョインテーブルのツリー構造への変換方法、および、変換プログラム
US7231379B2 (en) * 2002-11-19 2007-06-12 Noema, Inc. Navigation in a hierarchical structured transaction processing system
EP1452993A1 (en) * 2002-12-23 2004-09-01 STMicroelectronics S.r.l. Method of analysis of a table of data relating to expressions of genes and relative identification system of co-expressed and co-regulated groups of genes
US6990632B2 (en) * 2003-02-28 2006-01-24 Microsoft Corporation Method and system for inferring a schema from a hierarchical data structure for use in a spreadsheet
US7054877B2 (en) * 2003-03-31 2006-05-30 International Business Machines Corporation Dealing with composite data through data model entities
US7103588B2 (en) * 2003-05-05 2006-09-05 International Business Machines Corporation Range-clustered tables in a database management system
US7530012B2 (en) * 2003-05-22 2009-05-05 International Business Machines Corporation Incorporation of spreadsheet formulas of multi-dimensional cube data into a multi-dimensional cube
US7330848B2 (en) * 2003-05-23 2008-02-12 Microsoft Corporation Method and apparatus for generating statistics on query expressions for optimization
WO2005018136A1 (ja) * 2003-07-11 2005-02-24 Canon Kabushiki Kaisha 鍵情報処理方法及びその装置、並びにプログラム
US7734581B2 (en) * 2004-05-18 2010-06-08 Oracle International Corporation Vector reads for array updates
US20060041584A1 (en) * 2004-06-07 2006-02-23 Dirk Debertin System and method for communicating with a structured query language statement generator
US7302447B2 (en) * 2005-01-14 2007-11-27 International Business Machines Corporation Virtual columns
US8112459B2 (en) * 2004-12-17 2012-02-07 International Business Machines Corporation Creating a logical table from multiple differently formatted physical tables having different access methods
US7343370B2 (en) * 2005-03-07 2008-03-11 Hewlett-Packard Development Company, L.P. Plan generation in database query optimizers through specification of plan patterns
US8201106B2 (en) * 2005-07-01 2012-06-12 Alcatel Lucent Method for transforming a tree structure into a more human-comprehensible document
US7505991B2 (en) * 2005-08-04 2009-03-17 Microsoft Corporation Semantic model development and deployment
US7567973B1 (en) * 2005-08-05 2009-07-28 Google Inc. Storing a sparse table using locality groups
US7428524B2 (en) * 2005-08-05 2008-09-23 Google Inc. Large scale data storage in sparse tables
US10007686B2 (en) * 2006-08-02 2018-06-26 Entit Software Llc Automatic vertical-database design
US8386464B2 (en) * 2006-08-18 2013-02-26 National Instruments Corporation Configuration of optimized custom properties in a data finder tool
US20080052644A1 (en) * 2006-08-25 2008-02-28 Netfortis, Inc. String matching engine for arbitrary length strings
US20080059492A1 (en) * 2006-08-31 2008-03-06 Tarin Stephen A Systems, methods, and storage structures for cached databases
US7552130B2 (en) * 2006-10-17 2009-06-23 International Business Machines Corporation Optimal data storage and access for clustered data in a relational database
US8239778B2 (en) * 2007-02-08 2012-08-07 Kgmp Trust Graphical database interaction system and method
US8069188B2 (en) * 2007-05-07 2011-11-29 Applied Technical Systems, Inc. Database system storing a data structure that includes data nodes connected by context nodes and related method
US20100017009A1 (en) * 2008-06-30 2010-01-21 International Business Machines Corporation System for monitoring multi-orderable measurement data

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103294678A (zh) * 2012-02-24 2013-09-11 深圳市腾讯计算机系统有限公司 基于长度内容格式的数据存储及访问方法和系统
CN103294678B (zh) * 2012-02-24 2016-03-16 深圳市腾讯计算机系统有限公司 基于长度内容格式的数据存储及访问方法和系统
CN103365883A (zh) * 2012-03-30 2013-10-23 华为技术有限公司 数据的索引查询方法、装置及系统
CN103425722A (zh) * 2012-04-30 2013-12-04 Sap股份公司 无日志的原子数据移动
CN103425722B (zh) * 2012-04-30 2017-08-15 Sap欧洲公司 原子数据移动的方法和系统
CN104737162B (zh) * 2012-09-06 2018-04-03 甲骨文国际公司 用于大规模集群中的分析型查询处理的自动反规范化
CN104737162A (zh) * 2012-09-06 2015-06-24 甲骨文国际公司 用于大规模集群中的分析型查询处理的自动反规范化
CN103853818B (zh) * 2014-02-12 2017-04-12 博易智软（北京）技术股份有限公司 多维数据的处理方法和装置
CN103823850A (zh) * 2014-02-13 2014-05-28 南京梅山冶金发展有限公司 一种多层结构关系数据库的存储方法
CN103823850B (zh) * 2014-02-13 2017-02-22 南京梅山冶金发展有限公司 一种多层结构关系数据库的存储方法
CN104166666A (zh) * 2014-05-15 2014-11-26 杭州斯凯网络科技有限公司 PostgreSQL高并发流式大数据多维度准实时统计的方法
CN104166666B (zh) * 2014-05-15 2017-03-08 杭州斯凯网络科技有限公司 PostgreSQL高并发流式大数据多维度准实时统计的方法
CN104572941A (zh) * 2014-12-30 2015-04-29 杭州华为数字技术有限公司 数据存储方法、装置和设备
CN104572941B (zh) * 2014-12-30 2017-12-05 杭州华为数字技术有限公司 数据存储方法、装置和设备
CN107766494A (zh) * 2017-10-19 2018-03-06 北京科技大学 材料基因工程数据的存储方法及系统
CN107766494B (zh) * 2017-10-19 2021-11-30 北京科技大学 材料基因工程数据的存储方法及系统
CN108920519A (zh) * 2018-06-04 2018-11-30 贵州数据宝网络科技有限公司 一对多数据供应系统及方法
CN112740199A (zh) * 2018-09-21 2021-04-30 华为技术有限公司 用于数据库查询优化的物化视图
CN113641669A (zh) * 2021-06-30 2021-11-12 北京邮电大学 一种基于混合引擎的多维数据查询方法及装置
CN113641669B (zh) * 2021-06-30 2023-08-01 北京邮电大学 一种基于混合引擎的多维数据查询方法及装置

Also Published As

Publication number Publication date
US20120030246A1 (en) 2012-02-02
EP2250584A4 (en) 2012-08-29
US8204885B2 (en) 2012-06-19
EP2250584A2 (en) 2010-11-17
JP2011510379A (ja) 2011-03-31
WO2009089190A3 (en) 2009-08-27
AU2009204319B2 (en) 2012-07-26
WO2009089190A2 (en) 2009-07-16
US8312020B2 (en) 2012-11-13
US9311349B2 (en) 2016-04-12
AU2009204319A1 (en) 2009-07-16
US20120030245A1 (en) 2012-02-02
US20090193006A1 (en) 2009-07-30
US8150850B2 (en) 2012-04-03
JP5271359B2 (ja) 2013-08-21
US20130031084A1 (en) 2013-01-31
US20120036167A1 (en) 2012-02-09

Similar Documents

Publication Publication Date Title
CN101960454A (zh) 多维数据库体系
Tung et al. Efficient mining of intertransaction association rules
CN108292315B (zh) 储存和检索数据立方体中的数据
US8782075B2 (en) Query handling in databases with replicated data
AL-Zawaidah et al. An improved algorithm for mining association rules in large databases
Mining Data mining: Concepts and techniques
JP5421269B2 (ja) Ｏｌｔｐデータをレポートするための、重複がないｅｔｌレスシステム及びその方法
US8065264B1 (en) Systems and methods for optimizing database queries
Mamoulis et al. Efficient top-k aggregation of ranked inputs
Agrawal et al. Asynchronous view maintenance for VLSD databases
JP3945771B2 (ja) データベース・システム
US6226634B1 (en) Association rule generation and group-by processing system
CN104199816B (zh) 单独可访问数据单元的管理存储
Plattner Sanssoucidb: An in-memory database for processing enterprise workloads
US8214408B2 (en) Method, database system and computer program for joining temporal database tables
Kozielski et al. New trends in data warehousing and data analysis
US20240330289A1 (en) Methods and systems for transforming distributed database structure for reduced compute load
Liu et al. CFP-tree: A compact disk-based structure for storing and querying frequent itemsets
Agrawal The reality of real-time business intelligence
JPH10333953A (ja) 統合データベースシステムおよびそのデータベース構造を管理するプログラムを記録したコンピュータ読み取り可能な記録媒体
Chavan et al. DEX: query execution in a delta-based storage system
Necir A data mining approach for efficient selection bitmap join index
Vaisman et al. Physical Data Warehouse Design
Lange et al. Cost-aware query planning for similarity search
Gopalan et al. Building A Data Mining Query Optimizer.

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20110126