Ligações de 1 para N em Bancos de Dados

Prévia do material em texto

Capitulo 1 - Entendendo ligações de 1 para N
Seguindo com nosso aprendizado do modulo anterior, iremos ver os modos de ligação entre as tabelas de um banco de dados.
Iremos iniciar com o método considerado o mais usado nos banco de dados, o modelo de 1 para N (um pra muitos ou em inglês: One to many). Este modo, consiste em ligações entre tabelas no formato de um registro de uma tabela tem relevância para vários registros de outra tabela. Segue uma figura ilustrativa abaixo:
	O exemplo acima mostra duas tabelas cuja função é gerir as apostilas de uma escola. 
Começando pela tabela Apostila:
· Codigo_Turma: É o código que está presente nas duas tabelas e faz a ligação entre elas, sendo neste caso do tipo Numérico Inteiro (Integer).
· Preço: O campo preço tem a função de armazenar o valor pelo qual a apostila será vendida, sendo neste caso do parâmetro Numérico (Float).
· Descrição: Neste campo se colocaria uma breve descrição da apostila para facilitar a identificação entre elas, usaríamos o campo de Texto (Varchar).
Continuando pela tabela Turma: 
· Código: Código de identificação da Turma, também serve como link entre esta tabela e a tabela Apostila.
· Descrição: Breve descrição sobre as turmas que facilita a identificação das mesma.
Como podemos ver o campo “Codigo_Turma” da tabela “Apostila” e o campo “Codigo” da tabela “Turma” tem uma relação de 1:N. Citaremos o exemplo abaixo que demonstra de forma visual:
	Tabela: Apostila
	Codigo_Turma
	Preço
	Descrição
	1
	10,00
	LING C
	1
	13,00
	Windows
	2
	17,00
	Linux
	Tabela: Turma
	Código
	Descrição
	1
	TIN1
	2
	TIN3
	3
	TIN2
Como vemos no exemplo acima, as apostilas de “LING C” e “Windows” estão com a marcação do numero 1, ou seja, olhando quem é o numero 1 na tabela turma, concluímos que as apostilas de Windows e LING C pertencem a turma do TIN1.
Podemos ver então que a tabela “Apostila” esta se repetindo os números referentes na tabela Turma e na tabela Turma os códigos não se repetem. Com isso podemos dizer que a tabela “Apostila” corresponderia ao “N” e a tabela “Turma” coresponderia ao “1”.
Chaves unitária
A chave unitária é o indexador principal de uma tabela. Este indexador consiste em uma sequencia de números gravados em uma coluna da tabela que corresponde ao 1 das conexões entre as tabelas. No exemplo acima o campo que possui a chave unitária é o campo “Codigo” da tabela “Turma”.
Esta chave unitária normalmente trata-se de uma numeração sequencial feita automaticamente pelo sistema do banco de dados. Logo quando cadastramos novos registros nessa tabela não necessitamos colocar o numero, deixamos em branco para que o próprio sistema preencha para nós o valor, assim evitando que, no ato do cadastro, seja registrado um numero que já tenha sido usado. 
Este método automático também previne possíveis referências erradas, pois se apagarmos algum registro na nossa tabela e cadastrarmos outro, o numero indexador não se repetirá. Exemplificando de forma pratica, em nossa tabela, caso apaguemos o registro de numero 2, o TIN 3, o registro de numero 3, o TIN 2, não passara a ser o numero 3, e se cadastrarmos um registro novo, ele virá com o índice 4. 
Isso funciona para evitar possíveis conflitos, pois mesmo que apaguemos este registro, os outros que fazem referência a ele, e que por ventura não foram corrigidos, não façam referencia a nada, mostrando que houve um erro, ao invés de fazer referencia a um registro errado.
Chave Estrangeira
As chaves estrangeiras são o oposto da chave unitária e agem como um complemento de ligação entre a tabela que contem a chave unitária e a tabela que contem a chave estrangeira.
O funcionamento da chave estrangeira define que registro de uma tabela esta ligado a que registro de outra tabela, porem, diferente da chave unitária, a chave estrangeira não é automática, pois seu funcionamento consiste em justamente fazer uma referencia a outra tabela, logo quando inserimos um registro novo na tabela que contem a chave unitária, nós temos que saber o valor que devemos colocar no campo que corresponde a chave estrangeira.
Utilizando nosso exemplo, temos a tabela “Apostila”, que contem os dados sobre as apostilas nós temos a coluna “Codigo_Turma” que contem um numero que faz uma referencia a uma chave unitária da tabela “Turma” logo esta coluna “Codigo_Turma” é uma chave estrangeira.
Observação importante: Caso um registro que contenha uma chave unitária seja deletada, todos os registros que façam referencia a ela, ou seja chaves estrangeiras, devem ser corrigidos ou deletados. Exemplificando, caso o registro de numero 2 na tabela “Turma” seja deletado, o registro “LINUX” fará referência a nenhuma turma, logo este registro teria que ser modificado ou deletado,para evitar quaisquer inconsistência ou informação errada gravada no sistema.
Entendendo ligações de 1 para N
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. O que você entende por ligações de 1 para N?
2. Defina chave Unitária.
3. Defina chave Estrangeira.
4. Em uma chave unitária ou estrangeira, qual é o tipo de variável utilizado para criar este campo em uma tabela?
5. Caso façamos modificações nas nossas tabelas que afetem nossas chaves estrangeiras ou unitárias, que precauções devemos tomar para não impactar em todo nosso sistema?
Atividade Pratica: 01
1 – Utilizando o DBDesigner faça uma modelagem que corresponda ao desenho abaixo:
	
	Tabela: Classe
	ID
	Nome
	ID_ADM
	ID_Area
	Quant
	1
	TIN1
	1
	2
	20
	2
	TIN2
	2
	2
	15
	3
	TIN3
	2
	2
	18
	4
	TME1
	1
	1
	14
	5
	TME2
	2
	1
	20
	6
	TME3
	3
	1
	14
	Tabela: ADM
	ID
	Tipo
	1
	Bruno
	2
	João
	3
	Maria
	4
	Suzane
	Tabela: Area
	ID
	Marca
	1
	Indústria
	2
	Escritório
 
