Identificación de patrones de acceso para la aplicación
Al diseñar un modelo de datos para una base de datos NoSQL, el objetivo es asegurarse de que las operaciones en los datos se realizan en el menor número de solicitudes. Para ello, debe comprender las relaciones entre los datos y cómo la aplicación accederá a ellos. Estos patrones de acceso son importantes porque, junto con las relaciones, determinarán cómo las propiedades de las distintas entidades se agrupan y se almacenan en documentos dentro de contenedores en las bases de datos de Azure Cosmos DB for NoSQL.
En Azure Cosmos DB for NoSQL, los documentos se denominan "elementos" y los contenedores a menudo se conocen como "colecciones".
Identificación de patrones de acceso para entidades de cliente
Empecemos con las entidades de cliente en nuestra base de datos de comercio electrónico. En el diagrama siguiente se muestran tres entidades y las relaciones entre ellas. Las tres entidades son Customer, CustomerAddress y CustomerPassword. La entidad Customer tiene una relación de 1 a varios con CustomerAddress. Customer tiene una relación 1 a 1 con CustomerPassword.
En nuestra aplicación, realizaremos tres operaciones sobre las entidades de cliente:
- Crear un cliente: cuando un nuevo usuario visita por primera vez el sitio de comercio electrónico, se crea un nuevo cliente.
- Actualizar un cliente: cuando un usuario existente actualiza su información de perfil, se actualizará su registro de cliente.
- Recuperar un cliente: cuando un usuario existente visita el sitio, inicia sesión con su contraseña. Durante esa misma sesión, tendrá que acceder a otros datos del cliente (como la dirección) para comprar nuevos artículos.
Para cada una de estas operaciones, necesitamos todos estos datos al mismo tiempo. Estas entidades se podrían modelar como documentos independientes, pero serían necesarios varios recorridos de ida y vuelta al servidor para crear, actualizar y recuperar los datos del cliente.
Modelado de entidades de cliente
Azure Cosmos DB almacena datos como JSON, por lo que podemos modelar la relación de 1 a varios entre Customer y CustomerAddress e insertar los datos de dirección del cliente como matriz. En el caso de la relación de 1 a 1 entre Customer y CustomerPassword, podemos insertarlos como objeto en nuestro nuevo documento de cliente único. A continuación, la aplicación de comercio electrónico puede crear, editar o recuperar datos de cliente en una sola solicitud.
En el diagrama siguiente se muestra el aspecto de nuestra entidad de cliente.
