以用戶為中心的異構數據集成方法

高 明，陳正鳴，呂 嘉

（河海大學物聯網工程學院，常州213022）

以用戶為中心的異構數據集成方法

高 明，陳正鳴，呂 嘉

（河海大學物聯網工程學院，常州213022）

為了實現用戶數據在不同用戶應用程序間的共享，將同一用戶分布在不同應用程序上的數據按照統一的數據模型組織，并存放在統一的平臺上，用異構數據集成技術處理用戶數據模型和統一數據模型間的異構問題，使得不同應用平臺之間能實現數據共享。

以用戶為中心；異構數據集成；擴展機制

1 引 言

現今，用戶使用的應用程序類型呈現多樣化。按應用程序功能可以分為微博類、郵件類、即時通信類等等，用戶使用同一類型的應用程序也有很多種，微博應用程序中有新浪微博、騰訊微博、網易微博等等。各個應用程序的數據之間彼此隔離，互不共享，分散的應用程序各自存儲和管理用戶數據的方式給用戶帶來了不便。另外數據分散還會出現垃圾數據，與用戶相關的新業務難以快速有效的開展，用戶數據管理問題日益明顯。

各個應用程序的數據存在著存儲方式、數據格式、訪問控制、用戶視圖、數據模型方面的不同，導致用戶的信息像一個個信息孤島，很難達到互聯互通，實現數據間的共享，解決用戶信息間的異構問題是實現用戶信息集成的關鍵。

這里提出的服務平臺（即中央平臺）發布統一的數據模型給各個用戶應用程序，通過異構數據集成技術解決數據模型之間的異構問題，使得用戶應用程序中使用的各類數據能統一成中央平臺規定的數據格式，用戶的所有數據統一保存在中央平臺，中央平臺為各用戶應用程序數據之間的共享提供服務。

2 基本思路

中央平臺的數據模型從用戶角度出發設計，將各個用戶應用程序中涉及的所有數據進行分析，再將分析后的數據及其聯系進行邏輯組織，生成中央數據模型。中央平臺制定異構規則，并發布中央數據模型給各個用戶應用程序。用戶應用程序在中央平臺上進行注冊，將中央數據模型對應部分作為用戶應用程序數據模型的基本框架，通過中央平臺給出的異構規則設計出用戶應用程序的數據模型，即用戶數據模型。

中央數據模型與用戶數據模型之間存在著差異。用戶在用戶應用程序中上傳的數據通過JSON格式的數據接口上傳到中央平臺后，經過異構規則對應的異構函數處理，以中央數據模型的格式保存到中央平臺上。用戶應用程序可以通過異構逆函數，將中央平臺的數據轉換成用戶應用程序能處理的格式。系統基本思路如圖1所示。

圖1 基本思路示意圖

3 以用戶為中心的數據模型

中央平臺設計式的中央數據模型，從用戶角度出發，設計出的中央數據模型要能滿足用戶需求，能實現用戶數據的統一化管理，體現以用戶為中心的理念，實現用戶數據在不同應用程序上的重用。

3.1 中央數據模型的設計思路

現在多數用戶數據模型為關系數據模型，由于用戶應用程序和中央平臺之間需要進行模型比較和匹配，中央數據模型使用關系數據模型。同時，關系數據模型的結構簡單、清晰，具有更高的獨立性，也能簡化中央數據模型的建立和維護。

設計中央數據模型前首先要了解現有用戶使用的應用程序，本研究以微博類、郵箱類和即時通訊類應用程序為重點，將這些社區類應用程序的數據模型中涉及到的實體和屬性進行分析，依據這些實體和屬性與用戶的密切程度和重用價值進行篩選，再將選出的實體和屬性從用戶角度出發，統一進行分類，最后設計出中央數據模型。

3.2 中央數據模型實體分類

將用戶數據模型中的信息進行分類，并將相關信息抽象成中央數據模型的實體。一些用戶數據模型中的信息在不同類應用程序里，但從用戶角度分析，有著類似的作用，同樣可以抽象成中央數據模型中的實體。通信錄包括用戶在各應用程序平臺中所包括的通信聯系人，微博和社交類應用中可私信的對象，QQ、MSN等即時通信工具里的通信對象，郵箱中的通信錄信息，從而使得通訊錄中擁有所有建立了通信關系的對象信息。

用戶同一類型的不同應用程序可能有很多種，而同一類型應用程序的實體相似度很大，可以將各個用戶應用程序中描述同一實體的部分進行集成。例如，新浪微博、騰訊微博和網易微博里都有微博這一實體，這些可以統一成用戶的微博這一實體。