Capitulo 2 - Entendendo ligações de 1 para 1
Seguindo nosso estudo sobre os métodos de relacionamento utilizados em bancos de dados, vamos ao próximo passo, o método de ligação 1:1 ou um para um.
Este método de ligação consiste em interligar duas bases de dados através de uma chave que deve fazer referencia nas duas tabelas, assim como a ligação de 1:N com sua chave estrangeira e unitária, porem com a diferença de que a mesma não se repete em nenhum dos dois lados. 
O sistema de ligações entre tabelas 1:1 tem a função de interligar tabelas do banco de dados de forma que apenas um registro de cada tabela fique vinculado com um registro de outra tabela.
Mas qual a utilidade deste tipo de vinculo? Bom inicialmente temos a impressão de que este tipo de ligação não tem nenhuma utilidade aparente, porem, com ele podemos interligar duas tabelas de conteúdos diferentes com menos modificações, facilitando a montagem do bando de dados e sua manutenção.
Vamos seguir nossas explicações com um exemplo: Suponhamos que estamos ha fazer um sistema de gestão para um hotel, onde cada quarto é representado por um registro, ao cadastrar um novo cliente em sua respectiva tabela, temos que vinculá-lo a tabela que contem os quartos, com isso este vinculo é feito utilizando o método 1:1 segue imagem de referencia.
Abaixo segue a descrição de cada um dos seus campos, começaremos pela tabela Clientes.
· ID: Identificação numeral de cada registro na tabela serve para identificar cada registro de forma única e interligar com outras tabelas. Tipo: Numérico.
· Nome: É o local onde se registra o nome do cliente para identificação do mesmo. Tipo: Texto ou Varchar.
· Endereço: É o local onde se registra o endereço do cliente para possíveis consultas do mesmo. Tipo: Texto ou Varchar.
· Telefone: É o local onde se registra o telefone do cliente para possíveis consultas e contatos do mesmo. Tipo: Texto ou Varchar.
Agora iremos para a tabela Quartos:
· ID: Identificação numeral de cada registro na tabela serve para identificar cada registro de forma única e interligar com outras tabelas. Tipo: Numérico.
· ID_Cliente: Identificação numeral para referencia 1:1 com a tabela Clientes, utilizado como chave estrangeira.Tipo: Numérico.
· Descrição: É o local onde se registra uma breve descrição dos quartos para facilitar identificação do mesmo. Tipo: Texto ou Varchar.
· Valor: Local onde se registra o valor a ser cobrado pela locação do quarto. Tipo: Numero com ponto flutuante ou Float.
Bom como podemos ver a tabela tem uma conexão onde as informações de uma tabela não podem se repetir na referencia da outra tabela, afinal, é impossível que o mesmo cliente ocupe mais de um quarto, nem dois clientes diferentes ocupem o mesmo quarto. Logo em um exemplo pratico podemos fazer o seguinte preenchimento para esta tabela.
	Tabela: Quartos
	ID
	Valor
	Descricao
	ID_Cliente
	1
	50,00
	Classe C
	2
	2
	100,00
	Classe B
	3
	3
	250,00
	Classe A
	1
	Tabela: Clientes
	ID
	Nome
	Endereco
	Telefone
	1
	João
	Santos
	123-4456
	2
	Maria
	São Paulo
	555-6789
	3
	Pedro
	Guaruja
	998-7667
