CN1766886A - 用于数据管理和/或转换的数据结构、数据库***及方法 - Google Patents

用于数据管理和/或转换的数据结构、数据库***及方法 Download PDF

Info

Publication number
CN1766886A
CN1766886A CNA2005101188625A CN200510118862A CN1766886A CN 1766886 A CN1766886 A CN 1766886A CN A2005101188625 A CNA2005101188625 A CN A2005101188625A CN 200510118862 A CN200510118862 A CN 200510118862A CN 1766886 A CN1766886 A CN 1766886A
Authority
CN
China
Prior art keywords
data
node
subtree
subclauses
clauses
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
CNA2005101188625A
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.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
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 Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of CN1766886A publication Critical patent/CN1766886A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40Data acquisition and logging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/288Entity relationship models
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees

Landscapes

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

Abstract

一种数据库***,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联来创建目录树形式的数据库,一个或多个主题节点中的每个具有属于其中的数据,以及定义关联属性来表示相关联的关联节点与主题节点之间的关联中每一个,所述数据库***包括:目录树创建部件,用于创建关联节点中每个的关联节点条目以及关联属性中每个的关联属性条目,以及用于通过根据相应关联节点与相应关联属性之间的关联将条目相关来创建目录树;以及数据相关部件,用于根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建关联属性条目相关。

Description

用于数据管理和/或转换的数据结构、数据库***及方法
相关申请
本申请基于2004年10月25日提交的日本申请号2004-309439并要求其优先权,其公开通过引用完整地结合于本文中。
技术领域
本发明的实施例涉及用于数据管理和/或转换的数据结构、数据库***、方法及存储程序的计算机可读介质。
背景技术
关系数据库一直用于存储相关数据以及用于搜索预期的存储数据。
实例包括以下参考文献:“相关数据模型***”(Lazy Software,2000年9月),JP 2001-209647A,以及WO 00/29980,通过引用全部完整地结合到本文中。
但是,在上述参考文献中公开的方法的一部分中,不易改变已经完成的关系数据库的结构(模式)。
在上述参考文献中公开的其它方法中,数据的描述性内容变得复杂,以及数据不一定总是在存储之前被唯一地分析,因此原始数据可能不会在必要时从存储数据中准确再生。
此外,在上述参考文献中公开的方法中,当数据库分布在多个服务器当中时,不易在所述服务器当中分配负荷。
发明内容
根据本发明的一个实施例,提供一种数据库***,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关,来创建目录树形式的数据库,一个或多个主题节点中的每个具有属于其中的数据,以及关联属性被定义为表示相关的关联节点与主题节点之间的关联中的每一个。数据库***包括:目录树创建部件,用于创建关联节点中每个的关联节点条目以及关联属性中每个的关联属性条目,以及用于通过根据相应关联节点与相应关联属性之间的关联将这些条目相关来创建目录树;以及数据相关部件,用于根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
根据本发明的一个实施例,提供一种数据管理方法,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联,来创建目录树形式的数据库,一个或多个主题节点中的每个具有属于其中的数据,以及关联属性被定义为表示相关的关联节点与主题节点之间的关联中的每个。该方法包括:创建关联节点中的每个的关联节点条目以及关联属性中的每个的关联属性条目;通过根据相应关联节点与相应关联属性之间的关联将这些条目相关来创建目录树;以及根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
根据本发明的一个实施例,提供在其中存储程序的计算机可读介质。该程序用于包括计算机的数据库***中,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联,来创建目录树形式的数据库,一个或多个主题节点中的每个具有属于其中的数据,以及关联属性被定义为表示相关的关联节点与主题节点之间的关联中的每个。该程序在数据库***中运行时使计算机执行以下步骤:创建关联节点中的每个的关联节点条目以及关联属性中的每个的关联属性条目;通过根据相应关联节点与相应关联属性之间的关联将这些条目相关来创建目录树;以及根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
根据本发明的一个实施例,提供一种在其中存储数据结构的计算机可读存储器。该数据结构包括:主题节点字段,用于在其中存储属于多个对象的对象数据;关联节点字段,用于在其中存储描述所述对象之间的关联的关联数据;以及关联属性字段,用于在其中存储表示这些对象对于相关的关联所充当的角色的属性的角色数据。
根据本发明的一个实施例,提供一种方法,用于把具有由多个链接所连接的多个节点的第一数据结构转换为具有多个相关主题和关联节点的第二数据结构。该方法包括:把第一数据结构的节点中的每个转换成第二数据结构的主题节点之一;把第一数据结构的链接中的每个转换成第二数据结构的关联节点之一;在第二数据结构中,把关联节点中的每个与对应于在第一数据结构中由与所述关联节点对应的链接所连接的节点的主题节点中的两个相关联;以及在第二数据结构中,把关联属性分配给相关的关联与主题节点之间的每个关联,以便表示这些节点对于第一数据结构中的相关链接充当的角色的属性。
通过思考以下具体结合附图对具体实施例的详细说明,本发明的实施例的目的、特征和优点将会非常明显。
附图说明
在附图的各图中,以举例而不是限制的方式说明本发明的实施例,整个附图中,具有相同参考标号的部件表示相似的部件。
图1是示意图,示意说明根据本发明的一个实施例转换相关网络数据时的数据结构或模型。
图2(a)是示意图,示意说明要存储的一系列(n)相关数据,以及图2(b)是示意图,示意说明如何根据图1所示的数据模型来存储所述数据系列。
图3(a)-(b)是示意图,均示意说明根据本发明的一个实施例、表达相关节点之间的关联的方法的一个实例。
图4是示意图,示意说明根据本发明的一个实施例、表达相关网络数据的实例。
图5是本发明的一个优选实施例的框图。
图6是示意图,说明根据本发明的一个实施例的第一数据库***(DB***)的配置。
图7是示意图,说明图6所示的DB服务器和PC的硬件配置。
图8是示意图,示意说明重新排列形式的图3(a)的数据结构。
图9是示意图,示意说明一般化形式的图8的数据结构。
图10是示意图,示意说明一般化形式的图3(b)和图4的数据关联。
图11是用于存储图9所示的数据结构的数据的关联角色(AR)表的视图。
图12是用于存储图9所示的数据结构的数据的T节点标识符(ID)表的视图。
图13是用于存储图9所示的数据结构的数据的A节点标识符(ID)表的视图。
图14是示意图,示意说明根据本发明的一个实施例、在例如图6和图7所示的DB服务器中的数据搜索方法。
图15是流程图,说明在图6和图7所示的DB服务器中执行的搜索过程。
图16是流程图,说明基于图15所示的搜索过滤器的相关节点选择过程。
图17是流程图,说明获取图15和图16所示的节点ID和节点名称的过程。
图18是框图,示意说明根据本发明的一个实施例、例如在图6和图7所示的DB服务器中运行的DB程序2的结构。
图19是示意图,示意说明对图6和图7所示的DB服务器(DB程序;图18)的数据输入以及搜索条件。
图20是根据本发明的一个实施例、例如由AR条目创建单元(图18)和ARDB管理单元所创建并存储在ARDB中的AR表的视图。
图21是根据本发明的一个实施例、例如由ID条目创建单元(图18)和IDDB管理单元所创建并存储在IDDB中的T节点ID表的视图。
图22是根据本发明的一个实施例、例如由ID条目创建单元(图18)和IDDB管理单元所创建的A节点ID表的视图。
图23是示意图,说明根据本发明的一个实施例的第二DB***的配置。
图24是示意图,说明本发明的一个实施例的第三DB***的配置。
图25是示意图,示意说明图24所示的DB***中的信息的图形表示。
图26是示意图,示意说明图25所示的信息的目录信息树表示。
图27是示意图,示意说明根据本发明的一个实施例分割以目录结构表示的相关数据的方法。
图28是示意图,示意说明图27所示的DB服务器(A)的条目dn_A2与DB服务器(N)的条目dn_N之间的引用关系。
图29是根据本发明的一个实施例、用于管理在图27所示的DB服务器(A至N)中分割及存储的相关数据的目录树表的视图。
图30是根据本发明的一个实施例、用于对DB服务器(A至N)中存储的目录树(或子树)的顶部条目dn_A至dn_N以及在子树中存储的相关数据进行分类的数据表的视图。
图31是示意图,示意说明根据本发明的一个实施例、在图24所示的DB管理服务器中运行的第一DB管理程序的结构。
图32是根据本发明的一个实施例、通过使用图31所示的DB管理程序在用于输入数据的计算机(PC)的输入/输出装置(图6和图7)上显示的GUI屏幕的视图。
图33是流程图,说明根据本发明的一个实施例、采用图31所示的DB管理程序的相关数据的登记过程。
图34是流程图,说明根据本发明的一个实施例、采用图31所示的DB管理程序修改数据表(图30)的过程。
图35是流程图,说明根据本发明的一个实施例、采用图31所示的DB管理程序修改目录树表的过程。
图36是顺序图,示意说明根据本发明的一个实施例的图31所示的DB管理程序的整体运行。
图37是示意图,示意说明根据本发明的一个实施例在图24所示的DB服务器的每个中运行的第二DB程序。
图38是示意图,示意说明根据本发明的一个实施例在图24所示的检索装置中运行的搜索程序。
图39是流程图,表示采用图38所示的搜索程序的搜索过程。
图40是顺序图,说明根据本发明的一个实施例、图31所示的DB管理程序以及图38所示的搜索程序的整体过程。
图41是第一示意图,示意说明根据本发明的一个实施例在图24所示的DB***的DB服务器中登记的平面目录结构的相关数据。
图42是第二示意图,示意说明图41所示的目录结构的相关数据。
图43是第三示意图,示意说明图41所示的目录结构的相关数据。
图44是第四示意图,示意说明根据本发明的一个实施例、仅表示特定区域的销售信息、在图24所示的DB***的DB服务器中登记的目录结构的相关数据。
图45是第五示意图,示意说明根据本发明的一个实施例、表示多个区域的销售信息、在图24所示的DB***的DB服务器中登记的目录结构的相关数据。
图46是包含图44和图45所示的销售信息(相关数据)的顶部条目的目录树表的视图。
图47是根据本发明的一个实施例、在图44和图45所示的销售信息(相关数据)被分割为子树时包含其顶部条目、分类类型和分类值的数据表的视图。
图48是根据本发明的一个实施例、用于搜索图44和图45所示的销售信息的GUI屏幕的视图。
图49是示意图,示意说明根据本发明的一个实施例、由图24所示的检索装置执行以便检测要从图46和图47所示的目录树表和数据表中检索的DB服务器的过程。
图50是创建从图48所示的搜索条件中得到的并用于仅搜索图44所示的Kanto地区的销售信息的LDAP操作的搜索请求消息的视图。
图51(A)-(B)是示意图,均示意说明根据本发明的一个实施例、分别在新子树的添加之前和之后在图24所示的DB***的DB服务器中新添的子树。
图52是用于图51(A)和(B)所示的新子树的添加的搜索条件管理表的视图。
图53(A)-(B)是示意图,均示意说明根据本发明的一个实施例、分别在交换之前和之后在图24所示的DB***的DB服务器之间的子树交换/移动。
图54(A)-(B)是示意图,说明根据本发明的一个实施例、分别在更新之前和之后、参与图53(A)和(B)所示的子树交换的DB服务器的目录树表(图46)的更新。
图55是示意图,示意说明根据本发明的一个实施例的第三DB程序,它在新子树的添加及其移动/交换在图24所示的DB***中执行时在DB服务器中运行。
图56是示意图,示意说明根据本发明的一个实施例的第二DB管理程序,它在新子树的添加及其移动/交换在图24所示的DB***中执行时在DB管理服务器中运行。
图57是流程图,说明图56所示的DB管理程序的过程。
图58是示意图,示意说明根据本发明的一个实施例、在多个DB服务器上的相同层上的条目。
图59是示意图,示意说明根据本发明的一个实施例的第二搜索程序,它在新子树的添加及其移动/交换在图24所示的DB***中执行时在检索装置上运行。
具体实施方式
在详细说明本发明的实施例之前,大家要理解,本发明不限于它在以下描述中阐述或者在附图中所示的构造的详细情况以及组件配置的应用。本发明能够采用其它实施例并且能够以各种方式来实施或执行。另外还要理解,本文所使用的措辞和术语是为了便于描述而不应当被视作限制。用于标识方法或过程的步骤的字母只是用于标识而不是意味着表示这些步骤应当以特定顺序来执行。
包含各种成分的数据经过分析,并存储已分析数据。
希望在必要时,原始数据从存储数据中准确再生。
一般来说,在集合A×B的笛卡儿积的部分集合RA×B中,对于有序对(a,b)∈R的aRb表示法表示“a与b具有关系R”。作为需要被存储以及将来再生的原始数据的一个简单实例,现在考虑“剧作家莎士比亚写作戏剧哈姆雷特”。
原始数据处于二元关系。即,原始数据“剧作家莎士比亚写作戏剧哈姆雷特”可表达为“aRb”格式,其中,a为“剧作家莎士比亚”,R为“作者-作品”,以及b为“戏剧哈姆雷特”。
这样,原始数据作为“a”、“R”和“b”被存储在数据库中,并且可在必要时再生。
但是,当数据成分的数量增加时,即原始数据不是二元关系而是n元关系时,一系列这类相关数据以超图结构来表达,并且数据的处理不是简单的。
因此,采用一种把任何n元关系分解为多个二元关系、把数据分析为二元关系的组合以及在数据库中存储已分析数据的方法。
作为第一实例,现在将考虑“剧作家莎士比亚在大约1600年在英国写作戏剧哈姆雷特”。
这个实例表示一种四元关系,它被分解为六个二元关系的组合,如表1所示,因为4C2=6。
                          表1
  a   R   b
  剧作家莎士比亚   作者-作品   戏剧哈姆雷特
  剧作家莎士比亚   作者-创作时间   约1600年
  剧作家莎士比亚   作者-创作国家   英国
  戏剧哈姆雷特   作品-创作时间   约1600年
  戏剧哈姆雷特   作品-创作国家   英国
  约1600年   创作时间-创作国家   英国
换言之,对于任何给定的n,nC2二元关系的组合是表达n元关系所必需的。
随后,将作为第二实例来考虑“剧作家莎士比亚在大约1600年写作戏剧第十二夜”。这个实例表示一种三元关系,它被分解为3个二元关系的组合,即n=3,且3C2=3。结果如表2所示。
                        表2
  a   R   b
  剧作家莎士比亚   作者-作品   戏剧第十二夜
  剧作家莎士比亚   作者-创作时间   约1600年
  戏剧第十二夜   作品-创作时间   约1600年
在这种情况下,在相同数据库中第一实例的信息以及第二实例的信息的存储导致一个问题:由“剧作家莎士比亚”-“作者-创作时间”-“约1600年”组成的相同二元关系被存储。
另一个问题是判断用于表达第一和第二实例的数据的二元关系的组合中哪一个应当用来再生原始信息的不可能性。换言之,数据、例如第一和第二实例没有被唯一分析和存储。
这些问题可通过对二元关系中的每个添加标识符得到解决。但存在一个缺点,因为数据结构和处理将变得更复杂。
在关系数据库中存储二元或三元或者任何n元数据是已知的。
关系数据库包括其中存储数据项的一个或多个字段。关系数据库的一个简单实例是表格,其中,字段或数据元素以列排列,以及数据项以行排列。本文所使用的“字段”或“数据元素”被理解为数据的逻辑定义,而“数据项”则被理解为字段中存储的数据的实际单元。
现在回到第一实例“剧作家莎士比亚在大约1600年在英国写作戏剧哈姆雷特”。
(1)“谁”、(2)“什么”、(3)“何时”、(4)“何地”、(5)“为何”以及(6)“如何”可指定为数据元素或字段。
与这些字段相对应,可存储(1)“剧作家莎士比亚”、(2)“戏剧哈姆雷特”、(3)“约1600年”、(4)“英国”、(5)“空”以及(6)“写作”的数据项。
但是,下列问题是采用关系数据库存储数据的方法中固有的。
(1)以后当新数据进入时,不易添加数据元素。在由定型成分组成的数据的情况中,添加不成问题。但是,在包含各种成分的输入数据的情况下,每当带有一个或多个新数据成分的新数据进入时,需要改变数据库的模式以添加数据元素。模式改变一般是困难的,特别是在联机输入数据时。
(2)由于不易在以后添加新的字段或数据元素,因此在初始数据库构建中,模式可采用最大数量的字段或数据元素来构建。但是,字段中的许多不可能包含任何数据项。这不可避免地导致存储器使用效率的降低。
为了解决这类问题,已经提出基于“Lazy Software”Inc.(英国)开发的“相关数据模型”的数据存储方法,作为替代传统关系数据库模型的模型。
按照这个相关数据模型,根据对象之间的关联来处理信息,以及这种关联以“源-动词-目标”语法来表达。
这个模型解决了基于关系数据库的存储方法中固有的一部分问题。
但是,该相关数据模型具有下列问题。在处理复杂数据关系的情况下,表达数据之间的关系的模型的方法是复杂且不直观的。如上所述,以二元树的形式表达n元关系时,数据没有被唯一分析和存储。另外,当数据存储在数据库中时,操作员能够随意地改变数据结构。这样,原始信息可能不会准确地再生。
如上所述,关系数据库在传统上已知为存储彼此相关的多个数据的方法。
根据这个方法,字段或数据元素经过预置,以及数据项存储在这些字段中。
该方法有利之处在于,数据关系可易于理解和/或表达。但是,不易对已经构建的数据库添加新字段或数据元素、即修改已经构建的数据库的结构(模式)。
如果将来添加新字段或数据项,则将对于存储数据产生“空”条目,导致与存储器使用效率的降低有关的问题。
另一方面,在Lazy Software Inc.提出的“相关数据模型”的情况下,与添加新数据项的困难以及存储器使用效率降低有关的问题得到解决。但是,数据描述内容变得复杂,以及数据结构不直观,从而导致所分析/存储数据不唯一的另一个问题。
图1说明根据本发明的一个实施例、由主题节点111、121以及表示节点111、121与数据模型102之间关联的链接131组成的相关网络数据101。关联(链接)131在数据模型102中重新定义为关联节点132(以下称作“A节点”)。主题节点111、121对应于数据模型102中的主题节点112、122(以下称作“T节点”)。数据模型102还包括分别把T节点112、122连接到A节点132并具有反映主题节点111、121对于相关网络数据101中的关联或链接131充当的角色(以下称作“关联角色”)的属性的链接142、152。
这样,相关网络数据101转换为数据模型102。在本发明的一个实施例中,数据模型102被重新构建。在一个简单实例中,数据模型102以包括三个字段、即一个“A节点”字段、一个“T节点”字段和一个“关联角色”字段的关联角色表的形式来表示,以及从相关网络数据101中提取的信息被作为数据项输入如表3所示的这种关联角色表(以下称作“AR表”)的行(记录)中。在一个实施例中,定义为关系数据库的一部分的AR表采用关系数据库管理***来管理。
表3
  A节点   T节点   关联角色
  A1   T1   关联角色1
  A1   T2   关联角色2
