APEXDATA (1)

APEXDATA

VOLUMEN 02 • JULIO 2026

El arte del modelado de datos y arquitecturas de persistencia de nivel empresarial en sistemas modernos de información.

COMITÉ EDITORIAL

Astudillo, Isaac V-32.829.810 Centeno, Gregoria V-26.204.472 Rodríguez, Yiledys V-34.446.296 Pinto, Brad V-31.856.924 Villarroel, Valeria V-27.928.036 Héctor Acosta V-31.649.363

Estructura Editorial 01

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.

0 2 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.

DEL MODELADO: 0 3 INGENIERÍA 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.

0 4 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.

01 / FUNDAMENTOS TEÓRICOS

ESTRUCTURAS Y ESTÁNDARES DE PERSISTENCIA

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.

01 / FUNDAMENTOS TEÓRICOS

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.

SUBLENGUAJES SQL DE COMUNICACIÓN Y ESTRUCTURA Categoría

DDL (Definición)

DML (Manipulació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

DCL (Control)

Gestiona permisos, accesos y seguridad a nivel de usuarios y roles de conexión.

GRANT, REVOKE

TCL (Transacción)

Controla los estados y fronteras físicas de ejecución de transacciones para garantizar ACID.

COMMIT, ROLLBACK, SAVEPOINT

02 / CASO DE ESTUDIO PRÁCTICO

SISTEMA TRANSACCIONAL DE VENTAS: "OMNICART" Reglas del Negocio (Constraint Core) La compañía distribuidora de tecnología OmniCart procesa cientos de miles de pedidos diarios.

Actualmente opera con un sistema heredado fragmentado en archivos CSV y hojas de cálculo locales que genera colisiones severas: inventarios incorrectos, órdenes de pago sin registro y pérdida de trazabilidad en las entregas. Se requiere diseñar y estructurar la persistencia de forma centralizada.

Justificación del Modelo Relacional Se opta categóricamente por un RDBMS sobre alternativas NoSQL documentales. El negocio de OmniCart requiere transaccionalidad estricta y control de consistencia cruzada. Al aplicar el cumplimiento estricto del estándar ACID evitamos fallos catastróficos, como la sobreventa de productos sin existencias físicas o cobros fantasmas por pérdida de conexión.

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.

03 / INGENIERÍA DE DISEÑO

EVOLUCIÓN DEL ESQUEMA RELACIONAL Presentamos la transición matemática formal desde un único registro estructurado masivo (Forma No Normalizada) hasta la Tercera Forma Normal (3FN), mitigando anomalías de inserción, actualización y borrado de información.

Forma No Normalizada (UNF)

Primera Forma Normal (1FN)

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:

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 } )

T_Orden_Cliente (ID_Orden, Fecha_Registro, ID_Cliente, Nombre_Cliente, Correo_Cliente, Cod_Envio, Direccion_Entrega)

T_Detalle_Temp: (ID_Orden, SKU_Producto, Nombre_Producto, Descripcion_Producto, Cantidad_Comprada, Precio_Pactado)

03 / INGENIERÍA DE DISEÑO

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. T_Orden_Cliente:

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)

(ID_Orden, Fecha_Registro, ID_Cliente, Nombre_Cliente, Correo_Cliente, Cod_Envio, Direccion_Entrega)

T_Producto:

PRODUCTO: (SKU_Producto, Nombre, Descripcion)

(SKU_Producto, Nombre_Producto, Descripcion_Producto)

T_Linea_Detalle (ID_Orden, SKU_Producto, Cantidad_Comprada, Precio_Pactado)

ORDEN_COMPRA: (ID_Orden, Fecha, Cod_Envio, Direccion, ID_Cliente)

DETALLE_VENTA: (ID_Orden, SKU_Producto, Cantidad, Precio_Venta)

03 / INGENIERÍA DE DISEÑO

DICCIONARIO DE DATOS TÉCNICO (3FN) TABLA

NOMBRE FÍSICO

