SlideShare une entreprise Scribd logo
1  sur  37
MODELAGEM
    EM
  BANCO
    DE
  DADOS




 Prof. Marcos Alexandruk
MODELAGEM EM BANCO DE DADOS                                                               1


INTRODUÇÃO AOS CONCEITOS DE INFORMAÇÃO

INFORMAÇÃO:
•   Acrescenta algo ao conhecimento da realidade a ser analisada. Por exemplo, a dosagem
    que um paciente precisa receber de um determinado remédio é uma INFORMAÇÃO. Este
    conhecimento pode ser (ou não) modelado (registrado).

DADO:
•   É uma representação, um registro de uma informação. Este DADO pode ser registrado
    fisicamente através de um papel (receita médica), um disco magnético, etc.

O tratamento das INFORMAÇÕES dá origem a uma série de DADOS, porém o DADO deve
registrar apenas aspectos relevantes da INFORMAÇÃO.
Tendo em vista a natural quot;restriçãoquot; humana de manipular grandes quantidades de
informações ao mesmo tempo, foram criadas técnicas para modelar os diversos problemas que
existem. Estas técnicas, juntas, formam um conjunto conhecido como METODOLOGIA de
produção de sistemas de informação.
Desde 1950, várias metodologias estão sendo colocadas em prática. Estas metodologias
definem o CICLO DE VIDA do desenvolvimento, no qual estão mostradas as fases que
compõem o caminho a ser seguido pelos analistas e programadores, até a produção do
sistema de informações na sua versão operacional. Cada fase pode ser vista como o
refinamento da etapa anterior.
A seguir serão apresentadas algumas metodologias utilizadas no processo de desenvolvimento
de sistemas de informação:

CICLO DE VIDA TRADICIONAL OU EM CASCATA
Apresenta como principal característica a baixa interação dos usuários do sistema com o
pessoal de desenvolvimento.
Durante as etapas de Levantamento e Análise, o usuário tenta passar para o analista tudo o
que sabe sobre o problema e o que ele deseja para solucionar o mesmo. Após a definição do
problema é criado um documento contendo os requisitos do futuro sistema, que é então
congelado e utilizado durante todas as fases de desenvolvimento.
Neste ciclo de vida quase não existe oportunidade para o usuário realizar alguma alteração em
pontos dos requisitos congelados. As atividades são realizadas em seqüência e não existem
retornos entre as atividades. Toda a documentação é produzida após o término do projeto.
Os projetos realizados com este ciclo de vida se caracterizam pela alta incidência de
manutenção, pois estão sujeitos a poucas alterações durante o desenvolvimento.
•   LEVANTAMENTO
•   ANÁLISE
•   PROJETO
•   CODIFICAÇÃO
•   DOCUMENTAÇÃO
•   TESTES
•   IMPLEMENTAÇÃO
•   MANUTENÇÃO

CICLO DE VIDA DA ANÁLISE ESTRUTURADA
Caracterizado pelo uso das técnicas estruturadas, incluindo as revisões estruturadas.
Muitas das atividades são executadas em paralelo, produzindo documentação nos vários
estágios do desenvolvimento.
Revisões periódicas são realizadas para se detectar o mais cedo possível problemas que podem
influenciar o produto final.
O envolvimento do usuário é bastante significativo. Sua participação na maioria das revisões
traz novas sugestões e correções dos aspectos não compatíveis com suas necessidades.
MODELAGEM EM BANCO DE DADOS                                                                2


CICLO DE VIDA DA ENGENHARIA DE SOFTWARE
Busca uma maior disciplina em termos de desenvolvimento de sistemas.
Caracterizada pela forte orientação por processos, pela determinação bem acentuada de cada
fase, enfatiza a reutilização de código de programa, provê revisões e pontos de checagem bem
determinados e define métricas bem fundamentadas para o gerente realizar o controle da
produtividade, a qualidade e o baixo custo final.
A engenharia de software é fundamentada em sete fases: viabilidade, análise, projeto,
implementação, teste do sistema, teste do usuário e produção. Quando um problema ocorre
em uma das fases, retorna-se a fase imediatamente anterior.

CICLO DE VIDA DA ENGENHARIA DE INFORMAÇÃO
No decorrer de 20 anos de uso de técnicas de desenvolvimento de sistemas, concluiu-se que
os dados envolvidos em cada processo eram extremamente estáveis, se comparados com os
processos.
Em 1981, Matt Flavin, James Martin e Clive Finkelstein introduziram o conceito de engenharia
da informação. O princípio fundamental baseava-se no fato de que o dado existe e é descrito,
independentemente dos processos que podem utilizá-lo.
Como o centro desta metodologia é o DADO, a idéia principal é levantar as estruturas de dados
que vão dar origem aos bancos de dados, provendo um fácil acesso aos mesmos.
A engenharia da informação é um conjunto integrado de técnicas que organiza os dados de um
determinado negócio e determina um acesso fácil, por parte do usuário final, a estes dados.
Esta metodologia pode ser detalhada nas seguintes fases: planejamento estratégico das
informações, análise da informação, modelagem dos dados, formação dos procedimentos,
análise do uso dos dados, análise da distribuição dos dados, projeto físico da base de dados e
especificação dos programas.
MODELAGEM EM BANCO DE DADOS                                                            3


INTRODUÇÃO

Conceitos básicos necessários à compreensão do projeto de banco de dados.

BANCO DE DADOS:
•   coleção de dados integrados que tem por objetivo atender a uma comunidade de usuários.
•   conjunto de dados persistentes e manipuláveis que obedecem a um padrão de
    armazemamento. Exemplos: lista telefônica, dicionário, etc..
•   equivalente eletrônico de um armário de arquivamento, isto é, um repositório para uma
    coleção de arquivos de dados computadorizados.

Por que utilizar DB’s (informatizados)?
    •   Compacto (elimina arquivos de papéis);
    •   Rápido;
    •   Integrado (repositório de dados de vários aplicativos);
    •   Compartilhado (vários usuários podem acessar);
    •   Seguro (acesso com restrições);
    •   Padronizado;
    •   Consistente;
    •   Suporte a transações (opcional)

SISTEMA DE GERÊNCIA DE BANCO DE DADOS (SGDB)
•   software que incorpora as funções de definição, recuperação e alteração de dados em um
    banco de dados
•   sistema computadorizado de manutenção de registros
MODELAGEM EM BANCO DE DADOS                                                                4


VANTAGENS:
•   Densidade: Não há necessidade de arquivos de papel, possivelmente volumosos
•   Velocidade: A 'máquina' pode obter e atualizar dados com rapidez muito maior que o ser
    humano
•   Menos trabalho monótono: Grande parte do tédio de manter arquivos à mão é eliminada.
    As tarefas mecânicas são sempre feitas com melhor qualidade por máquinas.
•   Atualidade: Informações precisas e atualizadas estão disponíveis a qualquer momento sob
    consulta
•   Proteção: Os dados podem ser mais bem protegidos contra perda não intencional e acesso
    ilegal
•   Centralização: O sistema de banco de dados proporciona à organização o controle
    centralizado de seus dados.

MODELO DE DADOS:
Descrição formal da estrutura de um banco de dados.

MODELO HIERÁRQUICO

Organiza os dados de cima para baixo, como uma árvore. Cada registro é dividido em partes
de registros denominados segmentos. O banco de dados se assemelha a um organograma com
um segmento raiz e um número qualquer de segmentos subordinados. Os segmentos, por sua
vez, são arranjados em estruturas multiniveladas, com um segmento superior ligado a um
segmento subordinado em um relacionamento “pai-filho”. Um segmento “pai” pode ter mais de
um “filho”, mas um segmento “filho” só pode ter um “pai”.

MODELO EM REDE
Os registros são organizados no banco de dados por um conjunto arbitrário de gráficos. Em
outras palavras, um “filho” pode ter mais de um “pai”. São mais flexíveis que os hierárquicos.
Existem limitações práticas para o número de ligações, que podem ser estabelecidas entre os
registros. Nem o modelo de gerenciamento de bancos de dados em rede nem o hierárquico
podem criar facilmente novos relacionamentos entre os elementos de dados ou novos padrões
de acesso sem grande esforço de programação.

MODELO RELACIONAL
A introdução do sistema relacional (1969-1970) foi o evento mais importante na história da
área de banco de dados.
De modo abreviado (e informal), um sistema relacional é aquele no qual:
•   Os dados são percebidos pelo usuário como tabelas
•   Os operadores à disposição do usuário (por exemplo, para busca de dados) são operadores
    que geram tabelas quot;novasquot; a partir de tabelas quot;antigasquot;. Por exemplo, há um operador de
    quot;restriçãoquot; (também conhecido como quot;seleçãoquot;) para extrair um subconjunto das linhas de
    uma dada tabela, e outro operador, quot;projeçãoquot;, que extrai um subconjunto das colunas.
Os primeiros produtos relacionais começaram a aparecer no final da década de 1970. Hoje a
maioria dos sistemas de banco de dados é relacional:
•   IBM: DB2
•   CA: Ingres II
•   Microsoft: SQL Server
•   Oracle: 9i, 10g
•   Sybase
•   Informix
A linguagem de manipulação de dados em sistemas de bancos de dados relacionais é o SQL
(Structured Query Language).
MODELAGEM EM BANCO DE DADOS                                                                5


VISÃO DE DADOS

O maior benefício de um banco de dados é proporcionar ao usuário uma visão abstrata dos
dados. Isto é, o sistema acaba por ocultar determinados detalhes sobre a forma de
armazenamento e manutenção desses dados.

ABSTRAÇÃO DE DADOS

NÍVEL FÍSICO:
•   É o nível mais baixo de abstração.
•   Descreve como os dados estão de fato armazenados.
•   Estruturas complexas são descritas em detalhes.

NÍVEL LÓGICO:
•   Descreve quais dados estão armazenados e quais os relacionamentos entre eles.
•   O banco de dados é descrito em termos de um número relativamente pequeno de
    estruturas simples.
•   Utilizado pelos administradores de banco de dados que precisam decidir quais informações
    devem pertencer ao banco de dados.


NÍVEL DE VISÃO:
•   É o nível mais alto de abstração.
•   Descreve apenas parte do banco de dados.
•   Muitos usuários utilizam apenas parte do banco de dados. Assim, para que estas interações
    sejam simplificadas, um nível de visão é definido.
•   O sistema pode proporcionar diversas visões do mesmo banco de dados.




INDEPENDÊNCIA DE DADOS:
•   É a capacidade de modificar a definição dos esquemas em determinado nível, sem afetar o
    esquema do nível superior.
•   Independência de dados física: é a capacidade de modificar o esquema físico sem que,
    com isso, qualquer programa ou aplicação precise ser reescrito.
•   Independência de dados lógica: é a capacidade de modificar o esquema lógico sem que,
    com isso, qualquer programa ou aplicação precise ser reescrito.
•   A independência lógica é mais difícil de ser alcançada que a independência física, uma vez
    que os programas de aplicação são mais fortemente dependentes da estrutura lógica dos
    dados do que de seu acesso.
MODELAGEM EM BANCO DE DADOS                                                            6


ARQUITETURAS DE SISTEMAS DE BANCOS DE DADOS

SISTEMAS CENTRALIZADOS

Sistemas de banco de dados centralizados são aqueles executados sobre um único sistema
computacional que não interagem com outros sistemas.
Tais sistemas podem ter a envergadura de um sistema de banco de dados de um só usuário
executado em um computador pessoal até sistemas de alto desempenho em sistemas de
grande porte.




SISTEMAS CLIENTE-SERVIDOR

As funcionalidades de um banco de dados podem ser superficialmente divididas em duas
categorias:
• back-end: gerencia as estruturas de acesso, desenvolvimento e otimização de consultas,
    controle de concorrência e recuperação.
• front-end: consiste em ferramentas como formulários, gerador de relatórios e recursos de
    interfaces gráficas.
A interface entre o front-end e o back-end é feita por meio da SQL ou de um programa de
aplicação.




SISTEMAS PARALELOS

Sistemas paralelos imprimem velocidade ao processamento e à I/O por meio do uso em
paralelo de diversas CPUs e discos.
Suprem a demanda de aplicações que geram consultas em bancos de dados muito grandes (da
ordem de terabytes) ou que tenham de processar um volume enorme de transações por
segundo (da ordem de milhares de transações por segundo).
MODELAGEM EM BANCO DE DADOS                                                                 7


Há diversos modelos arquitetônicos para máquinas paralelas:
• Memória compartilhada: Todos os processadores compartilham uma mesma memória.
• Disco compartilhado: Todos os processadores compartilham o mesmo disco. Sistemas com
   discos compartilhados são, às vezes chamados de clusters.
• Ausência de compartilhamento: Os processadores não compartilham nem memória nem
   disco.
• Hierárquico: É um híbrido das arquiteturas anteriores.




SISTEMAS DISTRIBUÍDOS

Em um sistema de banco de dados distribuído o banco de dados é armazenado em diversos
computadores. Os computadores comunicam-se uns com os outros por intermédio de redes de
alta velocidade ou linhas telefônicas. Eles não compartilham memória principal ou discos.
Os computadores em um sistema de banco de dados distribuídos podem variar, quanto ao
tamanho e funções, desde estações de trabalho até sistemas de grande porte (mainframe).
As principais diferenças entre os bancos de dados paralelos sem compartilhamento e os bancos
de dados distribuídos são que, nos bancos de dados distribuídos, há a distribuição física
geográfica (diversos sites), administração separada e uma intercomunicação menor. Outra
importante diferença é que, nos sistemas distribuídos, distinguimos transações locais de
globais. Uma transação local acessa um único site, justamente no qual ela se inicial. Uma
transação global, por outro lado, é aquela que busca acesso a diferentes sites, ou a outro site
além daquele em que se inicia.
MODELAGEM EM BANCO DE DADOS                                                                     8


VISÃO GERAL DA ESTRUTURA DO SISTEMA DE BANCO DE DADOS

COMPONENTES DE PROCESSAMENTO DE CONSULTAS:
•   Compilador DML: Traduz comandos DML da linguagem de consulta em instruções de baixo nível,
    inteligíveis ao componente de execução de consultas. Transforma a solicitação do usuário em uma
    solicitação equivalente, mas mais eficiente.
•   Pré-compilador para comandos DML: Inseridos em programas de aplicação que convertem
    comandos DML em chamadas e procedimentos normais da linguagem hospedeira. Interage com o
    compilador DML de modo a gerar o código apropriado.
•   Interpretador DDL: Interpreta os comandos DDL e registra-os em um conjunto de tabelas que
    contêm metadados.
•   Componentes para tratamento de consultas: Executam instruções de baixo nível geradas pelo
    compilador DML.

COMPONENTES DE ADMINISTRAÇÃO DE ARMAZENAMENTO DE DADOS:
•   Gerenciamento de autorização e integridade: Testam o cumprimento das regras de integridade
    e a permissão ao usuário no acesso ao dado.
•   Gerenciamento de transações: Garante que o banco de dados permanecerá em estado consistente
    (correto) a despeito de falhas no sistema e que transações concorrentes serão executadas sem
    conflitos em seus procedimentos.
•   Administração de arquivos: Gerencia a alocação de espaço no armazenamento em disco e as
    estruturas de dados usadas para representar as informações armazenadas em disco.
•   Administração de buffer: Responsável pela intermediação de dados do disco para a memória
    principal e pela decisão de quais dados colocar em memória cache.

OUTRAS ESTRUTURAS NECESSÁRIAS COMO PARTE DA IMPLEMENTAÇÃO FÍSICA DO SISTEMA:
•   Arquivo de dados: Armazena o próprio banco de dados.
•   Dicionário de dados: Armazena os metadados relativos à estrutura do banco de dados.
•   Índices: Proporcionam acesso rápido aos dados associados a valores determinados.
•   Estatísticas de dados: Armazenam informações estatísticas usadas pelo processador de consultas
    para seleção de meios eficientes para execução de uma consulta.
MODELAGEM EM BANCO DE DADOS                                                              9


MODELO CONCEITUAL

•   Representa ou descreve a realidade do ambiente do problema, constituindo-se em uma
    visão global dos principais dados e relacionamentos (estruturas de informações),
    independente das restrições de implementação.
•   É a primeira etapa do projeto de um sistema de aplicação em banco de dados.
•   É uma descrição em alto nível (macro definição) mas que tem a preocupação de capturar e
    retratar toda a realidade de uma organização.
•   O resultado de um modelo conceitual é um esquema que representa a realidade das
    informações existentes, assim como as estruturas de dados que representam estas
    informações.




MODELO LÓGICO

•   Tem seu início a partir do modelo conceitual, levando em consideração as três abordagens
    atualmente disponíveis: Relacional, Hierárquica e Rede.
•   O modelo lógico descreve as estruturas que estarão contidas no banco de dados, mas sem
    considerar ainda nenhuma característica específica de SGBD, resultando em um esquema
    lógico de dados.




MODELO FÍSICO

•   Parte do modelo lógico e descreve as estruturas físicas de armazenamento de dados, tais
    como: tamanhos de campos, índices, tipos de dados, nomenclaturas, etc.
•   Este modelo detalha o estudo dos métodos de acesso do SGDB, para elaboração dos
    índices de cada informação colocada nos modelos conceitual e lógico.
•   É a etapa final do projeto de banco de dados, na qual será utilizada a linguagem de
    definição de dados (DDL), para a realização da montagem do mesmo no nível de dicionário
    de dados.
MODELAGEM EM BANCO DE DADOS                                                              10


MODELO CONCEITUAL
Descrição do banco de dados de forma independente de implementação em um SGBD.
Registra que dados podem aparecer no banco de dados, mas não registra como estes dados
estão armazenados no SGDB.
DIAGRAMA ENTIDADE-RELACIONAMENTO




O Modelo Entidade-Relacionamento foi definido por Peter Chen em 1976, e teve como base a
teoria relacional criada por E. F. Codd (1970).
Um modelo ER é um modelo formal, preciso, não ambíguo. Isto significa que diferentes leitores
de um mesmo modelo ER devem sempre entender exatamente o mesmo. Tanto é assim, que
um modelo ER pode ser usado como entrada de uma ferramenta CASE (Computer Aided
Software Engineering) na geração de um banco de dados relacional.
ENTIDADE: Representa um conjunto de objetos (tudo que é perceptível ou manipulável) da
realidade modelada sobre os quais deseja-se manter informações no banco de dados.
ATRIBUTOS: Dados que são associados a cada ocorrência de uma entidade ou de um
relacionamento.
IDENTIFICADOR DE ENTIDADE: Atributo ou conjunto de atributos e relacionamentos cujos
valores distinguem uma ocorrência da entidade das demais.
CARDINALIDADE: Número (mínimo, máximo) de ocorrências de entidade associadas a uma
ocorrência da entidade em questão através do relacionamento.
Cardinalidade mínima: É o número mínimo de ocorrências de entidade que são associadas a
uma ocorrência de uma entidade através de um relacionamento.
A cardinalidade mínima 1 recebe a denominação de associação obrigatória, já que ela indica
que o relacionamento deve obrigatoriamente associar uma ocorrência de entidade a outra. A
cardinalidade mínima 0 (zero) recebe a denominação de associação opcional.
Cardinalidade máxima: É o número máximo de ocorrências de entidade que são associadas
a uma ocorrência de uma entidade através de um relacionamento. Apenas duas cardinalidades
máximas são relevantes: a cardinalidade máxima 1 e a cardinalidade máxima n (muitos).
DIAGRAMA DE OCORRÊNCIAS: Para fins didáticos, pode ser útil construir um diagrama de
ocorrências. Neste as ocorrências de entidades são representadas por círculos brancos e
ocorrências de relacionamentos por círculos pretos. As ocorrências de entidades participantes
de uma ocorrência de relacionamento são indicadas pelas linhas que ligam o círculo preto aos
círculos brancos.
MODELAGEM EM BANCO DE DADOS                                                             11


RELACIONAMENTO BINÁRIO

Um relacionamento binário é aquele envolve duas ocorrências de entidade.
Podemos classificar os relacionamentos binários em:
•   1:1 (um-para-um): cada elemento de uma entidade relaciona-se com um e somente um
    elemento de outra entidade.
