Nossa caminhada continua, já vimos quais são os conceitos de dados, informações, trabalhamos com os conceitos de abstração de dados dentro dos 3 níveis da arquitetura de Banco de Dados, conhecemos as características principais dos profissionais que atuam diretamente com sistemas de Bancos de Dados e agora, na lição de hoje, vamos estudar com mais detalhes as características dos Bancos de Dados Relacionais. 

Vamos aprofundar o tema e compreender qual é a sua importância, a evolução que ocorreu até os Bancos de Dados Relacionais e, ainda, exercitar o uso prático de Banco de Dados Relacional. 

Na primeira lição, estudamos sobre os conceitos dos Bancos de Dados e, agora, relacionaremos os conceitos, diretamente, com funções e pessoas. Como já falamos na lição anterior, os computadores são apenas ferramentas utilizadas por nós, seres humanos, para melhorar a qualidade do nosso trabalho, ou para melhorar a nossa vida em geral.

Com certeza, você já deve ter ouvido a frase que “informação é poder”, e, prova disso é que você, assim como todas as demais pessoas, busca sempre estar bem informada sobre assuntos e fatos relacionados à sua realidade, ou seja, neste momento, você está buscando aumentar o seu conhecimento, por meio da informação de quais são as profissões ligadas à área de Banco de Dados com algum objetivo específico, que pode ser: escolher uma profissão para o futuro, atender a um requisito escolar para avançar nos estudos, curiosidade, ou qualquer outro objetivo que você tenha.

Entender esta necessidade é muito importante, pois quando estamos em um mundo cada vez mais dependente de tecnologias, as informações podem ser consideradas “moedas” muito valorizadas. Por exemplo: Quando você compra um livro, o que você compra? Papel ou informações? Ao assistir a um telejornal, qual é o objetivo? Matar a saudade do apresentador, ou obter novas informações? Quando você manda uma mensagem de WhatsApp para alguém, qual é o seu objetivo? Escrever apenas palavras, ou motivar a pessoa que está do outro lado a lhe passar alguma informação?

Viu, nossa vida está cercada de informações o tempo todo. Agora, em uma visão profissional, dentro de uma empresa, imagine a bagunça que seria se não houvesse alguém que pensasse e organizasse o fluxo das informações: Quais são os dados que devem ser armazenados? Onde devem ser armazenados? Quais informações devem ser geradas a partir dos dados? Quem pode ter acesso a cada tipo de dados e informações? Caso as informações sejam perdidas por problemas técnicos ou roubo de informações, quais os procedimentos para recuperá-las?

Todas estas perguntas servem para refletirmos sobre a importância de existirem profissionais preparados e focados na ciência dos dados. Hoje, fala-se muito em “Big Data”, ou melhor, todo tempo estamos gerando dados, e há vários sistemas coletando-os, desde o seu celular, as câmeras de segurança, até o seu computador. A coleta de dados ocorre o tempo todo, mas o que fazer com estes dados e quais são os cuidados e perigos que devem ser analisados? Este é o desafio que teremos em nossa sociedade, cada vez mais intenso, pois a falta de dados ou dados agrupados de forma incorreta geram informações falsas e, consequentemente, decisões ou ações erradas.

Redundância e inconsistências: os dados eram duplicados em diversos arquivos e, isso gerava, constantemente, inconsistências após um determinado período de tempo, pois, quando havia qualquer atualização dos dados era necessário atualizar em todos os lugares, o que, nem sempre, era realizado. 

Dificuldade de acesso: Buscar as informações pela organização primária (por exemplo, ordem alfabética de nomes) era até simples, mas, quando havia necessidade de se fazer buscas por outros atributos (por exemplo: localizar quais foram os clientes que fizeram compras no último mês) era um trabalho demorado e muito complexo, pois, na maioria das vezes era realizado manualmente.

Falta de integridade lógica: Em virtude do volume de dados era muito difícil trazer as informações relacionadas a algum dado que havia sido encontrado. Dessa forma era muito comum que as informações fossem incompletas ou inconsistentes, pois poderia haver mais de uma informação relacionada ao dado e era muito difícil de identificar qual era a correta.