Como vemos no exemplo pratico acima, os clientes estão relacionados com os quartos de forma única, não existindo mais de um cliente no mesmo quarto nem o mesmo cliente em vários quartos, isso constitui um caso de relacionamento de 1:1.
Quebrando tabelas grandes
Uma coisa importante a se lembrar sobre este tipo de relacionamento é que ele tem uma outra função alem de relacionamento entre dados de tabelas como descrito acima. Ele também é usado para possibilitar ao programador quebrar uma tabela que possua muitos campos e varias tabelas com menos campos. Qual a utilidade disso? Simplesmente velocidade. As consultas a estes dados ficam muito mais rápidas e eficientes, pois tem que lidar com bem menos nados do que se existisse uma única tabela com muitos campos.
Chave estrangeira e chave unitária
Como vimos no capitulo anterior, a chave estrangeira de uma tabela é a que faz referencia a outra tabela, e a unitária e a que é referenciada em outra tabela, logo esta regra vale para nosso sistema de 1:1. A chave estrangeira corresponde a coluna ID_Cliente da tabela Quartos e a chave unitária corresponde a ID da tabela Clientes. Porem com a diferença de que a chave estrangeira não pode ser referenciada mais de uma vez em uma tabela que possua o relacionamento 1:1.
Por fim vamos ver como ficaria no DBDesigner:
Entendendo ligações de 1 para 1
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. O que você entende com relação 1:1?
2. Cite situações onde a relação de 1:1 normalmente é utilizada?
3. Neste tipo de relação, existem chaves estrangeiras e unitárias, qual há diferença entre elas e as utilizadas nas relações 1:N?
4. Ao quebrarmos uma grande tabela, temos varias vantagens, quais as principais?
5. Qual o tipo de campo que utilizamos normalmente para fazer as chaves estrangeiras e unitárias?
Atividade Pratica: 02
1 – Utilizando o DBDesigner faça uma modelagem que corresponda ao desenho abaixo: 
DICA: A relação de 1:1 e de 1:N e falta colunas em alguma/s das tabelas abaixo.
	Tabela: Clientes
	ID
	Nome
	Endereço
	Telefone
	1
	Bruno
	São Vicente
	555-8595
	2
	João
	Santos
	555-4785
	3
	Maria
	Praia Grande
	555-6252
	4
	Suzane
	Santos
	555-5110
	Tabela: filmes
	ID
	Filme
	1
	Senhor dos anéis
	2
	Jogos Mortais
	3
	Super Bad
	4
	Harry Potter
 
	Tabela: categorias
	ID
	Categoria
	1
	Fantasia
	2
	Comedia
	3
	Drama
Capitulo 3 - Entendendo ligações de N para N
A próxima ligação que iremos ver em nossos estudos é a ligação de N para N ou de “muitos para muitos”. Esta ligação nada é a mais complexa e elaborada, tendo detalhes que são cruciais para seu entendimento pleno.
Este relacionamento consiste em ter ilimitados registros em uma tabela relacionados com ilimitados registros de outra tabela. Complicado? Vamos tentar simplificar mais. Este relacionamento é usado quando queremos que a tabela A se relacione a tabela B sem nenhuma restrição de quantidades. Ainda complicado? Vamos a um exemplo:
Imaginemos que temos uma tabela chamada “produtos” e uma tabela chamada “fornecedores”. Para cada produto pode haver vários fornecedores, e cada fornecedor pode fornecer vários produtos, fazendo assim com que a tabela se relacione de forma completa entre as partes.
Para que isso possa ocorrer, é impossível que haja apenas as duas tabelas se inter-relacionando, devido a uma limitação da própria construção do conceito tabela. O que precisamos para fazer este relacionamento funcionar é uma tabela de ligação.
Tabela de ligação
A tabela de ligação nada mais é do que uma tabela que tem a função única de relacionar as duas tabelas principais, agindo como eixo entre as duas.
Como dito anteriormente, é impossível que se faça este relacionamento sem o uso da tabela de ligação. O desenho abaixo vai simplificar seu uso.
	Tabela: Produto
	ID
	Produto
	1
	Impressora
	2
	Computador
	3
	Câmera Digital
	4
	Smartphone
	Tabela: Fornecedor
	ID
	Fornecedor
	1
	Loja Joãozinho
	2
	Loja Roberto
	3
	Loja Aguia
	4
	Loja Tigre
 
	Tabela: For_Prod
	ID_Fornecedor
	ID_Produto
	1
	1
	2
	1
	2
	2
	1
	3