•   1:n (um-para-muitos): um elemento da entidade 1 relaciona-se com muitos elementos
    da entidade 2, mas cada elemento da entidade 2 somente pode estar relacionado a um
    elemento da entidade 1.
•   n:n (muitos-para-muitos): em ambos os sentidos encontramos um grau de
    relacionamento de um-para-muitos, o que o caracteriza no contexto geral como um
    relacionamento de muitos-para-muitos.




RELACIONAMENTO TERNÁRIO

Relacionamento entre múltiplas entidades, expressam um fato em que todas as entidades
ocorrem simultaneamente, ou seja, todas as ocorrências do relacionamento possuem, sempre,
ligações com todas as entidades envolvidas no relacionamento.
O exemplo a seguir queremos garantir que a seguinte situação seja representa de forma
apropriada: x fornece a peça y para o projeto z. Esta condição somente pode ser representada
através de um relacionamento ternário.




Observe o que ocorreria se tentássemos substituir o relacionamento ternário acima por três
relacionamentos binários:
x fornece a peça y: Não podemos inferir que a peça y será utilizada no projeto z.
y é utilizada no projeto z: Não podemos inferir que y foi fornecida por x.
x fornece para o projeto z: Não podemos inferir x fornece a peça y para o projeto z.

Veja este outro caso que expressa a cardinalidade num relacionamento ternário:




No exemplo acima, cada par de ocorrências (aluno, disciplina) está associado a no máximo um
professor.
A um par (aluno, professor) podem estar associadas muitas disciplinas, ou em outros termos,
um professor pode ministrar a um determinado aluno várias disciplinas.
A um par (disciplina, professor) podem estar associados muitos alunos, ou em outros termos,
um professor pode uma determinada disciplina a vários alunos.
MODELAGEM EM BANCO DE DADOS                                                          12


AUTO RELACIONAMENTO

Relacionamento entre ocorrências de uma mesma entidade.




Exemplo 1: 1:1 - uma ocorrência de pessoa exerce o papel de marido e outra ocorrência de
pessoa exerce o papel de esposa.
Exemplo 2: 1:n - uma ocorrência de funcionário exerce o papel de supervisor e      outras
ocorrências de funcionário exercem o papel de supervisionado.




GENERALIZAÇÃO/ESPECIALIZAÇÃO

Através deste conceito é possível atribuir propriedades particulares a um subconjunto das
ocorrências especializadas de uma entidade genérica.

Especialização total: para cada ocorrência da entidade genérica existe sempre uma
ocorrência em uma das entidades especializadas.




Especialização parcial: nem toda ocorrência da entidade genérica possui uma ocorrência
correspondente em uma entidade especializada.
MODELAGEM EM BANCO DE DADOS                                                                13


MÚLTIPLOS NÍVEIS E HERANÇA MÚLTIPLA

É admissível que uma mesma entidade seja especialização de diversas entidades genérica
(herança múltipla).
No diagrama abaixo o exemplo de herança múltipla aparece na entidade ANFÍBIO.




HERANÇA DE PROPRIEDADES

Herdar propriedades significa que cada ocorrência da entidade especializada possui, além de
suas propriedades (atributos, relacionamentos e generalizações/especializações) também as
propriedades da ocorrência da entidade genérica correspondente.

GENERALIZAÇÃO/ESPECIALIZAÇÃO EXCLUSIVA

Significa que uma ocorrência de entidade genérica           aparece,   para   cada   hierarquia
generalização/especialização, no máximo uma vez.

GENERALIZAÇÃO/ESPECIALIZAÇÃO NÃO EXCLUSIVA

Neste caso, uma ocorrência da entidade genérica pode aparecer em múltiplas especializações.
No exemplo abaixo, considera-se o conjunto de pessoas vinculadas a uma universidade. Neste
caso a especialização não é exclusiva, já que a mesma pessoa pode aparecer em múltiplas
especializações. Uma pessoa pode ser professor de um curso e ser aluno em outro curso (pós-
graduação, por exemplo). Por outro lado, uma pessoa pode acumular o cargo de professor em
tempo parcial com o cargo de funcionário, ou, até mesmo, ser professor de tempo parcial em
dois departamentos diferentes, sendo portanto duas vezes professor.




O principal problema que este tipo de generalização/especialização apresenta é que neste caso
as entidades especializadas não podem herdar o identificador da entidade genérica. No caso, o
identificador de pessoa não seria suficiente para identificar professor, já que uma pessoa pode
ser múltiplas vezes professor.
MODELAGEM EM BANCO DE DADOS                                                         14


ENTIDADE ASSOCIATIVA

Um relacionamento é uma associação entre entidades. Na modelagem ER não foi prevista a
possibilidade de associar uma entidade com um relacionamento ou então de associar dois
relacionamentos entre si.
Uma entidade associativa nada mais é que a redefinição de um relacionamento, que passa a
ser tratado como se fosse também uma entidade.
Representamos graficamente uma entidade associativa conforme o exemplo abaixo:
MODELAGEM EM BANCO DE DADOS                                                             15


MODELO RELACIONAL

CHAVE PRIMÁRIA: Atributo através do qual seja possível identificar determinado registro.
Uma chave primária não pode ser repetida, ou seja, o conjunto de valores que constituem a
chave primária deve ser único dentro de uma tabela.
   •   Chave primária simples: apenas um atributo (campo) compõe a chave primária.
   •   Chave primária composta: mais de um atributo compõe a chave primária.
CHAVE ÚNICA: Utilizada quando determinado campo não deve ser repetido e não é chave
primária. Aumenta a consistância do banco de dados.
Exemplo: Cadastro de clientes. Cada cliente recebe um código único, que é a chave primária.
Para maior segurança e consistência podemos optar que o campo RG também seja único,
evitando que o mesmo cliente seja cadastrado duas vezes.
CHAVE ESTRANGEIRA: Utilizada quando queremos que o valor de um atributo seja validado
a partir do valor de atributo de uma outra tabela. Criamos assim uma relação de dependência
(um relacionamento) entre as tabelas.
Exemplo: Antes de efetuar o cadastro de um pedido de venda, é necessário que o cliente em
questão conste no cadastro de clientes.
RELACIONAMENTOS: Associação estabelecida entre campos comuns de duas tabelas. Dessa
forma permitimos o estabelecimento de correspondência entre registros de diferentes tabelas.
Relacionamento um-para-um (1-1):
FUNCIONARIO                        ARMARIO
CodigoFuncionario (1) ----|        NumeroArmario
NomeFuncionario           |--- (1) CodigoFuncionario
EnderecoFuncionario                DataCadastro
TelefoneFuncionario

Relacionamento um-para-muitos (1-N):
CLIENTE                        PEDIDO
CodigoCliente (1) ---|         NumeroPedido
NomeCliente          |---- (N) CodigoCliente
EnderecoCliente                DataPedido
TelefoneCliente                CodigoProduto

Relacionamento muitos-para-muitos (N-N): Não é possível efetuar de forma direta. Esse
tipo de relacionamento só é possível definindo uma terceira tabela (tabela de associação ou
tabela de detalhes). Essa tabela deve possuir chave primária composta de dois campos e as
chaves estrangeiras provenientes das duas tabelas primárias. Concluindo, um relacionamento
de muitos-para-muitos deve ser dividido em dois relacionamentos de um-para-muitos com
uma terceira tabela.
PEDIDO                        ITENSPEDIDO                     PRODUTO
NumeroPedido (1) -------- (N) NumeroPedido         |---- (1) CodigoProduto
CodigoCliente                 CodigoProduto (N) ---|         DescProduto
DataPedido                    Quantidade                     ValorProduto
                                                             EstoqueProduto

NOTAÇÃO RESUMIDA PARA MODELOS LÓGICOS RELACIONAIS

Notação compacta, útil para discussões sobre a estrutura geral do banco de dados, utilizada
quando não se deseja entrar no nível maior de detalhamento.
Funcionario(CodFunc, Nome, CodDept, CPF)
            CodDept referencia Departamento
Departamento(CodDept, Nome)
MODELAGEM EM BANCO DE DADOS                                                              16


INTEGRIDADE DE DADOS

INTEGRIDADE DE DOMÍNIO: Zela pelos valores ideais e necessários para um atributo. Para
isso definimos algumas regras de validação por meio de expressões compostas de valores
constantes.
•   Não permitir um estoque negativo
•   Impedir uma data de nascimento superior à data atual
•   Não permitir que o valor de um produto seja negativo

INTEGRIDADE DE ENTIDADE: Tem o objetivo de validar os valores permitidos a partir de
valores já inseridos na própria entidade. Após uma “auto-consulta” a entidade vai permitir ou
não a gravação do novo registro.

    •    Não permitir duas pessoas com o mesmo CPF
    •    Impedir que seja locada uma fita que já está locada

INTEGRIDADE REFERENCIAL: Zela pela consistência dos registros de uma entidade a partir
de valores provenientes de outras entidades, isto é, determinado registro vai “depender”
diretamente de um registro de outra tabela.
• Um registro em uma tabela pai pode ter um ou mais registros em uma tabela filho.
• Um registro em uma tabela filho sempre tem um registro coincidente em uma tabela pai.
• Para a inclusão de um registro em uma determinada tabela filho, é necessário que exista
    um registro pai coincidente.
• Um registro pai só poderá ser excluído se não possuir nenhum registro filho.

NOMENCLATURA DE CAMPOS

    •    Não utilizar caracteres especiais (exceto o underscroe “_”);
    •    Começar com uma letra e não com um número;
    •    Evitar acentuação e “ç”;
    •    Não utilizar espaços.

                                  ORACLE - TIPOS DE DADOS
     Tipo                                          Descrição
char               Cadeia de caracteres de tamanho fixo n. O default é 1 e o máximo é 255.
varchar2 (n)       Cadeia de caracteres de tamanho variável. Tamanho máximo 4.000.
                   Cadeia de caracteres de tamanho variável. Tamanho máximo 2 GB. Só
long
                   pode existir um campo deste tipo por tabela.
                   Equivalente ao varchar2 e long, respectivamente. Utilizado para
raw e long raw
                   armazenar dados binários (sons, imagens, etc.) Limite: 2.000 bytes.
number (p,e)       Valores numéricos. Ex: number (5,2) armazena -999,99 a +999,99.
date               Armazena data e hora (inclusive minuto e segundo). Ocupam 7 bytes.

                                  CONSTRAINTS / RESTRIÇÕES
        Nome                                           Uso
                   Informa se o campo pode receber valores nulos. Caso não possa, deve ser
null
                   precedido de not.
                   Indica que os valores na coluna, ou conjunto de colunas, não pode ser
unique
                   repetido. Cria um índice automaticamente.
check              Especifica os valores que uma coluna pode assumir.
primary key        Identifica a chave primária da tabela. Cria um índice automaticamente.
                   Identifica a chave estrangeira da tabela. Implementada pela cláusula
foreign key
                   references.
MODELAGEM EM BANCO DE DADOS   17
MODELAGEM EM BANCO DE DADOS   18
MODELAGEM EM BANCO DE DADOS                                                                19


NORMALIZAÇÃO
•   Conceito introduzido em 1970 por E. F. Codd (1FN).
•   Processo matemático formal com fundamento na teoria dos conjuntos.

O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados
para verificar se estas foram corretamente projetadas.

Objetivos principais:
•   Garantir a integridade dos dados, evitando que informações sem sentido sejam inseridas.
•   Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a redundância e
    permitindo a evolução do banco de dados.

São seis as formas normais mais conhecidas:
•   1FN – 1ª Forma Normal
•   2FN – 2ª Forma Normal
•   3FN – 3ª Forma Normal
•   FNBC – Forma Normal de Boyce e Codd
•   4FN – 4ª Forma Normal
•   5FN – 5ª Forma Normal
Nota: As três primeiras formas normais atendem à maioria dos casos de normalização.
Uma forma normal engloba todas as anteriores, i.e., para que uma tabela esteja na 2FN, ela
obrigatoriamente deve estar na 1FN e assim por diante.
Normalmente após a aplicação das regras de normalização, algumas tabelas acabam sendo
divididas em duas ou mais tabelas. Este processo colabora significativamente para a
estabilidade do modelo de dados e reduz consideravelmente as necessidades de manutenção.

Conceitos úteis:

1. Chaves
•   Chave candidata: Atributo ou conjunto de atributos que são únicos para cada registro.
    Para cada tabela podemos ter uma ou várias chaves desse tipo. Exemplo: codigo e cpf.
•   Chave primária: Entre as chaves candidatas, escolhemos uma para ser o identificador
    principal da tabela. Este atributo passa a ser chamado de chave primária (PK – Primary
    Key).
•   Chaves alternativas: São as chaves candidatas que não foram definidas como chave
    primária.
•   Chave estrangeira: É o atributo ou conjunto de atributos que faz a ligação com a chave
    primária de outra tabela (FK – Foreign Key).

2. Dependência Funcional (DF)
  Sempre que um atributo X identifica um atributo Y, dizemos que entre eles há uma
dependência funcional. Temos, portanto, que X é o determinante e que Y é o
dependente. A representação é: X Y (lê-se X determina Y ou Y é dependente de X).
    cidade   estado
    estado   país
   Em outras palavras, estado é funcionalmente dependente de cidade e país é fincionalmente
dependente de estado. Ou ainda, estado é dependente de cidade e país é dependente de
estado. E por último, cidade determina estado e estado determina país.

3. Trivialidade
   A dependência funcional trivial indica que um determinante com mais de um atributo pode
determinar seus próprios membros quando isolados.
MODELAGEM EM BANCO DE DADOS                                                                  20


  {banco, agência}      banco      DF trivial: banco é parte do determinante
  {banco, agência}      agência    DF trivial: agência é parte do determinante
   Quando um determinante identifica outro atributo qualquer, temos uma dependência
funcional não trivial (essa DF é a que nos interessa no processo de normalização):
  {banco, agência}      cidade        DF não trivial: cidade não faz parte do determinante

4. Transitividade
   Se um atributo X determina Y e se Y determina Z, podemos dizer que X determina Z de
forma transitiva. i.e., existe uma dependência funcional transitiva de X para Z.
  cidade      estado
  estado      país
  ciade    país (cidade determina país de forma transitiva)

5. DF (Dependência Funcional) irredutível à esquerda
   Dizemos que o lado esquerdo de uma dependência funcional é irredutível quando o
determinante está em sua forma mínima. Temos a forma mínima quando não é possível
reduzir a quantidade de atributos determinantes sem perder a dependência funcional.
  {cidade, estado}      país     (não está na forma irredutível à esquerda, pois podemos ter
                                 somente o estado como determinante)
  estado      país               (forma irredutível à esquerda)

  Nota: Nem sempre estar na forma irredutível à esquerda significa possuir um determinante
com apenas uma coluna.

6. DMV (Dependência Multivalorada)
   A DMV é uma ampliação da Dependência Funcional (DF). Na DMV o valor de um atributo
determina um conjunto de valores de um outro atributo.
É representada por X      Y (X multideterina Y ou Y é multidependente de X).
DF:   {CPF}    {Nome}              Temos somente um nome para cada CPF
DMV: {CPF}       {Dependente}      Temos vários dependentes para cada pessoa
MODELAGEM EM BANCO DE DADOS                                                            21


Primeira Forma Normal:
Uma Tabela está na Primeira Forma Normal quando seus atributos não contêm grupos de
repetição (tabelas aninhadas).
Proj(CodProj,Desc(CodFunc,Nome,Salario,DtInicio))      Não está na 1FN
Proj(CodProj,Desc)

ProjFunc(CodProj,CodFunc,Nome,Salário,DtInicio)        Está na 1FN

Segunda Forma Normal:
Ocorre quando a chave primária é composta por mais de uma coluna. Neste caso, devemos
observar se todos as colunas que não fazem parte da chave dependem de todos os colunas
que compõem a chave. Se alguma coluna depender somente de parte da chave composta
(dependência funcional parcial), então esta coluna deve pertencer a outra tabela.
ProjFunc(CodProj,CodFunc,Nome,Cargo,Salario,DtInicio)       Não está na 2FN
ProjFunc(CodProj,CodFunc,DtInicio)

Func(CodFunc,Nome,Cargo,Salario)                            Está na 2FN

Terceira Forma Normal:
Uma tabela está na Terceira Forma Normal quando cada coluna não chave depende
diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou
indiretas. Uma dependência funcional transitiva acontece quando uma coluna não chave
primária depende funcionalmente de outra coluna ou combinação de colunas não chave
primária.
Func(CodFunc,Nome,Cargo,Salario)                            Não está na 3FN
Func(CodFunc,Nome,Cargo)

Cargo(Cargo,Salario)                                        Está na 3FN

Forma Normal de Boyce-Codd
A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de
qualquer chave (primária ou candidata). Aplica-se a FNBC quando:
•   Encontramos duas ou mais chaves candidatas
•   As chaves candidatas são compostas (apresentam mais de um atributo)
•   Todas as chaves candidatas têm um atributo em comum
Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e
irredutível à esquerda tem uma chave candidata como determinante.
No exemplo a seguir vamos assumir que um professor possa estar associado a mais de uma
Escola e uma sala.
Aluno(NomeAluno,EnderecoAluno,NomeEscola,NumeroSala,NomeProfessor)

Chaves candidatas:
  NomeAluno+EnderecoAluno            Encontramos três chaves candidatas
  NomeAluno+NumeroSala               Todas apresentam mais de um atriobuto (concatenados)
  NomeAluno+NomeProfessor            Todas compartilham um mesmo atributo: NomeAluno
Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas, uma que contém
todos os atributos que descrevem o aluno e outra que contém os atributos que designam um
professor em uma determinada escola e número de sala.
Aluno(NomeAluno,EnderecoAluno,NomeEscola,NumeroSala)
Sala(NomeEscola,NumeroSala,NomeProfessor)
MODELAGEM EM BANCO DE DADOS                                                                          22


Quarta Forma Normal:
Uma tabela está na Quarta Forma Normal caso não possua mais de uma dependência funcional
multivalorada.

 CodProj     CodFunc      CodEquip              CodProj     CodFunc           CodProj   CodEquip
    1             1           1                     1           1               1            1
    1             2           1                     1           2               1            2
    1             1           2                     2           1               2            1
    1             2           2                                                 2            2
    2             1           1
    2             1           2

CodProj multidetermina de forma independente CodFunc e CodEquip.

Quinta Forma Normal
Aplicada em casos de relacionamentos múltiplos (ternários ... n-ários). Trata do conceito de
dependência de junção. Primeiro decompõe-se a tabela através de uma operação de projeção
e em seguida faz-se a reconstrução da mesma através de uma junção.
A tabela está na Quinta Forma Normal quando seu conteúdo não puder ser reconstruído
através da junção destas tabelas secundárias.

Material    Pedido Requisicao        Material Pedido      Pedido Requisicao    Material Requisicao
   1          1          1              1       1           1         1             1        1
   1          2          2              1       2           2         2             1        2
   2          1          2              2       1           1         2             2        2
   1          1          2

Reconstruindo o conteúdo da tabela original através da junção natural das tabelas
secundárias:

1º passo – Junção da tabela MaterialPedido com PedidoRequisicao:

 Material   Pedido     Requisicao
    1         1            1
    1         1            2
    1         2            2
                                      Esta linha não aparece na tabela gerada no 2º passo
    2         1            1
    2         1            2

2º passo – Junção da tabela PedidoRequisicao com MaterialRequisicao:

 Material   Pedido     Requisicao
    1         1            1
    1         2            2
                                      Esta linha não aparece na tabela gerada no 1º passo
    2         2            2
    1         1            2
    2         1            2

3º passo – Interseção das duas tabelas (geradas no 1º e no 2º passo):

 Material   Pedido     Requisicao
    1         1            1         O conteúdo desta tabela é o mesmo da tabela original.
    1         1            2
    1         2            2
    2         1            2
MODELAGEM EM BANCO DE DADOS                                                                                                                 23


NORMALIZAÇÃO PASSO A PASSO

CASE 1: 1FN, 2FN E 3FN

   Exemplo: em uma determinada empresa, os produtos recebidos de um fornecedor são
registrados em um formulário próprio que pode ser visualizado a seguir:

                                      NOTA DE FORNECIMENTO DE MERCADORIA
