Enquete

Para o TISS ficar melhor ainda, o que é preciso?
 

Notícias

On-line

Nós temos 5 visitantes online

Links


Google
Sem comentários :).
Perguntas mais frequentes
Perguntas mais frequentes encontradas no site da ANS.
TISS da ANS
Site do Tiss da ANS.
ANS
Site da Agência Nacional de Saúde.

Fases de um projeto de banco de dados relacional PDF Imprimir E-mail
Escrito por Administrator   
Qua, 07 de Julho de 2004 09:54
Objetivo

Gerar um banco de dados que permita armazenar informações sem redundância e recuperá-las com facilidade.

Fases de um projeto

Na modelagem de um banco de dados devemos primeiramente ter conhecimento do ambiente real ao qual será aplicado o modelo. Durante o processo de modelagem deverá ser usado o bom senso e as regras inerentes ao ambiente de aplicação do banco de dados.

1. Levantamento de requisitos

Um modelo de dados de alto nível oferece ao p+rojetista conceitos que o possibilitam especificar as necessidades dos usuários e como o banco será estruturado para atender plenamente todas as necessidades. Aqui são importantes as entrevistas e a avaliação do projetista.

Resultado dessa fase - Especificação das necessidades dos usuários (levantamento de requisitos).

2. Projeto conceitual

A fase conceitual depende muito da habilidade do projetista e das qualidades do modelo de dados adotado.

Escolha do modelo de dados, para com ele transcrever as necessidades e informações coletadas para um esquema de banco de dados.

O projeto conceitual indicará as necessidades funcionais da empresa, as consultas, exclusões, etc.

Então deve-se rever o esquema dos dados para adequar às necessidades funcionais.

O projeto conceitual gera o esquema conceitual. No projeto conceitual não se leva em conta o SGBD que será utilizado.

O propósito do projeto conceitual é descrever o conteúdo de informação do banco de dados ao invés das estruturas de armazenamento.

3. Projeto lógico

Tem por objetivo avaliar o esquema conceitual frente às necessidades de uso do banco de dados pelos usuários e aplicações, realizando possíveis refinamentos com a finalidade de melhorar o desempenho das operações.

Um esquema lógico é uma descrição da estrutura do banco de dados que pode ser processada por um SGBD.

Depende do modelo de dados adotado pelo SGBD, mas não especificamente do SGBD.

Neste mapeamos o modelo conceitual para o modelo de implementação (físico).

O projeto lógico gera o esquema lógico.

4. Projeto físico

Este toma por base o esquema lógico para gerar o esquema físico e é direcionado para um específico SGBD.

O projeto físico gera o esquema físico.

Fases práticas:

  • Análise de requisitos;
  • Identificação das relações e atributos;
  • Identificar as chaves das relações;
  • Analisar as pendências anteriores e aprofundar a modelagem;
  • Focar nos atributos, seus tipos, domínios e constraints. Substituir multivalorados, repetidos e nulos;
  • Gerar relacionamentos.


Um bom projeto de banco de dados evita:

  • Inconsistência e redundância;
  • Dificuldade de acesso pela falta de planejamento;
  • Isolamento de dados;
  • Problemas de integridade;
  • Problema na falta de atomicidade nas transações;
  • Anomalias no acesso concorrente;
  • Problemas de segurança;
  • Operações entre disco e memória (minimizar).


Para normalizar as informações precisamos colher informações detalhadas sobre a empresa real para a qual iremos modelar o banco de dados.

O que evitar?

  • Informações repetidas;
  • Dificuldade na recuperação de informações.


Repetições

  • Desperdiçam espaço;
  • Dificultam (engessam) atualizações.


Exemplo: Temos um cadastro de clientes assim:

nome, fone, numero, rua, bairro, cidade, uf


Com uma grande quantidade de registros, caso sofra alteração em algum dos campos multivalorados, como uf, teremos que atualizar todos os registros dos clientes.

Caso normalizemos a tabela de clientes e ufs sejam uma tabela separada apenas se relacionando com clientes, ao alterar uma uf apenas atualizaremos um registro na tabela ufs, sem contar que não cadastraremos a uf em cada cliente, mas apenas uma vez na tabela ufs.

Decomposição

Quando decompomos uma relação em várias, devemos ter cuidado para que não haja perda de informações nas dependências.

Fonte: http://www.htmlstaff.org/ver.php?id=21458

LAST_UPDATED2