Diferencias entre los modelos de datos

Existen diferentes tipos de modelos de datos, cada uno con un propósito específico. Me gusta compararlos con las etapas de planificación al construir una casa, ya que estas etapas representan de manera visual cómo se desarrolla el modelado de datos y su aplicación en proyectos de cualquier escala.

  1. Modelo conceptual: Este modelo es como el boceto inicial de una casa. Es un esquema general que muestra la idea principal de lo que se quiere construir, sin preocuparse por los detalles. En este nivel, me enfoco en identificar las entidades principales que formarán parte del sistema. Por ejemplo, en un modelo conceptual para un comercio electrónico, consideraría entidades como productos, clientes y pedidos. El objetivo no es definir cada atributo o relación, sino obtener una comprensión global de la estructura de los datos y cómo podrían interactuar entre sí.

    Este modelo también es ideal para comunicar la idea del proyecto a quienes no están directamente involucrados en el desarrollo técnico, ya que no requiere conocimientos profundos sobre bases de datos. Es más, al enfocarse únicamente en los aspectos generales, se evitan malentendidos que podrían surgir al entrar demasiado en los detalles.

  2. Modelo lógico: Este modelo es como el plano detallado de la casa, donde ya empiezo a especificar elementos como las dimensiones de las habitaciones, las posiciones de las ventanas y las puertas. En términos de modelado de datos, aquí defino las entidades con sus atributos y comienzo a establecer las relaciones entre ellas. Por ejemplo, en el caso de los pedidos de un comercio electrónico, incluiría atributos como el identificador de factura, los precios, las cantidades y las fechas. Además, definiría las relaciones entre las entidades, considerando la cardinalidad, que describe cuántas veces una entidad puede estar asociada con otra. Ejemplos típicos incluyen:

    Al especificar estas relaciones, se genera una estructura lógica que refleja las interacciones del sistema. Es importante en este paso asegurarse de que las relaciones sean claras y que el diseño soporte las necesidades del negocio.

  3. Modelo físico: Este modelo se enfoca en cómo se almacenarán y se accederá a los datos dentro del sistema. Es el nivel más técnico, donde se toman decisiones sobre los tipos de datos, índices, particiones y otros aspectos físicos que afectan el rendimiento y la escalabilidad del sistema. Por ejemplo, al crear una tabla de clientes en Snowflake, necesito definir con precisión los tipos de datos que usaré para cada columna:

    CREATE OR REPLACE TABLE customers (
        customer_id NUMBER(38,0),
        country VARCHAR(255),
        customer_name VARCHAR(255)
    );
    

    Este paso traduce el diseño lógico en instrucciones que Snowflake u otro sistema de bases de datos puede ejecutar. Aquí también se optimiza el diseño para garantizar que las consultas sean rápidas y eficientes, especialmente en sistemas que manejan grandes volúmenes de datos.

    Además, en este nivel se consideran aspectos de seguridad, como el control de acceso a los datos, asegurando que solo las personas autorizadas puedan ver o modificar información sensible. Esto añade una capa adicional de confianza al modelo físico.


Creación de una tabla basada en un modelo lógico

Siguiendo con el ejemplo del comercio electrónico, si quiero crear una tabla para los clientes, el primer paso es identificar los atributos necesarios y sus respectivos tipos de datos. Esto se puede lograr explorando la estructura de las tablas existentes en el sistema:

DESC TABLE ecommerceonlineretail;

El comando anterior devuelve una descripción detallada de la tabla, incluyendo las columnas y sus tipos de datos. Basándome en esta información, puedo diseñar la tabla para que cumpla con los requisitos definidos en el modelo lógico. Por ejemplo:

CREATE OR REPLACE TABLE customers (
    customer_id NUMBER(38,0),
    customer_name VARCHAR(255),
    country VARCHAR(255),
    email_address VARCHAR(255),
    phone_number VARCHAR(15)
);

Este diseño incluye campos adicionales, como el correo electrónico y el número de teléfono, que podrían ser útiles para el negocio. Este nivel de detalle permite preparar la base para análisis futuros o integraciones con otros sistemas.

Además, este proceso asegura que la estructura de la tabla sea compatible con las necesidades del sistema y esté optimizada para consultas y análisis. Es una buena práctica validar el diseño con pruebas de carga antes de implementarlo en un entorno de producción, especialmente en sistemas con alta demanda de rendimiento.