Data                     24/08/2004                                                           Nº da Nota:          001
                                                          Fornecedor
      CodForn                              Nome                    Telefone                                Endereço
        25               ABC Ltda                               011 5555-1111                 Rua Direita, 12
                                                             Item
      CodItem                   CodProd           Produto         Quantidade                       Preço               Total Item
         1                        CA         Chapa de aço             35                           15,00                      525,00
         2                        BB         Bobina                   20                           15,00                      300,00
         3                        TC         Tábuas Corridas          50                           20,00                   1.000,00

                                      NOTA DE FORNECIMENTO DE MERCADORIA
Data                     25/08/2004                                                           Nº da Nota:          002
                                                          Fornecedor
      CodForn                              Nome                    Telefone                              Endereço
        32               XYZ Ltda                               011 5555-2222                 Rua Esquerda, 13
                                                             Item
      CodItem                   CodProd           Produto         Quantidade                       Preço               Total Item
         1                        TC         Tábuas Corridas          50                           20,00                   1.000,00
         2                        CM         Compensado               30                           15,00                      450,00
         3                        RM         Ripas de Madeira        300                           2,00                       600,00

                                      NOTA DE FORNECIMENTO DE MERCADORIA
Data                     26/08/2004                                                           Nº da Nota:          003
                                                          Fornecedor
      CodForn                              Nome                    Telefone                                Endereço
        25               ABC Ltda                               011 5555-1111                 Rua Direita, 12
                                                             Item
      CodItem                   CodProd           Produto         Quantidade                       Preço               Total Item
         1                        CA         Chapa de aço             50                           15,00                      750,00
         2                        BB         Bobina                   20                           15,00                      300,00


   Vamos informatizar esse processo criando uma base de dados para armazenar as
informações deste formulário.
   A primeira versão pode ser vista a seguir. Essa estrutura ainda não pode ser carregada em
um banco de dados relacional, pois possui campos multivalorados (CodItem, CodProd,
Produto, Qtde, Preço, Total Item).

NrNota       Data     CodForn      Nome     Telefone       Endereço       CodItem   CodProd        Produto      Qtde   Preço    TotalItem
                                                                             1        CA      Chapa de aço        35    15,00      525,00
    001    24/08/04     25      ABC Ltda   5555-1111   Rua Direita, 12       2        BB      Bobina              20    15,00      300,00
                                                                             3        TC      Tábua corrida       50    20,00    1.000,00
                                                                             1        TC      Tábua corrida       50    20,00    1.000,00
    002    25/08/04     32      XYZ Ltda   5555-2222   Rua Esquerda, 13      2        CM      Compensado          30    15,00      450,00
                                                                             3        RM      Ripa de madeira    300     2,00      600,00
                                                                             1        CA      Chapa de aço        50    15,00      750,00
    003    26/08/04     25      ABC Ltda   5555-1111   Rua Direita, 12
                                                                             2        BB      Bobina              20    15,00      300,00


1ª Forma Normal (1FN)

  O primeiro passo para normalizar a estrutura é aplicar as regras da primeira forma normal.
Uma entidade está na primeira forma normal quando cada atributo contém somente um valor,
em somente um lugar. Essa exigência é também conhecida como atomicidade de dados.
  As regras gerais para obtenção da 1FN são:
•         Não podemos ter atributos multivalorados. Nesse caso, colocamos cada valor do atributo
          em uma linha diferente e repetimos os dados de todas as outras colunas.
•         Não podemos ter atributos repetidos, como Telefone1, Telefone2, etc. A solução é
          semelhante ao item anterior.
MODELAGEM EM BANCO DE DADOS                                                                                                                   24


•    Todos os registros têm de ser diferentes
•    A entidade não pode ter mais de duas dimensões
•    Cada atributo deve ter somente um tipo de dado. Uma violação comum dessa regra, por
     exemplo, é a criação de um campo para armazenar o CPF e o CNPJ, alternadamente. Esse
     cenário deve ser evitado pois cria complicações para a evolução da regra de negócio.
    Observe a tabela gerada após a aplicação da FN1:

NrNota     Data     CodForn      Nome       Telefone         Endereço       CodItem   CodProd        Produto      Qtde   Preço    TotalItem
 001     24/08/04     25      ABC Ltda     5555-1111   Rua   Direita, 12       1        CA      Chapa de aço        35    15,00      525,00
 001     24/08/04     25      ABC Ltda     5555-1111   Rua   Direita, 12       2        BB      Bobina              20    15,00      300,00
 001     24/08/04     25      ABC Ltda     5555-1111   Rua   Direita, 12       3        TC      Tábua corrida       50    20,00    1.000,00
 002     25/08/04     32      XYZ Ltda     5555-2222   Rua   Esquerda, 13      1        TC      Tábua corrida       50    20,00    1.000,00
 002     25/08/04     32      XYZ Ltda     5555-2222   Rua   Esquerda, 13      2        CM      Compensado          30    15,00      450,00
 002     25/08/04     32      XYZ Ltda     5555-2222   Rua   Esquerda, 13      3        RM      Ripa de madeira    300     2,00      600,00
 003     26/08/04     25      ABC Ltda     5555-1111   Rua   Direita, 12       1        CA      Chapa de aço        50    15,00      750,00
 003     26/08/04     25      ABC Ltda     5555-1111   Rua   Direita, 12       2        BB      Bobina              20    15,00      300,00



   Para trabalhar com a 2FN precisamos definir uma chave primária. Na tabela recém-criada, a
chave escolhida é formada pelos campos NrNota e CodItem, pois através deles detrminamos
todos os outros campos. Por exemplo:
    Com NrNota, determinamos os campos Data, CodForn, Nome, Telefone e Endereço:
    NrNota           {Data, CodForn, Nome, Telefone, Endereço}
    Com NrNota e CodItem determinamos os demais campos:
    {NrNota, CodItem}                    {CodProd, Produto, Qtde, Preço, TotalItem}

2ª Forma Normal (2FN)

  Essa forma normal visa a diminuição da redundância e o desagrupamento de informações.
Com a 2FN, uma tabela passa a representar uma quantidade menor de entidades (o ideal é
que cada entidade seja armazenada em apenas uma tabela). A tabela anterior agrupa as
entidades: Nota Fiscal, Item da Nota Fornecedor e Produto.
   A definição da segunda forma normal é: uma tabela está em 2FN se estiver em 1FN e todo
atributo não-chave for determinado por todos os campos da chave primária. Em outras
palavras, é necessário eliminar as dependências funcionais parciais.
   A tabela anterior viola a 2FN pois os campos Data, CodForn, Nome, Telefone e Endereço
não são determinados pela chave primária completa (o campo CodItem não é necessário para
identificar essas informações).
    NrNota           {Data, CodForn, Nome, Telefone, Endereço}
    Como regra geral, a 2FN deve ser aplicada através dos passos:
1. Eleger a chave primária da tabela;
2. Verificar as dependências funcionais parciais;
3. Mover os campos não enquadrados na 2FN para uma nova tabela, fazendo a decomposição
   sem perdas;
4. Na tabela criada, repetir os passos 1 a 4 até eliminar a DF parcial.
   O resultado pode ser observado a seguir. Observe que todos os campos, nas duas tabelas
são agora determinados por suas chaves primárias completas – garantindo a 2FN. Note
também que o resultado da aplicação desta forma normal são tabelas mais simples, que
representam as entidades com mais proximidade.

                                          tabela 1
NrNota        Data        CodForn          Nome    Telefone                Endereço
 001        24/08/04        25           ABC Ltda 5555-1111            Rua Direita, 12
 002        25/08/04        32           XYZ Ltda 5555-2222            Rua Esquerda, 13
 003        26/08/04        25           ABC Ltda 5555-1111            Rua Direita, 12
MODELAGEM EM BANCO DE DADOS                                                                25



                                 tabela 2
NrNota    CodItem   CodProd        Produto      Qtde   Preço TotalItem
 001         1        CA      Chapa de aço        35   15,00    525,00
 001         2        BB      Bobina              20   15,00    300,00
 001         3        TC      Tábua corrida       50   20,00  1.000,00
 002         1        TC      Tábua corrida       50   20,00  1.000,00
 002         2        CM      Compensado          30   15,00    450,00
 002         3        RM      Ripa de madeira    300     2,00   600,00
 003         1        CA      Chapa de aço        50   15,00    750,00
 003         2        BB      Bobina              20   15,00    300,00


3ª Forma Normal (3FN)

   A 3FN dá continuidade ao objetivo da 2FN: reduzir as redundâncias, desagrupando as
tabelas de forma que cada uma represente apenas uma entidade. No exemplo acima, a tabela
1 agrupa informações sobre as entidades Nota e Fornecedor e a tabela 2 agrupa informações
sobre as entidades ItemNota e Produto.
  A técnica utilizada pela 3FN é a identificação e eliminação da transitividade. Dizemos que
uma tabela está na 3FN se também estiver na 2FN e todo atributo não chave for determinado
de uma forma não transitiva pela chave primária. Em outra leitura, dizemos que todo atributo
não chave deve ser determinado somente pela chave primária.
  Vamos analisar a tabela criada na 2FN. Observe que os campos Nome, Telefone e Endereço
podem ser determinados tanto pela chave primária quanto pelo campo CodForn:
  NrNota        {Data, CodForn, Nome, Telefone, Endereço}
  CodForn        {Nome, Telefone, Endereço}
  Assim esses campos possuem dependência funcional transitiva com a chave primária:
  NrNota        CodForn       {Nome, Telefone, Endereço}
  Na segunda tabela também temos transitividade:
  {NrNota, CodItem}            CodProd      {Produto, Preço}
   Outro tipo de violação da 3FN são os campos calculados, que também possuem
transitividade. Na 3FN todos os campos calculados são removidos da base de dados. Veja a
representação:
  {NrNota, CodItem}            Preço, Quantidade        {TotalItem}
  Para adequar as tabelas a 3FN, seguimos um roteiro semelhante ao usado na 2 FN:
1. Mover os campos com transitividade para uma nova tabela;
2. Criar uma chave primária na tabela nova com o(s) campo(s) da tabela original que
   determinava(m) diretamente os campos movidos.
3. Na nova tabela, repetir os passos 1, 2 e 3, até eliminar totalmente a transitividade.
  Observe a seguir o formato final das tabelas após a aplicação da 3FN.

              Tabela Fornecedor
CodForn   Nome      Telefone    Endereço
  25    ABC Ltda 5555-1111 Rua Direita, 12
  32    XYZ Ltda 5555-2222 Rua Esquerda, 13

          Tabela Produto
CodProd         Produto       Preço
  CA       Chapa de aço       15,00
  BB       Bobina             15,00
  TC       Tábua corrida      20,00
  CM       Compensado         15,00
  RM       Ripa de madeira      2,00
MODELAGEM EM BANCO DE DADOS                                                               26


       Tabela Nota
NrNota    Data    CodForn
 001    24/08/04    25
 002    25/08/04    32
 003    26/08/04    25

         Tabela Item Nota
NrNota    CodItem CodProd     Qtde
 001         1        CA        35
 001         2        BB        20
 001         3        TC        50
 002         1        TC        50
 002         2       CM         30
 002         3       RM        300
 003         1        CA        50
 003         2        BB        20


  Nesse ponto temos a organização ideal para a base de dados, pelos motivos a seguir:
1. A decomposição foi feita sem perdas (através de junções podemos recuperar a tabela
   original);
2. As quatro entidades (Nota, ItemNota, Fornecedor e Produto) possuem tabelas exclusivas,
   eliminando o agrupamento de informações e a redundância;
3. As tabelas foram separadas de tal forma que as anomalias de atualização não poderão
   ocorrer;
4. As tabelas são fáceis de evoluir e manter. Por exemplo, se quisermos incluir dados de um
   produto que ainda não tenha sido fornecido, podemos inserir sua descrição na tabela
   Produtos (isso não era possível até a aplicação da 3FN);
5. Do ponto de vista relacional, os dados estão armazenados e distribuídos de forma eficiente.

CASE 2: 4FN

  Um condomínio deseja cadastrar os veículos e os motoristas que os dirigem (para cada
apartamento):

Apto     Nome       Placa
101       João    GBD-2541
101       João    GHJ-5468
101      Maria    GBD-2541
101      Maria    GHJ-5468
101      Carlos   GBD-2541
101      Carlos   GHJ-5468
102      Paulo    GDA-7677
102       Rosa    GDA-7677

  Placa       Carro    Ano
GBD-2541      Siena    2003
GHJ-5468      Parati   2002
GDA-7677      Fusca    1990

Nome      Idade
 João       55
Maria       50
Carlos      22
Paulo       57
 Rosa       56


A primeira tabela contém anomalias de atualização. Se o apartamento 101 comprar mais um
carro, precisaremos inserir mais três linhas na primeira tabela. Se o apartamento 102 vender o
carro perderemos a informação de quem mora no referido apartamento.

Estas anomalias ocorrem porque temos duas DMVs independentes:
{Apto}       {Nome}
{Apto}       {Placa}
MODELAGEM EM BANCO DE DADOS                                                          27


Ou como aparece em algumas bibliografias:
{Apto}       {Nome}|{Placa}

Para deixarmos a tabela na 4FN devemos efetuar a decomposição sem perdas e levar cada
DMV para uma tabela diferente.

Apto     Nome
101       João
101      Maria
101      Carlos
102      Paulo
102       Rosa

Apto       Placa
101      GBD-2541
101      GHJ-5468
102      GDA-7677

Nome      Idade
 João       55
Maria       50
Carlos      22
Paulo       57
 Rosa       56

  Placa       Carro      Ano
GBD-2541      Siena      2003
GHJ-5468      Parati     2002
GDA-7677      Fusca      1990


Note que a primeira tabela pode ser unida à terceira tabela e que a segunda tabela também
pode ser unida à quarta tabela. Ou seja, a normalização nem sempre leva ao formato ideal
exigindo sempre uma análise do seu resultado.

Apto     Nome       Idade
101       João        55
101      Maria        50
101      Carlos       22
102      Paulo        57
102       Rosa        56

Apto       Placa       Carro    Ano
101      GBD-2541      Siena    2003
101      GHJ-5468      Parati   2002
102      GDA-7677      Fusca    1990


BIBLIOGRAFIA

SQL Magazine – Edições 6 e 7
MODELAGEM EM BANCO DE DADOS                                                                 28


ÁLGEBRA RELACIONAL
•        Desenvolvida para descrever operações sobre uma base de dados relacional
•        Cada operador toma uma ou duas relações como sua entrada e produz uma nova relação como
         sua saída
•        Linguagem da consulta teórica, usuários não a utilizam diretamente
•        É usada internamente em todos os SGBDRs

Características:
•        Constituída de cinco operadores fundamentais:

                             σ
                   Seleção           (sigma)

                                 π
                   Projeção          (pi)

                   Produto cartesiano X

                   Diferença –

                           ∪
                   União

•        Três operadores derivados:

                                     ∩
                   Intersecção

                   Junção

                             :
                   Divisão

SELEÇÃO
Seleciona todas as tuplas que satisfazem à condição de seleção de uma relação R.

                                      σ (A=’a1’)(R)
          R
    A         B                        A         B
    a1        b1                       a1        b1
    a2        b2

PROJEÇÃO
Produz uma nova relação com apenas alguns atributos de R, removendo as tuplas duplicadas.

                                      π (B)(R)
          R
    A         B                          B
    a1        b1                         b1
    a2        b2                         b2

PRODUTO CARTESIANO
Produz uma nova relação com todas as possíveis tuplas resultantes da combinação de duas tuplas,
uma de cada relação envolvida na operação.

          R                                      (R X S)
    A         B                        A         B    C    D
    a1        b1                       a1        b1   c2   d2
    a2        b2                       a1        b1   c3   d3
                                       a2        b2   c2   d2
          S
                                       a2        b2   c3   d3
    C         D
    c2        d2
    c3        d3
MODELAGEM EM BANCO DE DADOS                                                             29


DIFERENÇA
Produz uma nova relação com todas as tuplas em R que não estão em S. R e S devem ter número
iguais de atributos.

      R                   (R - S)
 A        B              A       B
 a1       b1             a1      b1
 a2       b2
      S
 A        B
 a2       b2
 a3       b3

UNIÃO
Produz uma nova relação com a união das tuplas em R e em S. R e S devem ter número iguais de
atributos.

                              ∪ S)
      R                  (R
 A        B              A       B
 a1       b1             a1      b1
 a2       b2             a2      b2
                         a3      b3
      S
 A        B
 a2       b2
 a3       b3

INTERSECÇÃO
Produz uma nova relação com a intersecão das tuplas em R e em S, ou seja, com as tuplas que
aparecem em R e em S. R e S devem ter número iguais de atributos.

                              ∩ S)
      R
                         (R
 A        B              A       B
 a1       b1             a2      b2
 a2       b2
      S
 A        B
 a2       b2
 a3       b3

JUNÇÃO
Junção de R com S = (R X S) [expressão de seleção]

      R                        R X S [B = C]
 A        B              A       B     C       D
 a1       b1             a1      b1    b1      d3
 a2       b2             a2      b2    b2      d2
      S
 C        D
 b2       d2
 b1       d3
MODELAGEM EM BANCO DE DADOS                                                             30


JUNÇÃO NATURAL
Quando a condição de junção for a igualdade do valor de um atributo comum e o atributo comum
aparecer só uma vez no resultado.

         R                             R*S
    A        B                    A    B     D
    a1       b1                   a1   b1    d3
    a2       b2                   a2   b2    d2
         S
    C        D
    b2       d2
    b1       d3

DIVISÃO
Produz uma nova relação S contendo todas as tuplas de A (dividendo) que aparecem em R
(mediador) com todas as tuplas de B (divisor).

    A                         R                   B        S
    A                  A          B               B       A
    a1                 a1         b1              b1      a1
    a2                 a1         b2                      a2
    a3                 a1         b3
    a4                 a1         b4
                                                  B        S
    a5                 a2         b1
                       a2         b2              B       A
                       a3         b2              b2      a1
                       a4         b2              b4      a4
                       a4         b4
                                                  B        S
                                                  B       A
                                                  b1      a1
                                                  b2
                                                  b3
                                                  b4

SOFTWARE

WinRDBI (Windows Relational DataBase Interpreter)
http://www.eas.asu.edu/~winrdbi/
Arizona State University
•        Relational Algebra
•        Domain Relational Calculus
•        Tuple Relational Calculus
•        SQL
MODELAGEM EM BANCO DE DADOS                                                                     31


CÁLCULO RELACIONAL

    Alternativa à Álgebra Relacional
    Logicamente equivalentes
    Baseia-se em um ramo da lógica matemática chamado cálculo de predicados

    Referências bibliográficas:
    Cálculo relacional como base para uma linguagem de consulta: J.L.Kuhns: “Answering
    Questions by Computer: A Logical Study.” (1967)
    Cálculo de predicados adaptados especificamente a banco de dados relacionais: E.F.Codd:
    “A Relational Model of Data for Large Shared Data Banks.” (1970)

    Cálculo Relacional: descreve qual é o problema (não procedural).

    Álgebra Relacional: Prescreve um procedimento para resolver o problema (procedural).

CÁLCULO RELACIONAL DE TUPLA

  É baseado na especificação de um conjunto de variáveis de tuplas. Cada variável de tupla
pode assumir como seu valor qualquer tupla da relação especificada.

Forma geral:




•   Variável livre: Assume velores de tuplas de uma ou mais relações. Constitui a resposta da
    consulta.
•   Predicado: Expressão lógica que, se verdadeira para determinados valores das variáveis
    livres t, v, ..., x, retorna os valores destas variáveis na resposta da consulta.

EXEMPLOS – SELEÇÃO E PROJEÇÃO:

1. Buscar os dados dos pacientes que estão com sarampo:

          ∈                ∧
{p | p        Pacientes        p.doenca = 'sarampo'}

2. Buscar o número e a capacidade dos ambulatórios do terceiro andar

                                    ∈                       ∧
{a.numero, a.capacidade | a              Ambulatorios           a.andar = 3}

EXEMPLOS – PRODUTOS OU JUNÇÃO:

1. Buscar o nome dos médicos que têm consulta marcada e as datas das suas consultas:

                           ∈             ∧       ∈               ∧
{m.nome, c.data | m            Medicos       c       Consultas       m.crm = c.crm}

2. Buscar os nomes dos médicos ortopedistas e o número e andar dos ambulatórios onde eles
   atendem:

                                         ∈              ∧                                   ∧
{m.nome, a.numero, a.andar | m               Medicos        m.especialidade = 'ortopedia'
    ∈                  ∧
a       Ambulatorios       m.numero = a.numero}
MODELAGEM EM BANCO DE DADOS                                                                            32



QUANTIFICADORES EXISTENCIAIS:

∃ exists
∀ forall

   QUANTIFICADOR EXISTENCIAL

∃ v (P)
Existe pelo menos um valor v que torna P verdadeira.


   QUANTIFICADOR UNIVERSAL

∀ v (P)
Para todos os valores de v, P é verdadeira.
EXEMPLO: Suponha que a variável v percorra o conjunto Senado, e suponha que P seja a FBF *
quot;v é mulherquot;, então:

∃ v (P)    verdadeiro

∀ v (P)    falso
* FBF = Fórmula Bem Formada

EXEMPLOS – QUANTIFICADOR EXISTENCIAL:

1. Buscar o nome dos médicos que atendem em ambulatórios do segundo andar:

                   ∈             ∧∃       ∈                                ∧
                                              Ambulatorios (a.andar = 2
{m.medico | m          Medicos        a                                        m.numero =
a.numero)}

2. Buscar o nome e o problema dos pacientes de têm consulta marcada com o médico João da
   Silva:

                              ∈ Pacientes ∧ ∃ c ∈ Consultas (p.rg                       ∧∃       ∈
                                                                               = c.rg
{p.nome, p.problema | p                                                                      m
                             ∧ c.nome = 'Joao da Silva'))}