TIPO DE DATO

INTEGRIDAD / CLAVE

DESCRIPCIÓN / REGLA

CLIENTE

ID_Cliente

INT

PRIMARY KEY

Identificador unívoco del comprador.

CLIENTE

Nombre

VARCHAR(120)

NOT NULL

Nombres y apellidos completos.

CLIENTE

Correo

VARCHAR(100)

UNIQUE

Casilla de correo único del usuario.

PRODUCTO

SKU_Producto

VARCHAR(50)

PRIMARY KEY

Stock Keeping Unit interno del artículo.

PRODUCTO

Nombre

VARCHAR(100)

NOT NULL

Nombre de exhibición del producto.

PRODUCTO

Descripcion

TEXT

NULLABLE

Ficha de especificaciones detallada.

ORDEN_COMPRA

ID_Orden

INT

PRIMARY KEY

Código correlativo de factura de venta.

NOT NULL

Fecha y hora exacta del checkout de compra.

NOT NULL

Destino geográfico seleccionado de despacho.

FOREIGN KEY

Clave foránea hacia CLIENTE.ID_Cliente .

ORDEN_COMPRA

ORDEN_COMPRA

ORDEN_COMPRA

Fecha

Direccion

ID_Cliente

DATETIME

VARCHAR(250)

INT

03 / IMPLEMENTACIÓN DE ESQUEMA FÍSICO SQL

CÓDIGO DDL DE PERSISTENCIA LIMPIA

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: -================================================ ========= -- DISEÑO ESTRUCTURADO BASE DE DATOS OMNICART (3FN) -================================================ =========CREATE TABLE CLIENTE ( ID_Cliente INT PRIMARY KEY, Nombre VARCHAR(120) NOT NULL, Correo VARCHAR(100) UNIQUE NOT NULL ); CREATE TABLE PRODUCTO ( SKU_Producto VARCHAR(50) PRIMARY KEY, Nombre VARCHAR(100) NOT NULL, Descripcion TEXT ); CREATE TABLE ORDEN_COMPRA ( ID_Orden INT PRIMARY KEY, Fecha DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, Cod_Envio VARCHAR(50), Direccion VARCHAR(250) NOT NULL, ID_Cliente INT, FOREIGN KEY (ID_Cliente) REFERENCES CLIENTE(ID_Cliente) ON UPDATE CASCADE ON DELETE RESTRICT ); CREATE TABLE DETALLE_VENTA ( ID_Orden INT, SKU_Producto VARCHAR(50), Cantidad INT NOT NULL CHECK (Cantidad > 0), Precio_Venta DECIMAL(10,2) NOT NULL, PRIMARY KEY (ID_Orden, SKU_Producto), FOREIGN KEY (ID_Orden) REFERENCES ORDEN_COMPRA(ID_Orden) ON DELETE CASCADE, FOREIGN KEY (SKU_Producto) REFERENCES PRODUCTO(SKU_Producto) );

REFLEXIONES DE MANTENIBILIDAD 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.

04 / ESPARCIMIENTO TÉCNICO E INTERACTIVO

Zona de Desafíos Lógicos Estructura Desafiante "Paso de la redundancia extrema a la limpieza ideal, con tres pasos matemáticos dejo el esquema formal. Evito colisiones, cuido tu consistencia y te salvo de fallos en producción con eficiencia. ¿Qué soy?"

Garantía Segura "Si el servidor explota o falla la conexión, restauro tu base a su previa condición.

Tengo cuatro letras y garantizo la verdad de cada transacción en la posteridad. ¿Quién soy?"

SUDOKU

Garantía Segura "Tengo llaves de sobra pero no abro ningún portal, conecto tablas ajenas para un reporte genial. Si me modificas con cuidado mantengo la integridad, evitando registros fantasmas en la realidad. ¿Qué soy?"

CASCADA

COMANDO

COMPRA

CORREO

DATOS

NDICE

PRECIO

REGISTRO

VENTA

VISTAS