Modeling of a database

Asked

Viewed 1,630 times

5

I created the following modeling:

inserir a descrição da imagem aqui

Would you like to know what can be improved? leading in good practice considerations for database?

Explanation:

In the TBLogin a person will create a login, which may be PessoaFisica or PessoaJuridica. Note: In this case a PessoaJuridica = Empresa

In the TBPessoas I put the fields that are common to both types of people.

TBEndereco TBCidades TBEstados are for storing the location.

TBVagas related to the TBPessoaJuridica(Company). It would be the vacancies that this person/company would register to disclose.

TBCurriculos All PessoaFisica may have only one curriculum. The curriculum consists of TBIdiomas that in the case would be the languages that the person speaks, there may be + 1.

TBEmpregos It’s a work history of where the person has worked. TBFormacoes They are the formations that a person has. (College/Faculty/Courses) TBTiposFormacoes are the types of training. Ex: (graduate / post-graduate / master / doctorate / high school / etc)

OBS: I’m not very good with modeling, I have little knowledge of relationships of tables and stuff.

2 answers

7


The answer was invalidated by the edition of the question, but it stays here who wants to see on top of the original.

It is always difficult without knowing the real requirements. What can be right in one case can be wrong in another.

I didn’t find any serious mistake, as many models tend to see. Generally I liked everything, even the details, except for prefixing the tables with TB and name tables in plural. Of course, information is scarce. Tables have few columns. What I see is that real registrations usually have more data. But that may not be your case. You may want to expand later. Then the model might start to go wrong. But I can only talk about what I’m seeing now.

What I don’t like but I can’t say is wrong without knowing the details:

  • Having a relationship table of people with addresses depending on whether it is physical or legal. It makes sense to do so but I wouldn’t. I think it’s duplication of effort in most cases.
  • I find it strange shift to be tied to resume, but will know if you have any reason. Maybe it is what turn of interest the person. She might have several, right? Thought about it?
  • Obviously there is a simplification and rigidity of what can be in a resume but I cannot discuss this in the specific case. Even depending on the position it is likely that specific tables may be necessary to inform about certain types of skills. But it’s just my speculation. You can get creative here.

Ah, the positioning of the diagram could give more emphasis to the most important tables and make clearer as satellites the less important, secondary, complementary. But nothing that affects the model, of course.

  • Marginal to your question, but following the bigown’s hint about diagram organization: look for aggregated root, which is a concept that addresses the determination of the 'main' branches'. More geared to when implementing the business rules that will manipulate your data, but obviously helps to organize the diagram.

  • I updated the schematic. and tried to explain more or less how it works.

  • In practice, the simpler the better. Both to understand the dynamics and to bring the relationships of the data. always try to adopt the idea that all MER can always be improved, and that in the future, it should be able to be expanded, so be as abstract as possible, never create unnecessary tables just for the purpose of expanding your architecture, be objective. In general, you can improve... Dry as much as you can. You want to know how to improve, start by making a use case first...

3

From my point of view the model is practically correct.

The only change I would make would be this::

Pessoa -> Endereco (1..N)
Pessoa -> PessoaFisica (1..1)
Pessoa -> PessoaJuridica (1..1)

Thus eliminating the tables :
- TBPessoasFisicas_has_TBEndereco.
- TBPessoaasJuridicas_has_TBEndereco.

After all, person has address, no matter if it is legal or physical.
Thus creating TBPessoa_has_TBEndereco.

I didn’t understand the table of Vagas, related to legal entity, after all you are identifying the person, Vagas would be better related to a table of Empresa, because the company has vacancies.

  • In this case PessoaJuridica = 'Enterprise'

Browser other questions tagged

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