Na fase inicial do desenvolvimento de um projeto de software realizam-se etapas importantes, como a análise de requisitos, levantamento dos atributos e relacionamentos presentes no sistema. Outra atividade indispensável nessa fase do projeto é reunir todos os dados e analisar a estrutura, a quantidade, os tipos e as relações desses dados. Com base nessa análise, é necessário decidir qual banco de dados é mais adequado e otimizado para armazenar e recuperar os dados desse sistema.
Tendo em vista as diferentes necessidades de cada aplicação, como por exemplo a escalonabilidade do sistema ou a agilidade da busca em um banco de dados muito extenso, surgiram novos bancos de dados que implementam diferentes paradigmas. Vale ressaltar que, atualmente, o paradigma relacional é um dos paradigmas de banco de dados mais utilizados em diferentes sistemas. No entanto, com o crescimento do volume de dados sendo gerados e com as diferentes possibilidades de estrutura desses dados, é possível notar que os bancos de dados relacionais podem apresentar algumas limitações em determinadas aplicações.
Neste artigo, apresentaremos um breve resumo sobre o funcionamento de sete paradigmas de bancos de dados: key-value (chave-valor); wide column; document oriented (orientado a objeto); relational (relacional); graph (grafo); search engine (motor de busca); e multi-model (multi-modelos).
Sete paradigmas de Bancos de Dados:
Paradigma Key-Value
O paradigma Key-Value (chave-valor) é o mais simples de todos os paradigmas de banco de dados. E conforme o nome já descreve, o banco de dados é estruturado como um objeto json que possui um conjunto de pares chave-valor, no qual cada chave é única e aponta para um valor. Pode-se armazená-lo como um inteiro, uma string, JSON (JavaScript Object Notation), um array, entre outros. Alguns dos bancos de dados mais populares que implementam este paradigma são Redis, Memcached Etc.
Paradigma Key-Value
Os bancos de dados Key-Value usam estruturas de índice compactas e eficientes para localizar um valor de forma rápida e confiável por sua chave. Assim, tornam-se ideais para sistemas que precisam encontrar e recuperar dados rapidamente. Além disso, são fáceis de projetar e implementar.
Nesse banco de dados, os dados ficam salvos na memória RAM e não na memória rígida (disco – DISK). Isso limita a quantidade de dados para armazenamento, mas, em contrapartida, torna o banco de dados muito mais rápido. Outra desvantagem desse paradigma é a limitação da modelagem de dados, já que impossibilita realizar consultas (queries). Os bancos de dados Key-Value não têm uma linguagem de consulta, mas fornecem uma maneira de adicionar e remover pares de chave-valor. Sendo assim, não se pode consultar ou pesquisar os valores. Pode-se consultar apenas a chave.
redis> SET cor “azul”
redis> GET cor
>> “azul”
Na maioria das vezes, utiliza-se este paradigma como um cache para reduzir latência de dados. Grandes empresas como Twitter, Github e Snapchat utilizam bancos de dados que implementam este paradigma.
Paradigmas de bancos de dados – Paradigma Wide Column
No paradigma Wide Column (ou Column-family), adiciona-se uma nova dimensão se comparada com o paradigma Key-Value. Nos bancos de dados Wide Column, uma chave aponta para um conjunto de colunas e valores, tornando assim possível agrupar dados que se relacionam. Apesar de se assemelharem aos bancos de dados relacionais, os bancos de dados Wide Column não apresentam um schema (tabela), logo são capazes de lidar com dados não estruturados. Em vez de tabelas, esse paradigma apresenta estruturas chamadas column families, que contêm linhas de dados, onde cada linha define seu próprio formato. Os bancos de dados mais populares que implementam este paradigma são Cassandra e Apache HBase.
A linguagem de consulta utilizada no Cassandra é a CQL. Ela é muito similar a SQL, no entanto apresenta mais limitações, como por exemplo: não realizar uniões (joins) entre tabelas, tendo em vista que não existem tabelas neste paradigma.
Algumas das vantagens deste paradigma são: a velocidade das queries; a facilidade de escalonar e replicar dados; e um modelo de dados flexível. Além disso, por ser descentralizado é possível escalonar horizontalmente.
Geralmente, utiliza-se o paradigma Wide Column em situações em que há uma frequência de escrita dos dados no banco, mas não realizam-se leituras e updates desses dados com tanta frequência. Uma ótima aplicação para este paradigma é escalonar uma grande quantidade de dados de séries temporais, como registros de dispositivos IOT ou sensores.
Paradigmas de banco de dados – Paradigma Wide Column

