1.1. El Ecosistema de Datos: Más allá de los Archivos

No todos los almacenamientos de datos son iguales. Es crucial entender el propósito de cada uno:

• Archivos Planos (CSV, Excel): Excelentes para compartir y para análisis rápidos y pequeños. No gestionan concurrencia, seguridad ni integridad.
• Bases de Datos (SGBD): Sistemas optimizados para transacciones operativas del día a día (lectura y escritura constante). Son la fuente de verdad para las aplicaciones.
• Data Warehouse (Almacén de Datos): Bases de datos especializadas y optimizadas para el análisis y la generación de informes (Business Intelligence). Consolidan datos históricos de múltiples fuentes.
• Data Lake (Lago de Datos): Repositorio centralizado para almacenar enormes cantidades de datos en su formato nativo (estructurados, semi-estructurados y no estructurados). Ideal para Machine Learning y Big Data.

1.2. El Modelo Relacional y sus Garantías: ACID

Las bases de datos relacionales garantizan la fiabilidad de las transacciones a través de las propiedades ACID:

2.1. El Arte de la Normalización

La normalización es un proceso sistemático para reducir la redundancia y mejorar la integridad de los datos. Exploraremos las formas más comunes con ejemplos prácticos.

2.2. Las Formas Normales en la Práctica

3.1. Las Cuatro Caras de SQL: DDL, DML, DCL y TCL

SQL se divide en cuatro sub-lenguajes. Cada uno tiene una misión específica y es crucial entender sus diferencias para ser un profesional de datos completo.

3.2. El Arte de Unir Tablas: Dominando los JOINs

Unir tablas es el pan de cada día en SQL. Es crucial entender cómo funciona cada tipo de `JOIN` para combinar datos de forma precisa.

3.3. Consultas Legibles: Subconsultas vs. Expresiones Comunes de Tabla (CTE)

Ambas permiten construir consultas complejas, pero las CTEs (`WITH`) son a menudo más legibles y reutilizables dentro de una misma consulta, facilitando la lógica y la depuración.

SELECT * FROM Empleados
            WHERE salario > (SELECT AVG(salario) FROM Empleados);

WITH SalarioPromedio AS (
                SELECT AVG(salario) as avg_sal FROM Empleados
            )
            SELECT * FROM Empleados, SalarioPromedio
            WHERE salario > SalarioPromedio.avg_sal;

3.4. La Magia del Análisis: Funciones de Ventana

Las funciones de ventana realizan cálculos sobre un conjunto de filas relacionadas con la fila actual, sin colapsar el resultado como lo hace `GROUP BY`. Son esenciales para análisis avanzados como rankings, series temporales y cálculos acumulados.

            -- Ranking de ventas por vendedor y mes
            SELECT
                vendedor,
                mes,
                ventas,
                -- Ranking de ventas dentro de cada mes
                RANK() OVER (PARTITION BY mes ORDER BY ventas DESC) as ranking_mensual,
                -- Venta del mes anterior para este vendedor
                LAG(ventas, 1, 0) OVER (PARTITION BY vendedor ORDER BY mes) as ventas_mes_anterior,
                -- Venta acumulada para este vendedor
                SUM(ventas) OVER (PARTITION BY vendedor ORDER BY mes) as venta_acumulada
            FROM Ventas_Mensuales;
                        

5.1. El Punto de Partida: Diagramas Entidad-Relación (ER)

Antes de construir un Data Warehouse, los datos nacen en sistemas transaccionales, y estos sistemas se diseñan usando Diagramas Entidad-Relación (ERD). Un ERD es el plano de una base de datos normalizada (como las que vimos en el Módulo 2).

Los componentes de un ERD son:

• Entidades: Son los "sustantivos" del negocio. Representan objetos o conceptos del mundo real sobre los que queremos guardar información (ej: `CLIENTE`, `PRODUCTO`, `PEDIDO`). Se convierten en tablas.
• Atributos: Son las propiedades o características de una entidad (ej: el `nombre` de un cliente, el `precio` de un producto). Se convierten en las columnas de las tablas.
• Relaciones: Son los "verbos" que conectan a las entidades. Describen cómo interactúan entre sí. Las más comunes son:
  • Uno a Muchos (1:N): Un `CLIENTE` puede realizar muchos `PEDIDOS`.
  • Muchos a Muchos (N:M): Un `PEDIDO` puede contener muchos `PRODUCTOS`, y un `PRODUCTO` puede estar en muchos `PEDIDOS`. Este tipo de relación siempre se resuelve con una tabla intermedia (en nuestro diagrama, `DETALLE_PEDIDO`).

5.2. Los Bloques del Análisis: Hechos y Dimensiones

