| (8 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 43: | Linha 43: | ||
|[ ] || escolha uma das opções alternativas | |[ ] || escolha uma das opções alternativas | ||
|- | |- | ||
| Linha 97: | Linha 93: | ||
<br> | <br> | ||
* Exemplo: | |||
** Caminhão = @placa + marca + carga | |||
* | *** placa = {caracter-valido}3 + {digito} | ||
** Caminhão = @placa + marca + carga | |||
*** digito = [0-9] | *** digito = [0-9] | ||
*** marca = | *** marca = [ “BMW”|“Volvo”|“Mercedes”|“Outros”] | ||
<br> | <br> | ||
| Linha 256: | Linha 231: | ||
* DER ou DEA é uma técnica de | * DER ou DEA é uma técnica de modelagem que representa a visão estática dos dados e dos relacionamento (associações) entre eles | ||
* Um DER identifica: | * Um DER identifica: | ||
** as entidades internas do sistema (depósitos de dados) | ** as entidades internas do sistema (depósitos de dados) | ||
** as associações entre os dados | ** as associações entre os dados | ||
** as características dos dados e das associações | ** as características dos dados e das associações | ||
<br> | <br> | ||
* Estes elementos encontram-se espalhados pelos requisitos do problema, modelo de circulação da informação (DFDs), dicionário de dados (DDs) e especificação de processos | * Estes elementos encontram-se espalhados pelos requisitos do problema, modelo de circulação da informação (DFDs), dicionário de dados (DDs) e especificação de processos | ||
<br> | <br> | ||
[[Arquivo:DER-01.png|center]] | [[Arquivo:DER-01.png|center]] | ||
<br> | <br> | ||
# Será que um cliente pode ter alugado (ou pode alugar) vários filmes? | # Será que um cliente pode ter alugado (ou pode alugar) vários filmes? | ||
# Será que um cliente pode nunca ter alugado um filme? | # Será que um cliente pode nunca ter alugado um filme? | ||
# Será que um filme só pode ser alugado por um cliente, por nenhum ou por muitos? | # Será que um filme só pode ser alugado por um cliente, por nenhum ou por muitos? | ||
<br> | <br> | ||
* Devemos completar as associações com a sua cardinalidade. | * Devemos completar as associações com a sua cardinalidade. | ||
<br> | <br> | ||
== Cardinalidade == | == Cardinalidade == | ||
<br> | <br> | ||
* A cardinalidade define os graus de uma associação: | * A cardinalidade define os graus de uma associação: | ||
<br> | <br> | ||
[[Arquivo:DER-02.png|center]] | [[Arquivo:DER-02.png|center]] | ||
<BR> | <BR> | ||
== Relacionamento um-para-um (1:1) == | == Relacionamento um-para-um (1:1) == | ||
<br> | <br> | ||
* Indica que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade. | * Indica que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade. | ||
<br> | <br> | ||
* Este tipo de relacionamento é raro (no mundo cotidiano) | * Este tipo de relacionamento é raro (no mundo cotidiano) | ||
<br> | <br> | ||
* Exemplo: Logicamente aplicado a países que não aceitam poligamia | * Exemplo: Logicamente aplicado a países que não aceitam poligamia | ||
** MARIDO (1) possui (1) ESPOSA | ** MARIDO (1) possui (1) ESPOSA | ||
<br> | <br> | ||
[[Arquivo:Rel-um-pra-um.png|center]] | [[Arquivo:Rel-um-pra-um.png|center]] | ||
<br><br><br> | <br><br><br> | ||
* Exemplos de Maridos e suas respectivas Esposas | * Exemplos de Maridos e suas respectivas Esposas | ||
** Os depósitos de dados estão individualizados e os dados não necessariamente estão alinhados | ** Os depósitos de dados estão individualizados e os dados não necessariamente estão alinhados | ||
<br> | <br> | ||
[[Arquivo:Rel-um-pra-um-B.png|center]] | [[Arquivo:Rel-um-pra-um-B.png|center]] | ||
<br><br><br> | <br><br><br> | ||
* Uma forma interessante de armazenar: | * Uma forma interessante de armazenar: | ||
<br> | <br> | ||
[[Arquivo:Rel-um-pra-um-C.png|center]] | [[Arquivo:Rel-um-pra-um-C.png|center]] | ||
<br> | <br> | ||
* Cada linha de uma tabela se relaciona facilmente com a linha de outra | * Cada linha de uma tabela se relaciona facilmente com a linha de outra | ||
<br><br><br> | <br><br><br> | ||
== Relacionamento um-para-muitos (1:N ou 1:M) == | == Relacionamento um-para-muitos (1:N ou 1:M) == | ||
<br> | <br> | ||
* Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade | * Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade | ||
* No entanto, a recíproca não é verdadeira | * No entanto, a recíproca não é verdadeira | ||
* Este tipo de relacionamento é o mais encontrado | * Este tipo de relacionamento é o mais encontrado | ||
<br><br> | <br><br> | ||
[[Arquivo:Rel-um-pra-n.png|center]] | [[Arquivo:Rel-um-pra-n.png|center]] | ||
<br><br><br> | <br><br><br> | ||
* Uma situação comum: Um pai tem vários filhos | * Uma situação comum: Um pai tem vários filhos | ||
** Exige que existe uma referência na tabela filhos para encontrar o pai | ** Exige que existe uma referência na tabela filhos para encontrar o pai | ||
<br> | <br> | ||
[[Arquivo:Rel-um-pra-n-b.png|center]] | [[Arquivo:Rel-um-pra-n-b.png|center]] | ||
<br><br><br> | <br><br><br> | ||
== Relacionamento muitos-para-muitos (N:M) == | == Relacionamento muitos-para-muitos (N:M) == | ||
<br> | <br> | ||
* Indica que várias ocorrências de uma entidade podem se relacionar com muitas ocorrências de outra entidade | * Indica que várias ocorrências de uma entidade podem se relacionar com muitas ocorrências de outra entidade | ||
<br> | <br> | ||
* Geralmente, um relacionamento desse tipo pode ser convertido e simplificado pela criação de uma entidade intermediária (do tipo associativa) e de dois relacionamentos do tipo 1:N (um-para-muitos) | * Geralmente, um relacionamento desse tipo pode ser convertido e simplificado pela criação de uma entidade intermediária (do tipo associativa) e de dois relacionamentos do tipo 1:N (um-para-muitos) | ||
<br> | <br> | ||
* Exemplo: | * Exemplo: | ||
** Sistema de compras: Um cliente pode comprar vários produtos, e um produto pode ser comprado por vários clientes | ** Sistema de compras: Um cliente pode comprar vários produtos, e um produto pode ser comprado por vários clientes | ||
** Nesse caso, existe a necessidade da implementação de uma entidade fraca entre as duas entidades | ** Nesse caso, existe a necessidade da implementação de uma entidade fraca entre as duas entidades | ||
<br> | <br> | ||
* Essa entidade é chamada de entidade fraca pois sua chave primária é formada por duas chaves estrangeiras | * Essa entidade é chamada de entidade fraca pois sua chave primária é formada por duas chaves estrangeiras | ||
<br> | <br> | ||
* Nesse caso, as chaves estrangeiras poderão se repetir, mas o conjunto delas duas nunca irá se repetir, formando a chave primária | * Nesse caso, as chaves estrangeiras poderão se repetir, mas o conjunto delas duas nunca irá se repetir, formando a chave primária | ||
<br> | <br> | ||
* Como fazer para mostrar que um produto pode ser adquirido por mais de um cliente? | * Como fazer para mostrar que um produto pode ser adquirido por mais de um cliente? | ||
* Como mostrar que um cliente pode comprar mais de um produto? | * Como mostrar que um cliente pode comprar mais de um produto? | ||
<br><br> | <br><br> | ||
[[Arquivo:Rel-n-pra-n.png|center]] | [[Arquivo:Rel-n-pra-n.png|center]] | ||
<br><br><br> | <br><br><br> | ||
* Outra situação comum: Armazenar informações sobre professores e suas disciplinas. | * Outra situação comum: Armazenar informações sobre professores e suas disciplinas. | ||
* Analisando algumas necessidades: | * Analisando algumas necessidades: | ||
** Como fazer para incluir mais disciplinas para um professor? | ** Como fazer para incluir mais disciplinas para um professor? | ||
** Como permitir que uma disciplina seja dada por mais de um professor? | ** Como permitir que uma disciplina seja dada por mais de um professor? | ||
<br> | <br> | ||
[[Arquivo:Rel-n-pra-n-B.png|center]] | [[Arquivo:Rel-n-pra-n-B.png|center]] | ||
<br><br><br> | <br><br><br> | ||
* Essas condições forçam a ter uma segunda tabela para manter os relacionamentos acima. | * Essas condições forçam a ter uma segunda tabela para manter os relacionamentos acima. | ||
<br> | <br> | ||
| Linha 462: | Linha 387: | ||
[[Arquivo:Rel-n-pra-n-C.png|center]] | [[Arquivo:Rel-n-pra-n-C.png|center]] | ||
<br><br><br> | <br><br><br> | ||
= Exercícios = | = Exercícios = | ||
<br> | <br> | ||
# | # Desenhar cada Depósito de Dados com os principais atributos envolvidos (limitar em 10) | ||
# Complementar com novos atributos que não foram descritos | |||
# Destacar atributo(s) chave(s) para cada depósito | |||
# Criar os relacionamentos entre os depósitos | |||
<br> | |||
* a) Funcionário = {Nome + Endereço + Salário + Data-ingresso} | |||
** Avaliar: Endereço e Salário | |||
<br> | |||
* b) Cliente = {Nro-CPF + Nome + Endereço + Data-Nasc + Sexo + EstCivil} | |||
** Avaliar: Endereço, Sexo e EstCivil | |||
<br> | |||
* c) Aluno = {Matrícula + Nome + Sexo + Data-nasc + Curso} | |||
** Avaliar: Sexo e Curso | |||
<br> | |||
* d) Notas = {Matrícula + Disciplina + Sem + Notas} | |||
** Avaliar: Disciplina | |||
<br> | |||
* e) Livros = {Codigo + Titulo + Autor + Editora + Edição} | |||
** Avaliar: Autor + Editora | |||
<br> | |||
* f) Emprestimos = {Aluno + Livro + Data + Hora + Atendente + Biblioteca} | |||
** Avaliar: Aluno + Livro + Atendente | |||
<br> | <br> | ||
Edição atual tal como às 02h15min de 5 de outubro de 2011
Dicionário de dados
- Lista organizada dos elementos do sistema, com definições precisas e rigorosas
- Permite que tenhamos uma compreensão comum dos fluxos de entrada e saída, dos componentes dos depósitos de dados e dos cálculos intermediários
- Na descrição do dicionário é utilizada uma gramática, quase formal, para descrever o conteúdo dos elementos definidos durante a análise estruturada
- Especifica os “valores ” e “unidades ” de partes elementares de informações dos fluxos de dados e dos depósitos de dados
- Detalha os relacionamentos entre os depósitos especificados em um DER
| Símbolo | Notação |
|---|---|
| = | é composto de |
| ( ) | opcional (pode estar presente ou ausente) |
| { } | iteração (zero ou mais ocorrências) |
| [ ] | escolha uma das opções alternativas |
| @ | identificador (campo chave) de um depósito |
| Barra Vertical | separa as alternativas na construção [ ] |
Notação:
Exemplos de notação:
- { }
- código_cartão = {número_válido}7 ou 7{número_válido}
- caracter = {caracter-valido}
- filmes = { Filme + (código-sócio) }
- [ ]
- número_válido = [0-9]
- classe-social = [A-E]
- |
- sexo = [F | M]
- status = [ativo | inativo]
- titulo = [Sr. | Srta. | Sra. | Dr.]
- situação = [ "alugado" | "disponível" ]
- caracter-valido = [a-z | A-Z | ‘ | | - | .]
- @
- Aluno = @matricula + nome + cpf + identidade + cep + complemento
- Carro = @placa + marca + modelo + ano + cor + (acessorios)
- Filme = @código-filme + nome + realizador + (atorprincipal) + situação
- Disciplina = @{cod-disciplina + cod-professor} + nome + CH
- Exemplo:
- Caminhão = @placa + marca + carga
- placa = {caracter-valido}3 + {digito}
- digito = [0-9]
- marca = [ “BMW”|“Volvo”|“Mercedes”|“Outros”]
- Caminhão = @placa + marca + carga
Modelo Entidade-Relacionamento
- Modelos Conceituais Comuns para Bases de Dados
- Entidade Relacionamento:
- Focaliza na estrutura dos dados/metadados
- Modelagem funcional separada da Orientação a objetos que será vista mais a frente
- Entidade
- Grupo de pessoas, coisas ou eventos que compartilham um conjunto de atributos
- Caracterizada pelos relacionamentos com outros tipos
- Uma entidade é descrita (em BD) usando um conjunto de atributos
- Relacionamentos
- Associações lógicas entre entidades
Exemplo: Entidade Clientes
- Atributo identificador:
- número do cliente
- Atributos descritores:
- nome, cidade, telefone, data nascimento, profissão, sexo, etc
- Exemplo de instância:
- número do cliente: 125
- nome: João Freitas Filho
- cidade: Uberlândia
- telefone: 3214-4657
- data nascimento: 01/09/1984
- profissão: carpinteiro
- sexo: M
Relacionamento
- Um relacionamento ou associação representa um conjunto de ligações entre entidades que necessitam ser guardadas pelo sistema
- A associação é caracterizada pela conjunção dos atributos identificadores das entidades envolvidas
- Cada relacionamento é definida por:
- Substantivo + relação + Substantivo
Tipos de Relacionamento
- Unária: Auto-associação ou relação entre uma entidade e ela própria

- Binária: Relação entre duas entidades.

- Complexa: Relação entre três ou mais entidades

Chaves
Chave Primária
- Atributo usado como identificador do item da entidade, como por exemplo um produto que possui um código de barras que o difere dos demais produtos
- Esse código de identificação deve ser único
- Exemplos:
- matricula
- placa
- cpf
- Pode-notar que não pode existir dois ou mais dados iguais para a mesma chave
- Dois alunos não podem ter a mesma matrícula, dois carros não podem ter a mesma placa, duas pessoas não podem ter CPFs iguais
Chave Estrangeira
- Responsável pelo relacionamento entre duas entidades, como por exemplo, um produto que se relaciona com categoria deve conter como chave estrangeira o código (chave primária) da categoria a qual ele pertence
- Permite que a partir dela se chegue na chave primária de outra entidade.
- Exemplos:
- cidade na Entidade Pessoa => Várias pessoas podem ter a mesma cidade de origem
- professor na Entidade Disciplina => Uma disciplina pode ter vários professores ou uma professor pode ministrar várias disciplinas
- medico na Entidade Consulta => um médico pode fazer várias consultas para a mesma pessoa ou para pessoas diferentes
- banco na Entidade movimento-conta => Um cliente pode ter mais de uma conta no mesmo banco ou ter muitos movimentos na mesma conta
DER – Diagrama Entidade-Relacionamento
- DER ou DEA é uma técnica de modelagem que representa a visão estática dos dados e dos relacionamento (associações) entre eles
- Um DER identifica:
- as entidades internas do sistema (depósitos de dados)
- as associações entre os dados
- as características dos dados e das associações
- Estes elementos encontram-se espalhados pelos requisitos do problema, modelo de circulação da informação (DFDs), dicionário de dados (DDs) e especificação de processos

