Can an employee be an individual?

Asked

Viewed 167 times

4

Was recommended, in this question, maintain the relationship between Pessoa Física and Funcionário as generalization (Employee extends Physical Person).

I do not understand why it is not in this case to make a paper relationship (Employee is Person role), at least as I understand that roles work. In order to avoid doubts in the comments and generate some points in the Q&A system, I turned into a question.

A justification may be that from there it is strange the entity Vendedor be "role of a role", that is, Seller be role of the Employee, which in turn is role of Individual. But I would like a further clarification.

It was justified that Individual is an exclusionary condition (it cannot be physical and legal at the same time), and in this case it makes no sense to have papers, but I did not understand this justification. I see no harm in physical person playing a role.

modeling diagram der
  • 2

    Usually for me the Employee is a specialization (maybe what you call paper) of Individual. Just as Client is another specialization, System User is more a specialization, and so it goes. After all, they are people, right? And all people potentially could be any or all of the aforementioned specializations. I don’t even see confusion in it, for me modeling is merely a formal description of reality.

  • 1

    On the question of the excludent, I see two more obvious ways. Either you have juridical and physical, without mixing, or you have "entities" and the juridical person and physical person are specializations (which does not rule out that physics continue to be treated as I mentioned at the beginning). I tend not to mix the 2 things (which does not mean not reuse the relationships in common points, are things that can be administered without problem), but there is case by case.

  • I do not call role of specialization but rather a relationship Individual "has role" or "performs role of" Employee. Example Company having Buyer, Seller papers, etc. (taken from here). It’s a relationship of composition.

  • 1

    These examples I find quite nonsense, because they invent unnecessary figures (or have bad names for things). I don’t know if the problem is nomenclature, but I think it’s too extensive for comment. Unfortunately there is a lot of large and famous company that follows this line of examples.

  • Has in the Wikipedia also (Figure 3).

  • 1

    The one on wikipedia is much better, use "person". Except for a "bot", a seller is really a person, a buyer too (it can be legal, then it comes down to what I say about convenience for your case), and a employee is also a person. And this person can be all at once. More than modeling, it’s fact. "Company role" for me does not carry any sense. " Person" I know what it is without need of explanation.

  • I agree with everything Bacco has said so far, later I can see better.

  • Do you think it’s strange the Company? I should have shown this figure, the other only makes a generalization about the roles. For me it is the same relationship that in Person, "has role", "can act as one". Relationship of composition. Does not see sense in the case of Company also?

  • 1

    I can’t see a company relating to a vendor or a Costomer. I can see a company relating to a person with a vendor role and/or Ustomer. This last figure is jumping the person.

  • Sorry, I think I contextualized wrong for you. In the example of Company is the company itself that is assuming the role of Vendor or Customer. She (the company) is a Seller or Buyer of products.

  • 1

    Ah, but then we’re out of your question. You can even have a direct sale online etc, but the subject begins to get broad if we cover all possibilities.

  • All right, I’m just using the example that the article gave. I learned from it. We can stay in Person then. In Person you see sense. Does it make sense that the Employee is the role of Individual? I’ll reread what you wrote.

  • 2

    Right. I wouldn’t have much to add, I just think you really have to take your real problem and solve, as long as you describe the situation well. There’s no magic recipe for every case, just principles, I guess. Mine are to make things as simple as possible and to make things self-describing (That’s why you won’t see me in the posts with too much academicism, I find life too short for this :D - I think if I had good recipe that served for everything, would have consolidated, and if not, we will solve in the real case that is faster)

  • I don’t see how academicism the application of roles, I’m just wondering if they apply to that particular case. As in general heritage It greatly enhances relationships, I thought that composition in this case would make the design more flexible (if such a relationship fits conceptually).

  • "And all persons potentially could be any or all of the specializations mentioned" (there in the first comment) did not understand, you are talking about multiple inheritance?

  • @Bacco Or a hierarchy with some levels?

  • 1

    Hi, I think it’s what has in the @Maniero’s answer even, between heritage and composition I would say composition, but I already mentioned that I try not to stick to academicity for that very reason. The theoretical world is "very cool", but at the moment what will command is what the language actually has and what gives of appeal, so I run away from these definitions whenever I can :)

  • Those who voted against could justify?

Show 13 more comments

1 answer

4


It was recommended, in this question, to maintain the relationship between Physical Person and Employee as generalization (Employee extends Physical Person). I do not understand why it is not in this case to make a paper relationship (Employee is role of Person), at least as I understand that roles work.

It was recommended in the question, not in the answer. I find a mistake and said that Funcionario is a role of PessoaFisica. Because if that person is also a client and is a specialization, therefore inheritance, the only solution is to have two instances of the same person, which is a conceptual madness, or to save space in the person to be everything that it can be.

Taking this second case has two ways of doing: one is to keep everything together and the other is to have external references.

Keeping together in memory only gives with huge waste, and in DB, or has this problem too, or needs a format without scheme, which can bring other problems.

Keeping it separate in memory is not too complicated, in a database is exactly what the role model does. It’s much more obvious to do so, so it’s not really a legacy, also because it’s something dynamic that the programmer has no control over.

The solution that people make is to have more than one person among the data representing the real person. It’s an obvious gross mistake that "nobody" sees.

Can’t you ever do it? It can, like optimization or if it really makes sense. Forbidden is never.

