实体属性值模型的简介

实体属性值模型（Entity-attribute-value modelEAV）是一种用数据模型描述实体的属性（属性，参数），可以用来形容他们潜在巨大，但实际上将适用于给定的实体的数量是相对较少。 在数学中，这种模式被称为一个稀疏矩阵 。 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建模：您应用它只有传统的关系模型是已知先验笨重（如在临床上的数据域），或发现的子系统，在系统演化，构成重大维修挑战。