李春生,王荊龍,程兆全
(東北石油大學計算機學院,黑龍江大慶163318)
企業生產決策與設計很大程度上依賴于作業狀態的分析,以及基于專業知識的判斷。大量的生產數據存儲于數據庫中,工作人員通過傳統的查詢分析生產狀態,并且做出生產決策與規劃[1]。
然而關系數據庫的數據組織結構不能表示概念、事實和規則之間的關系,因此無法支持智能分析及信息推理。并且相同領域的不同部門對于同一概念可能用不同表述方式,從而造成信息的非一致性和信息的冗余。因此,論文研究支持信息推理的關系數據庫語義解析機制,設計工程決策知識服務支撐環境,通過對關系數據存在的動態作業信息提取和描述并結合專業知識,以輔助企業的生產方案設計與規劃[2-3]。
生產決策及方案的制定是一個結合動態作業狀態分析的過程。工程決策知識服務支撐環境(如圖1所示)集成并且管理決策知識,以知識驅動的方式,實現各類輔助決策方案。工程規劃與設計往往需要考察生產數據,根據實際狀態選擇不同的決策方法。生產數據在數據庫系統中以關系的形式存儲,本身并不具備支持知識推理的能力[4]。需要結合數據分析,提取生產論據并且結合實際業務知識獲得符合應用的結果。如何從生產數據中得出領域知識所需要的論據是工程決策知識服務所研究的重要問題。

圖1 工程決策知識服務支撐環境Fig.1 The supporting environment of engineering decision knowledge service
數據庫按照關系的模型組織、描述、存儲數據。關系數據模式不能夠直接提供語義信息,在關系數據庫中,一個關系包含若干元組,每個元組都表示現實世界中的某個實體[5]。關系實體或者其組合對應的邏輯對象需要用語義進行描述才具有參加知識推理的能力。主詞關系網提供了領域概念在企業不同部門之間開放統一的、共享的公共認識框架。引入具有語義關系的主詞網捕獲工程領域的業務知識,確定該領域內共同認可的概念,并分層次的給出這些概念的明確定義以及之間相互關系。利用領域知識,將不同層次概念之間存在的父子關系形成樹集,并且給出各節點的具體含義的描述。
定義 領域主詞關系網規范了開發設計的基本概念及概念所屬類,形式化為一個二元組:
FieldSubject={EntitySet,ClassSet}
EntitySet:工程領域主詞表示的實體集合,主詞為具有相同語義的生產對象的集合。對于領域每項實體Entity∈EntitySet。對于實體Entity可形式化描述為:
實體=<實體名稱,描述集合>
ClassSet:實體間的父-子類關系樹集,對于每個實體所屬類Class∈ClassSet,Class可形式化描述為:
關系類=<類名稱,父類實體,子類實體>
對于非完全意義上父子關系要相應的處理,例如實體-屬性關系可看做實體為父節點,相應屬性則為子節點。對應兄弟關系則處理為多顆子樹,如果該關系中不同實體存在關系,則各個子樹可存在上層節點相交,或存在下層節點的相交。
工程生產決策以領域知識為基礎,通過動態作業信息的解讀與分析,做出各項施工方案及規劃。知識結構框架需要對知識作必要的劃分,并且避免不必要的重復,知識元素設計能夠支持對應于關系實體的推理活動。因此,采用元詞匯-事實分析-決策規則的層次劃分。
1.2.1 元詞匯層
主詞關系網表達應用領域可共享的概念及相互關系,元詞匯層在關系映射架構的基礎上實現數據庫實體語義化說明。元詞匯表示并且存儲了關系實體的概念映射信息,賦予數據庫模式規范的、可共享的語義。
定義 元詞匯映射領域主詞(邏輯對象)與關系實體存儲的對應關系,形式化的表達為三元組:
UnitVocabulary={UID,EntityName,MappingSet}
UID:領域元詞匯ID,為元詞匯在知識系統的唯一標志。
EntityName:元詞匯所描述的實體名稱。
MappingSet:映射關系集合,表示為映射元組的運算表達式,元組映射表達了關系模式的存儲信息。以下給出映射關系的結構:
映射元組=<映射ID,映射名稱,關系表名,關系字段名,字段類別>
由于元詞匯可能對應多個映射元組運算,例如對于實際工作中日產液量是由日產水量與日產油量的和算出的,但是油、水則存在不同的關系數據表中,所以對于日產液實體則需要利用兩個映射的運算來表示。因此采用映射元組的運算表達式描述邏輯對象對應的關系模式如下:
<MappingSet>::=< 映射元組 >|[< 運算 >]< 映射元組>{<運算><映射元組>}
<運算>::=+|-|*|/|%|^|連接,當MappingSet為一元映射關系時,無運算操作。
1.2.2 事實分析層
事實分析層定義了領域內生產決策以及措施中所依賴的事實和證據。事實為生產工程中表示狀態中基礎單位,在此成為單元事實。在此層次中對元詞匯實體做量化處理。
定義 單元事實指生產數據實體可提供決策的狀態信息,形式化表達為五元組:
UnitFact={FactID,FactName,FactSubject,State-Relation,State}
FactID:事實ID,為事實在知識系統的唯一標志。
FactName:事實名稱,對事實加以描述。
FactSubject:事實所描述的主體標識(元詞匯U-nitVocabulary)。
State-Relation:狀態關系(包括>、≥、=、<、≤、contains、between-and)。
State:狀態信息(值、范圍、NULL)。
在決策分析中,即要參考生產數據實體所表達的意義同時需要實際狀態和內容,因此論文引入詞匯語義-事實分析方法對基礎數據實體描述并表示當前的狀態。實現在工程事實與關系模式交互解析的基礎上,分析決策事實當前狀態,并以SQL操作對所需數據提取和應用。
1.2.3 決策規則層
決策規則定義了生產設計決策工作的基本問題解決方案。生產活動描述了動態設計方案,在該層次中,利用詞匯語義-事實分析層給定的模型建立合理的規范化說明生成完整的數據描述,并通過主詞關系網加以解析。
定義 決策規則由核心數據對象和多單元事實組成,描述了一類生產活動中基本的解決方案。形式化的表達為四元組:
DecisionRule={RuleID,CoreData,FactSet,RuleClass}
RuleID:決策規則ID,為決策規則在知識系統的唯一標志。
CoreData:核心數據,表示該規則所關心的重點數據實體描述,利用主詞關系網加以解析,得出數據實體的所有子樹節點,得到一個完整的數據實體。
FactSet:單元事實集合,設fact為單元事實,單元事實集合即為n維交集,形式表達為:
FactSet={<fact1∩fact2∩ …∩factn>∣fact1∈Facts,fact2∈Facts,…,factn∈Facts}當 n=1 時 FactSet表示為有唯一事實。
RuleClass:決策規則所表達的生產門類,不同生產過程的門類有所區別,例如包括堵水措施規則,壓裂措施規則,注水措施規則等。
生成決策規則后,即可完整的表達對所需數據的描述(如圖2所示),之后將規則進行解析并結合SQL利用實體映射關系對對數據提取。