多個實體合并為統一的實體，合并后實體中的屬性可能會出現冗余重復，應首先消去多余的屬性。有些屬性之中存在單屬性對應多屬性、名稱不同但指代事物相同等等的異構現象，應仔細分析后刪除冗余的屬性，再和其它屬性統一整合到對應的實體。多數用戶應用程序涉及的實體或者屬性應保留到中央數據模型，少數用戶應用程序涉及的實體或者屬性依據其重用價值選擇是否保留到中央數據模型。

中央數據模型的實體分為用戶基本信息、用戶社交信息、用戶上傳資料、用戶博文、用戶通信信息五大類，每個分類包含相關的實體，如圖2所示。

圖2 中央數據模型中實體的分類

3.3 中央數據模型的核心部分與非核心部分

按中央數據模型中內容的必要性分為核心部分和非核心部分。中央數據模型的核心部分是定義用戶數據模型時不可缺少的部分，所有用戶數據模型必須定義這部分，缺少核心部分會導致用戶數據在一些情況下無法實現重用。非核心部分豐富了中央數據模型的業務功能，用戶數據模型可以選擇是否包含中央平臺的非核心部分。在中央平臺的建模過程中，分析各個實體和屬性的必要性，并標注上“核心部分”或者“非核心部分”。

圖3為中央數據模型中用戶個人資料部分的簡圖。個人資料中的ID是中央平臺唯一標示用戶的信息，用戶的賬號信息和密碼是用戶登錄各個平臺的憑證，姓名，性別，生日，職業信息中的單位名稱，教育經歷中的學校名稱和類型都是關于用戶的重要信息。血型，家庭地址，標簽信息對于多數用戶應用程序而言，不是必要信息，這些信息是中央數據模型的非核心部分，圖3中核心部分用灰色背景標注，非核心部分用白色背景標注。

圖3 中央數據模型中用戶的個人資料部分簡圖

3.4 數據模型的擴展機制

為了豐富中央數據模型和用戶數據模型的內容，增強中央數據模型和用戶數據模型的適應性和擴展性，系統提出了數據模型的擴展機制。中央數據模型能擴展自身模型，以適應用戶應用程序變化的需求，用戶數據模型也能通過擴展機制增加中央數據模型沒有的屬性和實體。

3.4.1 中央數據模型的擴展

中央數據模型可以進行擴展。各個應用程序不斷更新，出現新的業務功能，中央數據模型必須要擴展大多數用戶數據模型中擴展的實體或者屬性，以適應用戶應用程序的變化。中央平臺及時發布更新后的數據模型給所有用戶應用程序，同時說明最新擴展的內容。

3.4.2 用戶數據模型的擴展

用戶數據模型也可以在自身數據模型基礎上進行擴展，擴展屬性到對應的實體中，也可以擴展中央數據模型中沒有的實體，但要保證實體之間的聯系，并在中央平臺上保存擴展后的用戶數據模型。例如，中央數據模型用戶的微博實體中沒有“標記”這一屬性，某個用戶應用程序希望用戶數據模型中出現“標記”這一屬性，用戶數據模型可以通過擴展機制實現。

4 數據異構規則

用戶應用程序利用用戶數據模型的擴展機制，擴展中央數據模型中沒有的屬性或者實體，而對于模型之間對應屬性間存在異構的現象，則要通過異構處理技術來統一數據格式。這里提出的用戶異構數據集成方法是基于異構規則的，用戶應用程序通過使用中央平臺制定的異構規則來建立用戶數據模型。

不同數據模型之間存在著各種語義沖突，中央平臺針對用戶數據特點進行分析，歸納用戶異構數據的沖突類型，制定異構規則。異構規則的主要任務是分類中央數據模型和用戶數據模型中語義相關屬性存在的異構情況。

在實際的匹配過程中按照發生異構情況中的屬性數量分為多屬性沖突和單屬性沖突，單屬性沖突針對單一屬性中類型、格式、精度方面的差異，而多屬性沖突針對屬性的組合方式不同。對應規則如下（其中A，B表示屬性值，E表示實體，D1表示用戶數據模型，D2表示中央數據模型，＃表示實體主鍵）。

4.1 單屬性異構

單屬性異構主要有格式沖突和分配沖突：

（1）格式沖突：指中央數據模型和用戶數據模型描述同一個屬性的描述方式不同。

如：D1：User（id＃，name，birthday（YYYY-MM）……）；

