ETAPAS DE UM PROJETO DE BANCO DE DADOS (RESUMO DA APOSTILA

E VIDEOAULA)

1. INTRODUÇÃO À MODELAGEM DE DADOS

 Modelagem de dados é um passo essencial no processo de criação de qualquer software complexo.

 No centro da modelagem de banco de dados está a ideia de projetar uma estrutura de banco de dados que
define como as informações armazenadas podem ser acessadas, categorizadas e manipuladas e, qual
história essa informação dirá.

 As técnicas e ferramentas de modelagem de dados capturam e traduzem projetos de sistemas em

representações de fácil compreensão dos fluxos e processos de dados.

 Se a ferramenta de software que é usada para os dados é o cérebro, a modelagem de dados são os neurônios
que se conectam uns aos outros.

 As escolhas de modelagem de dados precisarão ser feitas no início de qualquer implantação de software.

Objetivos da modelagem de dados:

 Identificar diferentes componentes de dados (considerar dados brutos e processados, e entidades).

 Identificar as relações entre diferentes componentes de dados (estes são chamados associações).

 Identificar os usos antecipados dos dados (requisitos), com o reconhecimento de que os dados
podem ser mais valiosos no futuro para usos não previstos.

 Identificar pontos fortes e restrições da tecnologia (hardware e software) que planeja-se usar
durante o projeto.

 Construir um modelo preliminar das entidades e suas relações, tentando manter o modelo
independente de quaisquer usos específicos ou restrições de tecnologia.

 Um modelo é a representação abstrata e simplificada de um sistema real. Na modelagem de dados, utilizamos

modelos para representar dados em um sistema, como são gerados, se relacionam e se transformam. O caminho
do dado até sua transformação em informação.
 Diferença entre dados, informação e conhecimento:

a) Dados:
 São registros soltos, aleatórios, sem quaisquer análise.

 Dados são códigos que constituem a matéria prima da informação, ou seja, é a informação não tratada que ainda
não apresenta relevância.

 Eles representam um ou mais significados de um sistema que isoladamente não pode transmitir uma mensagem
ou representar algum conhecimento.

b) Informação:
 A informação seria qualquer estruturação ou organização desses dados.

 Ela é um registro, em suporte físico ou intangível, disponível à assimilação crítica para produção de
conhecimento.

 Informação é, portanto, o material de que é feito o conhecimento, após posicionamento crítico do indivíduo. Além
disso, a informação é derivada dos dados que, sem um sentido ou contexto, significam muito pouco.

 Informação não é Conhecimento, informação é diferente de Conhecimento. A informação (matéria-prima

para o conhecimento) é um bem comum ao qual todo cidadão deve ter direito/acesso, levando à socialização da
informação, das oportunidades e do poder.

c) Conhecimento:
 Conhecimento é a informação processada e transformada em experiência pelo indivíduo.

 O conhecimento é a capacidade que, o processamento da informação adicionado ao repertório individual, nos

dá, de agir e prever o resultado dessa ação.

 Para construir modelos de dados, utilizamos os modelos em formatos textuais ou gráficos. Dessa forma, o
mesmo modelo pode ser apresentado de formas diferentes.

 Um modelo de dados, pode ser pensado como um fluxograma que ilustra as relações entre os dados. Modelos de
dados bem documentados permitem que os interessados identifiquem erros e façam alterações antes de
qualquer código de programação ter sido escrito.

 O analista responsável pela modelagem de dados deve ser capaz de observar o mundo real e em seguida
materializar o objeto observado em um modelo de dados.

 O modelo de dados orienta e define como os dados se comportarão em um sistema. Além disso, serve como um
marco importante dentro do ciclo de evolução do processo de modelagem, pois por meio desse artefato, os atores
envolvidos no processo podem validar o que está sendo projetado. É nesse momento em que o analista
responsável pelo planejamento do banco de dados valida junto ao seu cliente o que ele observou e se o que foi
observado condiz com a realidade.
 Exemplo:
 Imagine que temos a tarefa de planejar um modelo de banco de dados para um cliente que possui uma loja de
Petshop.

 Em nossa primeira entrevista com o cliente, temos que investigar e analisar como o negócio de nosso cliente
funciona em nível estrutural, ou seja, quais são os departamentos, suas relações e funções.

 Cliente → Minha loja possui dois setores. Um setor é a loja, onde vendo diversos produtos para animais. No outro
