Enquete

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

Notícias

On-line

Nós temos 3 visitantes online

Links


Perguntas mais frequentes
Perguntas mais frequentes encontradas no site da ANS.
TISS da ANS
Site do Tiss da ANS.
Google
Sem comentários :).
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