As access optimization you can keep in the papers all the data from Pessoa not to have to look more than one table, but to have a writing cost (which can be advantageous) since any data change in the Pessoa has to obligatorily and preferably atomically update all the roles that that person will have.

A detail of implementation of papers is that it is usually more interesting to have a mechanism that indicates what roles that person actively possesses. This can be a few columns (then only with programmatic change to add some new, and may have some waste of space), it can be schemaless with a "array" of papers (not all Dbs allow easily), or may have an extra table that does the mooring (very expensive cost of access). In memory is not much different, except that it has more difficulty to be without schema without an auxiliary table, but in compensation an extra table costs cheap in this device.

Paper is just a simple composition, just as you can have N sales of a product, you will have N roles of a person. In fact the normal will be quite low N, in most cases should be 1. Is to think what makes more.

A justification may be that from there it is strange the entity Vendendor be "role of a role", that is, Seller be role of the Employee, which in turn is role of Individual. But I would like a further clarification.

Exactly, a role being attached to a role does not make sense, who has the role of Vendedor? To Pessoa. In this case it can be physical or legal (even if your model never accepts this who guarantees that in the future will not accept?), has already broken the model of Vendedor be bound by Funcionario. But if someone says it’s different, okay, every real situation can ask for something different.

In the comments has a model of roles I don’t like it, I don’t know if that’s what I call paper. But it might just be that I’m confused about what I already know. Anyway it has very bad examples, full of seemingly unnecessary things.

I see no harm in physical person playing a role

I didn’t either.

What I said was that a PessoaFisica should not be a role of Pessoa. But I made the caveat that this vision is valid in some scenario.

Concretely you, or have a PessoaFisica, or has a PessoaJuridica. Pessoa is naturally an abstract concept, which can give the impression of not being because we tend to believe that person is a human being. We are talking about personality according to legislation. There is not only Pessoa, from the legal point of view does not have this object, no one is just that, there are no descriptions for what would be this object. For physical or legal has: lists the necessary documents, a name, address, sex or activity, has date of birth/foundation, etc.

One cannot play a role in something that even exists. One must have a concrete concept based on something that can be generalized. In fact in relational databases it is normal that Pessoa evaporate when shaping the physical. At most you will have a view that allows access PessoaFisica or PessoaJuridica without distinction.

But it’s said there that it’s not the end of the world Pessoa concrete, just find inefficient for little or no benefit, you would always have to access two tables to get everything you need in most cases. This is a case that does not risk having the same entity being represented by two objects in the roll manipulated data. Papers are not only good, they are necessary to not turn mess. The simple should always be preferable and in this case the simple is to have no paper. Who wants to complicate that should justify what problem he wants to solve with complication.

I know how to justify the use of roles among concrete people. That’s partly what’s up there.

I tend not to use 1:1 relations in the model (not to confuse 1:1 in the data), I find them unnecessary in most cases, and where it is usually is to solve another problem created mistakenly. Again, if you think you should wear something like this, you have to justify.

Have you seen the question What is the advantage of a 1:1 relationship?? There it speaks of 1:1 data and not model, and if we analyze well, except for the first, all the others are for need of mechanisms, it has nothing to do with the conceptual model. I speak which is the ideal model, if the mechanism requires something else is part of another scope.

I only care about it because I know the difficulty that it is to change something when it has been misconceived (and we always do this, there is no way to do perfect always), and I like to do it optimized. If you can let go of one of those things it matters less, if you can let go of both, then everything goes.

As Bacco said in the comments, modeling has to be based on facts. The problem is that many models are made in assumptions, and visions of reality that are not real. And it’s easy to fall into that trap. I keep falling in domains I haven’t worked yet, and even the ones I’ve worked on make some mistakes.

  • "Because if that person is also a client and is a specialization, therefore inheritance, the only solution is to have two instances of the same person, which is a conceptual madness, or to save space in the person to be everything that it can be." I do not master the transformation from conceptual to physical, could clarify what these solutions are about?

  • Yes, and if you clarify what the doubt is that I don’t understand.

  • I think that this phrase I quoted is talking about the conceptual, the model. Then it talks about how it becomes physical, about data. Am I right? Doubt is there, when you say "the only solution is this or this" I don’t understand what these solutions are.

  • Not exactly, the conceptual is the focus, even I speak of the physical applying the conceptual, because the physical is the application of the conceptual. Even you end up changing the concept if you need to make a different physicist. Conceptual there is not logical. Especially because nothing adinata have a logical great if the physical does not fit.

  • "Having two instances of the same person" I understood more or less what it is (but explain anyway if possible), now "save space in the person" I did not understand. Do you speak of having attributes in the entity Person? (can I speak of the DER as if it were a class diagram? The two are similar). If so, doubt is how it is converted into data.

  • If you have a person who has several roles in himself and only wants to have one instance, what is the solution? Having a person who "knows" everything about the papers, turn into a linguing object with everything there. The data stays all inside. It’s horrible too.

  • Conceptual is different from logical? "Rapaiz" from heaven, I go there to study database, I return later... : P

  • In the sense that what I’m talking about is, conceptual is what it is, I don’t talk about drawing on paper. This is the problem of creating too much academicism, it starts to have too much term, too little concept. Concept is a general idea, anything that goes beyond that I cannot see purpose. Logical model I see, but little used, because it is little needed, and often create an unnecessary burden for the project.

Show 3 more comments

Browser other questions tagged modeling diagram der

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