To answer your question in a more didactic way, I’ll take a simpler example of a relationship 1:N.
Imagine that you went to a laundry (shop) to wash your T-shirts and at the time of leaving them you filled out a registration with your personal data and what were your T-shirts.
These data have been stored as follows:
Table Person:
IdPessoa | Nome
1 | HeyJoe
2 | Caique
Table T-shirt:
IdCamiseta | Descricao | IdPessoa
1 | Azul | 1
2 | Amarela | 1
3 | Preta | 2
In the above example it is clear that the blue and yellow shirts belong to the person of IdPessoa = 1
, that is, belong to the HeyJoe
.
We know that T-shirts must have a "owner", a person.
Imagine someone goes in there and erases the person’s record from the database IdPessoa=1
, What will happen to the blue and yellow T-shirts, will stay in the store forever? No.
No, we may own that the records of people who own washing T-shirts are erased to ensure the integrity of the information. For this we must use the foreign keys that will accuse an error when we try to delete a person who owns t-shirts.
See in code:
CREATE TABLE Pessoa(
IdPessoa INT NOT NULL PRIMARY KEY IDENTITY(1,1),
Nome VARCHAR(20) NOT NULL
)
CREATE TABLE Camiseta(
IdCamiseta INT NOT NULL PRIMARY KEY IDENTITY(1,1),
Descricao VARCHAR(20) NOT NULL,
IdPessoa INT NOT NULL
CONSTRAINT FK_Camiseta_Pessoa FOREIGN KEY(IdPessoa) REFERENCES Pessoa(IdPessoa)
)
INSERT INTO Pessoa VALUES ('HeyJoe')
INSERT INTO Pessoa VALUES ('Caique')
INSERT INTO Camiseta VALUES ('Azul', 1)
INSERT INTO Camiseta VALUES ('Amarela', 1)
INSERT INTO Camiseta VALUES ('Preta', 2)
SELECT * FROM Pessoa, Camiseta WHERE Pessoa.IdPessoa = Camiseta.IdPessoa
And what would happen if I tried to delete a person after doing the relationship with FK
:
DELETE Pessoa WHERE IDPessoa = 1
The above operation would be canceled and following error would be displayed:
The DELETE statement conflicted with the REFERENCE Constraint
"Fk_camiseta_pessoa". The Conflict occurred in database "Trading",
table "dbo. T-shirt", column 'Idpessoa'. The statement has been
terminated.
It is possible to carry out queries relating tables that do not have their defined keys, but that is not why we should do them.
The standards exist for one reason and the main reason for the use of FK
is to ensure data integrity, follows another reply who can assist you.
That way you would have to have "n" publisher records for "n" book records, that is, every book you have, you - mandatorily - have to have a record from a publisher for it. This way you will have a lot of duplicated data and will affect performance etc. However, leave this field in the table "book", you only need to have a record in the table "publisher" that it will serve for several books.
– Valdeir Psr
In fact what I question is whether this rule of putting FK in table N is just a matter of standards, some rule/ standard defined by analysts/ programmers.
– HeyJoe
I’ll try to come up with a detailed answer, but I’ll tell you right away, nay Keys don’t just follow rules. In addition to making clear how the relationship of the tables to those who will give maintenance in the future, they also serve to prevent undue actions to be performed, ensuring the integrity of the data.
– Caique Romero
For example, you could quote me an example of a 1:N ratio?
– HeyJoe
I didn’t really get a good example of a 1:N relationship. Since if I am to reason well, I can register the publisher without informing a book, already in the books I need to inform the publisher. If FK is in the publishing table, I must inform the book.
– HeyJoe
Sorry for the delay, I tried to think of a good example to answer your question. xD
– Caique Romero
Come on, you were quick on the trigger!
– HeyJoe