5
I have the following code for creating tables:
CREATE TABLE pessoa (
cod_pessoa int NOT NULL IDENTITY PRIMARY KEY,
nm_pessoa varchar (50) NOT NULL,
tp_pessoa char(1) NOT NULL,
endereco_pessoa varchar(50) NOT NULL,
CONSTRAINT pessoa_tipo CHECK (tp_pessoa = 'F' or tp_pessoa = 'J')
);
CREATE TABLE pessoa_fisica (
cod_pessoaf int NOT NULL PRIMARY KEY,
cpf int NOT NULL UNIQUE,
FOREIGN KEY(cod_pessoaf) REFERENCES pessoa(cod_pessoa)
);
CREATE TABLE pessoa_juridica (
cod_pessoaj int NOT NULL PRIMARY KEY,
cnpj int NOT NULL UNIQUE,
FOREIGN KEY(cod_pessoaj) REFERENCES pessoa(cod_pessoa)
);
My problem is in the tables pessoa_fisica
and pessoa_juridica
. As you can see the table pessoa
has a field indicating its type tp_pessoa
(F for physics and J for legal), I would like to add a CONSTRAINT
or something like that in the tables pessoa_fisica
and pessoa_juridica
that delimites the Foreign Keys only to the correct type of person. Ex (code between **):
CREATE TABLE pessoa_fisica (
cod_pessoaf int NOT NULL PRIMARY KEY,
cpf int NOT NULL UNIQUE,
FOREIGN KEY(cod_pessoaf) REFERENCES pessoa(cod_pessoa) **WHERE pessoa.tp_pessoa = 'F'**
);
You can do it?
One
CHECK CONSTRAINT
would be enough?– Guilherme Portela
@Guilhermeportela How can it be created? I can’t use a subquery inside a Constraint, can I? Or reference columns from other tables? I think it should be something in the Constraint Foreign key itself or a check applied to it, but how?
– Mariana Sempe
@Marianasempe I don’t know if these tables are just to illustrate the need. In being a real need, I would solve with another modeling that dispensed with this type of Constraint.
– Caffé
@Caffé this is the real need! As you suggest?
– Mariana Sempe
@Marianasempe Considering only these fields, you can simply disappear with the tables
pessoa_fisica
andpessoa_juridica
and add a fieldcpf_cnpj
inpessoa
; would be correct because CPF and CNPJ are in fact the same type of information (unique national identification of a person). If the other fields of these two tables arerg
andinscricao_estadual
, does not yet justify the complexity of the new tables. Note that some companies are exempt from state inscr.and some people use other identification than RG; these Docs are only attributes and not part of a person’s identity.– Caffé
@Marianasempe If there are many more exclusive fields for
pessoa_fisica
orpessoa_juridica
, inform in your question that will help suggest a modeling.– Caffé
@Caffé could have several (this is a work), the problem is that it needs to show normalization (here 2FN) so of the two tables. I only put Cpf/cnpj to simplify the registration later.
– Mariana Sempe
@Marianasempe I understand... Solving a problem that does not exist is more difficult. It is difficult to normalize person because it is very simple. Perhaps you can choose an entity easier to normalize, and the easiest to exercise normalization is with complex entities. A "client", for example, could have category, type of relationship, % allowed income commitment... And some of these attributes may be related in order to give rise to new tables, facilitating the demonstration of normalization.
– Caffé