Modelagem de Bancos de Dados sem Segredos

Albert Eije Barreto Mouta

Apr 26 · 11 min read

Introdução

Um banco de dados é uma das coisas mais antigas que se possa imaginar. E não estou me referindo ao que você está vendo na figura a seguir.

Sabemos que, não muito tempo atrás, nós não tínhamos os computadores. Algumas pessoas compravam fiado na bodega e o dono do comércio ia anotando tudo em sua caderneta, a conhecida Caderneta do Fiado.

Nessa caderneta o comerciante colocava o nome do cliente, para identificar o “dono” da caderneta e ia inserindo suas compras, mais ou menos com os seguintes dados: data, item, quantidade e valor.

Até hoje existem comércios que adotam essa prática, que deve ter começado séculos ou milênios atrás. Pois saiba que estamos diante de um banco de dados. Não é, no entanto, um banco de dados digital, pois não está armazenado num dispositivo dessa natureza.

Com o advento dos computadores, começamos a utilizá-los para armazenar dados, os mais diversos tipos de dados. Note que eu não mencionei que começamos a armazenar INFORMAÇÃO, mas sim DADOS. Qual a diferença?

Ainda é comum entre alguns profissionais de TI a dificuldade de distinção entre INFORMAÇÃO e DADO. INFORMAÇÃO acrescenta algo ao conhecimento da realidade a ser analisada. Por exemplo, a dosagem que um paciente precisa receber de um determinado remédio é uma INFORMAÇÃO. Este conhecimento pode ser (ou não) modelado (registrado).

DADO é uma representação, um registro de uma informação. Este DADO pode ser registrado fisicamente através de um papel (receita médica), um disco de computador ou um impulso elétrico. Este registro pode ser o originador de uma série de processos que influenciam na realidade observada. (Salvar a vida de um paciente, tocar um alarme, etc). Temos ainda o conceito de CONHECIMENTO, que é a uma informação valiosa da mente humana. Podemos ver a distinção entre os três na tabela a seguir.

A dificuldade em entender a diferença dos conceitos acima traz, como consequência direta, problemas na especificação e modelagem de um sistema.

Até pouco tempo atrás as definições acima eram suficientes para compreender um problema no mundo real e como resolvê-lo de forma computacional. No entanto, alguns estudiosos da área adicionaram os conceitos de IDEIA (INSIGHT) e SABEDORIA. E como ficaria a comparação desses cinco conceitos? Vamos a um exemplo que é muito utilizado por professores e é facilmente encontrado na Internet para esclarecer esse ponto.

O DADO é como um pingo de chuva. Você está andando na rua e sente um pingo. O pingo por si só não representa muita coisa. Será que está chovendo? Pode ser um ar-condicionado pingando. Você então olha para o céu e percebe que existem nuvens escuras (outro DADO). Além disso, você começa a sentir mais pingos. “Vai chover” você pensa. Essa é a INFORMAÇÃO: vai chover!

O CONHECIMENTO é quando você percebe que vai se molhar, e se você se molhar não vai poder chegar ao seu destino e ainda pode ficar doente. Quando você conseguir prever o que vai acontecer a partir das INFORMAÇÕES que tem, seja pelo histórico dos fatos anteriores ou por novas conclusões, está utilizando o seu CONHECIMENTO.

Você então começa a pensar em soluções para o seu problema. Essas possíveis soluções são as IDEIAS (Insights). Por exemplo: comprar um guarda-chuva, pegar um táxi, esperar a chuva passar em algum lugar seco.

A sabedoria é o que vai fazer com tudo isso. Se você vai continuar andando desesperadamente no meio da chuva e se molhar todo, se vai se preservar numa marquise e deixar a chuva passar ou se vai pegar um táxi.

Muitos autores já escreveram sobre o tema e o meio acadêmico sempre traz alguma novidade, portanto você pode encontrar versões diferentes dos conceitos vistos anteriormente, mas todas acabam convergindo de uma forma ou de outra.

O tratamento das INFORMAÇÕES dá origem a vários tipos de DADOS, porém o DADO deve registrar apenas os aspectos realmente relevantes da INFORMAÇÃO. Por exemplo: para um sistema de controle que mantém a vida dos pacientes em uma UTI, não seria necessário armazenar o endereço do fabricante do remédio.

Portanto, em um sistema informatizado estão contidas todas as INFORMAÇÕES necessárias ao objetivo do mesmo. Os DADOS originados dessas INFORMAÇÕES serão processados pelo sistema criado. Por definição, um computador não processa INFORMAÇÕES, mas sim, DADOS.

O Projeto de um Banco de Dados

