CODEWITHSUNDEEP
sqldatabasepostgresqldatabase-design
Bulva
Bulva

Reputation: 1248

Design for relation database with object structure

I am designing database for my app. I am using PostgreSQL. It has to be generic app and real world structure looks like this:

Category (e.g. vegetation) ---> Phenomenon (e.g. tree) ---> Parameters (e.g. type - coniferous vs. deciduous, height in meters - 10 and so on)

The database can store a lot of categories, phenomenons, parameters and their values. One category can have N phenomenons, one phenomenon can have N parameters.

So I created these tables:

Category
--------
id
name


Phenomenon
----------
id
name
category FK (to Category)


Parameter
---------
phenomenon FK (to Phenomenon)
name
value <-- here is a problem

In value column can be value from dictionary, varchar value, numeric value or boolean value. How can I design Parameter table? Should I make more columns for different types of value (varchar - can be dictionary value without integrity check, numeric, boolean). Or is there any design considering this problem? I don't want use JSON or XML.

I am really appreciate for any help.

Upvotes: 1

Views: 47

Answers (1)

reaanb
reaanb

Reputation: 10066

Your Parameter table is an EAV (entity-attribute-value) table and is not supported by the relational model. The RM is a first-order logical model which requires that every attribute have a single domain.

In your model, the domain of the value attribute depends on the value of the name attribute. So, it's not relational but it is implementable in SQL databases, though it's a pattern I avoid when possible since it makes integrity constraints difficult to impossible and complicates queries.

In first-order models, each distinct parameter would be in a separate relation, e.g.:

PhenomenonHeight
----------------
phenomenon FK (to Phenomenon)
height

PhenomenonType
----------------
phenomenon FK (to Phenomenon)
type

and so on.

Upvotes: 2

Related Questions