• Português
  • English
  • Español
  • Escolhendo o seu Banco de Dados

    Por: em 24 de novembro de 2017

    Em Ciências da Computação, frequentemente nos deparamos com situações nas quais é preciso definir um modelo para representar ou armazenar dados, uma abstração. Essas representações acabam se tornando bastante importantes, uma vez que impactam a maneira como pensamos os problemas que tentamos resolver e a forma como o software é escrito. Dependendo da aplicação, podem, inclusive, existir múltiplas camadas de abstração, cada uma utilizando seus próprios modelos. Essas abstrações tornam mais fácil o trabalho conjunto de pessoas com atribuições e formações diferentes que precisam lidar com um mesmo sistema, possibilitando que cada um represente o mesmo conceito de maneiras diferentes, de acordo com as características de cada camada. Cada representação carrega consigo, portanto, um conjunto de premissas sobre como os dados serão usados, o que pode tanto facilitar como limitar determinados usos dos mesmos. Diante disso, fica claro que a escolha do tipo de banco de dados utilizado em um sistema é uma escolha muito mais importante do que se pode presumir inicialmente. Neste artigo, serão abordadas duas das principais representações/modelos de dados utilizados por bancos de dados, e os principais aspectos aos quais deve-se estar atento ao optar por um modelo ou outro.

     

    Relacional x NoSQL Bancos Orientados a Documentos

    Bancos de dados relacionais reinaram soberanos por cerca de três décadas, até verem seu império ameaçado pelo crescimento de modelos alternativos. Em bancos relacionais, os dados são organizados em relações, também chamadas de tabelas, e cada relação é composta por coleções de tuplas. Esse tipo de banco de dados, em geral, usa a linguagem SQL para a realização de consultas, através da qual descrevem-se as características dos dados que deseja-se recuperar, como quais campos, obedecendo a quais condições e utilizando quais formas de ordenação e agregação. Já NoSQL, sigla para Não só SQL, refere-se a qualquer outra forma de representação dos dados que difira do tradicional modelo relacional. Os bancos de dados NoSQL ganharam força principalmente desde 2010, e entre os motivos para a sua adoção podemos citar: 1) a demanda por maior escalabilidade, com conjuntos de dados cada vez maiores; 2) a necessidade de realizar consultas especializadas, como buscas em dados geolocalizados, muitas vezes não suficientemente bem suportadas em bancos relacionais; e 3) a busca por um modelo de representação mais dinâmico, mais expressivo e menos restritivo.

    A seguir abordaremos algumas das principais considerações com relação às vantagens e limitações do modelo relacional em comparação a um tipo específico de banco NoSQL, os bancos de dados orientados a documentos. Outros tipos de bancos NoSQL não serão abordados por brevidade.

     

    Incompatibilidade Objeto-Relacional

    A maior parte das aplicações desenvolvidas atualmente utiliza linguagens de programação orientadas a objeto. Quando utiliza-se um banco de dados relacional, os objetos, geralmente, não podem ser simplesmente escritos da maneira como existem na aplicação, precisando, antes, serem convertidos e compatibilizados com o formato de tuplas e tabelas do banco, tornando a aplicação mais complexa. A figura 1 apresenta um exemplo de representação de um currículo em um banco de dados relacional, toda a informação do currículo acaba ficando espalhada em diversas tabelas, que precisam ser associadas durante a recuperação da informação.

    Figura 1 – Um currículo é um exemplo de objeto que não é bem representado pelo modelo relacional (figura extraída de [1])

     

    Objetos como um currículo, que são bastante autocontidos, são geralmente melhor representados em bases de dados orientadas a documentos, utilizando formatos como o JSON. A figura 2 traz uma representação de como esses dados poderiam ser estruturados em um documento JSON, que guarda uma similaridade muito maior com a forma como o objeto currículo provavelmente seria representado em uma aplicação. Nota-se também que toda a informação relevante pode ser encontrada dentro de uma mesma estrutura, motivo pelo qual diz-se que JSON oferece melhor localidade, o que evita a realização de muitas junções. Além disso, as relações no currículo tendem a ser do tipo 1xN (um para muitos, da pessoa para cada item associado), o que implica uma estrutura em árvore que fica evidenciada na estrutura do JSON, e é bem modelada por esse tipo de representação.

    Figura 2 – As relações em um currículo são melhor modeladas através de uma estrutura similar a uma árvore, JSON serve bem esse propósito (figura extraída de [1])
     

    Relações Nx1 e NxN

    Relações Nx1 (muitos para 1) são comumente usadas em bancos de dados relacionais para associar entidades a identificadores únicos, dessa forma é possível ter diversas referências a uma única entidade, cuja representação é armazenada em um único local, evitando inconsistências, ambiguidades, duplicações desnecessárias e facilitando o processo de atualização, busca e internacionalização. Esse tipo de relação é muito bem modelado em um banco de dados relacional, onde as entidades podem ser escritas em uma tabela e consultadas através de junções utilizando os seus identificadores. Em bancos de dados orientados a documentos o suporte a junções tende a ser limitado, o que requer que essa operação seja feita através do código da aplicação, tornando-o mais complexo.

    É importante considerar também que, mesmo que inicialmente um sistema só possua relações do tipo 1xN, com a evolução do mesmo, os dados podem se tornar mais complexos e novas relações podem surgir. No caso do currículo, por exemplo, inicialmente pode-se ter apenas a relação entre a pessoa e seus empregos, mas futuramente pode-se enxergar valor em representar empresas como entidades e empregos como relações entre pessoas e empresas, dando origem a relacionamentos do tipo NxN, que também são melhor representados no modelo relacional.

     

    Wrapping Up

    O modelo de representação dos dados que resulta no código de aplicação mais simples depende do tipo de relacionamento que existe entre as entidades representadas. Se todos os relacionamentos são do tipo 1xN, os relacionamentos possuem uma estrutura similar a uma árvore, que é muito bem modelada através de um documento, enquanto uma representação relacional pode se tornar demasiadamente complexa. Por outro lado, relações do tipo Nx1 e NxN tendem a ser melhor modeladas em um banco de dados relacional, que oferece melhor suporte a junções e, possivelmente, um código de aplicação mais enxuto.

    Outro ponto importante diz respeito a quão restritiva é a representação. Bancos de dados relacionais tendem a demandar a definição de um esquema ao qual todos os dados inseridos devem obedecer (schema-on-write), enquanto bancos de dados orientados a documento tendem a não forçar o uso de esquemas, permitindo a escrita de qualquer campo livremente dentro de um documento (schema-on-read). No entanto, de maneira geral, quando o esquema não é forçado, ele acaba sendo implicitamente representado através do código da aplicação, que é criado carregando diversas premissas sobre o formato dos dados, o que pode resultar em um código mais complexo e suscetível a erros decorrentes de dados inseridos em um formato não previsto. De maneira geral, não forçar um esquema tem mais apelo quanto mais heterogêneos são seus dados.

    A questão da localidade dos dados também pode esconder algumas armadilhas. Essa vantagem que os bancos orientados a documento podem ter geralmente só se aplica se em cada consulta, a maior parte do documento é acessada, uma vez que, mesmo que só haja interesse em apenas um atributo, o documento todo tende a ser carregado. O mesmo problema tende a ocorrer na escrita. Essas características, no entanto, dependem da implementação do banco específico utilizado.

    Por fim, vale considerar que cada modelo de representação e cada banco é acompanhado por sua linguagem de consulta e os frameworks que o suportam, e pode ser importante também avaliá-los.

     

    Referências

    [1] M. Kleppmann. Designing Data-Intensive Applications. O’Reilly Media, 2017

    24 de novembro de 2017

    Filtre por mês

    Filtre por autor