CLASE 052

Ejercicio Práctico: Transición de SQL Directo a Ficheros SAP HANA

🎯 Transición Metodológica

Objetivo: Aplicar todos los conceptos de CREATE TABLE utilizando el sistema de ficheros de desarrollo de SAP HANA

🔄 Cambio de Paradigma: De SQL a Ficheros

📝 Método SQL Directo (Anterior)

  • Comando CREATE TABLE explícito
  • Definición inline de restricciones
  • Ejecución inmediata
  • Ideal para pruebas rápidas
  • Menos organización del código

📁 Método con Ficheros (Nuevo)

  • Sin comando CREATE explícito
  • Restricciones en ficheros separados
  • Proceso de construcción
  • Mejor para proyectos grandes
  • Organización modular

⚠️ Diferencias Clave a Recordar

  • No usar CREATE: Los ficheros .hdbtable omiten esta palabra
  • Namespaces obligatorios: Ruta completa con comillas dobles
  • Claves foráneas separadas: Requieren ficheros .hdbconstraint
  • Construcción por dependencias: El sistema maneja el orden automáticamente

🏗️ Flujo de Trabajo del Ejercicio

1
Crear carpeta "ejercicios_sql"
Organización del proyecto en la zona de desarrollo
2
Analizar requisitos del negocio
Sistema de productos, proveedores y países
3
Diseñar estructura de tablas
Decidir tipos de datos y restricciones apropiadas
4
Crear ficheros .hdbtable
Productos, proveedores y países
5
Establecer relaciones
Ficheros .hdbconstraint para claves foráneas
6
Validar y construir
Construcción automática respetando dependencias

💭 Proceso de Toma de Decisiones

🧠 Decisiones de Diseño Explicadas

📊 Tipos de Datos

  • INTEGER para IDs: Estándar robusto, rango amplio sin ser excesivo
  • NCHAR para textos: Soporte Unicode para empresas multinacionales
  • DECIMAL(6,2): Precios hasta 9999.99, suficiente para productos normales
  • Tamaños de cadena: 30-50 caracteres con margen de seguridad

🏢 Decisiones de Negocio

  • Tabla de países separada: Normalización evita repetición
  • UNIQUE en nombres: Evita productos duplicados en inventario
  • NOT NULL obligatorio: Garantiza datos esenciales
  • DEFAULT 0.0: Evita NULL en cálculos matemáticos

💡 Filosofía "Curarse en Salud"

Ejemplo del puente: Si calculas que soporta X peso, hazlo para 3X. Si el nombre más largo son 30 caracteres, pon límite de 35-40.

🗃️ Diseño Final de Tablas

🏢 EJE_PAÍSES
id_pais INTEGER PRIMARY KEY
nombre NCHAR(30) NOT NULL UNIQUE
🏭 EJE_PROVEEDORES
id_proveedor INTEGER PRIMARY KEY
nombre NCHAR(50) NOT NULL UNIQUE
id_pais INTEGER FOREIGN KEY
📦 EJE_PRODUCTOS
id_producto INTEGER PRIMARY KEY
nombre NCHAR(50) NOT NULL UNIQUE
cantidad INTEGER -
precio_compra DECIMAL(6,2) DEFAULT 0.0
id_proveedor INTEGER FOREIGN KEY

📂 Estructura de Ficheros

📁 ejercicios_sql/ ├── eje_productos.hdbtable ├── eje_proveedores.hdbtable ├── eje_paises.hdbtable ├── fk_pais.hdbconstraint └── fk_proveedor.hdbconstraint

💻 Ejemplo de Fichero .hdbtable

COLUMN TABLE "BBDD_MODELADO"."DB"."EJERCICIOS_SQL"::"EJE_PRODUCTOS" ( id_producto INTEGER PRIMARY KEY, nombre NCHAR(50) NOT NULL UNIQUE, cantidad INTEGER, precio_compra DECIMAL(6,2) DEFAULT 0.0, id_proveedor INTEGER );

🔗 Ejemplo de Fichero .hdbconstraint

CONSTRAINT "BBDD_MODELADO"."DB"."EJERCICIOS_SQL"::"FK_PROVEEDOR" ON "BBDD_MODELADO"."DB"."EJERCICIOS_SQL"::"EJE_PRODUCTOS" (id_proveedor) REFERENCES "BBDD_MODELADO"."DB"."EJERCICIOS_SQL"::"EJE_PROVEEDORES" (id_proveedor) ON DELETE CASCADE;

🎯 Lecciones Clave del Ejercicio

✅ Conceptos Aplicados Exitosamente

  • Transición metodológica: De SQL directo a ficheros estructurados
  • Análisis de requisitos: Empresa multinacional con productos, proveedores y países
  • Normalización: Tabla separada para países evita redundancia
  • Tipos de datos apropiados: INTEGER, NCHAR, DECIMAL según necesidades
  • Restricciones de integridad: PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL
  • Valores por defecto: DEFAULT 0.0 para evitar problemas con NULL
  • Acciones referenciales: CASCADE y SET NULL según lógica de negocio
  • Organización modular: Ficheros separados para mejor mantenimiento

🏆 Resultado Final

Sistema completo de inventario con:

  • ✅ Tres tablas interrelacionadas
  • ✅ Integridad referencial garantizada
  • ✅ Datos de prueba insertados correctamente
  • ✅ Acciones referenciales configuradas
  • ✅ Validación en Database Explorer

🧹 Buenas Prácticas Destacadas

  • Limpieza regular: Borrar objetos de prueba para mantener orden
  • Naming conventions: Nombres descriptivos y consistentes
  • Orden de inserción: Respetar dependencias (países → proveedores → productos)
  • Validación continua: Construir frecuentemente para detectar errores