Vendo as tabelas desenhadas, podemos entender melhor seu funcionamento.
A tabela “For_Prod” tem este nome como uma junção da palavra “Fornecedor“, vindo de uma das tabelas, e da palavra “Produto”, vindo do nome da outra tabela. Este nome se deve ao fato de ela fazer a junção entre as tabelas e não é nenhum padrão regulamentado, porem se recomenda que, ao montar suas tabelas, faça o em algum padrão facilmente reconhecível.
Vendo o conteúdo da tabela “For_Prod” podemos entender sua intenção, ela pode relacionar de forma indefinida quantos produtos eu quiser há apenas um fornecedor, e pode relacionar quantos fornecedores eu quiser há a apenas um produto, e isso caracteriza uma junção N:N.
DBDesigner 
O DBDesigner nos fornece uma grande facilidade na montagem da tabela que queremos montar. Ele já monta a tabela de ligação para você automaticamente!
Sim, exatamente isso, ele monta a tabela de ligação sem precisar intervir, de forma simples e direta.
Como fazer isso?
Vamos partir do ponto que já temos as tabelas criadas, como mostra a imagem abaixo:
Para utilizar a ligação desejada, é necessário que clique no botão “new N:M”, da figura abaixo:
Ao clicar no botão, deve-se clicar nas duas tabelas, neste caso não faz diferença em qual das duas você toca primeiro, já que as duas são “N”, nenhuma é diferenciada da outra. A única diferença relevante é que o primeiro que você clica vai ser o primeiro que será referenciado, o que na pra tica não faz diferença.
Seguindo nosso raciocínio, após o clique, a tabela se forma na tala, podendo ser editada e alterada após sua criação. Como mostra a figura abaixo:
Como podemos ver, criou-se uma nova tabela automaticamente, já com os campos que indexam nossas tabelas de forma direta.
IMPORTANTE
Reparou que a marcação que liga as tabelas é a mesma da ligação “1:N“? Exatamente isso, as tabelas que você criou tem uma relação de 1:N com a tabela de ligação, e o conjunto forma uma relação de N:N. Logo entende-se que para criar uma relação de N:N sempre é necessário uma tabela de ligação e um relacionamento entre as tabelas principais e esta é a relação de 1:N.
Mas como ele sabe que usarei o ID? Simples, na hora que criou-se as tabelas Fornecedor e Produto, ao criar o campo ID, foi dito que estes campos eram PRIMARIOS, logo eles são os normalmente utilizados para este tipo de relacionamento.
Porem é possível Mudar esta isso, clicando duas vezes na tabela criada e editando os campos, como indicado na tabela abaixo:
Entendendo ligações de N para N
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. O que você entende com relação N:N?
2. Na pratica, como diferenciamos as relações de N:N das de 1:N?
3. Para que serve a tabela de ligação?
4. No DBDesigner devemos criar a tabela de ligação? Por que?
5. Quando nossa tabela de ligação esta criada, podemos perceber que elatem um outro tipo de relacionamento com as tabelas principais, e que o conjunto gera uma relação de N:N, qual o relacionamento e por que ele é usado desta forma?
Atividade Pratica: 03
1 – Utilizando o DBDesigner faça uma modelagem que corresponda ao desenho abaixo: 
DICA: A relação é de N:N, a tabela de ligação precisa ser criada e não esta descrita abaixo.
	Tabela: Clientes
	ID
	Nome
	Endereço
	Telefone
	1
	Bruno
	São Vicente
	555-8595
	2
	João
	Santos
	555-4785
	3
	Maria
	Praia Grande
	555-6252
	4
	Suzane
	Santos
	555-5110
	Tabela: filmes
	ID
	Filme
	1
	Senhor dos anéis
	2
	Jogos Mortais
	3
	Super Bad
	4
	Harry Potter
 
Capitulo 4 - N para N e 1 para N juntas
Após vermos todas 3 formas possíveis de ligação entre tabelas de um banco de dados, vamos ver agora algumas junções entre elas, que nos possibilitam uma gama muito maior de possibilidades.
Vamos ver a relação “N para N” e “1 para N” trabalhando juntas para nos possibilitar uma integração maior de nosso banco, nos proporcionando economia de espaço e tempo em nosso trabalho.
Como vimos no capitulo anterior, a relação “N para N” é na verdade, em seu entendimento interno, duas relações de “1 para N” com uma tabela de ligação. Graças a isso podemos interagir com o banco de dados pela relação “N para N”. Para fins organizacionais vamos chamar a relação de “N para N”.
Vamos colocar uma situação hipotética. Pegaremos os dados do exemplo do capitulo anterior, onde tínhamos N fornecedores para N produtos, que nos forçou a criar a tabela de ligação. Mas agora acrescentaremos uma nova tabela, onde será listado em que unidades de nossa franquia de lojas os produtos são vendidos e por qual preço. Veja o modelo conceitual abaixo:
Veja como cresceu nosso pequeno projeto. Agora possuímos uma nova ligação na tabela produtos. 
A tabela “Loja” possui o campo indexador “ID_Produto” que proporciona uma referencia a tabela “Produtos”, logo criando uma conexão de 1 para N com a mesma, aumentando nossa gama de informação.	
A tabela “Fornecedor” nada tem haver com a tabela “Loja”, porem caso seja necessário, utilizando uma boa lógica, poderíamos saber em que loja um fornecedor é mais usado que outra, e assim reduzir custos com o transporte da mercadoria, podendo assim vender mais em menos tempo.
Da maneira como está descrito acima, podemos ver que é possível construir indefinidas ligações, de forma a complementar e atualizar nosso projeto, e assim criando uma ferramenta funcional e totalmente utilizável.
Segue abaixo uma tabela preenchida de exemplo para melhor compreensão.
	Tabela: Fornecedor
	ID
	Fornecedor
	1
	Loja Joãozinho
	2
	Loja Roberto
	3
	Loja Aguia
	4
	Loja Tigre
	Tabela: Produto
	ID
	Produto
	1
	Impressora
	2
	Computador
	3
	Câmera Digital
	4
	Smartphone
	Tabela: For_Prod
	ID_Fornecedor
	ID_Produto
	1
	1
	2
	1
	2
	2
	1
	3
 
	Tabela: Loja
	ID
	ID_Produto
	Loja
	Preço
	1
	1
	São Vicente
	10,00
	2
	2
	Santos
	15,00
	3
	2
	Cubatao
	14,00
	4
	3
	Santos
	12,00
