Nesta lição, daremos continuidade aos estudos da Arquitetura de Banco de Dados. Vamos entender quais são os procedimentos para converter o que foi levantado junto ao usuário e extrair as informações do minimundo, isto é, o que foi criado a partir das regras de negócios e conceitos levantados na realidade, no nível externo, e que devem ser tratados no mundo dos dados.

O Nível Conceitual, abordado na lição de hoje, trata-se de uma etapa fundamental para que seja possível aos desenvolvedores (DEVS) programarem o sistema de informações.

Você, neste momento, deve se perguntar: por que preciso saber de tudo isso para montar um Banco de Dados?  Talvez, você tenha imaginado que, no mundo da informática, tudo é bem simples e sem organização, planejamento, ou melhor, basta aprender uma linguagem e sair programando.

Isso até pode ser aplicado, quando falamos de sistemas, ou programas, simples ou pontuais, que resolvem apenas uma situação, ou atendem apenas a uma função, por exemplo, um programa que mostre as horas. Mas imagine a quantidade de dados, informações e regras de negócios que têm em uma empresa, seja ela de qualquer porte. 

Vamos pensar em um Restaurante, para exemplificar. Olhando o Mundo Real, podemos dizer que o Restaurante tem Fornecedores, que fornecem Produtos para serem vendidos aos Clientes. Além dos produtos prontos, como sorvetes, por exemplo, vários produtos são fabricados no Restaurante. Para organizar quais são os produtos do Restaurante, existe um cardápio, utilizado pelo cliente para escolher quais produtos vai consumir. Além disso, o Restaurante tem funcionários, contas a pagar, receitas dos pratos, entre diversos outros itens que necessitam ser gerenciados pelo Sistema que está sendo desenvolvido. 

Quando fazemos o levantamento em nível externo, temos uma série de visões que o cliente nos informa, a qual temos que organizar. Para essa organização, utilizaremos o segundo nível da nossa arquitetura: o nível conceitual.

Mas, afinal, por que isso é importante? 

Construir um bom projeto é importante para que todos os profissionais envolvidos no desenvolvimento do Sistema sigam uma padronização, visando, principalmente, atender às necessidades do usuário/cliente e para que sejam evitados, ao máximo, interpretações ou soluções pessoais que podem estar desalinhadas com o pensamento do todo. E, desse modo, acarretar alguns problemas no sistema, por falta de compatibilidade com o restante do projeto que está sendo desenvolvido.

Para entender bem esse problema, imagine que temos duas equipes cavando um túnel, onde vai passar um trem, uma equipe na Inglaterra e outra na França. Se cada equipe fizer do seu jeito, é bem provável que haja problemas na hora de interligar os túneis, podendo, inclusive, jamais se encontrarem e terem seu trabalho completamente perdido, mas, se ambas as equipes seguirem o mesmo projeto, reduz-se o risco de erros e, assim, tem-se grande probabilidade de sucesso. Com certeza, para criar o projeto, houve uma demanda de tempo e profissionais qualificados, mas esse tempo é compensado com a segurança de desenvolvimento de um trabalho eficaz.

Quando falamos em Banco de Dados, é bem semelhante: temos que ter um bom projeto, pois várias equipes poderão participar do desenvolvimento de programas que farão acesso a esses dados e, caso não haja um bom projeto, o risco de que os dados percam a integridade é grande. Lembrando que: se perdermos a integridade, as informações podem gerar decisões erradas às empresas e, por consequência, podem render grandes prejuízos.

Como você deve ter observado na Realidade Nebulosa que criamos do nosso Restaurante, temos várias informações que precisamos organizar para conseguir criar um modelo conceitual. Para facilitar, vamos olhar cada um dos itens que registramos no minimundo criado e tentar visualizar como os itens estão relacionados entre si, pois itens soltos, ou não relacionados, geralmente, são itens que não têm importância dentro do sistema e, logo, não precisam estar no nosso projeto.

Para isso, é importante analisarmos todos os itens, vamos lá? 

Inicialmente, vamos olhar o Restaurante: a não ser que existam filiais do Restaurante, ele é único, ou seja, já sabemos que seus dados não vão variar de forma que causem impacto no sistema. Dessa forma, vamos deixá-lo isolado. Agora, vamos vincular o restante dos itens. 