setor, eu ofereço os serviços veterinários, banho e tosa.

 A partir dessa primeira conversa, criamos nosso primeiro modelo:

2. LEVANTAMENTO DE REQUISITOS E REGRAS DE NEGÓCIOS

2.1. LEVANTAMENTO DE REQUISITOS

 Requisitos de sistemas são os artefatos que determinam o que o sistema deve fazer. O objetivo do levantamento
de requisitos é identificar a situação do mundo real em detalhes suficientes para ser capaz de definir
componentes de banco de dados, coletando principalmente dois tipos de dados: dados naturais (entrada para o
banco de dados) e processamento de dados (saída do banco de dados).

Nessa etapa, o analista responsável deve buscar basicamente o seguinte:

 Delinear os requisitos de dados da empresa em termos de elementos de dados básicos;

 Descrever as informações sobre os elementos de dados e as relações entre eles necessários para modelar esses
requisitos de dados;

 Determinar os tipos de transações que se pretende executar no banco de dados e a interação entre as
transações e os elementos de dados;

 Definir quaisquer restrições de desempenho, integridade, segurança ou administrativas que devem ser impostas
ao banco de dados resultante;

 Especificar quaisquer restrições de projeto e de implementação, como tecnologias específicas, hardware e

software, linguagens de programação, políticas, padrões ou interfaces externas.
Essas informações podem ser reunidas de várias maneiras:

 Revisão de documentos existentes → tais documentos incluem formulários e relatórios existentes, diretrizes
escritas, descrições de cargos, narrativas pessoais e memorandos. A documentação em papel é uma boa
maneira de se familiarizar com a organização ou atividade que você precisa para modelar.

 Entrevistas com usuários finais → podem ser uma combinação de reuniões individuais ou em grupo. Tente
manter as sessões com grupos de até seis pessoas. Se possível, com pessoas que tenham/pertençam à mesma
função ou cargo em uma reunião

 Revisão de sistemas automatizados existentes → se a organização já possui um sistema automatizado, revise

as especificações de projeto do sistema e a documentação.

 A análise e o levantamento de requisitos geralmente é feita ao mesmo tempo que a modelagem de dados. À
medida que as informações são coletadas, os objetos de dados são identificados e classificados como entidades,
atributos ou relacionamentos. Os objetos são então modelados e analisados usando diagramas. Esses
diagramas podem ser revistos pelo analista e pelos usuários finais para determinar sua precisão. Se o modelo
não estiver correto, ele é modificado, o que às vezes requer informações adicionais a serem coletadas. O ciclo de
revisão e edição continua até que o modelo seja certificado como correto.

3 pontos na dinâmica do levantamento e análise de requisitos:

 Converse com os usuários finais sobre seus dados em termos de “mundo real”. Os usuários não pensam em
termos de entidades, atributos e relacionamentos, mas sobre as pessoas, coisas e atividades reais que lidam
diariamente.

 Aproveite o tempo para aprender o básico sobre a organização e as atividades que você deseja modelar. Ter um
entendimento sobre os processos tornará mais fácil a construção do modelo.

 Os usuários finais normalmente pensam e visualizam dados de diferentes maneiras de acordo com sua função ou
cargo dentro de uma organização. Portanto, é importante entrevistar o maior número de pessoas que o tempo
permite. É válido ressaltar que o levantamento de requisitos aborda somente a identificação dos objetos
(entidades, atributos ou relacionamentos), o que o sistema deve fazer. Como e quando os dados serão
armazenados está a sob a responsabilidade da identificação das regras de negócios.

2.2. REGRAS DE NEGÓCIOS

 Uma regra de negócios é independente do paradigma de modelagem, software ou hardware. Sendo uma
declaração que define ou restringe alguns aspectos do negócio.

 As regras de negócios permitem que o analista desenvolva regras e restrições de entidades e relacionamentos e
crie um modelo de dados condizente com o “mundo real”.
  Regras de negócios também permitem aos analistas entender os processos de negócios, bem como a natureza,
o papel e o escopo dos dados. Elas são uma ferramenta de comunicação entre usuários e criadores, e também
ajudam a padronizar a visão da empresa sobre os dados.

 Regras de Negócios dão a classificação adequada de entidades, atributos, relações e restrições. Fontes de
