Entity-Attribute-Value Model (EAV)

Unlike a conventional relational table where NULL values consume storage for every absent attribute, the EAV model stores only the attributes that actually exist for a given entity. This makes it exceptionally efficient for domains like clinical data warehousing, where a single patient may have thousands of potential observations but only a few dozen recorded values. The model converts a wide, sparse table into a narrow, dense set of rows, dramatically reducing storage overhead and eliminating the need for constant schema migrations when new clinical parameters are introduced.

The EAV model decouples the logical data model from the physical storage schema. New types of facts—such as a novel genomic biomarker or a newly mandated quality measure—can be added simply by inserting new rows into the attribute definition table, without executing any ALTER TABLE DDL statements. This agility is critical in healthcare, where medical knowledge and regulatory reporting requirements evolve continuously. However, this flexibility shifts the burden of data type enforcement and referential integrity from the database engine to the application layer, requiring robust metadata management.

Every single fact about an entity is stored as an independent row in a narrow table with three core columns:

• Entity: The subject of the fact (e.g., a specific patient encounter ID)
• Attribute: The property being described (e.g., 'systolic_blood_pressure')
• Value: The observed datum (e.g., '120') This row-level granularity allows for precise data provenance tracking, as each fact can carry its own metadata—such as timestamp, unit of measure, and recording clinician—without complicating a fixed-column schema. It naturally supports the temporal and contextual richness required for longitudinal patient records.

While the EAV model is optimized for write-time flexibility and storage efficiency, it is inherently suboptimal for direct analytical queries. To answer a question like 'Show all patients with HbA1c > 8.0 and LDL > 130,' the narrow rows must be conceptually pivoted back into a wide, tabular format. This is achieved through self-joins or conditional aggregation (e.g., MAX(CASE WHEN attribute='HbA1c' THEN value END)). Modern clinical data warehouses often use EAV as an ingestion and staging model before transforming data into a star schema or a graph-based representation for high-performance analytics.

The EAV model's power is entirely dependent on a robust metadata registry. This separate table defines every permissible attribute, including its data type, valid value ranges, unit of measure, and ontological mappings to standards like LOINC or SNOMED CT. The metadata layer acts as the semantic anchor, preventing the model from degenerating into an ungoverned 'bag of tags.' A well-designed metadata registry enables automatic data validation, unit conversion, and the generation of type-safe application code, effectively making the EAV system self-describing.

An EAV table is functionally a serialized property graph. Each row represents an edge connecting an entity node to a literal value node, labeled by the attribute. This structural isomorphism makes EAV data a natural candidate for migration to graph databases like Neo4j or RDF triplestores. In a graph model, the implicit relationships buried in EAV self-joins become explicit, traversable edges, enabling complex path queries—such as finding all patients who received a medication within 24 hours of a specific lab result—with far greater efficiency and expressive power than SQL on EAV tables.

The process of mapping EAV-stored attributes to standardized terminologies like SNOMED CT or LOINC. Since EAV models often store local, proprietary attribute names, alignment harmonizes these to canonical concepts for semantic interoperability.

• Resolves terminological heterogeneity across source systems
• Uses lexical matching and structural graph mapping techniques
• Critical for transforming legacy EAV clinical data warehouses into standards-compliant knowledge graphs

The task of mapping the diverse textual values stored in an EAV model's value column to a single canonical identifier. For example, normalizing 'HTN', 'High Blood Pressure', and 'Essential Hypertension' to the same UMLS Concept Unique Identifier (CUI).

• Handles synonymy and abbreviation expansion
• Often uses vector embeddings for fuzzy semantic matching
• A prerequisite for accurate cohort identification in EAV-based clinical data repositories

The atomic data unit of the Resource Description Framework (RDF) that directly mirrors the EAV structure. A triple consists of a Subject (Entity), Predicate (Attribute), and Object (Value), making RDF a natural graph-based serialization for EAV data.

• Subject → Entity ID
• Predicate → Attribute name
• Object → Value (literal or another entity reference)
• Enables SPARQL querying over what was previously a rigid relational EAV structure

The transformation of EAV-modeled clinical data into Fast Healthcare Interoperability Resources (FHIR). EAV tables are often the source format for legacy EHR data that must be mapped to FHIR's profiled resources like Observation and Condition.

• Maps EAV rows to FHIR Observation.component arrays
• Requires explicit context binding (e.g., linking a blood pressure value to the encounter)
• Enables modern API-based data liquidity from historically siloed EAV warehouses