Insegurança: Por estarem armazenados em arquivos individualizados, a segurança de acesso a esses arquivos era difícil de ser realizada, pois, a partir do momento que uma pessoa tinha acesso a um terminal de computador, essa pessoa conseguia acessar todas as informações que estavam disponíveis no computador.

Falta de atomicidade das transações: A atomicidade é uma característica dos Bancos de Dados, que é muito importante, pois diz que o dado não deve ser composto, ou seja, o dado armazenado deve ser sempre atômico (indivisível). Para agilizar a recuperação dos dados era muito comum compor o armazenamento com várias informações e isso gerava sérios problemas, pois sempre que recuperava-se algum dado, era necessário consultar algum lugar para separar o significado do dado. (Por exemplo: armazenar o endereço completo do cliente em um único local, contendo a rua, número, cidade, estado, cep tudo junto).

Frente a esses problemas, em 1968, a IBM  desenvolveu, em parceria com as empresas Rockwell e Caterpillar, um dos primeiros Sistemas de Bancos de Dados, o IMS (Information Management System), que existe até os dias de hoje. O grande desafio do sistema, na época, foi realizar o inventário (levantamento) de todas as peças do foguete Saturn V. O IMS é um Banco de Dados com Arquitetura Hierárquica, que é uma arquitetura que antecede o modelo relacional e que ainda atende a algumas necessidades de mercado, em segmentos específicos. 

No início da década de 60, o presidente dos Estados Unidos John F. Kennedy desafiou a nação a enviar o primeiro americano, com segurança, para a Lua. Além disso, o programa deveria permitir voltar à lua antes do final da década. A empresa norte-americana Rockwell ganhou a chance de projetar e fazer o foguete Saturn V. Mas, como os prazos foram definidos para construção de forma precisa, a Rockwell exigiu que fosse incluído no projeto a aquisição de um sistema automatizado, capaz de acompanhar a enorme quantidade de materiais e equipamentos envolvidos, obtendo as informações de forma imediata, sempre que necessário. 

Na época havia uma pequena equipe de programadores, dentro da empresa IBM, que estavam desenvolvendo o projeto de um sistema de banco de dados hierárquico, de alto desempenho, que conseguiria recuperar, organizar e armazenar alto volume de dados rapidamente. A programação de software naqueles dias era um grande desafio, e os mentores sempre tinham que avaliar todos os novos produtos que eram desenvolvidos pela equipe. Como era uma época em que todo o conhecimento estava na experiência das pessoas, ou nos livros e artigos científicos, qualquer evolução sempre era mais demorada.

“Um dos problemas de estar a frente no negócio de programação é que não havia nada por perto com mais experiência do que você”, disse Vern Watts, da IBM. Em 1966, uma equipe de 12 membros da IBM,  juntamente com 10 técnicos da Rockwell e três da Caterpillar Inc. – que era quem fornecia equipamentos de energia para as comunicações entre a espaçonave e todas as estações de rastreamento da NASA ao redor do mundo – começaram a trabalhar projetando e desenvolvendo o sistema que foi chamado de “ICS/DL/I”.  A primeira versão do sistema foi concluída e empacotada em 1967. No ano seguinte, o sistema de software foi entregue à NASA. E em 14 de agosto de 1968, a primeira palavra “READY”(pronto) foi exibida em um terminal IBM 2740 na Rockwell Space Division da NASA em Downey, Califórnia. 

E então, com todos os olhos voltados para o histórico pouso na Lua em 20 de julho de 1969, o ICS/DL/I fazia história, instalado em um computador mainframe (de grande porte) no Centro de Naves Espaciais Tripuladas da NASA em Houston, Texas. O novo sistema de banco de dados acompanhava a enorme lista de materiais do Saturn V, que era composta por centenas de milhares de peças. A descida da Apollo 11 na Lua foi o primeiro grande passo para o desenvolvimento de sistemas automatizados de gestão de dados e operação de informações. 

