{"id":4508,"date":"2018-01-25T12:11:24","date_gmt":"2018-01-25T20:11:24","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=4508"},"modified":"2023-08-29T11:55:09","modified_gmt":"2023-08-29T18:55:09","slug":"json-data-modeling-rdbms-users","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/json-data-modeling-rdbms-users\/","title":{"rendered":"Modelagem de dados JSON para usu\u00e1rios de RDBMS"},"content":{"rendered":"
\n

A modelagem de dados JSON \u00e9 uma parte essencial do uso de um banco de dados de documentos como o Couchbase<\/a>. Al\u00e9m de entender os conceitos b\u00e1sicos de JSON, h\u00e1 duas abordagens principais para modelar relacionamentos entre dados que ser\u00e3o abordados nesta postagem do blog.<\/p>\n<\/div>\n

\n

Os exemplos nesta postagem ser\u00e3o baseados no exemplo de faturas que mostrei em Ferramenta CSV para migrar do Relacional para o Couchbase<\/a>.<\/p>\n<\/div>\n

\n

Atualiza\u00e7\u00e3o de dados importados<\/h2>\n
\n
\n

No exemplo anterior, comecei com duas tabelas de um banco de dados relacional: Invoices (faturas) e InvoicesItems (itens de faturas). Cada item de fatura pertence a uma fatura, o que \u00e9 feito com uma chave estrangeira em um banco de dados relacional.<\/p>\n<\/div>\n

\n

Fiz uma importa\u00e7\u00e3o muito simples (ing\u00eanua) desses dados para o Couchbase. Cada linha se tornou um documento em um bucket de \"prepara\u00e7\u00e3o\".<\/p>\n<\/div>\n

\n

\"Data<\/span><\/p>\n<\/div>\n

\n

Em seguida, precisamos decidir se esse design de modelagem de dados JSON \u00e9 adequado ou n\u00e3o (acho que n\u00e3o \u00e9, como se o balde chamado \"staging\" j\u00e1 n\u00e3o tivesse revelado isso).<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Duas abordagens para a modelagem de dados JSON de relacionamentos<\/h2>\n
\n
\n

Com um banco de dados relacional, h\u00e1 apenas uma abordagem: normalizar seus dados. Isso significa tabelas separadas com chaves estrangeiras que vinculam os dados entre si.<\/p>\n<\/div>\n

\n

Com um banco de dados de documentos, h\u00e1 duas abordagens. Voc\u00ea pode manter os dados normalizados ou pode desnormaliz\u00e1-los aninhando-os em seu documento pai.<\/p>\n<\/div>\n

\n

Normalizado (documentos separados)<\/h3>\n
\n

Um exemplo do estado final do normalizado<\/strong> representa uma \u00fanica fatura distribu\u00edda em v\u00e1rios documentos:<\/p>\n<\/div>\n

\n
\n
key - invoice::1\r\n{ \"BillTo\": \"Lynn Hess\", \"InvoiceDate\": \"2018-01-15 00:00:00.000\", \"InvoiceNum\": \"ABC123\", \"ShipTo\": \"Herman Trisler, 4189 Oak Drive\" }\r\n\r\nkey - invoiceitem::1811cfcc-05b6-4ace-a52a-be3aad24dc52\r\n{ \"InvoiceId\": \"1\", \"Price\": \"1000.00\", \"Product\": \"Brake Pad\", \"Quantity\": \"24\" }\r\n\r\nkey - invoiceitem::29109f4a-761f-49a6-9b0d-f448627d7148\r\n{ \"InvoiceId\": \"1\", \"Price\": \"10.00\", \"Product\": \"Steering Wheel\", \"Quantity\": \"5\" }\r\n\r\nkey - invoiceitem::bf9d3256-9c8a-4378-877d-2a563b163d45\r\n{ \"InvoiceId\": \"1\", \"Price\": \"20.00\", \"Product\": \"Tire\", \"Quantity\": \"2\" }<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Isso est\u00e1 alinhado com a importa\u00e7\u00e3o direta de CSV. O InvoiceId<\/code> em cada documento de item de fatura \u00e9 semelhante<\/em> O Couchbase \u00e9 um banco de dados de documentos distribu\u00eddo, mas observe que o Couchbase (e os bancos de dados de documentos distribu\u00eddos em geral) n\u00e3o imp\u00f5e esse relacionamento da mesma forma que os bancos de dados relacionais. Essa \u00e9 uma troca feita para satisfazer as necessidades de flexibilidade, escalabilidade e desempenho de um sistema distribu\u00eddo.<\/p>\n<\/div>\n
\n
Observe que, neste exemplo, os documentos \"filhos\" apontam para o pai por meio de InvoiceId<\/code>. Mas tamb\u00e9m poderia ser o contr\u00e1rio: o documento \"pai\" poderia conter uma matriz das chaves de cada documento \"filho\".<\/em><\/p>\n<\/div>\n<\/div>\n
\n
Desnormalizado (aninhado)<\/h3>\n
\n
O estado final do aninhado<\/strong> A abordagem de um documento \u00fanico para representar uma fatura.<\/p>\n<\/div>\n
\n
\n
key - invoice::1\r\n{\r\n  \"BillTo\": \"Lynn Hess\",\r\n  \"InvoiceDate\": \"2018-01-15 00:00:00.000\",\r\n  \"InvoiceNum\": \"ABC123\",\r\n  \"ShipTo\": \"Herman Trisler, 4189 Oak Drive\",\r\n  \"Items\": [\r\n    { \"Price\": \"1000.00\", \"Product\": \"Brake Pad\", \"Quantity\": \"24\" },\r\n    { \"Price\": \"10.00\", \"Product\": \"Steering Wheel\", \"Quantity\": \"5\" },\r\n    { \"Price\": \"20.00\", \"Product\": \"Tire\", \"Quantity\": \"2\" }\r\n  ]\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Observe que o \"InvoiceId\" n\u00e3o est\u00e1 mais presente nos objetos da tabela Itens<\/code> array. Esses dados n\u00e3o s\u00e3o mais estrangeiros - agora s\u00e3o nacionais -, portanto, esse campo n\u00e3o \u00e9 mais necess\u00e1rio.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Regras b\u00e1sicas de modelagem de dados JSON<\/h2>\n
\n
\n
Voc\u00ea j\u00e1 deve estar pensando que o segundo<\/em> \u00e9 uma op\u00e7\u00e3o natural nesse caso. Uma fatura nesse sistema \u00e9 uma op\u00e7\u00e3o natural raiz agregada<\/em><\/a>. No entanto, nem sempre \u00e9 simples e \u00f3bvio quando e como escolher entre essas duas abordagens em seu aplicativo.<\/p>\n<\/div>\n
\n
Aqui est\u00e3o algumas regras de ouro para saber quando escolher cada modelo:<\/p>\n<\/div>\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n
Tabela 1. Folha de consulta de dados de modelagem<\/caption>\n 
Se ...<\/th>\nEnt\u00e3o, considere...<\/th>\n<\/tr>\n<\/thead>\n
\n
O relacionamento \u00e9 de 1 para 1 ou de 1 para muitos<\/p>\n<\/td>\n
\n
Objetos aninhados<\/p>\n<\/td>\n<\/tr>\n
\n
O relacionamento \u00e9 de muitos para 1 ou de muitos para muitos<\/p>\n<\/td>\n
\n
Documentos separados<\/p>\n<\/td>\n<\/tr>\n
\n
As leituras de dados s\u00e3o, em sua maioria, campos pai<\/p>\n<\/td>\n
\n
Documento separado<\/p>\n<\/td>\n<\/tr>\n
\n
As leituras de dados s\u00e3o, em sua maioria, campos pai + filho<\/p>\n<\/td>\n
\n
Objetos aninhados<\/p>\n<\/td>\n<\/tr>\n
\n
As leituras de dados s\u00e3o, em sua maioria, parentais ou<\/em> filho (n\u00e3o ambos)<\/p>\n<\/td>\n
\n
Documentos separados<\/p>\n<\/td>\n<\/tr>\n
\n
As grava\u00e7\u00f5es de dados s\u00e3o, em sua maioria, pai e<\/em> crian\u00e7a (ambos)<\/p>\n<\/td>\n
\n
Objetos aninhados<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
Exemplo de modelagem<\/h3>\n
\n
Para explorar isso mais a fundo, vamos fazer algumas suposi\u00e7\u00f5es sobre o sistema de faturas que estamos criando.<\/p>\n<\/div>\n
\n