D2：User（id＃，name，birthday（YYYY-MM-DD）……）；

用戶數據模型中的日期類型有很多種，YYYYMM，YYYY／MM，YYYY／MM／DD，YY-MM-DD，YYMM。

假設：｛A1，A2，A3……An……Am｝＝E1∈D1，｛A1，A2，A3……An-1，Bn……Am｝＝E2∈D2，An和Bn存在格式沖突。

規則：中央平臺枚舉出所有可選的格式，用戶選擇對應的格式。

（2）分配沖突：指中央數據模型和用戶數據模型為同一屬性的相同數據類型但分配空間大小不同。

如：D1：Fans（id＃，name，amount（varchar（8））……）；

D2：Fans（id＃，name，amount（varchar（16））……）；

假設：｛A1，A2，A3……An……Am｝＝E1∈D1，｛A1，A2，A3……An-1，Bn……Am｝＝E2∈D2，An和Bn數據類型一致，且存在分配沖突。用戶應用程序中An的數據可以直接賦值給中央平臺的Bn，Bn映射到An則需要根據An的數據類型不同，使用對應的異構規則，分配沖突中各種情況下的規則如表1所示。

4.2 多屬性異構

多屬性異構主要為組合沖突，復雜組合沖突。

（1）組合沖突：指同一語義的屬性在中央數據模型和用戶數據模型中用不同的屬性組合方式表示，組合方式規律可循。

如：D1：Message（id＃，sendtime，content，sendplace，userid）；

D2：Message（id＃，sendtime，content，province，city，userid）（D2中sendplace中數據對應D1中provice中的數據和city中的數據組合）

假設：｛A1，A2，A3……An-1，An，An＋1……Ak-1，Ak，Ak＋1……Am｝＝E1∈D1，｛A1，A2，A3……An-1，Bn，Ak＋1……Bm｝＝E2∈D2；且E1中屬性An……Ak與E2中的Bn表示同樣語義。

規則：An，An＋1……Ak→Bn＝An［＾＼n＼r＼t＼v］An＋1……Ak-1［＾＼n＼r＼t＼v］Ak

表1 分配沖突Bn映射到An各種情況下的規則

（2）復雜組合沖突：指同一語義的屬性存在組合沖突，且組合方式無規律可循。

如：屬性name對應屬性given-name和family-name的組合，但name的拆分方式沒有規律，中文名字中的姓存在單復姓現象。

復雜組合沖突的規則：根據每個屬性出現的概率去拆分語義復雜的屬性，拆分方案和屬性數據出現的概率由中央平臺給出，用戶應用程序選擇用戶數據模型需要的拆分方案。例如name屬性的拆分，中央數據模型提供name拆分為famliy-name和givenname的方案。對于family-name有專門的一張表列出不同數據成為family-name的概率，屬性數據按照表中famliy-name概率最大的方案進行拆分。復雜組合的逆規則為拆分后的屬性按照原順序組合。

5 用戶異構數據集成流程

用戶使用應用程序前，首先要在中央平臺上進行注冊，并錄入自己的個人資料，注冊后平臺分配給用戶一個用戶ID作為標識。用戶在注冊時，中央平臺的個人資料數據可以被重用到用戶應用程序。對于每條上傳的數據，中央平臺統一分配一個用戶數據ID對該條數據進行唯一標識，并標示數據上傳的平臺名稱和用戶ID。用戶可以在任意用戶應用程序上使用在中央平臺上保存的相關數據，通過用戶ID實現數據查詢。

5.1 異構函數

中央數據模型和用戶數據模型之間的映射關系是基于異構規則建立的，實際的映射關系持久化成文件，保存在中央平臺上。異構函數處理用戶數據是在中央平臺上實現的，異構函數將用戶應用程序的數據和中央平臺的數據進行轉化，實現了用戶數據的互通。

異構函數首部中的函數名、存儲方式以及函數體由中央平臺給出，而異構函數中的函數類型、參數則由用戶平臺設計時對應的映射關系所決定。

異構函數是異構規則的具體實現，函數的更新由中央平臺決定，用戶平臺通過修改映射關系來實現對異構函數的修改。

5.2 整體流程

用戶數據通過JSON格式的數據接口上傳到中央平臺，中央平臺讀取相應的持久化文件，使用對應的異構函數對用戶數據進行異構處理，處理后的數據以中央平臺的格式保存在中央平臺上。用戶應用程序使用用戶數據時，首先用戶應用程序對中央平臺發出數據請求，中央平臺判斷用戶數據模型與中央數據模型之間是否存在異構，如果存在，則利用對應的異構逆函數處理用戶數據后再返回給用戶應用程序。用戶數據在系統中的整體流程如圖4所示。