- Será que um cliente pode ter alugado (ou pode alugar) vários filmes?
- Será que um cliente pode nunca ter alugado um filme?
- Será que um filme só pode ser alugado por um cliente, por nenhum ou por muitos?
- Devemos completar as associações com a sua cardinalidade.
Cardinalidade
- A cardinalidade define os graus de uma associação:

Relacionamento um-para-um (1:1)
- Indica que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade.
- Este tipo de relacionamento é raro (no mundo cotidiano)
- Exemplo: Logicamente aplicado a países que não aceitam poligamia
- MARIDO (1) possui (1) ESPOSA

- Exemplos de Maridos e suas respectivas Esposas
- Os depósitos de dados estão individualizados e os dados não necessariamente estão alinhados

- Uma forma interessante de armazenar:

- Cada linha de uma tabela se relaciona facilmente com a linha de outra
Relacionamento um-para-muitos (1:N ou 1:M)
- Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade
- No entanto, a recíproca não é verdadeira
- Este tipo de relacionamento é o mais encontrado

- Uma situação comum: Um pai tem vários filhos
- Exige que existe uma referência na tabela filhos para encontrar o pai

Relacionamento muitos-para-muitos (N:M)
- Indica que várias ocorrências de uma entidade podem se relacionar com muitas ocorrências de outra entidade
- Geralmente, um relacionamento desse tipo pode ser convertido e simplificado pela criação de uma entidade intermediária (do tipo associativa) e de dois relacionamentos do tipo 1:N (um-para-muitos)
- Exemplo:
- Sistema de compras: Um cliente pode comprar vários produtos, e um produto pode ser comprado por vários clientes
- Nesse caso, existe a necessidade da implementação de uma entidade fraca entre as duas entidades
- Essa entidade é chamada de entidade fraca pois sua chave primária é formada por duas chaves estrangeiras
- Nesse caso, as chaves estrangeiras poderão se repetir, mas o conjunto delas duas nunca irá se repetir, formando a chave primária
- Como fazer para mostrar que um produto pode ser adquirido por mais de um cliente?
- Como mostrar que um cliente pode comprar mais de um produto?

