FUNDAMENTOS DE PERSISTENCIA TEÓRICA
Exploración profunda de la Arquitectura ANSI/SPARC, el modelo transaccional ACID, arquitecturas internas de los SMBD, comandos SQL (DDL, DML, DCL, TCL) y controles de seguridad.
CASO DE ESTUDIO PRÁCTICO: OMNICART
Definición detallada de requisitos para un sistema de E-commerce. Reglas de negocio e implicaciones del modelado lógico relacional frente a paradigmas no relacionales.
INGENIERÍA DEL MODELADO: SQL Y NORMALIZACIÓN
De Forma No Normalizada (UNF) a la Tercera Forma Normal (3FN). Diagrama de entidad relación detallado, diccionario de datos estructurado y scripts SQL de implementación listos para bases de datos.
ZONA DE ESPARCIMIENTO LÓGICO
Adivinanzas tecnológicas de diseño de software, juego de sudoku relacional y sopa de letras interactiva sobre ingeniería de datos.
Antes de modelar bases de datos concretas, debemos dominar el estándar teórico que asegura la escalabilidad y la tolerancia a fallas. La arquitectura moderna se cimienta en la independencia de datos y la garantía transaccional.
La Arquitectura ANSI/SPARC
Propone un modelo de tres niveles de abstracción para lograr la total independencia de los datos:
1. Externo (Vistas):Vistas personalizadas para el usuario final o servicios sin exponer la BD entera.
2. Conceptual:Esquema global con entidades, relaciones, restricciones y reglas de integridad de negocio.
3. Interno (Físico):Organización física en memoria, rutas de acceso, almacenamiento y estructura de índices.
El Contrato Transaccional
ACID
El pilar que asegura que las bases de datos relacionales no sufran inconsistencias ni pérdidas catastróficas de información:
A - Atomicidad:La transacción se realiza al 100% o no se realiza en absoluto. Si falla un paso, hay un "rollback".
C - Consistencia:Las transacciones mueven la BD de un estado de integridad válido a otro válido.
I - Aislamiento:Múltiples operaciones concurrentes se ejecutan sin interferir entre sí.
D - Durabilidad:Al confirmar la operación (commit), el cambio es permanente incluso si el sistema se apaga.
Seguridad y Arquitectura de SMBD
La seguridad no se limita a restringir la entrada, sino a encriptar y gestionar de forma estricta los privilegios sobre esquemas físicos.
Un Sistema de Manejo de Bases de Datos (SMBD) intercepta cada petición de red, analiza sintácticamente la estructura, genera un plan optimizado de ejecución de bajo nivel y garantiza que solo los roles autorizados interactúen con las tablas subyacentes mediante cifrado TLS y de disco.
Categoría
DDL (Definición)
DML (Manipulación)
DCL (Control)
TCL (Transacción)
Descripción
Crea, altera y destruye las estructuras físicas de almacenamiento (tablas, vistas, índices)
Consulta, inserta, modifica y elimina los datos contenidos dentro de las estructuras existentes.
Comandos
Fundamentales
CREATE, ALTER, DROP, TRUNCATE
SELECT, INSERT, UPDATE, DELETE
Gestiona permisos, accesos y seguridad a nivel de usuarios y roles de conexión. GRANT, REVOKE
Controla los estados y fronteras físicas de ejecución de transacciones para garantizar ACID.
COMMIT, ROLLBACK, SAVEPOINT
Justificación del Modelo
Relacional
Reglas del Negocio (Constraint Core)
R1: Clientes y Cuentas
Un cliente posee un código único de registro global, nombre completo, correo verificado y una dirección física principal para envíos.
R2: Inventario de Productos
Un artículo se registra mediante un SKU único, nombre comercial, descripción técnica y precio de venta actual.
R3: Orden y Transaccionalidad
Una orden es emitida en una marca de tiempo exacta por un único cliente. Contiene metadatos de facturación e impuestos.
R4: Detalle de Venta
Cada orden puede incluir múltiples productos agregados, detallando la cantidad unitaria adquirida y la cotización pactada al momento de la compra.
Forma No Normalizada (UNF)
La tabla unificada que captura datos transaccionales, de clientes y productos posee un grupo repetitivo complejo (indicado entre llaves { }) por cada artículo comprado dentro de una misma transacción:
Primera Forma Normal (1FN)
Eliminar grupos repetitivos y garantizar la atomicidad absoluta de las celdas. Se dividen en dos tablas asociadas mediante la clave primaria de la orden.
ORDEN _ SISTEMA _ UNF
( ID Orden, Fecha Registro, ID Cliente, Nombre Cliente, Correo Cliente, Cod Envio, Direccion Entrega, { SKU Producto, Nombre Producto, Descripcion Producto, Cantidad Comprada, Precio Pactado } )
(ID Orden, Fecha Registro, ID Cliente, Nombre Cliente, Correo Cliente, Cod Envio, Direccion Entrega)
(ID Orden, SKU Producto, Nombre Producto, Descripcion Producto, Cantidad Comprada, Precio Pactado)
Segunda Forma Normal (2FN)
Cumplir con 1FN y que todos los atributos que no forman parte de la clave compuesta dependan de forma funcional y completa de ella, y no de forma parcial. El nombre del producto no depende de la orden, depende únicamente del SKU.
(ID Orden, Fecha Registro, ID Cliente, Nombre Cliente, Correo Cliente, Cod Envio, Direccion Entrega)
(SKU Producto, Nombre Producto, Descripcion Producto)
(ID Orden, SKU Producto, Cantidad Comprada, Precio Pactado)
Tercera Forma Normal (3FN)
Cumplir con 2FN y remover dependencias transitivas. Los atributos deben depender directamente de la clave primaria y de nada más. Los datos del cliente (nombre, correo) dependen del ID Cliente, no de la Orden.
CLIENTE:
(ID Cliente, Nombre, Correo)
PRODUCTO:
(SKU Producto, Nombre, Descripcion)
ORDEN COMPRA:
(ID Orden, Fecha, Cod Envio, Direccion, ID Cliente)
DETALLE VENTA:
(ID Orden, SKU Producto, Cantidad, PrecioVenta)
TABLA NOMBRE FÍSICO TIPO DE DATO
INTEGRIDAD / CLAVE DESCRIPCIÓN / REGLA
CLIENTE ID Cliente INT PRIMARYKEY
CLIENTE Nombre VARCHAR(120) NOTNULL
Identificador unívocodel comprador
Nombresy apellidos completos
CLIENTE Correo VARCHAR(100) UNIQUE Casilladecorreo únicodelusuario
PRODUCTO SKU Producto VARCHAR(50) PRIMARYKEY StockKeepingUnit internodelartículo.
PRODUCTO Nombre VARCHAR(100) NOTNULL
PRODUCTO Descripcion TEXT NULLABLE
ORDEN COMPRA ID Orden INT PRIMARYKEY
ORDEN COMPRA Fecha DATETIME NOTNULL
ORDEN COMPRA Direccion VARCHAR(250) NOTNULL
ORDEN COMPRA ID Cliente INT FOREIGNKEY
Nombrede exhibicióndel producto.
Fichade especificaciones detallada.
Códigocorrelativo defacturade venta.
Fechayhora exactadel checkoutde compra.
Destinogeográfico seleccionadode despacho
Claveforánea hacia CLIENTEID Cliente
El siguiente código SQL DDL normalizado puede ejecutarse de forma directa en motores de persistencia empresariales como PostgreSQL, MySQL o MariaDB. Asegura el acatamiento implícito de la integridad referencial y de cascada para preservar las claves foráneas:
Al normalizar el sistema hasta 3FN, se reduce la duplicidad de cadenas de texto y se elimina por completo la anomalía de actualización (por ejemplo, actualizar el correo de un cliente requería alterar todas sus ventas pasadas en esquemas UNF). Ahora la modificación se realiza en un único registro, agilizando el rendimiento de la red y el almacenamiento.
Zona de Desafíos Lógicos