圖4 平臺更新用戶數據（左）和查詢用戶數據（右）流程圖

6 實例

以建立微博平臺B數據模型和該平臺的一條用戶微博信息給微博平臺B重用為實例，來說明用戶數據在系統中的處理流程。

用戶平臺首先了解中央數據模型，以下是應用中央數據模型中的微博實體設計出用戶平臺數據模型對應部分的設計過程。利用格式異構規則將屬性Created_at和sendtime實現映射關系，利用表示異構規則實現兩者格式的映射，并將映射關系用可持久化文件保存在中央平臺上，同時生成了微博平臺B 的數據模型（見圖5）。

圖5 微博平臺B建模實例圖

微博平臺A利用用戶數據模型的擴展機制擴展中央平臺中沒有的favorite字段。用戶在微博平臺A中的一條微博信息，通過JSON格式的數據接口提交給中央平臺，其數據接口具體內容和微博平臺A上顯示的微博內容如下：

｛＂uid＂：1773020834，

＂created_at＂：＂2010／11／11 23：20：31＂，

＂content＂：＂明天會很美好＂，

＂favourite＂：false，

＂id＂：4545632｝

中央平臺對該條微博數據進行異構處理后保存。當微博平臺B需要使用這條微博信息時，中央平臺通過用戶ID找到所要查詢的微博數據，sendtime和created-at之間存在格式異構，通過對應的異構逆函數，將該微博數據轉換成微博平臺B能處理的格式，從而實現了該條微博數據在微博平臺B上的重用。實例中各平臺數據格式如圖6所示。

圖6 用戶數據重用實例圖

微博平臺B使用此條微博，接口數據用的JSON格式和微博平臺B上顯示的微博內容如下：

｛＂uid＂：132457865，

＂content＂：＂明天會很美好＂，

＂sendtime＂：＂2010-11-11 23：20：31＂，

＂id＂：4545632｝

7 結束語

提出了一種將用戶異構數據集成的方法。中央平臺設計以用戶為中心的數據模型，用戶應用程序基于中央數據模型和異構規則設計用戶數據模型，用戶數據通過對應的異構函數處理后以統一的數據格式保存到中央平臺，中央數據模型能夠很好地支持用戶個性化需求，數據管理更加統一集中，并保證用戶數據的一致性。原型系統采用JAVA語言進行開發，具有良好的擴展性。

該系統平臺仍存在一些不足，分析的異構沖突情況較少，以致用戶應用程序建立用戶數據模型時存在一定的局限性。在后續開發中要進一步完善用戶數據異構處理的方法。

［1］陳樺，麻風梅，韓艷艷.基于XML的異構數據集成模式的研究［J］.微電子學與計算機，2009，26（1）：137-139，144.

［2］趙國增，郭恒川.基于本體的異構數據共享研究［J］.計算機技術與發展，2010，20（10）：39-42.

［3］趙志強.實現數據庫數據重用的技術分析［J］.軟件技術，2004（6）：46.

［4］周建芳，徐海銀，盧正鼎.基于上下文仲裁的語義異構解決方案［J］.計算機工程，2008（20）：10-12.

［5］蔡國森.數據語義沖突的解決方法［J］.北京工商大學學報（自然科學版），2005（3）：44-46.

［6］靳強勇，李冠宇，張俊.異構數據集成技術的發展和現狀［J］.測繪通報，2002（11）：112-114.

［7］朱凡微.基于本體的異構數據庫集成關鍵技術研究［D］.杭州：浙江大學，2008.

［8］鄭婭峰.異構數據集成的研究和實現［D］.西安：西北大學，2005.

A Method of User-centered Heterogeneous Data Integration

GAO Ming，CHEN Zheng-ming，LV Jia
（College of Internet of Things Engineering，Hohai University，Changzhou 213022，China）

In order to achieve the data share between the differentuser platforms，the same user data distributing on different application platforms are organized according to the unified data model in a unified platform.The heterogeneous data integration technology is used to process user data model and unify them between the heterogeneous problems for data sharing between different application platforms.

User-centered；Heterogeneous data integration；Extension mechanism

10.3969／j.issn.1002-2279.2014.03.008

TP311

：A

：1002-2279（2014）03-0025-05

高明（1988-），男，江蘇常州人，碩士研究生在讀，主研方向：信息系統與工程應用。

2013-12-04