圖2 知識整體結構表示Fig.2 The presentation of whole structure of knowledge
實際生產中,不同人員對數據的描述存在差異,上文利用主詞關系網建立了統一共享的認識框架,并利用知識體系形成了完整的數據描述。實體映射關系架構主要對該數據描述分析,解釋出各數據單項字段。建立關系數據庫中的關聯關系,將單項字段對應匹配形式數據鏈路,最后利用SQL提取。
1.3.1 規則解析項目
對于存在的規則創建推理機將規則解析成各個可利用的數據項,數據項大體可分為兩類。一類為觀察數據項,用以表達所關心的數據;另一類為條件數據項,表示提取數據所滿足的條件信息。具體表達形式如下:
觀察數據項=<數據名稱,數據類型,映射表名稱,映射字段>
條件數據項=<數據名稱,數據類型,映射表名稱,條件表達式,值>
在決策規則層中,CoreData為主要的觀察數據實體,在CoreData中是以樹形結構存放了對應核心數據,根節點表示對該數據實體的總體描述,葉子節點表示真實的數據項目信息。所以將CoreData解析,形成觀察數據項集中的重要部分。
事實分析層中,UnitFact為工程事實,多為數據狀態和條件的約束。同樣,數據的狀態和約束條件同時被人們所關心,在此解析為雙數據項,一部分作為觀察數據項提供更多的決策支持;一部分作為條件數據項描述所提取數據的狀態及約束。
1.3.2 關系數據關聯關系與解析過程
在關系數據庫中,ER圖 (Entity-Relation Diagram)提供了表示實體(即數據對象)、屬性和聯系的方法,用來描述現實世界的概念模型。由于ER圖描述是建立在數據庫模型中的概念設計階段,是一個獨立于機器,獨立于DBMS的圖形模型,所以利用單純的ER圖建立表關系的自動識別時連接方向不強,事實邏輯不能充分提現。
所以基于實體關系圖,建立一種可支持邏輯關系較好識別的結構,圖3為邏輯結構簡圖。