因此,与某些数据(主题节点)有关的新属性信息被定义为另一个相关数据,并通过采用相应A和T节点以及节点之间的链接的组合(即根据本发明的一个实施例的数据模型中的基本成分)表达为与AR表的一行相关的数据,从而可添加新属性信息而不改变现有表格结构(数据库模式)。
此外,把标识符分配给A和T节点,从而唯一标识这些节点。对于标识符,标识符表(以下称作“ID表”)被定义,并且包含表示节点属性类型的节点类型以及表示属性值、即节点的具体内容的节点名称(表5)。
ID表由关系数据库管理***来管理,如在AR表的情况中那样。
在本发明的一个实施例中,作为描述由某个A节点表示的关联的具体含义的数据来新添加T节点,这两个节点、即预先存在的A节点和新的T节点通过预定义为“具体化”的关联角色彼此相关联。
通过进一步定义/描述新的T节点与类似地对另一个A节点添加的另一个新的T节点之间的关联,能够表达两个原始A节点所表示的关联之间的关系。
新的T节点以及特别引入以描述A节点的含义的关联角色“具体化”可通过AR表来存储/管理。
通过采用ID表和AR表来管理节点,实现能够不仅表达A与T节点之间的关联、而且表达A节点之间的关联的数据表达方法。
在先有方法中,nC2二元关系是表达一段n元数据所必需的。但是,根据本发明的一个实施例,表达相同的n元数据只需要n个关系。
换言之,根据本发明的一个实施例,当由具有一个公共关联的n个数据成分组成的数据集(图2,(a))被存储时,数据集公共的一个新节点(A节点)被添加,然后对于每个数据成分、即T节点定义关联角色(图2,(b))。
所得AR表由表4给出。
                   表4
  A节点   T节点   关联角色
  A1   T1   关联角色1
  A1   T2   关联角色2
  A1   T3   关联角色3
  A1   T4   关联角色4
  :   :   :
  A1   T(n-1)   关联角色(n-1)
  A1   Tn   关联角色n
图2(b)和表4中采用的A1是分配给相应A节点的标识符,表明数据成分(T节点具有分配到其中的其它标识符“T1”至“Tn”)具有某种公共关联。
当数据成分具有多个不同的公共关联时,具有多个不同标识符的多个A节点被添加。
此外,对于已经分配了标识符的A和T节点,创建具有作为数据属性的“节点类型”字段和“节点名称”字段的ID表,如表5所示。
                 表5
  节点ID   节点类型   节点名称
  A1   A节点类型1   A节点名称1
  T1   T节点类型1   T节点名称1
  T2   T节点类型2   T节点名称2
  :   :   :
  Tn   T节点类型n   T节点名称n
图3(a)-3(b)说明一个实例,其中T节点T1和T2通过A节点A1彼此相关,以及T节点T1和T3通过A节点A2彼此相关(图3,(a)),新增T节点(标识符T11)以描述由A节点A1所示的关联的具体含义,并根据预定义为“具体化”的关联角色与A节点A1相关。
类似地,A节点A2根据关联角色“具体化”与新的T节点T12相关,以及两个T节点T11与T12之间的关联通过采用A节点A11来定义(图3,(b))。
因此,两个原始A节点A1和A2之间的关系可通过采用与表6所示类似的AR表来表达。
               表6
  A节点   T节点   关联角色
  A1   T11   具体化
  A2   T12   具体化
  A11   T11   关联角色11
  A11   T12   关联角色12
数据存储方法/数据结构
下面将描述根据本发明的一个实施例的数据存储方法和数据结构。
作为一个具体实例,下面将考虑“剧作家莎士比亚在大约1600年在英国写作戏剧哈姆雷特”作为第一数据。
第一数据表示具有以下数据成分的四元关系:(1)“剧作家莎士比亚”、(2)“戏剧哈姆雷特”、(3)“约1600年”以及(4)“英国”。当第一数据采用先有方法分析为二元关系时,这将需要六个二元关系的组合,如表7所示,因为4C2=6。
                      表7
主题节点1   链接(关联) 主题节点2
剧作家莎士比亚   作者-作品 戏剧哈姆雷特
剧作家莎士比亚   作者-创作时间 约1600年
剧作家莎士比亚   作者-创作国家 英国
戏剧哈姆雷特   作品-创作时间 约1600年
戏剧哈姆雷特   作品-创作国家 英国
约1600年   创作时间-创作国家 英国
已分析数据根据本发明的一个实施例来转换。表7的第一记录(行)按照以下所述来转换。
主题节点1中的数据成分“剧作家莎士比亚”在这个信息中表明“剧作家”。因此,数据成分被分析为“剧作家”和“莎士比亚”,其中“莎士比亚”被设置为T节点,以及“作者”被设置为关联角色。如以下所述,“剧作家”被设置为T节点。
对于表明关联的链接“作者-作品”,对于“哈姆雷特的出处”添加A节点,从而表明信息系列属于同一组。
由于“哈姆雷特的出处”用来表明属于同一组的信息系列,因此,只要此信息可与另一组的信息区分开,则允许其它表达。
这样,表7的第一记录(行)如表8所示进行转换。
                    表8
  A节点     T节点     关联角色
  哈姆雷特的出处     莎士比亚     作者
类似地,主题节点2中的“戏剧哈姆雷特”按照表9所示进行转换,因为它在这个信息中是“作品”。另外,“戏剧”被设置为T节点。
                    表9
  A节点   T节点   关联角色
  哈姆雷特的出处   哈姆雷特   作品
随后,表7的第二记录(行)的类似转换示于表10。
                    表10
  A节点   T节点   关联角色
  哈姆雷特的出处   莎士比亚   作者
  哈姆雷特的出处   约1600年   创作时间
在这里,数据项“哈姆雷特的出处”、“莎士比亚”和“作者”可省略,因为它们是冗余的。此后,表7的全部记录(行)类似地经过转换,冗余数据被省略,结果如表11所示。
                  表11
  A节点   T节点   关联角色
  哈姆雷特的出处   莎士比亚   作者
  哈姆雷特的出处   哈姆雷特   作品
  哈姆雷特的出处   约1600年   创作时间
  哈姆雷特的出处   英国   创作国家
因此,当由具有一个公共关联的四个数据成分组成的数据集采用先有方法表达成二进制关系时,需要六个记录,因为4C2=6。但是,大家会理解,根据本发明的一个实施例,仅需要四个记录。
在一个实施例中,当具有四个数据成分的数据集被分析并存储在数据库中时,添加数据集公共的一个新节点(A节点),然后对每个数据成分定义关联角色,以及定义具有“A节点”、“T节点”和“关联角色”字段的数据库。这样,根据本发明的实施例的数据结构可重新构建。
在这里,标识符“A1”分配给A节点“哈姆雷特的出处”。大家会理解,具有公共标识符“A1”的数据属于一组。另外,标识符“T11”至“T14”分别分配给四个T节点“莎士比亚”、“哈姆雷特”、“约1600年”以及“英国”。
这样,对于第一数据创建了AR表,如表12所示。
              表12
  A节点   T节点   关联角色
  A1   T11   作者
  A1   T12   作品
  A1   T13   创作时间
  A1   T14   创作国家
表明“哈姆雷特的出处”的A节点(标识符A1)被设置为“出处相关信息”,以及已经分配了标识符T11至T14的T节点的节点类型被设置为“剧作家”、“戏剧”、“时间”和“国家”。因此,创建ID表,如表13所示。
                 表13
  节点ID   节点类型   节点名称
  A1   出处相关信息   (空)
  T11   剧作家   莎士比亚
  T12   戏剧   哈姆雷特
  T13   时间   约1600年
  T14   国家   英国
作为第二数据,将在另一个实例中考虑陈述“原著戏剧哈姆雷特的日译本由○○出版社于2003年2月出版”。
根据本发明的一个实施例,第二数据按照以下方式进行分析。在这里,所有数据成分公共的A节点是“哈姆雷特的日译本”,以及标识符“A2”分配到其中。结果如表14所示。
                 表14
  A节点   T节点   关联角色
  A2   哈姆雷特   原著
  A2   哈姆雷特   译本
  A2   2003年2月   出版日期
  A2   ○○出版社   出版
标识符“T12”已经分配给作为原著的哈姆雷特。这样,当标识符“T22”被分配给译本哈姆雷特,以及标识符“T23”和“T24”被分配给出版日期和出版商时,第二数据的AR表被表示于表15中。
               表15
  A节点   T节点   关联角色
  A2   T12   原著
  A2   T22   译本
  A2   T23   出版日期
  A2   T24   出版
另外,还创建ID表,如表16所示。
               表16
  节点ID   节点类型   节点名称
  A2   出处相关信息   (空)
  T22   戏剧   哈姆雷特
  T23   日期   2003年2月
  T24   出版商   ○○出版社
第一和第二数据以及其它这类数据存储在相同数据库中。这样,最终获得与表17和表18类似的AR表和ID表。
             表17
  A节点   T节点   关联角色
  A1   T11   作者
  A1   T12   作品
  A1   T13   创作时间
  A1   T14   创作国家
  A2   T12   原著
  A2   T22   译本
  A2   T23   出版日期
  A2   T24   出版
  :   :   :
                  表18
  节点ID   节点类型   节点名称
  A1   出处相关信息   (空)
  T11   剧作家   莎士比亚
  T12   戏剧   哈姆雷特
  T13   时间   约1600年
  T14   国家   英国
  A2   出处相关信息   (空)
  T22   戏剧   哈姆雷特
  T23   日期   2003年2月
  T24   出版商   ○○出版社
  :   :   :
此外,如图4所示,提供附加的T节点以便描述具有标识符A1和A2的A节点所表明的关联的具体含义。标识符“T31”和“T32”被分配给附加/新的T节点,以及附加/新的T节点通过关联角色“具体化”与节点A1和A2关联。
这两个新的T节点的节点类型被设置为“出处信息”,以及节点名称分别被设置为“哈姆雷特的出处”和“哈姆雷特的日译本”。
新增表明节点T31与T32之间的关联的A节点,采用标识符A3,以及节点类型被设置为“原著-译本信息”。
关联中节点T31和T32的角色为“原著信息”和“译本信息”。通过上述处理,添加了AR表和ID表,分别如表19和表20所示。在本发明的一个实施例中,表19、表20分别附加到表17、表18。
              表19
  A节点   T节点   关联角色
  A1   T31   具体化
  A2   T32   具体化
  A3   T31   原著信息
  A3   T32   译本信息
                  表20
  节点ID   节点类型   节点名称
  T31   出处信息   哈姆雷特的出处
  T32   出处信息   哈姆雷特的日译本
  A3   原著-译本信息   (空)