Medicos (c.crm = m.crm

EXEMPLOS – QUANTIFICADOR UNIVERSAL:

1. Buscar o nome dos médicos que têm consulta marcada com todos os pacientes:

                   ∈             ∧∀       ∈                    ∈                                 ∧
                                              Pacientes (∃ c       Consultas (p.rg = c.rg
{m.medico | m          Medicos        p                                                              c.crm
= m.crm))}

2. Buscar o nome dos pacientes de têm consulta marcada com todos os médicos ortopedistas:

              ∈                ∧ ∀ m ∈ Medicos (m.especialidade                                  ∃c∈
{p.nome | p        Pacientes                                              = 'ortopedia'
                         m.crm ∧ c.rg = p.rg))}
Consultas (c.crm =
MODELAGEM EM BANCO DE DADOS                                                               33


CÁLCULO RELACIONAL DE DOMÍNIO

   No CRD as variáveis estendem-se sobre valores únicos de domínios de atributos. Para
formar uma relação de grau n para um resultado de consulta, faz-se necessário criar n
variáveis de domínio, uma para cada atributo.

Forma geral:




•   Variáveis de domínio: Abrangem os valores únicos dos domínios dos atributos. Devemos
    ter n destas variáveis de domínio, uma para cada atributo.
• Fórmula: São constituídas a partir de átomos, variáveis e quantificadores.
EXEMPLOS:

1. Buscar o nome da agência, número da conta que têm saldo superior a 1200 reais:

                       ∈             ∧
{a, c, s | a, c, s          Contas       s > 1200}

2. Buscar os nomes de todos os clientes que tenham uma conta em todas as agências
   localizadas na Aclimação:

                               ∈              ∧                     ∃ a, b (x, a, b ∈ Contas
{ c | ∀ x, y, z (x, y, z           Agencias       y = 'Aclimacao'
∧          ∈
    c, a       Clientes)}

NOTA: Enquanto a SQL (baseada no Cálculo Relacional de Tupla) estava sendo desenvolvida
pela IBM Research em San Jose, Califórnia, outra linguagem, chamada QBE (Query By
Example (baseada no Cálculo Relacional de Domínio) estava sendo desenvolvida quase
simutaneamente pela IBM Research em Yorktown Heights, Nova York.
MODELAGEM EM BANCO DE DADOS                                                              34


EXERCÍCIOS

Sistema Bancário

Em sistema bancário simplificado temos: Clientes, onde cada cliente tem CPF, RG, nome,
endereço, telefone e estado civil. Um cliente pode ter mais de uma conta em agências
distintas. As agências possuem código da agência, nome, endereço e nome do gerente. Sobre
as contas tem-se número da conta e saldo atualizado. Uma conta é gerenciada por uma única
agência. Os clientes podem movimentar suas contas, na movimentação deve constar sobre o
tipo (crédito ou débito), quantia, data e hora.

Sistema Locadora

Uma pequena locadora de vídeos possui ao redor de 2000 fitas de vídeo, cujo empréstimo
deve ser controlado.
Cada fita possui um número. Para cada filme, é necessário saber seu título e sua categoria
(comédia, drama, aventura, ... ). Cada filme recebe um identificador próprio. Cada fita é
controlado que filme ela contém. Para cada filme há pelo menos uma fita, e cada fita contém
somente um filme. Alguns poucos filmes necessitam mais de uma fita.
Os clientes podem desejar encontrar os filmes estrelados pelo seu ator predileto. Por isso, é
necessário manter a informação dos atores que estrelam em cada filme. Nem todo filme possui
estrelas. Para cada ator os clientes às vezes desejam saber o nome real, bem como a data de
nascimento.
A locadora possui muitos clientes cadastrados. Somente clientes cadastrados podem alugar
fitas. Para cada cliente é necessário saber seu prenome e seu sobrenome, seu telefone e seu
endereço. Além disso, cada cliente recebe um número de associado.
Finalmente desejamos saber que fitas cada cliente tem emprestadas. Um cliente pode ter
várias fitas em um instante do tempo. Não são mantidos registros históricos de aluguéis.

Sistema Cinema

Projetar um modelo de dados que atenda às necessidades de controle dos cinemas e filmes em
uma determinada empresa de distribuição de filmes.
Regras de negócio que serão a base para o desenvolvimento do DER:
A empresa de distribuição possui vários cinemas em várias localidades.
Cada cinema possui identificação única, um nome fantasia, um endereço, etc.
Cada filme é registrado com um título original, tempo de duração, etc.
Existirá um único diretor para cada filme.
Cada filme terá vários atores.
As sessões possuem horários variados.
Os atores de um filme podem atuar em diversos filmes, assim como o diretor de um filme pode
também ser ator neste filme, ou ainda mais, ser ator em outro filme. Um ator possui número,
nome, nacionalidade e idade.

Sistema Escola

Uma escola mantém em seu catálogo vários cursos livres (Windows, Word, etc.).
Professores são contratados para ministrar um ou mais cursos.
Há várias turmas para cada curso. Cada turma tem um professor.
Um aluno pode matricular-se simultaneamente em vários cursos e, portanto, pertencer a mais
de uma turma.
Elabore um DER completo para o caso acima.
MODELAGEM EM BANCO DE DADOS                                                               35


Sistema Museu de Arte

Projete o DER para um museu de arte, conforme as seguintes informações coletadas:
O museu tem uma coleção de objetos de arte. Cada objeto tem um número, um artista (se
conhecido), um ano (quando foi criado, se conhecido), um título e uma descrição.
Os objetos de arte são categorizados de diversas formas de acordo com o seu tipo. Há três
tipos principais: pintura, escultura e estátua, mais um chamado outros para comodar objetos
que não se enquadram em algum dos três tipos principais.
Uma pintura tem um tipo (óleo, guache, etc.), material (papel, tela, madeira, etc.) e estilo
(moderno, abstrato, etc.).
Uma escultura tem o material do qual foi criado (madeira, pedra, etc.) e estilo.
Um objeto de arte na categoria outros tem um tipo (impressão, foto, etc.) e estilo.
Um objeto de arte também é categorizado como coleção permanente que é de propriedade do
museu (com as informações de data de aquisição, se está exposto ou guardado e preço) ou
empréstimo, do qual tem informações da coleção (da qual foi emprestado), data de
empréstimo e data de devolução.
Cada objeto de arte tem também a descrição de seu país/cultura de origem (iteliano, egípcio,
americano, etc.) e época (renascimento, moderna, antiga, etc.).
O museu mantém informações sobre artistas, quando conhecidos: nome, data de nascimento,
data de falecimento (se não-vivo), país de origem, época, estilo principal e descrição. Nome é
assumido como sendo único.
Diferentes exibições ocorrem, cada uma tem um nome, data de início e data de término, e é
relacionada a todos os objetos de arte que estão à mostra durante a exibição.
Mantêm-se também informações de outras coleções com a qual o museu interage, incluindo
nome (único), tipo (museu, pessoal, etc.), descrição, endereço, telefone e pessoa de contato.

Sistema Empresa

Uma empresa é organizada em departamentos. Cada departamento possui um nome e um
código único, e o departamento pode ter várias localidades (cidades). Os projetos existentes
na empresa são, obrigatoriamente, controlados por um departamento, e cada projeto possui
um nome, um código único e uma única localização (cidade), que pode ser diferente das
possíveis localidades do departamento que o controla. Alguns departamentos não possuem
projetos sobre sua responsabilidade, como por exemplo o “departamento pessoal”.
No caso dos empregados da empresa é armazenado número de matricula, nome, endereço,
salário, sexo e data de nascimento. Quase todos os empregados tem um outro empregado que
é o seu supervisor direto, e consequentemente, somente alguns são supervisores, conforme a
sua hierarquia na empresa. Em função da cadeia hierárquica existem empregados que não
possuem supervisores.
A maioria dos empregados são alocados a um departamento, ou seja, pode até existir um
empregado sem departamento, mas todo departamento deve possuir empregados alocados a
ele, além disso, todo departamento tem um chefe que o gerencia, a partir de uma data, pois a
empresa implementa um sistema de rodízio na chefia dos departamentos, o rodízio na chefia
determina que um empregado só pode ser chefe de somente um departamento.
Um empregado pode trabalhar em mais de um projeto, mesmo que não seja do seu
departamento, dedicando algumas horas por semana em cada um dos projetos. E, é claro,
alguns empregados, como os do “departamento pessoal”, não estão empenhados em nenhum
projeto. Por outro lado, todo projeto tem pelo menos um ou mais empregados trabalhando
nele.
A empresa oferece alguns benefícios sociais aos dependentes dos seus empregados, caso ele
possua. Para tanto, é mantido para cada dependente do empregado o nome do dependente, o
sexo, a data de nascimento e o grau de parentesco.

Sistema Agenda

Deseja-se construir uma agenda de endereços de pessoas e empresas onde trabalham. As
pessoas da agenda possuem endereços para fins postais e telefones, que podem ser
residenciais, comerciais, fax, celular ou de outro tipo. Anota-se no telefone DDD, prefixo e
MODELAGEM EM BANCO DE DADOS                                                                36


número. Telefones do tipo fixo são associados a endereços e telefones do tipo móvel são
associados a pessoas. A cada endereço associa-se um código de endereço(único), rua,
número, bairro, CEP, todo endereço de pessoa pode ser classificado dentre os tipos residência
própria, residência com os pais, residência com parentes, residência com amigos, de referência
ou outro, sendo que, um endereço pode pertencer a mais de uma pessoa. Para toda pessoa da
agenda armazena-se seu código seqüencial na agenda, seu nome. Uma pessoa pode ser amiga
de outras pessoas e têm armazenadas a data de início da amizade entre elas, ou se a pessoa
for parente de outras pessoas deve armazenar o tipo do parentesco. Alem disso, pessoas têm
armazenadas, o seu sexo e sua data de nascimento e a profissão. Sendo que algumas pessoas
podem trabalhar em uma empresa da agenda. Da Empresa, armazena-se a razão social da
empresa, a inscrição estadual, o CGC, o ramo de dedicação da empresa e o proprietário da
empresa que é uma pessoa armazenada na agenda. As empresas da agenda possuem um
único endereço, e em uma empresa trabalham várias pessoas da agenda, sendo que a
existência de uma empresa está condicionada a existir uma pessoa na agenda que trabalha
nela.

Sistema Imobiliária

Uma imobiliária lida com venda de imóveis urbanos. Para qualquer imóvel têm-se registradas a
sua inscrição, preço de venda, área total e área construída. Todo imóvel tem localização num
endereço. A cada endereço associa-se um código de endereço, rua, número, bairro, CEP e os
telefones associados (se existirem). Uma pessoa pode assumir um dos seguintes papéis em
relação a imobiliária: corretor, proprietário de imóvel ou comprador. Sobre o proprietário do
imóvel têm-se CPF, nome, estado civil e, se for casado, o nome do cônjuge. Um proprietário
pode ter vários imóveis a venda na imobiliária. Sobre os compradores têm-se CPF, nome,
profissão e uma lista de preferências de imóveis a adquirir. Sobre os corretores da imobiliária
têm-se número do CRECI, nome e data de admissão. Um corretor negocia com um comprador
a venda de um imóvel. E, é claro, um corretor negocia outros imóveis com outros
compradores, podendo um mesmo comprador adquirir um outro imóvel com o mesmo
comprador e com outros compradores. Sobre a venda são necessárias as seguintes
informações: data da venda, valor da venda e valor da comissão.

Sistema campeonato de futebol

Na construção de um banco de dados para administrar times, jogos e campeonatos de futebol,
cada time tem um nome (único) e uma quantidade de jogadores que jogam para o time, a
partir de uma data inicial e final do contrato.
Nos jogos do time, cada um desses jogadores é escalado, e, é preciso saber qual foi a sua
escalação no jogo (o número da camiseta do jogador). Para cada jogador tem-se o nome, o
apelido, a posição, o salário e o número de registro na federação.
Um time participa de jogos com outros times dentro de campeonatos. Um jogo é realizado em
estádio numa certa data (dia e hora) e produz um resultado, registrando, também, o público
presente e a renda do jogo. Cada jogo realizado tem um número de ordem em função do
campeonato, ou seja, o número de ordem serve para identificar um jogo dentro do
campeonato que ele pertence.
Os estádios tem nome (único), cidade, capacidade de público e o(s) time(s) que mandam jogo
naquele estádio, sendo que os times só possuem um estádio onde eles mandam seus jogos.
Em um jogo válido pelo campeonato deve ter sempre um juiz da federação, sobre os juízes
que apitam os jogos tem-se os nome, número de registro na federação, nome da mãe, classe,
data que começou como juiz e para quais campeonatos está designado, e claro durante um
campeonato temos vários juizes escalados.
Para um campeonato tem-se o nome (único), quantidade de times e descrição, e para cada
campeonato precisa-se ter os times que participaram do campeonato, bem como a
classificação de cada time e o time que foi o campeão.

Contenu connexe

Tendances

Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAlberto Simões
 
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...Leinylson Fontinele
 
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Leinylson Fontinele
 
Banco de Dados I Aula 02 - Introdução aos Bancos de Dados
Banco de Dados I  Aula 02 - Introdução aos Bancos de DadosBanco de Dados I  Aula 02 - Introdução aos Bancos de Dados
Banco de Dados I Aula 02 - Introdução aos Bancos de DadosLeinylson Fontinele
 
Tipos de sistemas de informação nas organizações
Tipos de sistemas de informação nas organizaçõesTipos de sistemas de informação nas organizações
Tipos de sistemas de informação nas organizaçõesPricila Yessayan
 
Lógica de Programação - Estrutura de repetição
Lógica de Programação - Estrutura de repetiçãoLógica de Programação - Estrutura de repetição
Lógica de Programação - Estrutura de repetiçãoWesley R. Bezerra
 
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)Leinylson Fontinele
 
Aula1 - Apresentação de Banco de Dados
Aula1 - Apresentação de Banco de DadosAula1 - Apresentação de Banco de Dados
Aula1 - Apresentação de Banco de DadosRafael Albani
 
Aula 1 introdução a base de dados
Aula 1   introdução a base de dadosAula 1   introdução a base de dados
Aula 1 introdução a base de dadosHélio Martins
 
Banco de dados exercícios resolvidos
Banco de dados exercícios resolvidosBanco de dados exercícios resolvidos
Banco de dados exercícios resolvidosGleydson Sousa
 
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. Ref
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. RefBD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. Ref
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. RefRodrigo Kiyoshi Saito
 
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)Leinylson Fontinele
 
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...Leinylson Fontinele
 
Lógica de programação em ppt
Lógica de programação em pptLógica de programação em ppt
Lógica de programação em pptAndrei Bastos
 
Sistemas Operacionais - Aula 05 (Concorrência)
Sistemas Operacionais - Aula 05 (Concorrência)Sistemas Operacionais - Aula 05 (Concorrência)
Sistemas Operacionais - Aula 05 (Concorrência)Leinylson Fontinele
 

Tendances (20)

Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de Atividade
 
Risc e cisc
Risc e ciscRisc e cisc
Risc e cisc
 
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...
Banco de Dados II Aula Prática 1 (Conversão do modelo conceitual para modelo ...
 
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
 
Banco de Dados I Aula 02 - Introdução aos Bancos de Dados
Banco de Dados I  Aula 02 - Introdução aos Bancos de DadosBanco de Dados I  Aula 02 - Introdução aos Bancos de Dados
Banco de Dados I Aula 02 - Introdução aos Bancos de Dados
 
Modelo E-R
Modelo E-RModelo E-R
Modelo E-R
 
Tipos de sistemas de informação nas organizações
Tipos de sistemas de informação nas organizaçõesTipos de sistemas de informação nas organizações
Tipos de sistemas de informação nas organizações
 
Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2Diagramas de casos de uso - aula 2
Diagramas de casos de uso - aula 2
 
Lógica de Programação - Estrutura de repetição
Lógica de Programação - Estrutura de repetiçãoLógica de Programação - Estrutura de repetição
Lógica de Programação - Estrutura de repetição
 
Banco de Dados
Banco de DadosBanco de Dados
Banco de Dados
 
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)
Banco de Dados I - Aula 06 - Banco de Dados Relacional (Modelo Lógico)
 
Aula1 - Apresentação de Banco de Dados
Aula1 - Apresentação de Banco de DadosAula1 - Apresentação de Banco de Dados
Aula1 - Apresentação de Banco de Dados
 
Aula 1 introdução a base de dados
Aula 1   introdução a base de dadosAula 1   introdução a base de dados
Aula 1 introdução a base de dados
 
Banco de dados exercícios resolvidos
Banco de dados exercícios resolvidosBanco de dados exercícios resolvidos
Banco de dados exercícios resolvidos
 
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. Ref
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. RefBD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. Ref
BD I - Aula 03 - Atributos, Tuplas, PK, FK, Relacionamento, Int. Ref
 
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)
Banco de Dados II Aula 07 - Linguagem de Consulta SQL (Comandos DDL)
 
Algoritmos: Tipos de Dados
Algoritmos: Tipos de DadosAlgoritmos: Tipos de Dados
Algoritmos: Tipos de Dados
 
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...
Banco de Dados II Aula 14 - Projeto de Banco de Dados e Estudo de Caso (Postg...
 
Lógica de programação em ppt
Lógica de programação em pptLógica de programação em ppt
Lógica de programação em ppt
 
Sistemas Operacionais - Aula 05 (Concorrência)
Sistemas Operacionais - Aula 05 (Concorrência)Sistemas Operacionais - Aula 05 (Concorrência)
Sistemas Operacionais - Aula 05 (Concorrência)
 

En vedette

Exercícios de relacionamento 2012
Exercícios de relacionamento 2012Exercícios de relacionamento 2012
Exercícios de relacionamento 2012Vitor Leal Diniz
 
Mer - Modelo Entidade Relacionamento
Mer - Modelo Entidade RelacionamentoMer - Modelo Entidade Relacionamento
Mer - Modelo Entidade RelacionamentoRademaker Siena
 
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)Gleyciana Garrido
 
DER - Diagrama de Entidade e Relacionamentos
DER - Diagrama de Entidade e RelacionamentosDER - Diagrama de Entidade e Relacionamentos
DER - Diagrama de Entidade e RelacionamentosCláudio Amaral
 
Diagrama Entidade Relacionamento - Bancos de Dados I
Diagrama Entidade Relacionamento - Bancos de Dados IDiagrama Entidade Relacionamento - Bancos de Dados I
Diagrama Entidade Relacionamento - Bancos de Dados IDjonathas Cardoso
 