Como podemos ver as tabelas se relacionam, proporcionando um poder de pesquisa muito maior ao nosso banco, como por exemplo, se quisermos saber em que loja um fornecedor vende mais, podemos fazer a pesquisa dos produtos e depois da loja, entre muitas outras pesquisas que podem ser imaginadas. Os filtros são ilimitados se houver informações suficientes.
Outra possibilidade seria de descobrir em que loja um produto vende mais ou menos, e depois tentar negociar um bom preço com este fornecedor. Também nos possibilita descobrir se um fornecedor esta “dominando” uma loja nossa com maioria de seus produtos, o que nos da condições de negociação de melhores preços ou de troca deste fornecedor por um mais barato.
DBDesigner
Vamos agora passar nosso projeto para o DBDesigner, será bem mais simples a compreensão vislumbrando nosso projeto.
Utilizaremos os mesmos comandos que sempre usamos para o DBDesigner, como o botão de criação de relações de N para N e de 1 para N.
Gostaria de lembrar que o botão de 1 para N tem um funcionamento peculiar, quando for clicar nas tabelas, a primeira deve ser a que corresponde ao 1.
Começaremos com a criação das tabelas como mostra a figura abaixo:
Veja que não criei o campo “ID_Produto” na tabela “Loja” pois no momento que clicamos com o botão de relação de 1 para N o campo se cria automaticamente assim como a tabela auxiliar para a ligação de N para N. Vide figura abaixo:
Vejam só, com apenas os cliques foi criada a tabela de ligação com o nome “Fornecedor_has_Produto” e na tabela “Loja” foi criado o campo “Produto_ID”. Os nomes ficaram um pouco diferentes do planejado, porem isso não faz diferença na pratica, logicamente caso deseje manter os nomes sugeridos pelo programa é uma escolha de vocês. Caso queira arrumar os nomes, pode-se clicar duas vezes em cada tabela e arrumar seus nomes. 
O mesmo vale para os nomes das ligações, que podem ser dados conforme sua vontade e necessidade.
Com o projeto pronto, podemos exportá-lo para qualquer banco de dados ou fazer manualmente, o importante é a lógica para seu funcionamento estar correta que o resto e facilmente traspassável.
Capitulo 4 - N para N e 1 para N juntas
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. Em uma relação, é possível que conectemos uma outra relação? Justifique o motivo.
2. Quais são os 3 tipos de relação que podemos ter, explique-as.
3. Cite o motivo de termos uma relação de N para N junto com uma de 1 para N.
4. É possível construir muitas conexões diferentes no mesmo banco? Justifique com um motivo.
5. O DBDesigner tem a possibilidade de criação de tabelas com interligações diferentes entre si? Como?
6. 
Atividade Pratica: 04
1 – Utilizando o DBDesigner faça uma modelagem que corresponda ao desenho abaixo: 
DICA: A relação é de N:N e 1:N, a tabela de ligação precisa ser criada e não esta descrita abaixo.
	Tabela: Clientes
	ID
	Nome
	Endereço
	Telefone
	1
	Bruno
	São Vicente
	555-8595
	2
	João
	Santos
	555-4785
	3
	Maria
	Praia Grande
	555-6252
	4
	Suzane
	Santos
	555-5110
	Tabela: filmes
	ID
	Filme
	1
	Senhor dos anéis
	2
	Jogos Mortais
	3
	Super Bad
	4
	Harry Potter
 
	Tabela: Locadora
	ID
	ID_Filmes
	Cidade
	QTD
	1
	1
	Santos
	3
	2
	1
	Praia Grande
	4
	3
	2
	São Vicente
	4
	4
	3
	Cubatão
	6
	