为了在相同关系数据库中直接存储第一和第二数据,必须新增例如与“哈姆雷特”对应的、作为翻译版本或“○○出版社”的项(数据属性)作为新字段。根据先有方法,这种添加不容易,因为数据库的表结构必须相应改变。
但是,根据本发明的一个实施例,通过如上所述对现有AR表添加新的行、即新的记录而不是新的字段,通过把具有不同数据属性的数据作为不同组来存储,就能够区分第一数据和第二数据。
采用A节点、T节点以及表示这些节点之间关联的链接来表达第一和第二数据,如图4所示。
本发明的一个实施例提供易于表示具有复杂结构的数据的方法以及采用关系数据库的存储/管理方法。
随后将描述对于本发明的一个实施例的数据库中的预期数据的示范搜索。
例如,用户希望知道剧作家莎士比亚创作的戏剧哈姆雷特的日译本的出版商。
图5是流程图,说明根据本发明的一个实施例执行的搜索过程。下面将说明图5的流程图。
在步骤110:用户输入搜索条件,例如由“剧作家”(或“作者”)、“莎士比亚”写作的“戏剧”(或“作品”)。
在步骤120:满足搜索条件的一组或多组数据被检索。
在步骤130:与所检索的一组或多组数据中的“戏剧”对应的数据被显示。
在步骤140:用户从所显示数据中选择预期戏剧名称,即“哈姆雷特”。
在步骤150:再次搜索数据库,采用“哈姆雷特”和“译本”作为新的搜索条件。
在步骤160:满足新的搜索条件的另一组或多组数据被检索。
在步骤170:与所检索的一组或多组数据中的“出版商”和“出版日期”有关的数据被显示。
在步骤180:用户从所显示数据中选择预期出版商。
下面进行详细描述。
用户输入“莎士比亚”和“作者”作为搜索条件,并搜索数据。
在这个特定实例中,在数据库中存在T节点的节点名称“莎士比亚”和关联角色“作者”。通过参考数据库中的AR表(例如表17)来检索其关联角色为“作者”的T节点的标识符(例如T11)。随后,通过参考ID表(例如表18)中存储的节点名称属性来检索与其节点名称为“莎士比亚”的T节点(例如T11)对应的一组或多组A节点标识符。
在包括所检索的一组或多组A节点标识符的搜索结果中,从AR表(例如表17)中选择另一个搜索条件、即其关联角色为“作品”的T节点标识符。
根据所选标识符从ID表(例如表18)中显示与所选T节点、即与关联角色“作品”对应的戏剧有关的数据、即节点名称。
例如显示戏剧或节点名称“哈姆雷特”、“驯悍记”、“威尼斯商人”、“仲夏夜之梦”、“李尔王”等。用户选择预期戏剧或节点名称,即“哈姆雷特”。
随后,使用所选节点名称“哈姆雷特”的标识符“T12”作为关键字,根据本发明的一个实施例的***从AR表(例如表17)中搜索包含标识符“T12”作为T节点ID、同时具有关联角色“译本”的A节点标识符。
相应地,与满足搜索条件的A节点标识符相关的一组或多组数据被检索。
通过参考ID表(例如表18),从所检索的一组或多组数据中显示具有“出版”和“出版日期”作为关联角色的T节点的节点名称。
用户这时可从所显示数据中选择预期出版商,即实际上在“2003年2月”新近出版了戏剧哈姆雷特的译本的“○○出版社”。
作为一个搜索实例描述了图5的过程。毫无疑问,当搜索条件的数量增加时,在数据库中的搜索次数不限于如图5所示的两次,而是根据搜索条件可以是任意的次数。
在所述具体实例中,单一属性被定义为关联角色。但是,每个关联角色不限于只是一个单一属性。
换言之,关联角色可具有多个属性。在以上实例中,更详细的属性可通过把诸如“悲剧”、“喜剧”、“传奇”、“历史剧”等题材添加及指定到关联角色“戏剧”来定义。
数据存储方法/数据结构的特征
如上所述,根据本发明的一个实施例的数据存储方法和数据结构,通过采用广泛使用的关系数据库形式,可存储和管理数据,同时维护表示具有三元或更复杂关系、一般为n元相互关系的一系列数据的关系的超图结构。
按照根据本发明的一个实施例在关系数据库的表中直接映射相关网络数据的方法,能够解决无法有效地存储/管理具有三元或更复杂关系、一般为n元关系的数据的先有问题。
还能够解决以下先有问题:诸如把属性数据添加到数据库中存储的数据之类的修改必需改变关系数据库表的结构、导致灵活性损失以及要求更多工作量。
此外,能够通过利用通常分配给数据的附加标识符以及相同数据库模式的构架中的附加关联角色,为一系列关联提供具体含义。
第一数据库***
下面将描述本发明的一个实施例的第一数据库。
图6说明实现本发明的一个实施例的第一数据库***(DB***)1的配置。
参照图6,本发明的一个实施例的第一DB***1通过经由诸如LAN、WAN或因特网的网络100把数据库服务器(DB服务器)12连接到用于输入和搜索数据的计算机(PC)102来配置。
在以下描述中,术语可能部分或者略微不同于以上参照图4、图5以及表7至表20描述数据存储方法和数据结构所使用的术语。但是,描述的相应术语的含义实质上相同。
在出现矛盾时,将以DB***1的以下描述中使用的术语的含义为准。
在以下参考的附图中,相似组件将由相似参考标号表示。
硬件配置
图7说明图6所示的DB服务器12和PC 102的硬件配置。
参照图7,DB服务器12和PC 102包括:主单元120,其中包括CPU 122、存储器124及其***电路;输入/输出装置126,其中包括显示单元和键盘;以及记录装置128,例如CD或HDD。此外,当DB服务器12和PC 102(用于进行通信的组件以下可通称为通信节点)连接到网络100时,可添加用于经由网络100与其它通信节点进行通信的通信装置132。
换言之,DB服务器12和PC 102包括作为配备了与其它通信节点进行通信的功能的计算机的组件。
数据结构
DB服务器12构建为允许根据以上参照图4、图5和表7至表20所述的本发明的一个实施例的数据存储方法及数据结构来存储数据以及搜索所存储的数据。
现在描述DB服务器12中的数据结构和数据搜索机制。
图8说明重新排列形式的图3(a)的数据关联。
参照图8,在DB服务器12中,主题节点(以下称作T节点)与一个或多个关联节点(以下称作A节点)相关,以及在相关的T和A节点之间定义关联属性R。
关联属性R可以是用于定义T与A节点之间的关联的任何属性。但是,为了以下提供的具体清楚的描述,将考虑一个具体实例,其中关联属性R为关联角色R(如本发明的一个实施例的数据存储方法和数据结构的以上描述中的详细说明)。
图3(a)所示的数据关联可重新排列,如图8所示。
在图8所示的A节点A1至An(n为1或大于1的整数,但n在所有情况中不表示相同的数)中,A节点A1以及与A节点A1相关联的T节点T1-1至T1-3和T2-1通过链接互连。
类似地,与A节点A2相关联的T节点T2-1、T2-2和Tn-1与A节点A2通过链接互连。
对于A节点An,情况也是这样。与A节点An相关联的T节点Tn-1至Tn-4与A节点An通过链接互连。
换言之,图8表明,T节点T2-1具有与A节点A1和A2两者的关联,以及T节点Tn-1具有与A节点A2和An两者的关联。
图9说明一般化形式的图8的数据结构。
图8中,从T节点T1-1通过A节点A1、T节点T2-1、A节点A2和T节点Tn-1到A节点An的链接851、852、853、854、855沿着图9中从上到下方向延伸的路径961来表示。
在一个具体实例中,图9还表明下列情况。
(1)T节点T1-1至T1-m1和T2-1与A节点A1相关联,以及在T节点T1-1至T1-m1和T2-1与A节点A1之间的关联(链接)中定义关联角色R1-1至R1-m1和R1-0。
(2)T节点T2-1至T2-m2以及从图9中省略的T节点与A节点A2相关联,以及在T节点T2-1至T2-m2与A节点A2之间的关联中定义关联角色R2-1至R2-m2。
(3)类似地,此后,从图9中省略的T节点与A节点相关联,以及在其之间定义关联角色R。
(4)T节点Tn-1至Tn-mn以及从图9中省略的T节点与A节点An相关联,以及在T节点Tn-1至Tn-mn与A节点An之间的关联中定义关联角色Rn-1至Rn-mn(m1至mn,n为整数)。
换言之,在DB服务器12中,T节点中的每个与一个或多个A节点相关联,以及A节点中的每个与一个或多个T节点相关联,从而多个T节点可经由A节点彼此相关联,以及多个A节点可经由T节点彼此相关联。
在DB服务器12中,如图9所示相关联的A和T节点的多个组合可被存储。
图10是示意图,说明一般化形式的图3(b)和图4的数据关联。
参照图10,与A节点A1相关联的T节点T1-1至T1-3(以及T3-1)经由链接连接到A节点A1,与A节点A2相关联的T节点T2-1至T2-3(以及T3-2)经由链接连接到A节点A2,以及A节点An和T节点Tn-1至Tn-3和T2-3(以及T3-n)经由链接连接在一起。
T节点T2-3通过链接连接到A节点A2和An这两者,这意味着T节点T2-3与A节点A2和An这两者相关联。
当如在这种情况下,通过A节点A1、A2和An相关联的一系列信息具有公共关联时,可定义新的关联节点A3。
例如,当A节点A1是与哈姆雷特的原著有关的信息,A节点A2是与哈姆雷特的译本有关的信息,以及A节点An是与哈姆雷特的演出有关的信息时,A节点A1、A2和An所表示的相关数据具有作为有关哈姆雷特的数据的共同性。
因此,为了表明通过A节点A1、A2和An相关联的数据具有共同性,新的关联节点A3被定义并存储在数据库中。
如图10中的虚线所示,为了具体描述A节点A1和T节点T1-1至T1-3所表示的一系列信息,新的T节点T3-1被定义并存储在数据库中。
类似地,为了具体描述A节点A2和An的关联,新的T节点T3-2和T3-n被定义并存储在数据库中。
例如,数据“哈姆雷特的出处”被定义为T节点T3-1中的主题内容,数据“哈姆雷特的日译本”被定义为T节点T3-2中的主题内容,以及数据“哈姆雷特的演出”被定义为T节点T3-n中的主题内容。这些数据存储在数据库中。
另外,在新的A节点A3与T节点T3-1至T3-n的每个之间定义关联角色R,并将其存储在数据库中。
例如,“原著信息”被定义为新的A节点A3与T节点T3-1之间的关联角色R,“译本信息”被定义为新的A节点A3与T节点T3-2之间的关联角色R,以及“演出信息”被定义为新的A节点A3与T节点T3-n之间的关联角色R。这些数据存储在数据库中。
类似地,例如,在A节点A1、A2和An与T节点T3-1、T3-2和T3-n之间定义由***预定义为“具体化”的关联角色R。
图11说明用于存储图9所示的结构的数据的关联角色(AR)表。
图12说明用于存储图9所示的结构的数据的T节点标识符(ID)表。
图13说明用于存储图9所示的结构的数据的A节点标识符(ID)表。
在DB服务器12中,通过图9所示的结构相关的A和T节点的数据以及T节点的数据通过采用图11的AR表和图12的ID表来存储。
图11所示的AR表的条目(或记录或者行)中的每个表示一个给定的A节点、与A节点相关联的一个T节点以及在相关联的A与T节点之间定义的关联角色R,并且包括A节点ID、T节点ID以及关联角色R。
换言之,AR表的条目中的每个包括图9所示的链接之一的一端的A节点的标识符、链接的另一端的T节点的标识符以及定义链接的属性的关联角色。
对于图9所示的所有链接(T节点T1-1与A节点A1之间以及T节点Tn-mn与A节点An之间的链接)创建这类条目,并存储在AR表中。图9所示的A与T节点之间的关联相应地存储在图11的AR表中。
每个T节点具有其内容(T节点的名称、T节点本身的数据、T节点引用的数据等)。此外,对于每个T节点,除了存储在AR表的各条目中的标识符(ID)之外,还定义了T节点的属性(节点类型(NT);主题属性)。下面将考虑一个具体实例,其中,每个T节点仅具有其名称(节点名称(N))作为其内容。
图12所示的T节点ID表的每个条目包括图9所示的T节点之一的标识符(ID)、为T节点定义的属性(节点类型(NT))以及T节点的名称(节点名称(N))。
对于图9所示的所有T节点T1-1至Tn-mn创建这些条目,并存储在T节点ID表中。图9所示的所有T节点的数据相应地被存储。
图13所示的A节点ID表的每个条目包括图9所示的A节点之一的标识符(ID)、为A节点定义的属性(节点类型(NT’))以及A节点的名称(节点名称(N’))。
对于图9所示的所有A节点A1至An创建这些条目,并存储在A节点ID表中。图9所示的所有A节点的数据相应地被存储。
要注意,类似的形式可用来存储A与T节点之间的关联以及图9所示的A和T节点的数据,作为表格形式的补充或替代。但是,在以下描述中,将考虑采用AR表和ID表的一个具体实例。
根据DB服务器12的使用、配置或处理任务,如图11所示,每个条目可包括T节点的内容(节点名称(N))来取代AR表中的T节点的标识符(ID)。
类似地,在AR表中,每个条目还可包括T节点的内容。
数据搜索
图14说明在图6和图7所示的DB服务器12中的数据搜索方法。
如图14所示,将考虑一个具体实例,其中,T节点T1至Tn和T节点Tret(T返回)、(待输出的)搜索结果与某个A节点相关联,在A节点与T节点T1至Tn和Tret之间定义关联角色R1至Rn和Rret,以及T节点T1至Tn和Tret具有节点名称N1至Nn和Nret。
在DB服务器12中,为Tret定义的关联角色Rret、用于搜索的A节点的属性(节点类型NT;图14中的ANT1和ANT2)、用于搜索的T节点的关联角色R和节点名称N的一个或多个组合用作搜索条件。
如图14所示,例如,搜索条件由(Rret,(ANT1,ANT2,...),Filter)来表示,其中Filter=((R1,N1),(R2,N2),...,(Rn,Nn))。
搜索条件还可包含T节点的属性NT(第三条件数据),稍后进行描述。
在搜索条件中,包含在Filter中的关联角色R和T节点的节点名称N的一个或多个组合(R1,N1)、(R2,N2),...(Rn,Nn)用作搜索的过滤器,因而以下称作搜索过滤器。
在搜索条件中,A节点的属性(ANT1,ANT2,...)可省略。
图15是第一流程图,说明在图6和图7所示的DB服务器12中的搜索过程的整个过程(S20)。
参照图15,在步骤S200,例如,DB服务器12接受例如由搜索者采用PC 102(图6)或DB服务器12的输入/输出装置126输入的图14所示的搜索条件。
在图16中详细说明的步骤S22,根据稍后进行描述的搜索过滤器来选择关联节点。
在图17中详细说明的步骤S24,获取稍后进行描述的节点ID和节点名称。
在步骤S202,DB服务器12根据经过S24中的处理作为搜索结果得到的标识符(节点ID)和T节点Tret的节点名称(Nret)来创建对搜索者的查询的响应。
对于该响应,仅可使用节点名称Nret、由节点Tret引用的各种数据或者表明节点Tret的各种数据。
在步骤S204,参照图15,DB服务器12确定搜索者的查询是否已终止。
当搜索者的查询已经终止时,DB服务器12结束此过程,否则返回到S200的处理。
图16是流程图,说明基于图15所示的搜索过滤器的关联节点选择过程(S22)。
参照图16,在接受图15所示的S200的处理中的搜索条件(Rret,(ANT1,ANT2,...),Filter),Filter=((R1,N1),(R2,N2),...,(Rn,Nn))时,DB服务器12在步骤S220中初始化用于处理的关联节点的列表。
在这个关联节点列表中,在从AR表(图11)得到的A节点之间,在搜索条件中包含A节点的属性之一(节点类型;ANT1,ANT2,...)作为其属性(节点类型NT)的A节点的标识符被存储。
要注意,在从搜索条件中省略A节点的属性时((ANT1,ANT2,...)=NULL),在S220的处理中,从AR表(图11)所得到的A节点的所有标识符被存储。
在步骤S222,DB服务器12确定是否对所有搜索过滤器(Ri,Ni)执行了处理。
如果已经对所有搜索过滤器执行了此处理,则DB服务器12进入S24的处理(图15和图17)。否则,DB服务器12把仍未处理的搜索过滤器(Ri,Ni)的任一个设置为用于处理的下一个过滤器,然后进入S224的处理。
在步骤S224,DB服务器12搜索T节点ID表(图12),以便检索包含搜索过滤器(Ri,Ni)的节点名称Ni的所有条目,并创建在所检索条目中包含的一组T节点标识符(节点ID集T,其中T={Ti|节点名称=ID表中的Ni})。
要注意,当搜索条件包含T节点的属性(节点类型;NT),并且搜索过滤器由(Ri,Ni,NTi)表示时,在S224的处理中,DB服务器12只需要从ID表中检索包含搜索过滤器(Ri,Ni,NTi)的节点名称Ni和节点类型NTi的条目,以及创建在所检索条目中包含的一组T节点标识符作为节点ID集T。
在步骤S226,DB服务器12确定S224的处理中得到的节点ID集T是否为空。
当节点ID集T为空时,DB服务器12执行用于终止搜索过程的处理(向搜索者显示“找到零个匹配”消息等),然后结束搜索过程。否则,DB服务器12进入S228的处理。
在步骤S228,DB服务器12搜索AR表(图11),以便更新关联节点列表A。
也就是说,DB服务器12从AR表中检索包含搜索过滤器(Ri,Ni)的关联角色Ri以及在S224的处理中得到的节点ID集T中包含的T节点标识符的所有条目,并把所检索条目中包含的A节点标识符存储在关联节点列表A中(A={Aj|角色=Ri,T节点标识符=Ti(所有i),A节点标识符∈AR表中的A})。
在步骤S230,DB服务器12确定在S228的处理中得到的关联节点列表A是否为空。
当关联节点列表A为空时,DB服务器12执行用于终止搜索过程的处理,然后结束搜索过程。否则,DB服务器12进入S232的处理。
在步骤S232,DB服务器12读取搜索条件中包含的搜索过滤器,但不进行处理并返回到S222的处理。
图17是流程图,说明图15和图16所示的节点ID和节点名称获取过程S24。
参照图17,在根据搜索过滤器完成关联节点选择过程S22时,在步骤S240,DB服务器12搜索AR表(图11)以创建T节点ID集T。
也就是说,DB服务器12从AR表中检索包含搜索条件所包含的关联角色Rret以及在S22(S228)的处理中得到的关联节点列表A中包含的A节点标识符的所有条目,并创建所检索条目中包含的一组T节点标识符(T节点ID集T)(T={Tm|角色=Rret,A节点标识符∈AR表中的A})。
在步骤S242,DB服务器12确定S240的处理中得到的T节点ID集T是否为空。
当T节点ID集T为空时,DB服务器12执行终止处理以结束搜索过程。否则,DB服务器12进入S244。
在步骤S244,DB服务器12搜索T节点ID表(图12),以便创建节点ID和节点名称集P。
也就是说,DB服务器12从ID表中检索包含在S240的处理中创建的T节点ID集T所包含的T节点标识符Tm中任一个的所有条目,并创建条目中包含的节点名称Nm和T节点标识符Tm的集合P(P={(Tm,Nm)|T节点标识符=ID表中的Tm(所有m)})。
在步骤S246,DB服务器12确定S244的处理中得到的T节点标识符和T节点名称的集合P是否为空。
当T节点标识符和T节点名称的集合P为空时,DB服务器12执行终止处理以结束搜索过程。否则,DB服务器12进入S202的处理。
这个集合P用于在图15所示的S202的处理中创建对搜索者的响应。
DB程序2
图18说明在图6和图7所示的DB服务器12中运行的DB程序2的结构。
在图18中,为了清楚地进行说明,在不需要的情况下省略了表示数据流的线条。
参照图18,DB程序2包括DB管理单元20、DB单元24和DB搜索单元26。
DB管理单元20包括管理操作接收器200、AR条目创建单元202、ID条目创建单元204、AR数据库管理单元(ARDB管理单元)206以及ID数据库管理单元(IDDB管理单元)208。
DB单元24包括AR数据库(ARDB)240、T节点ID数据库(IDDB)242和A节点IDDB 244。
DB搜索单元26包括搜索操作接收器260、搜索条件创建单元262、搜索控制单元264、AR数据库搜索单元(ARDB搜索单元)266以及ID数据库搜索单元(IDDB搜索单元)268。
例如,DB程序2在记录介质130(图7)上携带并从其中读出到DB服务器12,加载到存储器124,并通过具体利用DB服务器12的硬件在DB服务器12中的操作***下运行(以下各程序均类似)。
采用这些组件,DB程序2用来创建以上参照图9至图13所述的AR数据库(图11)和ID数据库(图12和图13),并采用这些数据库来执行数据搜索(图14至17)。
在DB单元24中,ARDB 240存储图11所示的AR表。
IDDB 242存储图12所示的T节点ID表。
IDDB 244存储图13所示的A节点ID表。
图18说明一个具体实例,其中,图12和图13所示的T节点ID表和A节点ID表存储在IDDB 242和244中。但是,T节点ID表和A节点ID表可存储在相同数据库中。
T节点ID表和A节点ID表不需要总是分开创建,而是它们可共同创建在一个数据库中。
在DB管理单元20中,管理操作接收器200从输入/输出装置126(图7)或者通过网络100从PC 102(图6)接收管理或修改AR表和ID表中存储的数据的操作,并把操作输出到ARDB管理单元206和IDDB管理单元208。
管理操作接收器200接收用于指定A节点和T节点、A节点与T节点之间的关联、A节点与T节点之间定义的关联角色R(链接)、分配给A节点和T节点的标识符(ID)、分配给T节点的节点名称(N)以及为T节点定义的属性(图9)的用户操作,并把操作输出到AR条目创建单元202和ID条目创建单元204。
例如,管理操作接收器200在输入/输出装置126上显示表示A节点和T节点、如图14所示的其间关联的用户界面(UI)图像,接收UI图像上的用户操作,以及接受指定。
AR条目创建单元202根据从管理操作接收器200输入的用户指定来创建图11所示的AR表的条目,并把条目输出到ARDB管理单元206。
ARDB管理单元206把从AR条目创建单元202输入的AR表的条目添加到ARDB 240存储的AR表中。
ARDB管理单元206根据从管理操作接收器200输入的用户操作来修改ARDB 240中存储的AR表的内容。
ARDB管理单元206根据ARDB搜索单元的搜索请求来检索ARDB 240中存储的AR表的条目,并把条目输出到ARDB搜索单元266。
ID条目创建单元204根据从管理操作接收器200输入的用户指定来创建图12和图13所示的T节点和A节点ID表的条目,并把条目输出到IDDB管理单元208。
IDDB管理单元208把从ID条目创建单元204输入的T节点ID表的条目添加到IDDB 242存储的T节点ID表中。
IDDB管理单元208把从ID条目创建单元204输入的A节点ID表的条目添加到IDDB 244存储的A节点ID表中。
IDDB管理单元208根据从管理操作接收器200输入的用户操作来修改IDDB 242和244中存储的ID表的内容。
IDDB管理单元208根据IDDB搜索单元268的搜索请求来检索IDDB 242和244中存储的ID表的条目,并把条目输出到IDDB搜索单元268。
在DB搜索单元26中,搜索操作接收器260从输入/输出装置126(图7)或者通过网络100从PC 102(图6)接收指定用于图14至17所示的搜索过程的搜索条件(图14,还可包含可选T节点的属性(节点类型(NT)))的搜索者操作。
搜索操作接收器260把所接收操作输出到搜索条件创建单元262。
例如,当搜索操作接收器260接受自然语言查询形式的搜索条件时,搜索条件创建单元262分析查询语句以便提取单词。
随后,搜索条件创建单元262通过ARDB搜索单元266、IDDB搜索单元268、ARDB管理单元206以及IDDB管理单元208来搜索ARDB 240和IDDB 242、244中存储的AR表和ID表,并提取用作搜索条件的单词。
此外,搜索条件创建单元262按照查询语句的结构组合所提取单词,检索图14所示的(Rret,(ANT1,ANT2,...),((R1,N1),(R2,N2),...,(Rn,Nn))形式的搜索条件,并把搜索条件输出到搜索控制单元264。
要注意,当搜索者直接指定图14所示的(Rret,(ANT1,ANT2,...),((R1,N1),(R2,N2),...,(Rn,Nn)))形式的搜索条件时,搜索条件创建单元262可省略。
搜索条件创建单元262可以是用于帮助搜索者检索搜索条件(Rret,(ANT1,ANT2,...),((R1,N1),(R2,N2),...,(Rn,Nn)))的工具。
搜索控制单元264根据从搜索条件创建单元262(搜索操作接收器260)输入的搜索条件(Rret,(ANT1,ANT2,...),((R1,N1),(R2,N2),...,(Rn,Nn)))控制ARDB搜索单元266和IDDB搜索单元268,以便通过ARDB管理单元206和IDDB搜索单元208来执行在ARDB 240(AR表;图11)和IDDB 242、244(ID表;图12和图13)中的搜索,如图15至17所示。
当通过基于搜索条件的搜索得到搜索结果(集合P;图17)时,搜索控制单元264根据搜索结果创建响应,在输入/输出装置126(图7)中显示此响应,或者通过网络100(图6)在PC 102的输入/输出装置126中向搜索者显示此响应。
ARDB搜索单元266在搜索控制单元264的控制下通过ARDB管理单元206搜索ARDB 240(AR表;图11),并把搜索结果返回给搜索控制单元264。
IDDB搜索单元268在搜索控制单元264的控制下通过IDDB管理单元208搜索IDDB 242、244(ID表;图12和图13),并把搜索结果返回给搜索控制单元264。
整体操作
下面将针对具体实例来描述图6和图7所示的DB服务器12(DB程序2;图18)的整体操作。
AR表和ID表的创建
首先描述通过DB程序2的DB管理单元20创建AR表和ID表的过程。
图19说明对图6和图7所示的DB服务器12(DB程序2;图18)的数据输入以及对其中包含的数据执行搜索的搜索条件。
例如,如图19所示相关的数据被输入DB程序2的管理操作接收器200。
图19所示的数据包含如以下所述相关的A节点和T节点,以及节点名称被分配给T节点(但是,A节点的属性(节点类型(NT)和节点名称,以及T节点的属性(节点类型(NT))从以下小节(1)至(8)以及图19中省略)。
(1)“A节点A1”和“T节点T11”相关在一起,在它们之间定义关联角色R“作者”,以及节点名称“莎士比亚”(具有相同名称的不同人)被分配给“T节点T11”。
(2)“A节点A9”和“T节点T92、T41”相关在一起,在它们之间定义关联角色R“作品”和“作者”,以及节点名称“威尼斯商人”和“莎士比亚”被分配给“T节点T92和T42”。
(3)“A节点A4”和“T节点T41、T42”相关在一起,在它们之间定义关联角色R“作者”和“作品”,以及节点名称“哈姆雷特”被分配给“T节点T42”。
(4)“A节点A13”和“T节点T42”相关在一起,以及在它们之间定义关联角色R“剧本”。
(5)“A节点A19”和“T节点T42”相关在一起,以及在它们之间定义关联角色R“原著”。
(6)“A节点A10”和“T节点T42”相关在一起,以及在它们之间定义关联角色R“原著”。
(7)“A节点A10”和“T节点T103、T101”相关在一起,在它们之间定义关联角色R“出版”和“译本”,以及节点名称“○○出版社”被分配给“T节点T103”。
(8)“A节点A19”和“T节点T191”相关在一起,以及在它们之间定义关联角色R“译本”。
管理操作接收器200接收输入数据,并把数据输出到AR条目创建单元202和ID条目创建单元204。
AR条目创建单元202从图19所示的数据中创建AR表的每个条目,并把条目输出到ARDB管理单元206。
图20说明由AR条目创建单元202(图18)和ARDB管理单元206创建并存储在ARDB 240中的AR表。
要注意,在以下附图中,NULL(“空”)表明没有任何属性(节点类型)/名称(节点名称)。
ARDB管理单元206把从AR条目创建单元202输入的AR表的条目依次添加到ARDB 240存储的AR表中。
作为通过AR条目创建单元202和ARDB管理单元206的处理的结果,图20所示的AR表从图19所示的数据中创建并存储在ARDB240中。
图21说明由ID条目创建单元204(图18)和IDDB管理单元208创建并存储在IDDB 242中的T节点ID表。
ID条目创建单元204从图19所示的数据中创建T节点ID表的条目,并把条目输出到IDDB管理单元208。
IDDB管理单元208把从ID条目创建单元204输入的T节点ID表的条目依次添加到IDDB 242存储的ID表中。
作为通过ID条目创建单元204和IDDB管理单元208的处理的结果,图21所示的T节点ID表从图19所示的数据中创建并存储在IDDB 242中。
图22说明由ID条目创建单元204(图18)和IDDB管理单元208创建的A节点ID表。
ID条目创建单元204从图19所示的数据中创建A节点ID表的条目,并把条目输出到IDDB管理单元208。
IDDB管理单元208把从ID条目创建单元204输入的ID表的条目依次添加到IDDB 244存储的A节点IDDB表中。
作为通过ID条目创建单元204和IDDB管理单元208的处理的结果,与图22所示类似的A节点ID表从图19所示的数据中创建并存储在IDDB 244中。
数据搜索
例如,当搜索者以查询语句的形式向DB服务器12的输入/输出装置126(图7)输入搜索条件“出版剧作家莎士比亚作为作者写作的作品之一-戏剧哈姆雷特的原著的译本的出版商的名称是什么?”时,搜索条件创建单元262分析这个查询语句,并把查询语句分析为两个部分,即图19所示的第一半和第二半。
在查询语句的第二半“剧作家莎士比亚作为作者写作的作品”中,为了检索与“作品”有关的数据,搜索条件创建单元262把要作为搜索结果的T节点Tret的关联角色Rret设置为“作品”。
搜索条件创建单元262从第二半“莎士比亚作为作者写作”中创建搜索过滤器(R1=“作者”,N1=“莎士比亚”)。
此外,搜索条件创建单元262从T节点Tret的关联角色(Rret=“作品”)和搜索过滤器(R1=“作者”,N1=“莎士比亚”)创建与查询语句的第二半对应的搜索条件(Rret,(ANT1),((R1,N1)))=(作品,(空),((作者,莎士比亚)))。
在查询语句的第一半“出版戏剧哈姆雷特的原著的译本的出版商的名称是什么?”中,为了检索与“出版的出版商”有关的信息,搜索条件创建单元262把要作为搜索结果的T节点Tret的关联角色Rret设置为“出版”。
搜索条件创建单元262从第一半包含戏剧“哈姆雷特”的“原著”的条件创建第一搜索过滤器(R1=“原著”,N1=“哈姆雷特”),以及从第一半包含的“译本”创建第二搜索过滤器(R2=“译本”,N2=“空(未指定)”)。
此外,搜索条件创建单元262从关联角色(Rret=“出版”)、第一搜索过滤器(”R1=“原著”,N1=“哈姆雷特”)和第二过滤器(R2=“译本”,N2=“空”)创建与查询语句的第一半对应的搜索条件(Rret,(ANT1),((R1,N1),(R2,N2)))=(出版,(空),((原著,哈姆雷特),(译本,空)))。
根据搜索条件创建单元262创建的搜索条件,搜索控制单元264通过ARDB搜索单元266和IDDB搜索单元268来搜索ARDB 240(AR表;图20)和IDDB 242(T节点ID表;图21),以便获得搜索结果,如以下所述。
首先,由从查询语句的第二半得到的搜索条件,搜索控制单元264执行以下操作。
(1)搜索控制单元264参考IDDB 242(图18)中存储的T节点ID表以检索其节点名称为“莎士比亚”的T节点的所有标识符(ID),并获得T11、T31、T41、T51和T81(图21)作为这个处理的结果。
(2)搜索控制单元264参考ARDB 240中存储的AR表(图20)以检索其中角色为“作者”以及T节点标识符匹配(1)的处理中得到的T节点标识符的所有A节点标识符,并且获得A1、A4和A9作为这个处理的结果。
(3)搜索控制单元264参考AR表以在通过(2)的处理得到的A节点标识符之中检索与其关联角色R为“作品”的A节点对应的T节点标识符(ID;一般为复数),并获得T42和T92作为这个处理的结果。
(4)搜索控制单元264参考ID表,并把与通过(3)的处理得到的T节点标识符对应的标识符的节点名称与T节点标识符(ID)设置在一起作为搜索结果。
也就是说,搜索控制单元264根据通过(1)至(4)的处理从查询语句的第二半得到的搜索条件(作品,(空),((作者,莎士比亚)))来执行搜索,并获得搜索结果(T42,哈姆雷特)以及(T92,威尼斯商人)。
随后,根据从查询语句的第一半得到的搜索条件以及与第二半对应的搜索结果,搜索控制单元264执行以下操作。
(5)从对应于查询语句的第二半的搜索结果(T42,哈姆雷特)和(T92,威尼斯商人),搜索控制单元264选择其节点名称对应于第一搜索过滤器(原著,哈姆雷特)的(T42,哈姆雷特),并获得其节点标识符(ID)T42。
(6)搜索控制单元264参考AR表以检索其中关联角色为“原著”以及T节点标识符匹配通过(5)的处理得到的节点标识符(ID)的所有A节点标识符,并且获得A10和A19作为结果。
(7)搜索控制单元264参考AR表以在通过(6)的处理得到的A节点标识符之中检索其角色为“译本”的所有标识符,并且获得A10和A19作为结果。
(8)搜索控制单元264参考AR表以在通过(7)的处理得到的A节点标识符之中检索与其角色为“出版”的A节点对应的T节点标识符,并获得T103作为结果(当存在来自多个出版商的译本时,获得多个T节点)。
(9)搜索控制单元264参考ID表,并把与通过(8)的处理得到的T节点标识符对应的节点ID的节点名称与节点标识符设置在一起作为搜索结果(T103,○○出版社)。
也就是说,搜索控制单元264根据通过(5)至(9)的处理从查询语句的第一半得到的搜索条件(出版,(空),((原著,哈姆雷特),(译本,空)))来执行搜索,并获得搜索结果(T013,○○出版社)。
(10)搜索控制单元264在输入/输出装置126(图7)等中向搜索者显示搜索结果。
第二数据库***3
图23说明根据本发明的一个实施例的第二DB***3的配置。
参照图23,第二DB***3通过经由网络100互连DB服务器12、用于在与DB服务器12相似的硬件(图7)上操作DB程序2的DB管理单元20和DB单元24的DB服务器30、以及用于在与DB服务器12相似的硬件上操作DB程序2的DB搜索单元26的检索装置32来配置。
这样,DB程序2不需要始终在一台计算机上运行,而是可分布到通过网络互连的多台计算机上运行。
第三DB***4
下面将描述配置成根据目录结构存储和搜索关联信息的本发明的一个实施例的第三DB***4。
图24说明第三DB***4的配置。
参照图24,DB***4通过经由网络100互连PC 102、检索装置40、DB管理服务器5以及n个DB服务器6-1至6-n来配置。
要注意,当未指定诸如DB服务器6-1至6-n等的多个组件的任一个时,它可简称作DB服务器6。
检索装置40、DB管理服务器5和DB服务器6的硬件采用图7所示的配置。
当DB服务器6包括象在图6所示的第一DB***1的DB服务器12(图6)和DB程序2(图18)的情况下那样的搜索功能时,检索装置40可变成不需要的。
此外,在DB***4中,可提供复制服务器(镜像服务器;DB服务器6’),与每个DB服务器6对应。
DB服务器6-1至6-n以下可称作DB服务器A至N。
接下来将描述图24的DB***4中的数据表示。
图25说明图24的DB***4中存储的数据的图形表示。
图26说明图25所示的数据的目录信息树表示。
如以上参照图8所述,当为A和T节点定义了节点名称等(A节点的节点名称等为“与关联节点对应的数据”,以及T节点的节点名称等为“与主题节点对应的数据”),并且在A与T节点之间定义了关联角色时,通过这些节点相关的相关数据可通过如图25所示的图形形式来表示。
图25说明一种情况,其中,“位置信息”、“商店”、“区域”被定义为节点(T1,T3-1和T3-2)的节点名称,用于定义T和A节点的节点类型(类),“商店1”和“区域3”被定义为T节点(T2-1和T2-2)的节点名称,“位置”被定义为A节点(A1)的节点名称,以及“建筑物”和“地点”被定义为T和A节点之间的关联角色。
A节点A2-1和A2-2表明用于定义节点类型(类)的节点以及作为其示例的节点(与实体对应的节点)。这样,节点A2-1和A2-2是特殊节点,因为它们实现不是基于由用户根据目的独立定义的角色、而是基于由***预定义的两个角色“类”和“示例”的T节点的关联。
图25所示的图形表示的相关数据可通过DIT(目录信息树)的形式来表示,它是图26所示的LDAP(轻型目录访问协议)的数据模型。
也就是说,根据DIT表示,图25所示的相关数据可由以下条目来表示:对应于A节点的条目以及对应于关联角色且具有T节点数据作为属性的条目,如图26中的实线所示,它们设置在作为各DB服务器6的顶部条目虚拟提供的虚拟根条目之下;以及表示第一、第二、...关联(关联#1、#2...)的条目,如图26中的虚线所示。
换言之,在图26所示的情况中,与两个角色“建筑物”和“地点”对应的条目直接在表明节点类型(assocType)为“位置信息”以及用于充当角色的成员“商店1”和“区域3”为相应条目的属性的相关数据的条目“位置”之下提供。
要注意,在图26所示的DIT形式中,“目录”被定义成以与现实相关的易于理解形式来构造与现实中的各种对象有关的数据,以便于数据的定位以及提供用于检索和更新数据的方式。
“条目”被定义以便根据对象类对与现实的对象有关的数据排列/分类以及把数据表示为目录信息,或者被定义为目录中存储的数据。
“目录信息树”被定义为在以分层方式管理条目(目录信息)时表示树结构中的分层关系。
换言之,图26中的正方形对应于条目,并且它是在树结构中表示其分层关系的目录信息树(DIT)。
如上所述,条目是与对象有关的一组数据,以及与这个对象有关的数据称作“属性”。
属性包括“属性类型”和一个或多个值“属性值”。参照图26,每个条目结构以“属性类型:属性值”的形式表示为LDAP中的条目表示,如下表21至23所示。
在紧接“ou=关联#1”之下的条目中,条目的各属性被定义,其方式例如是,属性类型对象类的属性值为关联节点,属性类型cn(普通名称)的属性值为位置、...。
                       表21
dn:associd=关联节点ID
对象类:关联节点
associd:关联节点ID
assocType:位置信息
cn:位置
角色:建筑物
角色:地点
                       表22
dn:角色=建筑物,associd=关联节点ID
对象类:关联角色
cn:建筑物
角色:建筑物
成员:商店1
                       表23
dn:角色=地点,associd=关联节点ID
对象类:关联角色
cn:地点
角色:地点
成员:区域3
图27说明分割以目录结构表示的相关数据的方法。
图28说明图27所示的DB服务器6-1(A)的条目dn_A2与DB服务器6-n(N)的条目dn_N之间的引用关系。
如图27所示,以DIT形式表示的相关数据可根据目录结构来分割。
在图27所示的情况中,相关数据由包含条目dn_A以及下级条目dn-A1和dn_A2的目录结构来表示,与条目dn_A1或下级条目的目录对应的相关数据被分割,对应于条目dn_B至dn_(N-1),以及与条目dn_A2或下级条目的目录对应的相关数据对应于条目dn_N或下级条目的目录结构(要注意,在图27所示的实例中,具有条目dn_B至dn_N作为顶部条目的目录结构为子树,以及包含这类子树以及条目dn_A作为顶部条目的目录结构为目录树)。
例如,如图28所示,图27所示的DB服务器6-n(N)的顶部条目dn_N在DB服务器6-1(A)的条目dn_A2之下,并且dn_N引用dn_A2。
因此,按照目录树分割的相关数据可经过分割并存储在图27所示的DB服务器6-1至6-n中。
图29说明用于管理经过分割并存储在图27所示的DB服务器6-1至6-n(DB服务器A至N)中的相关数据的目录树表。
为了管理经过分割并存储在图27和图28所示的DB服务器6-1至6-n(A至N)中的相关数据,使用与图29所示相似的目录树表。
参照图29,目录树表包含DB服务器6-1至6-n的服务器名称(A至N)、DB服务器6的顶部条目(dn_A至dn_N;与图26的虚拟条目相似)、由DB服务器6的顶部条目引用的条目(引用条目)、以及在DB服务器6中以对应方式存在复制服务器(镜像服务器(第二数据库服务器))时的装置名称(A’、C’等)。
图30说明用于把图27和图28所示的DB服务器6-1至6-n中存储的目录树(或子树)的顶部条目dn_A至dn_N与用于对目录树(或子树)中存储的相关数据分类的分类类型/分类值(分类数据)相关的数据表。
如图25和图26所示,以DIT形式的目录结构所表示、按照目录结构分割并存储在DB服务器6-1至6-n(A至N)中的相关数据可看作是分别在DB服务器6-1至6-n(A至N)中具有公共关联的数据集。
因此,可对于图27和图28所示的DB服务器6-1至6-n(A至N)中存储的目录树(或子树)定义表示用于对所存储相关数据分类的属性等的分类类型和分类值。
为了管理DB服务器6-1至6-n(A至N)中存储的相关数据,如图30所示,采用一种数据表,它包含为顶部条目dn_A至dn_N之下的子树a至n所定义的分类类型和分类值、顶部条目(dn_A至dn_N)以及以对应方式示于图27和图28的DB服务器6-1至6-n(A至N)的DB服务器6-1至6-n(A至N)的顶部条目或下级条目的子树。
要注意,图30所示的“分类类型”对应于关联类型(A节点(图22)的节点类型;属性)。
“分类值”对应于LDAP数据模型中的示例。
可能是图27至30所示的顶部条目的条目的具体实例包括但不限于:
(1)包含某个分类类型(关联类型;A节点的节点类型)的具体分类值(示例)的子树的根条目;以及
(2)包括其中含某个具体分类值(示例)的相关数据的子树的根条目。
在这里,描述了其中“分类类型”对应于关联类型以及“分类值”对应于其示例的情况。但是,这只是图30与图27和图28相关的一个实例。“分类类型”可能不对应于关联类型,以及“分类值”可能不对应于其示例。
例如,图30所示的子树包含“分类类型:类别,以及类型值:附属”的相关数据。这是其中“分类类型”不对应于关联类型以及“分类值”不对应于其示例的一个实例。
例如,表示为包含图30所示的数据表的顶部条目dn_B的条目分类类型的“位置信息”是(1)“包含某个分类类型(关联类型;A节点的节点类型)的具体分类值(示例)的子树的根条目”的分类类型的一个实例,它包含分类值“位置(位于)”作为分类值之一。
这个条目表明具有“位置(位于)”作为分类值的所有相关数据均存储在DB服务器6-2(B)中。
作为分类类型“位置信息”的分类值的其它实例,可列举分类值“相邻(紧接)”等。
或者,写为包含图30所示的顶部条目dn_(N-1)的条目分类类型的“建筑物”是(2)“包括其中含某个具体分类值(示例)的相关数据的子树的根条目”的分类类型的一个实例,它包括作为分类值之一的分类值“商店1”。
这个条目表明具有“商店1”作为分类值的所有相关数据均存储在DB服务器6-(n-1)(N-1)中。
相关数据的创建和搜索
下面将描述采取以上参照图25至30所述的DIT形式的目录结构来表示的相关数据的创建以及对已创建相关数据的搜索。
第一DB管理程序50
图31说明在图24所示的DB管理服务器5中运行的第一DB管理程序50的结构。
参照图31,DB管理程序50包括用户界面(UI)单元500、数据登记单元502、数据传送单元504、相关数据创建及管理单元510(目录树创建部件和数据相关部件)、树信息提供单元512、目录树表创建单元522(顶部条目相关部件)、目录树表管理单元524、目录树表DB526、数据表创建单元532(分类数据相关部件)、数据表管理单元534以及数据表DB 536。
采用这些组件,DB管理程序50创建以图26所示的DIT形式的目录结构所表示的相关数据。
DB管理程序50分割已创建相关数据并将其存储在如图27和图28所示的DB服务器6-1至6-n中,并且通过采用图29和图30所示的目录树表和数据表来管理相关数据。
另外,DB管理程序50适当地提供目录树表和数据表中包含的数据(树数据),它是对检索装置40(图24)搜索所需的。
图32说明图31所示的DB管理程序50向DB管理服务器5的输入/输出装置126(图7)显示的GUI图像。
在DB管理程序50中,UI单元500为DB管理服务器5或PC 102的用户提供GUI环境,并向输入/输出装置126(图7)显示与图32所示类似的GUI图像。
UI单元500接受所显示GUI图像上登记、管理或修改相关数据的用户操作,把操作输出到DB管理程序50的组件、如数据登记单元502和相关数据创建及管理单元510,以及控制其操作。
另外,UI单元500向输入/输出装置126显示/输出由DB管理程序50的各组件所创建的数据。
要注意,UI单元500可安装在DB管理服务器5或PC 102中,以及功能可提供给PC 102上的用户。
相关数据创建及管理单元510控制目录树表创建单元522和数据表创建单元532等的操作,由从UI单元500输入的表明T和A节点及关联属性的数据创建以图26所示的DIT形式的目录结构所表示的相关数据,以及通过采用图29和图30所示的目录树表和数据表来管理已创建相关数据。
对请求作出响应,相关数据创建及管理单元510向树数据提供单元512输出目录树表和数据表所包含的用于检索装置40的检索的数据(树数据)。
另外,根据用户操作,相关数据创建及管理单元510分割以图27和图28所示的DIT形式的目录结构所表示的相关数据,并把相关数据输出到数据登记单元502。
数据登记单元502通过数据传送单元504把从相关数据创建及管理单元510输入的相关数据传送给DB服务器6-1至6-n,并请求对相关数据的登记。
树信息提供单元512响应来自检索装置40的请求而提供从相关数据创建及管理单元510输入的树数据。
目录树表创建单元522在相关数据创建及管理单元510的控制下创建图29所示的目录树表,并把该表输出到目录树表管理单元524。
目录树表管理单元524把从目录树表创建单元522输入的目录树表存储在目录树表DB 526中。
对请求作出响应,目录树表DB 526把目录树表DB 526中存储的目录树表输出到相关数据创建及管理单元510。
要注意,虽然在图18所示的DB程序2中DB管理单元20执行从相关数据创建AR表和ID表的处理,但是在图31所示的DB管理程序50中,相关数据创建及管理单元510创建目录结构的相关数据(图21和图22),以及DB服务器6通过相关数据创建及管理单元510和数据传送单元504接收已创建的目录结构的相关数据,并存储/管理相关数据。
数据表创建单元532在相关数据创建及管理单元510的控制下创建图30所示的数据表,并把数据表输出到数据表管理单元534。
数据表管理单元534把从数据表创建单元532输入的数据表存储在数据表DB 536中。
另外,对请求作出响应,数据表管理单元534把数据表DB 536中存储的数据表输出到相关数据创建及管理单元510。
下面将描述DB管理程序50的整个过程。
图33是流程图,说明通过使用图31所示的DB管理程序50的相关数据的登记过程S30。
参照图33,在步骤S300,DB管理程序50或PC 102的UI单元500向输入/输出装置126显示图32所示的GUI图像。
用户在所显示的GUI图像上进行操作,并向各字段输入与新增相关数据有关的数据。
在步骤S302,相关数据创建及管理单元510根据在步骤S300的处理中输入的相关数据来标识关联(题目;例如“莎士比亚的作品”)。
在步骤S304,相关数据创建及管理单元510标识相关数据的节点类型(分类类型;例如“出处信息”),并把这个类型设置为条目属性。
在步骤S306,相关数据创建及管理单元510通过数据表管理单元534参考数据表,并根据在步骤S302和S304的处理中标识的题目和节点类型来确定把已创建条目分类到的子树。
在步骤S310,相关数据创建及管理单元510通过目录树表管理单元524参考目录树表,并确定在其中存储步骤S306的处理中得到的子树的DB服务器6。
在步骤S312,相关数据创建及管理单元510根据与通过UI单元500输入的相关数据有关的数据来创建相应条目。
在步骤S314,相关数据创建及管理单元510通过数据登记单元502和数据传送单元504把添加的相关数据条目传送到在步骤S310的处理中确定的DB服务器6。DB服务器6判断所接收相关数据条目是否已被存储。
要注意,相关数据创建及管理单元510在对DB服务器6中的存储预处理时采用DB服务器6中的数据。
每个条目dn(区别名称)被分配给这个数据,以及DIT中的所有条目可由dn唯一标识。因此,可判断是否存在相同条目。
DB管理程序50在接收到来自DB服务器6的已经存储所添加相关数据条目的结果时结束此过程,否则进入步骤S316的处理。
在步骤S316,相关数据创建及管理单元510在所确定的DB服务器6中登记所添加相关数据条目。
图34是流程图,说明通过图31所示的DB管理程序50对数据表(图30)的更新过程S34。
在步骤S340,用户操作DB管理服务器5(图24)或PC 102来指定要改变的子树,并设置指定子树的分类类型/分类值。
相关数据创建及管理单元510通过UI单元500接收操作。
在步骤S342,用户操作DB管理服务器5(图24)或PC 102来设置指定子树的顶部条目。
相关数据创建及管理单元510通过UI单元500接收操作。
在步骤S344,相关数据创建及管理单元510判断在S340和S342的处理中接收的操作所表明的分类类型、分类值和顶部条目是否都已经对指定子树设置。
相关数据创建及管理单元510通过数据表管理单元534读取数据表,并在已经对指定子树设置了所有数据时结束此过程,否则进入S346的处理。
在步骤S346,相关数据创建及管理单元510把所接收的设定值(指定子树、分类类型、分类值和顶部条目)输出到数据表管理单元534。
数据表管理单元534把从相关数据创建及管理单元510输入的设定值设置到数据表中,并将其存储在数据表DB 536中。
图35是流程图,说明通过图31所示的DB管理程序50对目录树表(图29)的更新过程S36。
参照图35,在步骤S360,UI单元500从DB管理服务器5接收分割目录信息树的用户操作。
在步骤S362,相关数据创建及管理单元510从目录树表管理单元524获得目录树表(图29),检索表明DB服务器6的配置和目录结构的数据,并向用户显示数据。
在步骤S364,UI单元500接收在按照对所显示的目录结构的用户操作进行分割之后的子树的顶部条目和引用条目的设定。
在步骤S366,相关数据创建及管理单元510根据分割目录信息树的用户操作来判断是否设置在其中存储已分割子树的DB服务器6的复制服务器。
DB管理程序50在设置复制服务器时进入S368的处理,否则进入S370的处理。
在步骤S368,相关数据创建及管理单元510当在S366的处理中配置了复制服务器的设定时确定复制服务器。
在步骤S370,当分割之后的子树的顶部条目和引用条目和复制服务器被设置时,相关数据创建及管理单元510把复制服务器的名称输出到目录树表管理单元524。
在写入目录树表DB 526的指定部分时,目录树表管理单元524反映从相关数据创建及管理单元510输入的数据。
在步骤S372,相关数据创建及管理单元510判断是否已经对所有DB服务器6完成目录树表的更新过程。
当还没有对所有DB服务器6完成更新过程时,DB管理程序50返回到S364的处理。
随后将描述DB管理服务器5的整个过程。
图36是顺序图,说明图31所示的DB管理程序50的整个操作S40。
参照图36,在步骤S400,用户把相关数据输入DB管理程序50的UI单元500。
在步骤S402,UI单元500把与输入的相关数据有关的数据输出到相关数据创建及管理单元510。
相关数据创建及管理单元510接收数据。
在步骤S404,相关数据创建及管理单元510向数据表管理单元534输出用于对与所接收相关数据有关的数据之中的相关数据、如题目和节点类型进行分类的分类数据(分类类型/分类值)。
在步骤S406,数据表管理单元534从相关数据创建及管理单元510接收用于对相关数据分类的数据,并把相应子树的顶部条目返回给相关数据创建及管理单元510。
相关数据创建及管理单元510接收子树的顶部条目。
要注意,当没有相应子树时,DB服务器6-1的顶部条目(即根条目)被返回给相关数据创建及管理单元510来替代相应子树的顶部条目。
在S406的处理中,采用与数据表(图30)中存储的分类类型和分类值对应的数据,以及与通过图32所示的GUI图像输入的相关数据有关的数据都可由相关数据创建及管理单元510使用。
也就是说,相关数据创建及管理单元510把节点类型和特定示例的组合提供给数据表管理单元534,从而数据表管理单元534可获得与用于对相关数据分类的数据对应的子树的顶部条目。另外,例如,作为分类类型的“类别”以及作为分类值的“莎士比亚的作品”可提供给数据表管理单元534。
在步骤S408,相关数据创建及管理单元510把在S406的处理中得到的子树的顶部条目输出到目录树表管理单元524。
目录树表管理单元524接收子树的顶部条目。
在步骤S410,目录树表管理单元524通过采用子树的所接收顶部条目来搜索目录树表DB 526,并确定用于存储子树的DB服务器6。表明所确定DB服务器6的数据被返回给相关数据创建及管理单元510。
在步骤S412,相关数据创建及管理单元510向数据登记单元502输出DIT形式的相关数据以及表明所确定DB服务器6的数据。
数据登记单元502把输入的相关数据传送给所确定的DB服务器6,并登记数据。
在步骤S416至S422,从数据登记单元502向UI单元500通知登记结果(正常或异常结束),并将其向用户显示。
第二DB程序60
图37说明在图24所示的各个DB服务器6中运行的第二DB程序60。
参照图37,DB程序60包括数据管理单元600、信息DB602、数据传送单元604和搜索执行单元606。
采用这些组件,DB程序60从DB管理服务器5(DB管理程序50;图31)接收以DIT形式的目录结构表示且适当分割的相关数据的登记,并存储该数据。
DB程序60响应来自检索装置40的搜索请求而提供已登记相关数据。
DB程序60在DB管理服务器5的控制下修改已登记相关数据。
在DB程序60中,数据传送单元604从DB管理服务器5接收相关数据、其登记请求及其修改请求,并将其输出到数据管理单元600。
搜索执行单元606根据来自检索装置40的搜索条件(稍后描述且如图38所示的搜索程序42的搜索条件创建单元420所创建的LDAP操作,LDAP操作如图50所示)采用数据管理单元600搜索相关数据。
此外,搜索执行单元606把从数据管理单元600得到的相关数据作为搜索结果返回给发出搜索请求的检索装置40。
数据管理单元600响应来自DB管理服务器5的登记请求和修改请求而把从DB管理服务器5或者其它DB服务器6发送的相关数据(图26至图28)存储在信息DB 602中。
另外,响应搜索装置40的检索,数据管理单元600从信息DB 602中读取相关数据,并把数据输出到搜索执行单元606。
第一搜索程序42
图38说明在图24所示的检索装置40上运行的搜索程序42。
参照图38,搜索程序42具有一种结构,其中,搜索条件创建单元420和搜索结果输出单元422被添加到图18所示的DB搜索单元26。
采用这些组件,搜索程序42执行对于DB服务器6的搜索处理,并向搜索者显示作为搜索结果得到的相关数据。
在搜索程序42中,搜索操作接收器260接收搜索者输入到检索装置40的输入/输出装置126(图7)等中的搜索操作,并把操作输出到搜索条件创建单元420。
搜索条件创建单元420(目录树搜索部件)分析从搜索操作接收器260输入的搜索操作的内容,然后从DB管理服务器5获得与搜索操作的内容匹配的树数据(在目录树表和数据表(图29和图30)中搜索所需的数据),创建与搜索操作和树数据匹配的搜索条件,以及把搜索条件输出到搜索控制单元264。
具体来说,根据通过分析搜索操作的内容所得的相关数据的分类类型和分类值,搜索条件创建单元420从DB管理服务器5接收数据表(图30)以便搜索内容,以及获取与搜索操作的内容匹配的相关数据的顶部条目(但是,在没有这种顶部条目时,搜索条件创建单元420采用DB服务器6-1的顶部条目dn_A作为与搜索操作的内容匹配的相关数据的顶部条目)。
然后,搜索条件创建单元420搜索从DB管理服务器5接收的目录树表(图29)中的内容,以及确定存储通过搜索数据表所得的顶部条目的DB服务器6。
此外,搜索条件创建单元420通过使用搜索操作的内容和对从数据表所得的相关数据分类所使用的属性(分类类型和值)来创建将由DB服务器6执行的LDAP操作的命令和参数,并把命令和参数作为搜索条件输出到搜索控制单元264。
搜索控制单元264(数据搜索部件)把从搜索条件创建单元420输入的搜索条件输出到DB服务器6,并控制对相关数据的搜索。
搜索结果输出单元422向检索装置40的输入/输出装置126(图7)以及向搜索者显示/输出作为搜索结果从DB服务器6返回的相关数据。
下面将描述搜索程序42的整个过程。
图39是流程图,说明通过图38所示的搜索程序42进行的搜索过程S44。
参照图39,在步骤S440,搜索操作接收器260接收来自用户的搜索条件。
在步骤S442,搜索操作接收器260创建搜索请求消息(稍后参照图50进行描述),并把消息输出到搜索条件创建单元420。
在步骤S444,搜索条件创建单元420判断是否在搜索请求消息中指定分类类型和分类值。
当指定分类类型和分类值时,搜索条件创建单元420进入S446的处理,否则,进入S454的处理。
在步骤S446,搜索条件创建单元420把分类类型和分类值发送给DB管理服务器5,并确定相应子树的顶部条目。
在步骤S448,搜索条件创建单元420判断是否在S446的处理中已经确定子树。
当已经确定子树时,搜索程序42进入S450的处理,否则,进入S454的处理。
在步骤S450,搜索条件创建单元420把所确定顶部条目发送给DB管理服务器5,并确定在其中存储与顶部条目对应的子树的DB服务器6。
在步骤S452,搜索条件创建单元420把所确定的子树的顶部条目设置为搜索起始条目(查询基础)。
在步骤S454,搜索条件创建单元420从DB管理服务器5接收目录树表,参考所接收的目录树表以便通过所有DB服务器中存储的子树把顶部条目(根条目)设置为查询基础,以及确定存储根条目的DB服务器6。
在步骤S456,搜索控制单元264从搜索条件创建单元420获得与搜索请求、查询基础等有关的数据,并为所确定DB服务器6创建LDAP操作命令。
在步骤S458,搜索控制单元264通过采用已创建LDAP操作命令在DB服务器6上执行搜索处理,并接收和输出其结果。
下面将结合DB管理程序50的过程进一步描述搜索程序42的整个过程。
图40是顺序图,说明图31所示的DB管理程序50以及图38所示的搜索程序42的整个过程S52。
参照图40,在步骤S520,搜索程序42的搜索操作接收器260接收用户的查询操作。
在步骤S522,搜索操作接收器260把搜索请求消息传送给搜索条件创建单元420。
在步骤S526,搜索条件创建单元420把搜索请求消息中包含的分类类型和分类值传送给DB管理程序50的相关数据创建及管理单元510。
要注意,S526的处理对应于在图39所示的步骤S446中从搜索条件创建单元420向DB管理服务器5传送分类类型/值的处理。
在步骤S528,相关数据创建及管理单元510把从搜索条件创建单元420所接收的分类类型/值输出到数据表管理单元534。
在步骤S530,数据表管理单元534通过采用从相关数据创建及管理单元510输入的分类类型/值来参考数据表,以便获得与输入分类类型/值对应的顶部条目。
数据表管理单元534把所得顶部条目返回给相关数据创建及管理单元510。
在步骤S532,相关数据创建及管理单元510把在S530的处理中得到的顶部条目输出到目录树表管理单元524。
在步骤S534和S536,目录树表管理单元524通过相关数据创建及管理单元510把与输入顶部条目对应的DB服务器6返回给搜索条件创建单元420。
在步骤S538,搜索条件创建单元420创建搜索条件,并把搜索条件与所确定DB服务器6等的名称一起输出到搜索控制单元264。
在步骤S540,搜索控制单元264创建LDAP命令,并访问所确定DB服务器6以执行搜索。
在步骤S542至S546,搜索结果从DB服务器6返回并向用户显示。
DB***4中的相关数据和搜索实例(1)
下面将通过举一个具体实例来描述如何登记相关数据以及如何在DB***4中检索已登记相关数据。
图41是在图24所示的DB***4的DB服务器6中登记的目录结构的相关数据实例的第一示意图,说明平面目录结构。
在图41所示的目录结构中,由图26所示的虚线表示的条目(ou=关联#1至#n)不存在,而所有相关数据直接位于根条目下面。
这个目录结构称作“平面目录结构”。
用户对于DB管理服务器5(图24)或PC 102的输入/输出装置126(图7)中显示的GUI图像(图32)执行依次登记相关数据的操作。
通过这个操作,下列数据以下列形式输入DB管理服务器5
(关联名称,关联类型,名称,角色):
(哈姆雷特的出处,出处信息,莎士比亚,作者),
(哈姆雷特的出处,出处信息,哈姆雷特,作品),
(威尼斯商人的出处,出处信息,莎士比亚,作者),
(威尼斯商人的出处,出处信息,威尼斯商人,作品),
(哈姆雷特的日译本,译本信息,哈姆雷特,原著),
(哈姆雷特的日译本,译本信息,哈姆雷特的日译本,译本),
(哈姆雷特的日译本,译本信息,出版、○○出版社),
....
作为用户进行的登记操作的结果,相关数据在与图41所示类似的DIT形式的目录结构中产生。
要注意,在图41所示的DIT形式的目录结构中,没有考虑目录信息树到子树的分割,以及可对于整个目录信息树定义分类类型和分类值,但平面目录结构在必要时可分割为子树。
在这个目录结构中,条目设置在与五个A节点(“哈姆雷特的出处”,“威尼斯商人的出处”,“哈姆雷特的日译本”,“哈姆雷特的中译本”,以及“哈姆雷特的演出”);A4,A9,A10,A19以及A13(参照图19等))对应的虚拟根条目下面。对于虚拟根条目,分类类型和分类值被定义,以及所定义分类类型和值在DB管理服务器5中根据图30所示的数据表来管理。
另外,在目录结构中,与A节点的关联角色对应的条目设置在与A节点对应的条目下面,以及与充当相应角色的T节点(T41,T42,T92,T101,T103,以及T191;参见图19)有关的数据设置为条目属性。
图41所示的相关数据全部存储在一个DB服务器6-1(图24)中。或者,相关数据根据顶部条目中的每个来分割,存储在五个DB服务器6-1至6-n中,并且成为由搜索程序42进行的搜索的目标。
图42和图43是第二和第三示意图,说明图41所示的目录结构的相关数据。
图42说明一种情况,其中,通过注意作为莎士比亚的作品的某个关联(题目),重新把相应条目“莎士比亚的作品”设置在根条目下面,以及相关数据设置在其下面,从而实现基于题目的分层结构。条目“莎士比亚的作品”对应于图26中虚线所示的条目(ou=关联#1至#n)之一。
图43说明一种情况,其中,表示分类类型“出处”、“译本”和“演出”(关联类型;A节点的节点类型)的条目被定义并重新设置在条目“莎士比亚的作品”的下面。
如上所述,通过根据关联类型(节点类型)把相关数据登记在条目下面,根据关联类型(节点类型)实现分层结构。
如图42所示,图41的相关数据还可进一步分级。
也就是说,“莎士比亚的作品”可定义为图41所示的相关数据中包含的节点的公共题目。这样,如图42所示,用户可操作DB管理服务器5来创建表明条目及其下面所存储的数据与五个A节点对应的条目上的莎士比亚的作品相关的新条目,并且可对相关数据分级。
在图42所示的情况中,以包含条目“莎士比亚的作品”下面的条目“哈姆雷特的出处(A4)”到“哈姆雷特的演出(A13)”的目录结构来表示相关数据。
例如,条目“莎士比亚的作品”以及条目“哈姆雷特的出处(A4)”到“哈姆雷特的中译本(A19)”或其下面的条目作为子树存储在DB服务器6-1中,以及条目“哈姆雷特的演出(A13)”或其下面的条目作为子树存储在DB服务器6-2中,等等,从而相关数据可根据目录结构被分割为子树。以这种方式得到的子树可被分割并存储在DB服务器6-1至6-n中。
在这种情况中,“莎士比亚的作品”和“哈姆雷特的演出”的目录设置为顶部条目,对于这些顶部条目定义分类类型和值,所定义分类类型和值由DB管理服务器5在图30所示的数据表中管理,并且其引用关系在图29所示的目录树表中管理。
在另一个实例中,在图42所示的相关数据的分层目录结构中,与“莎士比亚的作品”以及它下面的“哈姆雷特的出处”和“威尼斯商人的出处”对应的相关数据存储在DB服务器6-1中,与“哈姆雷特的日译本”和“哈姆雷特的中译本”对应的相关数据存储在DB服务器6-2中,以及与“哈姆雷特的演出”对应的相关数据存储在DB服务器6-3中。
要注意,顶部条目是子树中的根(顶部)条目,因而对于DB服务器6中存储的每个子树只定义一个顶部条目。对于这个顶部条目定义分类类型/值。
因此,在图42所示的实例中,为了在DB服务器6-2中存储与“哈姆雷特的日译本”和“哈姆雷特的中译本”对应的相关数据,提供顶部条目(例如与图43所示的“译本信息”对应的条目)以便结合这两个条目,并且存储其中把这个条目设置为顶部条目的子树。
以这种方式分割的子树的引用关系通过采用图29所示的目录表来管理,以及为各子树定义的分类类型和分类值通过采用图30所示的数据表来管理。
此外,当“出处信息”被定义为在图41所示的五个A节点之中的A4节点(“哈姆雷特的出处”)和A9节点(“威尼斯商人的出处”)的关联类型(节点类型),“译本信息”被定义为A10节点(“哈姆雷特的日译本”)和A19节点(“威尼斯商人的中译本”)的关联类型(节点类型),以及“演出信息”被定义为A13节点(“哈姆雷特的演出”)的关联类型(节点类型)时,所定义的关联类型(节点类型)可被分层,如图43所示。
例如,在图43所示的相关数据的分层结构中,与“莎士比亚的作品”以及它下面的“出处信息”对应的相关数据存储在DB服务器6-1中,与“译本信息”对应的相关数据存储在DB服务器6-2中,以及与“演出信息”对应的相关数据存储在DB服务器6-3中。
在这种情况中,“莎士比亚的作品”、“译本信息”和“演出信息”的条目被设置为顶部条目,为顶部条目定义分类类型和值,所定义的分类类型和值在DB管理服务器5中在图30所示的数据表中管理,并且其引用关系在图29所示的目录树表中管理。
当搜索者(用户)运行搜索程序42(图24)来搜索DB服务器6中存储的相关数据时,如图41至43所示,则搜索程序42分析搜索操作的内容,以及从DB管理服务器5获得与搜索操作的内容匹配的树信息(目录树表)和数据表的必要信息(图29和图30)。
此外,搜索程序42创建与搜索操作和树信息匹配的搜索条件(LDAP操作的命令和参数),并在存储与搜索条件匹配的目录信息的DB服务器6中执行搜索,以便获得搜索结果。
这样得到的搜索结果向搜索程序42的用户显示。
DB***4中的相关数据和搜索实例(2)
下面将通过表明用于商品促销的商品、商店和节目的销售信息的具体实例,更详细地描述如何登记相关数据以及如何在DB***4中检索已登记数据。
图44和图45是第四和第五示意图,说明在图24所示的DB***4的DB服务器6中登记的目录结构的相关数据。图44说明仅在特定区域、例如Kanto地区的销售信息,以及图45说明多个区域、例如Kanto和Kansai地区的销售信息。
通过图24所示的DB管理服务器5或PC 102的用户操作,Kanto地区的销售信息登记为图44所示的目录结构中表示的相关数据。
也就是说,根据用户输入的相关数据的已登记数据,结合与“销售信息”有关的目录信息的条目直接设置在虚拟根条目下面。在这个条目下面,设置与“Kanto地区”的销售信息有关的条目。
对于“Kanto地区”的销售信息,设置具有“位置信息”、“报价信息”和“参与信息”作为关联类型(节点类型)的条目。在这些条目下面,设置与诸如“商店”、“区域”、“报价”和“组织者”之类的关联角色对应的条目。作为这些条目的属性(属性存储在DB服务器6中,但没有定义或创建独立的管理表来管理属性),与充当“商店A”、“Shinjuku”等(对应于T节点ID表(图21)的节点ID和节点名称)的角色的成员有关的数据被登记。
要注意,图44等所示的“角色”对应于图20中所示的AR表的关联角色,以及“成员”对应于T节点。
在图20所示的实例中,对于关联节点(A节点)A4,成员T41充当“作者”的角色,以及成员T42充当“作品”的角色。
如图45所示,当销售信息还包含除了Kanto地区的信息之外的信息(Kansai地区的销售信息等)时,“销售信息”的条目直接设置在虚拟根条目下面。在这个条目下面,设置“Kanto地区”和“Kansai地区”的条目。在“Kansai地区”的条目下面,设置表示“位置信息”、“报价信息”和“参与信息”的关联类型(节点类型)的条目。
在这些条目下面,设置与“商店”、“报价”、“区域”、“组织者”等的角色对应的条目。作为条目的属性,与充当“商店B”、“商店C”、“Osaka”、“活动A”等的角色的成员有关的数据被登记。
例如,图44和图45所示的销售信息被分割为子树。例如,不同于虚拟根条目及其下面的“销售信息”的目录信息存储在DB服务器6-1(A;图24)中,“Kanto地区”及“销售信息”下级的目录信息存储在DB服务器6-2(B)中,“Kanto地区”或下级的目录信息存储在DB服务器6-3(C)中,以及不同于这些地区的地区的目录(未示出)信息存储在DB服务器6-4(D)等中。
图46说明表明图44和图45所示的销售信息(相关数据)的顶部条目和引用条目的目录树表。
图47说明表明图44和图45所示的销售信息(相关数据)的顶部条目的分类类型和值的数据表。
DB服务器6-1至6-3中存储的销售信息的顶部条目和引用条目、已分割目录树(或子树)的顶部条目、以及子树中存储的目录信息的分类类型/值由DB管理服务器5根据图46和图47所示的目录树表及数据表来管理。
图48说明用于图44和图45所示的销售信息的GUI图像。
图48所示的GUI图像在DB管理服务器5或PC 102的输入/输出装置126中显示。根据用户在GUI图像上的操作,在DB服务器6-1至6-3中登记的销售信息被搜索。
搜索仅Kanto地区的销售信息
首先描述图44所示的仅对Kanto地区的销售信息的搜索。
但是要注意,图44说明仅Kanto地区的销售信息,但作为实际的目录信息,其它地区的信息以及除销售信息以外的信息都被登记/存储。
搜索者(用户)在检索装置40的输入/输出装置126所显示的GUI图像(图48)上执行搜索例如“通过参与Kanto地区的某个销售节目而与商店B联系的商店”的操作。
图49说明一个过程,其中,图24所示的检索装置40从图46和图47所示的目录树表及数据表中检索目标DB服务器6。
例如,如图49所示,检索装置40分析搜索者的搜索请求的内容,并参考从DB管理服务器5得到的树信息中包含的数据表(图47)的内容,以便得到其中“地区”和“Kanto地区”作为分类类型和分类值被相关的子树(“Kanto地区”的目录)的顶部条目dn_B。
此外,检索装置40还搜索树信息中包含的目录树表(图46)的内容,以及检索顶部条目dn_B已经存储在其中的DB服务器6-2(B)。
图50说明创建从图48所示的搜索条件中得到的并用于搜索图44所示的仅Kanto地区的销售信息的LDAP操作的搜索请求消息。
要注意,图50说明用户以XML消息输入的搜索请求,并且用于实际搜索的LDAP操作命令从这个搜索请求来产生,但XML以外的格式并不排除在本发明的范围之外。
用于搜索“通过参与Kanto地区的某个销售节目与商店B联系的商店”的LDAP操作(LDAP命令和参数)从操作员所输入的搜索条件、从树信息得到的子树的顶部条目以及表明它存储在DB服务器6-2(B)的信息中产生,以及搜索在DB服务器6-2(B)中执行。
图50说明用于创建LDAP操作的搜索请求消息,它表明检索装置40在存储Kanto地区的目录以及此目录下面的条目的DB服务器6-2(B;图24)中执行以下搜索操作(1)和(2)。
(1)其下级条目“角色”为“参加者”以及其下级条目“成员”为“商店B”的条目从其中“关联类型”(图22所示的A节点的节点类型;关联类型)为“参与信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“组织者”的下级条目的那些中获得。
作为这个处理的结果,得到“节目A”,作为商店B参与的销售节目。
(2)其下级条目“角色”为“组织者”以及其下级条目“成员”为“节目A”的条目从其中“关联类型”为“参与信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“参加者”的下级条目的那些中获得。
作为这个处理的结果,得到“商店A”和“商店B”,作为参与销售节目“节目A”的商店。检索装置40选择不同于搜索操作(图48)的内容中包含的“商店B”的“商店A”,作为最终搜索结果。
搜索特定区域中的销售信息
随后将描述搜索图45所示的Kanto及其它地区的销售信息。
搜索者(用户)在检索装置40的输入/输出装置126中显示的GUI图像(图48)上执行搜索例如“不管地区(在所有地区)通过对商品报价来参与商店A参加的活动的商店”的操作。
检索装置40分析搜索者的搜索操作的内容,并搜索从DB管理服务器5得到的树信息中包含的数据表(图47)。但是,由于搜索操作的内容不限地区,因此检索装置40检索由“Kanto地区”、“Kansai地区”等的地区条目所引用的“销售信息”的条目(例如在图46中为dn_A)。
此外,检索装置40还搜索目录树表(图46),以及检索顶部条目dn_A已经存储在其中的DB服务器6-1(A)。
搜索“不管地区(在所有地区)通过对商品报价来参与商店A参加的活动的商店”的LDAP操作(LDAP命令和参数)从操作员所输入的搜索条件、从树信息得到的顶部条目以及表明它存储在DB服务器6-1(A)的信息中产生,以及搜索在DB服务器6中执行。
LDAP操作包括以下搜索操作。
(1)其下级条目“成员”为“商店A”以及其下级条目“角色”为“被报价方”的条目从其中“关联类型(图22所示的A节点的节点类型;关联类型)”为“报价信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“报价”的下级条目的那些中获得。
作为这个处理的结果,得到“商品A”,作为由商店A报价的商品。
(2)其下级条目“成员”为“商品A”以及其下级条目“角色”为“参加者”的条目从其中“关联类型”为“参与信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“组织者”的下级条目的那些中获得。
作为这个处理的结果,得到“活动A”,作为商品A被报价的活动节目。
(3)其下级条目“成员”为“活动A”以及“角色”为“组织者”的条目从其中“关联类型”为“参与信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“参加者”的下级条目的那些中获得。
作为这个处理的结果,检索装置40检索“商品A”和“商品C”,作为由参与活动A的商店报价的商品。
(4)其下级条目“成员”为“商品A”以及其下级条目“角色”为“报价”或者其下级条目“成员”为“商品C”且其下级条目“角色”为“报价”的条目从其中“关联类型”为“报价信息”的所有条目中获得,以及成员属性值(成员名称)从其中“角色”为“被报价方”的下级条目的那些中获得。
作为这个处理的结果,得到“商店A”和“商店C”,作为向活动A对商品A和C报价的商店,以及检索装置40从“商店A”和“商店C”中选择不同于搜索操作(图48)的内容中包含的“商店A”的“商店C”,作为最终搜索结果。
目录结构以及DB服务器之间的负荷分布的动态修改
如上所述,在DB***4(图24)中,相关数据以目录结构来表示。因此,易于执行在DB服务器6中基于子树的分割和复制。
因此,在DB***4中,例如,即使在对DB服务器6中存储的某个条目的访问因某种原因变得过多时,易于对负荷分布采取若干措施,例如添加用于存储条目的复制服务器(镜像服务器),以及把条目及其下级条目(某个条目及其下级条目的集合以下可称作子树)共同传送到另外的DB服务器6。
下面将对通过采用DB***4的特征的目录结构的动态修改和适合于DB服务器6之间的负荷分布以及防止DB***4的***性能下降的子树交换/移动进行描述。
下列方法用于对目录结构的动态修改以及在DB***4中的DB服务器6之间的子树交换/移动:
(1)在相同DB服务器6中的新子树的创建(新子树的提供),以及
(2)子树从高负荷DB服务器6到低负荷DB服务器6的传送,或者高负荷DB服务器6的频繁访问的子树与低负荷DB服务器6的不频繁访问的子树之间的交换(子树交换/移动)。
新子树的提供
首先将描述DB***4中的新子树的提供。
图51说明在图24所示的DB***4的DB服务器6中的新子树的提供,其中,(A)部分说明提供新子树之前的目录结构,以及(B)部分说明提供新子树之后的目录结构。
将考虑如图51(A)所示的一种情况,其中,当检索装置40把queryBaseDN设置为查询基础并通过采用过滤器queryFiler来执行搜索时,与搜索条件匹配的条目集中于某个DB服务器6所存储的目录树(或子树)的一部分中。
要注意,过滤器queryFiler对应于LDAP的搜索条件,以及条件“角色”=“报价”、“成员”=“商品C”等构成到目前为止所述的搜索操作中的过滤器queryFiler。
在过滤器queryFiler中,复杂条件可通过一些条件的逻辑积来表示。
DB服务器6计算对于每个搜索操作,各条目与搜索条件匹配的次数,以及这种计数的结果在DB管理服务器5中合计,从而在特定搜索条件下可得到一组频繁访问的条目及其上级条目。
例如,在提供新子树之前的目录结构(图51(A))中,通过执行这种测量,能够检测到附图所示的加阴影条目匹配搜索条件,以及在某些搜索条件(查询基础:queryBaseDN,过滤器:queryFilter)下访问集中在这些条目上。
当检测到这种访问集中时,把上级条目(groupDN)提供给一组访问集中的条目,以及那些条目将被构建为新子树。这样,对该条目集合的访问可被局部化,并且可防止DB***的性能的下降。
此外,还可准备在一个DB服务器6与另一个之间移动访问集中的子树。
图52说明用于图51(A)和(B)所示的新子树的提供的搜索条件管理表。
当通过提供上级条目(groupDN)新建子树时,DB管理服务器5(图24)创建其中把搜索起始条目(查询基础;queryBaseDN)、用于搜索的过滤器(queryFilter)以及在搜索起始条目之下并建立在访问集中条目之上的条目(新查询基础;groupDN)相关的搜索条件管理表,如图52所示,并把该表提供给检索装置40。
在接收搜索条件管理表以便创建搜索条件的情况下,当在其查询过滤器中包括上述特定过滤器(queryFilter)作为逻辑积的搜索在已改变条目(查询基础:queryBaseDN)之下的子树中进行时,检索装置40通过采用排除了不是用于原始搜索起始条目(查询基础;queryBaseDN)之下的子树、而是用于新建搜索起始条目(新查询基础;groupDN)之下的子树的特定过滤器(queryFilter)的过滤器来执行搜索。因此能够缩短搜索所需的时间。
当过滤器不包含特定过滤器(queryFilter)时,原始条目(queryBaseDN)被设置为搜索起始条目,以及搜索在所有下级子树的范围中被执行。
在提供新子树之后,如没有使用搜索条件管理表的情况那样,当搜索的顶部条目无法从数据表(图47)或者搜索条件管理表中得到时,检索装置40在DB服务器6-1至6-n(A至N)中从顶部目录执行搜索。
子树的移动/交换
图53(A)和图53(B)举例说明图24所示的DB***4的DB服务器6-1与6-2(A与B)之间的子树交换/移动,其中图53(A)说明子树交换之前的目录结构,以及图53(B)部分说明子树交换之后的目录结构。
将考虑如图53(A)所示的一种情况,其中存在访问集中于DB服务器6-2(B)的子树(条目dn_3或下级的子树),同时存在DB服务器6-1(A)中几乎没有访问的子树(条目dn_2或下级的子树)。
对每个条目的访问次数由DB服务器6计算,以及这种计数的结果由DB管理服务器5合计,从而可得到频繁访问的子树。同时可得到DB服务器6的负荷状态。另外,访问集中的子树可通过采用图52所示的搜索条件管理表来获得。
当检测到这种访问集中(不均匀性)时,如图53(B)所示,高负荷DB服务器6-2(B)的条目dn_3或下级的子树配置为DB服务器6-1(A)的条目dn_A-1或下级的子树,而DB服务器6-1(A)的条目dn_2的子树则配置为其中DB服务器6-2(B)的dn_2为顶部条目的子树,以及子树在DB服务器6-1与6-2(A与B)之间交换。因此,负荷可在DB服务器6-1与6-2(A与B)之间分布。
但是,宏观地考虑访问集中/不均匀性(例如,被搜索的次数少、从而降低访问和负荷的情况),并不是始终需要将搜索条件管理表用于子树移动/交换。
新子树(搜索条件管理表)的提供被设计以根据在某个时间点之前出现的在特定搜索条件下访问集中的程度来实现之后的高速(高效)搜索处理。
另一方面,子树移动/交换解决了以下问题:负荷的极不均匀分布因不取决于搜索条件或者不限于特定搜索条件的对于各服务器或子树的访问的绝对次数(频率)的增加/减少而出现。
图54说明由图53(A)和(B)所示的子树交换所引起的对DB服务器6-1和6-2(A和B)的目录树表(图46)的更新,其中,(A)部分说明更新前的目录表,以及(B)部分说明更新后的目录表。
要注意,这种子树交换对于如图51(A)和(B)所示的新增子树以及现有子树来执行。
当执行更新时,DB管理服务器5更新DB服务器6-1和6-2(A和B)的目录树表的内容,如图54(A)和(B)所示(但是,在本例中,DB服务器6-1(A)的目录树表的内容没有变化)。
例如,当访问集中于图53(A)所示的DB服务器6-1(A)的目录dn_1,而对整个DB服务器6-2(B)的访问不频繁从而设置低负荷状态时,仅通过把目录dn_1或下级的子树从DB服务器6-1(A)移动到DB服务器6-2(B),在DB服务器6之间分布负荷。
上述子树移动/交换根据以下过程来执行。
(1)访问频率的测量:DB服务器6测量对于从紧接虚拟根条目之下的条目到比相关数据的第一级基本成分(图26)高一层位置中的条目的条目的访问次数(频率),以及DB管理服务器5合计测量值。
(2)移动/交换源的子树的选择:在各DB服务器6中检测到对属于相同级的多个条目之下的子树的极不均匀访问(集中)时,DB管理服务器5选择这些条目之下的子树作为移动/交换源的子树。
(3)移动/交换目标的DB服务器的选择:在选择移动/交换源的子树时,DB管理服务器5选择其中没有作为下级条目来存储移动/交换源的子树并且其访问频率(负荷)整体上低于已经存储了移动/交换源的子树的DB服务器6的其它DB服务器6。
第三DB程序62
图55说明在图24所示的DB***4中新建或移动/交换子树时在DB服务器6中运行的第三DB程序62。
参照图55,DB程序62采用一种配置:数据传送单元620和访问监测单元624被添加到图37所示的第二DB程序60中。
采用这些组件,除了与第二DB程序60相似的那些功能之外,DB程序62还实现提供新子树和移动/交换所需的功能。
在DB程序62中,数据传送单元620根据来自DB管理服务器5的控制来传送图53(A)和53(B)所示的子树移动/交换所需的相关数据。
访问监测单元624测量对于DB服务器6中存储的目录信息的各条目的访问的次数(频率),并把测量值传送给DB管理服务器5。
第二DB管理程序56
图56说明在图24所示的DB***4中新建和移动/交换子树时在DB管理服务器5中运行的第二DB管理程序56。
参照图56,第二DB程序56采用一种体系结构:重新配置过程单元560、数据传输控制单元562(数据传输部件)、DB监测单元570、监测DB 572、搜索条件管理单元580、搜索条件DB 582以及搜索条件提供单元584被添加到图31所示的第一DB管理程序50中。
采用这些组件,除了与第一DB管理服务器50相似的那些功能之外,DB管理程序56还实现提供新子树和移动/交换所需的功能。
在DB管理程序56中,DB监测单元570合计从DB服务器6发送的对条目的访问次数(频率)以及与用于访问的LDAP的搜索操作有关的数据(查询基础以及过滤器),并把合计值存储在监测DB 572中。
DB监测单元570把所存储的访问频率合计值以及与搜索操作有关的数据输出到重新配置过程单元560。
重新配置过程单元560根据从DB监测单元570输入的对条目的访问次数的合计值来控制数据传输控制单元562,并执行如图51(A)和(B)所示的提供新子树的处理。
重新配置过程单元560根据对条目的访问次数的合计值来控制数据传输控制单元562,并执行如图53(A)和(B)所示的子树的移动/交换所需的处理。
此外,重新配置过程单元560还控制数据表管理单元534来执行如图54(A)和(B)所示的提供新子树以及移动/交换所引起的目录树表(图46)的修改所需的处理。
搜索条件管理单元580在新建或移动/改变子树时创建图52所示的搜索条件管理表,并把该表存储在搜索条件DB 582中。
另外,搜索条件管理单元580还把所存储搜索条件管理表输出到搜索条件提供单元584。
搜索条件提供单元584把从搜索条件管理单元580输入的搜索条件管理表提供给检索装置40(搜索程序44;图59)。
下面将更详细地描述访问次数的计数。
图57是流程图,说明图56所示的DB管理程序56的过程S56。
参照图57,在步骤S560,DB管理程序50执行初始化。
在步骤S562,DB监测单元570开始测量对DB服务器6的各条目的访问次数。
在步骤S564,DB服务器6从搜索控制单元264接收LDAP搜索操作命令。
在步骤S566,DB监测单元570检索输入到DB服务器6的搜索操作命令中包含的搜索条件。
在步骤S568,DB监测单元570从DB服务器6中检索与搜索条件匹配的条目的数据。
要注意,执行S564至S568的处理以便合计与DB服务器6所执行的搜索操作有关的数据,以及合计值从DB服务器6发送给DB监测单元570。
在步骤S570,DB监测单元570判断是否经过了合计与搜索操作有关的数据的预定测量时间。
DB管理程序56在经过了测量时间时进入S572的处理,否则进入S564的处理。
在步骤S572,DB监测单元570结束访问次数的测量。
在步骤S574,DB监测单元570在测量时间内从测量的开始到结束计算对所有条目的访问次数以及所有DB服务器6的负荷状态。
在步骤S576,重新配置过程单元560根据DB监测单元570所计算的测量结果来检测是否存在对所有条目的访问集中。
在步骤S578,DB监测单元570判断是否继续此过程。
如果继续此过程,DB管理程序56进入S560的处理,否则结束此过程。
图58说明在多个DB服务器上存储的相同层的条目。
例如,某个条目或子树上的访问集中通过下列方法(1)或(2)来确定。
(1)在预定测量时间内对所有搜索操作计算访问集中指数(访问集中指数=满足搜索条件的条目的数量/特定层存在的条目数量(图51(A))。
当每个搜索操作的执行次数大于预设数值,并且所计算的访问集中指数等于或小于门限值时,确定出现相对于搜索条件的访问集中。
(2)存储分割子树的DB服务器6被设置为测量的目标,在其中各子树的顶部条目以及属于与顶部条目相同层的所有条目用作根据搜索请求的查询基础的处理的次数(频率)被设置为对子树的访问频率,以及访问集中由类似于(1)的方法来确定。
第二搜索程序44
图59说明在图24所示的DB***4中新提供和移动/交换子树时在检索装置40上运行的第二搜索程序44。
参照图59,第二搜索程序44采用一种配置:搜索条件变换单元440被添加到图38所示的第一检索装置40中。
除了与第一检索装置40相似的那些功能之外,搜索程序44还通过采用搜索条件管理表来变换搜索条件。
在搜索程序44中,搜索条件变换单元440从DB管理单元5接收搜索条件管理表(图52),并判断搜索条件创建单元420创建的搜索条件中包含的过滤器和搜索起始条目(查询基础)是否匹配搜索条件管理表中表示的条件。
当搜索条件中包含的过滤器和查询基础匹配搜索条件管理表中表示的条件时,搜索条件变换单元440把原始搜索起始条目(查询基础;queryBaseDN)修改为新的搜索起始条目(新查询基础;groupDN),并且控制搜索条件创建单元420把过滤器变换为新的过滤器,其中,搜索条件管理表中表示的过滤器(queryFilter)从搜索条件的过滤器中删除。
新建子树时DB***4的操作
下面将描述新建子树时DB***4的整个操作。
如以上参照图51(A)所述,对于每个搜索操作、条目匹配搜索条件的次数由DB服务器6计数,以及这类计数结果由DB管理服务器5合计,从而可得到在特定搜索条件下的一组频繁访问的条目及其顶部条目。
当这种访问集中被确定时,通过在访问集中的条目集合中提供顶部条目(groupDN),以及把其下级条目构造为新子树,就能够使对条目集合的访问局部化,并且防止DB***的性能的下降。
DB服务器6通知DB管理服务器5关于对各条目的访问次数以及用于访问的过滤器的情况。
DB管理服务器5从DB服务器6计算对条目访问的次数(频率)以及用于访问的过滤器。
在对于某个DB服务器6的子树的访问频繁时,如图51(A)和(B)所示,DB管理服务器5控制DB服务器6来创建新的子树。
DB管理服务器5把搜索条件管理表(图52)的内容修改为匹配新建子树。
DB管理服务器5把已修改的搜索条件管理表提供给检索装置40。
在响应搜索者(用户)的搜索请求而根据搜索操作创建搜索条件时,检索装置40通过采用从DB管理服务器5提供的搜索条件管理表来执行变换,并且执行DB服务器6中的搜索。
移动/交换子树时DB***4的操作
下面将描述移动/交换子树时DB***4的整个操作。
如以上参照图58所述,通过合计各条目被设置为多个DB服务器上的相同层的条目的查询基础的次数,可确定子树上的访问集中。
DB服务器6测量每个条目用作查询基础的次数,并将结果通知DB管理服务器5。
DB管理服务器5计算各条目被设置为各DB服务器6的顶部条目以及与顶部条目相同层的其它DB服务器的所有条目的查询基础的次数,并计算每个子树的访问频率。
在对于某个DB服务器6的子树的访问频繁时,如图53(A)和(B)所示,DB管理服务器5控制DB服务器6来移动/交换子树。
另外,DB管理服务器5把目录树表(图46)、数据表(图47)等的内容修改为匹配所移动/交换的子树。
DB管理服务器5把已修改目录树和数据表提供给检索装置40。
检索装置40通过采用所提供的目录树和数据表,根据搜索者(用户)的搜索操作来执行DB服务器6中的搜索。
应当注意,虽然本发明的一些公开实施例以包含在计算机可读介质中并且可由计算机执行的软件指令的形式来实现,但本发明不限于这种配置。在备选实施例中,硬连线电路可以用来代替软件指令或者与其结合。因此,本发明不限于硬件电路和软件的任何特定组合。
还应当注意,本发明的公开实施例提供以下优点。
(1)公开实施例提供允许轻易添加各种信息、特别是数据元素或字段而无需改变数据库模式的数据模型及数据库***。
(2)公开实施例还提供允许数据被唯一分析、存储以及检索供再生的数据模型和数据库***。
(3)公开实施例还提供允许负荷容易地在多个处理装置之间分布的数据库***和管理方法及软件。
(4)公开实施例还提供允许用户搜索已登记信息的数据模型和数据库***以及管理方法及软件。
(5)公开实施例还提供把预先存在的数据库转换为允许轻易添加各种信息、特别是数据元素或字段而无需改变数据库模式的数据模型及数据库***的方法。
虽然已经描述和说明了本发明的具体实施例,但大家很清楚,可进行对具体说明和描述的实施例的细节上的变更,而没有明确背离所附权利要求中定义的本发明的真实精神和范围。

Claims (25)

1.一种数据库***,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联来创建目录树形式的数据库,所述一个或多个主题节点中的每个具有属于其中的数据,以及定义关联属性来表示相关联的关联节点与主题节点之间的关联中的每个,所述数据库***包括:
目录树创建部件,用于创建所述关联节点中的每个的关联节点条目以及所述关联属性中的每个的关联属性条目,以及用于通过根据相应关联节点与相应关联属性之间的关联将所述条目相关来创建目录树;以及
数据相关部件,用于根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
2.如权利要求1所述的数据库***,其特征在于,所述关联属性表示在相关联的关联节点与主题节点之间定义的角色。
3.如权利要求1所述的数据库***,其特征在于,
所述目录树包括一个或多个子树,
为所述目录树和所述子树定义所述目录树的顶部条目,
所述子树中每个的至少一个顶部条目引用所述目录树和/或其它子树的条目中的至少一个,以及
所述关联节点和主题节点在所述目录树和所述子树中以分层方式相关。
4.如权利要求3所述的数据库***,其特征在于,还包括顶部条目相关部件,用于把所述子树中每个的至少一个顶部条目与由所述至少一个顶部条目引用的目录树和/或其它子树中的至少一个条目相关。
5.如权利要求3所述的数据库***,其特征在于,还包括一个或多个第一数据库服务器,用于存储属于目录树和子树中的一个中包含的主题节点中至少一个的数据、属于与所述至少一个主题节点相关的关联节点的数据、以及根据目录树和子树中的所述一个在相关联的主题节点和关联节点之间定义的角色。
6.如权利要求5所述的数据库***,其特征在于,还包括数据传输部件,用于把一个所述第一数据库服务器中存储的数据传输并存储在另一个所述第一数据库服务器中。
7.如权利要求6所述的数据库***,其特征在于,所述数据传输部件根据从其中传输数据的第一数据库服务器的操作状态来确定要传输的数据。
8.如权利要求6所述的数据库***,其特征在于,所述数据传输部件根据对目录树或子树的访问状态来确定要传输的数据。
9.如权利要求5所述的数据库***,其特征在于还包括,
第二数据库服务器,用于存储第一数据库服务器中的一个或多个中存储的数据的复制品,以及
顶部条目相关部件,用于把子树中每个的至少一个顶部条目与由所述至少一个顶部条目引用的目录树和/或其它子树中的至少一个条目相关,以及还用于把第一数据库服务器的顶部条目与第二数据库服务器相关。
10.如权利要求9所述的数据库***,其特征在于,目录树和子树中的每个还包括一个或多个另外的子树,以及所述数据库***还包括用于从目录树和子树中的每个中创建至少一个所述另外的子树的子树创建部件。
11.如权利要求9所述的数据库***,其特征在于,为目录树和子树中的每个定义用于对关联节点和主题节点分类的分类信息,以及所述数据库***还包括用于把目录树和子树中的每个与为所述目录树或子树定义的分类信息相关的分类信息相关部件。
12.如权利要求11所述的数据库***,其特征在于,还包括检索装置,用于检索属于主题节点中至少一个的所存储数据。
13.如权利要求12所述的数据库***,其特征在于,所述检索装置包括
搜索条件接受部件,用于接受搜索条件,
目录树搜索部件,用于搜索与对应于所接受的搜索条件的分类信息相关的目录树或子树,以及
数据搜索部件,用于搜索属于由所述目录树搜索部件找到的目录树或子树中包含的主题节点中至少一个的所存储数据。
14.一种数据管理方法,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联来创建目录树形式的数据库,所述一个或多个主题节点中的每个具有属于其中的数据,以及定义关联属性来表示所述相关联的关联节点与主题节点之间的关联中的每个,所述方法包括:
创建关联节点中的每个的关联节点条目以及关联属性中的每个的关联属性条目;
通过根据相应关联节点和相应关联属性之间的关联将所述条目相关来创建目录树;以及
根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
15.如权利要求14所述的数据管理方法,其特征在于:
所述目录树包括一个或多个子树,
为目录树和子树定义目录树的顶部条目,
子树中的每个的至少一个顶部条目引用目录树和/或其它子树的条目中的至少一个,以及
目录树和子树中的每个还包括一个或多个另外的子树;以及
所述方法还包括从目录树和子树中的每个中创建至少一个所述另外的子树。
16.如权利要求14所述的数据管理方法,其特征在于:
所述目录树包括一个或多个子树,
为目录树和子树定义目录树的顶部条目,以及
子树中的每个的至少一个顶部条目引用目录树和/或其它子树的条目中的至少一个;以及
所述方法还包括:
存储属于目录树和子树中的一个中包含的主题节点中的至少一个的数据、属于与所述至少一个主题节点相关联的关联节点的数据、以及根据目录树和子树中的所述一个在相关联的主题节点和关联节点之间定义的角色;以及
搜索属于所述主题节点的所存储数据。
17.如权利要求16所述的数据管理方法,其特征在于还包括:
接受搜索条件;
搜索与对应于所接受的搜索条件的分类信息相关的目录树或子树;以及
搜索属于作为搜索结果得到的目录树或子树中包含的主题节点的所存储数据。
18.如权利要求14所述的数据管理方法,其特征在于还包括:
存储属于目录树和子树中的一个中包含的主题节点中的至少一个的数据、属于与所述至少一个主题节点相关联的关联节点的数据、以及根据目录树和子树中的所述一个在多个第一数据库服务器中在相关联的主题节点和关联节点之间定义的角色;以及
将一个所述第一数据库服务器中存储的数据传输并存储在另一个所述第一数据库服务器中。
19.一种其中存储程序的计算机可读介质,所述程序用于包括计算机的数据库***中,用于通过把一个或多个关联节点中的每个与一个或多个主题节点相关联来创建目录树形式的数据库,所述一个或多个主题节点中的每个具有属于其中的数据,以及定义关联属性来表示相关联的关联节点与主题节点之间的关联中的每个,
所述程序在所述数据库***中运行时,使所述计算机执行以下步骤:
创建关联节点中的每个的关联节点条目以及关联属性中的每个的关联属性条目;
通过根据相应关联节点和相应关联属性之间的关联将所述条目相关来创建目录树;以及
根据主题节点与相应关联属性之间的关联把属于主题节点之一的数据与所创建的关联属性条目相关。
20.如权利要求19所述的计算机可读介质,其特征在于:
所述目录树包括一个或多个子树,
为目录树和子树定义目录树的顶部条目,
子树中的每个的至少一个顶部条目引用目录树和/或其它子树的条目中的至少一个,以及
目录树和子树中的每个还包括一个或多个另外的子树;以及
所述程序在所述数据库***中运行时还使所述计算机执行从目录树和子树中的每一个中创建至少一个所述另外的子树的步骤。
21.如权利要求19所述的计算机可读介质,其特征在于:
所述目录树包括一个或多个子树,
为目录树和子树定义目录树的顶部条目,以及
子树中的每个的至少一个顶部条目引用目录树和/或其它子树的条目中的至少一个;以及
所述程序在所述数据库***中运行时,还使所述计算机执行以下步骤:
存储属于目录树和子树中的一个中包含的主题节点中的至少一个的数据、属于与所述至少一个主题节点相关联的关联节点的数据、以及根据目录树和子树中的所述一个在相关联的主题节点和关联节点之间定义的角色;以及
搜索属于所述主题节点的所存储数据。
22.如权利要求21所述的计算机可读介质,其特征在于,所述程序在所述数据库***中运行时,还使所述计算机执行以下步骤:
接受搜索条件;
搜索与对应于所接受的搜索条件的分类信息相关的目录树或子树;以及
搜索属于作为搜索结果得到的目录树或子树中包含的主题节点的所存储数据。
23.如权利要求19所述的计算机可读介质,其特征在于,所述程序在所述数据库***中运行时,还使所述计算机执行以下步骤:
存储属于目录树和子树中的一个中包含的主题节点中的至少一个的数据、属于与所述至少一个主题节点相关联的关联节点的数据、以及根据目录树和子树中的所述一个在多个第一数据库服务器中在相关联的主题节点和关联节点之间定义的角色;以及
将一个所述第一数据库服务器中存储的数据传送并存储在另一个所述第一数据库服务器中。
24.一种计算机可读存储器,其中存储了一种数据结构,所述数据结构包括:
主题节点字段,用于在其中存储属于多个对象的对象数据;
关联节点字段,用于在其中存储描述所述对象之间的关联的关联数据;以及
关联属性字段,用于在其中存储表示所述对象对于所述相关联的关联充当的角色的属性的角色数据。
25.一种用于把具有由多个链接所连接的多个节点的第一数据结构转换为具有多个相关联的主题节点和关联节点的第二数据结构的方法,所述方法包括:
把所述第一数据结构的节点中的每个转换为所述第二数据结构的主题节点之一;
把所述第一数据结构的链接中的每个转换为所述第二数据结构的关联节点之一;
在所述第二数据结构中,把关联节点中的每个与对应于在所述第一数据结构中由对应于所述关联节点的链接所连接的节点的主题节点中的两个相关联;以及
在所述第二数据结构中,把关联属性分配给相关联的关联节点与主题节点之间的每个关联,以表示所述节点对于所述第一数据结构中的相关链接所充当的角色的属性。
CNA2005101188625A 2004-10-25 2005-10-25 用于数据管理和/或转换的数据结构、数据库***及方法 Pending CN1766886A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004309439A JP2006120056A (ja) 2004-10-25 2004-10-25 データベースシステムおよびその方法
JP309439/04 2004-10-25

Publications (1)

Publication Number Publication Date
CN1766886A true CN1766886A (zh) 2006-05-03

Family

ID=35759244

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2005101188625A Pending CN1766886A (zh) 2004-10-25 2005-10-25 用于数据管理和/或转换的数据结构、数据库***及方法

Country Status (5)

Country Link
US (1) US20060122985A1 (zh)
EP (1) EP1650681A3 (zh)
JP (1) JP2006120056A (zh)
KR (1) KR20060049337A (zh)
CN (1) CN1766886A (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102687139B (zh) * 2009-09-08 2015-09-09 意大利电信股份公司 探索数字信息内容的目录的方法
CN105335448A (zh) * 2014-08-15 2016-02-17 ***股份有限公司 基于分布式环境的数据存储及处理***
CN106326427A (zh) * 2016-08-24 2017-01-11 明算科技(北京)股份有限公司 线性结构到树形结构的数据结构转换方法
CN106776714A (zh) * 2016-11-21 2017-05-31 辽宁工程技术大学 检索方法、装置和***
CN108897811A (zh) * 2018-06-19 2018-11-27 广州地铁集团有限公司 一种地铁设备维修数据的标准化方法及装置
US20220188339A1 (en) * 2020-12-16 2022-06-16 Electronics And Telecommunications Research Institute Network environment synchronization apparatus and method

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8180864B2 (en) 2004-05-21 2012-05-15 Oracle International Corporation System and method for scripting tool for server configuration
JP4696721B2 (ja) * 2005-06-27 2011-06-08 富士ゼロックス株式会社 文書管理サーバ、文書管理システム
US8078971B2 (en) * 2006-01-24 2011-12-13 Oracle International Corporation System and method for scripting explorer for server configuration
KR100758288B1 (ko) * 2006-02-10 2007-09-13 한국과학기술연구원 손 동작 기반의 입출력 장치, 시스템 및 방법
JP4876734B2 (ja) * 2006-06-22 2012-02-15 富士ゼロックス株式会社 文書利用管理システム及び方法、文書管理サーバ及びそのプログラム
JP5003131B2 (ja) * 2006-12-04 2012-08-15 富士ゼロックス株式会社 文書提供システム及び情報提供プログラム
JP4305510B2 (ja) * 2006-12-28 2009-07-29 富士ゼロックス株式会社 情報処理システム、情報処理装置及びプログラム
JP5082460B2 (ja) * 2007-01-19 2012-11-28 富士ゼロックス株式会社 情報処理装置及びプログラム及び情報処理システム
JP5023715B2 (ja) 2007-01-25 2012-09-12 富士ゼロックス株式会社 情報処理システム、情報処理装置及びプログラム
JP5042647B2 (ja) * 2007-01-26 2012-10-03 ヒューレット−パッカード デベロップメント カンパニー エル.ピー. 検索システムおよびその方法
JP2008257317A (ja) * 2007-04-02 2008-10-23 Fuji Xerox Co Ltd 情報処理装置、情報処理システム及びプログラム
JP2009042856A (ja) * 2007-08-07 2009-02-26 Fuji Xerox Co Ltd 文書管理装置、文書管理システム及びプログラム
JP5119840B2 (ja) 2007-10-02 2013-01-16 富士ゼロックス株式会社 情報処理装置、情報処理システム、及びプログラム
JP2009116496A (ja) * 2007-11-05 2009-05-28 Hitachi Ltd ディレクトリサーバ装置、ディレクトリサーバプログラム、ディレクトリサービスシステム、およびディレクトリサービス管理方法
US8509093B2 (en) * 2008-03-26 2013-08-13 Verizon Patent And Licensing Inc. Outage analysis system
US8326977B2 (en) * 2008-07-16 2012-12-04 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
KR101258322B1 (ko) * 2010-07-29 2013-04-25 주식회사 팬택 이동통신 단말 및 그의 컨텐츠 처리 방법
JP5582344B2 (ja) * 2010-08-09 2014-09-03 日本電気株式会社 接続管理システム、及びシンクライアントシステムにおける接続管理サーバの連携方法
JP5039189B2 (ja) * 2010-08-23 2012-10-03 株式会社東芝 分散型データベースシステム
KR101477672B1 (ko) * 2011-07-28 2014-12-30 네이버 주식회사 확장 가능한 분산 인덱스를 사용하여 데이터를 저장하는 장치 및 방법
EP2940975A1 (en) * 2014-04-28 2015-11-04 Koninklijke Philips N.V. Wireless communication system
WO2016178313A1 (ja) * 2015-05-07 2016-11-10 日本電気株式会社 情報処理装置、情報処理方法および情報処理プログラムを記憶する記録媒体

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61220027A (ja) * 1985-03-27 1986-09-30 Hitachi Ltd 文書ファイリングシステム及び情報記憶検索システム
JPH06332782A (ja) * 1993-03-22 1994-12-02 Hitachi Ltd ファイルサーバシステム及びそのファイルアクセス制御方法
US5608903A (en) * 1994-12-15 1997-03-04 Novell, Inc. Method and apparatus for moving subtrees in a distributed network directory
US5826254A (en) * 1995-04-18 1998-10-20 Digital Equipment Corporation System for selectively browsing a large, distributed directory tree using authentication links
US6105062A (en) * 1998-02-26 2000-08-15 Novell, Inc. Method and system for pruning and grafting trees in a directory service
US6735593B1 (en) * 1998-11-12 2004-05-11 Simon Guy Williams Systems and methods for storing data
US6487556B1 (en) * 1998-12-18 2002-11-26 International Business Machines Corporation Method and system for providing an associative datastore within a data processing system
AU2001243443A1 (en) * 2000-03-09 2001-09-17 The Web Access, Inc. Method and apparatus for performing a research task by interchangeably utilizinga multitude of search methodologies
US6965903B1 (en) * 2002-05-07 2005-11-15 Oracle International Corporation Techniques for managing hierarchical data with link attributes in a relational database
JP2004157925A (ja) * 2002-11-08 2004-06-03 Hitachi Ltd 情報処理システム及び情報処理方法
US8543564B2 (en) * 2002-12-23 2013-09-24 West Publishing Company Information retrieval systems with database-selection aids
US7593909B2 (en) * 2003-03-27 2009-09-22 Hewlett-Packard Development Company, L.P. Knowledge representation using reflective links for link analysis applications

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102687139B (zh) * 2009-09-08 2015-09-09 意大利电信股份公司 探索数字信息内容的目录的方法
CN105335448A (zh) * 2014-08-15 2016-02-17 ***股份有限公司 基于分布式环境的数据存储及处理***
CN105335448B (zh) * 2014-08-15 2018-09-21 ***股份有限公司 基于分布式环境的数据存储及处理***
CN106326427A (zh) * 2016-08-24 2017-01-11 明算科技(北京)股份有限公司 线性结构到树形结构的数据结构转换方法
CN106326427B (zh) * 2016-08-24 2019-08-06 明算科技(北京)股份有限公司 线性结构到树形结构的数据结构转换方法
CN106776714A (zh) * 2016-11-21 2017-05-31 辽宁工程技术大学 检索方法、装置和***
CN108897811A (zh) * 2018-06-19 2018-11-27 广州地铁集团有限公司 一种地铁设备维修数据的标准化方法及装置
US20220188339A1 (en) * 2020-12-16 2022-06-16 Electronics And Telecommunications Research Institute Network environment synchronization apparatus and method
US12026181B2 (en) * 2020-12-16 2024-07-02 Electronics And Telecommunications Research Institute Network environment synchronization apparatus and method

Also Published As

Publication number Publication date
KR20060049337A (ko) 2006-05-18
EP1650681A3 (en) 2006-11-22
JP2006120056A (ja) 2006-05-11
US20060122985A1 (en) 2006-06-08
EP1650681A2 (en) 2006-04-26

Similar Documents

Publication Publication Date Title
CN1766886A (zh) 用于数据管理和/或转换的数据结构、数据库***及方法
CN1262958C (zh) 使用元数据在关系数据库中创建多维数据集的方法和***
CN1279477C (zh) 检索关键字分析***和方法
CN1592905A (zh) 自动产生数据库查询的***和方法
CN1749999A (zh) .net数据类型和实例的持久存储
CN1629869A (zh) 产生和管理商业过程集成解决方案的***和方法
CN1604082A (zh) 用于任意数据模型的映射体系结构
CN1897556A (zh) 信息处理设备、信息处理方法和信息处理程序
CN1811772A (zh) 企业信息集成平台
CN1609855A (zh) 查询优化***和方法
CN1744036A (zh) 报告软件中支持定制图形表示的***和方法
CN1866253A (zh) 把Web服务映射到本体
CN101044484A (zh) 信息处理装置、方法以及程序
CN1310422A (zh) 数据处理方法、***、处理程序及记录媒体
CN1750003A (zh) 信息处理装置,信息处理方法,和程序
CN1292901A (zh) 数据库设备
CN1678991A (zh) Web服务设备和方法
CN1949763A (zh) 共享信息服务器***
CN1359081A (zh) 结构编辑装置、目标内容结构的管理及显示方法和记录媒体
CN1524216A (zh) 软件构件插件程序结构的***和方法
CN1726495A (zh) 规定用于关系olap引擎的多维计算
CN1809829A (zh) 数据库装置和作成方法、数据库检索装置及检索方法
CN1839403A (zh) 经改进的慈善管理***和商务方法
CN1856783A (zh) 使用参考与一般数据项关联的数据管理结构
CN1510593A (zh) 编排***、编排程序和编排方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication