[E-BOOK GRÁTIS]: Windows 7 Básico, 476 pgs - QUERO RECEBER!
Você está em: PrincipalArtigosOffice : Modelorelacional_p2
Quer receber novidades e e-books gratuitos?
›››

Conheça o Júlio Battisti

Julio Battisti - Autor de mais de 25 livros de informática Júlio Battisti tem mais de 36 livros publicados, dezenas de e-books e é certificado Microsoft.

Ganhe o e-book a Seguir

e-book grátis Windows 7 Básico

476 páginas



Curta Nossa Fanpage

Loja Virtual do Site

Livros do Julio Battisti

O Modelo Relacional de Dados - Parte 2

Introdução

Objetivo: Na primeira parte deste artigo falei sobre Entidades (tabelas), Atributos (campos) e sobre o conceito de Chave Primária. Nesta segunda parte vou abordar os seguintes tópicos:
  • Relacionamentos entre entidades (tabelas) - conceito


  • Relacionamentos entre entidades (tabelas) - tipos
  • Nota: Os exemplos apresentados utilizarão telas do Microsoft Access e o arquivo de exemplos Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:

    C:\Arquivos de programas\Microsoft Office\Office\Samples

    Porém os princípios básicos do modelo relacional aplicam-se a qualquer banco de dados baseado no modelo relacional de dados. Estes bancos de dados são algumas vezes denominados: SGBDR - Sistemas Gerenciadores de Banco de Dados Relacionais.

    Relacionamentos entre Tabelas

    Neste item vou apresentar o conceito de relacionamento entre tabelas, este um conceito fundamental para o Modelo Relacional de Dados. Também falarei sobre os diferentes tipos de relacionamentos existentes. Serão apresentados exemplos práticos.

    Conforme descrito na Parte 1, um banco de dados é composto por diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, na prática devem existir relacionamentos entre as tabelas. Por exemplo: Um Pedido é feito por um Cliente e neste Pedido podem existir diversos itens, itens que são gravados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único (Código do pedido), mas um mesmo Cliente pode fazer diversos pedidos e assim por diante.

    Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de seus atributos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos:
  • Um para Um

  • Um para Vários

  • Vários para Vários
  • Relacionamento do Tipo Um para Um:

    Esta relação existe quando os campos que se relacionam são ambos do tipo Chave Primária, em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo. Um exemplo poderia ser o seguinte: Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questões de projeto do Banco de Dados, podemos criar uma Segunda Tabela "Alunos da Banda", a qual se relaciona com a tabela Alunos através de um relacionamento do tipo Um para Um. Cada aluno somente é cadastrada uma vez na Tabela Alunos e uma única vez na tabela Alunos da Banda. Poderíamos utilizar o Campo Matrícula do Aluno como o Campo que relaciona as duas Tabelas.

    Importante: O campo que relaciona duas tabelas deve fazer parte, ter sido definido, na estrutura das duas tabelas.

    Na tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno, além das informações a respeito do Instrumento que ele toca, tempo de banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitação.

    Na Figura a seguir vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.


    Figura 1: Relacionamento Um para Um entre as Tabelas Alunos e Alunos da Banda.

    Com a criação deste relacionamento estamos evitando a repetição desnecessária de informações em diferentes tabelas.

    Relacionamento do Tipo Um para Vários:

    Este é, com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes.

    Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrado uma única vez na tabela de Clientes (por isso o campo Código do Cliente, na tabela Clientes, é uma chave primária, indicando que não podem ser cadastrados dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Ao mesmo tempo cada cliente pode fazer diversos pedidos, por isso que o mesmo Código de Cliente poderá aparecer várias vezes na tabela Pedidos: tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode realizar diversos (vários) pedidos.

    Na próxima figura vemos um exemplo de um Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código do cliente:


    Figura 2: Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos.

    Observe que o lado Vários do relacionamento é representado pelo símbolo do infinito (¥). Esta é a representação utilizada no Microsoft Access. Diferentes representações poderão ser utilizadas por outros bancos de dados.

    No lado Um do relacionamento o campo é definido como uma Chave Primária (Campo CódigoDoCliente na tabela Clientes) e no lado Vários não (campo CódigoDoCliente na tabela Pedidos), indicando que no lado vários o Código do Cliente pode se repetir várias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.

    IMPORTANTE: Observe que o campo que é o lado vários do relacionamento não pode ser definido como chave primária. Lembrando do conceito de Chave Primária, apresentado na Parte 1: Chave Primária é o campo no qual não podem haver valores repetidos. Ora, se o campo está no lado "vários", significa que ele poderá ter o seu valor repetido em vários registros. Por exemplo, na tabela pedidos, poderá haver vários registros para o mesmo cliente. Se o campo terá que ter valores repetidos, então ele não pode ser definido como chave primária.

    No Banco de Dados NorthWind.mdb, Northwind.mdb, o qual é instalado juntamente com o Microsoft Access. Este arquivo está disponível, por padrão, no seguinte caminho:

    C:\Arquivos de programas\Microsoft Office\Office\Samples

    Existem diversos outros exemplos de relacionamentos do tipo Um para Vários, conforme descrito na Próxima Tabela:

    Tipo Lado Um Lado Vários
    Um para Vários CódigoDoFornecedor na tabela Fornecedores CódigoDoFornecedor na tabela Produtos
    Um para Vários CódigoDaCategoria na tabela Categorias CódigoDaCategoria na tabela Produtos
    Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido
    Um para Vários CódigoDoFuncionário na tabela Funcionários CódigoDoFuncionário na tabela Pedidos
    Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido
    Um para Vários CódigoDaTransportadora na tabela Transportadoras Via na tabela Pedidos
    Um para Vários CódigoDoCliente na tabela Clientes CódigoDoCliente na tabela Pedidos

    Em um dos próximos artigos mostrarei como implementar, na prática, estes relacionamentos. Algumas observações importantes sobre relacionamentos:
  • O Nome dos Campos envolvidos no Relacionamento, não precisa ser, necessariamente, o mesmo, conforme indicado pelo relacionamento entre os campos CódigoDaTransportadora e Via, na tabela anterior. O tipo dos campos é que precisa ser o mesmo, por exemplo, se um dos campos for do tipo Texto, o outro também deverá ser do tipo Texto.


  • Sempre o Lado um do Relacionamento deve ser uma chave primária, já o lado vários não pode ser uma chave Primária.


  • De Preferência, antes de Criar os Relacionamentos verifique se o tipo dos campos a serem relacionados é o mesmo, além de características como máscaras de entrada e formato.
  • Relacionamento do tipo Vários para Vários:

    Este tipo de relacionamento "aconteceria" em uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparece um determinado produto, além disso vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários.

    Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido.

    Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Vários dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários, conforme descrito pela próxima tabela:


    Tipo Lado Um Lado Vários
    Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido
    Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido

    Na figura abaixo temos a representação dos dois relacionamentos Um para Vários, resultantes da quebra do relacionamento vários-para-vários:


    Tabela Detalhes do Pedido ficou com o lado Vários dos Relacionamentos.

    Esta situação em que um relacionamento um para Vários é "quebrado" em dois Relacionamentos do tipo Um para Vários é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma série de problemas no Banco de Dados, tais como informação repetida e inconsistência de Dados.

    Agora que já conhecemos os Tipos de Relacionamentos existentes, na próxima Parte 3, falarei sobre o conceito de Integridade Referencial como uma maneira de Garantir a Consistência dos Dados.

    Conclusão:

    Neste segundo artigo da série, você aprendeu sobre os conceitos de relacionamentos, sem dúvidas um dos conceitos mais importantes do Modelo Relacional. Implementar um banco de dados sem se preocupar com um projeto cuidados dos relacionamentos, é garantia certa de "encrenca" mais adiantes. São consultas que retornam dados inesperados, são relatórios que retornam valores "absurdos" e por aí vai. É fundamental que os profissionais de desenvolvimento e de administração de banco de dados entendem o quão impotante é planejar o banco de dados, cuidadosamente, definindo quais tabelas farão parte do banco de dados, quais os campos de cada tabela, quais campos serão chave primária e qual o relacionamento entre as tabelas. Muitos acham que esta é uma "perda de tempo", que o bom mesmo é sentar e começar a implementar o banco de dados, depois "a gente vê o que dá". Ledo engano. Não é perda de tempo, muito pelo contrário, é um ganho de tempo e principalmente de qualidade no produto final. Quanto tempo é perdido depois, tentando corrigir erros e incosistências que muitas vezes são decorrentes de um banco de dados mal projetado? Uma boa leitura a todos e até a Parte 3.

    Entre em contato. Deixe-me conhecer a sua opinião e também suas sugestões. Entre em contato através do e-mail webmaster@juliobattisti.com.br ou diretamente através de um dos seguintes sites: http://www.juliobattisti.com.br/ e http://www.certificacoes.com.br/.


    Outras partes do Artigo
    Parte 1 Atributos e Tabelas
    Parte 2 Relacionamentos entre tabelas
    Parte 3 Integridade Referencial
    Parte 4 Normalização de tabelas
    Parte 5 Projeto de Banco de Dados




    Dúvidas?

    Utilize a área de comentários a seguir.

    Me ajude a divulgar este conteúdo gratuito!

    Use a área de comentários a seguir, diga o que achou desta lição, o que está achando do curso.
    Compartilhe no Facebook, no Google+, Twitter e Pinterest.

    Indique para seus amigos. Quanto mais comentários forem feitos, mais lições serão publicadas.

    Quer receber novidades e e-books gratuitos?
    ›››

    Vídeo-Aulas

  • Access
  • Excel
  • Programação
  • Windows/Linux
  • Redes
  • + Todas as categorias
  • E-books

  • Access
  • Excel
  • Programação
  • Windows/Linux
  • Redes
  • + Todas as categorias
  • Livros

  • Administração
  • Excel
  • Programação
  • Windows/Linux
  • Redes
  • + Todas as categorias
  • Cursos Online

  • Banco de Dados
  • Carreira
  • Criação/Web
  • Excel/Projetos
  • Formação
  • + Todas as categorias
  • Conteúdo Gratuito

  • +1500 Artigos e Tutoriais
  • ASP 3.0
  • ASP.NET
  • Access Básico
  • Access Avançado
  • Excel Básico - 120 lições
  • Excel Avançado - 120 lições
  • SQL Server 2005
  • Windows 7
  • Windows XP
  • Windows 2003 Server
  • Windows 2008 Server
  • Novidades e E-books grátis

    Fique por dentro das novidades, lançamento de livros, cursos, e-books e vídeo-aulas, e receba ofertas de e-books e vídeo-aulas gratuitas para download.



     

    Institucional

  • Quem somos
  • Garantia de entrega
  • Contato
  • O Autor

  • Atendimento: (51) 3717-3796 - webmaster@juliobattisti.com.br Todos os direitos reservados, Júlio Battisti 2001-2014 ®