Após essa conquista, o ICS/DL/I foi renomeado para IMS - “Information Management System”(Sistema de Gerenciamento de Informação) e foi lançado comercialmente para mainframes IBM. O produto comercial tinha duas partes principais: o sistema de Banco de Dados, suportando um modelo de dados de estrutura hierárquica, que armazena os dados em forma de árvore; e o software de processamento de transações para atuar com transações complexas e de alto volume.

Voltando a 1978, a IBM iniciou um projeto chamado System R, que tinha suporte na teoria dos Bancos de Dados Relacionais, desenvolvida por Edgar Frank Codd. Para aplicar o modelo, Codd criou uma linguagem específica para Banco de Dados Relacionais, que a chamou de Alpha. 

Entretanto, a IBM não acreditava no potencial das suas ideias, deixando-o fora da supervisão do grupo de programadores, que violaram diversas ideias fundamentais do modelo relacional de Codd. Em 1983, foi lançado, pela IBM, do Banco de Dados DB2, com o suporte da linguagem SEQUEL - Structured English Query Language" (Linguagem de Consulta Estruturada em Inglês), que foi renomeado para  SQL (Structured Query language – Linguagem de Consulta Estruturada), porque SEQUEL já era uma marca registrada. 

Tanto o IMS, quanto o DB2 são produtos comerciais da IBM que continuam evoluindo juntamente com as novas características que a Tecnologia da Informação impõe com a evolução das tecnologias, integrando, por exemplo, recursos de processamento em nuvem, inteligência artificial, entre outros.

Retomando o que vimos até o momento: estudamos os três níveis da arquitetura de banco de dados, e é importante relembrar o conceito das Independências Conceitual e Lógica. Independência lógica: Quando trazemos o mundo externo para dentro do Banco de Dados, fazemos uma abstração da Realidade Nebulosa, que está no ambiente externo, transformando esta realidade em um Minimundo, que resume uma parte da realidade geral. 

O Minimundo é composto pelas principais características e regras de negócios que devem ser consideradas para o desenvolvimento do sistema e que deverão estar atendidas na base de dados. Para padronizar o entendimento, cria-se um modelo conceitual, que, no nosso caso, vimos por meio de uma versão simplificada do DER - Diagrama, Entidade Relacionamento. Esse modelo organiza todas as regras e características importantes em entidades, relacionamentos e cardinalidades. Passando do modelo conceitual para o modelo físico temos uma análise importante a ser feita, que é qual será a arquitetura do Banco de Dados que será utilizada.

A grande maioria dos Bancos de Dados que suportam os sistemas desenvolvidos no mercado mundial de computação são Banco de Dados Relacionais, que seguem de forma quase direta as especificações de um modelo conceitual Entidade-Relacionamento. Entretanto, existem hoje no mercado várias soluções de Sistemas de Gerenciamento de Bancos de Dados (SGBD), que seguem outras arquiteturas, como arquitetura hierárquica, arquitetura de redes, orientado a documentos ou ainda arquitetura de objetos. Todos esses Bancos são classificados como Bancos NoSQL (Não SQL), pois não seguem os padrões do SQL, apesar de a grande maioria deles terem muita referência ao SQL ou ainda seguirem conceitos genéricos de Bancos de Dados Relacionais.

Mas, por que os Bancos de Dados Relacionais são tão importantes?

Os Sistemas de Gerenciamento de Bancos de Dados Relacionais (SGBD-R) dominam o mercado mundial de Bancos de Dados, ou melhor, mais de 72% dos Bancos de Dados utilizados no mundo todo são Relacionais, de acordo com o site DB-Engines. O Ranking DB-Engines classifica sistemas de gerenciamento de banco de dados de acordo com sua popularidade e é atualizado mensalmente. Veja abaixo a distribuição de bancos de dados instalados de acordo com a sua estrutura:

Gráfico 1: Ranking de Modelos de SGBD – Sistemas Gerenciadores de Bancos de Dados,  por modelo de dados de janeiro de 2022. / Fonte: DB-Engines (2022, on-line).

