Em meados da década de 1990, surgiu a noção de dados semi-estruturados para definir as propriedades dos dados envolvidos na Web e as novas aplicações que surgiram em torno dela (por exemplo, bancos de dados de genoma ou bancos de dados geográficos), bem como lidar com a integração de fontes de dados independentes e navegação de dados (ou seja, para escrever consultas de dados sem conhecimento do esquema) (ABITEBOUL, 1996;
ABITEBOUL; BUNEMAN; SUCIU, 2000;BUNEMAN, 1997).
Os dados semi-estruturados são caracterizados principalmente pelo fato de sua es- trutura não estar definida em um esquema separado, mas está implícita nos próprios dados. Geralmente, os dados semi-estruturados são descritos como uma tupla de pares
𝐶ℎ𝑎𝑣𝑒 − 𝑉 𝑎𝑙𝑜𝑟. Chaves (campos e tags) denotam propriedades ou atributos dos dados, e
os valores podem ser primitivos (isto é, valores atômicos de tipos como números, cadeias de caracteres e booleanos) ou complexos (por exemplo, arrays).
Dados semi-estruturados também possuem uma estrutura hierárquica (ou seja, es- trutura aninhada) com um atributo raiz (ou pai) que pode incluir outros atributos ani- nhados.Vale a pena notar que os dados semi-estruturados representam um formato para expressar objetos incorporados ou agregados, mas sem a necessidade de definição prévia de um esquema.
Como indicado em (BUNEMAN, 1997), uma parte dos dados semi-estruturados pode ser formalizada com estruturas semelhantes a um grafo ou uma árvore. Se referências entre partes de dados são permitidas, a estrutura seria um grafo. Uma representação em grafo pode incluir nós de folha rotulados com dados significativos (valores atômicos) e arestas intermediárias rotuladas com símbolos que denotem os nomes dos atributos. Um nó raiz ou intermediário tem um nó filho para cada campo de objeto associado (aninhado).
A criação de dados em tempo de execução e persistentes geralmente requer a existência de uma especificação de sua estrutura. Por exemplo, objetos são instanciados de classes (ou seja, tipos) durante a execução de programas orientados a objeto, e um esquema deve ser definido antes de armazenar dados em um banco de dados relacional. No entanto, os dados semi-estruturados podem ser criados diretamente, porque incluem informações que descrevem sua estrutura. Por este motivo, estes tipos de dados são comumente caracte- rizados como "sem esquema fixo/rígido"e "auto-descritivo", pois as informações sobre a estrutura estão dentro dos dados mas nenhum esquema ou tipos foram definidos previa- mente em uma especificação separada dos dados.
A falta de esquemas explicitamente definidos (sem esquema) oferece alguns benefícios significativos aos desenvolvedores de aplicativos de banco de dados, como observado em
(ABITEBOUL, 1996;SADALAGE; FOWLER, 2012). Em particular, essa característica facilita a evolução dos dados e o uso de dados não uniformizados.
Evolução dos dados - A estrutura dos dados pode evoluir com frequência, pois alterações de esquema não são necessárias. Dados com a nova estrutura podem ser armazenados sem qualquer tipo de restrição. Em sistemas relacionais, a evolução dos dados requer a mudança do esquema e algum tipo de migração de dados.
Estrutura variada - Um dos principais pontos fortes dos dados semi-estruturados é permitir a variação da estrutura em dados do mesmo tipo. Por exemplo, uma propriedade pode ter valores de tipos diferentes ou pode ser opcional. Essas variações geralmente impactam em pequenas alterações na representação.
Embora a ausência de esquema forneça uma maior flexibilidade no gerenciamento de dados, ela pode apresentar algumas desvantagens para desenvolvedores. Quando um es- quema é formalmente definido (por exemplo, um esquema relacional), é assegurado que somente os dados que se ajustam ao esquema podem ser manipulados no código do apli- cativo, e os erros cometidos pelos desenvolvedores ao escrever o código são previamente identificados. Esta é a mesma analogia das linguagens estáticas e dinâmicas, que é comu- mente usada para observar a diferença entre dados semi-estruturados e dados que estão de acordo com um esquema rígido pré-definido (BUNEMAN, 1997). Quando um esquema não é pré-definido, erros como propriedades duplicadas ou ausentes não são capturados no momento em que os dados são criados.
A maioria dos bancos de dados NoSQL não tem esquema, por motivos como: (1) arma- zenam dados cuja estrutura está mudando rapidamente ou é tomada como desconhecida, e (2) o suporte ao desenvolvimento ágil é um dos principais requisitos que devem satisfazer. Novos domínios de aplicações nas quais é esperado que as estruturas de dados passem por mudanças rápidas, já foram identificados há vinte anos nos primeiros trabalhos sobre da- dos semi-estruturados (ABITEBOUL, 1996;BUNEMAN, 1997). O número dessas aplicações cresceu consideravelmente desde então.
XML tem sido o formato comumente usado para armazenar dados semi-estruturados a partir do advento da Web e sua adoção pelo World Wide Web Consortium (W3C) como um padrão para intercâmbio de dados na Web 6. No entanto, desde a aparição do JavaScript
Object Notation (JSON) no final da última década, o XML está perdendo predominância
como formato de intercâmbio de dados em favor do JSON (SEVILLA; FELICIANO; GARCíA- MOLINA, 2017). JSON é o formato usado para armazenar dados em alguns dos bancos de
dados NoSQL (MongoDB, por exemplo). Nestes, os dados são internamente codificados em algum formato de serialização binária, como o BSON 7. Mais detalhes sobre bases de dados NoSQL e o formato JSON serão apresentados a seguir.
6 https://www.w3.org/standards/xml/ 7 https://www.mongodb.com/json-and-bson
2.2.1
O Formato JSON
JSON8é um formato de texto amplamente utilizado para representar dados semi-estruturados. Essa notação está tomando o lugar do XML como formato de intercâmbio de dados devido a alguns benefícios como sua performance, simplicidade e facilidade de leitura (GOYAL; SINGH; RAMKUMAR, 2017). O JSON é um subconjunto da linguagem JavaScript, mais especificamente os dados JSON são literais JavaScript. Isso contribuiu significativamente para o sucesso do JSON. Existem dois padrões de JSON: ECMA e RFC7159. A principal diferença é que o ECMA considera qualquer valor JSON como um texto JSON válido e o RFC7159 estabelece que um texto JSON válido deve ter um objeto ou array como
root. O JSON é altamente interoperável porque os dados trocados são simplesmente texto
Unicode. A gramática do JSON especifica que um texto (também conhecido como do- cumento) pode ser (1) um objeto formado por um conjunto de pares de chave-valor ou (2) um array (ou seja, uma lista ordenada) de valores. O tipo de um valor JSON pode ser um tipo primitivo (Number, String ou Boolean), um objeto ou um array de valores.
null é usado para indicar que uma chave não tem valor. Esta gramática permite repre-
sentar dados na forma de estruturas aninhadas usando objetos e arrays como construções de composição. É importante observar que JSON é uma notação destinada a expressar dados semi-estruturados em forma de árvore e sem esquema.
Esquemas JSON - A iniciativa JSON Schema9 surgiu recentemente fornecendo espe- cificações para descrição de esquemas JSON. Embora sua adoção ainda seja muito limi- tada, algumas ferramentas (por exemplo, validadores, geradores de esquemas, geradores de documentação) evidenciaram a utilidade de se ter esquemas JSON. Como exemplo de especificações podemos citar a indicação do tipo JSON de cada campo. Para um campo que hospeda um objeto, os campos ("propriedades do objeto") são especificados. Para um campo Array, o tipo dos itens é especificado e as propriedades necessárias também são especificadas.