Bdm aula 5 - construindo modelos er e mapeamento er-relacional
Bdm   aula 5 - construindo modelos er e mapeamento er-relacionalBdm   aula 5 - construindo modelos er e mapeamento er-relacional
Bdm aula 5 - construindo modelos er e mapeamento er-relacionalTicianne Darin
 
Banco de Dados - Introdução - Projeto de Banco de Dados - DER
Banco de Dados - Introdução - Projeto de Banco de Dados - DERBanco de Dados - Introdução - Projeto de Banco de Dados - DER
Banco de Dados - Introdução - Projeto de Banco de Dados - DERRangel Javier
 
Apostila Modelo ER (Entidade Relacionamento)
Apostila Modelo ER (Entidade Relacionamento)Apostila Modelo ER (Entidade Relacionamento)
Apostila Modelo ER (Entidade Relacionamento)Ricardo Terra
 
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizado
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizadoINSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizado
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizadoManim Edições
 
Banco de dados i 2010 lista de exercícios i
Banco de dados i 2010   lista de exercícios iBanco de dados i 2010   lista de exercícios i
Banco de dados i 2010 lista de exercícios ijogosem
 
Modelagem de dados usando o mer parte 1
Modelagem de dados usando o mer parte 1Modelagem de dados usando o mer parte 1
Modelagem de dados usando o mer parte 1Elaine Cecília Gatto
 
Implantação de Software para Transportadora
Implantação de Software para TransportadoraImplantação de Software para Transportadora
Implantação de Software para TransportadoraMarco Coghi
 
Sistema de Gerenciamento de Locadora de Vídeo - Banco de Dados
Sistema de Gerenciamento de Locadora de Vídeo - Banco de DadosSistema de Gerenciamento de Locadora de Vídeo - Banco de Dados
Sistema de Gerenciamento de Locadora de Vídeo - Banco de DadosGleyciana Garrido
 
Sorria e diga: photosop
Sorria e diga: photosopSorria e diga: photosop
Sorria e diga: photosopClarissa Ramos
 

En vedette (20)

Apostila modelagem de banco de dados
Apostila modelagem de banco de dadosApostila modelagem de banco de dados
Apostila modelagem de banco de dados
 
Exercícios de relacionamento 2012
Exercícios de relacionamento 2012Exercícios de relacionamento 2012
Exercícios de relacionamento 2012
 
Mer - Modelo Entidade Relacionamento
Mer - Modelo Entidade RelacionamentoMer - Modelo Entidade Relacionamento
Mer - Modelo Entidade Relacionamento
 
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)
Projeto de Banco de Dados: Gerenciamento de Locadora de Vídeo (parte escrita)
 
DER - Diagrama de Entidade e Relacionamentos
DER - Diagrama de Entidade e RelacionamentosDER - Diagrama de Entidade e Relacionamentos
DER - Diagrama de Entidade e Relacionamentos
 
Diagrama Entidade Relacionamento - Bancos de Dados I
Diagrama Entidade Relacionamento - Bancos de Dados IDiagrama Entidade Relacionamento - Bancos de Dados I
Diagrama Entidade Relacionamento - Bancos de Dados I
 
Apostila banco de dados
Apostila banco de dadosApostila banco de dados
Apostila banco de dados
 
Modelagem de Dados
Modelagem de DadosModelagem de Dados
Modelagem de Dados
 
Bdm aula 5 - construindo modelos er e mapeamento er-relacional
Bdm   aula 5 - construindo modelos er e mapeamento er-relacionalBdm   aula 5 - construindo modelos er e mapeamento er-relacional
Bdm aula 5 - construindo modelos er e mapeamento er-relacional
 
Banco de Dados - Introdução - Projeto de Banco de Dados - DER
Banco de Dados - Introdução - Projeto de Banco de Dados - DERBanco de Dados - Introdução - Projeto de Banco de Dados - DER
Banco de Dados - Introdução - Projeto de Banco de Dados - DER
 
Apostila Modelo ER (Entidade Relacionamento)
Apostila Modelo ER (Entidade Relacionamento)Apostila Modelo ER (Entidade Relacionamento)
Apostila Modelo ER (Entidade Relacionamento)
 
Estudo dos geradores
Estudo dos geradoresEstudo dos geradores
Estudo dos geradores
 
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizado
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizadoINSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizado
INSS como fazer emprestimo no programa de financeiras 15-09-2011 atualizado
 
Banco de dados i 2010 lista de exercícios i
Banco de dados i 2010   lista de exercícios iBanco de dados i 2010   lista de exercícios i
Banco de dados i 2010 lista de exercícios i
 
Modelagem de dados usando o mer parte 1
Modelagem de dados usando o mer parte 1Modelagem de dados usando o mer parte 1
Modelagem de dados usando o mer parte 1
 
Dbmod
DbmodDbmod
Dbmod
 
Database Design
Database DesignDatabase Design
Database Design
 
Implantação de Software para Transportadora
Implantação de Software para TransportadoraImplantação de Software para Transportadora
Implantação de Software para Transportadora
 
Sistema de Gerenciamento de Locadora de Vídeo - Banco de Dados
Sistema de Gerenciamento de Locadora de Vídeo - Banco de DadosSistema de Gerenciamento de Locadora de Vídeo - Banco de Dados
Sistema de Gerenciamento de Locadora de Vídeo - Banco de Dados
 
Sorria e diga: photosop
Sorria e diga: photosopSorria e diga: photosop
Sorria e diga: photosop
 

Similaire à Material Modelagem - Prof. Marcos Alexandruk

Projeto de Banco de Dados - Capítulo 1
Projeto de Banco de Dados - Capítulo 1Projeto de Banco de Dados - Capítulo 1
Projeto de Banco de Dados - Capítulo 1Januário Neto
 
Concepcao de banco_de_dados-aula_1
Concepcao de banco_de_dados-aula_1Concepcao de banco_de_dados-aula_1
Concepcao de banco_de_dados-aula_1Carlos Melo
 
Universidade federal do amazonas Banco de Dados - Apresentação final
Universidade federal do amazonas   Banco de Dados - Apresentação finalUniversidade federal do amazonas   Banco de Dados - Apresentação final
Universidade federal do amazonas Banco de Dados - Apresentação finalRenan Levy
 
Banco de Dados - Conceitos
Banco de Dados - ConceitosBanco de Dados - Conceitos
Banco de Dados - Conceitosssuser69006f
 
Programação em Banco de Dados - Aula 16/08/2018
Programação em Banco de Dados - Aula 16/08/2018Programação em Banco de Dados - Aula 16/08/2018
Programação em Banco de Dados - Aula 16/08/2018Elaine Cecília Gatto
 
aula01_Fundamentos de Banco de Dados.pptx.pdf
aula01_Fundamentos de Banco de Dados.pptx.pdfaula01_Fundamentos de Banco de Dados.pptx.pdf
aula01_Fundamentos de Banco de Dados.pptx.pdfssuser7a84f91
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de softwareDanilo Gois
 
Introdução à Banco de Dados
Introdução à Banco de DadosIntrodução à Banco de Dados
Introdução à Banco de DadosBruno Siqueira
 
Conceitos Base_de_Dados.pdf
Conceitos Base_de_Dados.pdfConceitos Base_de_Dados.pdf
Conceitos Base_de_Dados.pdfticepcCapelas
 
Big data e mineração de dados
Big data e mineração de dadosBig data e mineração de dados
Big data e mineração de dadosElton Meira
 
BANCO DE DADOS RELACIONAIS
BANCO DE DADOS RELACIONAIS BANCO DE DADOS RELACIONAIS
BANCO DE DADOS RELACIONAIS Antonio Pedro
 
Célio Azevedo - Apostilas de SQL atualizadas
Célio Azevedo - Apostilas de SQL atualizadasCélio Azevedo - Apostilas de SQL atualizadas
Célio Azevedo - Apostilas de SQL atualizadasUCAM
 
Aula01 administrador de banco de dados dba
Aula01 administrador de banco de dados  dbaAula01 administrador de banco de dados  dba
Aula01 administrador de banco de dados dbajjuniorlopes
 
Palestra big data_e_mineracao_dedados_5agosto13-versaoslideshare
Palestra big data_e_mineracao_dedados_5agosto13-versaoslidesharePalestra big data_e_mineracao_dedados_5agosto13-versaoslideshare
Palestra big data_e_mineracao_dedados_5agosto13-versaoslidesharepccdias
 
Arquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosArquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosdiogocbj
 
Apresentacao1 base de_dados
Apresentacao1 base de_dadosApresentacao1 base de_dados
Apresentacao1 base de_dadosDaniel Silva
 
Banco de Dados - conceitos, usuários, características
Banco de Dados - conceitos, usuários, característicasBanco de Dados - conceitos, usuários, características
Banco de Dados - conceitos, usuários, característicasFernandaNascimento276697
 

Similaire à Material Modelagem - Prof. Marcos Alexandruk (20)

Projeto de Banco de Dados - Capítulo 1
Projeto de Banco de Dados - Capítulo 1Projeto de Banco de Dados - Capítulo 1
Projeto de Banco de Dados - Capítulo 1
 
Concepcao de banco_de_dados-aula_1
Concepcao de banco_de_dados-aula_1Concepcao de banco_de_dados-aula_1
Concepcao de banco_de_dados-aula_1
 
Artc 1249307788 43
Artc 1249307788 43Artc 1249307788 43
Artc 1249307788 43
 
Universidade federal do amazonas Banco de Dados - Apresentação final
Universidade federal do amazonas   Banco de Dados - Apresentação finalUniversidade federal do amazonas   Banco de Dados - Apresentação final
Universidade federal do amazonas Banco de Dados - Apresentação final
 
Banco de Dados - Conceitos
Banco de Dados - ConceitosBanco de Dados - Conceitos
Banco de Dados - Conceitos
 
Programação em Banco de Dados - Aula 16/08/2018
Programação em Banco de Dados - Aula 16/08/2018Programação em Banco de Dados - Aula 16/08/2018
Programação em Banco de Dados - Aula 16/08/2018
 
aula01_Fundamentos de Banco de Dados.pptx.pdf
aula01_Fundamentos de Banco de Dados.pptx.pdfaula01_Fundamentos de Banco de Dados.pptx.pdf
aula01_Fundamentos de Banco de Dados.pptx.pdf
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
Introdução à Banco de Dados
Introdução à Banco de DadosIntrodução à Banco de Dados
Introdução à Banco de Dados
 
Conceitos Base_de_Dados.pdf
Conceitos Base_de_Dados.pdfConceitos Base_de_Dados.pdf
Conceitos Base_de_Dados.pdf
 
Big data e mineração de dados
Big data e mineração de dadosBig data e mineração de dados
Big data e mineração de dados
 
BANCO DE DADOS RELACIONAIS
BANCO DE DADOS RELACIONAIS BANCO DE DADOS RELACIONAIS
BANCO DE DADOS RELACIONAIS
 
Célio Azevedo - Apostilas de SQL atualizadas
Célio Azevedo - Apostilas de SQL atualizadasCélio Azevedo - Apostilas de SQL atualizadas
Célio Azevedo - Apostilas de SQL atualizadas
 
BD I - Aula 07 A - Projetando BD
BD I - Aula 07 A - Projetando BDBD I - Aula 07 A - Projetando BD
BD I - Aula 07 A - Projetando BD
 
Aula01 administrador de banco de dados dba
Aula01 administrador de banco de dados  dbaAula01 administrador de banco de dados  dba
Aula01 administrador de banco de dados dba
 
Palestra big data_e_mineracao_dedados_5agosto13-versaoslideshare
Palestra big data_e_mineracao_dedados_5agosto13-versaoslidesharePalestra big data_e_mineracao_dedados_5agosto13-versaoslideshare
Palestra big data_e_mineracao_dedados_5agosto13-versaoslideshare
 
Arquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosArquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dados
 
Apresentacao1 base de_dados
Apresentacao1 base de_dadosApresentacao1 base de_dados
Apresentacao1 base de_dados
 
Banco de Dados - Aula 01
Banco de Dados - Aula 01Banco de Dados - Aula 01
Banco de Dados - Aula 01
 
Banco de Dados - conceitos, usuários, características
Banco de Dados - conceitos, usuários, característicasBanco de Dados - conceitos, usuários, características
Banco de Dados - conceitos, usuários, características
 

