Quando pensamos em um projeto de banco de dados, o primeiro grande objetivo é transformar em dados ou informações o que existe no mundo real do nosso usuário, em uma estrutura que suporte o atendimento a todas as necessidades futuras de informação que ele terá.  

Nesta aula, você entenderá como se inicia um projeto de banco de dados e conhecerá o primeiro nível de uma Arquitetura de Banco de Dados que está mais próximo ao usuário, chamado de nível externo.

Neste momento, convido você a refletir um pouco sobre o mundo de projetos de Banco de Dados. Imagine quantos Sistemas existem, quantos projetos são desenvolvidos e como os Analistas/Desenvolvedores fazem para manter seus projetos dentro de um padrão mínimo que permita a todos trabalhar com o mesmo foco, mantendo uma uniformização que permita reproduzir as regras de negócios dentro do mundo dos computadores. Este é um grande desafio, pois temos que transformar algo que está em um mundo visual, que conhecemos, para o mundo dos dados. Pensando nisso, temos que relembrar o conceito de abstração que vimos na Lição 1.

Com a abstração buscamos trazer da realidade as características que utilizaremos dentro do sistema para atender às necessidades do nosso usuário. Para tornar essa abstração mais padronizada, em 1975, foi proposta uma arquitetura, utilizada até hoje, chamada Arquitetura de Banco de Dados ANSI/SPARC, que define quais são os níveis de abstração que devemos utilizar dentro de um projeto de banco de dados, respeitando todos os atores envolvidos no processo e a forma como estes enxergam a realidade dos dados, incluindo, nesses atores, os usuários, os desenvolvedores e os analistas de bancos de dados.

Como você já deve ter percebido, nós trabalharemos, então com três níveis de abstração dentro de um projeto de banco de dados: o primeiro chamamos de nível externo, que é aquele que define como o usuário visualiza o sistema, ou melhor, quais são as telas e os relatórios que o usuário terá, ou que ele quer dentro do sistema. O segundo, chamado de nível conceitual, é o que define a disposição das informações dentro do banco de dados, ou melhor, como as informações estarão organizadas. Por último, nós temos o nível interno, que define a maneira como os dados são, efetivamente, armazenados e quais os métodos utilizados para acessá-los. 

Quando iniciamos um projeto de banco de dados, na grande maioria das vezes, consultamos o cliente, ou usuário do sistema, a pessoa que nos passará quais são as características que o sistema terá. É como se estivéssemos construindo uma casa nova, e o arquiteto precisasse fazer a planta dessa casa para que, depois, os engenheiros e os pedreiros conseguissem, efetivamente, construí-la. No momento em que o arquiteto está fazendo as entrevistas com a pessoa que o contratou para fazer o projeto, ele(a) faz diversas perguntas, buscando entender quais são os desejos e as necessidades que o(a) cliente tem em mente. Lembrando que, na maioria das vezes, esse cliente está sonhando com a sua casa, mas não tem o conhecimento técnico de como construí-la, não sabe qual é a necessidade de fundações, melhores materiais a serem utilizados, infraestrutura que deve ser providenciada, legislação aplicada etc. 

No caso de desenvolvimento de sistemas de informação, temos problemas bem semelhantes, pois, em geral, o usuário conhece a sua empresa, suas regras de negócios e quais são seus problemas para obter informações dentro da realidade da sua corporação, o que chamaremos, tecnicamente, de “Realidade Nebulosa”. Utilizamos esta nomenclatura, pois sabemos que a realidade existe e faz parte do dia a dia do(a) nosso(a) contratante, porém extrair dele(a) estas informações e as validar demanda uso de alguns recursos que nos possibilitem criar modelos que sejam compreensíveis a todas as pessoas que estão envolvidas no projeto, que denominaremos “modelagem”.

Então, quando nos referirmos ao levantamento de dados junto aos usuários, a descrição das necessidades e o detalhamento das informações necessárias ou desejadas, diremos que estamos fazendo uma modelagem em nível externo.

O case te deixou intrigado(a)? Assista ao vídeo a seguir para conhecer um pouco mais sobre essa história:

Já falamos, anteriormente, em nossos desafios junto ao nível externo do sistema, ou do banco de dados, que é o nosso primeiro nível de trabalho, mas temos que pensar um pouco mais tecnicamente para conseguir entender o porquê de definirmos um padrão para desenvolvimento de projetos.

Você sabe que, hoje, temos, em nossas empresas, e também em nossa vida uma grande dependência dos dados e das informações. A cada dia, a agilidade em se obter informações aumenta, o que nos permite armazenar cada vez mais dados para extrair as informações, porém com todo este volume de informações, temos que conseguir extrair da realidade apenas o que é relevante para a nossa empresa ou para o nosso projeto. 

Além disso, temos três tipos de atores diferentes que serão responsáveis pelo sistema: o usuário, os desenvolvedores e os administradores de banco de dados. É importante lembrar que cada um deles tem uma linguagem técnica diferente. Imagine se a cada nova necessidade tivéssemos que reescrever todo o nosso projeto?

Pensando nisso, a arquitetura de dados definiu nove características que são seguidas por todos os fornecedores de SGBD (Sistemas Gerenciadores de Banco de Dados), que, como nós já vimos anteriormente, é o software que faz a gestão dos Bancos de Dados e que permite aos programas do computador, ou sistemas, fazer acesso a eles, mantendo os dados e os processamentos independentes. As características são:

Agora que entendeu quais são as características que devemos observar, entenderá, efetivamente, o que precisamos registrar, ou levantar, no nível externo, junto ao usuário.

Para entendermos melhor, veja a figura a seguir:

Podemos observar que, neste modelo, o Analista observa a Realidade Nebulosa, que é onde estão todas as necessidades do cliente, e organiza as ideias em um modelo de alto nível, ou que representa o nível externo, que denominaremos aqui de minimundo, pois extrai uma porção da realidade que está sendo observada. O minimundo pode ser uma porção única, ou, ainda, pode ser subdividida, dependendo da complexidade da realidade do(a) nosso(a) cliente. A esse minimundo, ou às partes dele, daremos o nome visão, que discutiremos mais profundamente nas próximas lições. Devemos considerar, também, que é a Realidade Nebulosa que, efetivamente, interagirá com o nosso Banco de Dados, atualizando seus valores e, a cada atualização, podemos dizer que o Banco de dados tem uma nova “fotografia” da Realidade Nebulosa. Ou seja, a cada atualização, o Banco de Dados descreverá o estado atual da realidade, por meio dos dados que estão armazenados nele.

O mais importante quando fazemos referência ao nível externo, é entender que, neste nível, buscaremos compreender toda a realidade dos dados e as informações que o(a) usuário(a) necessita a partir da visão do(a) usuário(a), ou melhor, buscaremos aprender sempre a partir da sua realidade.

Nas próximas lições, você entenderá melhor as outras duas camadas, ou níveis, que utilizaremos para desenvolver um projeto de Banco de Dados, que são os níveis Conceitual (junto com o nível Lógico) e o nível Físico (ou nível Interno), que será nossa estrutura de dados.

Ficou interessado(a) sobre esse tema? Clique no play a seguir e assista ao vídeo:

Nesta aula, conhecemos quais são os três níveis de abstração que envolvem um projeto de Banco de Dados e nos aprofundamos nas características principais do primeiro nível, que é o nível externo. Para fixar melhor o nosso conhecimento e compreender um pouco mais sobre o nível externo, buscaremos informações para criarmos um sistema. Para efeito de exercício apenas, desenvolveremos um sistema de agenda pessoal. Esse mesmo sistema nós utilizaremos nas próximas lições, portanto, nesse primeiro nível, que é o externo, apenas entenderemos as necessidades que um(a) usuário(a) tem em relação a este tema.

Na imagem apresentada, podemos observar a realidade nebulosa, ou mundo real, onde as pessoas podem agendar seus compromissos em agendas de papel. Este é o nosso nível externo, pois não está dentro do nosso banco de dados. Nesse nível, na função de analista, temos que observar quais são as informações necessárias para, no nível conceitual, começarmos a projetar nosso Banco de Dados.

Podemos, então, observar que temos, os seguintes dados:

Pronto, montamos a nossa abstração em nível externo para o Sistema de Agenda. Em nossa próxima lição, continuaremos com o nosso exemplo, evoluindo para o nível Conceitual.