Modelagem de Dados (Estrutura Relacional)

Transcrição

1 Modelagem de Dados (Estrutura Relacional) Se você pretende desenvolver aplicações que usam banco de dados relacionais deverá possuir os conceitos básicos sobre modelagem de dados. Não importa se sua aplicação é muito simples; a correta modelagem dos seus dados irá com certeza tornar sua aplicação mais consistente e mais fácil de manter. Qual o objetivo da modelagem de dados? Por que modelar? Representar o ambiente observado Documentar, normalizar e fornecer processos de validação Observar processos de relacionamentos entre objetos Modelar implica em construir modelos. Para tal, iniciamos definindo as etapas envolvidas na construção de modelos: Mini Mundo Relacionamentos Esquema de Tabelas MINI MUNDO: Descrição formal da realidade a ser representada. Exemplo: suponhamos que uma empresa funcione assim: Cada Empregado pode fazer vários Pedidos Cada Pedido pode ser feito por um único Empregado O Empregado é cadastrado pelo Cpf, Nome e Endereço O Pedido é armazenado por um Número único, sua Data e Situação Não existem 2 Pedidos com o mesmo Número Cada Pedido pode conter muitos Materiais Cada Material pode estar contido em inúmeros Pedidos Cada Pedido pode conter quantidades diferentes para cada Material Cada Material é registrado por um Código único, Descrição e Tipo. Não existem 2 Materiais com o mesmo Código. Relacionamentos As tabelas se relacionam através das chaves principais e estrangeiras. As chaves secundárias são aquelas que são principais em uma tabela e são colocadas em outra tabela para que haja um relacionamento. Relacionamento 1 para N

2 Suponhamos que nós tenhamos as seguintes tabelas: Cliente e Pedido No exemplo acima, temos o seguinte: A tabela Cliente possui os seguintes campos ou atributos: Cpf, Nome, Fone e Cep. Não existem dois Clientes com o mesmo Cpf, por isso o campo Cpf foi escolhido para ser a chave principal. A tabela Pedido possui os seguintes campos ou atributos: Número, Data e Situação (que pode ser: atendido, pendente, cancelado, alterado, etc...) Não existem dois Pedidos com o mesmo Número, por isso o campo Número foi escolhido para ser a chave principal. Os nomes da tabela devem estar em maiúsculo. As chaves principais estão com sublinhado simples e em negrito. Para que uma tabela se relacione com a outra, é necessário que a chave principal de uma tabela esteja no outra tabela, como chave secundária. Devemos considerar ainda o seguinte no raciocínio: Um Cliente pode fazer muitos (N) Pedidos. Cada Pedido pode ser feito por um único (1) Cliente REGRA do 1 para N Então, a tabela Cliente está com o 1 e a tabela Pedido está com o N A tabela que está com o 1 envia sua chave principal para ser a chave estrangeira na tabela que está com o N. A tabela que está com o N recebe a chave principal da tabela que está com o 1. Portanto, a tabela Pedido recebe o campo Cpf-Cliente para ser sua chave estrangeira. Layout de Relacionamento A chave estrangeira está representada pelo sublinhado duplo. As duas tabelas estão relacionadas pelo campo Cpf-Cliente. O 1 e o N indicam que 1 Cliente pode fazer muitos (N) Pedidos. 1 e N são chamados de Cardinalidade.

3 Cardinalidades A chave principal fica com a cardinalidade 1, enquanto que a chave estrangeira fica com a cardinalidade N. Se fosse colocada a chave principal da TAB-PEDIDO (Número-Pedido) na TAB-CLIENTE como chave estrangeira, a situação absurda seria a seguinte: Cada Cliente só poderia fazer um único Pedido. Cada Pedido poderia ser feito por vários Clientes. Esquema de Tabelas O Layout de Relacionamento acima poderia ser representado conforme um Esquema de Tabelas, como veremos a seguir: Tanto no Layout de Relacionamentos como no Esquema de Tabelas, o nome de cada campo fica acompanhado do nome da tabela (Nome-Cliente) pelo seguinte motivo: - No caso de uma consulta por qualquer usuário, fica fácil de identificar se o Nome é do Cliente, do Produto, do Funcionário, do Fornecedor, etc... Relacionamento para N Mini Mundo: Cada Produto é distribuído por vários (N) Fornecedores. Cada Fornecedor pode distribuir vários (N) Produtos. Cada Produto tem um Preço diferente para cada Fornecedor O Produto é cadastrado por Código e Descrição. Não existem 2 Produtos com o mesmo Código O Fornecedor é cadastrado por Cnpj e Nome. Não existem 2 Fornecedores com o mesmo Cnpj

4 Regra do N para N É criada uma tabela entre as tabelas Produto e Fornecedor com qualquer nome. No caso abaixo, demos o nome de TAB-DISTRIBUIÇÃO. A tabela Distribuição recebe a chave principal das 2 tabelas que a enquadram. As 2 chaves juntas ficam sendo a chave principal da tabela Distribuição e não chave estrangeira. A tabela Distribuição se relaciona com as outras duas tabelas pelos campos chaves. Layout de Relacionamentos Esquema de Tabelas Obs: A TAB-PRODUTOS está relacionada com a TAB-DISTRIBUIÇÃO pelo campo Código-Prod A TAB-DISTRIBUIÇÃO está relacionada com a TAB-FORNECEDOR pelo campo Cnpj-Fornec Resposta do Mini Mundo da AEDB Mini Mundo da AEDB Cada aluno pertence a um curso, que por sua vez pode ter vários alunos. O curso é armazenado por um código único e pelo seu nome. Os alunos são cadastrados pela matrícula, nome e endereço. Não existem 2 alunos com a mesma matrícula. Cada curso possui algumas disciplinas que são identificadas por um controle único e pela sua descrição. A mesma disciplina pode ser lecionada em outros cursos em dias diferentes. Cada professor pode ministrar mais de uma disciplina, mas cada disciplina só pode ser lecionada por um único professor. CPF, nome e telefone são os atributos de cada professor.

5 Resposta: Layout de Relacionamentos Resposta: Esquema de Tabelas Fim