What kind of data model is this

Question

I reviewed a "database application"and found it by large to consists of flat tables containing name-value pairs. Relations are not existing as DDL but by use of helper tables providing "pointers" to other table and column names providing referential informations. These relations are resolved at runtime via generic functions.

Simplified example

The meta code of a generic function providing "relations" between entities looks like

FUNCTION Translate (Element)

    LOCAL c, t, r

    SELECT Table, Column
    INTO   t, c
    FROM   Translator
    WHERE  Item = $Element

    SELECT $c
    INTO   $r
    FROM   $t
    WHERE  Name = $Element

    RETURN $r

END FUNCTION

and in the above example, would be resolved to

Translate "Ele1" ==> "Bar"
Translate "Ele2" ==> NULL
Translate "Ele3" ==> "Bar2"

These "relations" are of course incomplete as not all "values" of table "catalog" are referenced, on the other hand rows can be easily added to a catalog with new referencing tables created and linked into the application by "just" adding table and column names to the "Translator" table. Needless to say that I am unable to develop an ER model for this application nor do I think that such would make sense at all.

Questions:

is there a technical term in literature for this approach/concept?
is there a theoretical concept describing this way of storing data ad creating "functional/adhoc/indirect" dependencies? (I may not want to call this "relations")
would it be better to describe the above in terms of a "design pattern"?

I don't know of a name for this pattern, but I will point out one of its features. The values stored in user tables are a mixture of data and metadata. In a traditional relational model, the DDL defines the data, and the metadata that results from the DDL is all stored in system tables, aka the data dictionary. User tables do not contain metadata. — Walter Mitty, Nov 02 '16 at 13:14
The reason some designers prefer this kind of thing is simple. It allows some changes to the data model to be made on the fly, without performing any DDL. This allows application programmers to make changes without running them through a DBA, and slowing down the process. The downside is that it results in undocumented data. — Walter Mitty, Nov 02 '16 at 13:16
Further research results in the above sometimes being described as "polymorphistic associations and sometimes attributed as antipattern — MikeD, Nov 02 '16 at 14:17

score 1 · Accepted Answer · edited May 23 '17 at 10:27

It is a variant of EAV, Entity-Attribute-Value, with a more complex mapping from actual DBMS tables to the conceptual tables they represent. It is an encoding of the tables and metadata tables of a DBMS that unfortunately isn't offering or using the metadata and functionality of the actual DBMS that is executing. (Observe how encapsulating EAV translations in functions is the right way to do the wrong thing.) And it is an anti-pattern for exactly the same reasons that EAV is.

What kind of data model is this

1 Answers1