View
217
Download
0
Category
Preview:
Citation preview
BASES DE DADOS I LTSI/2 Universidade da Beira Interior, Departamento de Informática Hugo Pedro Proença, 2010/2011
Modelo Conceptual
Modelo Conceptual de uma Base de Dados
Esquematização dos dados necessários para um conjunto de aplicações, visualizando simultaneamente o relacionamento existente entre eles. O modelo produzido auxiliará à criação da Base de Dados pretendida.
Dois níveis (Duas fases): Conceptual: Representação o mais aproximada possível da
realidade a modelar, sem considerar restrições técnicas ao nível da implementação.
Físico: Adaptação do modelo conceptual construído anteriormente às características de um sistema informático específico.
Modelo Conceptual
Existem normalmente duas abordagens para a concepção e modelação de uma base de dados:
Bottom-Up
Parte da identificação dos itens mais elementares de informação (atributos) e prossegue agrupando-os e identificando os relacionamentos entre eles. Esta é a metodologia mais comummente utilizada no processo de construção de bases de dados,sendo normalmente composta pelas seguintes fases:
Modelo Entidade / Relacionamento Análise das dependências funcionais Construção do modelo
Modelo Conceptual
Top-Down: Normalmente mais utilizada em grandes projectos, onde a quantidade e complexidade da informação a modelar é elevada. Começa pela identificação de grandes objectos de informação (entidades). Identifica os relacionamentos entre entidades e os atributos que compõem cada uma.
Apresenta como principais vantagens: Construção faseada Facilita a comunicação entre o analista (autor do modelo) e o
implementador. Não exige o levantamento antecipado de todos os itens de informação
(atributos) a incluir na base de dados. Facilidade em lidar com grandes quantidades de informação.
Modelo Entidade / Relacionamento
Entidade: Qualquer objecto ou conceito com interesse para a organização a respeito da qual é necessário registar informação. Esta deve poder ser identificada de forma unívoca.
Exemplos:
Funcionário, Departamento, Produto, Peça, Contrato, ...
Atributo: Toda a propriedade relativa a uma entidade pode ser classificada como um atributo. Devem ser elementos atómicos de informação.
Relacionamento: Ligação lógica entre diferentes entidades.
Professor Disciplina Ensina
(Número, Nome, ...) (Código, Descrição, ...)
Diagrama de Ocorrências
O Diagrama de Ocorrências serve para exemplificar um relacionamento entre entidades.
Exemplo:
...Um professor pode leccionar várias disciplinas ...Cada disciplina só é leccionada por um professor ...Todas as disciplinas são leccionadas por algum professor
Professor P1 P2 P3 P4
Disciplina D1 D2 D3 D4
Diagrama Entidade / Relaccion.
Relacionamento de grau 1:1 sem participação obrigatória de nenhuma das entidades. Cada instância de qualquer das entidades pode-se relacionar no máximo com uma instância da outra entidade.
A1
A2
A3
A4
B1
B2
B3
B4
1 1
A B
Diagrama Entidade / Relaccion.
Relacionamento de grau 1:1 com participação obrigatória de uma das entidades. No lado da entidade obrigatória todas as instâncias têm obrigatoriamente que se relacionar com uma instância da outra relação.
A1
A2
A3
A4
B1
B2
B3
1 1
A B
Diagrama Entidade / Relaccion.
Relacionamento de grau 1:1 com participação obrigatória de ambas as entidades. Qualquer instância tem obrigatoriamente que se relacionar com uma instância da outra relação
A1
A2
A3
B1
B2
B3 1 1
A B
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau 1:N sem participação obrigatória. Cada instância de uma entidade (A) pode-se relacionar com “n” instâncias da outra (B). No entanto cada instância desta (B) apenas se relaciona, no máximo com uma entidade de (A).
A1
A2
A3
B1
B2
B3 1 n
A B
B4
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau 1:N com participação obrigatória de (A). Cada instância de (A) pode-se relacionar com “n” instâncias de (B), tendo no mínimo que se relacionar com uma. Ao invés, cada instância de (B) apenas se relaciona, no máximo com uma entidade de (A).
A1
A2
B1
B2
B3 1 n
A B
B4
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau 1:N com participação obrigatória de (B). Cada instância de (A) pode-se relacionar com “n” instâncias de (B), tendo no mínimo que se relacionar com uma. Ao invés, cada instância de (B) apenas se relaciona, no máximo com uma entidade de (A).
A1
A2
B1
B2
B3 1 n
A B
B4
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau N:M sem participação obrigatória. Cada instância de (A) pode-se relacionar com “M” de (B). Cada instância de (B) pode-se relacionar com “N” de (A)
A1
A2
B1
B2
B3 n m
A B
B4 A3
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau N:M com participação obrigatória de (A). Cada instância de (A) pode-se relacionar com “M” de (B), tendo no mínimo que se relacionar com uma. Cada instância de (B) pode-se relacionar com “N” de (A)
A1
A2
B1
B2
B3 n m
A B
B4 A3
Diagrama Entidade / Relaccion.
Relacionamento (A,B) de grau N:M com participação obrigatória de ambas as entidades. Cada instância de (A) pode-se relacionar com “M” de (B), tendo no mínimo que se relacionar com uma. Cada instância de (B) pode-se relacionar com “N” de (A) tendo igualmente que se relacionar com uma no mínimo.
A1
A2
B1
B2
B3 n m
A B
B4 A3
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 e participação obrigatória de ambas as entidades:
Apenas é necessária uma relação.
A chave dessa relação pode ser a chave primária de qualquer das entidades.
1 1
Professor Disciplina
BI NomeProf CodDisciplina Descricao
123 Ana 5671 Álgebra
651 José 7182 Análise
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 e participação obrigatória de apenas uma das entidades.
1 1
Professor Disciplina
BI NomeProf CodDisciplina Descricao
123 Ana 5671 Álgebra
651 José 7182 Análise
null null 7612 Química
Surgirão valores “null” sempre que uma disciplina não tiver professor
São necessárias duas relações, uma para cada entidade. A chave primária da entidade com participação não obrigatória é usada como atributo na relação com participação obrigatória.
BI NomeProf CodDisciplina
123 Ana 5671
651 José 7182
CodDisciplina Descrição
5671 Álgebra
7182 Análise
7612 Química
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 sem participação obrigatória nenhuma das entidades.
1 1
Professor Disciplina
A criação de uma relação, ou a sua sub-divisão em duas, origina sempre o potencial aparecimento de valores nulos. Neste caso são necessárias 3 relações, uma para cada entidade e a terceira para modelar os relacionamentos entre elas.
BI NomeProf
123 Ana
651 José
898 Pedro
CodDisciplina Descrição
5671 Álgebra
7182 Análise
7612 Química
BI CodDisciplina
123 5671
651 7182
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N sem participação obrigatória nenhuma das entidades.
1 n
Professor Disciplina
Neste caso são necessárias 3 relações, uma para cada entidade e a terceira para modelar os relacionamentos entre elas. A chave da tabela correspondente ao relacionamento será composta pela conjunto das chaves das duas entidades a modelar.
BI NomeProf
123 Ana
651 José
898 Pedro
CodDisciplina Descrição
5671 Álgebra
7182 Análise
7612 Química
9825 Física
BI CodDisciplina
123 5671
651 7182
123 7612
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N com participação obrigatória do lado (N)
1 n
Professor Disciplina
Esta situação pode ser modelada eficientemente por duas relações, em que na relação do lado (N) se coloca como chave externa a chave primária da outra relação. A chave primária de cada relação corresponde à chave primária de cada entidade.
BI NomeProf
123 Ana
651 José
898 Pedro
CodDisciplina Descrição BI*
5671 Álgebra 123
7182 Análise 651
7612 Química 123
9825 Física 651
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N com participação obrigatória do lado (1)
1 n
Professor Disciplina
Neste caso são necessárias três relações, uma para cada entidade e a terceira para modelar o relacionamento. A chave primária da tabela de relacionamento será a composição da chave primária das restantes entidades.
BI NomeProf
123 Ana
651 José
898 Pedro
CodDisciplina Descrição
5671 Álgebra
7182 Análise
7612 Química
9825 Física
5281 Biologia
BI CodDisciplina
123 5671
651 7182
123 7612
898 9825
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos binários de grau M:N.
m n
Professor Disciplina
Neste tipo de relacionamentos são sempre necessárias 3 tabelas. Uma para cada entidade e a terceira para modelar o relacionamento. Tal como nos casos anteriores, a chave primária desta relação será a composição das chaves das restantes entidades.
BI NomeProf
123 Ana
651 José
898 Pedro
CodDisciplina Descrição
5671 Álgebra
7182 Análise
7612 Química
9825 Física
5281 Biologia
BI CodDisciplina
123 5671
651 7182
123 7612
898 9825
Diagrama Entidade / Relaccion.
Regra de Relacionamento: Modelação de relacionamentos entre K entidades (K>2).
1 n
Professor Disciplina
Neste tipo de relacionamentos são sempre necessárias no mínimo (K+1) tabelas. Uma para cada entidade e a ultima para modelar o relacionamento existente. Tal como nos casos anteriores, a chave primária da tabela relacionamento será a composição das chaves das restantes entidades.
Sala
m
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
Análise de requisitos.
Fase inicial do processo de construção de uma base de dados. Corresponde à recepção de toda a informação e conjunto de regras que governarão o sistema pretendido. Constitui uma fase nuclear, uma vez que serve de fonte a todo o subsequente processo de desenvolvimento.
Identificação de entidades.
A partir da informação recebida na fase anterior, identificam-se e agrupam-se todos os itens de informação relevante.
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
Identificação dos atributos próprios de cada entidade. Este será o conjunto de atributos que pertencem exclusivamente a cada uma
das entidades identificadas no pontos anterior. Após esta fase, cada uma das entidades permanecerá isolada, não existindo atributos que denotam a existência de relações entre entidades.
Identificação de relacionamentos entre entidades. Após a identificação de cada entidade parte-se para a análise de
relacionamentos entre entidades. Quais as que se relacionam entre si ? De que forma será feita esse relacionamento?
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
Análise da cardinalidade e obrigatoriedade das relações. Para o conjunto de relacionamentos identificados anteriormente,
identificar o tipo, cardinalidade e obrigatoriedade de cada um. É um relacionamento binário ? Ternário ? Do tipo de “pertença”, “respeitante a”, ...? É obrigatório para alguma das relações ? Para todas ? Qual a cardinalidade da relação ?
Construção de relações. Após a fase anterior é possível esboçar o conjunto de relações e
respectivos atributos (próprios e de relacionamento) que irão compor a base de dados.
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
Identificação de chaves candidatas e externas. Tendo as relações definidas é necessário identificar claramente os
atributos ou conjuntos de atributos que podem ser usados como chaves primárias das relações (as chaves candidatas). Os atributos que denotam relacionamentos (chaves externas) devem também merecer atenção especial.
Normalização do modelo. Os passos anteriores permitiram a construção de um primeiro modelo do
sistema. É necessário proceder à sua optimização, executando o processo de normalização associado ao modelo relacional.
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
Optimização do modelo. A fase anterior (normalização) pode ter acrescentado regras ou
restarições ao sistema ? É importante garantir que as premissas originais permanecem satisfeitas. Finalmente pode-se partir para a optimização do modelo a implementar. Alguma das chaves primárias identificadas tem demasiados atributos, ou
o tipo de algum atributo pode constituir problema ? Será preferível implementar chaves numéricas sequenciais a algumas das
relações ? Quais ?
Modelo Conceptual
Processo de desenvolvimento de uma base de dados:
É importante notar que o processo de construção descrito anteriormente é iterativo e normalmente regressivo, isto é, em cada momento pode ser necessária a passagem a fases anteriores, por forma a resolver problemas apenas identificados posteriormente.
A análise de requisitos será em ultimo caso o ponto de partida de cada nova abordagem, e é de importãncia relevante a sua qualidade.
Todas as regras estão claramente definidas? Enuncia os obejectivos pretendidos para o sistema? Existem ambiguidades? É objectiva?
Modelo Conceptual
Por vezes a análise de requisitos não fornece toda a informação necessária para a implementação da base de dados de suporte ao sistema de informação.
Caso seja possível consultar as fontes de informação necessárias, será sempre esta a situação preferível, por forma a ajustar a base de dados o mais possível ao pretendido
Caso contrário, cabe ao analista/implementador a terefa de fazer assumpções sobre o funcionamento do sistema, condicionando de alguma forma o seu desempenho.
Modelo Conceptual - Exemplo
Uma empresa de distribuição de combustíveis decidiu implementar um sistema de fidelização de clientes através da atribuição de pontos por abastecimentos efectuados. O texto que se segue é um resumo resultante da análise de requisitos entretanto efectuada:
“Temos neste momento 256 postos distribuídos pelo Continente e Regiões Autónomas e estamos firmemente decididos a alargar a nossa quota de mercado. Para isso pensámos em lançar uma nova promoção que visa essencialmente a atribuição de pontos aos clientes por cada litro de combustível abastecido. Cada cliente que deseje aderir basta efectuar o processo de registo num dos nossos postos e ser-lhe-à atribuído um cartão de acumulação de pontos. Estes poderão posteriormente ser trocados por um conjunto de prendas ou por litros de combustível. Sendo os combustíveis a nossa área de negócio, decidimos atribuir uma bonificação de 15% sobre a totalidade de pontos aos clientes que optem pela troca por combustível.
A inovação desta campanha reside no dinamismo da cotação de cada tipo de prenda. Consoante o desenrolar da promoção e analisando a relação entre os produtos mais desejados pelos clientes e a quantidade existente em stock, poderá ser alterada a quantidade de pontos necessários para a aquisição de um determinado produto, podendo esta cotação variar entre postos de abastecimento. Na tentativa de aumentar o consumo de combustível, decidimos atribuir um prazo de validade a cada ponto acumulado por cliente. Em principio, este será de 30 dias, apesar deste ponto ainda ser passível de alteração em reunião de direcção. Para evitar que os nossos clientes se sintam defraudados com a perca de pontos ou com a qualidade das prendas recebidas, decidimos permitir que prendas a partir de 2000 pontos possam ser atribuídas simultaneamente a mais que um cliente, isto é, permitir que vários clientes juntem os pontos necessários para receber prendas mais valiosas.
Modelo Conceptual - Exemplo
Outro dos aspectos importantes reside na facilidade com que o sistema permitirá a identificação de processos fraudulentos, bastantes comuns neste tipo de campanhas. (Enorme acumulação de pontos num determinado momento, acumulação de pontos simultaneamente em dois postos de abastecimentos distintos, etc...) Relativamente às prendas atribuídas, elas são todas adquiridas através da sede e posteriormente distribuídas pela nossa rede de abastecimento. Por esta razão o preço de custo é fixo para cada uma delas. O sistema que pretendemos servirá essencialmente para registar informação sobre os resultados desta campanha, os clientes que aderiram, as prendas atribuídas, litros abastecidos, etc... A nossa empresa dá grande relevância à área das novas tecnologias e estamos obviamente dispostos a aceitar sugestões que possam ter e permitam optimizar os resultados da campanha...”
Modelo Conceptual – Exemplo
Modelo Conceptual – Exemplo
Construa um modelo conceptual de base de dados utilizando o modelo relacional. Siga o processo de construção atrás
descrito para a construção de um modelo passível de implementação física.
Modelo Conceptual – Exemplo
Passo 1: Análise de Requisitos
Vulgarmente a análise de requisitos não é efectuada pela equipa que vai conceber e implementar a base de dados. Também neste caso, a análise (os aspectos mais importantes) é-nos fornecida através do texto anteriormente transcrito.
Estão enunciadas todas as regras do sistema? Podem-se inferir novas regras? Necessário repetir processo de análise de requisitos para
esclarecimento de dúvidas, regras?
Modelo Conceptual – Exemplo
Passo 2: Identificação de Entidades
A partir da leitura (repetida) da análise de requisitos podem-se identificar as seguintes entidades:
• Clientes
• Postos de Abastecimento
• Combustíveis • Promoções
• Pontos
• Vendas
• Prendas • Fornecedores
• Cartões
Modelo Conceptual – Exemplo
Passo 3: Identificação dos atributos próprios de cada entidade.
Qual a informação que é necessário guardar acerca de cada entidade identificada na fase anterior? Será que vale mesmo a pena considerar todas as entidades?
• Clientes • NumCliente • Nome • Morada
• PostosAbastecimento • CodPosto • Descrição • Localização • Encarregado
Modelo Conceptual – Exemplo
Passo 3: Identificação dos atributos próprios de cada entidade.
• Pontos • ?
• Vendas • DataVenda • Valor
Existe informação relevante para registar acerca de cada ponto ? Apesar de bastante referido na análise de requisitos, será necessária a criação de uma entidade ?
Modelo Conceptual – Exemplo
Passo 3: Identificação dos atributos próprios de cada entidade.
• Promoções • CodPromoção • DataInicio • DataFim • Designação
• Combustíveis • CodCombustivel • Descrição • ValorVenda
Para possibilitar que o sistema implementado funcione não só para esta, como outras promoções
Modelo Conceptual – Exemplo
Passo 3: Identificação dos atributos próprios de cada entidade.
• Prendas • CodPrenda • Designação • ValorUnitário
• Fornecedores • CodFornecedor • Nome • Morada
• Cartões • CodCartão • DataRegisto
Modelo Conceptual – Exemplo
Passo 4: Identificação dos relacionamentos entre entidades. Quais os relacionamentos existentes entre as entidades
identificadas nos passos anteriores? São obrigatórias? Qual a sua cardinalidade? O funcionamento do sistema pode ser flexibilizado sem
violação de nenhuma regra definida no processo de análise?
É necessária a implementação do modelo entidade / relacionamento...
Modelo Conceptual – Exemplo
Passo 4: Identificação dos relacionamentos entre entidades:
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar
Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Para cada relação existente no modelo entidade/relacionamento é necessário expressar a sua cardinalidade e obrigatoriedade.
Caso seja necessário, é altura de efectuar os diagramas de ocorrência para melhor ilustrar as regras subjacentes a cada relacionamento.
Exemplo:
Oferta1
Oferta2
Oferta3
Cartão1
Cartão2
Cartão3
Cartão4 Oferta4
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Que regras se podem inferir do diagrama de ocorrências anterior?
Respeitam as restrições iniciais do problema? Restringem/alargam a flexibilidade do sistema?
Cada oferta é sempre efectuada a um único cartão? Todas as ofertas são efectuadas a algum cartão? Existem cartões que podem acumular ofertas? Existem cartões sem nenhumas ofertas?
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
A partir da análise dos diagramas de ocorrência, pode-se partir para um primeiro esboço da cardinalidade de cada relação.
A obrigatoriedade de cada uma deve também estar explicita, uma vez que constitui um factor importante na transposição do modelo conceptual para o modelo físico da base de dados.
A decomposição de relações de grau maior que dois deve também constituir uma preocupação, uma vez que irá facilitar a passagem para o modelo físico e a realização do processo de normalização.
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar
Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir 1
1
n m
1
n
m n
n
n 1 n
n
n
1
p
1
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar
Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir 1
1 m
1
n
1 n
n
1 n
n
n
1
1
1 Relativa
m
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir 1
1 m
1
n
1
1
n
n
n
1
1
1
Relativa
1
OfertaCartão
Relativa
1
n
n
Modelo Conceptual – Exemplo
Passo 5: Análise da cardinalidade e obrigatoriedade das relações:
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir 1
1 m
1
n
1
1
n
n
n
1
1
1
Relativa
OfertaCartão
Relativa
1
n
n
1 1
Modelo Conceptual – Exemplo
Passo 6: Construção do esquema de relações
Mediante a informação que é necessário registar e o diagrama entidade / relacionamento obtido na fase anterior, pode-se partir para um esboço do conjunto de relações (tabelas) existentes na base de dados.
Aplicação das regras de transposição para o modelo físico.
Análise da cardinalidade de cada relacionamento Análise da obrigatoriedade de cada relacionamento.
Modelo Conceptual – Exemplo
Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação
Combustível • CodCombustível • Descrição • Preço
Venda • Data • Hora • CodCliente (*) • CodPostoAbastecimento (*) • CodCombustível (*) • Pontos
PostoAbastecimento • CodPostoAbastecimento • Descrição • Localização • Encarregado ?
Cliente • CodCliente • Nome • Morada
Fornecedor • CodFornecedor • Nome • Morada
? Cartão • CodCartão • CodCliente (*) • DataRegisto • CodPostoRegisto (*)
Modelo Conceptual – Exemplo
Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação
Oferta • CodOferta • Data • Hora • CodPrenda (*) • CodPromoção (*)
OfertaCliente • CodCliente (*) • CodOferta (*)
Promoção • CodPromoção • Descrição • DataInicio • DataFim
Prenda • CodPrenda • Nome • Pontos • CodFornecedor(*)
?
Modelo Conceptual – Exemplo
Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação O primeiro modelo gerado levanta algumas duvidas, nomeadamente
relativamente a... Determinar a cotação actual de cada prenda Identificar qual o posto que atribuiu uma prenda (cada uma será
forçosamente atribuída num posto de combustível) Registo do nome do encarregado (E se este se repetir em múltiplos postos) Localização dos postos e morada dos clientes. Será de toda a utilidade a
disponibilização de informação detalhada (Sem redundância e sem violação de alguma forma normal inferior À terceira).
Será necessário efectuar algumas alterações ao modelo...
Modelo Conceptual – Exemplo
Cliente
PostoAbastecimento
Combustível
Promoção
Venda
Prenda Fornecedor
Registar
Referir
Localizar Efectuar
Fornecimento
Respeitar
Oferta
Relativa
Cartão
Possuir 1
1 m
1
n
1 n
n
n
1
1
1
Relativa
OfertaCartão
Relativa
1
n
n
CodigoPostal
Localizar
Encarregado
Gerir Cotação
Referir
1
Efectuar n
n
1 1
1
n
1
Modelo Conceptual – Exemplo
Passo 6 + Passo 7: Adição de relações e alteração das anteriores
CodigoPostal • Codigo • Cidade
Encarregado • CodEncarregado • Nome • Telefone
Cotação • CodPrenda • Data • Pontos
Oferta • CodOferta • Data • Hora • CodPrenda (*) • CodPostoCombustível(*)
PostoAbastecimento • CodPostoAbastecimento • Descrição • Localização • CodPostal(*) • CodEncarregado (*)
Cliente • CodCliente • Nome • Morada • CodPostal (*) • DataRegisto • CodPostoRegisto (*)
OfertaCartão • CodOferta (*) • CodCartão (*)
Modelo Conceptual – Exemplo
Passo 8: Normalização do modelo
Aplicar o processo de normalização a cada relação existente: A 1FN é verificada? A 2FN é verificada? A 3FN é verificada? A FNBC também? Valerá a pena prosseguir com o processo até aos níveis
máximos (4FN e 5FN)? Existem dependências multi-valor ou de junção?
Qual a forma normal escolhida? Porquê?
Modelo Conceptual – Exemplo
Passo 9: Optimização do modelo
Por motivos de eficiência ou segurança, será necessário substituir alguma chave primária identificada?
No caso de chaves compostas pode-se chegar à conclusão de que é mais eficiente a utilização de chaves numéricas auto-incrementais.
As chaves externas estão correctamente identificadas? São as ideais? Após a execução deste processo, chega-se ao modelo proposto para
a resolução do problema. Acrescentaram-se restrições ao funcionamento do sistema? Não? (Caso ideal) Sim? São razoáveis ?
Poderá ser necessário consultar novamente a(s) pessoa(s) que pediu a base de dados.
Recommended