- Outra situação comum: Armazenar informações sobre professores e suas disciplinas.
- Analisando algumas necessidades:
- Como fazer para incluir mais disciplinas para um professor?
- Como permitir que uma disciplina seja dada por mais de um professor?

- Essas condições forçam a ter uma segunda tabela para manter os relacionamentos acima.

Exercícios
- Desenhar cada Depósito de Dados com os principais atributos envolvidos (limitar em 10)
- Complementar com novos atributos que não foram descritos
- Destacar atributo(s) chave(s) para cada depósito
- Criar os relacionamentos entre os depósitos
- a) Funcionário = {Nome + Endereço + Salário + Data-ingresso}
- Avaliar: Endereço e Salário
- b) Cliente = {Nro-CPF + Nome + Endereço + Data-Nasc + Sexo + EstCivil}
- Avaliar: Endereço, Sexo e EstCivil
- c) Aluno = {Matrícula + Nome + Sexo + Data-nasc + Curso}
- Avaliar: Sexo e Curso
- d) Notas = {Matrícula + Disciplina + Sem + Notas}
- Avaliar: Disciplina
- e) Livros = {Codigo + Titulo + Autor + Editora + Edição}
- Avaliar: Autor + Editora
- f) Emprestimos = {Aluno + Livro + Data + Hora + Atendente + Biblioteca}
- Avaliar: Aluno + Livro + Atendente