Após estudarmos os dois primeiros níveis da Arquitetura de Banco de Dados, chegamos ao 3º Nível, que é conhecido como Nível Físico, ou melhor, esse é o nível onde fisicamente vamos trabalhar com o armazenamento dos dados. Nesse nível temos que definir quais são os espaços físicos onde os dados serão armazenados, especificando características exclusivas para cada tipo e dado que será armazenado, qual o tamanho que o dado vai ocupar na base de dados, como os dados estão organizados e como o acesso será realizado.

Agora que chegamos ao nível mais profundo dentro de um projeto de Banco de Dados, precisamos retomar a nossa terceira lição, quando falamos sobre os níveis externo, conceitual, quando citamos que uma das principais características em se trabalhar dentro do modelo  de arquitetura de dados em 3 níveis é a independência de dados: Lógica e Física. 

Agora, depois de conhecer os níveis externos e conceitual, você já deve ter observado que entre os dois modelos há independência, pois, apesar de termos estudado apenas uma versão do DER (Diagrama Entidade Relacionamento), podemos utilizar outros modelos de diagramas no nível Conceitual, que, conforme você for se familiarizando com as características de Análise de Sistemas e de Banco de Dados, certamente terá contato.

Além de muitas outras formas de representação que podem ser desenvolvidas conforme a evolução do conhecimento e das necessidades dos sistemas. O importante, nesse momento, é compreender que o nível Conceitual pode ser apresentado de diversas formas, mas sempre estará representando o mesmo mundo externo, por isso citamos que existe a independência lógica entre eles. Outra característica importante que citamos, e vamos aprofundar nessa lição é a independência física entre os níveis Conceitual e Interno (ou nível físico). 

Mas onde será que todos os dados ficam armazenados? Será que é necessário um lugar físico para isso? E se sim, como se comunicam com os demais níveis da Arquitetura de um Banco de Dados? 

Na lição de hoje vamos aprender que no nível físico, o Analista/DBA irá criar efetivamente o Banco de Dados, onde ficarão guardados todos os dados coletados no mundo exterior, ou melhor, da realidade do usuário,  e que devem ser capazes de produzir as informações necessárias para dar suporte às decisões do usuário.

Quando falamos que existe a independência, significa que o nosso banco de dados pode ter estruturas diferentes, de acordo com as características técnicas dos dados que serão armazenados e ainda podem ser de fornecedores diferentes. Se voltarmos ao exemplo da construção de uma casa, podemos fazer uma comparação entre o desejo do cliente com a casa. 

Seguindo o exemplo iniciado nas lições anteriores, vamos dar continuidade à criação do sistema para um Restaurante. No segundo nível, conseguimos finalizar uma estrutura conceitual que representa o nosso sistema de Restaurante, que ficou conforme a Figura 1, a qual podemos ver a seguir:

O próximo passo, agora, é identificar quais são os atributos que existem em cada uma das entidades, que, no modelo físico, iremos chamar de tabelas. Os atributos das tabelas serão denominados campos. Durante essa identificação, vamos fazer uma análise nos atributos para buscar identificar se existe algum atributo que é único. Observe o exemplo a seguir

Analisamos, portanto, que somente o campo cpf_cliente é um campo único, ou seja, os demais campos podem ter o mesmo conteúdo (dados) para outros clientes, mas o CPF identifica, apenas, uma pessoa. Por exemplo: o Restaurante pode ter vários clientes com o nome José da Silva, vários clientes VIPs, com o mesmo limite de crédito, ou ainda que nasceram no dia 01/01/1980, porém com o CPF 123.456.789.11 vai existir, apenas, para um cliente. Nesse caso, conseguimos identificar um campo único para a tabela, que vai ser muito útil para fazermos os relacionamentos.

Como já foi citado no início desta lição, o Modelo Interno ou Físico do Banco de Dados é a camada mais avançada em relação à gestão de dados e, consequentemente, é a camada mais técnica, no qual vamos encontrar as linguagens. Diferente de outras ferramentas de Tecnologia da Informação, o Banco de Dados tenta manter um padrão de linguagem para fazer todos os processos relativos aos dados. Essa linguagem base recebeu o nome geral de SQL (Structured Query Language), ou Linguagem Estruturada de Consultas. 

