Hello,
Dealing with EAV( entity attribute value model ) oriented structure of data.
So this look like this:
Entity( Entity_Id number , Entity_Name varchar2, Entity_Desc varchar2 )
Entity that list attributes and some meta data on characteristics of attributes:
Type_Of_Attribute( Attr_Id varchar2, Type_Of_Value TOV_Domain, Unit_Of_Value varchar2 , Min_Value variant_type , Max_Value variant_Type )
Then we have actual data. Entity is described with set of attributes and their values. So aditionally to attributes on row form in Entity there are aditional attrbutes in columnar form.
Because of sparsity...
However there in columnar form the challenge or issue is type of values so domains of attributes.
For example:
weight_of_ person is number between min_number and max_number.
But another parameter for example mood_of_person is string from the domain which consists of set of strings/descpriptions.
Another possibility could be reference to some table of values ( key value ) that could be modelled as one:many relationship if put in entity Entity on row form of attributes.
But since this is attribute relate only to few intances or it is very dispersed....and for preserving table form..it was put in columnar form ..
Attribute_Of_Entity( Entity_Id, Attr_Id, value,
-- when not normalized, could be add also unit like kg or lbs or inch or piece ).
My question is on good/succesfull practice of modelling for VALUE in attribute_of_entity?
Somewhere read that some databases have feature of so-called variant type.
Guess the objective is to modell in such a way that implementation of this model is as easy as possbile in
issues like:
a) validating column oriented form during entering or updating values
b) consolidating queries when reporting
c) agregating data when grouping when grouping data and preventing non-comparable data.
So to implement value as structure/complex_type with methods or there is any other feature supporting variabilty of the data along same column in the table. So logical design that would not cause too much complexity in the relational design and table implementation and procedures are handled as much as possible on the database level?
Thank you in advance for comments, experiences, suggestions,