El modelado dimensional cambia la terminología. En lugar de entidades y relaciones, hablamos de Hechos y Dimensiones. Son los dos únicos tipos de tablas que encontraremos.

5.3. El Protagonista: Esquema de Estrella (Star Schema)

Es el diseño más famoso, rápido y recomendado para la mayoría de los casos de BI. Su estructura es simple y potente: una tabla de hechos en el centro conectada directamente a sus dimensiones, formando una estrella.

5.4. La Familia Dimensional: Copo de Nieve, Galaxia y más

Si bien el modelo Estrella es el rey, existen otras variaciones para resolver problemas específicos. Son como "evoluciones" del modelo estrella.

5.5. Una Filosofía Diferente: El Modelo Data Vault

Data Vault no es solo otro tipo de esquema, es una metodología de modelado distinta. Su objetivo no es la consulta directa, sino la **integración de datos de forma ágil, escalable y auditable**.

4.1. Taller Avanzado de Análisis

Usa la base de datos `taller_seguridad.db` para resolver estos retos. ¡Algunos requieren las técnicas avanzadas que acabamos de ver!

# Este código prepara la base de datos para el taller.
import pandas as pd
import requests
import sqlite3

# Cargar datos de secuestros
api_url = "https://www.datos.gov.co/resource/886s-p2i3.json?$limit=10000"
response = requests.get(api_url)
data = response.json()
df_secuestros = pd.DataFrame(data)
df_secuestros['cantidad'] = pd.to_numeric(df_secuestros['cantidad'], errors='coerce').fillna(0).astype(int)
df_secuestros['año'] = pd.to_datetime(df_secuestros['fecha_hecho'], errors='coerce').dt.year
df_secuestros.dropna(subset=['departamento', 'año'], inplace=True)
df_secuestros['año'] = df_secuestros['año'].astype(int)

# Datos de población (ejemplo)
poblacion_data = {
    'nombre_depto': ['ANTIOQUIA', 'CUNDINAMARCA', 'VALLE DEL CAUCA', 'ATLÁNTICO', 'BOGOTÁ, D.C.', 'SANTANDER', 'BOLÍVAR'],
    'poblacion': [6677930, 3242996, 4532152, 2722128, 7743955, 2280908, 2180976]
}
df_poblacion = pd.DataFrame(poblacion_data)

# Crear y poblar la base de datos
conn = sqlite3.connect('taller_seguridad.db')
df_secuestros.to_sql('secuestros', conn, index=False, if_exists='replace')
df_poblacion.to_sql('poblacion_deptos', conn, index=False, if_exists='replace')
conn.close()

print("Base de datos 'taller_seguridad.db' lista para el taller.")
                            

-- Solución con Funciones de Ventana
WITH CasosAnuales AS (
    SELECT
        departamento,
        año,
        SUM(cantidad) as total_anual
    FROM
        secuestros
    WHERE año IN (2020, 2021)
    GROUP BY departamento, año
)
SELECT
    departamento,
    total_anual - LAG(total_anual, 1, 0) OVER (PARTITION BY departamento ORDER BY año) AS crecimiento
FROM CasosAnuales
WHERE año = 2021
ORDER BY crecimiento DESC
LIMIT 1;
                                 

-- Solución
WITH TasaDepartamental AS (
    SELECT
        s.departamento,
        p.region,
        (CAST(SUM(s.cantidad) AS REAL) / p.poblacion) * 100000 AS tasa_por_100k
    FROM
        secuestros s
    JOIN
        poblacion_deptos p ON s.departamento = p.nombre_depto
    GROUP BY s.departamento, p.region, p.poblacion
)
SELECT
    departamento,
    region,
    tasa_por_100k,
    RANK() OVER (PARTITION BY region ORDER BY tasa_por_100k DESC) as ranking_regional
FROM TasaDepartamental;
                                 

4.2. Optimización: Entendiendo al Gestor de Consultas

Cuando envías una consulta, el SGBD no la ejecuta ciegamente. Primero, crea un Plan de Ejecución, que es el "mapa" de la forma más eficiente de obtener los datos. Entender estos planes es clave para la optimización.

• Planes de Ejecución: Usando comandos como `EXPLAIN QUERY PLAN` en SQLite, puedes ver si la base de datos está usando un "Full Table Scan" (lento) o un "Search using index" (rápido).
• Índices Clustered vs. Non-Clustered:
  • Un índice Clustered ordena físicamente los datos en el disco según la columna del índice. Solo puede haber uno por tabla (generalmente la Clave Primaria).
  • Un índice Non-Clustered es una estructura separada que apunta a los datos. Puede haber muchos por tabla.