O grande desafio inicial do SQL é ser uma linguagem de alto nível, ou seja, uma linguagem próxima ao idioma humano, sendo, ainda, adaptada ao modelo relacional. Como o SQL é uma linguagem que foi desenvolvida na década de 70, pela empresa IBM, na Califórnia, Estados Unidos, naturalmente seus comandos derivam do idioma Inglês e seguem, em geral, a mesma estrutura desse idioma. Mais para frente, vamos tratar sobre os principais comandos do SQL. 

Dentro do SQL, temos poucos comandos e eles estão classificados conforme o tipo de função que realizam nos dados. O primeiro grupo de comandos é o mais utilizado, e é denominado de DML ou Data Manipulation Language (Linguagem de Manipulação de Dados), que serve, especificamente, para trabalhar com os dados. Nessa camada, teremos os comandos:

Nas próximas lições, exploraremos um pouco mais os comandos, mas, nessa lição, vamos trabalhar especificamente em nível físico; então, o nosso próximo passo é criar o modelo físico do Banco de Dados, a partir do modelo conceitual. Para isso, nós vamos trabalhar transformando todas as entidades, do modelo conceitual, em Tabelas. 

Resgatando o sistema de restaurante, teremos, inicialmente, as seguintes tabelas:

Agora, colocaremos os campos em cada tabela, ou seja, vamos identificar formalmente os dados que cada tabela vai armazenar:

Como o Banco de Dados aceita somente uma palavra no nome do campo, teremos que usar underline “_” para simplificar os atributos com mais de uma palavra na identificação. Nesse caso, teremos:

As demais tabelas serão definidas como:

O próximo passo é identificar a chave de acesso à tabela. Uma chave de acesso é um campo que recebe um valor único, ou melhor, que jamais irá repetir para outros registros dentro da tabela. Relembrando que um registro é um conjunto de dados de um lançamento dentro da tabela, por exemplo, no caso de cliente, poderíamos ter como registro: (12345678911, “José Maria”, 01/01/1980, sim, “1000,00”). Nesse caso, temos um registro do cliente José Maria, que nasceu em 01/01/1980, é um cliente vip, com limite de R$1.000,00, e tem o CPF 12345678911.

Se analisarmos todos os dados, podemos ter outros clientes com o nome José Maria? A resposta é sim; em nossa comunidade, é comum termos pessoas homônimas. Podemos ter outro cliente que nasceu no dia 01/01/1980? Sim, pois as pessoas nascem no mesmo dia. VIP e com limite de crédito, com certeza teremos vários clientes que se enquadram nessas características. E o CPF? Podemos ter outro cliente com o mesmo número do CPF do cliente José Maria? Com certeza, não podemos. 

Desta forma, podemos dizer que o CPF é uma chave natural para a tabela cliente. Dentro do nosso modelo físico, então, vamos marcar a chave de acesso de forma diferenciada. Neste caso, vamos identificar a chave de acesso, sublinhando-a.

Nas outras tabelas, ainda, temos que fazer algumas análises, por exemplo, o Produto. No caso de Produto, temos 5 atributos, ou campos, e poderíamos dizer que o nome_produto seria uma chave natural, pois não poderíamos ter 2 produtos com o mesmo nome. No entanto, como esse é um item que pode ser externo ao restaurante, ou seja, ele será definido por um fornecedor, que pode colocar o nome que quiser, não é recomendado utilizar esse campo como chave. Nesse caso, teremos que criar uma chave única artificial dentro do nosso banco de dados, a qual podemos chamar de código_produto. O mesmo faremos com as tabelas ingrediente e prato, observe:

Agora temos, ainda, as tabelas de estoque e receita. Se olharmos no modelo conceitual, vamos observar que ambas têm um relacionamento 1:1, ou seja, sempre vamos ter apenas um registro de produto ou ingrediente relacionado a um registro de estoque e, sempre, vamos ter apenas uma receita vinculada ao prato.

