Specialization and generalization in databases and application development

Asked

Viewed 240 times

5

I have a table Livros and I know that the specialization/generalization of books are Livros de Ficção, Livros de Drama and Livros de Suspense, for example.

However, in the logical model, I don’t know if I create a table Livros relationship 1:N Tipos de livros with each type registered or if I create a table for each specialization (livro_drama, livro_ficção)!

I know it would be impractical to create a table for each Tipo, because if I needed new types of books I would always have to create a new table. But if I use the other way, each type of book registered would have its specific business rules, even registering each type, I would have to program the associated rules.

Something is bothering me in both solutions! How do I resolve this impasse?

database modeling relational-model

  • I see it like this: a table for books, and one only containing genres (suspense, drama, science fiction, etc). There an associative table holding the information that a book may have one or more genres.

  • @Piovezan This is exactly what I saw at first, but with a closer analysis I saw the following case: what if for example the suspense books need some specific rule in the application, being it a genre? And the new genres that were added to the system, I would constantly have to remodel the system with "possible" rules in the application.

2 answers

4


Is there any reason to have a specialization? If so, is there any reason to have a generalization? It may seem obvious, but one of the two seems to be wrong in relational modeling. If you’re talking about specialization you don’t have to talk about relationship, they’re exclusionary concepts.

Don’t do something for no reason. Ask yourself why you’re using something? What problem is this solving? And what are they causing?

You say that each type of book has specific business rules. Really? Are you sure? Let’s say yes, and why are the business rules in the database? Let’s say you want to do so, which the question already shows that this is not a good idea, what solution do you see other than separating each type in a table? If the data behaves differently it needs to be in a different table. I just wouldn’t do it like this, in my vision, I might actually need something out of the ordinary.

A solution is to have a single table and some actions that depend on the type being made conditional.

There is no impasse. I don’t see any specialization or relationship there, so there is no dichotomy. It only has different business rules that are programmed in the application. Or in the database if you prefer. But there is no reason to create a new table if the structure is the same. Database is not application, although some think it is.

Behold advantages and disadvantages of putting the business rule in the database.

  • It is exactly this doubt that I am going through for not having a good initial analysis of the application. Not only because of me, but because you pass me such requirements, perhaps because you do not know certain parts of the process forcing me to have certain points and avoid as many maintenance problems in the future. So in his view, it would be like: only the table "Books" with the types "enums" and with rules in the application or only the table "genres"? I see your point.

-4

I was thinking that your book specialties were, for example,:

  • Digital books
  • Audiobooks
  • Printed books

in which the nature of the reading experience is different, in each case. Hence a specialization.

In addition, as to the criterion of using several or a table, will according to your will, or according to the will of the data architect, basically.

  • I like that view, it really makes sense. It reinforces me more and more that the ideal would be "genres of books" but if I had to put a rule in this type, for example "Suspense" that something would be different here. Would I just make a "suspense" query and program these rules? but and if for some reason the field is deleted, the rule in the application would still be there. I would always have this concern between the application and the bank. There is some way to better control this. Version control does not manage the database.

  • In libraries, a code called CDD, https://pt.wikibooks.org/wiki/T%C3%B3pico:Wikilivros_discuss%C3%A3o:Biblioteca/Classifica%C3%A7%C3%A3o_e_categoriza%C3%A7%C3%A3o_dos_livros/resposta_(10) is usually used to classify the subject of the book, so specializing the book according to its genre would supercomplicate the bank scheme, I think!

  • Here: https://processotecnicoucs.wordpress.com/2011/09/14/classificacao-de-obras-literarias-ii/ also has a list of literary genre classifications by CDD/CDU.

Browser other questions tagged database modeling relational-model

You are not signed in. Login or sign up in order to post.