專利名稱:將非結構化數據實時聚集為結構化數據以便關系數據庫引擎進行sql處理的制作方法
技術領域:
本發明涉及搜索(即查詢)存儲在數據庫中的非結構化(unstructured)數據的方法,包括將SQL查詢轉換為非結構化數據的適當查詢。本發明的另一個方面是將結構化關系數據庫所標識的外部SQL訪問類型轉換為非結構化數據庫或文件的內部訪問,并且將SQL外部查詢格式轉換為中間或內部查詢格式。本發明的方法、系統和程序產品特別應用于文本搜索和索引。
背景技術:
通過SQL訪問結構化數據與例如web上文檔的非結構化數據的全文本搜索是非常不同的。在具有行和列的二維表中維護關系模型中的結構化數據。表中每行代表對象的一個實例(instance),而每列代表該對象的屬性。給列賦予符號化名稱,并分配特定的數據類型(例如整數、日期等)。可以對列施加完整性限制,以進一步指示有效值。
由于以固定格式命名和表示了列值,可以非常精確地基于其內容選擇行。所述能力在處理數字數據中非常有用。可以基于匹配列值將來自不同表的數據結合在一起。可以進行有用類型的分析,例如在一個表中列出在相關表中遺漏的(或在相關表中呈現的,或具有指定屬性的)對象。可以從一張大表中提取感興趣的特定行,重新組合所述行,并對其產生簡單的統計。
相反,不總是以固定的并且可預測的方式組織非結構化數據。非結構化數據以各種形狀和格式被存儲,在整個企業中分布,并由針對正在進行的任務最合適的軟件進行管理。趨向于以自由文本格式記錄數據(例如,包含于電子郵件、筆記和文檔中的文本),所述格式具有很少或沒有編成字段的元數據。因此,搜索實際上是較少地參數化,而更多的是基于關鍵字的。搜索結果更多的是得自于“匹配”給定關鍵字集合,而很少得自于計算標準。
然而,希望以結構化方式查詢非結構化數據,以將更多的值增加到結果集合中。將web看作可以使用標準SQL查詢的關系數據庫是有益的。同樣重要的是,能夠通過SQL接口統一地處理多個異構和非結構化數據源也是有益的,因此消除了數據集成的模糊性。
解決所述問題的常規技術是從非結構化數據源中提取預期數據,對數據應用任何必要的轉換,然后將如此轉換的數據放置到關系數據庫中,以進行以后處理。實際上,這種倉儲(warehousing)技術是現在針對各種應用所使用的一種通用方法。
然而,所述技術沒有涉及使非結構化數據可用于參數化查詢的構建(overarching)問題。
發明內容
我們通過用于參數化搜索非結構化數據的方法、系統和程序產品解決了上述問題。通過由擴展搜索協調器(Extended Search Broker)首先搜索非結構化數據,來搜索例如文本數據或圖像數據的非結構化數據。擴展搜索協調器具有用于非結構化數據搜索的搜索請求者和搜索代理(agent)之間的中間部件。搜索代理返回搜索結果給協調器以進行聚集(aggregation)。協調器聚集搜索結果并將其返回給包裝器(wrapper)。包裝器然后從聚集的搜索結果中提取屬性,并使所述屬性作為別名(nickname)表中的一個或多個列。關系數據庫使用結構化查詢語言(SQL)可以搜索所述別名表。
本發明的一個方面是一種搜索非結構化數據的方法。所述方法包括通過擴展搜索協調器搜索非結構化的數據。所述擴展搜索協調器具有用于非結構化數據搜索的搜索請求者和搜索代理之間的中間部件。搜索代理返回來自搜索代理的搜索結果給協調器以聚集搜索結果到包裝器中。接著,在別名表中輸入結果屬性,其中關系數據庫使用結構化查詢語言可以搜索所述別名表。
本發明的另一個方面是一種計算機系統,所述系統具有非結構化數據搜索系統、和結構化數據搜索引擎,兩者由別名表在邏輯上或虛擬地結合在一起。計算機系統適用于啟動通過結構化數據搜索引擎啟動的非結構化數據的搜索。非結構化數據搜索系統包括用于非結構化數據搜索的擴展搜索協調器和搜索代理。非結構化數據搜索系統從搜索代理接收搜索結果,并發送搜索結果和搜索結果屬性給擴展搜索協調器以聚集到包裝器中。計算機系統適用于將包裝器屬性輸入別名表中。結構化數據搜索引擎適用于在別名表中進行搜索結果屬性的搜索。
本發明的又一個方面是一種計算程序產品,包括計算機可讀代碼以編程并配置計算機系統通過非結構化數據搜索系統搜索非結構化數據,所述系統包括用于非結構化數據搜索的擴展搜索協調器和搜索代理。程序產品還包括能夠使搜索結果和搜索結果屬性從搜索代理返回給協調器以進行聚集、并將搜索結果和搜索結果屬性聚集在包裝器中的代碼。代碼然后在別名表中輸入搜索結果屬性,作為別名表中的一個或多個列,其中關系數據庫使用結構化查詢語言可以搜索所述別名表,以搜索非結構化數據。
根據本發明,可以通過聯合(federated)關系數據庫引擎和擴展搜索引擎的組合來搜索非結構化數據,分別例如IBM DB2聯合數據庫和IBM Lotus擴展搜索。聯合關系數據庫引擎和擴展搜索引擎的組合提供了到在整個企業中分布的非結構化數據的關系接口。
RDBMS聯合(federation)提供了可擴展體系結構,通過所述體系結構,內部和外部開發者可以編寫包裝器以集成外部數據源。聯合RDBMS包裝器是封裝(或包裝)所需原始API調用以從外部服務器取回數據的模塊。當參考數據的相關聯的別名表中的數據以在遠端數據源上處理查詢時,通過在SQL處理周期中各個點上的回調(callback)來激活包裝器。
別名表是專門用于聯合的特殊類型的RDBMS表。別名表不包括固定數據而是由包裝器根據需要向其中填充數據。在本上下文中,別名表是虛擬表,并不真實存在于物理意義中,但是仍支持大多(或者全部)可以在SQL表達式中表達的表操作。
擴展搜索引擎,例如IBM Lotus擴展搜索,是這樣一種產品,通過允許用戶搜索和取回所有類型信息,而不僅是主機軟件所管理的數據,“擴展”了其它搜索產品的標準能力。擴展搜索引擎是基于協調搜索技術(brokered search technology)的,所述技術提供了貫穿整個企業分布的數千數據源的高效的并行搜索。擴展搜索引擎代理以后端數據庫系統的原始語法來執行遠端搜索。代理返回結果給協調器,以進行聚集并遞送給原始調用方(original caller)-在所述情況下是擴展搜索引擎包裝器。
通過如上所述集成所述兩種技術,可以實現幾個好處。第一,通過擴展搜索引擎別名表的加載,包括實時加載,使得來自不同數據源類型集合的非結構化數據,對于RDBMS引擎而言為實時可用的。通過所述手段,數據是當前的并且是更新的。雖然其它聯合包裝器針對單個源提供了當前數據,但是僅有擴展搜索引擎包裝器同時針對多個數據源啟用這種能力。以這種方式,將擴展搜索引擎包裝器接收的數據作為單個標準化的數據集合呈現出來,即使在其形成中包括了多個源。
第二個好處是數據保持分布在整個企業中,在邏輯上或虛擬地離執行工作的地點最近。擴展搜索引擎而不是關系數據庫引擎負責搜索存儲在不同位置上的數千數據源。與擴展搜索協調器結合使用的擴展搜索包裝器作為所述大量非結構化信息的網關。
第三個好處是針對非結構化信息的聚集應用關系概念的能力。單獨通過擴展搜索引擎不可能將接收于一個源的結果和接收于其它離散源的結果關聯起來,以獲取從屬(subordinate)結果集合。例如,不可能基于匹配字段值將來自不同源的數據結合起來。擴展搜索引擎僅對返回數據執行聚集(類似于SQL中的UNION查詢),以產生單個的結果集合。但是,一旦通過擴展搜索引擎包裝器,使得數據對于別名表為可用的,則通過RDBMS引擎,數據可以自由與數據庫中任何其它表,包括其它別名表結合。
所述能力具有深遠意義。通過使用本發明概念,針對可由擴展搜索引擎取回的每種不同類型的數據配置別名表,現在可以利用關系引擎的能力來輕易地在數據的主機環境之外集成所述數據。
在附圖中說明了本發明的特定實施例和示例。
圖1說明各種硬件和軟件平臺,所述平臺可能用在本發明的實施中。示出了兩個終端用戶客戶端,其中一個通過World Wide Web和web服務器連接到數據服務器上,另一個客戶端通過局域網連接到數據服務器上。Web服務器連接到兩個關系數據庫管理系統上,并且連接到擴展搜索服務器上,所述搜索服務器依次連接到兩個非結構化數據庫上。
圖2是說明本發明的方法和系統的各種元件的框圖,其中用戶輸入SQL查詢到關系數據庫管理系統中。關系數據庫管理系統是聯合關系數據庫管理系統,并且使用具有擴展搜索協調器和代理的擴展搜索系統,來搜索非結構化數據。通過擴展搜索別名表和擴展搜索數據庫來訪問所述結果。
圖3說明了通過使用結構化數據搜索引擎產生非結構化數據的查詢以執行查詢處理的方法。結構化數據搜索引擎輸入查詢到擴展搜索協調器中。擴展搜索協調器然后將查詢傳輸給搜索代理,所述代理搜索非結構化數據,并返回搜索的結果,在包裝器中聚集搜索結果。將結果屬性分配給包裝器,并且將結果屬性輸入到結構化數據搜索引擎可搜索的別名表中。結構化數據搜索引擎然后查詢別名搜索表。
具體實施例方式
本發明有助于通過關系數據庫管理系統使用結構化查詢語言來搜索非結構化數據。本發明包括使用結構化查詢語言和關系數據庫管理系統通過擴展搜索協調器來搜索非結構化數據。擴展搜索協調器具有用于非結構化數據搜索的搜索請求者和搜索代理之間的中間部件。搜索代理返回其搜索結果給擴展搜索協調器,以聚集搜索結果到具有結構化查詢語言可搜索屬性的包裝器中。將包裝器屬性輸入到別名表中,其中關系數據庫使用結構化查詢語言可以搜索別名表。
本發明的另一個方面是一種計算機系統,所述計算機系統具有至少兩個搜索引擎,一個是非結構化數據搜索引擎,另一個是結構化數據搜索引擎。別名表在邏輯上,即虛擬地將所述搜索引擎結合在一起。計算機系統適用于通過非結構化數據搜索引擎和結構化數據搜索引擎的別名表的協同交互,來進行非結構化數據的搜索。
本發明的另一個方面是一種計算機程序產品,所述產品包括計算機可讀代碼,所述代碼用于編程和配置計算機系統,以通過非結構化數據搜索系統,從用于結構化數據的關系數據庫管理系統中搜索非結構化數據,所述非結構化數據搜索系統包括擴展搜索協調器,所述擴展搜索協調器具有非結構化數據搜索的搜索請求者和搜索代理之間的中間部件。所述程序產品還包括代碼,所述代碼能夠使來自搜索代理的搜索結果返回給協調器以進行聚集,并將搜索結果和搜索結果屬性聚集在包裝器中。所述代碼然后將結果屬性輸入到別名表中,其中關系數據庫使用結構化查詢語言可以搜索別名表以搜索非結構化數據。
聯合關系數據庫管理系統和擴展搜索系統的集成系統根據本發明,通過聯合關系數據庫引擎和擴展搜索引擎之間的組合和交互來搜索非結構化數據,所述引擎例如為IBM DB2聯合數據庫和IBM Lotus擴展搜索。聯合關系數據庫引擎和擴展搜索引擎的組合提供了對可能貫穿整個企業分布的非結構化數據的關系接口。
RDBMS聯合提供了可擴展體系結構,內部和外部開發者可以通過所述體系結構編寫包裝器以集成外部數據源。聯合的RDBMS包裝器是封裝(即包裝)所需原始API調用以從外部服務器上取回數據的模塊。當參考相關聯別名表中的數據時,通過在SQL處理周期中戰略(strategic)點上的回調來激活包裝器。
別名表是專門用于數據庫聯合的特定類型的RDBMS表。別名表不包括固定數據而是由包裝器根據需要向其中填充數據。在本上下文中,別名表是虛擬表,并不真實存在于物理意義中,但是仍支持大多數(或者全部)可以在SQL表達式中表達的表操作。
擴展搜索引擎,例如IBM Lotus擴展搜索,是一種產品,所述產品通過允許用戶搜索和取回所有類型信息,而不僅是主機軟件所管理的數據,“擴展”了其它搜索產品的標準能力。擴展搜索引擎是基于協調搜索技術的,所述技術提供了貫穿整個企業分布的數千數據源的高效的并行搜索。擴展搜索引擎代理以后端數據庫系統的原始語法來執行遠端搜索。代理返回結果給協調器,以進行聚集并遞送給原始調用方-在所述情況下是擴展搜索引擎包裝器。
在附圖中說明了本發明的特定實施例和示例。
圖1是說明各種硬件和軟件平臺的框圖,所述平臺可以用在本發明的一個實施示例中。示出了兩個終端用戶客戶端101和102,其中一個101通過World Wide Web 105和web服務器111連接到數據服務器121上,另一個客戶端通過局域網連接到數據服務器121上。Web服務器111連接到兩個關系數據庫管理系統131、132上,并且連接到擴展搜索服務器141上,所述搜索服務器141依次連接到兩個非結構化數據庫服務器151和152上。非結構化數據庫服務器151或152可能包括一個或多個非結構化數據庫,以及可選地是web客戶端,其中另外的web服務器和數據服務器的組合包括將被搜索的非結構化數據。
圖2是說明本發明的方法和系統的各種元件的框圖,其中用戶201輸入SQL查詢202到關系數據庫管理系統203中。關系數據庫管理系統203是聯合關系數據庫管理系統,并且使用具有擴展搜索協調器204和代理205、205’的非結構化數據搜索系統,來搜索非結構化數據206和206’。結果存儲在擴展搜索別名表207和擴展搜索數據庫208中。
圖3說明了在步驟301中通過使用結構化數據搜索引擎產生非結構化數據的查詢以執行查詢處理的方法。在步驟303中結構化數據搜索引擎將查詢輸入到包括擴展搜索協調器的非結構化搜索系統中。在步驟305中擴展搜索協調器然后將請求傳輸給搜索代理,在步驟307中所述代理搜索非結構化數據,并在步驟309中返回搜索的結果和結果屬性,在步驟311中將搜索結果和結果屬性聚集到包裝器中。在步驟313中將結果屬性分配給包裝器,并且在步驟315中將結果屬性輸入到結構化數據搜索引擎可搜索的別名表中。結果屬性被輸入到別名表中,作為一列。在步驟317中結構化數據搜索引擎然后查詢別名搜索表,并返回查詢結果給請求者。
通過如上所述集成聯合數據庫和擴展搜索技術,可以實現幾個好處。第一,通過擴展搜索引擎別名表的加載,包括實時加載,使得來自不同數據源類型集合的非結構化數據,對于RDBMS引擎而言為實時可用的。呈現給結構化數據庫搜索引擎(關系數據庫管理系統)的數據是當前的并且是更新的。雖然其它聯合包裝器針對單個源提供了當前數據,但是僅擴展搜索引擎包裝器同時針對多個數據源啟用該能力。以這種方式,將擴展搜索引擎包裝器接收的數據作為單個標準化的數據集合呈現出來,即使在其形成中包括了多個源。
第二個好處是數據保持分布在整個企業中,邏輯上離執行工作的地點最近。擴展搜索引擎而不是關系數據庫引擎負責搜索存儲在不同位置上的數千數據源。與擴展搜索協調器結合使用的擴展搜索包裝器作為所述大量非結構化信息的網關。
第三個好處是針對非結構化信息的聚集應用關系概念的能力。單獨通過擴展搜索引擎不可能將接收于一個源的結果和接收于其它離散源的結果關聯起來,以獲取從屬結果集合。例如,不可能基于匹配字段值將來自不同源的數據結合起來。擴展搜索引擎僅在返回數據上執行聚集,以產生單個的結果集合。但是,一旦通過擴展搜索引擎包裝器,使得數據可用于別名表,則通過RDBMS引擎,數據可以自由與數據庫中任何其它表,包括其它別名表結合。
所述能力具有深遠意義。通過使用本發明概念,針對可由擴展搜索引擎取回的每個不同類型數據配置別名表,現在可能使用關系引擎的能力來輕易地在數據的主機軟件之外集成所述數據。
說明示例通過舉例的方式,假設智能代理試圖識別可能是潛在恐怖分子的個人。在所述代理能夠訪問各種敏感源的情況下,他們可能提出如下問題“列出下述人員的姓名所述人員在一定時間內獲得簽證、從這些天起購買了大量化肥、與有關炸藥制造的人員進行過e-mail通信、并且申請了B類(卡車)駕照。”需要搜索的源是很多的,并且具有各種等級的結構。然而每個源具有可以用于執行結合(join)的人員的概念(通過姓名標識)。擴展搜索系統將用來執行到遠端數據源的協調搜索(brokered search)以及返回合適的數據,但是然后將依賴于關系引擎以執行結合。為了進行結合,需要將數據組織成為分離的別名表,每類要搜索的數據源使用一個表。
上述例子中需要4個別名表。配置一個別名表來代表e-mail結果,另一個別名表代表駕照信息,另一個代表化肥購買,還一個代表簽證申請。每個別名表與一個或多個類似目的的擴展搜索源相關聯。例如,應用于駕照別名表的查詢可能實際上導致了50個機動車輛注冊數據源(每個州一個)的擴展搜索。
假設每個別名表將包括針對個人姓名的外來關鍵字(foreignkey),執行結合將基于所述個人姓名。擴展搜索字段映射將用來通過后端源(此后將詳細解釋)中遇到的語句構成不同,來標準化別名表中的外來關鍵字。給定以所述方式配置所述4個別名表,則現在可能在SQL中提出如下詢問表格簽證
表格駕照
表格郵件
表格購買
SELECTN1.FirstName,N1.LastNameFROM INS as N1,DRIVERas N2,EMAIL as N3,FERTILIZERas N4WHERE ES_SEARCH(N1.DOC_RANK,‘DATE_OF_ISSUE>=“01/01/2000’”)=1ANDES_SEARCH(N2.DOC_RANK,‘LICENSETYPE=“B”’)=1
ANDES_SEARCH(N3.DOC_RANK,‘DOCUMENT TOKEN“bomb”and DOMCUMENT TOKEN“fabrication”’) =1ANDES_SEARCH(N4.DOC_RANK,‘ProductType=“FERTILIZER”and Quantity>500 andDate>“01/01/2000”’) =1ANDN1.LastName=N2.LastName ANDN2.LastName=N3.LastName ANDN3.LastName=N4.LastName如前面提到的,擴展搜索具有將通用字段名映射到后端上一個或多個語義上相同但是句法不同的字段的能力。在從別名表中產生有意義的數據模型中,這將是非常有用的。
例如,50個駕照數據庫中的個人姓名的符號標識大多可能不同,特別是由于各個州自由構建它們自己的MVA數據庫。通過擴展搜索,可以定義持照者名稱的單個字段,并將其映射到駕照數據庫中合適的原始字段。然后在駕照別名表中可以使用針對持照者名稱單個映射的字段。如果沒有該映射特征,將被迫在后端數據庫中為每個唯一定義的名稱字段定義一個別名列。所述表將水平增長出許多列,并且將不會為第3種正常形式。由于任何一行一次僅填充一個姓名列,則將稀疏地填充所述表。
然而存在可能利用來自許多離散數據源的大量字段的應用。對于所述應用,數據(特別是非結構化數據)之間的關系不是預先已知的,因此定義和結構化別名表是非常困難的。通過填充所謂的垂直別名表,擴展搜索可以支持所述類型應用。
垂直別名表包括4個預定義列。它們是字段名稱、字段值、字段類型和源名稱。不是使用前面例子建議的映射字段,而是通過使擴展搜索返回原始字段名稱/值對來進行反向操作。也返回元數據,例如字段類型(例如日期、整數等)和數據的來源。現在密集地通過許多數據行填充了別名表-針對每個數據源的每個字段使用一行。
但是如何在關系模型中使用這些垂直別名表?假設相同的智能代理詢問一系列問題,所述問題有助于所述代理發現數據之間的有用關系,而不管所述數據從何處而來。所述代理已經建立了擴展搜索系統,以在上千個具有自己的數據模型和字段集合的各種類型數據源上進行查詢。在不知道哪些字段將與你的搜索有關的情況下,可以配置擴展搜索來搜索并返回所有字段。以剛才所述的垂直格式返回這些字段。
現在智能代理可以使用關系引擎來發現并分析數據關系自身。所述代理可能要求包含詞“化肥”的所有字段,通過數據源名稱排列結果。
聯合關系數據庫管理系統聯合數據庫管理系統,也稱作聯合數據庫系統或聯合系統,是其中每個數據庫服務器是自治并且獨立的集中的DBMS的系統,所述DBMS具有自己的本地用戶、本地業務、數據庫管理員并且因此具有高度的本地自治性。在聯合數據管理系統中,每個單獨服務器可以通過指定“輸出計劃(export schema)”來授權其服務器的指定部分的訪問,所述輸出計劃指定可以由非本地用戶的指定集合訪問的其數據庫部分,以及所述非本地用戶具有的規范。在聯合數據庫管理系統中,用戶基本上是到幾個本地數據庫管理系統的額外接口,由此允許全局用戶訪問多個本地、自治數據庫。
聯合數據庫管理系統,例如IBM DB2全球數據庫聯合系統,支持提交SQL語句的應用和用戶,其中在單個語句中引用兩個或多個DBMS或數據庫。一個例子是兩個不同DB2數據庫中的表之間的結合。這種語句稱作分布式請求。
DB2全球數據庫聯合系統提供對數據庫和DBMS的分布式請求的支持。用戶例如可以在DB2表和Oracle視圖之間執行UNION操作。
聯合數據庫管理系統,例如IBM DB2聯合系統。提供數據庫對象的位置透明度。如果移動了信息(在表中和視圖中),可以更新對所述信息的參考(稱作別名),而無需對請求所述信息的應用的任何改變。聯合數據庫管理系統的另一個方面是數據源的補償,所述數據源不支持所有特定SQL方言(dialect)、人為缺陷(artifact)、或相互之間的特定優化能力。在所述DBMS下不能執行的操作(例如,不能實現GROUP BY條款的文件系統)在DB2下運行。
可以提交半自治方式的聯合系統功能,即包含對Oracle對象的參考的IBM DB2查詢,而同時Oracle應用訪問相同的服務器。聯合系統不會獨占或限制訪問(除了完整性和鎖定限制)遠端數據源上的其它對象。
在IBM DB2全球數據庫聯合系統的情況下,所述系統包括IBMDB2UDB實例,一種將作為聯合數據庫的數據庫以及一個或多個數據源。聯合數據庫包括標識數據源和它們特征的目錄條目(catalogentries)。數據源包括DBMS和其數據。應用連接到聯合數據庫上,正如連接到任何其它數據庫一樣。
聯合數據庫目錄條目包括關于數據源對象的信息被稱作什么,包括了什么信息,在什么條件下可以被使用。由于聯合數據庫目錄存儲了關于許多數據源中的對象的信息,所以被稱作全局目錄。對象屬性被存儲在目錄中。被引用的實際數據源、用于與數據源通信的模塊以及將訪問的DBMS數據對象(例如表)在數據庫之外。在這方面,應當注意到一個例外是聯合數據庫可以是聯合系統的數據源。具體地,IBM DB2支持遠端數據源和遠端DBMS的聯合。
可以使用例如IBM DB2 UDB控制中心或SQL數據定義語言(“DDL”)語句來產生聯合對象。作為通用規則,所需聯合數據庫對象是包裝器、服務器和別名。包裝器識別用于訪問特定類別的數據源的模塊(DLL、庫等等)。在本上下文中,服務器定義數據源。服務器數據包括包裝器名稱、服務器名稱、服務器類型、服務器版本、授權信息、和服務器選項。別名是在聯合數據庫中存儲的標識,所述標識參考了特定的數據源對象(表、化名、視圖)。應用程序在查詢中參考了別名,正如參考表和視圖一樣。
在建立了聯合系統之后,可以訪問數據源中信息,就像所述信息在一個大的數據庫中一樣。用戶和應用程序發送請求給一個聯合數據庫,如果需要,所述數據庫然后從DB2家族和Oracle系統中取回數據。用戶和應用程序在查詢中指定了別名;所述別名提供了對位于數據源中的表和視圖的參考。從終端用戶的角度出發,別名類似于化名(aliase)。
許多聯合系統在一些限制之下操作。例如,分布式請求可能被限制為只讀操作。在一些聯合系統中,不能針對別名執行實用操作(LOAD,REORG,REORGCHK,IMPORT,RUNSTATS等等)。然而,請求者可以使用傳遞工具(pass-through facility)來通過使用與所述數據源相關聯的SQL方言,將DDL(數據定義語言)和DML(數據處理語言)語句直接提交給數據庫管理者。
聯合系統容忍并行環境。性能增益受到聯合數據庫查詢可以在語義上被分解為本地對象(表、視圖)參考和別名參考的程度。連續處理別名數據的請求;可以并行處理本地對象。例如,給定查詢SELECT*FROM A,B,C,D其中A和B是本地表,而C和D是引用Oracle數據源上的表的別名,一個可能的計劃是通過并行結合來結合表A和B。然后將結果與別名C和D順序結合。
擴展搜索引擎和擴展搜索應用擴展搜索引擎通過允許終端用戶搜索并取回所有類型信息,而不僅是主機軟件所管理的數據,“擴展”了其它搜索產品的標準能力。例如,使用標準web瀏覽器,終端用戶可以輕易地并且迅速地定位和閱覽包含于散布在組織中的數千數據倉庫中的信息。所述倉庫可能是各種內容和結構,并且所述倉庫可能在地理上散布于全球。
通過單個查詢,終端用戶可以同時搜索內部和外部web站點、全文索引、Microsoft索引、文檔管理系統、e-mail系統、文件系統、關系數據庫、LDAP目錄和Lotus數據庫的完全補充。擴展搜索引擎可以被認為是代表用戶進行工作的協調代理(brokered agent);所述引擎搜索原始形式的每個數據儲備(data store),并在單個聚集結果集合中返回結果。
擴展搜索引擎對終端用戶屏蔽數據源多樣性。這是因為終端用戶與單個、通常是功能豐富的擴展搜索引擎接口進行交互,所述接口將終端用戶搜索透明地分發給潛在的數千個不同種類的數據儲備。可以以各種方式呈現結果。
比起終端用戶從典型搜索應用中所期待的,通過擴展搜索,終端用戶經歷了更多。終端用戶發現其觸及范圍已經進一步擴展到企業中,并且可以訪問以前不能輕易獲得的信息。
幾乎所有搜索系統都包括對將要搜索的信息進行分類的索引的使用。如果沒有索引,執行搜索的時間將大大增加,很像在沒有卡片目錄的情況下試圖在圖書館中查找一本書。但是雖然大多搜索解決方案需要終端用戶重新索引信息到一個新的索引中,但是擴展搜索引擎,例如IBM Lotus擴展搜索,影響了(leverage)企業的當前數據管理投資。
應注意企業信息通常以許多外形和形式存在,并且貫穿整個企業分布,以及對于正在進行的任務通常由任務特定軟件進行管理。擴展搜索引擎,例如IBM Lotus擴展搜索,進入數據源和數據訪問模式的迷宮,并將現有的集合處理為一個具有單個入口(entry)點的虛擬索引。
不管入口的模式,擴展搜索引擎將查詢轉化為目標數據源的原始搜索語言,并使用對于每個數據源是原始的搜索和取回方法來返回結果。
但是需要認識到,不是相同地產生后端數據源,所述數據源可以具有完全不同的體系結構、方法、方案、元數據和能力(例如全文本索引vs.關系數據庫vs.e-mail系統)。任何可能的時候,擴展搜索工具和引擎試圖最小化所述不同,并獲得大于最小公分母的效果。
例如,在查詢多個數據源中,擴展搜索引擎,例如IBM Lotus擴展搜索,可能針對一個數據源合并兩個或多個操作,以達到在對一個不同源的單個操作中可獲得的效果。所述技術使用戶可以通過單個查詢并行搜索多個數據源,所述數據源具有不同類型、體系、結構、能力和格式。通過所述手段,可能維護原始數據庫或搜索引擎的機制,并保留信息的完整性和流通性,同時避免將分散數據復制成集中索引,以減少整體存儲需求并消除重新索引資源的花費和開銷。此外,數據保持與正在執行的工作的近距離(邏輯上和虛擬上),并且各個數據特定的和任務特定的數據源和搜索引擎可以并行執行搜索操作,由此改善搜索響應時間。
擴展搜索引擎范例也提供了比圍繞集中索引構建的多個數據源范例更大的可縮放性。隨著域內文檔數目的增加,索引信息所需的時間也增加了。對較大域的索引使得搜索不可實現的情況并不少見。
在這種情況下,擴展搜索引擎的能力補充了索引的深度首先,將索引穩定在最大容量上,然后結合其它數據儲備來搜索索引。通過這種技術,終端用戶可以僅對需要索引的內容進行索引,同時使用擴展搜索引擎來搜索索引的和非索引的源。
連接新的源到搜索域中使得擴展搜索引擎引起的開銷較小,并且當與實際搜索操作自身的花費進行比較時,這將是可忽略的。由于使用現有搜索操作在已經存在于網絡(互聯網或內部網)中的一個或多個機器上執行搜索,因此連接新的源的增加花費是可忽略的。
擴展搜索引擎通過使用企業現有數據管理軟件,實現了訪問企業的所有信息的策略,無論其處于什么位置。通過這個策略,造成了固有的事實,即,不是所有的后端數據源被生成為相同的數據源。存在通用區域,其中大多系統在搜索和取回方面有所不同。建立在這些共性上,擴展搜索引擎提供了通用平臺(ground),使系統實現者能夠在以下領域互補工作(1)搜索語言,即如何表達查詢;(2)數據模型支持,即如何組織、關聯和呈現數據;(3)應用程序接口(API)支持,即如何執行信息訪問。
至于搜索語言,幾乎所有數據管理系統都使用某種語法或查詢語言來表達搜索標準。根據數據的結構和成分,所述語法可能大大地不同。例如,在例如web的自由文本系統中,例如通常將搜索表達為關鍵字列表。使用額外的概念,以表達boolean條件(與,或,非)或位置信息,例如必須在相同句子或段落中出現的特定詞。通過比較和對比的方式,如果數據被高度地整理和結構化了,則語法可能是更加參數化的,并且可能支持字段化操作(例如,數量字段的值大于100)。
顯然,對于用戶而言,知道擴展搜索中使用的搜索語法的全部集合的句法是不現實的。讓用戶以單個通用搜索語言來表達查詢是更易實現的。在IBM Lotus擴展搜索中,通用語言是通用化查詢語言(GQL)。可以將該語言當成能夠表達大多查詢的搜索語法的擴展集。
以GQL格式內部表達所有IBM Lotus擴展搜索查詢(除了將要簡要討論的“傳遞”查詢)。當GQL表達式到達特定數據源時,擴展搜索將其轉變為所述源的原始查詢語言。所述轉變處理將GQL的詞匯元素映射到原始語法的等同元素上。
雖然IBM Lotus擴展搜索的所有部件支持全部的GQL語法,但是不是所有后端搜索引擎能夠支持GQL語法的所有元素。當擴展搜索引擎,例如IBM Lotus擴展搜索,遇到所述不一致時,所述搜索引擎通過合并兩個或多個原始操作來試圖補償,以到達相同的效果。只有在擴展搜索引擎已經用盡所有可選方法之后,才忽略表達式的不支持部分。在所述情況下,終端用戶可以替代地傳遞不能得到轉換的查詢。
通用數據模型正如搜索語法可以隨每個不同的后端系統而不同一樣,數據模型可以用來組織和存儲信息。典型地針對其所服務的應用等級來設計特定數據管理系統使用的數據模型。這確定了其信息中所得到的結構和粒度的程度。
例如,自由文本系統往往使用具有低數據粒度的松散結構化的文檔模型。文檔可能包括幾個字段(例如標題、作者和正文),但是文檔的文本保持形式自由,并且是非結構化的。通過比較,可以高度結構化信息,例如在關系數據庫中所得到的。這里,將數據組織為可以以任意種方式相關聯的行和列,這導致了很高的數據粒度。
現代擴展搜索引擎,例如IBM Lotus擴展搜索,將不同數據模型集合標準化為單個模型,所述單個模型易于理解并可由大多搜索應用所使用。搜索應用設計者僅需要與這一個數據概念模型進行競爭,而不會被許多模型所混淆。
通常將源映射到常規意義的數據庫上,但是可以將源輕易地映射到web站點上、文件系統目錄上、或LDAP體系中的節點上。同樣地,將文檔方便地映射到基于文本的但是可以輕易地表示數據示例的所述系統上,所述數據示例例如是關系數據庫的表中的一行。
在將不同類型的數據源相關聯時,通常遇到的問題是,字段標簽不匹配。例如,作者名在一個數據源中可能被標記為AUTH NAME,在另一個中標記為CREATOR,而在另一個中表示為3個字段(名、中間首字母、姓)。
通用數據模型的重要特征是定義映射字段的能力。映射字段是一個或多個原始字段的合成。為了解決前面例子中的模糊問題,終端用戶可以定義具有標簽AUTHOR的單個映射字段。終端用戶然后可以映射所述字段到支持作者姓名的語義的每個數據源中一個或多個原始字段上。
當在搜索表達式中使用所述特征時,所述特征的好處是令人信服的。用戶僅需要在查詢中指定映射字段。IBM Lotus擴展搜索將在后端自動將映射的字段與正確的原始字段相關聯起來。所述技術大大簡化了查詢表達式,并當數據源的數目增加時,提供了更多的好處。
為了說明所述特征,考慮將要顯示指示器(barometer)的應用的情況,測量所述指示器以反映文檔的使用年限(即,文檔越新,將具有越高的指示器讀數)。如果在每個后端源中不同地標記了“產生日期”的字段,則該應用將需要一個窮盡的條件語句集合,每一個針對每個離散的日期字段名稱。但是,通過映射字段,僅需要識別一個映射的“產生日期”字段,以便取回并對其進行后續測試。通過參考所述單個映射字段,結果將包含正確的日期值,因為其與源的原始日期值相關聯。
在另一方面,如果結果來自e-mail系統,終端用戶可能希望返回日期、主題和作者。可以通過使用原始源字段標識,選擇性地取回這些語義不同的數據字段。當原始字段標記對于顯示目的而言太過保密(例如$Doc_Abstract),則再次將映射的字段用作原始字段名稱的化名(例如,Document Abstract)。
擴展搜索引擎的另一個方面是通用API的提供。通用API回答了“我如何與所有這些不同的后端系統交互,以搜索并取回它們的管理信息?”的問題。通過調用方法、句法、語法和編程語言,每個后端系統的API可以大大不同。通過擴展搜索引擎通用接口發布的功能由系統自動轉換為后端系統的原始方法,非常類似于轉換GQL為原始搜索語法的過程。
擴展搜索引擎尋求以可能的最佳方式與后端上每個不同機制接口,以獲得所有數據源之間的最佳平衡,并同時考慮到每個原始搜索API的操作策略。通過使用主機軟件的公布的API,保持了數據源的完整性和安全性。
為了獲得所述可通信性,針對每類后端數據源產生鏈路模塊,并使用所述模塊來封裝所述類型所需的所有原始API調用。
使用基于代理的技術來將這些鏈路模塊應用到它們的各數據源中。代理代表協調搜索工作,并通常是透明的(將在后面更詳細地描述鏈路和代理)。從設計者的角度,終端用戶通過單個API與一個可搜索的后端系統接口。
在IBM Lotus擴展搜索的情況下,可獲得兩種形式的通用API。第一種并且是最靈活的一種是Java bean接口。通過所述方法,bean與Java編程語言的能力相結合,以開發寬廣范圍的從簡單到高復雜度并且專門化的搜索和取回應用程序。該產品展示了這些bean在使用JavaServer Page(JSP)的示例web應用程序中的使用。
或者,可以使用一組類似HTML的標簽,其允許終端用戶將擴展搜索引擎功能嵌入到新的或現有的web頁面中。這些便于使用的標簽可以授權web管理員并且使用戶可以輸入指定各種搜索選項的查詢。終端用戶可以在web頁面的任何地方嵌入擴展搜索引擎標簽,所述標簽不與周圍的HTML標簽相干擾。
可以以各種方式呈現來自擴展搜索應用程序的搜索結果。作為配置系統的一部分,可以編程并配置系統,以確定允許用戶查詢、在結果頁面上觀看以及從數據源種取回哪些字段。向用戶呈現包含來自多個源的結果的單個、合并的頁面。針對關聯性對所述列表進行預先剪裁(pre-pruned),因此保證了用戶首先看見最匹配的。
擴展搜索系統的特征在于可縮放性。具體地,例如IBM Lotus擴展搜索的擴展搜索系統的分布式部件體系結構,提供了根據變化的需求對系統進行縮放的靈活性。它也允許以與環境匹配的拓撲結構安排擴展搜索引擎部件,使得終端用戶可以根據需要來混合IBM AIX、SunSolaris、Windows 2000和Windows NT平臺。
示例性可縮放擴展搜索體系結構包括縱向上,在單個擴展搜索服務器中,終端用戶可以配置多個服務器處理實例,以影響服務器可以處理的同時請求的數量。
橫向上,通過多個機器,終端用戶可以建立額外的擴展搜索服務器以及額外的web服務器。對于每個擴展的搜索服務器,終端用戶可以確定終端用戶希望運行的服務器任務類型。通過擁有多個服務器,終端用戶可以分布和均衡處理負載。
擴展搜索體系結構20世紀末期所經歷的巨大經濟增長歸功于信息技術所獲得的進步以及投資信息技術的那些公司。由于技術原來(并且現在仍然)以驚人的速度在改變,公司頻繁地投資并再投資他們的信息技術(“IT”)預算到不斷進化的產品中,以管理他們的信息。這樣做的結果經常是,貫穿整個組織分布的信息島--針對正在進行的任務是高度專門化的,但是不易基于企業范圍對所述信息進行訪問。即使一個公司能夠決定企業的通用IT策略,但是使用不同IT體系結構的公司的單次收購將會阻礙所述策略。
這里構想的由IBM Lotus擴展搜索例示的擴展搜索引擎,具有多層設計。例如,IBM Lotus擴展搜索系統使用4層體系結構。消息開始于第一層中的搜索應用程序,并通過后續的層連續進行到后端。在大多情況下,后端是IBM Lotus擴展搜索所連接到的第三方數據源,但是后端也可以是擴展搜索配置數據庫(CDB)、由關系數據庫管理系統所管理的私有后端,例如IBM DB2 RDBMS。
層間的消息流可以分割為兩個基本類別運行時間消息,這是通常由用戶團體所發布的消息,以執行搜索并取回文檔。
管理消息,這是由管理員發布的,并導致配置數據庫的更新。
鏈路是將針對搜索和取回的原始API調用封裝到特定數據管理系統的軟件模塊。它們包括與后端數據系統接口所需的所有數據結構、編程對象和程序邏輯。
單獨地組裝一個鏈路模塊以支持(最小化)通常存在于所有數據管理系統中的可調用方法連接到主機系統并從主機系統斷開連接的方法從系統中搜索內容并取回數據的方法對于后端源不支持的方法,鏈路模塊執行空操作。例如,文件系統搜索不支持連接和斷開連接的概念。
轉換器(translator)是負責將進入的GQL表達式轉換為后端數據系統的原始搜索語法的軟件模塊。它們也包括產生句法正確的搜索表達式所需的所有數據結構、編程對象和分析邏輯。
在一些情況下,同一轉換器模塊應用于幾個不同后端系統,和SQL轉換器和許多各種支持標準SQL語法的系統的情況一樣。
代理是響應旨在特定數據源的搜索和取回操作的程序。當第一次提出針對特定數據源類型的請求時,代理加載合適的鏈路和轉換器模塊。代理然后調用用于進行轉換(XLAT)、連接、斷開連接、搜索和取回操作的這些模塊庫。
對于搜索操作,代理將按照相關度等級來對結果集合進行分類(sort),然后將集合截取(truncate)為最大數量的命中(hit),如原始搜索請求中所指定的。所述命中列表的分類和隨后的截取是聚集的重要前期操作(precursor),將對其進行簡要討論。
代理可以位于與數據源相同的機器上(推薦),或使用數據源的遠端API進行訪問。可以在單個計算機上運行代理的不止一個拷貝,以處理同時的搜索和取回請求。一個代理可以用于單個數據源、特定類型的一組源或具有混合鏈路需求的某一范圍的源上。
協調器是存在于服務請求者和通過后端實際執行服務的代理之間的中間部件。協調器作為特殊用途資源協調者進行工作,被設計用來管理從單個請求產生的,例如由類別搜索(category search)引起的多個搜索。
協調器典型地執行下面任務驗證請求。
擴展類別以獲得應用程序可用的數據源列表,并解析源地址。(標記1)將查詢分發給代理,以進行高效、并行的搜索。(標記2)將由各個代理返回的搜索結果聚集并任意分類為單個搜索結果集合。(標記3)高速緩存搜索結果,以進行后續分頁(paging)的操作。(標記4)向代理發布請求,以便為用戶取回源文檔(注意到在大多情況下,web瀏覽器使用在結果列表中返回的URL,以取回文檔)。
示意超時(timeout)和響應選項。
在引起單個請求的后端系統的大的集合中,響應程度可能大大不同。一些數據管理系統比其它系統響應的快,而一些則不,-可能由于服務條件之外的原因。為了解決這種情況,協調器被設計為與它們的代理異步通信。
為了支持性能和可縮放性,擴展搜索系統可能包括多個協調器。這種建立協調器體系的能力,連同建立與所支持的源共同存在的代理的能力,或指定代理到特定源或源的類型的能力,為擴展搜索系統,例如IBM Lotus擴展搜索,提供了關于改變和擴展環境的無窮靈活性。在多個協調器的方案下,源被所有協調器分區,這是一種防止任何一個協調器被淹沒(overwhelm)的設計。
在單個協調器環境中,針對6打源的搜索將導致72個查詢被發送給遠端機器,以及72個搜索結果集合返回給協調器。如果每個結果集合包括最大數量的結果,則當協調器合并和聚集返回給請求者的列表的數據時(協調器截取結果,并僅保持頂部項目,直到搜索應用所允許的最大數量),將丟棄大多數據。
通過多個協調器,入口(entry)協調器發送單個消息給遠端機器的協調器。遠端協調器然后將該消息分離為針對它們各自機器上的源(由代理所指向)的多個請求。不是將所有結果集合返回給一個協調器,而是每個協調器合并、聚集并剪裁由其代理返回的結果,并然后僅將單個列表-包含頂部命中-返回給入口協調器。入口協調器僅需要從其自己的本地源中產生最終結果集合,以及由遠端協調器返回的合并的列表。
協調器從擴展搜索應用的配置數據庫中獲得關于其管理的資源的信息。所述數據庫包括關于數據源以及應該如何搜索數據源的信息。所述數據庫也存儲網絡地址、保存的查詢、保存的搜索結果以及webcrawler下載的數據。
終端用戶通過使用直觀(intuitive)管理接口,可以輕易地更新關于網絡拓撲、數據源和搜索應用的信息。所述接口也提供網關,終端用戶通過所述網關可以運行發現(下面討論)、觀看錯誤消息和事件數據、調度查詢,和利用保存的查詢和搜索結果工作。
雖然已經關于一定的優選實施例和示例描述了本發明,但是這不是旨在由此限制本發明的范圍,本發明的范圍僅由后附的權利要求限定。
權利要求
1.一種搜索非結構化數據的方法,包括a.搜索非結構化的數據;b.返回具有屬性的搜索結果以便進行聚集;c.聚集搜索結果;d.將聚集的搜索結果返回給包裝器;以及e.在別名表中輸入搜索結果屬性,通過結構化數據搜索引擎可以搜索所述別名表。
2.根據權利要求1中的方法,包括利用非結構化數據搜索系統搜索非結構化數據,所述非結構化數據搜索系統包括擴展搜索協調器和搜索代理,所述方法包括利用搜索代理搜索非結構化數據,利用擴展搜索協調器聚集由此獲得的搜索結果。
3.根據權利要求2中的方法,包括將搜索結果從搜索代理返回給擴展搜索協調器以進行聚集,以及將聚集的搜索結果和搜索結果屬性傳送給包裝器。
4.根據權利要求3中的方法,包括使搜索結果屬性成為別名表中的至少一列。
5.根據權利要求1中的方法,其中別名表是關系數據庫別名表。
6.根據權利要求5中的方法,其中別名表是關系數據庫管理系統表,結構化數據搜索引擎是關系數據庫管理系統,并且別名表可由關系數據庫管理系統使用結構化查詢語言進行搜索。
7.根據權利要求6中的方法,其中結構化查詢語言是SQL。
8.一種搜索非結構化數據的方法,包括a.通過結構化數據搜索引擎、非結構化數據搜索代理和兩者之間的擴展搜索協調器來搜索非結構化數據;b.將具有搜索結果屬性的搜索結果從搜索代理返回給擴展搜索協調器以進行聚集;以及c.在別名表中輸入搜索結果屬性,所述別名表可由關系數據庫管理系統使用結構化查詢語言進行搜索。
9.根據權利要求8中的方法,其中所述擴展搜索協調器輸入搜索結果屬性到別名表中。
10.根據權利要求9中的方法,包括輸入搜索結果屬性作為別名表中的一列。
11.根據權利要求9中的方法,其中結構化數據搜索引擎在別名表中查詢搜索結果屬性。
12.根據權利要求9中的方法,其中結構化查詢語言是SQL。
13.一種計算機系統,包括非結構化數據搜索代理、結構化數據搜索引擎和別名表,其中a.所述計算機系統適用于從結構化數據搜索引擎、通過非結構化數據搜索代理,來啟動非結構化數據的搜索;b.所述非結構化數據搜索代理適用于從非結構化數據中接收具有搜索結果屬性的搜索結果,并聚集搜索結果;c.所述計算機系統適用于在別名表中輸入搜索結果屬性;以及d.所述結構化數據搜索引擎適用于在別名表中搜索屬性。
14.根據權利要求13中的計算機系統,其中結構化數據搜索引擎是關系數據庫管理系統搜索引擎。
15.根據權利要求14中的計算機系統,其中關系數據庫管理系統搜索引擎是聯合搜索引擎。
16.根據權利要求15中的計算機系統,其中非結構化數據搜索代理包括擴展搜索協調器。
17.根據權利要求13中的計算機系統,其中將搜索結果屬性輸入到別名表中作為別名表中的列。
18.一種包括非結構化數據搜索系統、結構化數據搜索引擎和別名表的計算機系統,其中a.所述計算機系統適用于從結構化數據搜索引擎、通過非結構化數據搜索系統,來啟動非結構化數據的搜索;b.所述非結構化數據搜索系統包括擴展搜索協調器和非結構化數據搜索代理;所述非結構化數據搜索系統適用于從搜索代理中接收具有搜索結果屬性的搜索結果,并將具有搜索結果屬性的搜索結果返回給擴展搜索協調器以進行聚集,并適用于聚集搜索結果和搜索結果屬性;c.所述計算機系統適用于在別名表中輸入搜索結果屬性;以及d.所述結構化數據搜索引擎適用于在別名表中搜索搜索結果屬性。
19.根據權利要求18中的計算機系統,其中結構化數據搜索引擎是關系數據庫管理系統搜索引擎。
20.根據權利要求19中的計算機系統,其中關系數據庫管理系統搜索引擎是聯合搜索引擎。
21.根據權利要求18中的計算機系統,其中非結構化數據搜索系統包括擴展搜索協調器。
22.根據權利要求18中的計算機系統,其中將搜索結果屬性輸入到別名表中作為其中的一列。
23.一種計算程序產品,包括計算機可讀代碼以編程并配置計算機系統進行下述操作a.通過用于非結構化數據搜索的擴展搜索協調器和搜索代理來搜索非結構化數據;b.將搜索結果和搜索結果屬性從搜索代理返回給擴展搜索協調器以進行聚集;c.聚集搜索結果和搜索結果屬性;以及d.在別名表中輸入搜索結果屬性,所述別名表可由關系數據庫管理系統使用結構化查詢語言進行搜索,由此搜索非結構化數據。
24.根據權利要求23中的計算機程序產品,其中別名表中的搜索結果是結構化數據。
25.根據權利要求24中的程序產品,其中搜索結果屬性是別名表中的列。
26.根據權利要求23中的計算機程序產品,其中結構化查詢語言是SQL。
全文摘要
用于搜索非結構化數據的方法、系統和程序產品。通過由擴展搜索協調器首先搜索非結構化數據,來搜索作為文本數據或圖像數據的非結構化數據。擴展搜索協調器具有非結構化數據搜索的搜索請求者和搜索代理之間的中間部件。搜索代理返回搜索結果給協調器以進行聚集。協調器聚集搜索結果并將搜索結果返回給包裝器。包裝器然后從聚集的搜索結果中提取結果屬性,并使所述屬性作為例如別名表中的一個或多個列。關系數據庫使用結構化查詢語言(SQL)可以搜索所述別名表。
文檔編號G06F17/30GK1761962SQ200480007597
公開日2006年4月19日 申請日期2004年2月13日 優先權日2003年3月21日
發明者阿瑟·喬依, 托德·萊巴, 比特·伯斯特, 阿密特·R·索瑪尼 申請人:國際商業機器公司