簡介
實體屬性值模型（ Entity-attribute-value model EAV ）是一種用 數據模型描述實體的屬性（屬性，參數），可以用來形容他們潛在巨大，但實際上將適用於給定的實體的數量是相對較少。 在數學中，這種模式被稱為一個 稀疏矩陣 。 EAV也被稱為 對象的屬性值的模式，垂直的資料庫模型和 開放 式架構。
一個EAV表結構
這個數據表示方式是稀疏矩陣 ，和在一個非空的存儲空間存儲一個有效數據的方法類似。 在一個EAV數據模型里，每一個屬性值是描述一個實體的事實，也是在EAV表行存儲的一個事實。 EAV表經常被描述為“長瘦”：“長”指的行數，“瘦”指的是縱列。數據記錄為三列：?
1、 實體 ：被描述的項目。
2、 屬性或 參數 ：外鍵屬性定義的表。 至少，屬性定義表包含以下幾列：一個屬性ID，屬性名稱，描述， 數據類型 ，以及縱列的輸入驗證。例如，最大的字元串的長度和正則表達式，設定的允許值等
3、 該屬性的 值 。
套用範例
EAV生產資料庫建模的一個例子是臨床研究結果（過去的歷史，現在的投訴，體檢，實驗室測試，專項調查和診斷等），可以適用於病人。縱觀所有特色的醫藥，這些範圍可以在幾十萬（每個月都在開發新的測試）。但是，大多數去看醫生的人都有相對較少的結果。
沒有醫生會永遠有時間來詢問每一個病人。 相反，醫生更加注意他們的病因，並詢問一些問題。 還有的其他問題，是基於以前提出的問題的答覆，其他的問題或者測試也許可以聯繫到他們的體檢。某些結論可以自動排除許多人，例如，如果病人是一個男性，那么醫生將不會考慮與懷孕相關的醫療了。
當病人的記錄匯總之後，通常會記錄“積極”的結果，在任何情況下，不會記錄大量不相關的結果，導致沒有找到這個特殊的病人。
考慮什麼可以代表一個臨床記錄中的大體的數據。 顯然，創建一個數千列的表（或一組表），不是唯一的方法，因為絕大多數的列將是空的。如果是一些複雜的東西，在一個縱向的醫療記錄下患者的數據隨著時間的推移，可能有多個值相同的參數。比如說一個孩子的高度和體重，當孩子成長時，這些數據都在改變。最後，臨床發現病例不斷增加，例如疾病SARS的出現，要制定新的實驗室測試，這又將需要“列”，用戶界面要不斷增加、不斷修訂。 （在資料庫中，屬性列表的變動頻率被稱為“屬性的波動”。）
下面顯示了一個EAV表的臨床研究結果的快照。 所示的尖括弧中的條目在這裡顯示為文本，而不是作為編碼的外鍵值——為了便於理解和引用。 這是一個醫生在98年1月5日上午看一位發熱病人的一些細節。 在這個例子中， 值指的是所有的文字值，但這些也可以成為預先定義值列表的外鍵。當那些已知數是很有限的時候，這些將會變得特別有用。
1、 實體 。 臨床發現，實體是 病人的事件： 一個外鍵，記錄到一個至少包含一個病人ID和一個或更多的時間標記的表中（例如，測試的日期/時間的開始和結束）。
2、 屬性或 參數 ：一個成一個屬性定義的表的外鍵（在這個例子中，指的是臨床研究結果的定義）。 至少，屬性定義表將包含以下幾列：一個屬性ID，屬性名稱，描述， 數據類型 ，計量單位，和協助輸入驗證，例如，最大的字元串的長度和正則表達式，最大和最小允許列值，設定的允許值，等等。
3、該屬性的 值 。 這將取決於數據類型。
（<patient XYZ, 1/5/98 9:30 AM>, <Temperature in degrees Fahrenheit>,"102" ）
（<patient XYZ, 1/5/98 9:30 AM>, <Presence of Cough>, "True" ）
（<patient XYZ, 1/5/98 9:30 AM>, <Type of Cough>, "With phlegm, yellowish, streaks of blood" ）
（ <patient XYZ, 1/5/98 9:30 AM>, <Heart Rate in beats per minute>, "98"）
...
EAV資料庫
長期的“EAV資料庫”，是指一個相當大的比例的數據建模為EAV資料庫設計。 然而，即使在“EAV基於”描述了一個資料庫，系統中的某些表是傳統的關係表。
如上所述，EAV建模使得數據類別感，如臨床發現，屬性是無數和稀疏。 如果這些條件不成立，標準的關係模型（即，每一個屬性列）是可取的;使用EAV並不意味著放棄常識或良好的關係設計的原則。 在臨床記錄系統，subschemas處理病人的人口統計和計費通常是仿照傳統。（雖然大多數供應商的資料庫模式是專有的， VISTA ，整個系統的美國退伍軍人事務部（VA）醫療系統，被稱為退伍軍人健康管理局（VHA ）[1 ]，是開源和它的模式很容易視察的，雖然它採用了腮腺炎資料庫引擎，而不是一個關係資料庫。）
稍後討論，EAV資料庫是不可維護的元數據基本上沒有了許多相關的表，包含支持。 元數據表，通常超過EAV表至少有三個或更多的因素，通常是標準的關係表。[2 ] [3 ]元數據表的一個例子是上面提到的屬性定義表。
EAV與行建模
考慮的EAV上面介紹的一家超市銷售收據（這將反映在銷售管線項目資料庫中的表）的內容數據的相似性。 收據僅列出實際購買的物品的細節，而不是在店裡的每一個產品，客戶有可能購買，但沒有上市。 對於一個給定病人的臨床結果一樣，是稀疏的銷售收據。
§ “實體”的銷售/交易ID -進入銷售交易表的外鍵。 這是用來標記每個行項目內部，雖然收據上的有關銷售的信息出現在頂部（存儲位置，銷售日期/時間），並在底部（出售總價值）。
§ “屬性”到“產品”表的外鍵，其中一個看起來描述，單價，折扣和促銷活動，等（產品一樣不穩定的臨床研究結果，可能更是這樣的：每月推出新產品有的則是採取關閉市場，如果消費者接受程度差。無主管的資料庫設計者將硬編碼的多力多滋或健怡可樂，如個別產品作為表中的列。）
§ “價值觀”是購買的數量和線路總項目的價格。
行建模 ，那裡的東西（在這種情況下，銷售交易）的事實， 而不是多 列多行記錄，是一個標準的數據建模技術。 行建模和EAV（可能被視為行模型 的泛化）之間的差異是：
§ 一個行建模表 同質它描述的事實：一個行項目表描述僅售出產品。 相比之下，EAV表包含幾乎任何類型的事實。
§ 值列/小號連續建模的表中的數據類型是預先確定的，它記錄的事實的性質。 相比之下，在EAV表，在一個特定的行值的概念數據類型取決於該行中的屬性。 因此，在生產系統中，允許數據輸入到一個EAV表直接的將是一個災難，因為資料庫引擎本身將無法執行穩健的輸入驗證。 我們後面將看到它是如何建立通用的框架，執行對輸入的數據進行驗證，大部分任務，沒有一個屬性由屬性的基礎上的無盡的編碼。
行建模在臨床資料庫，還發現多種用途;實驗室測試子模式通常是仿照這種方式，因為實驗室的測試結果通常是數字，或者可以被編碼數值。
的情況下，你需要超越標準行建模，以EAV列舉如下：
§ 個別屬性的數據類型不同（與臨床結果）。
§ 數據種類眾多，增長或波動，但在每個類別中的實例數（記錄/行）是非常小的。 在這裡，與傳統的模擬，資料庫的實體關係圖可能有數百個表：千元/百萬行/實例強調視覺上的相同的程度上為那些極少數行的表中包含。 後者轉換為EAV代表性的候選人。
在本體建模環境，出現這種情況，通常必須在飛行創建類別（“類”），一些課往往在隨後的周期的原型淘汰。
§ 某些（“混合”）類非稀疏的一些屬性（目前在所有或大多數情況下），而其他屬性是充滿變數和稀疏。 後者是適合EAV建模的。 例如，取決於產品的類別，如企業集團公司製造的產品的描述，要描述一個燈泡的品牌的屬性來形容醫療成像設備所需的完全不同，但兩者有共同的屬性，如包裝單位和每個項目的成本。
EAV數據的物理表示
實體
在臨床數據，實體通常是一個臨床事件，如上面所述。 在更多的通用設定，實體是一個成一個“對象”記錄有關每個資料庫中的“對象”（事）的通用信息表的外鍵 - 在最低限度，首選名稱和簡要說明，以及類/實體，它所屬的類。 在此表中的每一個記錄（對象）被分配一個計算機生成的對象ID。
表“物”的做法是，由湯姆Slezak和他的同事在勞倫斯 - 利弗莫爾實驗室率先為19號染色體資料庫，是目前最大型的生物信息學資料庫的標準。 使用一個對象的表不任務的EAV設計的同時使用常規表可以用來存儲每個對象的類的具體細節。
中央對象表的主要好處是，有一個支持對象的同義詞和關鍵字表，可以提供一個標準的類似搜尋引擎的整個系統，用戶可以在其中找到任何感興趣的對象的信息搜尋機制，而無需首先指定的類，它屬於。 （這一點很重要，在生物科學的系統，像“乙醯膽鹼”的關鍵字可以參考分子本身，這是一種神經遞質，或與之結合的生物受體。）
值
所有的值強制轉換成字元串，在EAV數據上面的例子一樣，在一個簡單的，但非可擴展性，結構的結果：常量的數據類型間轉換是必需的，如果一個人想的價值觀做任何的，和價值指數列的EAV表基本上是無用的。 此外，它是不是方便存儲大型二進制數據，如圖像， Base64編碼的形式，在相同的表為小整數或字元串。 因此，更大的系統中每個數據類型（包括二進制大對象，“BLOBS”），確定EAV表，其數據將被儲存在一個給定的屬性的元數據，使用單獨的EAV表。 這種做法其實是相當有效的，因為屬性的元數據，用戶選擇與給定類或形式的適度量可以很容易被快取在記憶體中。 但是，它需要移動數據從一個表到另一個，如果一個屬性的數據類型改變。 （這不經常發生，但錯誤可以在元數據定義，就像在資料庫模式設計。）
屬性
在EAV表本身，這只是一個屬性ID，進入屬性定義表的外鍵，如上所述。 不過，通常有多個元數據表中包含相關屬性信息，這些都是稍後討論。
代表下部結構：EAV類和關係（EAV / CR）
到目前為止，我們所討論的其中一個屬性的值是簡單或原始數據類型的資料庫引擎。 然而，在高度多樣化的數據的代表性用於EAV系統，它是一個給定的對象（類的實例）可能有子結構：也就是說，它的一些屬性可能代表其他類型的對象，這反過來又可能有子結構，一個任意複雜的水平。 例如，一輛車，發動機，變速箱等，和發動機氣缸等元件。 （在給定的類允許子結構系統的屬性的元數據內定義，作為討論後，因此，例如，屬性隨機的訪問，記憶體“，可以申請到的類”計算機“，但不是的類的”引擎“ 。）
為代表的子結構，我們使用一種特殊的EAV表值列中包含系統中的其他實體的引用（即，對象表中的外鍵值）。 要獲得一個給定的對象上的所有信息，因此需要一個元數據的遞歸遍歷，其次是一個遞歸遍歷的數據檢索每個屬性是簡單的（原子），將停止。 這種遞歸遍歷是否有必要在常規或EAV形式代表個人類的細節，如遍歷執行例如，在標準的對象關係系統。 在實踐中，這是非常低效的，僅僅是因為遞歸級別數，往往是相對溫和的大多數類的。
EAV / CR（EAV類和關係）是指一個框架，它支持複雜的子結構。 它的名字是有點用詞不當：outshoot EAV系統的工作，在實踐中，許多甚至大多數在這樣一個系統的類可能代表在標準的關係形式，基於屬性是否是稀疏或密集。 EAV / CR真的是非常詳細的元數據，這是豐富的，足夠的支持，而無需編寫類級的用戶界面代碼自動生成瀏覽接口，個別班級的特點。
EAV系統元數據的關鍵作用
在博士，教授丹尼爾Masys（現任范德比爾特大學的醫學信息部主席），EAV乾工作的事實，在EAV資料庫，“物理模式”（數據的存儲方式）的挑戰的話從根本不同的“邏輯架構” - 方式的用戶，和許多套用軟體，如統計軟體包，把它，即個別班級常規行和列。 （因為一個EAV表概念混合蘋果，橙子，柚子和雜碎，如果你想要做的任何在大多數情況下，使用標準的現成的現成軟體，你有柱狀形式轉換成它的子集的數據分析。[ 4]所謂的旋轉 ，這樣做的過程中，重要的是足夠的，將分開討論。）
元數據有助於執行手的花招，讓用戶與系統互動的邏輯架構，而不是物理方面：軟體不斷諮詢各種操作，如數據演示，互動驗證，大量數據的提取和元數據專案查詢。 元數據其實是可以用於自定義系統的行為。
EAV系統權衡簡單的物理和邏輯結構 ，在其元數據，其中，除其他外，扮演的角色，為複雜的數據標準的資料庫設計資料庫約束和參照完整性。 這種代價是值得的，因為在典型的混合模式的生產系統，在傳統的關係表中的數據也可以從中受益的功能，如自動界面生成。 元數據的結構足夠複雜，它包括其自己的子模式：資料庫內的各種數據表中的外鍵是指在這個子模式中的表。 此子模式是標準的關係，與功能，如正在使用的劍柄的約束和參照完整性。
元數據內容的正確性，在預期的系統行為方面，是至關重要的，並確保正確性的任務，創建EAV系統時，相當大的設計工作必須進入建設的元數據編輯的用戶接口，可以為人們所使用的誰知道問題域（例如，中醫臨床），但不一定是程式設計師的團隊。 （從歷史上看，為什麼未能在其家鄉機構以外的網站通過預關係TMR系統的主要原因之一是，所有的元數據是與非直觀結構的單個檔案存儲自定義系統的行為，改變的內容這個檔案，而不會導致系統打破了這樣一個棘手的任務，該系統的作者只相信自己做。）
凡EAV系統是通過實施的RDF ， RDF Schema的語言可以方便地被用來表達這種元數據。 此架構的信息，然後可以使用EAV資料庫引擎，動態地重新組織其最佳效率的內部表結構 [ 5]。
關於元數據的一些最後的忠告：
§ 因為業務邏輯元數據，而不是明顯在資料庫架構，它是一個人是不熟悉系??統不那么明顯。 因此，重要的元數據瀏覽和元數據報告工具在確保一個EAV系統的可維護性。 在共同的元數據作為一個關係子模式實施的情況下，這些工具都沒有超過使用的，現成的報告或查詢元數據表進行操作的工具，構建的應用程式。
§ 元數據是不夠懂行的用戶容易搞亂。 因此，對元數據的訪問必須加以限制，並落實到位，處理多個個人元數據訪問的情況下訪問和變化的審計線索。 使用元數據的RDBMS將簡化元數據的創建過程中保持一致性和編輯的過程中，利用RDBMS的功能，如支持的交易。 此外，如果元數據是相同的架構作為數據的一部分，這樣可以保證，這將是備份至少經常數據本身，因此它可以恢復到某個時間點。
在元數據中捕獲的信息
屬性元數據
§ 驗證元數據包括數據類型，允許的值或一組值，正則表達式匹配，默認值的成員範圍，以及是否允許值是為空。 EAV代表與下部結構的類的系統，驗證元數據也會記錄，哪一個階級，如果任何一個給定的的屬性屬於。
§ 演講的元數據 ：屬性是如何顯示給用戶（例如，為指定的維度的一個文本框或圖像，下拉列表或單選按鈕）。
§ 屬性發生實驗室指標， 正常值範圍 ，可能會有所不同年齡，性別，生理狀態和含量測定方法，被記錄下來。
§ 分組的元數據 ：屬性通常高階組，例如，一個專業的具體形式的一部分。 分組的元數據包含的信息，如在其中的屬性出現的順序。 某些演示元數據，如字型/顏色和數量，每行顯示的屬性，適用於作為一個整體的集團。
高級驗證元數據
§ 依賴元數據 ：在許多的用戶界面，進入某些領域/屬性的具體值是必需的禁用/隱藏某些其他領域，或啟用/顯示等領域。 為了實現在一個通用的框架，涉及存儲控制的屬性和控制屬性之間的依賴關係。
§ 計算和複雜的驗證 ：在電子表格中，某些屬性的值可以計算的基礎上進入到其他領域值。 （例如，體表面積是一個身高和體重的功能）。 同樣，有可能被“限制”，必須是真實的數據進行有效：例如，在一個差的白細胞計數，個人的白細胞類型計數的總和必須始終等於100。 一般影響的價值觀巨觀取代，用戶輸入，並可以評估的元數據的存儲表達式的計算公式和複雜的驗證。 在Web瀏覽器的JavaScript 和 VBScript有一個eval（）函式可用於這一目的的槓桿。
驗證，演示和分組元數據支持兩種瀏覽以及互動編輯數據的自動用戶界面生成的代碼框架，創造可能。 EAV數據驗證的任務，在生產系統是通過網路交付，基本上是從back-end/database層（這個任務是無能為力的）中間/ Web伺服器層。 雖然後端驗證總是理想的，因為它是不可能顛覆試圖通過直接數據輸入到一個表，中間層驗證通過一個通用的框架是相當可行的，雖然大量的軟體設計工作，必須建設框架的第一個進入。 避免輪改造的可用性，可以研究和修改個性化需求的開放源碼框架，可以在很長的路要走。
適合EAV建模的場景
（本節的第一部分是一個在醫學中環奴/ Nadkarni參考文章PRECIS [6] ，以更多細節的讀者。）
EAV建模，根據替代條款“ 的通用數據建模 “或”開放式架構“，長期以來一直是先進的數據建模者的標準工具。 任何先進技術一樣，它可以是一把雙刃劍，應謹慎使用。
此外，EAV就業不排除傳統的關係資料庫建模方法，在同一個資料庫架構的就業。 EMRS該規則如RBDMS， Cerner公司 ，使用他們的臨床數據的子模式EAV方法，絕大多數的架構中的表，其實是傳統的建模與作為代表，而不是作為行的各個列的屬性，。
子模式的EAV系統的元數據建模，其實，是很好的契合了傳統的建模，因為之間的元數據的各個組成部分之間的相互關係。 在TrialDB系統中，例如，架構中的元數據表的數量比約十到一的數據表;因為元數據的正確性和一致性是非常關鍵的EAV系統的正確操作，系統設計師要採取充分利用所有的RDBMS提供的功能，如參照完整性和可程式約束，而不是徹底改造的RDBMS引擎輪。 因此，大量的元數據表，支持EAV設計通常是在第三個正常的關係形式。
建模稀疏屬性
使用EAV模型的典型案例，是非常稀少，異構屬性，如電子醫療記錄（EMRS），如上面所說的臨床參數，。 然而，即使在這裡，它是準確的狀態，EAV建模的原則是適用於的，而不是它的所有內容資料庫 的一個子模式。 （例如，病人的人口統計，是最自然為藍本一列每個屬性，傳統的關係結構。）
因此，關於EAV與“關係”的設計參數反映的問題不完全理解：EAV設計應僅受僱於稀疏屬性需要一個資料庫為藍本，分模式：即使在這裡，他們需要得到支持3 NF元數據表。 有相對較少的資料庫設計，稀疏的屬性中遇到的問題：這就是為什麼EAV設計是適用的情況是比較少見的的。即使他們遇到了一套EAV表是不是只有這樣，才能解決稀疏數據：一種基於XML的解決方案（下文討論）是適用於每個實體的屬性的最大數量是相對溫和，稀疏的總量數據也同樣是溫和的。 這種情況的一個例子是捕捉不同的產品類型的變數屬性的問題。
建模與極少數實例每班許多類：高動態模式
的EAV的另一種套用是在建模的類和屬性，不疏，是動態的，但每類數據行的數量將相對溫和 - 百行最多的夫婦，但通常是幾十 - 系統開發人員還需要一個很短的周轉時間內提供一個基於Web的最終用戶界面。 “動態”意味著新的類和屬性，需要不斷地加以定義和修改，以代表一個不斷發展的的數據模型。 可能會出現這種情況在迅速演變的科學領域，以及在本體論的發展，特別是在原型和疊代的細化階段。
雖然創建新的表和列來表示數據並不是特別是勞動力密集型的一個新的品類，是基於Web的接口，支持瀏覽或基本的編輯，類型和範圍為基礎的驗證編程。 在這種情況下，更易於維護的長期解決方案是創建一個類和屬性定義存儲在元數據框架，該軟體生成一個基本的用戶界面，此元數據動態。
創建EAV / CR框架，前面提到的，解決這一非常情況。 注意：EAV數據模型是沒有必要在這裡的，但系統設計者可能認為這是一個可以接受的替代品，創造，說，第六十二或更多的表，共包含不超過2萬行。 在這裡，因為每類行的數量是如此之少，效率的考慮是不那么重要;類ID /屬性ID的標準索引，資料庫管理系統最佳化可以輕鬆地在記憶體中快取，小班的數據，運行查詢時涉及這個類或屬性。
在動態屬性的情況下，這是值得注意的，資源描述框架（RDF）是受聘為語義Web相關的本體工作的基礎。 RDF中，是一個代表信息的一般方法，是EAV形式：RDF三元組包括一個對象，屬性和值。
總之，這是值得引用喬恩賓利的經典之作，“編寫高效的方案”（Prentice - Hall出版）。 在書的結尾，賓利警告更有效率，使代碼一般也使得它更難理解和維護，所以人們並不急於在和調整代碼，除非首先確定有* *性能問題，並採取措施如代碼分析已經查明的瓶頸的確切位置。一旦你這樣做，你只修改特定的代碼需要運行得更快。 類似的考慮也適用於EAV建模：您套用它只有傳統的關係模型是已知先驗笨重（如在臨床上的數據域），或發現的子系統，在系統演化，構成重大維修挑戰。
