Objetivo
- Divulgar os pontos mais relevantes do aprendizado adquirido em mais de 30 anos de experiência profissional nesta especialidade da Tecnologia da Informação.
Introdução
A modelagem de dados é a primeira etapa de um projeto que envolva banco de dados e tem como seu principal objetivo o desenvolvimento de um modelo que contenha entidades e relacionamentos, e que com isso seja possível representas as especificações das informações do negócio (OLIVEIRA, 2002).
A modelagem de dados ajuda a organizar a forma de pensamento sobre os dados, demonstrando o significado e a aplicação prática deles. Ela também estabelece o vínculo entre as necessidades dos usuários e a solução de software que as atende. Essa modelagem faz com que se tenha uma redução na complexidade do projeto a um ponto que o projetista possa compreender e manipular os dados (MULLER, 2002).
Para uma modelagem de dados alcançar os objetivos esperados, ela deve fornecer ao desenvolvedor.
* Representar o ambiente;
* Documentar e normalizar;
* Fornecer processos de validação;
* Observar processos de relacionamentos entre objetos.
A modelagem de dados ajuda a organizar a forma de pensamento sobre os dados, demonstrando o significado e a aplicação prática deles. Ela também estabelece o vínculo entre as necessidades dos usuários e a solução de software que as atende. Essa modelagem faz com que se tenha uma redução na complexidade do projeto a um ponto que o projetista possa compreender e manipular os dados (MULLER, 2002).
Para uma modelagem de dados alcançar os objetivos esperados, ela deve fornecer ao desenvolvedor.
* Representar o ambiente;
* Documentar e normalizar;
* Fornecer processos de validação;
* Observar processos de relacionamentos entre objetos.
Tipos de Modelos
Modelo Conceitual
Há também quem o denomine de Modelo de Entidades e Relacionamentos.
É usado para representar em alto nível as entidades e seus relacionamentos em um nível macro, considerando-se exclusivamente o ponto de vista do usuário gestor dos dados.
O exemplo abaixo exibe um modelo conceitual relativo a uma atividade comercial simples realizada por vendedor:
Neste momento inicial do levantamento, o mais importante é captar quais dados dizem respeito ao ambiente cotidiano dos usuários finais. O foco deve ficar restrito somente às entidades e os relacionamentos do escopo a ser modelado, guiando os usuários finais a se restringirem à sua área específica de negócio, pois a experiência mostra que o usuário pode "animar-se" e tender a mencionar entidades não pertencentes ao conjunto de informações a ser atendido. É a tal da empolgação de querer "modelar o mundo".
Lembro-me de ter usado esta técnica na área financeira de uma empresa onde trabalhei. Tomou-me alguns dias para chegar ao MER, pois, primeiro, tive que familiarizar o setor com esta convenção gráfica e suas regras. Foram escolhidos uns cinco funcionários para as sessões. Entretanto, o diretor da área quis participar das sessões... Não entendi porque. Depois descobri... Ele ficava lá atrás da sala de reunião. Cochilava o tempo inteiro.
Finalmente, há alguns modeladores que já identificam os principais atributos na confecção do MER. Particularmente, prefiro deixar esta etapa para o Modelo Lógico, contudo, não vejo qualquer problema nesta abordagem.
Há também uma abordagem para a elaboração do MER que se baseia em textos, elencando as regras de negócio em frases lógicas, relacionando-as às informações a elas pertinentes.
O site da Universidade Federal de Campo Grande exibe uma documentação interessante com boas dicas sobre este assunto. Vale a pena conhecê-lo. Disponível em http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/anal1/anal1.htm
Modelo Lógico
Uma vez que o MER esteja aprovado e o escopo definido, é o momento de "explodi-lo" para um modelo lógico,
O modelo de dados lógico espelha a lógica das informações inerentes à área de negócios, ainda não representa um banco de dados e independe do modelo físico. Podemos então considerar este como a conceito básico da modelagem lógica de dados, tornando-a independente da tecnologia física a ser utilizada.
A criação e manutenção de um modelo lógico justifica-se pela necessidade de satisfazer as condições listadas a seguir:
Marceliz Mayer publica um artigo onde aprofunda este conceito em
http://www.devmedia.com.br/por-que-construir-um-modelo-de-dados-logico-parte-i/368
Um exemplo gráfico de modelo lógico segue abaixo, que é a explosão do MER exibido na seção anterior:
Observe que o modelo acima obedece a uma série de regras inerentes a um modelo lógico. Por exemplo, nomes sempre no singular, eliminação de preposições, utilização de identificadores sequenciais "burros" como chave primária, introdução de chaves de negócio (Alternate Keys), etc, Tais detalhes serão mais bem explorados no capítulo "Documentação do Modelo".
Leia mais em http://www.diegomacedo.com.br/modelagem-conceitual-logica-e-fisica-de-dados/, de Diego Macêdo - Analista de T.I.
Modelo Físico
Onde é trabalhada a implementação do modelo lógico em seu nível mais baixo, projetando o modo como os dados são gravados nos meios de armazenamento, sendo definidos tanto os parâmetros de armazenamento físico como dos métodos de acesso aos dados nesse dispositivo. Os projetistas precisam de um conhecimento detalhado do hardware e do software utilizado para implementar o projeto de BD.
Assim como no lógico, os nomes dos elementos seguem regras que serão detalhadas mais adiante.
Há também quem o denomine de Modelo de Entidades e Relacionamentos.
É usado para representar em alto nível as entidades e seus relacionamentos em um nível macro, considerando-se exclusivamente o ponto de vista do usuário gestor dos dados.
O exemplo abaixo exibe um modelo conceitual relativo a uma atividade comercial simples realizada por vendedor:
Neste momento inicial do levantamento, o mais importante é captar quais dados dizem respeito ao ambiente cotidiano dos usuários finais. O foco deve ficar restrito somente às entidades e os relacionamentos do escopo a ser modelado, guiando os usuários finais a se restringirem à sua área específica de negócio, pois a experiência mostra que o usuário pode "animar-se" e tender a mencionar entidades não pertencentes ao conjunto de informações a ser atendido. É a tal da empolgação de querer "modelar o mundo".
Lembro-me de ter usado esta técnica na área financeira de uma empresa onde trabalhei. Tomou-me alguns dias para chegar ao MER, pois, primeiro, tive que familiarizar o setor com esta convenção gráfica e suas regras. Foram escolhidos uns cinco funcionários para as sessões. Entretanto, o diretor da área quis participar das sessões... Não entendi porque. Depois descobri... Ele ficava lá atrás da sala de reunião. Cochilava o tempo inteiro.
Finalmente, há alguns modeladores que já identificam os principais atributos na confecção do MER. Particularmente, prefiro deixar esta etapa para o Modelo Lógico, contudo, não vejo qualquer problema nesta abordagem.
Há também uma abordagem para a elaboração do MER que se baseia em textos, elencando as regras de negócio em frases lógicas, relacionando-as às informações a elas pertinentes.
O site da Universidade Federal de Campo Grande exibe uma documentação interessante com boas dicas sobre este assunto. Vale a pena conhecê-lo. Disponível em http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/anal1/anal1.htm
Modelo Lógico
Uma vez que o MER esteja aprovado e o escopo definido, é o momento de "explodi-lo" para um modelo lógico,
O modelo de dados lógico espelha a lógica das informações inerentes à área de negócios, ainda não representa um banco de dados e independe do modelo físico. Podemos então considerar este como a conceito básico da modelagem lógica de dados, tornando-a independente da tecnologia física a ser utilizada.
A criação e manutenção de um modelo lógico justifica-se pela necessidade de satisfazer as condições listadas a seguir:
- Ser derivado do modelo conceitual, visando a representação mais detalhada dos dados do negócio;
- Possuir entidades associativas em lugar de relacionamentos n:m (possíveis em um MER);
- Definir as chaves primárias das entidades;
- Normalizar até a 3a. forma normal;
- Adequar-se ao padrão de nomenclatura;
- Ter entidades e atributos documentados.
Marceliz Mayer publica um artigo onde aprofunda este conceito em
http://www.devmedia.com.br/por-que-construir-um-modelo-de-dados-logico-parte-i/368
Um exemplo gráfico de modelo lógico segue abaixo, que é a explosão do MER exibido na seção anterior:
Observe que o modelo acima obedece a uma série de regras inerentes a um modelo lógico. Por exemplo, nomes sempre no singular, eliminação de preposições, utilização de identificadores sequenciais "burros" como chave primária, introdução de chaves de negócio (Alternate Keys), etc, Tais detalhes serão mais bem explorados no capítulo "Documentação do Modelo".
Leia mais em http://www.diegomacedo.com.br/modelagem-conceitual-logica-e-fisica-de-dados/, de Diego Macêdo - Analista de T.I.
Onde é trabalhada a implementação do modelo lógico em seu nível mais baixo, projetando o modo como os dados são gravados nos meios de armazenamento, sendo definidos tanto os parâmetros de armazenamento físico como dos métodos de acesso aos dados nesse dispositivo. Os projetistas precisam de um conhecimento detalhado do hardware e do software utilizado para implementar o projeto de BD.
Segue o modelo físico de dados do nosso estudo de caso, derivado do lógico:
Assim como no lógico, os nomes dos elementos seguem regras que serão detalhadas mais adiante.
Modelagem Transacional e Informacional
O modelo de dados transacional é o projetado para atender a sistemas transacionais, ou seja, os que focam nos dados provenientes de interações de um sistema informatizado com suas fontes de dados. Por exemplo, quando se finalizam as compras no supermercado. Ao receber a fatura, recebe-se a lista como nomes dos produtos e seus preços, o total, etc. Esta fatura diz respeito somente àquela compra. Não há histórico de suas outras compras. A modelagem transacional prima por armazenar e recuperar os dados, normalmente poucos, referentes a numerosas transações. A normalização dos atributos é uma preocupação neste tipo de modelo. É útil no processamento de informações e análises imediatas, não atendendo plenamente à necessidade de informações quanto ao gerenciamento e tomada de decisão. Tal processo também é conhecido como OLTP (Online Transaction Processing). Os modelos exibidos anteriormente exemplificam tal abordagem.
Já a modelagem informacional, também chamada de dimensional, visa a um objetivo oposto ao da transacional, ou seja, atende à necessidade de tomada de decisão baseada em grandes volumes de dados coletados das bases de dados transacionais. O histórico é essencial. Com isso, o banco de dados informacional, ou data warehouse, armazena uma imensa quantidade de dados. Este processo é conhecido como OLAP (Online Analytical Processing). Os tipos de modelo mais usuais são o "Star Schema" e o "Snowflake". O Star Schema (modelo estrela) é o modelo de dados padrão para uma modelagem de dados dimensional onde temos tabela(s) fato(s) ligada(s) a diversas dimensões. Cada dimensão se liga com a(s) fato(s) e dessa maneira forma-se o desenho de uma estrela. Ainda visando à performance, geralmente há redundância e desnormalização de atributos, uma vez que a carga de seus dados é cuidadosamente planejada, com o devido tratamento daquilo que seriam imperfeições em um ambiente transacional.
Abaixo, um modelo informacional em alto nível derivado do transacional exibido nas seções anteriores.
Observe a dimensão "Tempo". Ela não existe no modelo transacional.
É habitualmente complexa, possuindo o máximo de informações relativas ao tempo, tais como
- Dia, semana, quinzena, mês, bimestre, trimestre, quadrimestre, semestre e ano;
- Dia acumulado na semana, na quinzena, no mês e no ano;
- Período fiscal e semana de cinco dias;
- Feriados e finais de semana
Quanto a granularidade, qual a ideal?
Bem... Depende do projeto, é necessário ter sensibilidade.
Mas, quando bem projetada, o projeto consumirá a granularidade necessária, ignorando as mais detalhadas.
A carga da dimensão tempo é feita uma só vez, através de algum programa gerador em um período anterior e outro futuro. Por exemplo, os últimos 10 anos e os próximos 15 anos.
Existe neste artigo um exemplo de dimensão tempo, abordada no tópico de Internacionalização.
Há uma publicação bem detalhada e muito interessante de Asterio K. Tanaka, da Unirio, em
Finalmente, falando sobre dimensões, existe uma que tem uma tipificação especial, chamada Dimensão Degenerada (Degenerate Dimension), que é uma dimensão derivada de uma tabela de fato. Não temos um exemplo nos modelos exibidos acima, mas há bom material na Internet explicando e exemplificando-as.
Padrões de Nomenclatura
Observando atentamente, os modelos lógico e físico acima seguem convenções para os nomes de seus elementos. Vamos listá-las agora.
Definição de Entidades/Tabelas
Nome físico:
O código que identifica fisicamente a tabela e deve ser registrado em letras maiúsculas, obedecendo ao formato TCCNDDDD, onde:
T - Fixo (constante). O prefixo “T” representa que o objeto é uma tabela.
CCN – Onde CC é o código da aplicação ou ou grupo de aplicações. No nosso exemplo, reservamos o AA para a modelo destinado a vendas. Se tivéssemos tabelas para outra área de atuação da empresa, escolheríamos o AB, por exemplo. Isto impede a criação de tabelas com o mesmo nome dentro da Organização. N - Número sequencial dentro do código CC, variando de 1 a 0 e, depois, de A a Z.
DDDD – Livre.
Exemplo: TAA2ITNF
T - Fixo (constante). O prefixo “T” representa que o objeto é uma tabela.
CCN – Onde CC é o código da aplicação ou ou grupo de aplicações. No nosso exemplo, reservamos o AA para a modelo destinado a vendas. Se tivéssemos tabelas para outra área de atuação da empresa, escolheríamos o AB, por exemplo. Isto impede a criação de tabelas com o mesmo nome dentro da Organização. N - Número sequencial dentro do código CC, variando de 1 a 0 e, depois, de A a Z.
DDDD – Livre.
Exemplo: TAA2ITNF
Nome conceitual:
Nome deve estar no singular, sendo a primeira letra de cada palavra em maiúsculo;
Podem ser usados nomes conhecidos do usuário;
Podem ser usadas siglas, desde que sejam conhecidas no negócio;
A descrição detalhada deve conter exemplos, se possível;
O número designando a quantidade máxima de ocorrências deve ser informado, assim como a ordem dos campos na chave primária e as regras de integridade a serem implementadas.
Exemplo: Item Nota Fiscal
Exemplo: Item Nota Fiscal
Definição de Atributos/Campos
Nome físico:
O código que identifica fisicamente o atributo (coluna) deve ser registrado em letras maiúsculas, obedecendo ao formato CCNDDDDD, onde:
CCN – Três primeiros caracteres do código da tabela
DDDDD – Livre.
Exemplo: AA2IDITN
Exemplo: AA2IDITN
Nome conceitual:
Primeiras letras de cada palavra em maiúsculo;
A primeira palavra deve ser uma natureza válida, por exemplo, Código, Numero, Valor, etc. É uma boa prática confeccionar uma lista com todas as naturezas válidas para nomes lógicos, bem como seu mnemônico correspondente para o nome físico do campo;
Não usar preposições, artigos, conectivos, etc.
A descrição detalhada deve conter exemplos, se possível;
As seguintes propriedades devem ser definidas:
- mandatório ou opcional
- tipo (caracter, numérico, data, etc.)
- tamanho
- quantidade de casas decimais, quando for o caso
- se o atributo possuir domínio, os valores válidos devem ser definidos e descritos.
Exemplo: Identificador Sequencial Item Nota Fiscal
Exemplo: Identificador Sequencial Item Nota Fiscal
Definição de relacionamentos
- O código do relacionamento deve estar em letras maiúsculas e obedecer ao formato RXXXYYYS, onde:
R - Fixo (constante). O prefixo "R" indica que o objeto é um relacionamento.
XXX - Três primeiras letras do código físico da entidade pai
YYY - Três primeiras letras do código físico da entidade filha
S - Caracter do alfabeto que indica a sequência do relacionamento entre as entidades (variando de A a Z);
Exemplo:
RAA1AA2A - Relacionamento entre a TAA1NOTF (Nota Fiscal) e TAA2ITNF (Item Nota Fiscal). Como houve necessidade de outro relacionamento entre as mesmas entidades, o código do relacionamento foi RAA1AA2B, se existisse um terceiro, seria RAA1AA2C, e assim por diante;
Padrão de nome para os papéis do relacionamento:
Evitar verbos vagos genéricos para descrever os relacionamentos como: se relaciona/está relacionado a, se associa/está associado a, tem, está , contém/está contido;
Usar verbos que descrevam adequadamente o papel do relacionamento (de preferência verbos que sejam jargão do usuário);
Colocar nomes nos dois sentidos do relacionamento, do ponto de vista de cada entidade;
Deve ser informada a regra de integridade referencial (restrict, cascade, set null) a ser definida para cada relacionamento, especificando se a mesma será implementada via banco (constraint) ou via processo.
A cardinalidade e opcionalidade do relacionamento também devem ser especificadas.
Documentação do Modelo
O modelo de dados também deve ter um mínimo de documentação que explique seus pontos principais:
- Data de criação
- Autor
- Objetivo
- Área(s) atendida(s) da corporação
- Quando for uma alteração evolutiva, deveria informar autor da última alteração, bem como uma rápida descrição (estes dados são históricos)
Normalmente, a ferramenta de modelagem possui um campo descritivo no nível do modelo, que deve ser utilizado.
- Data de criação
- Autor
- Objetivo
- Área(s) atendida(s) da corporação
- Quando for uma alteração evolutiva, deveria informar autor da última alteração, bem como uma rápida descrição (estes dados são históricos)
Normalmente, a ferramenta de modelagem possui um campo descritivo no nível do modelo, que deve ser utilizado.
Modelos Internacionalizados - Múltiplos Idiomas
Algumas corporações multinacionais precisam implementar as colunas descritivas de um modelo em mais de um idioma. Quando isto ocorrer, o que fazer? Uma solução mais elaborada seria seguir os seguintes passos:
- Criar uma dimensão de idiomas, independente, populando-a com as línguas necessárias, tendo como chave de negócio o código ISO de idiomas. Atente-se que há um código ISO (639) de duas posições e outro de três posições (639-1) para cada idioma.
- Criar uma dimensão associativa entre a dimensão proprietária das descrições e a de idiomas, criada no passo anterior;
- Mover para a dimensão associativa todos as colunas descritivas que demandem múltiplos idiomas.
Em uma abordagem mais simples, não é necessário criar a tabela de idiomas, bastando criar uma dimensão filha com as traduções, que terá o código do idioma como parte de sua chave primária, conforme exemplo abaixo.
- Criar uma dimensão de idiomas, independente, populando-a com as línguas necessárias, tendo como chave de negócio o código ISO de idiomas. Atente-se que há um código ISO (639) de duas posições e outro de três posições (639-1) para cada idioma.
- Criar uma dimensão associativa entre a dimensão proprietária das descrições e a de idiomas, criada no passo anterior;
- Mover para a dimensão associativa todos as colunas descritivas que demandem múltiplos idiomas.
Em uma abordagem mais simples, não é necessário criar a tabela de idiomas, bastando criar uma dimensão filha com as traduções, que terá o código do idioma como parte de sua chave primária, conforme exemplo abaixo.
Dados Geográficos
Determinadas corporações podem precisar de informações geográficas em maior ou menor nível de precisão. Este nível de precisão deve ser identificado e inserido no modelo de acordo com as respostas para as seguintes perguntas:
- Qual o nível administrativo interessa: Apenas país? País e unidade da federação? Ambos e município?
- Que dados de cada nível administrativo?
- Precisa internacionalizar nomes e descrições?
- Qual a fonte de dados?
Na situação que vivenciei bastou ir até município.
Quanto à fonte de dados, sugiro o site http://www.geonames.org/
A área de download está em http://download.geonames.org/export/dump/. Há vários arquivos, mas o mais completo é o allCountries.zip. Há documentação de layout para todos os arquivos, que são gratuitos. Contudo, caso seja necessária uma precisão maior nas informações no que diz respeito à qualidade de dados, é possível se registrar como usurário "Premium" (serviço pago) e ganhar acesso à área de download específica.
Algumas Ferramentas do Mercado
Pessoalmente, trabalhei com as seguintes:
http://erwin.com/
http://powerdesigner.de/en/
https://www.idera.com/er-studio-data-architect-software (Embarcadero E/R Studio)
Todas são pagas, mas permitem trabalhar por alguns dias como demonstração.
Ainda há outras. Vale a pena avaliar a comparação na Wikipedia
https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Finalmente, sobre modelagem de dados na Wikipedia, indico também
https://en.wikipedia.org/wiki/Data_modeling
Espero que este artigo tenha lhe sido útil. Abraço e boa sorte!
Gilberto Rodrigues dos Santos
Contatos
Email: giba.rodrigues@gmail.com
Fone (21) 98211 0505
Linkedin: br.linkedin.com/in/gilbertorodriguesadmdados
http://erwin.com/
http://powerdesigner.de/en/
https://www.idera.com/er-studio-data-architect-software (Embarcadero E/R Studio)
Todas são pagas, mas permitem trabalhar por alguns dias como demonstração.
Ainda há outras. Vale a pena avaliar a comparação na Wikipedia
https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Finalmente, sobre modelagem de dados na Wikipedia, indico também
https://en.wikipedia.org/wiki/Data_modeling
Espero que este artigo tenha lhe sido útil. Abraço e boa sorte!
Gilberto Rodrigues dos Santos
Contatos
Email: giba.rodrigues@gmail.com
Fone (21) 98211 0505
Linkedin: br.linkedin.com/in/gilbertorodriguesadmdados