Capitulo 5 - Relações avançadas
Seguindo nossas analises avançadas sobre relacionamento entre tabelas, vamos ver as ligações restantes. N:N e 1:1, 1:1 N:1.
N:N e 1:1 juntas.
Como sabemos a ligação de N:N serve para relacionar ilimitados registros de uma tabela com ilimitados registros de outra tabela. Até ai tudo bem, mas o que você entende como relacionamento 1:1?
Se você respondeu extensão dos dados acertou. Um relacionamento de 1:1 tem o intuído de criar uma nova tabela para complementar uma já existente, como se novos registros fossem necessários para o funcionamento de nosso sistema, e nós decidimos que seria melhor não estender a tabela existente e criar uma nova, assim criando um relacionamento de 1:1.
Porem o que os dois fazem juntos? Suas funções como foram designadas. O N:N faz sua ligação ilimitada entre duas tabelas e o 1:1 estende uma de suas tabelas.
Vamos citar um exemplo já citado em outros capítulos. Temos uma loja onde devemos armazenar produtos em uma tabela e fornecedores em outra, no formado de um relacionamento N:N. Porem com o tempo, surgiu a necessidade de implementar mais informações sobre os fornecedores e não se quis modificar uma tabela existente, decidiu-se criar uma nova e relacioná-la de forma 1:1. 
	Tabela: Fornecedor
	ID
	Fornecedor
	1
	Loja Joãozinho
	2
	Loja Roberto
	3
	Loja Aguia
	4
	Loja Tigre
	Tabela: Produto
	ID
	Produto
	1
	Impressora
	2
	Computador
	3
	Câmera Digital
	4
	Smartphone
	Tabela: For_Prod
	ID_Fornecedor
	ID_Produto
	1
	1
	2
	1
	2
	2
	1
	3
 
	Tabela: Cont_Fornecedor
	ID_Fornec
	Endereco
	TelefoneCidade
	1
	R: P. Wilson
	(13)1597532
	SV
	2
	R:C.Rodriges
	(12)4569878
	SV
	3
	AV:P.Kenedy
	(11)1588963
	PG
	4
	R:C.Santos
	(16)5559877
	SV
Como vimos no exemplo acima, a tabela “Cont_Fornecedor” possui um campo chamado “ID_Fornec”. Este campo liga a mesma ha tabela “Fornecedor” em uma relação de 1:1
E claro, como já foi explicado anteriormente mas vale a ressalva, a relação de N:N gera a tabela de ligação “For_Prod”.
Vemos abaixo como ficaria no DBDesigner.
Uma observação, ou melhor, lembrança: Na tabela “Cont_Fornecedor” não se cria a coluna “Fornecedor_ID”. Quando se clica para fazer a relação de 1:1 ela se cria automaticamente.
1:1 e N:1 Juntas.
Ha ultima dupla que falta falarmos é esta. O que entendemos na relação 1:1? Como discutimos anteriormente, ela fornece um tipo de ligação que complementa os dados de uma tabela. 
E a relação de N:1? Bom, já vimos anteriormente, porem vamos relembrar. A relação de N:1 cria entre duas tabelas um tipo particular de dependência, onde um único registro de uma tabela pode ser referenciado em vários de outra, como no exemplo das apostilas, onde a tabela que armazena a lista de apostila pode referenciar a mesma turma para varias apostilas vide abaixo:
	Tabela: Apostila
	Codigo_Turma
	Preço
	Descrição
	1
	10,00
	LING C
	1
	13,00
	Windows
	2
	17,00
	Linux
	Tabela: Turma
	Código
	Descrição
	1
	TIN1
	2
	TIN3
	3
	TIN2
 Nada complicado correto? Bom então o que tem de mais em união das duas relações?
Nada! Simples assim. Assim como a relação N:N com 1:1, a relação 1:1 com N:1, não fornece nada alem de suas funções básicas trabalhando juntas para aumentar o poder de um banco de dados.
Vamos pegar o exemplo de 1:N e aplicarmos uma nova tabela com relacionamento de 1:1.
	Tabela: Turma
	Código
	Descrição
	1
	TIN1
	2
	TIN3
	3
	TIN2
	Tabela: Apostila
	ID
	Codigo_Turma
	Preço
	Descrição
	1
	1
	10,00
	LING C
	2
	1
	13,00
	Windows
	3
	2
	17,00
	Linux
	Tabela: Cont_Apostila
	ID_Apostila
	Autor
	N_Pags
	1
	João
	50
	2
	Maria
	40
	3
	Pedro
	45
	
Vemos acima uma possível relação entre três tabelas. A tabela “Apostila” se relaciona com a tabela “Turma” no formato 1:N onde é possível referenciar a mesma turma varias vezes na tabela “Apostila” pelo campo “Codigo_Turma”.
Já com a tabela “Cont_Apostila” temos um relacionamento de 1:1 com a tabela “Apostila” através do campo “ID” da tabela “Apostila” e do campo “ID_Apostila” da tabela ”Cont_Apostila”.
Vemos abaixo um exemplo em DEDesigner.
 