Para facilitar a visualização, vamos colocar essas informações de uma forma gráfica.

Agora, vamos entender e praticar um pouco o Modelo Conceitual.

O primeiro ponto que temos que observar é: o modelo conceitual irá gerar um diagrama que representará o relacionamento entre os dados de todos os “objetos” do mundo real, ou melhor, da realidade nebulosa. Esse diagrama irá representar, graficamente, o levantamento realizado no nível externo, possibilitando ao Analista de Banco de Dados, ou o DBA (Database Administrator), visualizar e compreender a estrutura do Banco de Dados de forma rápida e dinâmica.  O Diagrama mais comum de encontrarmos nesse nível conceitual é o DER (Diagrama Entidade Relacionamento).

Em geral, esse não é um diagrama difícil de ser montado, ou de ser lido, pois, basicamente, o diagrama tem apenas 3 componentes: Entidades, Relacionamentos e Cardinalidade. Vamos estudar, agora, cada um deles individualmente.

Exemplos de Entidades: 

Cliente: este é uma entidade, em geral, pois é algo que existe, é um substantivo, e tem atributos específicos, que são os dados de cada cliente. Os tipos de dados nós vamos discutir um pouco mais no nível físico, mas é muito importante que a gente consiga visualizar a Entidade e seus atributos nesse nível, para conseguir validá-los com o usuário, caso seja necessário.

Outro exemplo: os veículos, pois eles também existem e têm atributos específicos, como placa, cor, marca, ano, modelo etc.

Se voltarmos à Figura 2, na qual fizemos a representação do Restaurante, podemos exemplificar que cada uma das “caixinhas” da figura é uma Entidade, pois, além de existirem, todos eles têm atributos específicos. 

Ainda, nesse exemplo, você deve ter observado que, entre o que identificamos na Figura 1 e transferimos para o diagrama da Figura 2, não trouxemos Restaurante como uma Entidade. Por que Restaurante não seria uma Entidade? Restaurante existe? Sim! Restaurante tem atributos? Sim. 

Não temos, porém, em geral, motivos para alterar os dados do Restaurante, ou seja, se os dados são fixos, não há necessidade de colocarmos dentro do Banco de Dados, pois tudo o que está no Banco de Dados é do Restaurante. Dessa forma, como essa é uma informação que já temos e todos sabem, não iremos transformá-la para o mundo digital.

A Entidade será representada por um retângulo “etiquetado”, com o nome que identifica de quem serão os atributos dentro desta Entidade:

Enquanto as Entidades são Substantivos, os Relacionamentos sempre serão Verbos. O Verbo irá identificar porque há um vínculo, ou relacionamento entre as entidades.  Os relacionamentos serão representados por um losango.

Importante ressaltar que dentro de um DER os nomes não podem se repetir, nem os substantivos que identificam as entidades, nem os verbos que identificam os Relacionamentos.

Para exemplificar, vamos recuperar uma frase que levantamos no primeiro nível: Cada bebida tem um Fornecedor.

Em um Diagrama identificaríamos como:

Explicando um pouco melhor, a cardinalidade vai indicar quantas informações estão vinculadas entre as entidades: por exemplo: cada Veículo é de apenas 1 Cliente e cada Cliente pode possuir vários Veículos. Considerando que Veículo e Cliente são entidades e “possuir” é o relacionamento, 1 e vários serão a cardinalidade.

Para facilitar, sempre vamos identificar a cardinalidade apenas com o número “1”, quando houver apenas 1 relacionamento, e com a letra “N”, quando houver mais do que um relacionamento. Nesse caso, usaremos o “N”, pois não sabemos quantos serão os registros que estarão relacionados.

Vamos observar novamente a frase, mas agora temos que a ler nos dois sentidos: da Entidade 1 para Entidade 2 e da Entidade 2 para a Entidade 1. No nosso caso, teríamos:

Em um diagrama, identificaríamos como:

Observe que a leitura do diagrama é semelhante a leitura do texto, pois colocamos a cardinalidade no mesmo sentido do texto, conforme você pode ver acima. Se começarmos a leitura pelo fornecedor, a frase seria: cada fornecedor fornece várias bebidas (“N” Bebidas). Caso iniciemos a leitura pela bebida, temos que: cada bebida é fornecida por apenas 1 fornecedor.