Como você pode observar no Gráfico 1, o modelo de Banco de Dados Relacional é o modelo mais utilizado nos dias atuais e suporta os principais sistemas de informação de todo o mundo.

Hoje, quando falamos de Sistemas de Gerenciamento de Bancos de Dados (SGBD) Relacionais estamos pensando basicamente em tabelas de dados vinculadas por meio de colunas e linhas que possibilitam agilidade na recuperação das informações, atomicidade, pois cada registro de dados é armazenado em um único local, apenas uma vez. Isso fortalece o conceito de integridade dos dados, pois, a partir do momento que ele é armazenado em um único local, os desenvolvedores não precisam fazer muitas validações para testar a confiança do dado, pois não existem “cópias” dele no banco.

Os SGBD Relacionais são indicados para manipulação de dados comuns, de baixa complexidade e que precisam ser recuperados e analisados rapidamente. Com certeza, nesse momento você deve estar se perguntando: E os outros modelos, para que são indicados?

Em uma resposta rápida, sem nos aprofundarmos muito, podemos dizer que os demais modelos de SGBDs são, em geral, focados no atendimento de alguma especificidade de armazenamento de dados, que não é atendida nativamente pelo modelo relacional. A seguir constam alguns dos problemas que um SGBD Relacional não consegue atender nativamente ou com facilidade:

• Bases de dados que dão suporte a sistemas de Geoprocessamento;

• Bancos de dados de imagens para reconhecimento facial;

• Banco de dados que armazenam documentos que não tem um formato padronizado, como processos jurídicos;

• Bancos de dados que armazenam áudios ou vídeos. 

Apesar de existirem diversos recursos que podem ser conectados ao SGBD Relacional e permitem que ele passe a atender essas demandas. Vamos conhecer quais são os principais SGDBs Relacionais utilizados, os 5 mais populares são:

Outra característica que agrada muito os meios corporativo e governamental é a diversidade de ferramentas úteis de integração com os pacotes de programas da empresa, como o Excel, além de ser uma plataforma com recursos de alta velocidade para atualização de informações. Isso facilita a extração e análise de dados, além da geração de consultas e relatórios simplificados.

Hoje é mantido pela Oracle Cloud Infrastructure (OCI) e um consórcio de desenvolvedores. Conta com mais de 400 profissionais vinculados diretamente com o seu desenvolvimento. Utiliza nativamente o SQL (Structured Query Language,  Linguagem de Consulta Estruturada) padrão, é atualmente um dos SGBDs mais populares, pois é distribuído gratuitamente e pode ser instalado facilmente em qualquer solução que necessite de um suporte de Banco de Dados. Muitas distribuições do Sistema Operacional Linux já trazem o MySQL instalado na configuração padrão do equipamento. Por ser um software de fácil manutenção, excelente performance e grande confiabilidade, é utilizado no suporte da maioria dos sites Web, incluindo grandes empresas como NASA, Motorola, Texas Instruments, etc. 

Essa característica chamou muito a atenção das empresas, que sempre investiram bastante no desenvolvimento de sistemas de informação e uma das maiores reclamações dos usuários finais sempre foi a demora entre a modelagem conceitual e a entrega da solução que era necessária. 

Com as ferramentas de usuário, os gestores de dados (DBAs) precisavam apenas fazer o controle de segurança de acesso e criar visões específicas de dados para os seus usuários, e, posteriormente, poderiam incluir o desenvolvimento de soluções definitivas integradas ao sistema de informação geral da empresa, caso fosse necessário. 

Por falar em visões, em linhas gerais, são um tipo de “janela” de acesso aos dados que os DBA’s podem criar no Banco de Dados, elas possuem uma pré-formatação de um grupo de dados que o usuário final terá acesso nas suas consultas. Mas, esse é um assunto muito importante, que vamos tratar em uma lição futura, combinado?

Outra característica que é original no Banco de Dados Oracle é a sua escalabilidade, ou melhor, o seu poder de crescimento conforme a empresa cresce e aumentam os dados e informações processadas.