Paradigma Document Oriented
No paradigma orientado a documento (Document Oriented), armazenam-se pares de chave-valor dentro de documentos. E esses documentos são agrupados em coleções. Neste banco, os dados não são estruturados e não apresentam um esquema (schema). Este paradigma usa a semântica simples de chave-valor, mas também oferece a possibilidade de definir uma estrutura que facilite a consulta e operação dos dados no futuro. Os bancos de dados mais populares que implementam este paradigma são MongoDB, Firestore e CouchDB.
Os campos em uma coleção podem ser indexados e as coleções podem ser organizadas de forma hierárquica, permitindo a modelagem e recuperação de dados relacionais. No entanto, este paradigma não suporta joins, logo, ao invés de normalizar os dados recomenda-se agrupar esses dados em um único documento. Por consequência, ler o dado do banco se torna muito mais rápido, mas escrever ou atualizar os dados tende a ser mais complexo.
Uma das maiores vantagens dos bancos de dados orientados a objeto é a sua flexibilidade, tendo em vista que os documentos não precisam manter a estrutura idêntica. Sendo assim, é possível atualizar os documentos, adicionando novos campos, por exemplo, sem afetar adversamente outros documentos. Essa alta flexibilidade também implica em mais responsabilidade para manter a consistência e a estrutura dos dados, o que pode ser desafiador.
Já que cada documento dentro do banco de dados é independente, com seu próprio sistema de organização, este paradigma é uma boa opção quando não se sabe como se estruturaram os dados e/ou quando o desenvolvimento precisa ser rápido, pois é possível alterar as propriedades dos dados a qualquer momento sem alterar estruturas ou dados existentes. No entanto, este paradigma não seria uma boa escolha em casos onde os dados são relacionais e atualizados com frequência, como por exemplo um aplicativo de rede social.
Paradigmas de banco de dados – Paradigma Document Oriented
Paradigmas de bancos de dados – Paradigma Relational
O paradigma relacional existe desde 1974. Ele foi criado pelo cientista de dados Ted Codd, e continua sendo o banco de dados mais utilizado em aplicações em diversas áreas. Os bancos de dados relacionais inspiraram a criação da linguagem SQL (Structured Query Language), que possibilita filtrar, agregar, resumir e limitar os dados retornados em uma query. Os mais populares deles, que implementam este paradigma, são MySQL, PostgreSQL, SQL Server e CockroachDB.
Ainda sobre os banco de dados relacionais, eles organizam seus dados em tabelas, estruturas que impõem um schema (esquema) aos registros contidos nelas. Estruturam-se as tabelas com linhas e colunas, onde cada coluna tem um nome e um tipo de dado. Além disso, cada linha representa um registro individual de dados na tabela, contendo valores para cada uma das colunas.
Modelo ACID
Os bancos de dados relacionais seguem o modelo ACID, quatro propriedades que preservam a integridade de uma transação:
Atomicidade: uma transação é atômica (indivisível), ou seja, todas as ações que resultam na transação devem ser concluídas com sucesso para que a transação seja efetivada. Então, ou a transação será executada em sua totalidade ou não será executada e um rollback será realizado no banco de dados.
Consistência: toda transação deve respeitar as regras/restrições de integridade dos dados descritas nos schemas do banco de dados.
Isolamento: uma transação não sofrerá interferência de nenhuma outra transação concorrente, ou seja, em um sistema com múltiplos usuários, transações em paralelo não interferem umas nas outras.
Durabilidade: as modificações realizadas por uma transação bem-sucedida são permanentes, podendo ser desfeitas somente por uma transação posterior e bem-sucedida. Sendo assim, os dados validados são registrados no banco de dados de tal forma que mesmo no caso de uma falha e/ou reinício do sistema, os dados estão disponíveis em seu estado correto.
Por obedecer as propriedades ACID, esse banco de dados é mais difícil de escalonar. No entanto, existem bancos de dados modernos, como o CockroachDB, que são especificamente construídos para operar com escalabilidade.
Geralmente, indicam-se os bancos de dados relacionais para dados regulares, previsíveis e que se beneficiem da capacidade de agregar informações de forma flexível. A estrutura altamente organizada conferida pela estrutura rígida das tabelas, combinada com a flexibilidade oferecida pelas relações entre as tabelas, torna esse paradigma muito poderoso e adaptável a muitos formatos de dados. A estrutura rígida das tabelas também reforça a integridade dos dados. Isso garante que os dados correspondam aos formatos esperados e que as informações necessárias sejam sempre incluídas.
Como esse paradigma organiza os dados de forma normalizada e requer schemas, se a estrutura dos dados não está bem estabelecida no início do projeto, torna-se ainda mais difícil implementar este banco de dados. Além disso, tornar-se mais desafiador alterar a estrutura dos dados no decorrer do desenvolvimento.
Paradigma Relational
Paradigma Graph
O paradigma orientado a grafos possui três componentes básicos: nós (vértices dos grafos); relacionamentos (arestas); e propriedades ou atributos. Ou seja, apresentam-se os dados como nós individuais, que podem ter qualquer número de propriedades associadas a eles, representando o relacionamento entre eles por arestas que conectam esses nós. Cada nó pode se conectar por mais de uma aresta. Os bancos de dados mais populares que implementam este paradigma são Neo4j, DGraph e Janus Graph.
Para realizar consultas em um banco de dados orientado a grafos, podemos usar um conceito chamado OGM (Object Graph Mapper), que pode ser implementado usando diversas linguagens de programação, como JavaScript, .NET, PHP e Java. Sendo assim, as queries são escritas com expressões mais concisas e legíveis.
A implementação deste paradigma é muito útil para lidar com dados em que os relacionamentos são muito importantes. Além disso, ele possibilita consultas mais complexas. Os bancos de dados orientados a grafos possuem alta performance, especialmente em datasets muito extensos.
Esse paradigma pode substituir o paradigma relacional, especialmente se, para obter as informações necessárias, realizarem-se muitos joins, afetando a performance da aplicação. Por exemplo, consultar a conexão entre dois usuários em um aplicativo de rede social utilizando um banco de dados relacional provavelmente exigirá várias junções (joins) de tabela e, portanto, consumirá muitos recursos. Realizar essa mesma consulta em um banco de dados orientado a grafos seria mais direto e eficiente, já que as conexões são mapeadas diretamente.
Paradigmas de bancos de dados – Paradigma Graph
Paradigmas de banco de dados – Paradigma Search Engine
O paradigma motor de busca apresenta similaridades ao paradigma orientado a documentos. No entanto, a principal diferença é que internamente este paradigma vai analisar todo o texto de todos os documentos e criar um índice dos termos pesquisáveis. Assim, quando um usuário faz uma busca é necessário escanear apenas o índice ao invés de buscar em todos os documentos do banco de dados. Essa busca textual otimizada torna esse paradigma muito rápido mesmo em bancos de dados enormes. Os bancos de dados mais populares que implementam este paradigma são ElasticSearch, Algolia e MeiliSearch.
Uma grande vantagem da utilização desses bancos de dados é a possibilidade de utilizar diversos algoritmos para ranquear os resultados, filtrar dados irrelevantes, lidar com erros de digitação, entre outros. Este paradigma é ideal para motores de busca textual, facilitando muito o processo de recuperação de informações relevantes, permitindo que os usuários pesquisem informações com texto em linguagem natural.
Paradigma Search Engine
Paradigma Multi-Model
O paradigma multi-modelo combina a funcionalidade de mais de um paradigma. Consequentemente, o mesmo banco de dados é capaz de usar diferentes representações e estruturas para diferentes tipos de dados. Os bancos de dados mais populares que implementam este paradigma são FaunaDB e CosmosDB.
Internamente o banco de dados analisa e decide como se beneficiar de múltiplos paradigmas de banco de dados, se baseando no código GraphQL que o usuário insere. Para recuperar as informações, apenas definimos o modo de consumo dos dados, e o banco de dados se encarrega de modelar e estruturar os dados.
Os bancos de dados multi-modelo também seguem os princípios ACID (Atomicidade, Consistência, Isolamento e Durabilidade) e são muito rápidos. Outra grande vantagem é a possibilidade de manipular os dados armazenados em diferentes paradigmas de banco de dados em uma única consulta. Além disso, esses bancos de dados também contribuem para manter a consistência dos dados, o que pode ser complexo ao realizar operações que modificam dados em vários tipos de bancos de dados ao mesmo tempo.
Utilizar um banco de dados multi-modelo garante mais flexibilidade no processo de desenvolvimento de um projeto, permitindo assim a alteração ou expansão das estruturas dos dados e dos paradigmas a partir das necessidades do projeto. Outro ponto positivo é não precisar aprender uma nova ferramenta de banco de dados, caso seja necessário mudar o paradigma que estrutura os dados.
Conclusão – Paradigmas de bancos de dados
Uma das decisões mais importantes ao iniciar um novo projeto é definir a estrutura organizacional que melhor atende às demandas desse projeto. Cada um dos paradigmas mencionados acima apresenta vantagens distintas que valem a pena serem exploradas. Portanto, aprender o que cada paradigma de banco de dados oferece pode ajudar a reconhecer quais sistemas viabilizam as melhores soluções para todos os diferentes tipos de dados e estruturas.
É fundamental ressaltar que nenhum paradigma é superior a outro. Na realidade, cada paradigma é mais adequado para ser utilizado em certas situações, e cabe aos desenvolvedores identificar qual dos paradigmas de banco de dados se encaixa melhor com a aplicação sendo desenvolvida. Inclusive, muitas vezes, implementar diferentes paradigmas de banco de dados é a melhor abordagem para lidar com os dados de seu projeto.
Graduada em Engenharia Elétrica pela Universidade Federal de Campina Grande (UFCG), com ênfase em Controle e Automação. Desenvolvedora Python na Aquarela Analytics, com foco na construção de APIs. Na área de Engenharia de Dados trabalha com modelagem de dados, e com a criação e estruturação de ETLs. Entusiasta na área de Machine Learning e Ciência de Dados.
Por muitos séculos, a melhor forma de armazenar e compartilhar informações foi escrevendo em papéis. E por mais que tenha sido de extrema importância para a propagação do conhecimento entre gerações, este método apresenta diversas desvantagens. Algumas delas são a dificuldade de se buscar e replicar informações; e a suscetibilidade dos papéis de se estragarem e suas informações se perderem. Com o desenvolvimento da tecnologia e da computação, surgiram ferramentas capazes de guardar esses dados de forma eficiente alcançando boa performance, segurança e confiabilidade.
Um banco de dados é um sistema, executando em um servidor físico, que registra e armazena dados. Além disso, também tem a função de prover essas informações quando solicitado pelo usuário. As aplicações dos bancos de dados são diversas, desde estrutura simples para armazenar informações de uma empresa pequena (dados de funcionários, planejamento de recursos e processos) até sistemas complexos com um grande volume de dados, utilizando Big Data.
Com o crescimento da internet e da quantidade de dados sendo gerados a cada segundo, surgiu a necessidade de processar, analisar e retornar informações de forma mais eficiente. Atualmente, existem diversos tipos de bancos de dados, cada um com suas especificidades e aplicações. Vale ressaltar que escolher o melhor banco de dados para a sua aplicação é uma das decisões mais importantes na hora de desenhar a arquitetura de um projeto.
História – Banco de Dados
As primeiras estruturas de bancos de dados surgiram na década de 1960 na empresa IBM. O objetivo era reduzir custos do trabalho de armazenação, organização e indexação dados e arquivos. Motivados por algumas adversidades como a dificuldade de acesso, falta de segurança, além das redundâncias e inconsistências de informações, no fim da década de 1960 a IBM lançou um dos primeiros sistemas de banco de dados, o IMS (Information Management System).
Já na década de 1970, o cientista de dados da IBM, Ted Codd, publicou o primeiro artigo sobre bancos de dados relacionais. Nele, Codd apresentou aplicações de cálculo e álgebra relacional que possibilitam armazenar e recuperar grande quantidade de informações. Neste banco de dados, o usuário poderia acessar os dados armazenados em tabelas por meio de comandos. A IBM montou um time de pesquisadores que criaram um sistema de banco de dados relacional, conhecido como System R (Sistema R).
Com a evolução das pesquisas, o Sistema R se tornou o DB2 e houve a criação da linguagem chamada Structured Query Language (SQL) ou Linguagem de Consulta Estruturada. SQL se tornou um padrão na indústria de bancos de dados relacionais, e ainda hoje é um padrão ISO (International Organization for Standardization – Organização Internacional de Padronização). Pesquisadores como Edgar Frank Codd e Dr. Peter Chen também apresentaram grandes contribuições para o desenvolvimento dos bancos de dados relacionais.
Desenvolvimento Comercial do Banco de Dados
Apesar de a IBM ter inventado os conceitos iniciais dos bancos de dados relacionais e desenvolvido a linguagem SQL, a Honeywell Information Systems Inc. foi a primeira a produzir um sistema comercial de banco de dados.
Como uma alternativa aos bancos relacionais, na década de 1980, outro paradigma que surgiu foi o banco de dados orientado a objetos. Os primeiros bancos de dados que implementaram orientação a objeto foram Exodus (1986), ORION (1986) e O2 (1988). Além disso, surgiram nessa época os bancos de dados que combinavam as características de orientação a objeto com o modelo relacional, apresentando otimização de consultas configuráveis, como por exemplo POSTGRES (1986) e STARBURST (1984-1992).
Na década de 1990 surgiram outros Sistemas Gerenciadores de Banco de Dados (SGBD), como o DBase III, Paradox, SQL Server, MySQL, entre outros. Pouco tempo depois, surgem também os bancos NoSQL (Not Only SQL – Não Somente SQL), devido ao grande crescimento da internet, aos novos formatos e estruturas de dados e à necessidade de processar esses dados de forma mais eficiente e veloz.
Atualmente, novas formas de armazenar, coletar e manipular dados existem no mercado, como o armazenamento em nuvem ou os bancos de dados autônomos. Mas com a grande quantidade de dados sendo gerados a todo momento devemos nos questionar se os modelos de armazenamento de dados atuais podem apresentar problemas de escassez de meios para guardar esses dados no futuro.
SGBDs
Data Base Management System ou Sistema de Gerenciamento de Bancos de Dados (SGBD) é uma ferramenta utilizada para gerenciar uma base de dados. Sendo assim, o SGBD é responsável por controlar, acessar, organizar e proteger as informações de uma aplicação. Ele também faz o intermédio da comunicação entre a pessoa usuária e os dados armazenados.
Utilizando uma linguagem de consulta, como o SQL, é possível inserir, atualizar, gerenciar, recuperar e remover dados do banco. Muitos SGBDs funcionam com uma extensão da linguagem padrão SQL. Por isso, é importante conhecer bem as características do SGBD com o qual se está trabalhando. Também é preciso entender o que diferencia os SGBDs e quais vantagens cada um deles pode oferecer ao seu projeto.
Alguns dos Sistema de Gerenciamento de Bancos de Dados mais conhecidos e utilizados na atualidade estão apresentados abaixo:
Oracle Database
Lançado pela Oracle no fim dos anos 1970, o Oracle Database ainda é na atualidade um dos SGBDs mais utilizados em aplicações corporativas. Ele pode ser instalado em múltiplas plataformas, como Unix, Linux, HP/UX, BIM AIX, IBM VMS e Windows; e para interagir com os dados é utilizada a linguagem PS/SQL. O Oracle também se destaca pelo seu poder de escalabilidade, por possuir muitos recursos de segurança e performance e por sua robustez e confiabilidade.
Logo ORACLE
SQL Server
Lançado pela Microsoft em 1989, o SQL Server é há anos um dos principais SGBDs relacionais do mercado, sendo utilizado em muitos órgãos públicos, instituições financeiras e empresas de e-commerce. O SQL Server pode ser instalado em contêineres do Linux com o suporte do Kubernetes ou no Windows e apresenta versões gratuitas e pagas. Sua linguagem de consulta é a Transact-SQL (T-SQL) com uma sintaxe simples e que se assemelha muito a linguagem SQL. Além de apresentar ferramentas de administração com excelentes interfaces gráficas, o fato de o fluxo de dados ser criptografado faz com que o SQL Server tenha camadas de segurança robustas.
Logo SQL Server
MySQL
Lançado pela MySQL AB em 1994, o MySQL é um software de código aberto que utiliza o modelo cliente-servidor. Em 2008, a MySQL AB foi adquirida pela Sun Microsystems. Já em 2010 a Oracle comprou a Sun Microsystems e todos os seus produtos, incluindo o MySQL. Parte do sucesso e popularidade desse SGBD se deve ao fato de que muitas empresas de tecnologia gigantes utilizam seus serviços, como o YouTube, Facebook, Twitter, Netflix, entre muitas outras. Outra vantagem é ser multiplataforma, ou seja, possui suporte para diferentes sistemas operacionais (Windows, Linux e MacOS).
Logo MySQL
PostgreSQL
O POSTGRES surgiu em 1986 no Departamento de Ciências da Computação de Berkeley, da Universidade da Califórnia. Em 1996, o projeto POSTGRES foi renomeado para PostgreSQL com o intuito de ilustrar seu suporte para SQL, no entanto, PostgreSQL é comumente chamado de Postgres atualmente. O PostgreSQL é um projeto open source coordenado pelo PostgreSQL Global Development Group.
Algumas das grandes vantagens desse SGBD são a estabilidade, robustez de recursos e desempenho, características apoiadas por mais de 20 anos de desenvolvimento pela comunidade de código aberto. O PostgreSQL também apresenta um bom índice de escalabilidade e se destaca pela proporção de funcionalidades avançadas, como por exemplo a possibilidade de suportar recursos ligados ao NoSQL e a aceitação de variados modelos de dados, como XML e JSON. Também possui suporte para diferentes plataformas, como Windows, Linux, MacOS, BSD e Solaris.
Muitas empresas construíram aplicações e soluções utilizando o PostgreSQL. Algumas empresas em destaque são Apple, Fujitsu, Cisco, Juniper Network, Instagram, entre outras.
Logo PostgreSQL
MongoDB
Seu desenvolvimento começou em 2007 pela 10gen, atual MongoDB Inc., e sua primeira versão pública foi lançada em 2009. O MongoDB é um sistema de gerenciamento de bancos de dados não-relacionais (NoSQL) de código aberto, alta performance, sem esquemas, orientado a documentos e escrito na linguagem de programação C++, tornando-o portável para diferentes sistemas operacionais (MacOS, Linux e Windows). No MongoDB, os dados são armazenados no formato BSON (Binary JSON) ou JSON e a linguagem de programação Javascript pode ser utilizada em consultas no banco de dados.
Logo MongoDB
Áreas de trabalho
Profissionais que trabalham na área de banco de dados enfrentam diversas dificuldades: gerenciamento da absorção de grandes quantidades de dados sem sobrecarregar o sistema; preocupações com a segurança e vulnerabilidade dos dados; manutenção da base de dados de forma funcional em relação à demanda exigida; escalabilidade da capacidade do banco de dados para acomodar o crescimento do mesmo; entre outros. Por ser uma área muito vasta, torna-se possível trabalhar em diferentes frentes:
Administrador de Banco de Dados (DBA): responsável pela administração e suporte dos SGBDs, sempre garantindo segurança, disponibilidade e eficiência à base de dados.
Pessoa Engenheira de Dados: responsável por coletar, armazenar e distribuir os dados. Além disso, desenvolver pipelines, que transformam os dados brutos em informações úteis para análise, e mantê-las em execução.
Pessoa Desenvolvedora SQL: responsável por desenvolver, refatorar e realizar manutenção em consultas e objetos do banco de dados utilizando a linguagem SQL.
Analista de Business Intelligence (BI): responsável por realizar a modelagem de novos negócios e dar suporte a tomada de decisões após análise de dados.
No mercado existem variações tanto das nomenclaturas dadas aos cargos quanto nas funções desempenhadas por cada cargo. Inclusive, em empresas menores é comum que algumas dessas funções apresentadas acima sejam de responsabilidade de um único cargo.
Conclusão – Banco de dados
Desde suas primeiras versões criadas em 1960, os bancos de dados têm evoluído continuamente e rapidamente. Atualmente, os bancos de dados estão por trás de diversos softwares que são vastamente utilizados, desde redes sociais e serviços de streaming até caixas eletrônicos e sistemas de IOT.
Com o avanço da internet e o crescente uso de aplicativos para diversas finalidades, a quantidade de dados que geramos cresce cada vez mais rápido. Logo, crescem também todas as áreas da tecnologia voltadas para armazenamento e gerenciamento de dados.
Para escolher com qual banco de dados trabalhar é preciso entender qual é a demanda do seu negócio e como seus dados podem ser estruturados. Só então é possível identificar o banco de dados e o SGBD que mais se alinham com o ritmo e volume do fluxo de dados do seu projeto.
Graduada em Engenharia Elétrica pela Universidade Federal de Campina Grande (UFCG), com ênfase em Controle e Automação. Desenvolvedora Python na Aquarela Analytics, com foco na construção de APIs. Na área de Engenharia de Dados trabalha com modelagem de dados, e com a criação e estruturação de ETLs. Entusiasta na área de Machine Learning e Ciência de Dados.
Teste de software é um processo sistemático e metódico de avaliar se o software desenvolvido atende aos requisitos esperados, garantindo que o produto esteja livre de defeitos. A realização desses testes envolve a execução de componentes do software utilizando ferramentas manuais ou automatizadas com o intuito de avaliar propriedades de interesse. O software devidamente testado garante confiabilidade, segurança e alto desempenho, resultando em economia de tempo e dinheiro e maior satisfação do cliente.
Os primeiros testes de software apareceram junto ao desenvolvimento de software, que teve seu início logo após a segunda guerra mundial. O cientista da computação, Tom Kilburn, escreveu o primeiro software, que estreou em 21 de junho de 1948, na Universidade de Manchester, na Inglaterra. Ele executou cálculos matemáticos usando instruções de código de máquina. Nessa época, a depuração era o principal método de teste e ainda permaneceu nas duas décadas seguintes. Contudo, na década de 1980, as equipes de desenvolvimento passaram a testar aplicativos em configurações do mundo real. Isso proporcionou uma visão mais ampla dos testes de software, que englobava o processo de garantia de qualidade e fazia parte do ciclo de vida do desenvolvimento de software.
Um dos motivadores por trás do impulso para as metodologias de desenvolvimento ágil é permitir que o teste seja incorporado ao longo da construção do software. Diante disso, a realização de teste de software desde o início da construção do projeto permite detectar bugs ou erros antecipadamente. Assim, torna-sesendo possível resolvê-los antes da entrega do produto final.
Quais são os benefícios do teste de software?
Uma das vantagens mais importantes dos testes de software é o custo-benefício. Realizando os testes durante todo o desenvolvimento do software, é possível detectar os erros na medida em que eles são criados e quanto mais rápido um problema for detectado, menos custará para consertá-lo. Outro benefício é a maior segurança, visto que os testes ajudam a remover riscos e vulnerabilidades.
Atrasos na entrega ou defeitos de software podem prejudicar bastante a reputação de uma marca e frustrar o público-alvo. Em casos extremos, um bug ou defeito pode degradar os sistemas interconectados ou causar sérios problemas de funcionamento. Logo, os testes também permitem que um software de qualidade seja entregue aos clientes, implicando na satisfação do usuário. Além disso, ao observar artifícios de design e de interações homem-máquina, os testes de UI/UX Design garantem uma melhor experiência, trazendo a sensação de conforto a quem utiliza. Veja mais sobre UX Design aqui.
Exemplos de falhas de software
Infelizmente, falhas de software são muito comuns. Algumas podem causar grandes perdas econômicas e outras podem até trazer risco à vida das pessoas.
– Em 26 de Abril de 1994, o Airbus A300 da China Airlines caiu devido a um bug de software, matando 264 pessoas.
– Em 2017, o streaming HBO Go atraiu muitos fãs de Game of Thrones com o lançamento da sétima e última temporada da série. No entanto, na estreia da série a plataforma online do canal a cabo ficou completamente inacessível durante várias horas, frustrando bastante os usuários. A HBO afirmou que a alta demanda de usuários se preparando para a estreia foi responsável pelos problemas de conexão no serviço, derrubando completamente a plataforma.
– A Nissan fez um recall de mais de 1 milhão de carros do mercado devido a uma falha de software nos detectores sensoriais de airbag. Foram relatados dois acidentes ocasionados por essa falha de software.
– Em abril de 1999, um bug de software causou o fracasso de um lançamento de satélite militar de U$ 1,2 bilhão, um dos acidentes mais caros da história. A falha desencadeou uma revisão militar e industrial completa dos programas de lançamento espacial dos EUA, incluindo integração de software e processos de teste.
– Em 2020, o esperado jogo Cyberpunk 2077, da CD Projekt, ficou bastante marcado no ramo dos games. Contudo, a antecipação do lançamento passou por diversos erros despercebidos pela equipe de desenvolvimento, sendo considerado uma decepção pelos fãs. Isso causou um prejuízo para a empresa, que tinha um jogo promissor em mãos.
Boas práticas
Bem como na medicina ou na engenharia, o desenvolvedor possui grande responsabilidade com a qualidade do código, pois pode afetar toda a reputação de uma empresa, além de culminar em um prejuízo econômico exorbitante. Desse modo, é necessário algumas medidas providenciais para que se assegure uma qualidade de código bem definida.
Suponha que uma montadora de veículos multinacional necessite reconstruir todo um lote de carros porque um sensor está desregulado, gerando uma insatisfação dos seus clientes e ocasionando um prejuízo bilionário, ou um software de machine learningaplicado na neurociência, que possa falhar e causar um dano vital. Todos esses casos podem ser solucionados com boas práticas e testes eficientes em seu desenvolvimento, que possam salvar milhões de dólares ou milhares de vidas. Diante disso, podemos citar algumas dessas boas práticas:
Testes de continuidade: São testes contínuos que vão sendo realizados à medida que a aplicação vai sendo construída. Realizados no desenvolvimento das aplicações para validação e critério de aceitação, diminuindo significativamente os possíveis erros e evitando riscos iminentes durante o processo de implementação no deploy.
Gerenciamento de configurações: As equipes possuem acesso à assets, tais como código, modelos, scripts e resultados de testes. Diante disso, é inerente de boas aplicações a autenticação de usuário e trilhas de auditoria. A finalidade disso consiste em auxiliar as equipes a atender aos requisitos de conformidade com o menor esforço administrativo possível.
Virtualização dos serviços: Ao início do processo de construção de uma aplicação, é evidente que não há ambientes de teste ainda. Desse modo, deve-se utilizar ambientes virtualizados para simular os serviços que não foram finalizados, permitindo a realização de testes antecipadamente. Ademais, abre a possibilidade de modificação para fins de testes sem que afete o ambiente original.
Detecção de falhas: A detecção de bugs e problemas devem ser realizadas o mais rápido possível e é de extrema importância que não sejam aplicados no deploy. Portanto, ferramentas de automação de testes devem ser aplicadas para que sejam realizadas diversas sessões de testes para descobrir falhas que não estão tão evidentes, mas que possam ser de suma importância.
Métricas e relatórios: As análises dos desenvolvedores são essenciais para um bom desenvolvimento e comunicação da equipe, portanto tudo o que é realizado deve ser documentado e estar alinhado. Para isso, pode-se aplicar algumas técnicas de gerenciamento e padronização. Desse modo, o ambiente cooperativo entra em ação para solucionar problemas e evitar retrabalho.
Sabendo que não é possível testar tudo, como decidir quando parar de testar?
Dois fatos devem ser considerados para decidir quantos testes devemos realizar, sendo eles: o fato de que todo sistema está sujeito a algum tipo de risco; e que existe um nível de qualidade aceitável para cada sistema.
A priorização é o aspecto mais importante para alcançar um resultado aceitável de uma quantidade finita e limitada de teste. Primeiramente, realize os testes mais importantes para que, se a qualquer momento as atividades de teste forem reduzidas, você possa ter certeza de que os testes prioritários já foram feitos. Esses testes serão os relacionados aos aspectos essenciais do sistema. Isso significa que eles vão testar as funções mais importantes, conforme os requisitos dos usuários e o comportamento não funcional mais relevante para o projeto. Além disso, eles abordarão os riscos mais significativos.
O próximo aspecto é conhecido como critério de conclusão e define os padrões para a atividade de teste. Por exemplo, ele define quanto do software deve ser testado e quais níveis de defeitos podem ser tolerados em um produto que será entregue. Ou seja, devem ser definidos critérios que indiquem se e quando é seguro interromper os testes, de modo que o tempo e outras pressões não interfiram no resultado final.
Prioridades e critérios de conclusão fornecem uma base para o planejamento de testes. No fim, os níveis desejados de qualidade e risco podem ser comprometidos. Porém, utilizando os dois fatores apresentados, podemos garantir que ainda seja possível determinar quantos testes serão necessários para atingir os níveis acordados.
Teste de software – Conclusão
Embora o processo de teste de software seja financeiramente custoso, as empresas conseguem economizar muito em desenvolvimento e suporte se implementarem boas técnicas de testes e processos de controle de qualidade. Utilizar os testes de software desde o início do processo de desenvolvimento possibilita que o produto vá para o mercado com menos falhas. Além disso, quanto antes as equipes de desenvolvimento receberem os resultados dos testes, mais rapidamente eles poderão solucionar problemas, tais como: falhas na arquitetura do projeto, vulnerabilidades do sistema, problemas de escalabilidade, funcionalidades inválidas ou incorretas, entre outros.
Quando a equipe de desenvolvimento permite um amplo espaço para testes no projeto, consequentemente a confiabilidade do software é amplificada e aplicativos de alta qualidade são entregues aos consumidores. Assim, ao atender as expectativas do usuário ou até mesmo excedê-la, o produto ganha mais visibilidade e maior participação no mercado.
Graduada em Engenharia Elétrica pela Universidade Federal de Campina Grande (UFCG), com ênfase em Controle e Automação. Desenvolvedora Python na Aquarela Analytics, com foco na construção de APIs. Na área de Engenharia de Dados trabalha com modelagem de dados, e com a criação e estruturação de ETLs. Entusiasta na área de Machine Learning e Ciência de Dados.
Python Developer na Aquarela Advanced Analytics. Graduando em Engenharia Elétrica pela UFCG. Entusiasta em automação, possui experiência em Engenharia de Software e utilizando Python (ROS e OpenCV), C/C++, JavaScript (NodeJS), TypeScript (NestJS). Experiência com metodologia ágil com uso do SCRUM como Scrum Master. Possui grande interesse em Machine Learning, IoT e Ciência de Dados.
