Modeling a Base of Knowledge
Posted on 2014-03-03
I'm involved in a project of creating a base of knowledge for human resources in projects. When doing the ER model of a little part of the problem a doubt assails me: which is the preferred way of modeling it, considering efficiency, good design practices and database normalization. The application will be developed in .NET, but It could be queried using php, for example. We have 4 levels of entities which represents our knowledge base:
I'm among two possible relational implementations:
If using weak entities, each table will have a composed key: a unique Id plus the keys of the foreign tables of previous levels. It seems to be better to make complex reports with this model because of the replication of keys form all previous levels.
- supertopic (IDSupertopic,...)
- topic (IDSupertopic, IDTopic,...)
- subtopic (IDSupertopic, IDTopic, IDSubtopic,...)
- knowledge(IDSupertopic, IDTopic, IDSubtopic, IDKnowledge...)
If using strong entities, each table will have a simple unique key, and a foreign key from the previous level object (table). It seems easier to manage this kind of model because of the simplification of table keys.
- supertopic (ConsecutiveKey,...)
- Topic (ConsecutiveKey, IDSupertopic, ...)
- subtopic(ConsecutiveKey, IDTopic...)
- knowledge(ConsecutiveKey, IDSubtopic...).
Can anyone give me some advise related with advantages and disadvantages of each possibility?