Assim como os demais, é um SGBD robusto, que conta com ferramentas modernas que permitem seu uso localmente, em rede ou no ambiente distribuído.

Access: Muito conhecido por ser uma versão popular de Banco de Dados, que compõe muitos pacotes Office, da empresa Microsoft, foi desenvolvido para atender basicamente o usuário que necessita gerenciar seus sistemas pessoais ou pequenas empresas.

Traz, nativamente a integração com os demais pacotes Office, o que lhe confere um grande poder de saída de dados para o usuário, pois consegue colocar dentro do seu texto do Word, ou dentro da sua Planilha, dados que estão armazenados no Access, gerando de forma rápida e simples relatórios que podem ser preparados por um usuário sem qualquer experiência em Banco de Dados, que conheça apenas como usar as ferramentas de edição de textos ou planilha de cálculos. É um SGBD exclusivo para o Sistema Operacional Windows e integra o pacote Office.

Os SGBDs são classificados pela forma como organizam estruturalmente os dados, ou seja, cada Banco de Dados no mercado segue um referencial de organização de dados e esse formato é o que o classifica.

Quando estamos falando em um SGBD (Sistema de Gerenciamento de Banco de Dados) Relacional, estamos fazendo referência a um conjunto de ferramentas que possibilita não apenas a criação das tabelas no Banco de Dados, mas também fazem a segurança e a consulta dos dados, além de outras funcionalidades que os fornecedores dos SGBDs podem incluir nos seus produtos, mas, basicamente, um SGBD Relacional recebe esse nome pois trabalha toda a composição das informações geradas com base em atributos de relacionamento entre as tabelas, o que denominamos de Chaves. 

A princípio, no Banco de Dados Relacional nós teremos 3 tipos de chaves:

Para entender completamente o conceito, vamos imaginar que temos que automatizar o processo de cadastramento de funcionários da empresa. No modelo externo (Realidade Nebulosa), conseguimos identificar o seguinte documento:

Com base no diagrama acima, teremos então as seguintes tabelas no nosso Banco de Dados:

Desta forma teríamos a distribuição das chaves, da seguinte forma:

Em resumo, pela tabela 6, conseguimos observar que todas as informações que precisaremos montar no sistema vão trafegar por meio das chaves primárias (PK) e chaves estrangeiras (FK), como, por exemplo, caso eu tenha a informação da dependente Maria Eulália da Silva, você saberia me dizer de quem ela é dependente, se o pai/mãe dela tem cônjuge e ainda, qual é o valor do salário base que o funcionário responsável por ela recebe?

Para isso teremos que usar os relacionamentos. Vamos recuperar na tabela de dependentes a Maria Eulália da Silva. Já sabemos que ela é dependente do(a) funcionário(a) 002, que, quando vamos até a tabela de funcionários, sabemos que é o Renato Barros e que ele não tem cônjuge cadastrado na Tabela de Cônjuges. Por último, olhando a tabela de funcionários, sabemos que o Renato Barros tem o cargo 171, que, ao consultar na tabela de cargos, sabemos que ele é Chefe de Costura e recebe um salário base de R$920,00. 

Espero que com esse exemplo tenha ficado claro para você como que um Banco de Dados, ou melhor, um SGBD Relacional funciona. Sugiro que você pesquise mais alguns exemplos para entender bem o funcionamento dos relacionamentos, pois é fundamental para trabalhar na área de Tecnologia da Informação. 

Antes de encerrarmos todas as atividades desta lição, vamos fazer dois exercícios de relacionamento para ver se você entendeu bem como os dados se relacionam dentro de um SGBD Relacional e como as informações são geradas. Para facilitar, vamos utilizar as mesmas tabelas que criamos durante a lição, observando os dados dos funcionários da empresa XYZ Confecções. Como fazemos para responder as 3 perguntas abaixo:

1. Quantos anos tem o(s) dependentes do funcionário Renato Barros?

2. Qual é o funcionário que tem o maior salário base na empresa?