Uma última observação importante nesse caso é: essa é uma regra de negócio, ou seja, que foi obtida no nível Externo (na realidade nebulosa), e deve sempre ser validada junto ao cliente/usuário. Jamais o Analista/DBA deve impor as suas regras. Nesse caso, você pode estar pensando que uma bebida poderia ser fornecida por vários fornecedores, mas temos que respeitar sempre a regra de negócio, e o nosso cliente nos informou que compra de apenas um fornecedor. Então, temos que respeitá-lo e representar de acordo com a sua realidade, pois, no nível físico, essa definição irá ajudar a preservar a integridade dos dados.

No caso, retomando o levantamento que fizemos do Restaurante, vamos chegar a um diagrama básico (DER) com a seguinte forma:

Para deixar bem claro o que o diagrama quer dizer, vamos utilizar a linguagem externa (1º Nível). Primeiro, uma observação técnica, que não faz parte do DER, mas didaticamente foi inserido no diagrama para melhor entendimento, que é a junção das entidades Bebidas e Produtos Prontos que, apesar de no minimundo eles serem diferentes, no mundo dos dados elas podem ser consideradas uma única entidade, pois têm as mesmas características. Considerando isso, foi criada a entidade Produto e ambas estão consideradas nesta nova entidade. Feita a observação, vamos, então, fazer a leitura do DER criado, lembrando que temos que ler sempre nos dois sentidos, ou seja, da entidade A para entidade B e vice-versa.

Quando um cliente escolhe um item de Cardápio ele é atendido por um funcionário. Já o funcionário pode atender vários itens de cardápio para cada cliente simultaneamente e o cliente pode ser atendido em vários itens por cada funcionário. Ainda, em relação ao cardápio, cada item do cardápio é relativo a apenas 1 prato, e cada prato pode estar em mais de um cardápio. Por exemplo, o Restaurante pode ter um cardápio de Férias, cardápio de Crianças, cardápio do dia etc. Cada prato tem apenas uma receita, e cada receita é de apenas 1 prato. A receita pode ter vários ingredientes, e cada ingrediente pode participar de várias receitas.

O ingrediente pode ter vários registros no estoque, mas cada item de estoque pode ser de apenas um ingrediente. Ainda, no estoque, ele pode ser relativo a um produto, caso não seja ingrediente, e cada produto pode ter vários lançamentos no estoque. O produto, também, pode compor vários cardápios e cada item do cardápio pode fazer referência a apenas um produto. O produto tem, ainda, um fornecedor (apenas um, conforme a regra de negócio) e cada fornecedor pode fornecer vários produtos. O fornecedor pode gerar vários títulos para contas a pagar, boletos, por exemplo, mas cada item do contas a pagar é gerado por apenas um fornecedor.

Na lição anterior, fizemos um exercício final, criamos uma agenda de compromissos. Baseado na descrição que fizemos na Lição 3 e com o que aprendeu nesta aula, você seria capaz de transformar o modelo externo em um modelo conceitual?

Tenho certeza que sim!

Primeiro, vamos retomar a descrição que fizemos. É importante que a gente identifique quais são as “coisas” que existem no mundo real e que vamos precisar registrar no nosso Banco de Dados. Apenas para relembrar, são os substantivos. Nesse caso, é importante saber se o substantivo tem atributos (características) ou se ele é apenas um atributo que pertence a uma Entidade. Por exemplo: o nome é um substantivo, mas não é uma entidade, pois a única informação que temos dentro de nome é ele mesmo. Quando falamos em Cliente, ele é uma Entidade, pois tem várias informações dentro dele, como o nome, data de nascimento, endereço, CPF etc.

Para relembrar então nós identificamos:

Agora é com você. Antes de olhar a solução abaixo, tente fazer o desenho em uma folha de papel para exercitar. Isso vai ajudar a compreensão. Lembre-se que um DER pode ser diferente de um profissional para outro, pois podem existir termos distintos, a ordem das entidades pode ser diferente etc.

Na próxima lição, retomaremos esse exercício para montar o modelo físico da agenda de compromissos.