Descripción general del modelado de datos en Apache Cassandra

En este artículo aprenderemos sobre estos tres modelos de datos en Cassandra: conceptual, lógico y físico.

Objetivo de aprendizaje:

• Construir base de datos utilizando técnicas de diseño rápido en Cassandra.
• Para mejorar el modelo existente utilizando una metodología basada en consultas en Cassandra.
• Para optimizar el modelo existente a través de técnicas de análisis y validación en Cassandra.

Modelado de datos en Apache Cassandra :
en Apache Cassandra, el modelado de datos juega un papel vital para administrar una gran cantidad de datos con la metodología correcta. La metodología es un aspecto importante en Apache Cassandra. El modelado de datos describe la estrategia en Apache Cassandra.

1. Modelo de datos
conceptuales: el modelo conceptual es una vista abstracta de su dominio. Es independiente de la tecnología. El modelo conceptual no es específico de ningún sistema de base de datos.

Objetivo:

• Para comprender los datos que son aplicables para el modelado de datos.
• Para definir objetos esenciales.
• Para definir restricciones aplicables al modelado de datos.

Las ventajas del modelado conceptual de datos en Cassandra es la colaboración.

Modelo de entidad-relación (ER):
el diagrama ER representará una vista abstracta del modelo de datos y dará una vista pictórica. El diagrama ER simplificó el modelo de datos. Por ejemplo, tomemos un ejemplo donde la cardinalidad m:n en la que la relación de muchos a muchos entre el estudiante y el curso significa que muchos estudiantes pueden inscribirse en muchos cursos y muchos estudiantes inscriben muchos cursos.

Figura – Diagrama ER para modelo conceptual en Cassandra con cardinalidad M:N

En este ejemplo, s_id, s_name, s_course, s_branch es un atributo de la Entidad del estudiante y p_id, p_name, p_head es un atributo de la Entidad del proyecto y ‘inscrito en’ es una relación en el registro del estudiante. Así es como convertiremos el diagrama ER en un modelo de datos conceptual.

Student(S_id, S_name, S_branch, S_course)
Project(P_id, P_name, P_head)
enrolled in(S_id, P_id, S_name)

Flujo de trabajo de la aplicación:
en cada aplicación hay un flujo de trabajo en el que la tarea y las dependencias, de modo que en la aplicación, el número de estudiantes que desea inscribirse para muchos proyectos.

Figura: diagrama de flujo del modelo de datos

Este es el diagrama de flujo del modelo de datos real de DataStax.

2. Modelo de datos lógicos:
en el modelo de datos lógicos, definiremos cada atributo, campo o columna con una funcionalidad tal que S_id es una partición clave en la Entidad del estudiante y P_id es una clave de partición en la Entidad del proyecto. La clave de partición juega un papel vital en Cassandra en el que podemos ejecutar la consulta en consecuencia. En Cassandra, la clave de partición es útil cuando ejecutaremos la consulta CQL y también en la indexación. Por ejemplo, en la base de datos relacional esta consulta funcionaría pero en Cassandra no funcionaría así.

Select * 
From student_data 
Where S_branch = 'CSE'; 

Porque, en Cassandra S_branch no es parte de la clave de partición de la tabla, primero definió la clave de partición para este tipo de consulta en Cassandra.

Select * 
From student_data 
Where S_id = '123'; 

Esta consulta funcionaría bien en Cassandra.

Figura –

3. Modelo de datos físicos:
en este modelo de datos describiremos la consulta de la tabla y escribiremos la consulta para construir la tabla y este es uno de los modelos de datos reales donde necesitamos escribir la consulta específicamente requerida e implementar la funcionalidad de la base de datos que realmente queremos. Por ejemplo, definamos la tabla una por una para la base de datos student_record mediante la consulta CQL.

Mesa: Estudiante

CREATE TABLE student_record.student
 ( 
  S_id int,
  S_name text,
  S_branch,
  S_course,
  PRIMARY KEY((S_id), S_name),
 );

Tabla: Proyecto

CREATE TABLE student_record.Project
 ( 
  P_id int,
  P_name text,
  P_head,
  PRIMARY KEY(P_id),
 ); 

Tabla: Inscrito_en

CREATE TABLE student_record.Enrolled_in
 ( 
  S_id int,
  P_id int,
  S_name text,
  PRIMARY KEY((S_id, P_id), S_name)),
 );