Algumas ressalvas para lembrá-los sobre como criar coisas no DBDesigner.
· Lembre-se que quando criamos um relacionamento de 1:N, temos que clicar primeiro na tabela que corresponderia ao “1”. 
· Em um relacionamento de 1:N não devemos criar o campo que corresponde ao campo “Turma_Codigo” do exemplo acima, pois este campo é criado automaticamente no ato da criação da relação.
· Ao criar uma relação 1:1, quando criamos uma nova tabela para complementar a que já existe, não devemos criar o campo “Apostila_ID” pois o mesmo e criado quando fazemos a relação.
· No relacionamento de 1:1, o primeiro a ser clicado deve ser o que já existe, e o segundo o que foi criado agora.
Capitulo 5 – Relações Avançadas
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. Quando criamos uma relação de 1:1, qual nosso objetivo?
2. No relacionamento conjunto N:N com 1:1, temos um objetivo, qual é este objetivo?
3. No relacionamento conjunto N:1 com 1:1, temos um objetivo, qual é este objetivo?
4. Ao criar nossos projetos no DBDesigner, temos que clicar na ordem correta para criar relações de 1:N. Qual esta ordem e por que ela é necessária.
5. Ao criar nossos projetos no DBDesigner, temos que clicar na ordem correta para criar relações de 1:1. Qual esta ordem e por que ela é necessária.
Atividade Pratica: 05
1 – Utilizando o DBDesigner faça uma modelagem que corresponda ao desenho abaixo: 
DICA: A relação é de N:N e 1:1, a tabela de ligação precisa ser criada e não esta descrita abaixo.
	Tabela: Clientes
	ID
	Nome
	Endereço
	Telefone
	1
	Bruno
	São Vicente
	555-8595
	2
	João
	Santos
	555-4785
	3
	Maria
	Praia Grande
	555-6252
	4
	Suzane
	Santos
	555-5110
	Tabela: filmes
	ID
	Filme
	1
	Senhor dos anéis
	2
	Jogos Mortais
	3
	Super Bad
	4
	Harry Potter
 
	ID_Filmes
	Fabricante
	QTD
	1
	New Line
	3
	2
	Evolution Entertainment
	4
	3
	Columbia Pictures
	4
	4
	 Warner Bros
	6
Capitulo 6 - Continuação Ligações avançadas
Seguiremos para o ultimo capitulo estudado de nosso material teórico sobre bancos de dados.
Neste capitulo introduziremos rapidamente o método de comunicação com bancos de dados chamado SQL.
SQL (Structured Query Language) ou linguagem de consulta estruturada é uma linguagem utilizada para comunicação entre software e bancos de dados relacionais declarada padrão no mercado. 
Esta linguagem vem de meados de 1970 pela IBM, em uma época em que bancos de dados relacionais eram apenas projetos.
Esta linguagem é um grande padrão no mercado, devido a ser extremamente simples e de fácil entendimento. Sendo assim, ela possui grandes adeptos e com o tempo todas as grandes plataformas de Bancos de dados adotaram seus preceitos de funcionamento.
Após sofrer varias revisões ao decorrer de sua existência, sendo a ultima em 2003, hoje seu padrões são geridos pela ISO ( International Organization for Standardization), facilitando muito sua padronização.
O SQL possui uma vantagem muito grande, quase todos os sistemas de bancos de dados que existem conseguem trabalhar com ele sem muitas diferenças entre si, ou seja, muito pouco é mudado e adaptado para cada sistema.
Suponhamos que temos um código escrito para o Oracle da empresa Oracle Corporation, e queremos que rode em um SQL Server, da Microsoft, com poucas adaptações e possível se fazer entender entre eles.
OBS: O nome do SQL originalmente era SEQUEL e por isso até hoje a sigla em inglês é pronunciada SÍ-QUE-EL.
FIREBIRD
Firebird é um servidor de bancos de dados gratuito que obedece as regras do OpenSource, ou seja, é livre para baixar, modificar seu código e redistribuir.
O Firebird e mantido pela Fundação FirebirdSQL, funcionando a base de doações e sem fins lucrativos. 
Apesar de ser mantido por uma instituição, o Firebird foi criado apartir de um software que começou sua vida fechado, o InterBase da Borland, porem a empresa decidiu abrir o código de seu sistema de bancos de dados. Graças a esta abertura o Firebird pode ser desenvolvido, se baseado neste código, que já era ultrapassado. Temos muito a agradecer por isso, pois graças ao InterBase, hoje temos um ótimo servidor de banco de dados gratuito para uso acadêmico e profissional.
SQL
Por que estamos falando de Firebird afinal? Estamos falando dele porque em nossos estudos sobre a linguagem SQL, estudaremos a versão presente nele, e testaremos nele.
Vamos entender rapidamente como os 4 comandos básicos de interação com o banco de dados funciona.
Consulta
A consulta, como o próprio nome nos diz, tem a função de trazer das tabelas dos bancos informações que nos são importantes.
Para simplificar nossa explicação, teremos um exemplo de uma tabela:
	Tabela: Clientes
	ID
	Nome
	Endereço
	Telefone
	1
	Bruno
	São Vicente
	555-8595
	2
	João
	Santos
	555-4785
	3
	Maria
	Praia Grande
	555-6252
	4
	Suzane
	Santos
	555-5110