É um processo complexo e que geralmente necessita de muitas decisões em níveis diferentes. Esta complexidade é melhor gerenciada quando o problema é subdividido em vários subproblemas independentes. A construção de bases de dados pode ser dividida em três fases bem distintas: modelagem conceitual, projeto lógico e projeto físico.

O fato central nas três fases do projeto de bases de dados é a modelagem do dado e suas propriedades. Existe ainda uma ordem lógica nessas fases. A partir do momento que se levanta os requisitos ou requerimentos do software, pode-se iniciar pela primeira fase até chegar na última.

Documentos do Mundo Real

Os fatos ocorrem a todo instante dentro de uma realidade. Geralmente ficam armazenados em documentos formais tais como: fichas, memorandos, requerimentos, protocolos etc. Às vezes ficam registrados na cabeça das pessoas que direta ou indiretamente influenciam na realidade a ser modelada (o dono da empresa, por exemplo).

O profissional que vai realizar a modelagem dos dados, normalmente um analista, deve se concentrar na observação dos fatos relevantes que ocorrem na realidade durante a modelagem conceitual dos dados, com a finalidade de construir um sistema que possa automatizar as necessidades de informação da mesma. Neste momento os documentos que registram estes fatos só devem ser utilizados como apoio ao entendimento, e não como base para o desenvolvimento do sistema. Não devemos nos preocupar em simular o ambiente atual.

Ao coletar e selecionar os fatos relevantes, o analista deve identificar os elementos geradores de informação, as leis que regem esta realidade, bem como as operações que incidem sobre os elementos básicos (dados).

Analise a Figura 1.7 logo a seguir. Temos um modelo de nota fiscal que é um documento do mundo real. Imagine-se como analista observando esse documento e tentando transformá-lo num modelo para armazenar os dados num computador, ou seja, você está modelando esse documento para desenvolver um banco de dados que vai armazenar os dados das notas fiscais de uma empresa. Se você tentar simular o ambiente atual, você vai criar um modelo que vai armazenar todos os itens dessa nota tal e qual você está vendo. Vamos pegar alguns dos itens dessa nota para tomarmos como exemplo.

Veja que, se você armazenar o Nome de Fantasia e o CNPJ, esses dados vão se repetir cada vez que você inserir um item da venda nessa nota. Simular o ambiente real tal qual ele é não é uma boa ideia. Veremos mais a frente como resolver esse e outros problemas de modelagem.

Elementos de Abstração

“Um banco de dados representa algum aspecto do mundo real, às vezes chamado de minimundo ou de universo de discurso (UoD — Universe of Discourse).” (Elmasri & Navathe, 2011)

O minimundo é uma porção da realidade, captada pelo analista, a qual a função gerencial tem forte interesse em observar. A complexidade de analisar até mesmo um minimundo pode levar o analista a subdividi-lo em partes menores, às quais se dá o nome de visão.

No exemplo anterior, visto na figura 1.7, temos um minimundo que poderíamos chamar de “Venda” onde a Nota Fiscal é um membro desse minimundo. Que outros membros desse minimundo poderíamos identificar? Cliente, vendedor, produto e fornecedor seriam alguns deles.

Sendo assim, podemos definir Banco de Dados como: “uma coleção de fatos registrados que refletem o estado de certos aspectos de interesse do mundo real. A todo o momento o conteúdo do banco de dados representa uma visão instantânea do estado do mundo real. Cada mudança em algum item do banco de dados reflete uma mudança ocorrida na realidade.” (Machado & Abreu, 1996).

Modelo Conceitual

Vimos anteriormente que a construção de bases de dados pode ser dividida em três fases bem distintas: Modelagem Conceitual, Projeto Lógico (ou Modelo Lógico) e Projeto Físico (ou Modelo Físico).

O Modelo Conceitual representa e/ou descreve a realidade do ambiente do problema. É a primeira etapa do projeto de um sistema de aplicação em bancos de dados.

O objetivo deste modelo é descrever as informações contidas em uma realidade, as quais estarão armazenadas em um banco de dados. É uma descrição em alto nível, mas que tem a preocupação de captar e retratar toda a realidade de uma organização, setor, repartição, departamento etc.

Modelo Lógico

Tem seu início a partir do Modelo Conceitual, levando em consideração uma das três abordagens possíveis: Relacional, Hierárquica e Rede.

O Modelo Lógico descreve as estruturas que estarão contidas no banco de dados, de acordo com as possibilidades permitidas pela abordagem, mas sem se preocupar ainda com qual SGBD (Sistema Gerenciador de Banco de Dados) será usado.

Modelo Físico

