Questions about database modeling, ID duality

Question

I am creating a system aimed at law firm, and in the middle of the development emerged the following situation:

There are the following tables (summarized):

TB_PROCESSO possessing:

IDPROCESSO
ID_CLIENTE
ID_REU

TB_CLIENTE possessing:

IDCLIENTE

TB_REU possessing:

IDREU

On the table TB_CLIENTE there is all relevant customer information to be served, while the table TB_REU contains only basic information, because usually the information of the defendant is not so relevant.

At the beginning of the project, I created the database with the following logic:

The client will always be the plaintiff, never defendant.

But that’s not the reality, there are cases where the office client will be the defendant. Summarizing back and a half the client will be defendant, formerly will be the plaintiff.

How the database modeling would behave in this case?

Answer 1

I believe that just change the table to OutraParte or some other neutral name. Even there is an asymmetry because if Reu was the correct name, the other table would be Autor.

In a deeper analysis maybe these two names are wrong. But this only you can do and need experience to do right.

In some cases one can separate the idea of customer and part of the process (by the AP response seems to be correct), the first being the contract you have with the person in the provision of service and the second being the one involved in the process, it may even be that in some case the party you represent may appear several times linked to the same client, who may be a natural person, but most likely will be a legal person. And then that table might be Parte (note that I do not understand legal terms well and without until they are half contextual according to region and time).

The plaintiff can become a defendant, and there are no defendants. Finally, there are many different situations than what is being perceived in the question and answer of AP and if the modeling does not think about how the processed ones are in fact there will be major problems.

It may be that the party’s data is contextual according to the process, but I have no way of knowing without me being the analyst. It may be, although the question implies that no, the parts (your client and the other) may be in a single table.

So with more information my recommendation is to have:

• Client (deals with the business relationship)
• Party (dealing with the legal relationship)

Optional:

• Pessoa Física
• Juridical Person

This containing the mandatory basic data of any person to be associated with the customer role or as a party to the process.

The UI does not necessarily need to separate, this table is separated only because of normalization. DB modeling is different from UI modeling.

It may be that none of this is appropriate, but it is because the analysis and description posted here is not appropriate.

So you haven’t even seen the surface of the problem. And doing wrong will have problems in the future.

I often say that taxonomy and ontology is one of the most important things in software development. Without mastering this it is difficult to make a correct software, and even when it works, it is often not the right one, and even when it is right, by coincidence it is not something very desirable.

Considering this basic difficulty there will be much more complex problems to deal with, it would probably be good to get someone more experienced to do the software together. You’re programming and engineering without having previous experience with someone who shows you how it’s done, and this is very complicated.

And if you’re hearing from a client that this is how it’s done, this client isn’t even knowing how to work himself, which is very common. In our area we need to be able to "take" away from the future user what often even he did not realize that this is how he worked. It is very common for the user to follow processes without realizing how he does it, and there are cases of doing wrong or doing what everyone does without questioning about the mistakes of that, or just not being able to pass to you.

Answer 2

Suggestion :

Tabela Processo
Id
Id_Pessoa  -Traz a pessoa
Id_TipoPessoa -Traz que tipo de participação ela terá nesse processo

Tabela Pessoa
Id
Nome


Tabela TipoPessoa
Id
Descricao (réu,cliente,autor)

Answer 3

Guys, I thought a lot about it, I argued with a brother of mine and he gave me the idea to register everything in one table, in the case of TB_CLIENTE. We came to this conclusion because it’s a way that solves all the impasses I was having, and up to pq As unlikely as it is, a defendant may one day be a client, so I’ve come to the conclusion that a defendant’s registration table would be unnecessary. Thank you very much to those who answered, I leave here my opinion. If anyone has any criticism, tip, send you that I will reply.