I think you just have to change the table to OutraParte or some other neutral name. There is even an asymmetry because if Reu was the correct name, the other table would be Autor .
On closer examination, these two names may be wrong. But that only you can do and need experience to do right.
In some cases you can separate the idea of client and part of the process (by AP's answer seems to be correct), the first being the contract you have with the person in service and the second being the involved in the process, it may even be that in some case the part you represent may appear several times linked to the same client, who may be an individual, but most likely will be a legal entity. And then this table may be Parte (note that I do not dominate legal terms well and without until they are somewhat contextual according to region and time).
The author can become defendant, has actions that there are no defendants. Anyway, there are many situations different from what is being perceived in the AP question and answer and if the modeling does not think about how the processed are in fact there will be big problems.
The part data may be contextual according to the process, but I can not know without my being the analyst. It may be, although the question implies that no, the parties (your client and the other) may be in a single table.
So with more information my recommendation is to have:
- Customer (deals with business relationship)
- Part (deals with legal relationship)
Optional:
This contains the mandatory basic data of any person to be associated with the role of customer or as part of the process.
The UI does not necessarily have to separate, this table is separated only for the sake of normalization. DB modeling is different from UI modeling.
It may not be appropriate, but it is because the analysis and description posted here is not appropriate.
So you have not even seen the surface of the problem. And doing wrong will have problems in the future.
I usually say that taxonomy and ontology is one of the most important things in software development. Without dominating 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 very desirable.
Considering this basic difficulty there will be much more complex problems to deal with, it would probably be good to arrange someone more experienced to make the software together. You're programming and engineering without previous experience with someone who shows you how it's done, and that's pretty tricky.
And if you're hearing from a customer that's how you do it, that customer is not even knowing how to work, which is very common. In our area we need to be able to "get" the future user, which often he did not even realize was how he worked. It is very common for the user to follow processes without realizing how he does it, and he has cases of doing wrong or doing what everybody does without questioning about the mistakes of that, or just not being able to get through to you.