Nesse caso, é importante analisar se existe a necessidade física de criarmos duas tabelas do relacionamento 1:1, ou se podemos apenas juntar as tabelas, colocando os atributos todos fisicamente em um só registro.

No caso de receita, a sugestão é juntar prato com receita. Observe que ambas as tabelas têm um campo com o nome de descrição, porém com finalidade diferente. No caso de prato, serve para descrever o prato e, no caso de receita, serve para descrever o passo a passo da receita. Teríamos, então, uma nova tabela de prato, na qual colocaremos a descrição de receita com o nome de preparação, com a seguinte especificação:

Vale, aqui, uma observação que os Bancos de Dados permitem a criação de um campo tipo texto longo, que será o caso do tipo do campo de preparação.

Em estoque, o único campo que temos diferente é o da quantidade. Nesse caso, podemos levar quantidade para as tabelas ingredientes e produtos, eliminando a tabela estoque. Teremos, então, as novas tabelas:

Feita a atribuição das tabelas, temos que fazer uma última validação, esta possibilitará resgatar os registros vinculados das tabelas. Em todos os lugares onde tivermos uma cardinalidade N (mais do que 1 registro vinculado), isto é, temos que verificar se o campo chave do lado 1 faz parte dos campos do lado N, caso não faça, vamos ter que o inserir para possibilitar o relacionamento físico entre os registros. 

Vamos iniciar com o relacionamento fornecedor: contas a pagar. Sabemos que a chave “fornecedor” terá que estar presente em contas a pagar. Quando fizermos referência a fornecedor, o CNPJ será sempre chave primária e, quando fizermos referência a contas a pagar, o CNPJ será uma chave estrangeira, pois ela vem de outra tabela (fornecedor) e serve, basicamente, para conseguirmos vincular as duas tabelas fisicamente.

Teremos então:

Para produto:cardápio e prato:cardapio, teremos:

Temos ainda um relacionamento N:N, entre ingredientes e prato (pois eliminamos a receita e um relacionamento ternário com 3 entidades) entre cliente, funcionário e cardápio.

Sempre que tivermos um relacionamento N:N e, na maioria das vezes, que tivermos um relacionamento ternário (com 3 entidades) precisaremos criar uma tabela de relacionamento, que vai conter a chave primária de todas as entidades envolvidas. Essa chave será uma chave composta pelas chaves primárias das tabelas envolvidas e, se necessário, algum outro atributo que a torne única.

Para prato:ingrediente teremos:

E para o relacionamento atende, que está entre cliente:funcionário:cardápio vamos ter:

Para finalizar o processo ainda podemos fazer mais alguns refinamentos, juntando algumas tabelas, mas, a princípio vamos manter dessa forma, pois estamos apenas introduzindo o conteúdo.

Para finalizar nossa lição, vamos voltar ao exemplo do sistema de agenda de compromissos. Na lição anterior definimos o modelo conceitual e agora é a hora de transformarmos o modelo conceitual em um modelo de físico. Para relembrar, o DER que finalizamos foi o seguinte:

A partir desse modelo, vamos agora definir as tabelas. Nesse caso teremos 5 tabelas, pois temos 3 entidades e dois relacionamentos: N:N. Considerando isso, podemos definir então:

No caso, os dois relacionamentos N:N serão tabelas de relacionamentos, que terão armazenadas apenas as chaves de acesso das tabelas principais, que permitirão o armazenamento dos dados de cada reunião, atendendo aos requisitos levantados no modelo conceitual.

Por último, apenas considerando que este não é um bom nome para uma tabela, pois não tem um significado autoexplicativo do tipo de registro que ela armazena, vamos renomeá-la para atividades do compromisso.

Agora que você já conhece os 3 níveis de abstração que devem ser desenvolvidos, com certeza vai enxergar o mundo dos dados de forma diferente. Observe, no seu dia a dia, quanta informação você tem a sua volta, não é mesmo? Tente abstrair dados de tudo o que está envolvido em um determinado momento e, com essas informações, responda: como tudo seria armazenado em um Banco de Dados? É um belo exercício para treinar a sua visão analítica! 

Em nossa próxima aula estudaremos os Bancos de Dados Relacionais, até mais!