实体属性值模型

简介

一个EAV表结构

这个数据表示方式是稀疏矩阵 ，和在一个非空的存储空间存储一个有效数据的方法类似。 在一个EAV数据模型里，每一个属性值是描述一个实体的事实，也是在EAV表行存储的一个事实。 EAV表经常被描述为“长瘦”：“长”指的行数，“瘦”指的是纵列。数据记录为三列：?

1、 实体 ：被描述的项目。

2、 属性或参数 ：外键属性定义的表。 至少，属性定义表包含以下几列：一个属性ID，属性名称，描述， 数据类型 ，以及纵列的输入验证。例如，最大的字元串的长度和正则表达式，设定的允许值等

3、 该属性的值 。

套用範例

EAV生产资料库建模的一个例子是临床研究结果（过去的历史，现在的投诉，体检，实验室测试，专项调查和诊断等），可以适用于病人。纵观所有特色的医药，这些範围可以在几十万（每个月都在开发新的测试）。但是，大多数去看医生的人都有相对较少的结果。

没有医生会永远有时间来询问每一个病人。 相反，医生更加注意他们的病因，并询问一些问题。 还有的其他问题，是基于以前提出的问题的答覆，其他的问题或者测试也许可以联繫到他们的体检。某些结论可以自动排除许多人，例如，如果病人是一个男性，那么医生将不会考虑与怀孕相关的医疗了。

当病人的记录汇总之后，通常会记录“积极”的结果，在任何情况下，不会记录大量不相关的结果，导致没有找到这个特殊的病人。

考虑什么可以代表一个临床记录中的大体的数据。 显然，创建一个数千列的表（或一组表），不是唯一的方法，因为绝大多数的列将是空的。如果是一些複杂的东西，在一个纵向的医疗记录下患者的数据随着时间的推移，可能有多个值相同的参数。比如说一个孩子的高度和体重，当孩子成长时，这些数据都在改变。最后，临床发现病例不断增加，例如疾病SARS的出现，要制定新的实验室测试，这又将需要“列”，用户界面要不断增加、不断修订。 （在资料库中，属性列表的变动频率被称为“属性的波动”。）

下面显示了一个EAV表的临床研究结果的快照。 所示的尖括弧中的条目在这里显示为文本，而不是作为编码的外键值——为了便于理解和引用。 这是一个医生在98年1月5日上午看一位发热病人的一些细节。 在这个例子中， 值指的是所有的文字值，但这些也可以成为预先定义值列表的外键。当那些已知数是很有限的时候，这些将会变得特别有用。

1、实体 。 临床发现，实体是病人的事件： 一个外键，记录到一个至少包含一个病人ID和一个或更多的时间标记的表中（例如，测试的日期/时间的开始和结束）。

2、属性或参数 ：一个成一个属性定义的表的外键（在这个例子中，指的是临床研究结果的定义）。 至少，属性定义表将包含以下几列：一个属性ID，属性名称，描述， 数据类型 ，计量单位，和协助输入验证，例如，最大的字元串的长度和正则表达式，最大和最小允许列值，设定的允许值，等等。

3、该属性的值 。 这将取决于数据类型。

（, ,102 ）

（, , True ）

（, , With phlegm, yellowish, streaks of blood ）

（ , , 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表本身，这只是一个属性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的解决方案（下文讨论）是适用于每个实体的属性的最大数量是相对温和，稀疏的总量数据也同样是温和的。 这种情况的一个例子是捕捉不同的产品类型的变数属性的问题。

建模与极少数实例每班许多类：高动态模式

虽然创建新的表和列来表示数据并不是特别是劳动力密集型的一个新的品类，是基于Web的接口，支持浏览或基本的编辑，类型和範围为基础的验证编程。 在这种情况下，更易于维护的长期解决方案是创建一个类和属性定义存储在元数据框架，该软体生成一个基本的用户界面，此元数据动态。

创建EAV / CR框架，前面提到的，解决这一非常情况。 注意：EAV数据模型是没有必要在这里的，但系统设计者可能认为这是一个可以接受的替代品，创造，说，第六十二或更多的表，共包含不超过2万行。 在这里，因为每类行的数量是如此之少，效率的考虑是不那么重要;类ID /属性ID的标準索引，资料库管理系统最佳化可以轻鬆地在记忆体中快取，小班的数据，运行查询时涉及这个类或属性。

在动态属性的情况下，这是值得注意的，资源描述框架（RDF）是受聘为语义Web相关的本体工作的基础。 RDF中，是一个代表信息的一般方法，是EAV形式：RDF三元组包括一个对象，属性和值。

总之，这是值得引用乔恩宾利的经典之作，“编写高效的方案”（Prentice - Hall出版）。 在书的结尾，宾利警告更有效率，使代码一般也使得它更难理解和维护，所以人们并不急于在和调整代码，除非首先确定有* *性能问题，并採取措施如代码分析已经查明的瓶颈的确切位置。一旦你这样做，你只修改特定的代码需要运行得更快。 类似的考虑也适用于EAV建模：您套用它只有传统的关係模型是已知先验笨重（如在临床上的数据域），或发现的子系统，在系统演化，构成重大维修挑战。