圖3 數據關聯邏輯結構簡圖Fig.3 Sketch of data association logical structure
對于關系數據實體,對應給出規范化描述,其中包括實體名稱、標識類別、主鍵、外鍵和屬性集等,并根據原有實體關系形成關系圖。實體名稱、主鍵、外鍵用來說明描述關系數據的總體特征。屬性集合為關系數據實體中包含的所有數據項目。標識類別為邏輯關系的識別基礎,具體表達方式為:
<Sign-Class-大類名稱:SC-關聯類集>
大類用以說明同一類事物,例如“井”類可表示為CS-A。關聯類存在與主類的主外鍵關系,其中包括父子關系、派生關系、從屬關系、并列關系等。例如“水井月報”表示為CS-A:SC-2。同時,“水井方案”,“水井措施”則與“水井月報”關聯,分別表示為CS-A:SC-2:SC2-1和CS-A:SC-2:SC2-2,以此類推。
屬性集合為關系數據實體中包含的所有數據項目。將規則解析中形成的需要分析的數據項映射到屬性集合中形成解析項目集合,并對每項數據找到對應的所屬實體標識,最終形成了帶有實體描述和類別標識的集合。針對集合按照類別區分,逐層劃歸。例如上圖中,若存在解析數據項目集合為:
{<井筒>:井筒型號(標識SC-A:SC-3:SC3-1)、
<水井月報>:月注水(標識SC-A:SC-2)、
<水井方案>:增注(標識SC-A:SC-2:SC2-1)、
< 水井措施 >:補孔(標識 SC-A:SC-2:SC2-2)}
大類名稱為SC-A確定為同類數據,進入下一層次將集合分為{SC-A:SC-3:SC3-1}和{SC-A:SC-2、SC-A:SC-2:SC2-1、SC-A:SC-2:SC2-2}。當集合中包含一個元素時則停止劃歸,針對集合二按層次依次可分為 {SC-A:SC-2、{{SC-A:SC-2:SC2-1}、{SC-A:SC-2:SC2-2}}}。由于集合都屬于同一SC-A類,可根據數據邏輯關系圖,找到最近的根,將多個游離的節點相連,最終可用樹形結構表示為圖4:

圖4 樹形結構簡圖Fig.4 Sketch of tree structure
針對形成的樹做由上至下的層次遍歷,從而找到所有數據項目的對應表連接關系。
根據數據項目及表關聯關系的解析,利用SQL將所描述的數據提取并利用。
研究油田開發方案設計知識結構,基于工程決策知識服務支撐環境,建立各類輔助決策應用系統。從業務劃分,油田開發涉及測井、鉆井、錄井、井下作業、采油工程等二十多個專業,初始概念達20000多個。油田開發需要分析生產狀態并且設計開發規劃及制定措施方案。開發設計具有經驗指導特征,通過總結經驗豐富的工作人員的開發知識,建立工程決策知識服務支撐環境,驅動各個輔助設計應用系統的工作。
在領域主詞關系網概念基礎上,設計油田開發元詞匯與數據的映射,生產數據模式來源于目前油田專業數據庫A2系統。元詞匯定義了主要的3000個關系模式,在概念層次描述了關系數據與邏輯概念的解析關系。
開發動態管理事實在元詞匯定義的基礎上,描述了油田開發生產的各種狀態和效果,分解為生產對象與狀態或者行為變化的集合。
設計了相應的推理機制,知識維護平臺提供了定義接口,用戶可以在現有設計的基礎上進行擴展。
設計規則包括措施優選、問題井檢測、生產狀態預警三個主要類別。決策活動的定義主要包括壓裂、補孔、堵水、分層注水調整等措施設計活動。
基于知識服務驅動實現了生產預警、分區塊措施選擇建議,輔助生成施工方案等決策支持應用系統。所開發系統已經正常工作,并且取得了應用部門的較好評價。
論文研究了關系數據庫語義解析和推理,賦予關系數據庫語義,使其對智能分析及信息推理提供支持。基于工程決策知識服務支撐環境,建立三層的知識結構,重點支持關系數據與生產事實的交互解析。針對不同應用,需要進一步加入特征元素。領域內建立統一的平臺框架,在此基礎上構建決策應用系統不但可以節約軟件資源,更加充分的利用領域知識,而且縮短了系統開發周期,帶來相當的社會與經濟效益。
[1]WANG NENGBIN. Database System Tutorial[M].Beijing:Publishing House ofElectronics Industry,2004.
[2]張德海,沙月林.基于本體與工作流的知識服務系統[J].計算機工程,2009,35(19):75~77,80.
[3]MENG XIAO-FENG,ZHOU LONG-XIANG,WANG SHAN.State of the art and trends in database research[J].Journal of Software,2004,15(12):1822~I836.
[4]杜小勇,李曼,王珊.本體學習研究綜述[J].軟件學報,2006,17(9):l837~1847.
[5]王珊,薩師煊.數據庫系統概論[M].北京:高等教育出版社,2005.