regras de negócios são gerentes, gerentes de departamento, documentação escrita, procedimentos, padrões,
manuais de operação e entrevistas com usuários finais.

Alguns exemplos de regras de negócio:

 Todo cliente deve estar cadastrado em nosso sistema;

 O CPF e e-mail devem ser campos obrigatórios no cadastro do cliente;
 Toda venda deve gerar um cupom fiscal;
 O campo CPF é obrigatório para a geração do cupom fiscal;
 Uma venda deve ser realizada somente por funcionários do departamento de frente de caixa.

 Regras de negócios faz referência a como o processo é executado e suas restrições;

 Regras de negócios são independentes de sistemas informatizados, elas pertencem ao negócio.

 Se as regras de negócios estiverem erradas, o modelo de dados será incorreto e, em última instância, o sistema
que irá consumir no banco de dados não funcionará como esperado pelos usuários.

3. NÍVEIS DE MODELAGEM

 O processo de modelagem de dados começa com uma visão abstrata do ambiente geral de dados (modelo
conceitual) e ganha detalhes (modelos lógico e Físico) à medida que o projeto se aproxima da implementação
do banco de dados.

3.1. MODELO CONCEITUAL

 Um modelo de dados conceitual identifica as relações de nível mais alto entre as diferentes entidades.

Características do modelo de dados conceitual incluem:

 Entidades importantes e as relações entre elas;
 Nenhum atributo é especificado;
 Nenhuma chave primária é especificada;
 No diagrama acima podemos ver que as únicas informações mostradas através do modelo de dados conceitual
são as entidades que descrevem os dados e as relações entre essas entidades. Nenhuma outra informação é
mostrada.

3.2. MODELO LÓGICO

 Um modelo de dados lógico descreve os dados com o máximo de detalhes possível, independentemente do
modo como será a implementação física no banco de dados.

As características do modelo de dados lógico incluem:

 Todas as entidades e relações entre elas;
 Todos os atributos para cada entidade especificados;
 A chave primária para cada entidade especificada;
 Especificadas as chaves estrangeiras (chaves que
identificam a relação entre diferentes entidades);
 A normalização ocorre neste nível.

As etapas para projetar o modelo de dados lógico

são as seguintes:
 Especifique chaves primárias para todas as
entidades;
 Encontre as relações entre entidades diferentes;
 Encontre todos os atributos para cada entidade;
 Resolva relacionamentos muitos-para-muitos;
 Normalização.

Comparação entre o modelo de dados lógico e o diagrama do modelo conceitual

 Em um modelo de dados lógico, chaves primárias estão presentes, enquanto que em um modelo de dados
conceitual, nenhuma chave primária está presente;

 Em um modelo de dados lógico, todos os atributos são especificados dentro de uma entidade. Nenhum dos
atributos são especificados em um modelo conceitual de dados;

 As relações entre entidades são especificadas usando chaves primárias e chaves estrangeiras em um modelo de
dados lógico;

 Em um modelo de dados conceitual, os relacionamentos são simplesmente declarados, não especificados,

simplesmente sabemos que duas entidades estão relacionadas, mas não especificamos quais atributos são
usados para essa relação.
3.3. MODELO LÓGICO

 O modelo de dados físico representa como o modelo será construído no banco de dados.

 Um modelo de banco de dados físico mostra todas as estruturas de tabela, incluindo nome da coluna, tipo de
dados da coluna, restrições de coluna, chave primária, chave externa e relações entre tabelas.

Os recursos de um modelo de dados físicos

incluem:
 Especificar todas as tabelas e colunas;
 Chaves estrangeiras são usadas para identificar
relações entre tabelas;
 Considerações físicas podem fazer com que o
modelo de dados físico seja bastante diferente do
modelo de dados lógicos;
 O modelo de dados físico será diferente para
diferentes SGDBs. Por exemplo, o tipo de dados
para uma coluna pode ser diferente entre o
MySQL, ORACLE, FIREBIRD e o SQL Server.

Principais diferenças entre o modelo de dados físicos e modelo de dados lógicos:

 Os nomes das entidades são agora nomes de tabelas.

 Os atributos são agora nomes de colunas.

 O tipo de dados para cada coluna é especificado, podendo ser diferentes dependendo do banco de dados real
sendo usado.