Antes de aprender SQL, bancos de dados relacional possuem diversos conceitos que devem ser aprendidos e compreendidos primeiro.
A unidade principal por trás de um banco de dados relacional tem como função aumentar a precisão, aumentando a eficiência com que os dados são armazenados. Por exemplo, os nomes de cada uma das milhões de pessoas que imigraram para os Estados Unidos através das Ilhas Ellis durante o século XX foram escritos à mão e guardados em uma grande quantidade de folhas de papel; pessoas da cidade de Londres tiveram seu país de origem definido como Inglaterra, ou Grã-Bretanha, ou Reino Unido ou ainda de alguma dessas formas abreviadas. Múltiplas maneiras de guardar a mesma informação geram confusão quando houver necessidade de saber algo simples como quantas pessoas vieram do país hoje conhecido como Reino.
A solução moderna para esse problema é o banco de dados. Um único registro é dado para cada país, por exemplo, em uma lista de referência que deve ser chamada de tabela de país. Quando alguém precisar indicar o Reino Unido, será necessário apenas ter uma escolha disponível para ela a partir da lista: uma simples lista de letras (ou string), "Reino Unido" como única representação do país, e qualquer outra informação que precisar desse país pode usar o mesmo termo a partir da lista para se referir ao mesmo país. Por exemplo, uma lista com os códigos de telefone do país e uma lista dos castelos europeus, ambos precisam se referir ao país; pelo uso da mesma lista de países para prover informações idênticas para as duas novas listas. Nós estabelecemos um novo relacionamento entre listas diferentes, com apenas um ítem em comum: país. Um banco de dados relacional, assim, é simplesmente uma coleção de listas que distribuem alguma parte da informação.
Bancos de dados armazenam dados de um sistema de informação. Nós reagrupamos dados através de grupos de dados comparáveis (todos os empregados, todos os projetos, todos os escritórios, por exemplo). Para cada grupo de dados comparáveis, é criada uma tabela. Essa tabela é especialmente desenhada para atender esses tipos de dados (seus atributos). Por exemplo, uma tabela nomeada empregados
que guarda todos os empregados seria feita assim:
empregados a tabela
|
id_empregado a chave primária |
um número inteiro
|
primeiro nome uma coluna |
uma string de caracteres uma coluna tipo
|
último nome |
uma string de caracteres
|
telefone |
10 numeros
|
endereço |
uma string de caracteres
|
E os funcionários da empresa seriam armazenados assim:
empregado
|
id_empregado |
primeiro-nome |
último-nome |
telefone |
endereço
|
1 um valor de coluna |
Big |
BOSS |
936854270 |
big.boss@company.com
|
2 |
Jonas |
Xavier |
936854271 |
jonas.xavier@company.com
|
3 |
Linus |
TORVALDS |
936854272 |
linus.torvalds@company.com
|
4 |
Jimmy |
WALES |
936854273 |
jimmy.wales@company.com
|
5 |
Larry |
PAGE |
936854274 |
larry.page@company.com
|
Os dados guardados em uma tabela são chamados entidades. Como uma tabela é usualmente representada como uma matriz, os atributos do dados (primeiro nome, último nome, ...) são chamados colunas e os registros (cada um dos empregados) são chamadas linhas. Uma chave primária é normalmente sublinhada. Qualquer atributo único (por exemplo, o endereço) ou grupo de atributos (como o primeiro nome e o último nome) podem ser a chave primária de uma tabela, mas isso é recomendado para a técnica do id, como no exemplo id_empregado como chave primária. A função da chave primária é simplesmente diferenciar uma das linhas, ou registros, que fazem parte de uma tabela.
Vamos criar um segunda tabela chamada projeto
que guardará os projetos da empresa:
empregado
|
id_empregado |
um inteiro
|
primeiro-nome |
uma string de caracteres
|
último-nome |
uma string de caracteres
|
phone |
10 números
|
endereço |
uma string de caracteres
|
|
projeto
|
id_projeto |
um inteiro
|
nome |
uma string de caracteres
|
data-da-criação |
uma data
|
data-término |
uma data
|
# gerente |
um inteiro
|
|
E os projetos da companhia seriam armazenados no banco da seguinte forma:
empregado
|
id_empregado |
primeiro-nome |
último-nome |
telefone |
endereço
|
1 |
Big |
BOSS |
936854270 |
big.boss@company.com
|
2 |
John |
DOE |
936854271 |
john.doe@company.com
|
3 |
Linus |
TORVALDS |
936854272 |
linus.torvalds@company.com
|
4 |
Jimmy |
WALES |
936854273 |
jimmy.wales@company.com
|
5 |
Larry |
PAGE |
936854274 |
larry.page@company.com
|
|
projetos
|
id_project |
nome |
data-criação |
data-término |
# gerente
|
1 |
Google |
1998-09-08 |
NULL |
5
|
2 |
Linux |
1991-01-01 |
NULL |
3
|
3 |
Wikipedia |
2001-01-01 |
NULL |
4
|
4
|
CRM
|
2015-09-14
|
NULL
|
5
|
|
id_project
é a chave primária da tabela projeto e #gerente é a chave estrangeira. Uma chave estrangeira é uma chave primária de uma tabela, fazendo referência ou ligação com algum valor de outra tabela. Fazendo isso, o projeto Google está conectado ao empregado Larry PAGE. Essa ligação, ou conexão, se chama relacionamento. Uma chave estrangeira é usualmente precedida por um símbolo sharp (cerquilha ou jogo-da-velha '#'). Note que diversos projetos podem apontar para o mesmo gerente (no caso em tela o empregado Larry, id_empregado n.º 5 é gerente dos projetos 1 e 4), então um mesmo empregado pode ser gerente de vários projetos.
Agora, nós queremos criar, não apenas uma única ligação, mas múltiplas. Então criamos uma tabela de junção. Uma tabela de junção é uma tabela que não é usada para guardar dados, mas as ligações entre entidades de outras tabelas. É a tabela onde as ligações, ou relacionamentos, entre as tabelas são guardadas. Vamos criar uma tabela chamada membros
que liga empregados com projeto:
empregado
|
id_empregado |
um inteiro
|
primeiro-nome |
uma string de caracteres
|
último-nome |
uma string de caracteres
|
telefone |
10 numeros
|
endereço |
uma string de caracteres
|
|
membros
|
# id_empregado |
um inteiro
|
# id_projeto |
um inteiro
|
|
projeto
|
id_projeto |
um inteiro
|
nome |
uma string de caracteres
|
data-criação |
uma data
|
data-término |
uma data
|
# gerente |
um inteiro
|
|
E os empregados e os projetos podem ser ligados assim:
empregado
|
id_employee |
primeiro-nome |
último-nome |
telefone |
endereço
|
1 |
Big |
BOSS |
936854270 |
big.boss@company.com
|
2 |
Augusto |
XAVIER |
936854271 |
augusto.xavier@company.com
|
3 |
Linus |
TORVALDS |
936854272 |
linus.torvalds@company.com
|
4 |
Jimmy |
WALES |
936854273 |
jimmy.wales@company.com
|
5 |
Larry |
PAGE |
936854274 |
larry.page@company.com
|
6 |
Max |
THE GOOGLER |
936854275 |
max.the-googler@company.com
|
7 |
Jenny |
THE WIKIPEDIAN |
936854276 |
jenny.the-wikipedian@company.com
|
|
projeto
|
id_project |
nome |
data-criação |
data-término |
# gerente
|
1 |
Google |
1998-09-08 |
NULL |
5
|
2 |
Linux |
1991-01-01 |
NULL |
3
|
3 |
Wikipedia |
2001-01-01 |
NULL |
4
|
4
|
CRM
|
2015-09-14
|
NULL
|
5
|
|
membros
|
# id_empregado |
# id_projeto
|
3 |
2
|
2 |
1
|
4 |
3
|
5 |
1
|
2 |
3
|
6 |
1
|
7 |
3
|
5
|
4
|
|
Um empregado pode estar ligado com vários projetos e um projeto pode ser associado a vários empregados, o que é impossível com apenas uma chave estrangeira. Uma tabela de junção não tem chave primária próprias. Sua chave primária é o par de chaves estrangeiras, pois esse casal é único. Uma tabela de junção pode ligar mais de duas tabelas contendo entidade por mais colunas.
Então vamos listar os diferentes tipos de relacionamento:
- Um para um,
- Um para muitos (como exemplo, o gerente de um projeto),
- Muitos para muitos (como exemplo, os membros de um projeto).