3. Podemos afirmar que a Maria da Silva (Tabela Cônjuge) é a mãe de Jonas de Aquino e Margarida Massa (Tabela: Dependentes)?

Resposta

Vamos às respostas, explicando passo a passo...

Para responder a pergunta 1, vamos ter que olhar na tabela de funcionários e achar o Renato Barros. Pegamos a chave primária, que é 002 e vamos na tabela de dependentes procurar por todos os dependentes que tem a chave estrangeira (id_func) igual a chave primária que trouxemos, ou seja, que seja igual a 002. Encontramos apenas um registro, que é a Maria Eulália Silva, que nasceu em dez/2018. Logo, ela tem 03 anos de idade até 09/12/2022, quando fará 4 anos. Nesse caso utilizamos apenas um relacionamento, que foi o que está entre funcionários e dependentes.

Para responder a pergunta 2, vamos ter que usar o relacionamento que existe entre as tabelas funcionários e cargos, pois o valor do salário está nesta tabela. Dessa forma sabemos que o maior salário é o de Chefe de Costura (R$ 920,00), que tem a chave primária 171. Levando essa chave para a tabela funcionários, vamos olhar a coluna codigo_cargo, que é a que tem a chave estrangeira da tabela de cargos. Nesta tabela observamos que temos dois registros que tem esse mesmo cargo, que são os funcionários: Luiz Correa e Renato Barros. Logo, a resposta então seria essa, ou seja esses dois funcionários são os que têm o maior salário base da empresa.

Para responder a pergunta 3, vamos precisar de dois tipos de conhecimento: primeiramente precisamos saber onde achar os dados e, além de receber os dados, vamos ter que compreender a regra que está sendo solicitada para encontrar os dados. A gente poderia iniciar pela segunda parte da análise, pois, nesse caso, seria mais rápido, porém vamos seguir um passo a passo lógico, como o SGBD faria para trazer a resposta. 

Vamos iniciar pela tabela de cônjuges,  onde vamos pegar a chave primária id_func e levar até a tabela funcionários, para encontrar quem é a chave que vai ligar a cônjuge aos dependentes. Apenas uma observação técnica aqui: você deve ter observado que as chaves primárias das tabelas cônjuges e funcionários são exatamente iguais. Isso ocorre sempre que temos um relacionamento 1:1 no modelo conceitual, ou seja a tabela cônjuge poderia ser considerada uma “extensão” da tabela funcionários, pois sempre teremos apenas um registro atuando neste relacionamento. 

Continuando vamos até a tabela de dependentes e confirmamos que Jonas e Margarida são dependentes de Sérgio Cardoso, que é o cônjuge de Maria da Silva. No mundo dos dados, conseguimos responder tecnicamente que os registros estão relacionados, mas, a “regra de negócio” ser mãe somente poderia ser respondida se tivéssemos certeza que Sérgio Cardoso é pai de Jonas e Margarida. No Banco de Dados nós não temos essa informação, apenas que ambos são dependentes. Podemos até deduzir que eles seriam filhos de Sérgio Massa, mas seria apenas dedução e não certeza, mas, ainda temos mais uma regra, que é a principal: Em nenhum local tem algo que nos informe que a cônjuge, nesse caso, é mãe dos dependentes. 

Ela poderia ser casada com o Sergio Cardoso em um segundo casamento, ou até em um primeiro, e ambos serem filhos de outra mãe. Logo, não é possível respondermos a terceira pergunta com os dados que temos armazenados no Banco de Dados. Essa é uma situação comum, pois os Bancos de Dados são criados com base no Minimundo estudado pelo Analista / DBA e, muitas vezes, nessa separação de regras da realidade do usuário que irá ser informatizada, há algumas regras não previstas, que podem ser implementadas posteriormente, caso haja essa necessidade no sistema.

Acredito que com esse exercício você tenha compreendido um pouco melhor a importância dos Bancos Relacionais. Vamos ficar por aqui nesta aula e nos encontramos na nossa próxima lição, até mais!