Material Modelagem - Prof. Marcos Alexandruk

  • 1. MODELAGEM EM BANCO DE DADOS Prof. Marcos Alexandruk
  • 2. MODELAGEM EM BANCO DE DADOS 1 INTRODUÇÃO AOS CONCEITOS DE INFORMAÇÃO INFORMAÇÃO: • Acrescenta algo ao conhecimento da realidade a ser analisada. Por exemplo, a dosagem que um paciente precisa receber de um determinado remédio é uma INFORMAÇÃO. Este conhecimento pode ser (ou não) modelado (registrado). DADO: • É uma representação, um registro de uma informação. Este DADO pode ser registrado fisicamente através de um papel (receita médica), um disco magnético, etc. O tratamento das INFORMAÇÕES dá origem a uma série de DADOS, porém o DADO deve registrar apenas aspectos relevantes da INFORMAÇÃO. Tendo em vista a natural quot;restriçãoquot; humana de manipular grandes quantidades de informações ao mesmo tempo, foram criadas técnicas para modelar os diversos problemas que existem. Estas técnicas, juntas, formam um conjunto conhecido como METODOLOGIA de produção de sistemas de informação. Desde 1950, várias metodologias estão sendo colocadas em prática. Estas metodologias definem o CICLO DE VIDA do desenvolvimento, no qual estão mostradas as fases que compõem o caminho a ser seguido pelos analistas e programadores, até a produção do sistema de informações na sua versão operacional. Cada fase pode ser vista como o refinamento da etapa anterior. A seguir serão apresentadas algumas metodologias utilizadas no processo de desenvolvimento de sistemas de informação: CICLO DE VIDA TRADICIONAL OU EM CASCATA Apresenta como principal característica a baixa interação dos usuários do sistema com o pessoal de desenvolvimento. Durante as etapas de Levantamento e Análise, o usuário tenta passar para o analista tudo o que sabe sobre o problema e o que ele deseja para solucionar o mesmo. Após a definição do problema é criado um documento contendo os requisitos do futuro sistema, que é então congelado e utilizado durante todas as fases de desenvolvimento. Neste ciclo de vida quase não existe oportunidade para o usuário realizar alguma alteração em pontos dos requisitos congelados. As atividades são realizadas em seqüência e não existem retornos entre as atividades. Toda a documentação é produzida após o término do projeto. Os projetos realizados com este ciclo de vida se caracterizam pela alta incidência de manutenção, pois estão sujeitos a poucas alterações durante o desenvolvimento. • LEVANTAMENTO • ANÁLISE • PROJETO • CODIFICAÇÃO • DOCUMENTAÇÃO • TESTES • IMPLEMENTAÇÃO • MANUTENÇÃO CICLO DE VIDA DA ANÁLISE ESTRUTURADA Caracterizado pelo uso das técnicas estruturadas, incluindo as revisões estruturadas. Muitas das atividades são executadas em paralelo, produzindo documentação nos vários estágios do desenvolvimento. Revisões periódicas são realizadas para se detectar o mais cedo possível problemas que podem influenciar o produto final. O envolvimento do usuário é bastante significativo. Sua participação na maioria das revisões traz novas sugestões e correções dos aspectos não compatíveis com suas necessidades.
  • 3. MODELAGEM EM BANCO DE DADOS 2 CICLO DE VIDA DA ENGENHARIA DE SOFTWARE Busca uma maior disciplina em termos de desenvolvimento de sistemas. Caracterizada pela forte orientação por processos, pela determinação bem acentuada de cada fase, enfatiza a reutilização de código de programa, provê revisões e pontos de checagem bem determinados e define métricas bem fundamentadas para o gerente realizar o controle da produtividade, a qualidade e o baixo custo final. A engenharia de software é fundamentada em sete fases: viabilidade, análise, projeto, implementação, teste do sistema, teste do usuário e produção. Quando um problema ocorre em uma das fases, retorna-se a fase imediatamente anterior. CICLO DE VIDA DA ENGENHARIA DE INFORMAÇÃO No decorrer de 20 anos de uso de técnicas de desenvolvimento de sistemas, concluiu-se que os dados envolvidos em cada processo eram extremamente estáveis, se comparados com os processos. Em 1981, Matt Flavin, James Martin e Clive Finkelstein introduziram o conceito de engenharia da informação. O princípio fundamental baseava-se no fato de que o dado existe e é descrito, independentemente dos processos que podem utilizá-lo. Como o centro desta metodologia é o DADO, a idéia principal é levantar as estruturas de dados que vão dar origem aos bancos de dados, provendo um fácil acesso aos mesmos. A engenharia da informação é um conjunto integrado de técnicas que organiza os dados de um determinado negócio e determina um acesso fácil, por parte do usuário final, a estes dados. Esta metodologia pode ser detalhada nas seguintes fases: planejamento estratégico das informações, análise da informação, modelagem dos dados, formação dos procedimentos, análise do uso dos dados, análise da distribuição dos dados, projeto físico da base de dados e especificação dos programas.
  • 4. MODELAGEM EM BANCO DE DADOS 3 INTRODUÇÃO Conceitos básicos necessários à compreensão do projeto de banco de dados. BANCO DE DADOS: • coleção de dados integrados que tem por objetivo atender a uma comunidade de usuários. • conjunto de dados persistentes e manipuláveis que obedecem a um padrão de armazemamento. Exemplos: lista telefônica, dicionário, etc.. • equivalente eletrônico de um armário de arquivamento, isto é, um repositório para uma coleção de arquivos de dados computadorizados. Por que utilizar DB’s (informatizados)? • Compacto (elimina arquivos de papéis); • Rápido; • Integrado (repositório de dados de vários aplicativos); • Compartilhado (vários usuários podem acessar); • Seguro (acesso com restrições); • Padronizado; • Consistente; • Suporte a transações (opcional) SISTEMA DE GERÊNCIA DE BANCO DE DADOS (SGDB) • software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados • sistema computadorizado de manutenção de registros
  • 5. MODELAGEM EM BANCO DE DADOS 4 VANTAGENS: • Densidade: Não há necessidade de arquivos de papel, possivelmente volumosos • Velocidade: A 'máquina' pode obter e atualizar dados com rapidez muito maior que o ser humano • Menos trabalho monótono: Grande parte do tédio de manter arquivos à mão é eliminada. As tarefas mecânicas são sempre feitas com melhor qualidade por máquinas. • Atualidade: Informações precisas e atualizadas estão disponíveis a qualquer momento sob consulta • Proteção: Os dados podem ser mais bem protegidos contra perda não intencional e acesso ilegal • Centralização: O sistema de banco de dados proporciona à organização o controle centralizado de seus dados. MODELO DE DADOS: Descrição formal da estrutura de um banco de dados. MODELO HIERÁRQUICO Organiza os dados de cima para baixo, como uma árvore. Cada registro é dividido em partes de registros denominados segmentos. O banco de dados se assemelha a um organograma com um segmento raiz e um número qualquer de segmentos subordinados. Os segmentos, por sua vez, são arranjados em estruturas multiniveladas, com um segmento superior ligado a um segmento subordinado em um relacionamento “pai-filho”. Um segmento “pai” pode ter mais de um “filho”, mas um segmento “filho” só pode ter um “pai”. MODELO EM REDE Os registros são organizados no banco de dados por um conjunto arbitrário de gráficos. Em outras palavras, um “filho” pode ter mais de um “pai”. São mais flexíveis que os hierárquicos. Existem limitações práticas para o número de ligações, que podem ser estabelecidas entre os registros. Nem o modelo de gerenciamento de bancos de dados em rede nem o hierárquico podem criar facilmente novos relacionamentos entre os elementos de dados ou novos padrões de acesso sem grande esforço de programação. MODELO RELACIONAL A introdução do sistema relacional (1969-1970) foi o evento mais importante na história da área de banco de dados. De modo abreviado (e informal), um sistema relacional é aquele no qual: • Os dados são percebidos pelo usuário como tabelas • Os operadores à disposição do usuário (por exemplo, para busca de dados) são operadores que geram tabelas quot;novasquot; a partir de tabelas quot;antigasquot;. Por exemplo, há um operador de quot;restriçãoquot; (também conhecido como quot;seleçãoquot;) para extrair um subconjunto das linhas de uma dada tabela, e outro operador, quot;projeçãoquot;, que extrai um subconjunto das colunas. Os primeiros produtos relacionais começaram a aparecer no final da década de 1970. Hoje a maioria dos sistemas de banco de dados é relacional: • IBM: DB2 • CA: Ingres II • Microsoft: SQL Server • Oracle: 9i, 10g • Sybase • Informix A linguagem de manipulação de dados em sistemas de bancos de dados relacionais é o SQL (Structured Query Language).
  • 6. MODELAGEM EM BANCO DE DADOS 5 VISÃO DE DADOS O maior benefício de um banco de dados é proporcionar ao usuário uma visão abstrata dos dados. Isto é, o sistema acaba por ocultar determinados detalhes sobre a forma de armazenamento e manutenção desses dados. ABSTRAÇÃO DE DADOS NÍVEL FÍSICO: • É o nível mais baixo de abstração. • Descreve como os dados estão de fato armazenados. • Estruturas complexas são descritas em detalhes. NÍVEL LÓGICO: • Descreve quais dados estão armazenados e quais os relacionamentos entre eles. • O banco de dados é descrito em termos de um número relativamente pequeno de estruturas simples. • Utilizado pelos administradores de banco de dados que precisam decidir quais informações devem pertencer ao banco de dados. NÍVEL DE VISÃO: • É o nível mais alto de abstração. • Descreve apenas parte do banco de dados. • Muitos usuários utilizam apenas parte do banco de dados. Assim, para que estas interações sejam simplificadas, um nível de visão é definido. • O sistema pode proporcionar diversas visões do mesmo banco de dados. INDEPENDÊNCIA DE DADOS: • É a capacidade de modificar a definição dos esquemas em determinado nível, sem afetar o esquema do nível superior. • Independência de dados física: é a capacidade de modificar o esquema físico sem que, com isso, qualquer programa ou aplicação precise ser reescrito. • Independência de dados lógica: é a capacidade de modificar o esquema lógico sem que, com isso, qualquer programa ou aplicação precise ser reescrito. • A independência lógica é mais difícil de ser alcançada que a independência física, uma vez que os programas de aplicação são mais fortemente dependentes da estrutura lógica dos dados do que de seu acesso.
  • 7. MODELAGEM EM BANCO DE DADOS 6 ARQUITETURAS DE SISTEMAS DE BANCOS DE DADOS SISTEMAS CENTRALIZADOS Sistemas de banco de dados centralizados são aqueles executados sobre um único sistema computacional que não interagem com outros sistemas. Tais sistemas podem ter a envergadura de um sistema de banco de dados de um só usuário executado em um computador pessoal até sistemas de alto desempenho em sistemas de grande porte. SISTEMAS CLIENTE-SERVIDOR As funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias: • back-end: gerencia as estruturas de acesso, desenvolvimento e otimização de consultas, controle de concorrência e recuperação. • front-end: consiste em ferramentas como formulários, gerador de relatórios e recursos de interfaces gráficas. A interface entre o front-end e o back-end é feita por meio da SQL ou de um programa de aplicação. SISTEMAS PARALELOS Sistemas paralelos imprimem velocidade ao processamento e à I/O por meio do uso em paralelo de diversas CPUs e discos. Suprem a demanda de aplicações que geram consultas em bancos de dados muito grandes (da ordem de terabytes) ou que tenham de processar um volume enorme de transações por segundo (da ordem de milhares de transações por segundo).
  • 8. MODELAGEM EM BANCO DE DADOS 7 Há diversos modelos arquitetônicos para máquinas paralelas: • Memória compartilhada: Todos os processadores compartilham uma mesma memória. • Disco compartilhado: Todos os processadores compartilham o mesmo disco. Sistemas com discos compartilhados são, às vezes chamados de clusters. • Ausência de compartilhamento: Os processadores não compartilham nem memória nem disco. • Hierárquico: É um híbrido das arquiteturas anteriores. SISTEMAS DISTRIBUÍDOS Em um sistema de banco de dados distribuído o banco de dados é armazenado em diversos computadores. Os computadores comunicam-se uns com os outros por intermédio de redes de alta velocidade ou linhas telefônicas. Eles não compartilham memória principal ou discos. Os computadores em um sistema de banco de dados distribuídos podem variar, quanto ao tamanho e funções, desde estações de trabalho até sistemas de grande porte (mainframe). As principais diferenças entre os bancos de dados paralelos sem compartilhamento e os bancos de dados distribuídos são que, nos bancos de dados distribuídos, há a distribuição física geográfica (diversos sites), administração separada e uma intercomunicação menor. Outra importante diferença é que, nos sistemas distribuídos, distinguimos transações locais de globais. Uma transação local acessa um único site, justamente no qual ela se inicial. Uma transação global, por outro lado, é aquela que busca acesso a diferentes sites, ou a outro site além daquele em que se inicia.
  • 9. MODELAGEM EM BANCO DE DADOS 8 VISÃO GERAL DA ESTRUTURA DO SISTEMA DE BANCO DE DADOS COMPONENTES DE PROCESSAMENTO DE CONSULTAS: • Compilador DML: Traduz comandos DML da linguagem de consulta em instruções de baixo nível, inteligíveis ao componente de execução de consultas. Transforma a solicitação do usuário em uma solicitação equivalente, mas mais eficiente. • Pré-compilador para comandos DML: Inseridos em programas de aplicação que convertem comandos DML em chamadas e procedimentos normais da linguagem hospedeira. Interage com o compilador DML de modo a gerar o código apropriado. • Interpretador DDL: Interpreta os comandos DDL e registra-os em um conjunto de tabelas que contêm metadados. • Componentes para tratamento de consultas: Executam instruções de baixo nível geradas pelo compilador DML. COMPONENTES DE ADMINISTRAÇÃO DE ARMAZENAMENTO DE DADOS: • Gerenciamento de autorização e integridade: Testam o cumprimento das regras de integridade e a permissão ao usuário no acesso ao dado. • Gerenciamento de transações: Garante que o banco de dados permanecerá em estado consistente (correto) a despeito de falhas no sistema e que transações concorrentes serão executadas sem conflitos em seus procedimentos. • Administração de arquivos: Gerencia a alocação de espaço no armazenamento em disco e as estruturas de dados usadas para representar as informações armazenadas em disco. • Administração de buffer: Responsável pela intermediação de dados do disco para a memória principal e pela decisão de quais dados colocar em memória cache. OUTRAS ESTRUTURAS NECESSÁRIAS COMO PARTE DA IMPLEMENTAÇÃO FÍSICA DO SISTEMA: • Arquivo de dados: Armazena o próprio banco de dados. • Dicionário de dados: Armazena os metadados relativos à estrutura do banco de dados. • Índices: Proporcionam acesso rápido aos dados associados a valores determinados. • Estatísticas de dados: Armazenam informações estatísticas usadas pelo processador de consultas para seleção de meios eficientes para execução de uma consulta.
  • 10. MODELAGEM EM BANCO DE DADOS 9 MODELO CONCEITUAL • Representa ou descreve a realidade do ambiente do problema, constituindo-se em uma visão global dos principais dados e relacionamentos (estruturas de informações), independente das restrições de implementação. • É a primeira etapa do projeto de um sistema de aplicação em banco de dados. • É uma descrição em alto nível (macro definição) mas que tem a preocupação de capturar e retratar toda a realidade de uma organização. • O resultado de um modelo conceitual é um esquema que representa a realidade das informações existentes, assim como as estruturas de dados que representam estas informações. MODELO LÓGICO • Tem seu início a partir do modelo conceitual, levando em consideração as três abordagens atualmente disponíveis: Relacional, Hierárquica e Rede. • O modelo lógico descreve as estruturas que estarão contidas no banco de dados, mas sem considerar ainda nenhuma característica específica de SGBD, resultando em um esquema lógico de dados. MODELO FÍSICO • Parte do modelo lógico e descreve as estruturas físicas de armazenamento de dados, tais como: tamanhos de campos, índices, tipos de dados, nomenclaturas, etc. • Este modelo detalha o estudo dos métodos de acesso do SGDB, para elaboração dos índices de cada informação colocada nos modelos conceitual e lógico. • É a etapa final do projeto de banco de dados, na qual será utilizada a linguagem de definição de dados (DDL), para a realização da montagem do mesmo no nível de dicionário de dados.
  • 11. MODELAGEM EM BANCO DE DADOS 10 MODELO CONCEITUAL Descrição do banco de dados de forma independente de implementação em um SGBD. Registra que dados podem aparecer no banco de dados, mas não registra como estes dados estão armazenados no SGDB. DIAGRAMA ENTIDADE-RELACIONAMENTO O Modelo Entidade-Relacionamento foi definido por Peter Chen em 1976, e teve como base a teoria relacional criada por E. F. Codd (1970). Um modelo ER é um modelo formal, preciso, não ambíguo. Isto significa que diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo. Tanto é assim, que um modelo ER pode ser usado como entrada de uma ferramenta CASE (Computer Aided Software Engineering) na geração de um banco de dados relacional. ENTIDADE: Representa um conjunto de objetos (tudo que é perceptível ou manipulável) da realidade modelada sobre os quais deseja-se manter informações no banco de dados. ATRIBUTOS: Dados que são associados a cada ocorrência de uma entidade ou de um relacionamento. IDENTIFICADOR DE ENTIDADE: Atributo ou conjunto de atributos e relacionamentos cujos valores distinguem uma ocorrência da entidade das demais. CARDINALIDADE: Número (mínimo, máximo) de ocorrências de entidade associadas a uma ocorrência da entidade em questão através do relacionamento. Cardinalidade mínima: É o número mínimo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamento. A cardinalidade mínima 1 recebe a denominação de associação obrigatória, já que ela indica que o relacionamento deve obrigatoriamente associar uma ocorrência de entidade a outra. A cardinalidade mínima 0 (zero) recebe a denominação de associação opcional. Cardinalidade máxima: É o número máximo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamento. Apenas duas cardinalidades máximas são relevantes: a cardinalidade máxima 1 e a cardinalidade máxima n (muitos). DIAGRAMA DE OCORRÊNCIAS: Para fins didáticos, pode ser útil construir um diagrama de ocorrências. Neste as ocorrências de entidades são representadas por círculos brancos e ocorrências de relacionamentos por círculos pretos. As ocorrências de entidades participantes de uma ocorrência de relacionamento são indicadas pelas linhas que ligam o círculo preto aos círculos brancos.
  • 12. MODELAGEM EM BANCO DE DADOS 11 RELACIONAMENTO BINÁRIO Um relacionamento binário é aquele envolve duas ocorrências de entidade. Podemos classificar os relacionamentos binários em: • 1:1 (um-para-um): cada elemento de uma entidade relaciona-se com um e somente um elemento de outra entidade. • 1:n (um-para-muitos): um elemento da entidade 1 relaciona-se com muitos elementos da entidade 2, mas cada elemento da entidade 2 somente pode estar relacionado a um elemento da entidade 1. • n:n (muitos-para-muitos): em ambos os sentidos encontramos um grau de relacionamento de um-para-muitos, o que o caracteriza no contexto geral como um relacionamento de muitos-para-muitos. RELACIONAMENTO TERNÁRIO Relacionamento entre múltiplas entidades, expressam um fato em que todas as entidades ocorrem simultaneamente, ou seja, todas as ocorrências do relacionamento possuem, sempre, ligações com todas as entidades envolvidas no relacionamento. O exemplo a seguir queremos garantir que a seguinte situação seja representa de forma apropriada: x fornece a peça y para o projeto z. Esta condição somente pode ser representada através de um relacionamento ternário. Observe o que ocorreria se tentássemos substituir o relacionamento ternário acima por três relacionamentos binários: x fornece a peça y: Não podemos inferir que a peça y será utilizada no projeto z. y é utilizada no projeto z: Não podemos inferir que y foi fornecida por x. x fornece para o projeto z: Não podemos inferir x fornece a peça y para o projeto z. Veja este outro caso que expressa a cardinalidade num relacionamento ternário: No exemplo acima, cada par de ocorrências (aluno, disciplina) está associado a no máximo um professor. A um par (aluno, professor) podem estar associadas muitas disciplinas, ou em outros termos, um professor pode ministrar a um determinado aluno várias disciplinas. A um par (disciplina, professor) podem estar associados muitos alunos, ou em outros termos, um professor pode uma determinada disciplina a vários alunos.
  • 13. MODELAGEM EM BANCO DE DADOS 12 AUTO RELACIONAMENTO Relacionamento entre ocorrências de uma mesma entidade. Exemplo 1: 1:1 - uma ocorrência de pessoa exerce o papel de marido e outra ocorrência de pessoa exerce o papel de esposa. Exemplo 2: 1:n - uma ocorrência de funcionário exerce o papel de supervisor e outras ocorrências de funcionário exercem o papel de supervisionado. GENERALIZAÇÃO/ESPECIALIZAÇÃO Através deste conceito é possível atribuir propriedades particulares a um subconjunto das ocorrências especializadas de uma entidade genérica. Especialização total: para cada ocorrência da entidade genérica existe sempre uma ocorrência em uma das entidades especializadas. Especialização parcial: nem toda ocorrência da entidade genérica possui uma ocorrência correspondente em uma entidade especializada.
  • 14. MODELAGEM EM BANCO DE DADOS 13 MÚLTIPLOS NÍVEIS E HERANÇA MÚLTIPLA É admissível que uma mesma entidade seja especialização de diversas entidades genérica (herança múltipla). No diagrama abaixo o exemplo de herança múltipla aparece na entidade ANFÍBIO. HERANÇA DE PROPRIEDADES Herdar propriedades significa que cada ocorrência da entidade especializada possui, além de suas propriedades (atributos, relacionamentos e generalizações/especializações) também as propriedades da ocorrência da entidade genérica correspondente. GENERALIZAÇÃO/ESPECIALIZAÇÃO EXCLUSIVA Significa que uma ocorrência de entidade genérica aparece, para cada hierarquia generalização/especialização, no máximo uma vez. GENERALIZAÇÃO/ESPECIALIZAÇÃO NÃO EXCLUSIVA Neste caso, uma ocorrência da entidade genérica pode aparecer em múltiplas especializações. No exemplo abaixo, considera-se o conjunto de pessoas vinculadas a uma universidade. Neste caso a especialização não é exclusiva, já que a mesma pessoa pode aparecer em múltiplas especializações. Uma pessoa pode ser professor de um curso e ser aluno em outro curso (pós- graduação, por exemplo). Por outro lado, uma pessoa pode acumular o cargo de professor em tempo parcial com o cargo de funcionário, ou, até mesmo, ser professor de tempo parcial em dois departamentos diferentes, sendo portanto duas vezes professor. O principal problema que este tipo de generalização/especialização apresenta é que neste caso as entidades especializadas não podem herdar o identificador da entidade genérica. No caso, o identificador de pessoa não seria suficiente para identificar professor, já que uma pessoa pode ser múltiplas vezes professor.
  • 15. MODELAGEM EM BANCO DE DADOS 14 ENTIDADE ASSOCIATIVA Um relacionamento é uma associação entre entidades. Na modelagem ER não foi prevista a possibilidade de associar uma entidade com um relacionamento ou então de associar dois relacionamentos entre si. Uma entidade associativa nada mais é que a redefinição de um relacionamento, que passa a ser tratado como se fosse também uma entidade. Representamos graficamente uma entidade associativa conforme o exemplo abaixo:
  • 16. MODELAGEM EM BANCO DE DADOS 15 MODELO RELACIONAL CHAVE PRIMÁRIA: Atributo através do qual seja possível identificar determinado registro. Uma chave primária não pode ser repetida, ou seja, o conjunto de valores que constituem a chave primária deve ser único dentro de uma tabela. • Chave primária simples: apenas um atributo (campo) compõe a chave primária. • Chave primária composta: mais de um atributo compõe a chave primária. CHAVE ÚNICA: Utilizada quando determinado campo não deve ser repetido e não é chave primária. Aumenta a consistância do banco de dados. Exemplo: Cadastro de clientes. Cada cliente recebe um código único, que é a chave primária. Para maior segurança e consistência podemos optar que o campo RG também seja único, evitando que o mesmo cliente seja cadastrado duas vezes. CHAVE ESTRANGEIRA: Utilizada quando queremos que o valor de um atributo seja validado a partir do valor de atributo de uma outra tabela. Criamos assim uma relação de dependência (um relacionamento) entre as tabelas. Exemplo: Antes de efetuar o cadastro de um pedido de venda, é necessário que o cliente em questão conste no cadastro de clientes. RELACIONAMENTOS: Associação estabelecida entre campos comuns de duas tabelas. Dessa forma permitimos o estabelecimento de correspondência entre registros de diferentes tabelas. Relacionamento um-para-um (1-1): FUNCIONARIO ARMARIO CodigoFuncionario (1) ----| NumeroArmario NomeFuncionario |--- (1) CodigoFuncionario EnderecoFuncionario DataCadastro TelefoneFuncionario Relacionamento um-para-muitos (1-N): CLIENTE PEDIDO CodigoCliente (1) ---| NumeroPedido NomeCliente |---- (N) CodigoCliente EnderecoCliente DataPedido TelefoneCliente CodigoProduto Relacionamento muitos-para-muitos (N-N): Não é possível efetuar de forma direta. Esse tipo de relacionamento só é possível definindo uma terceira tabela (tabela de associação ou tabela de detalhes). Essa tabela deve possuir chave primária composta de dois campos e as chaves estrangeiras provenientes das duas tabelas primárias. Concluindo, um relacionamento de muitos-para-muitos deve ser dividido em dois relacionamentos de um-para-muitos com uma terceira tabela. PEDIDO ITENSPEDIDO PRODUTO NumeroPedido (1) -------- (N) NumeroPedido |---- (1) CodigoProduto CodigoCliente CodigoProduto (N) ---| DescProduto DataPedido Quantidade ValorProduto EstoqueProduto NOTAÇÃO RESUMIDA PARA MODELOS LÓGICOS RELACIONAIS Notação compacta, útil para discussões sobre a estrutura geral do banco de dados, utilizada quando não se deseja entrar no nível maior de detalhamento. Funcionario(CodFunc, Nome, CodDept, CPF) CodDept referencia Departamento Departamento(CodDept, Nome)
  • 17. MODELAGEM EM BANCO DE DADOS 16 INTEGRIDADE DE DADOS INTEGRIDADE DE DOMÍNIO: Zela pelos valores ideais e necessários para um atributo. Para isso definimos algumas regras de validação por meio de expressões compostas de valores constantes. • Não permitir um estoque negativo • Impedir uma data de nascimento superior à data atual • Não permitir que o valor de um produto seja negativo INTEGRIDADE DE ENTIDADE: Tem o objetivo de validar os valores permitidos a partir de valores já inseridos na própria entidade. Após uma “auto-consulta” a entidade vai permitir ou não a gravação do novo registro. • Não permitir duas pessoas com o mesmo CPF • Impedir que seja locada uma fita que já está locada INTEGRIDADE REFERENCIAL: Zela pela consistência dos registros de uma entidade a partir de valores provenientes de outras entidades, isto é, determinado registro vai “depender” diretamente de um registro de outra tabela. • Um registro em uma tabela pai pode ter um ou mais registros em uma tabela filho. • Um registro em uma tabela filho sempre tem um registro coincidente em uma tabela pai. • Para a inclusão de um registro em uma determinada tabela filho, é necessário que exista um registro pai coincidente. • Um registro pai só poderá ser excluído se não possuir nenhum registro filho. NOMENCLATURA DE CAMPOS • Não utilizar caracteres especiais (exceto o underscroe “_”); • Começar com uma letra e não com um número; • Evitar acentuação e “ç”; • Não utilizar espaços. ORACLE - TIPOS DE DADOS Tipo Descrição char Cadeia de caracteres de tamanho fixo n. O default é 1 e o máximo é 255. varchar2 (n) Cadeia de caracteres de tamanho variável. Tamanho máximo 4.000. Cadeia de caracteres de tamanho variável. Tamanho máximo 2 GB. Só long pode existir um campo deste tipo por tabela. Equivalente ao varchar2 e long, respectivamente. Utilizado para raw e long raw armazenar dados binários (sons, imagens, etc.) Limite: 2.000 bytes. number (p,e) Valores numéricos. Ex: number (5,2) armazena -999,99 a +999,99. date Armazena data e hora (inclusive minuto e segundo). Ocupam 7 bytes. CONSTRAINTS / RESTRIÇÕES Nome Uso Informa se o campo pode receber valores nulos. Caso não possa, deve ser null precedido de not. Indica que os valores na coluna, ou conjunto de colunas, não pode ser unique repetido. Cria um índice automaticamente. check Especifica os valores que uma coluna pode assumir. primary key Identifica a chave primária da tabela. Cria um índice automaticamente. Identifica a chave estrangeira da tabela. Implementada pela cláusula foreign key references.
  • 18. MODELAGEM EM BANCO DE DADOS 17
  • 19. MODELAGEM EM BANCO DE DADOS 18
  • 20. MODELAGEM EM BANCO DE DADOS 19 NORMALIZAÇÃO • Conceito introduzido em 1970 por E. F. Codd (1FN). • Processo matemático formal com fundamento na teoria dos conjuntos. O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados para verificar se estas foram corretamente projetadas. Objetivos principais: • Garantir a integridade dos dados, evitando que informações sem sentido sejam inseridas. • Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a redundância e permitindo a evolução do banco de dados. São seis as formas normais mais conhecidas: • 1FN – 1ª Forma Normal • 2FN – 2ª Forma Normal • 3FN – 3ª Forma Normal • FNBC – Forma Normal de Boyce e Codd • 4FN – 4ª Forma Normal • 5FN – 5ª Forma Normal Nota: As três primeiras formas normais atendem à maioria dos casos de normalização. Uma forma normal engloba todas as anteriores, i.e., para que uma tabela esteja na 2FN, ela obrigatoriamente deve estar na 1FN e assim por diante. Normalmente após a aplicação das regras de normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas. Este processo colabora significativamente para a estabilidade do modelo de dados e reduz consideravelmente as necessidades de manutenção. Conceitos úteis: 1. Chaves • Chave candidata: Atributo ou conjunto de atributos que são únicos para cada registro. Para cada tabela podemos ter uma ou várias chaves desse tipo. Exemplo: codigo e cpf. • Chave primária: Entre as chaves candidatas, escolhemos uma para ser o identificador principal da tabela. Este atributo passa a ser chamado de chave primária (PK – Primary Key). • Chaves alternativas: São as chaves candidatas que não foram definidas como chave primária. • Chave estrangeira: É o atributo ou conjunto de atributos que faz a ligação com a chave primária de outra tabela (FK – Foreign Key). 2. Dependência Funcional (DF) Sempre que um atributo X identifica um atributo Y, dizemos que entre eles há uma dependência funcional. Temos, portanto, que X é o determinante e que Y é o dependente. A representação é: X Y (lê-se X determina Y ou Y é dependente de X). cidade estado estado país Em outras palavras, estado é funcionalmente dependente de cidade e país é fincionalmente dependente de estado. Ou ainda, estado é dependente de cidade e país é dependente de estado. E por último, cidade determina estado e estado determina país. 3. Trivialidade A dependência funcional trivial indica que um determinante com mais de um atributo pode determinar seus próprios membros quando isolados.
  • 21. MODELAGEM EM BANCO DE DADOS 20 {banco, agência} banco DF trivial: banco é parte do determinante {banco, agência} agência DF trivial: agência é parte do determinante Quando um determinante identifica outro atributo qualquer, temos uma dependência funcional não trivial (essa DF é a que nos interessa no processo de normalização): {banco, agência} cidade DF não trivial: cidade não faz parte do determinante 4. Transitividade Se um atributo X determina Y e se Y determina Z, podemos dizer que X determina Z de forma transitiva. i.e., existe uma dependência funcional transitiva de X para Z. cidade estado estado país ciade país (cidade determina país de forma transitiva) 5. DF (Dependência Funcional) irredutível à esquerda Dizemos que o lado esquerdo de uma dependência funcional é irredutível quando o determinante está em sua forma mínima. Temos a forma mínima quando não é possível reduzir a quantidade de atributos determinantes sem perder a dependência funcional. {cidade, estado} país (não está na forma irredutível à esquerda, pois podemos ter somente o estado como determinante) estado país (forma irredutível à esquerda) Nota: Nem sempre estar na forma irredutível à esquerda significa possuir um determinante com apenas uma coluna. 6. DMV (Dependência Multivalorada) A DMV é uma ampliação da Dependência Funcional (DF). Na DMV o valor de um atributo determina um conjunto de valores de um outro atributo. É representada por X Y (X multideterina Y ou Y é multidependente de X). DF: {CPF} {Nome} Temos somente um nome para cada CPF DMV: {CPF} {Dependente} Temos vários dependentes para cada pessoa
  • 22. MODELAGEM EM BANCO DE DADOS 21 Primeira Forma Normal: Uma Tabela está na Primeira Forma Normal quando seus atributos não contêm grupos de repetição (tabelas aninhadas). Proj(CodProj,Desc(CodFunc,Nome,Salario,DtInicio)) Não está na 1FN Proj(CodProj,Desc) ProjFunc(CodProj,CodFunc,Nome,Salário,DtInicio) Está na 1FN Segunda Forma Normal: Ocorre quando a chave primária é composta por mais de uma coluna. Neste caso, devemos observar se todos as colunas que não fazem parte da chave dependem de todos os colunas que compõem a chave. Se alguma coluna depender somente de parte da chave composta (dependência funcional parcial), então esta coluna deve pertencer a outra tabela. ProjFunc(CodProj,CodFunc,Nome,Cargo,Salario,DtInicio) Não está na 2FN ProjFunc(CodProj,CodFunc,DtInicio) Func(CodFunc,Nome,Cargo,Salario) Está na 2FN Terceira Forma Normal: Uma tabela está na Terceira Forma Normal quando cada coluna não chave depende diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas. Uma dependência funcional transitiva acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária. Func(CodFunc,Nome,Cargo,Salario) Não está na 3FN Func(CodFunc,Nome,Cargo) Cargo(Cargo,Salario) Está na 3FN Forma Normal de Boyce-Codd A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata). Aplica-se a FNBC quando: • Encontramos duas ou mais chaves candidatas • As chaves candidatas são compostas (apresentam mais de um atributo) • Todas as chaves candidatas têm um atributo em comum Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante. No exemplo a seguir vamos assumir que um professor possa estar associado a mais de uma Escola e uma sala. Aluno(NomeAluno,EnderecoAluno,NomeEscola,NumeroSala,NomeProfessor) Chaves candidatas: NomeAluno+EnderecoAluno Encontramos três chaves candidatas NomeAluno+NumeroSala Todas apresentam mais de um atriobuto (concatenados) NomeAluno+NomeProfessor Todas compartilham um mesmo atributo: NomeAluno Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas, uma que contém todos os atributos que descrevem o aluno e outra que contém os atributos que designam um professor em uma determinada escola e número de sala. Aluno(NomeAluno,EnderecoAluno,NomeEscola,NumeroSala) Sala(NomeEscola,NumeroSala,NomeProfessor)
  • 23. MODELAGEM EM BANCO DE DADOS 22 Quarta Forma Normal: Uma tabela está na Quarta Forma Normal caso não possua mais de uma dependência funcional multivalorada. CodProj CodFunc CodEquip CodProj CodFunc CodProj CodEquip 1 1 1 1 1 1 1 1 2 1 1 2 1 2 1 1 2 2 1 2 1 1 2 2 2 2 2 1 1 2 1 2 CodProj multidetermina de forma independente CodFunc e CodEquip. Quinta Forma Normal Aplicada em casos de relacionamentos múltiplos (ternários ... n-ários). Trata do conceito de dependência de junção. Primeiro decompõe-se a tabela através de uma operação de projeção e em seguida faz-se a reconstrução da mesma através de uma junção. A tabela está na Quinta Forma Normal quando seu conteúdo não puder ser reconstruído através da junção destas tabelas secundárias. Material Pedido Requisicao Material Pedido Pedido Requisicao Material Requisicao 1 1 1 1 1 1 1 1 1 1 2 2 1 2 2 2 1 2 2 1 2 2 1 1 2 2 2 1 1 2 Reconstruindo o conteúdo da tabela original através da junção natural das tabelas secundárias: 1º passo – Junção da tabela MaterialPedido com PedidoRequisicao: Material Pedido Requisicao 1 1 1 1 1 2 1 2 2 Esta linha não aparece na tabela gerada no 2º passo 2 1 1 2 1 2 2º passo – Junção da tabela PedidoRequisicao com MaterialRequisicao: Material Pedido Requisicao 1 1 1 1 2 2 Esta linha não aparece na tabela gerada no 1º passo 2 2 2 1 1 2 2 1 2 3º passo – Interseção das duas tabelas (geradas no 1º e no 2º passo): Material Pedido Requisicao 1 1 1 O conteúdo desta tabela é o mesmo da tabela original. 1 1 2 1 2 2 2 1 2
  • 24. MODELAGEM EM BANCO DE DADOS 23 NORMALIZAÇÃO PASSO A PASSO CASE 1: 1FN, 2FN E 3FN Exemplo: em uma determinada empresa, os produtos recebidos de um fornecedor são registrados em um formulário próprio que pode ser visualizado a seguir: NOTA DE FORNECIMENTO DE MERCADORIA Data 24/08/2004 Nº da Nota: 001 Fornecedor CodForn Nome Telefone Endereço 25 ABC Ltda 011 5555-1111 Rua Direita, 12 Item CodItem CodProd Produto Quantidade Preço Total Item 1 CA Chapa de aço 35 15,00 525,00 2 BB Bobina 20 15,00 300,00 3 TC Tábuas Corridas 50 20,00 1.000,00 NOTA DE FORNECIMENTO DE MERCADORIA Data 25/08/2004 Nº da Nota: 002 Fornecedor CodForn Nome Telefone Endereço 32 XYZ Ltda 011 5555-2222 Rua Esquerda, 13 Item CodItem CodProd Produto Quantidade Preço Total Item 1 TC Tábuas Corridas 50 20,00 1.000,00 2 CM Compensado 30 15,00 450,00 3 RM Ripas de Madeira 300 2,00 600,00 NOTA DE FORNECIMENTO DE MERCADORIA Data 26/08/2004 Nº da Nota: 003 Fornecedor CodForn Nome Telefone Endereço 25 ABC Ltda 011 5555-1111 Rua Direita, 12 Item CodItem CodProd Produto Quantidade Preço Total Item 1 CA Chapa de aço 50 15,00 750,00 2 BB Bobina 20 15,00 300,00 Vamos informatizar esse processo criando uma base de dados para armazenar as informações deste formulário. A primeira versão pode ser vista a seguir. Essa estrutura ainda não pode ser carregada em um banco de dados relacional, pois possui campos multivalorados (CodItem, CodProd, Produto, Qtde, Preço, Total Item). NrNota Data CodForn Nome Telefone Endereço CodItem CodProd Produto Qtde Preço TotalItem 1 CA Chapa de aço 35 15,00 525,00 001 24/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 2 BB Bobina 20 15,00 300,00 3 TC Tábua corrida 50 20,00 1.000,00 1 TC Tábua corrida 50 20,00 1.000,00 002 25/08/04 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 2 CM Compensado 30 15,00 450,00 3 RM Ripa de madeira 300 2,00 600,00 1 CA Chapa de aço 50 15,00 750,00 003 26/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 2 BB Bobina 20 15,00 300,00 1ª Forma Normal (1FN) O primeiro passo para normalizar a estrutura é aplicar as regras da primeira forma normal. Uma entidade está na primeira forma normal quando cada atributo contém somente um valor, em somente um lugar. Essa exigência é também conhecida como atomicidade de dados. As regras gerais para obtenção da 1FN são: • Não podemos ter atributos multivalorados. Nesse caso, colocamos cada valor do atributo em uma linha diferente e repetimos os dados de todas as outras colunas. • Não podemos ter atributos repetidos, como Telefone1, Telefone2, etc. A solução é semelhante ao item anterior.
  • 25. MODELAGEM EM BANCO DE DADOS 24 • Todos os registros têm de ser diferentes • A entidade não pode ter mais de duas dimensões • Cada atributo deve ter somente um tipo de dado. Uma violação comum dessa regra, por exemplo, é a criação de um campo para armazenar o CPF e o CNPJ, alternadamente. Esse cenário deve ser evitado pois cria complicações para a evolução da regra de negócio. Observe a tabela gerada após a aplicação da FN1: NrNota Data CodForn Nome Telefone Endereço CodItem CodProd Produto Qtde Preço TotalItem 001 24/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 1 CA Chapa de aço 35 15,00 525,00 001 24/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 2 BB Bobina 20 15,00 300,00 001 24/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 3 TC Tábua corrida 50 20,00 1.000,00 002 25/08/04 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 1 TC Tábua corrida 50 20,00 1.000,00 002 25/08/04 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 2 CM Compensado 30 15,00 450,00 002 25/08/04 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 3 RM Ripa de madeira 300 2,00 600,00 003 26/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 1 CA Chapa de aço 50 15,00 750,00 003 26/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 2 BB Bobina 20 15,00 300,00 Para trabalhar com a 2FN precisamos definir uma chave primária. Na tabela recém-criada, a chave escolhida é formada pelos campos NrNota e CodItem, pois através deles detrminamos todos os outros campos. Por exemplo: Com NrNota, determinamos os campos Data, CodForn, Nome, Telefone e Endereço: NrNota {Data, CodForn, Nome, Telefone, Endereço} Com NrNota e CodItem determinamos os demais campos: {NrNota, CodItem} {CodProd, Produto, Qtde, Preço, TotalItem} 2ª Forma Normal (2FN) Essa forma normal visa a diminuição da redundância e o desagrupamento de informações. Com a 2FN, uma tabela passa a representar uma quantidade menor de entidades (o ideal é que cada entidade seja armazenada em apenas uma tabela). A tabela anterior agrupa as entidades: Nota Fiscal, Item da Nota Fornecedor e Produto. A definição da segunda forma normal é: uma tabela está em 2FN se estiver em 1FN e todo atributo não-chave for determinado por todos os campos da chave primária. Em outras palavras, é necessário eliminar as dependências funcionais parciais. A tabela anterior viola a 2FN pois os campos Data, CodForn, Nome, Telefone e Endereço não são determinados pela chave primária completa (o campo CodItem não é necessário para identificar essas informações). NrNota {Data, CodForn, Nome, Telefone, Endereço} Como regra geral, a 2FN deve ser aplicada através dos passos: 1. Eleger a chave primária da tabela; 2. Verificar as dependências funcionais parciais; 3. Mover os campos não enquadrados na 2FN para uma nova tabela, fazendo a decomposição sem perdas; 4. Na tabela criada, repetir os passos 1 a 4 até eliminar a DF parcial. O resultado pode ser observado a seguir. Observe que todos os campos, nas duas tabelas são agora determinados por suas chaves primárias completas – garantindo a 2FN. Note também que o resultado da aplicação desta forma normal são tabelas mais simples, que representam as entidades com mais proximidade. tabela 1 NrNota Data CodForn Nome Telefone Endereço 001 24/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12 002 25/08/04 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 003 26/08/04 25 ABC Ltda 5555-1111 Rua Direita, 12
  • 26. MODELAGEM EM BANCO DE DADOS 25 tabela 2 NrNota CodItem CodProd Produto Qtde Preço TotalItem 001 1 CA Chapa de aço 35 15,00 525,00 001 2 BB Bobina 20 15,00 300,00 001 3 TC Tábua corrida 50 20,00 1.000,00 002 1 TC Tábua corrida 50 20,00 1.000,00 002 2 CM Compensado 30 15,00 450,00 002 3 RM Ripa de madeira 300 2,00 600,00 003 1 CA Chapa de aço 50 15,00 750,00 003 2 BB Bobina 20 15,00 300,00 3ª Forma Normal (3FN) A 3FN dá continuidade ao objetivo da 2FN: reduzir as redundâncias, desagrupando as tabelas de forma que cada uma represente apenas uma entidade. No exemplo acima, a tabela 1 agrupa informações sobre as entidades Nota e Fornecedor e a tabela 2 agrupa informações sobre as entidades ItemNota e Produto. A técnica utilizada pela 3FN é a identificação e eliminação da transitividade. Dizemos que uma tabela está na 3FN se também estiver na 2FN e todo atributo não chave for determinado de uma forma não transitiva pela chave primária. Em outra leitura, dizemos que todo atributo não chave deve ser determinado somente pela chave primária. Vamos analisar a tabela criada na 2FN. Observe que os campos Nome, Telefone e Endereço podem ser determinados tanto pela chave primária quanto pelo campo CodForn: NrNota {Data, CodForn, Nome, Telefone, Endereço} CodForn {Nome, Telefone, Endereço} Assim esses campos possuem dependência funcional transitiva com a chave primária: NrNota CodForn {Nome, Telefone, Endereço} Na segunda tabela também temos transitividade: {NrNota, CodItem} CodProd {Produto, Preço} Outro tipo de violação da 3FN são os campos calculados, que também possuem transitividade. Na 3FN todos os campos calculados são removidos da base de dados. Veja a representação: {NrNota, CodItem} Preço, Quantidade {TotalItem} Para adequar as tabelas a 3FN, seguimos um roteiro semelhante ao usado na 2 FN: 1. Mover os campos com transitividade para uma nova tabela; 2. Criar uma chave primária na tabela nova com o(s) campo(s) da tabela original que determinava(m) diretamente os campos movidos. 3. Na nova tabela, repetir os passos 1, 2 e 3, até eliminar totalmente a transitividade. Observe a seguir o formato final das tabelas após a aplicação da 3FN. Tabela Fornecedor CodForn Nome Telefone Endereço 25 ABC Ltda 5555-1111 Rua Direita, 12 32 XYZ Ltda 5555-2222 Rua Esquerda, 13 Tabela Produto CodProd Produto Preço CA Chapa de aço 15,00 BB Bobina 15,00 TC Tábua corrida 20,00 CM Compensado 15,00 RM Ripa de madeira 2,00
  • 27. MODELAGEM EM BANCO DE DADOS 26 Tabela Nota NrNota Data CodForn 001 24/08/04 25 002 25/08/04 32 003 26/08/04 25 Tabela Item Nota NrNota CodItem CodProd Qtde 001 1 CA 35 001 2 BB 20 001 3 TC 50 002 1 TC 50 002 2 CM 30 002 3 RM 300 003 1 CA 50 003 2 BB 20 Nesse ponto temos a organização ideal para a base de dados, pelos motivos a seguir: 1. A decomposição foi feita sem perdas (através de junções podemos recuperar a tabela original); 2. As quatro entidades (Nota, ItemNota, Fornecedor e Produto) possuem tabelas exclusivas, eliminando o agrupamento de informações e a redundância; 3. As tabelas foram separadas de tal forma que as anomalias de atualização não poderão ocorrer; 4. As tabelas são fáceis de evoluir e manter. Por exemplo, se quisermos incluir dados de um produto que ainda não tenha sido fornecido, podemos inserir sua descrição na tabela Produtos (isso não era possível até a aplicação da 3FN); 5. Do ponto de vista relacional, os dados estão armazenados e distribuídos de forma eficiente. CASE 2: 4FN Um condomínio deseja cadastrar os veículos e os motoristas que os dirigem (para cada apartamento): Apto Nome Placa 101 João GBD-2541 101 João GHJ-5468 101 Maria GBD-2541 101 Maria GHJ-5468 101 Carlos GBD-2541 101 Carlos GHJ-5468 102 Paulo GDA-7677 102 Rosa GDA-7677 Placa Carro Ano GBD-2541 Siena 2003 GHJ-5468 Parati 2002 GDA-7677 Fusca 1990 Nome Idade João 55 Maria 50 Carlos 22 Paulo 57 Rosa 56 A primeira tabela contém anomalias de atualização. Se o apartamento 101 comprar mais um carro, precisaremos inserir mais três linhas na primeira tabela. Se o apartamento 102 vender o carro perderemos a informação de quem mora no referido apartamento. Estas anomalias ocorrem porque temos duas DMVs independentes: {Apto} {Nome} {Apto} {Placa}
  • 28. MODELAGEM EM BANCO DE DADOS 27 Ou como aparece em algumas bibliografias: {Apto} {Nome}|{Placa} Para deixarmos a tabela na 4FN devemos efetuar a decomposição sem perdas e levar cada DMV para uma tabela diferente. Apto Nome 101 João 101 Maria 101 Carlos 102 Paulo 102 Rosa Apto Placa 101 GBD-2541 101 GHJ-5468 102 GDA-7677 Nome Idade João 55 Maria 50 Carlos 22 Paulo 57 Rosa 56 Placa Carro Ano GBD-2541 Siena 2003 GHJ-5468 Parati 2002 GDA-7677 Fusca 1990 Note que a primeira tabela pode ser unida à terceira tabela e que a segunda tabela também pode ser unida à quarta tabela. Ou seja, a normalização nem sempre leva ao formato ideal exigindo sempre uma análise do seu resultado. Apto Nome Idade 101 João 55 101 Maria 50 101 Carlos 22 102 Paulo 57 102 Rosa 56 Apto Placa Carro Ano 101 GBD-2541 Siena 2003 101 GHJ-5468 Parati 2002 102 GDA-7677 Fusca 1990 BIBLIOGRAFIA SQL Magazine – Edições 6 e 7
  • 29. MODELAGEM EM BANCO DE DADOS 28 ÁLGEBRA RELACIONAL • Desenvolvida para descrever operações sobre uma base de dados relacional • Cada operador toma uma ou duas relações como sua entrada e produz uma nova relação como sua saída • Linguagem da consulta teórica, usuários não a utilizam diretamente • É usada internamente em todos os SGBDRs Características: • Constituída de cinco operadores fundamentais: σ Seleção (sigma) π Projeção (pi) Produto cartesiano X Diferença – ∪ União • Três operadores derivados: ∩ Intersecção Junção : Divisão SELEÇÃO Seleciona todas as tuplas que satisfazem à condição de seleção de uma relação R. σ (A=’a1’)(R) R A B A B a1 b1 a1 b1 a2 b2 PROJEÇÃO Produz uma nova relação com apenas alguns atributos de R, removendo as tuplas duplicadas. π (B)(R) R A B B a1 b1 b1 a2 b2 b2 PRODUTO CARTESIANO Produz uma nova relação com todas as possíveis tuplas resultantes da combinação de duas tuplas, uma de cada relação envolvida na operação. R (R X S) A B A B C D a1 b1 a1 b1 c2 d2 a2 b2 a1 b1 c3 d3 a2 b2 c2 d2 S a2 b2 c3 d3 C D c2 d2 c3 d3
  • 30. MODELAGEM EM BANCO DE DADOS 29 DIFERENÇA Produz uma nova relação com todas as tuplas em R que não estão em S. R e S devem ter número iguais de atributos. R (R - S) A B A B a1 b1 a1 b1 a2 b2 S A B a2 b2 a3 b3 UNIÃO Produz uma nova relação com a união das tuplas em R e em S. R e S devem ter número iguais de atributos. ∪ S) R (R A B A B a1 b1 a1 b1 a2 b2 a2 b2 a3 b3 S A B a2 b2 a3 b3 INTERSECÇÃO Produz uma nova relação com a intersecão das tuplas em R e em S, ou seja, com as tuplas que aparecem em R e em S. R e S devem ter número iguais de atributos. ∩ S) R (R A B A B a1 b1 a2 b2 a2 b2 S A B a2 b2 a3 b3 JUNÇÃO Junção de R com S = (R X S) [expressão de seleção] R R X S [B = C] A B A B C D a1 b1 a1 b1 b1 d3 a2 b2 a2 b2 b2 d2 S C D b2 d2 b1 d3
  • 31. MODELAGEM EM BANCO DE DADOS 30 JUNÇÃO NATURAL Quando a condição de junção for a igualdade do valor de um atributo comum e o atributo comum aparecer só uma vez no resultado. R R*S A B A B D a1 b1 a1 b1 d3 a2 b2 a2 b2 d2 S C D b2 d2 b1 d3 DIVISÃO Produz uma nova relação S contendo todas as tuplas de A (dividendo) que aparecem em R (mediador) com todas as tuplas de B (divisor). A R B S A A B B A a1 a1 b1 b1 a1 a2 a1 b2 a2 a3 a1 b3 a4 a1 b4 B S a5 a2 b1 a2 b2 B A a3 b2 b2 a1 a4 b2 b4 a4 a4 b4 B S B A b1 a1 b2 b3 b4 SOFTWARE WinRDBI (Windows Relational DataBase Interpreter) http://www.eas.asu.edu/~winrdbi/ Arizona State University • Relational Algebra • Domain Relational Calculus • Tuple Relational Calculus • SQL
  • 32. MODELAGEM EM BANCO DE DADOS 31 CÁLCULO RELACIONAL Alternativa à Álgebra Relacional Logicamente equivalentes Baseia-se em um ramo da lógica matemática chamado cálculo de predicados Referências bibliográficas: Cálculo relacional como base para uma linguagem de consulta: J.L.Kuhns: “Answering Questions by Computer: A Logical Study.” (1967) Cálculo de predicados adaptados especificamente a banco de dados relacionais: E.F.Codd: “A Relational Model of Data for Large Shared Data Banks.” (1970) Cálculo Relacional: descreve qual é o problema (não procedural). Álgebra Relacional: Prescreve um procedimento para resolver o problema (procedural). CÁLCULO RELACIONAL DE TUPLA É baseado na especificação de um conjunto de variáveis de tuplas. Cada variável de tupla pode assumir como seu valor qualquer tupla da relação especificada. Forma geral: • Variável livre: Assume velores de tuplas de uma ou mais relações. Constitui a resposta da consulta. • Predicado: Expressão lógica que, se verdadeira para determinados valores das variáveis livres t, v, ..., x, retorna os valores destas variáveis na resposta da consulta. EXEMPLOS – SELEÇÃO E PROJEÇÃO: 1. Buscar os dados dos pacientes que estão com sarampo: ∈ ∧ {p | p Pacientes p.doenca = 'sarampo'} 2. Buscar o número e a capacidade dos ambulatórios do terceiro andar ∈ ∧ {a.numero, a.capacidade | a Ambulatorios a.andar = 3} EXEMPLOS – PRODUTOS OU JUNÇÃO: 1. Buscar o nome dos médicos que têm consulta marcada e as datas das suas consultas: ∈ ∧ ∈ ∧ {m.nome, c.data | m Medicos c Consultas m.crm = c.crm} 2. Buscar os nomes dos médicos ortopedistas e o número e andar dos ambulatórios onde eles atendem: ∈ ∧ ∧ {m.nome, a.numero, a.andar | m Medicos m.especialidade = 'ortopedia' ∈ ∧ a Ambulatorios m.numero = a.numero}
  • 33. MODELAGEM EM BANCO DE DADOS 32 QUANTIFICADORES EXISTENCIAIS: ∃ exists ∀ forall QUANTIFICADOR EXISTENCIAL ∃ v (P) Existe pelo menos um valor v que torna P verdadeira. QUANTIFICADOR UNIVERSAL ∀ v (P) Para todos os valores de v, P é verdadeira. EXEMPLO: Suponha que a variável v percorra o conjunto Senado, e suponha que P seja a FBF * quot;v é mulherquot;, então: ∃ v (P) verdadeiro ∀ v (P) falso * FBF = Fórmula Bem Formada EXEMPLOS – QUANTIFICADOR EXISTENCIAL: 1. Buscar o nome dos médicos que atendem em ambulatórios do segundo andar: ∈ ∧∃ ∈ ∧ Ambulatorios (a.andar = 2 {m.medico | m Medicos a m.numero = a.numero)} 2. Buscar o nome e o problema dos pacientes de têm consulta marcada com o médico João da Silva: ∈ Pacientes ∧ ∃ c ∈ Consultas (p.rg ∧∃ ∈ = c.rg {p.nome, p.problema | p m ∧ c.nome = 'Joao da Silva'))} Medicos (c.crm = m.crm EXEMPLOS – QUANTIFICADOR UNIVERSAL: 1. Buscar o nome dos médicos que têm consulta marcada com todos os pacientes: ∈ ∧∀ ∈ ∈ ∧ Pacientes (∃ c Consultas (p.rg = c.rg {m.medico | m Medicos p c.crm = m.crm))} 2. Buscar o nome dos pacientes de têm consulta marcada com todos os médicos ortopedistas: ∈ ∧ ∀ m ∈ Medicos (m.especialidade ∃c∈ {p.nome | p Pacientes = 'ortopedia' m.crm ∧ c.rg = p.rg))} Consultas (c.crm =
  • 34. MODELAGEM EM BANCO DE DADOS 33 CÁLCULO RELACIONAL DE DOMÍNIO No CRD as variáveis estendem-se sobre valores únicos de domínios de atributos. Para formar uma relação de grau n para um resultado de consulta, faz-se necessário criar n variáveis de domínio, uma para cada atributo. Forma geral: • Variáveis de domínio: Abrangem os valores únicos dos domínios dos atributos. Devemos ter n destas variáveis de domínio, uma para cada atributo. • Fórmula: São constituídas a partir de átomos, variáveis e quantificadores. EXEMPLOS: 1. Buscar o nome da agência, número da conta que têm saldo superior a 1200 reais: ∈ ∧ {a, c, s | a, c, s Contas s > 1200} 2. Buscar os nomes de todos os clientes que tenham uma conta em todas as agências localizadas na Aclimação: ∈ ∧ ∃ a, b (x, a, b ∈ Contas { c | ∀ x, y, z (x, y, z Agencias y = 'Aclimacao' ∧ ∈ c, a Clientes)} NOTA: Enquanto a SQL (baseada no Cálculo Relacional de Tupla) estava sendo desenvolvida pela IBM Research em San Jose, Califórnia, outra linguagem, chamada QBE (Query By Example (baseada no Cálculo Relacional de Domínio) estava sendo desenvolvida quase simutaneamente pela IBM Research em Yorktown Heights, Nova York.
  • 35. MODELAGEM EM BANCO DE DADOS 34 EXERCÍCIOS Sistema Bancário Em sistema bancário simplificado temos: Clientes, onde cada cliente tem CPF, RG, nome, endereço, telefone e estado civil. Um cliente pode ter mais de uma conta em agências distintas. As agências possuem código da agência, nome, endereço e nome do gerente. Sobre as contas tem-se número da conta e saldo atualizado. Uma conta é gerenciada por uma única agência. Os clientes podem movimentar suas contas, na movimentação deve constar sobre o tipo (crédito ou débito), quantia, data e hora. Sistema Locadora Uma pequena locadora de vídeos possui ao redor de 2000 fitas de vídeo, cujo empréstimo deve ser controlado. Cada fita possui um número. Para cada filme, é necessário saber seu título e sua categoria (comédia, drama, aventura, ... ). Cada filme recebe um identificador próprio. Cada fita é controlado que filme ela contém. Para cada filme há pelo menos uma fita, e cada fita contém somente um filme. Alguns poucos filmes necessitam mais de uma fita. Os clientes podem desejar encontrar os filmes estrelados pelo seu ator predileto. Por isso, é necessário manter a informação dos atores que estrelam em cada filme. Nem todo filme possui estrelas. Para cada ator os clientes às vezes desejam saber o nome real, bem como a data de nascimento. A locadora possui muitos clientes cadastrados. Somente clientes cadastrados podem alugar fitas. Para cada cliente é necessário saber seu prenome e seu sobrenome, seu telefone e seu endereço. Além disso, cada cliente recebe um número de associado. Finalmente desejamos saber que fitas cada cliente tem emprestadas. Um cliente pode ter várias fitas em um instante do tempo. Não são mantidos registros históricos de aluguéis. Sistema Cinema Projetar um modelo de dados que atenda às necessidades de controle dos cinemas e filmes em uma determinada empresa de distribuição de filmes. Regras de negócio que serão a base para o desenvolvimento do DER: A empresa de distribuição possui vários cinemas em várias localidades. Cada cinema possui identificação única, um nome fantasia, um endereço, etc. Cada filme é registrado com um título original, tempo de duração, etc. Existirá um único diretor para cada filme. Cada filme terá vários atores. As sessões possuem horários variados. Os atores de um filme podem atuar em diversos filmes, assim como o diretor de um filme pode também ser ator neste filme, ou ainda mais, ser ator em outro filme. Um ator possui número, nome, nacionalidade e idade. Sistema Escola Uma escola mantém em seu catálogo vários cursos livres (Windows, Word, etc.). Professores são contratados para ministrar um ou mais cursos. Há várias turmas para cada curso. Cada turma tem um professor. Um aluno pode matricular-se simultaneamente em vários cursos e, portanto, pertencer a mais de uma turma. Elabore um DER completo para o caso acima.
  • 36. MODELAGEM EM BANCO DE DADOS 35 Sistema Museu de Arte Projete o DER para um museu de arte, conforme as seguintes informações coletadas: O museu tem uma coleção de objetos de arte. Cada objeto tem um número, um artista (se conhecido), um ano (quando foi criado, se conhecido), um título e uma descrição. Os objetos de arte são categorizados de diversas formas de acordo com o seu tipo. Há três tipos principais: pintura, escultura e estátua, mais um chamado outros para comodar objetos que não se enquadram em algum dos três tipos principais. Uma pintura tem um tipo (óleo, guache, etc.), material (papel, tela, madeira, etc.) e estilo (moderno, abstrato, etc.). Uma escultura tem o material do qual foi criado (madeira, pedra, etc.) e estilo. Um objeto de arte na categoria outros tem um tipo (impressão, foto, etc.) e estilo. Um objeto de arte também é categorizado como coleção permanente que é de propriedade do museu (com as informações de data de aquisição, se está exposto ou guardado e preço) ou empréstimo, do qual tem informações da coleção (da qual foi emprestado), data de empréstimo e data de devolução. Cada objeto de arte tem também a descrição de seu país/cultura de origem (iteliano, egípcio, americano, etc.) e época (renascimento, moderna, antiga, etc.). O museu mantém informações sobre artistas, quando conhecidos: nome, data de nascimento, data de falecimento (se não-vivo), país de origem, época, estilo principal e descrição. Nome é assumido como sendo único. Diferentes exibições ocorrem, cada uma tem um nome, data de início e data de término, e é relacionada a todos os objetos de arte que estão à mostra durante a exibição. Mantêm-se também informações de outras coleções com a qual o museu interage, incluindo nome (único), tipo (museu, pessoal, etc.), descrição, endereço, telefone e pessoa de contato. Sistema Empresa Uma empresa é organizada em departamentos. Cada departamento possui um nome e um código único, e o departamento pode ter várias localidades (cidades). Os projetos existentes na empresa são, obrigatoriamente, controlados por um departamento, e cada projeto possui um nome, um código único e uma única localização (cidade), que pode ser diferente das possíveis localidades do departamento que o controla. Alguns departamentos não possuem projetos sobre sua responsabilidade, como por exemplo o “departamento pessoal”. No caso dos empregados da empresa é armazenado número de matricula, nome, endereço, salário, sexo e data de nascimento. Quase todos os empregados tem um outro empregado que é o seu supervisor direto, e consequentemente, somente alguns são supervisores, conforme a sua hierarquia na empresa. Em função da cadeia hierárquica existem empregados que não possuem supervisores. A maioria dos empregados são alocados a um departamento, ou seja, pode até existir um empregado sem departamento, mas todo departamento deve possuir empregados alocados a ele, além disso, todo departamento tem um chefe que o gerencia, a partir de uma data, pois a empresa implementa um sistema de rodízio na chefia dos departamentos, o rodízio na chefia determina que um empregado só pode ser chefe de somente um departamento. Um empregado pode trabalhar em mais de um projeto, mesmo que não seja do seu departamento, dedicando algumas horas por semana em cada um dos projetos. E, é claro, alguns empregados, como os do “departamento pessoal”, não estão empenhados em nenhum projeto. Por outro lado, todo projeto tem pelo menos um ou mais empregados trabalhando nele. A empresa oferece alguns benefícios sociais aos dependentes dos seus empregados, caso ele possua. Para tanto, é mantido para cada dependente do empregado o nome do dependente, o sexo, a data de nascimento e o grau de parentesco. Sistema Agenda Deseja-se construir uma agenda de endereços de pessoas e empresas onde trabalham. As pessoas da agenda possuem endereços para fins postais e telefones, que podem ser residenciais, comerciais, fax, celular ou de outro tipo. Anota-se no telefone DDD, prefixo e
  • 37. MODELAGEM EM BANCO DE DADOS 36 número. Telefones do tipo fixo são associados a endereços e telefones do tipo móvel são associados a pessoas. A cada endereço associa-se um código de endereço(único), rua, número, bairro, CEP, todo endereço de pessoa pode ser classificado dentre os tipos residência própria, residência com os pais, residência com parentes, residência com amigos, de referência ou outro, sendo que, um endereço pode pertencer a mais de uma pessoa. Para toda pessoa da agenda armazena-se seu código seqüencial na agenda, seu nome. Uma pessoa pode ser amiga de outras pessoas e têm armazenadas a data de início da amizade entre elas, ou se a pessoa for parente de outras pessoas deve armazenar o tipo do parentesco. Alem disso, pessoas têm armazenadas, o seu sexo e sua data de nascimento e a profissão. Sendo que algumas pessoas podem trabalhar em uma empresa da agenda. Da Empresa, armazena-se a razão social da empresa, a inscrição estadual, o CGC, o ramo de dedicação da empresa e o proprietário da empresa que é uma pessoa armazenada na agenda. As empresas da agenda possuem um único endereço, e em uma empresa trabalham várias pessoas da agenda, sendo que a existência de uma empresa está condicionada a existir uma pessoa na agenda que trabalha nela. Sistema Imobiliária Uma imobiliária lida com venda de imóveis urbanos. Para qualquer imóvel têm-se registradas a sua inscrição, preço de venda, área total e área construída. Todo imóvel tem localização num endereço. A cada endereço associa-se um código de endereço, rua, número, bairro, CEP e os telefones associados (se existirem). Uma pessoa pode assumir um dos seguintes papéis em relação a imobiliária: corretor, proprietário de imóvel ou comprador. Sobre o proprietário do imóvel têm-se CPF, nome, estado civil e, se for casado, o nome do cônjuge. Um proprietário pode ter vários imóveis a venda na imobiliária. Sobre os compradores têm-se CPF, nome, profissão e uma lista de preferências de imóveis a adquirir. Sobre os corretores da imobiliária têm-se número do CRECI, nome e data de admissão. Um corretor negocia com um comprador a venda de um imóvel. E, é claro, um corretor negocia outros imóveis com outros compradores, podendo um mesmo comprador adquirir um outro imóvel com o mesmo comprador e com outros compradores. Sobre a venda são necessárias as seguintes informações: data da venda, valor da venda e valor da comissão. Sistema campeonato de futebol Na construção de um banco de dados para administrar times, jogos e campeonatos de futebol, cada time tem um nome (único) e uma quantidade de jogadores que jogam para o time, a partir de uma data inicial e final do contrato. Nos jogos do time, cada um desses jogadores é escalado, e, é preciso saber qual foi a sua escalação no jogo (o número da camiseta do jogador). Para cada jogador tem-se o nome, o apelido, a posição, o salário e o número de registro na federação. Um time participa de jogos com outros times dentro de campeonatos. Um jogo é realizado em estádio numa certa data (dia e hora) e produz um resultado, registrando, também, o público presente e a renda do jogo. Cada jogo realizado tem um número de ordem em função do campeonato, ou seja, o número de ordem serve para identificar um jogo dentro do campeonato que ele pertence. Os estádios tem nome (único), cidade, capacidade de público e o(s) time(s) que mandam jogo naquele estádio, sendo que os times só possuem um estádio onde eles mandam seus jogos. Em um jogo válido pelo campeonato deve ter sempre um juiz da federação, sobre os juízes que apitam os jogos tem-se os nome, número de registro na federação, nome da mãe, classe, data que começou como juiz e para quais campeonatos está designado, e claro durante um campeonato temos vários juizes escalados. Para um campeonato tem-se o nome (único), quantidade de times e descrição, e para cada campeonato precisa-se ter os times que participaram do campeonato, bem como a classificação de cada time e o time que foi o campeão.