4
I’ve read some articles about Generalization/Specialization in data modeling, but some questions have arisen: Is the primary key to generalization also the primary key to specializations - that is, can specializations contain their own primary keys? If so, how are the relationships between them? A specialized entity must have attributes? When I should - or not - specialize an entity and when I should generalize others?
3
I don’t really like this idea. To tell you the truth it is more absurd and if applied creates very strange things. At least in the database if you do the generalization the right way is not to have any difficulty.
In an application there are those who say, and today having to agree in most cases, that a type of data must be prepared to be specialized and not allow create a concrete object of it, or be able to create the concrete object and not be able to be specialized. There are useful exceptions to this, so a type is allowed to generate concrete object and be specialized, but it should not be abused.
In a database it does not have this need, or is general and will never have such data or is specific and has data, never both. So the generalized type is only part of the logical model to better organize the model, there will be no data persisted in the Storage with this type, only have of the specific types, so doing so is the right your problem does not exist, there is only real primary key in the specialized type.
If you insist on doing wrong, I don’t even think you’re specializing, you’re normalizing tables by establishing a relationship. And with worse performance to zero gain. If it is really a specialization to ratio is 1:1, completely unnecessary in almost all cases where it is doing right. It makes no sense.
There is no such thing as specializing some entities and generalizing others, there is the establishment of relationship of generality and specialty between entities. When he realizes that there is a pattern in certain entities and this can provoke the creation of the idea of a general logical entity so that every time he touches it he has to work with his specialized ones, he has to do it. There are fewer such cases than it may seem. Most of the cases that people think have this kind of relationship to actually other forms of data composition, in general are papers.
The examples of link cited are bad and apparently done because who does not make real software. Legal persons are not the specializations of a client in any context. In general you have the physical or legal person who are concrete (and can have person with abstract generalization) and the client is only a role of a person. OP example is even too simplistic to teach something useful. More or less the same goes for others.
To do everything right you need to understand a lot of the subject you are modeling, you have to practice a lot of taxonomy and ontology. It is necessary to understand the relationships of things outside of software to model right within it. If you don’t understand what each is understood and the real relationship between them you will model wrong or hit just by coincidence, a real lottery. You don’t have a book or a degree or anything to teach this. The only way is to build the knowledge by consuming, observing, debating, practicing on these domains and general subjects, to form a logical, critical and holistic thinking about the world and the systems already established in the real world.
Some related questions:
Browser other questions tagged database modeling inheritance relational-model
You are not signed in. Login or sign up in order to post.
Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful to you. You can also vote on any question or answer you find useful on the entire site
– Maniero