これはどのような種類のデータモデルですか

Question

"データベースアプリケーション"を見直して、それが大きいと、名前と値のペアを含むフラットテーブルで構成されていることがわかりました。関係はDDLとして存在するのではなく、参照情報を提供する他の表と列の名前への "ポインタ"を提供するヘルパー表の使用によって存在します。これらの関係は、実行時に汎用関数を介して解決されます。

簡体例

エンティティ間の「関係」を提供する一般的な機能のメタコードは

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 

のように見え、上の例では、

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

に解決されるだろう

これらの「関係」はもちろんすべてが「不完全」であるテーブル「カタログ」の「値」は参照されますが、テーブルと列名を「トランスレータ」テーブルに追加するだけで、新しい参照テーブルが作成され、アプリケーションにリンクされたカタログに行を簡単に追加できます。言うまでもなく、私はこのアプリケーション用のERモデルを開発することはできませんし、まったく意味がないとは思いません。

質問：

• このアプローチ/コンセプトのための文献では専門用語がありますか？

• "機能/アドホック/間接"依存関係を作成するデータ広告を格納するこの方法を説明する理論的概念はありますか？ （私はこの「関係」と呼んでいないかもしれません）

• "デザインパターン"に関して上記を説明する方が良いでしょうか？

Answer 1

それは、それらが表す概念テーブルへの実際のDBMSテーブルから、より複雑なマッピングと、EAV、エンティティ属性値の変異体です。残念ながら、実行中の実際のDBMSのメタデータと機能を提供または使用していないのはencoding of the tables and metadata tables of a DBMSです。 （関数のEAV変換をカプセル化することは、間違ったことを行う正しい方法であることに注意してください。）EAVとまったく同じ理由で、anti-patternです。