{"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\/es\/json-data-modeling-rdbms-users\/","title":{"rendered":"Modelado de datos JSON para usuarios de RDBMS"},"content":{"rendered":"
\n

El modelado de datos JSON es una parte vital del uso de una base de datos de documentos como Couchbase<\/a>. M\u00e1s all\u00e1 de la comprensi\u00f3n de los conceptos b\u00e1sicos de JSON, hay dos enfoques clave para modelar las relaciones entre los datos que ser\u00e1n cubiertos en esta entrada del blog.<\/p>\n<\/div>\n

\n

Los ejemplos de este post se basar\u00e1n en el ejemplo de facturas que mostr\u00e9 en Herramientas CSV para migrar a Couchbase desde una base relacional<\/a>.<\/p>\n<\/div>\n

\n

Actualizaci\u00f3n de datos importados<\/h2>\n
\n
\n

En el ejemplo anterior, part\u00ed de dos tablas de una base de datos relacional: Facturas e InvoicesItems. Cada partida de factura pertenece a una factura, lo que se hace con una clave ajena en una base de datos relacional.<\/p>\n<\/div>\n

\n

Hice una importaci\u00f3n muy directa (ingenua) de estos datos a Couchbase. Cada fila se convirti\u00f3 en un documento en un bucket \"staging\".<\/p>\n<\/div>\n

\n

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

\n

A continuaci\u00f3n, debemos decidir si ese dise\u00f1o de modelado de datos JSON es apropiado o no (no creo que lo sea, como si el hecho de que el cubo se llame \"staging\" no lo delatara ya).<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Dos enfoques para el modelado de datos JSON de relaciones<\/h2>\n
\n
\n

Con una base de datos relacional, s\u00f3lo hay una soluci\u00f3n: normalizar los datos. Esto significa tablas separadas con claves externas que unan los datos.<\/p>\n<\/div>\n

\n

Con una base de datos de documentos, hay dos enfoques. Puede mantener los datos normalizados o puede desnormalizar los datos anid\u00e1ndolos en su documento padre.<\/p>\n<\/div>\n

\n

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

Un ejemplo del estado final del normalizado<\/strong> representa una \u00fanica factura repartida en varios 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
Esto coincide con la importaci\u00f3n directa de CSV. En InvoiceId<\/code> de cada documento de factura es similar<\/em> a la idea de una clave for\u00e1nea, pero ten en cuenta que Couchbase (y las bases de datos de documentos distribuidas en general) no imponen esta relaci\u00f3n de la misma manera que las bases de datos relacionales. Este es un compromiso hecho para satisfacer las necesidades de flexibilidad, escalabilidad y rendimiento de un sistema distribuido.<\/p>\n<\/div>\n
\n
Tenga en cuenta que, en este ejemplo, los documentos \"hijos\" apuntan al padre a trav\u00e9s de InvoiceId<\/code>. Pero tambi\u00e9n podr\u00eda ser al rev\u00e9s: el documento \"padre\" podr\u00eda contener una matriz con las claves de cada documento \"hijo\".<\/em><\/p>\n<\/div>\n<\/div>\n
\n
Desnormalizado (anidado)<\/h3>\n
\n
El estado final del anidado<\/strong> se utilizar\u00eda un \u00fanico documento para representar una factura.<\/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
Tenga en cuenta que \"InvoiceId\" ya no est\u00e1 presente en los objetos de la carpeta Art\u00edculos<\/code> array. Estos datos ya no son extranjeros, ahora son nacionales, por lo que ese campo ya no es necesario.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Reglas b\u00e1sicas del modelado de datos JSON<\/h2>\n
\n
\n
Puede que ya est\u00e9 pensando que el segundo<\/em> es una opci\u00f3n natural en este caso. Una factura en este sistema es una ra\u00edz agregada<\/em><\/a>. Sin embargo, no siempre es sencillo y obvio cu\u00e1ndo y c\u00f3mo elegir entre estos dos enfoques en su aplicaci\u00f3n.<\/p>\n<\/div>\n
\n
He aqu\u00ed algunas reglas generales sobre cu\u00e1ndo elegir cada modelo:<\/p>\n<\/div>\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n
Tabla 1. Ficha de datos de modelizaci\u00f3n<\/caption>\n 
Si...<\/th>\nEntonces considera...<\/th>\n<\/tr>\n<\/thead>\n
\n
La relaci\u00f3n es de 1 a 1 o de 1 a muchos<\/p>\n<\/td>\n
\n
Objetos anidados<\/p>\n<\/td>\n<\/tr>\n
\n
La relaci\u00f3n es muchos-a-1 o muchos-a-muchos<\/p>\n<\/td>\n
\n
Documentos separados<\/p>\n<\/td>\n<\/tr>\n
\n
Los datos le\u00eddos son en su mayor\u00eda campos padre<\/p>\n<\/td>\n
\n
Documento aparte<\/p>\n<\/td>\n<\/tr>\n
\n
Los datos le\u00eddos son en su mayor\u00eda campos padre + hijo<\/p>\n<\/td>\n
\n
Objetos anidados<\/p>\n<\/td>\n<\/tr>\n
\n
Las lecturas de datos son en su mayor\u00eda parentales o<\/em> ni\u00f1o (no ambos)<\/p>\n<\/td>\n
\n
Documentos separados<\/p>\n<\/td>\n<\/tr>\n
\n
Las escrituras de datos son en su mayor\u00eda de los padres y<\/em> ni\u00f1o (ambos)<\/p>\n<\/td>\n
\n
Objetos anidados<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
Ejemplo de modelizaci\u00f3n<\/h3>\n
\n
Para profundizar en este tema, hagamos algunas suposiciones sobre el sistema de facturaci\u00f3n que estamos construyendo.<\/p>\n<\/div>\n
\n