The following database modeling is in my head?

Asked

Viewed 2,348 times

6

I created this modeling (just an idea), so there are no null/white fields.

I have not completely reviewed it. There may be fields that would remain blank. The matrix table was the Entities and through the needs of not having blank fields, the others appeared.

Surely there must be unnecessary fields in some tables, such as who registered/updated and when these actions occurred. I would like someone who understands modeling if it fits my idea and where this I did would harm me in development. Thank you.

Dúvida em ideia de modelagem

  • 1

    I don’t know if it’ll guarantee no white people, but there doesn’t seem to be any need for nulls. I don’t know if you have a specific problem to solve. To me everything seems okay. But just looking at the model does not guarantee that everything is correct. To say if it would harm is more complicated. Not having nulls is something interesting, but it cannot be a goal in itself. http://answall.com/q/2296/101

2 answers

5


Apart from the nomenclature adopted that I do not like, but it is not a problem, does not seem to have errors within the requirement of the question. But if it won’t hurt anything it’s more complicated to say, I don’t know how it will be used.

It is not possible to guarantee that there will not be whites, or even nulls, but the model seems, as far as we can understand, that it helps to avoid null and void.

Which is a good thing, but should not be pursued at all costs.

What I found strange is the address table that can only have one item per entity. Or it would be interesting to put the address in the main table, since there is only one, or if this is wrong, you should take the column out of the table TEntidade relating the address and placing a column in TEndereco that relates to the entity, thus allowing multiple addresses, which I think is the intention.

There is a table that seems to be left over, for example TIE. I don’t see why it exists. But there may be a reason I don’t understand.

Some things seem loose. I see no real links with TEntidadesTipos. It may just be a column name problem, but I also don’t see any connection to TSituacoes.

I may have missed something.

  • hahah really this nomenclature, particularly, gives me goosebumps Srr

1

Nomenclature is equal to toothbrush neh personal? rs. But if there is a pattern I would like to read about.

Maniero

The idea of the table TENDERECOS eh have no duplicates. Incorrectly written there will be, but there will always be people who will correct the correct form. But what if they write Uashinton Soares instead of Washington Soares? We will search by zip code or via programming include addresses that are in the second part of the name or tie by the state zip code, with an option to show all.

The table TIE, State registration, I don’t know if every state has, but I’ve seen Cnpjs who don’t. I, as MEI, don’t have.

It exists to not leave white/null field in TPJ;

I think RG should also make a table a part, because it is a secondary document.

TENTIDADESTIPOS are the types of entities (supplier, customer, consumer, employee, outsourced, etc); TSITUACOES eh on account of the situation of an entity, order, purchase.. may be active, blocked, canceled, pending, closed, open, in transit, delivered... these things.

Browser other questions tagged

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