Saltar para o conteúdo

Modelagem de dados

Origem: Wikipédia, a enciclopédia livre.

Modelar significa criar um modelo que explique as características de funcionamento e comportamento de um software a partir do qual ele será criado, facilitando seu entendimento e seu projeto, através das características principais que evitarão erros de programação, projeto e funcionamento. É uma parte importante do desenho de um sistema de informação.

Os modelos de dados são ferramentas que permitem demonstrar como serão construídas as estruturas de dados que darão suporte aos processos de negócio, como esses dados estarão organizados e quais os relacionamentos que pretendemos estabelecer entre eles.[1]

A abordagem que se dispensa ao assunto normalmente atende a três perspectivas:

  • Modelagem Conceitual: é usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador dos dados;
  • Modelagem Lógica: agrega mais alguns detalhes de implementação.
  • Modelagem Física: demonstra como os dados são fisicamente armazenados.

Quanto ao objetivo, podemos identificar as seguintes variações:

  • modelagem de dados entidade-relacionamento (leitura, construção e validação dos modelos);
  • modelagem de relacionamentos complexos, grupos de dados lógicos e ciclo de vida das entidades;
  • modelagem de dados corporativa;
  • modelagem de dados distribuídos (cliente/servidor);
  • modelagem e reengenharia de dados legados e
  • modelagem de dados para Data Warehouse.
  • O banco de dados é utilizado para guardar informações.
  • O banco de dados é feito para ajudar as pessoas

De acordo com a abordagem que utilizam, os modelos de dados normalmente são classificados da seguinte forma:

  • Modelo Conceitual: O modelo conceitual é um diagrama em blocos que demonstra todas as relações entre as entidades, suas especializações, seus atributos e auto-relações.
  • Modelo Lógico: O modelo lógico mostra as ligações entre as tabelas de banco de dados, as chaves primárias, os componentes de cada uma, etc.
  • Modelo Físico: Inclui a análise das características e recursos necessários para armazenamento e manipulação das estruturas de dados (estrutura de armazenamento, endereçamento, acesso e alocação física), sendo uma sequência de comandos executados em SQL a fim de criar as tabelas, estruturas e ligações projetadas até então e finalmente criar o banco de dados.
Exemplo de Modelo Físico (SQL ANSI 2003)
CREATE TABLE Produtos (
       COD_PROD Texto(1) PRIMARY KEY,
       MODELO Texto(1),
       DESCRICAO Texto(1),
       COR Texto(1),
       CATEGORIA Texto(1),
       QUANT_PROD Texto(1),
)

Modelo Lógico de Dados

[editar | editar código-fonte]

Um modelo lógico de dados para uso meramente operacional/transacional deve:

  • Ser completamente normalizado;
  • Representar fielmente o NEGÓCIO, e NÃO necessariamente a base de dados desejada, a qual será construída posteriormente por ocasião do Projeto Físico;
  • Conter descrição sucinta das entidades, atributos e relacionamentos;
  • Conter os nomes de entidades e atributos, extensos e abreviados, atribuídos de acordo com algum padrão adotado na organização e formados por termos previamente convencionados em um glossário;
  • Contemplar, para cada um dos atributos, o tipo de dado, tamanho e opcionalidade.

Identificação de Objetos

[editar | editar código-fonte]
  • Coisas Tangíveis: elementos que têm existência concreta, que ocupam lugar no espaço.
Ex: Meio de Transporte (avião, carro, barco, navios, etc);
  • Funções: percepção dos objetos através da função por eles exercida (papel, atribuição, classificação, capacitação, etc).
Ex: Organização (órgãos funcionais - venda, suporte, despacho de mercadorias, etc), especialistas (médicos, engenheiros, etc), cliente (pessoa atendida), atendente (pessoa que atende), etc;
  • Eventos ou Ocorrências: alguns objetos só conseguem ser individualizados ou percebidos enquanto uma certa ação se desenrola (identifica-se características que tornam determinado fato materializável).
Ex: vôo comercial, acidente de trânsito, jogo de futebol, etc.
  • Interações: resultantes das associações entre objetos em função de um processo executado - cada objeto participante da interação preserva suas características não sendo impactados pela materialização da interação.
Ex: compra de um imóvel, adoção de uma criança, venda de um produto;
  • Especificações: são elementos que definem características de outros objetos.
Ex: modelos de carro (cor, dimensões, etc), espécies animais (mamíferos, carnívoros, etc.)

Uma definição deve:

  • ser única e especial (dentro de qualquer dicionário no qual ela aparece);
  • ser estabelecida no singular;
  • estabelecer o que o conceito é (não o que ele não é), o que faz, quando algum elemento passa a ser, ou deixa de ser, pertencente a esse grupo;
  • ser estabelecida como uma frase ou sentença descritiva;
  • ser expressa sem definições embutidas de outros termos;
  • estabelecer o significado essencial do conceito;
  • ser precisa e não-ambígua;
  • ser concisa;
  • ser significativa por si só;
  • evitar raciocínio circular.

Quanto ao tipo, podem ser classificados como:

  • Descritivos: representam as características intrínsecas dos objetos;
  • Nominativos: além de cumprirem a função de descritivos servem como definidores de nomes ou rótulos de identificação dos objetos (nome, código, número, sigla, etc);
  • Referenciais: representam uma citação ou ligação do objeto em questão com outro objeto, não propriamente definindo uma característica do objeto mas explicitando um relacionamento existente.[2]
Ex: Cidade de nascimento, Nome do fabricante do carro, Local de trabalho, etc.

Relacionamentos

[editar | editar código-fonte]

Na descrição de um relacionamento devem aparecer:

  • Sua função;
  • O que ele representa;
  • Quais as regras de seu estabelecimento;
  • Quais as exceções a seu estabelecimento;
  • Quando ocorre;
  • Quando pode deixar de existir.

Recomendações

[editar | editar código-fonte]

Um Modelo Lógico de Dados para uso meramente operacional/transacional não deve conter:

  • Replicações de atributos: fisicamente pode ser interessante alguma redundância com o objetivo de melhorar a performance de determinado(s) processo(s). No modelo lógico isso não pode ser feito; um atributo só é representado na Entidade que o pertence.
  • Atributos derivados: pelos mesmos motivos apontados anteriormente, a implementação das tabelas pode requerer o armazenamento de uma informação derivada de outra(s) (valor do saldo por exemplo). Tal tipo de informação não se constitui um atributo do modelo lógico.
  • Atributos repetitivos: o uso de atributos repetidos, como Telefone-1 e Telefone-2, não é admitido. Se existe a possibilidade de uma pessoa possuir mais de um telefone, então Telefone deve ser representado como uma entidade, mantendo relacionamento Nx1 com a entidade Pessoa.

Referências

  1. Carlos Alberto Debastiani (2015). Definindo Escopo em Projetos de Software. São Paulo: Novatec. ISBN 978-85-7522-429-8 
  2. Durante a normalização estes são deslocados para o objeto a que pertencem e é feito então um relacionamento entre eles