Bom, vamos lá, para selecionar todas as informações o comando seria:
SELECT * FROM Clientes;
Explicando rapidamente o comando:
· SELECT: Comando básico para seleção.
· *: Indica quais colunas vão ser retornadas.
· FROM: Comando que inicia qual tabela será usada.
· Clientes: Indica o nome da tabela que retornará.
Mais alguns exemplos de seleção:
SELECT Nome, Endereco FROM Clientes;
SELECT * FROM Clientes WHERE Nome = ‘Bruno’;
Opa! Tem um comando novo, o comando WHERE. Este comando tem a função de definir alguma clausula para nosso retorno. No caso temos a clausula(Nome=’Bruno’) que quer dizer que só serão retornadas aqueles registros cujo nome seja bruno.
Inserção
Inserir registros novos é bem mais simples. Vamos nos basear no nosso exemplo anterior e ver o comando:
INSERT INTO Clientes (Nome, Endereco, Telefone) VALUES (‘Eduardo’, ‘Mongagua’, ‘(13) 44334434’);
Bom, vamos analisar este comando:
· INSERT INTO: Comandos que indica que fará uma inserção de novos registros na tabela.
· Clientes (...): Nome da tabela e em seguida, entre parênteses, os nomes das colunas que deseja que seja feita a inserção;
· VALUES (...): Comando que indica quais valores que serão inseridos e em seguida, entre parênteses os valores separados por vírgulas na ordem igual ao parêntese anterior.
Deletar
Para deletar registros de uma tabela também é extremamente simples, basta seguir o modelo que tudo funcionará perfeitamente.
DELETE FROM Clientes WHERE ID = 1;
Vamos analisar o comando:
· DELETE FROM: Comando que indica que será uma ordem de exclusão na tabela.
· Clientes: A tabela onde será feita a exclusão de registros.
· WHERE ID = 1: Indica as condições que se seguem para haver a exclusão. Neste exemplo serão excluídos todos os registros que tenham o campo ID igual a um.
Alteração
Bom, vamos ao ultimo dos quatro comandos de interação básicos. O comando de alteração.
Vejamos o exemplo:
UPDATE Clientes SET Nome = ‘Raul’ WHERE id = 1;
Vamos explanar o comando.
· UPDATE: Comando que indica uma atualização de algum registro.
· Clientes: Tabela que contem o/os registro/s que serão atualizados.
· SET Nome = ‘Raul’: Comando que indica qual o campo do/s registro/s que será/ão atualizado/s. Nome = ‘Raul’ é o nome que ira se sobrepor.
· WHERE id = 1: Indica quais registros da tabela serão afetados pela atualização. No nosso caso o registro cujo id seja igual a um.
Capitulo 6 – Continuação Relações Avançadas
NOME:__________________________________ N°_____
TURMA:_______
PROFESSOR:_______________
	
DATA: __/__ /____ 					NOTA: 
											
Exercícios
1. Defina com suas palavras o que é SQL e qual sua função.
2. Qual a maior vantagem em se usar o SQL?
3. Defina Firebird.
4. Para selecionar um ou mais registros de uma tabela, que comando SQL devemos utilizar?
5. Na exclusão, devemos colocar uma clausula de filtro WHERE muito bem feita. Caso não façamos isso qual pode ser a conseqüência.
Atividade Pratica: 06
1 – Vendo a tabela abaixo, faça os comandos SQL para as seguintes alterações:
a) Inserir um novo registro para a FOX.
b) Alterar a QTD do fabricante NEW LINE para 10.
c) Excluir a Warner Bros.
d) Mostrar Todos os registros que possuam QTD = 4
	ID_Filmes
	Fabricante
	QTD
	1
	New Line
	3
	2
	Evolution Entertainment
	4
	3
	Columbia Pictures
	4
	4
	 Warner Bros
	6
Bibliografia
· Projeto de Banco de Dados 4ª edição Autor: Carlos Alberto Heuser
· DBDesigner 4 – Apostila oficial do sistema. www.fabforce.net
· Banco de dados relacional - Wikipedia a enciclopédia livre http://pt.wikipedia.org/wiki/Banco_de_dados_relacional
· Documentações presentes na Oracle. http://www.oracle.com
· http://www.luis.blog.br/relacionamento-entre-entidades-tipos-e-cardinalidade.aspx
· http://www.inf.ufrgs.br/~heuser/livroProjBD/amostra.pdf
· http://www.devmedia.com.br/exemplo-pratico-regras-e-tipos-de-relacionamentos-sql-server-2008-parte-3/18409
· http://www.firebirdsql.org/
· http://pt.wikipedia.org/wiki/N_para_N
· http://pt.wikipedia.org/wiki/Banco_de_dados_relacional
· http://pt.wikipedia.org/wiki/SQL
· http://pt.wikipedia.org/wiki/Firebird_(servidor_de_base_de_dados)
1