Irá partir do Modelo Lógico e descreve as estruturas físicas de armazenamento de dados, tais como: tamanho de campos, índices, tipo de preenchimento desses campos etc. Este modelo detalha o estudo dos métodos de acesso do SGBD, para elaboração dos índices de cada informação colocada nos Modelos Conceitual e Lógico. Esta é a etapa final do projeto de Banco de Dados.

Projetando o Banco de Dados

Todo o projeto de um sistema que utilize banco de dados necessita de um coração. A modelagem de um sistema através da abordagem Entidade-Relacionamento representa esse ponto central no projeto conceitual de um sistema.

O objetivo da Modelagem de Dados é transmitir e apresentar uma representação única, não redundante e resumida, dos dados de uma aplicação.

Em aplicações que usam banco de dados, o modelo Entidade-Relacionamento ainda é o mais largamente utilizado para a representação e entendimento dos dados que compõem a essência de um sistema.

A utilização de uma abordagem correta de metodologia orientada a banco de dados envolve a estruturação nos três níveis de visão de dados vistos acima, ou seja, três etapas na execução de um projeto: conceitual, lógico e físico.

Meta Modelo

É evidente que a realidade de uma empresa é diferente de outra. Mesmo duas livrarias podem ter diversas coisas diferentes. Pode ser que em uma delas exista um controle de comissões por vendedores e na outra não. Pode ser ainda que em uma livraria se queiram controlar os pedidos que os próprios funcionários fazem dos produtos da mesma, dando baixa no estoque, e na outra não.

Devido a esta não similaridade entre ambientes de mesma natureza, será sempre necessária a criação de um modelo específico para cada realidade observada.

Precisamos de um modelo “genérico” que nos permita construir vários outros modelos a partir dele. Esse é chamado de Meta Modelo. O Meta Modelo que vamos analisar agora é o Entidade-Relacionamento (E-R) ou Diagrama Entidade Relacionamento (DER).

Segundo a Wikipédia: “um modelo entidade relacionamento é uma maneira sistemática de descrever e definir um processo de negócio. O processo é modelado como componentes (entidades) que são ligadas umas as outras por relacionamentos que expressam as dependências e exigências entre elas. Exemplo: um edifício pode ser dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado em apenas um edifício. Entidades podem ter várias propriedades (atributos) que os caracterizam. Diagramas criados para representar graficamente essas entidades, atributos e relacionamentos são chamados de diagramas entidade relacionamento (DER).”

A Wikipédia continua: “Um modelo MER é normalmente implementado como um banco de dados. Nos casos de um banco de dados relacional, que armazena dados em tabelas, as próprias tabelas representam as entidades. Alguns campos de dados nestas tabelas apontam para índices em outras tabelas. Tais ponteiros representam relacionamentos.”

Este modelo foi definido por Peter Chen em 1976 e teve como base a teoria relacional criada por E. F. Codd (1970).

Ao longo dos anos vários estudiosos, entre eles Theorey, Fry e James Martin evoluíram e expandiram este Meta Modelo.

No desenvolvimento de aplicativos que usam banco de dados o modelo E-R ainda é o mais utilizado para a representação e entendimento dos dados que compõem a essência de um sistema de informações.

A notação original proposta por Peter Chen é composta de entidades (retângulos), relacionamentos (losangos), atributos (elipses) e linhas de conexão (linhas) que indicam a cardinalidade (veremos mais a frente o que significa cardinalidade) de uma entidade em um relacionamento. Na figura a seguir podemos ver um exemplo de DER utilizando a notação proposta por Peter Chen.

Segue outra figura que retrata o modelo Entidade-Relacionamento.

Parte 1 — Considerações Finais

Nessa primeira parte tivemos uma introdução aos bancos de dados. Vimos o que é um banco de dados e quais os passos necessários para se projetar um.

É importante que saibamos distinguir entre dado e informação e vimos a jornada que o dado faz, passando pela informação, conhecimento, ideia e chegando na sabedoria.

Para se projetar um banco de dados é necessário passar pelas três fases: modelo conceitual, modelo lógico e modelo físico. Os documentos do mundo real ajudarão e muito na modelagem do banco de dados e o Meta Modelo mais utilizado para realizar a modelagem é o chamado “Entidade Relacionamento” (E-R).

Continua na parte 2

T2Ti ERP — Aprenda a Desenvolver um ERP

O T2Ti ERP 2.0 é feito em C#, Delphi, Java (RIA e Web) e Lazarus. São cinco projetos diferentes. Que tal aprender a desenvolver esse ERP totalmente grátis? Parece bom?

Acompanhe o canal da T2Ti no Youtube. A T2Ti está postando todos os vídeos do T2Ti ERP 2.0 no Youtube. São quase 300 módulos!

Os vídeos estão organizados em Playlists. Então se inscreva no canal e ative o sininho para receber atualizações sobre as postagens.