Contenido verificado asociado a este RA
Diseño Físico de Bases de Datos: Estructuras de Almacenamiento y su Implementación
Esta unidad trabaja el paso del diseño lógico al diseño físico de una base de datos, centrándose en cómo el SGBD organiza el almacenamiento en disco mediante estructuras como tablespaces o filegroups. A partir de ahí se introduce la creación de tablas, la selección de tipos de datos y el uso combinado de DDL y herramientas gráficas, como pasos necesarios para materializar esas estructuras físicas.
Definición de Claves y Restricciones de Integridad
Esta unidad se centra en la implementación de la integridad de los datos mediante la definición de campos clave y la aplicación de diversas restricciones. Se explica cómo estas restricciones garantizan la coherencia y validez de la información en la base de datos.
Verificación y Documentación del Diseño Físico
Esta unidad aborda la fase crítica de verificación de la implementación de la base de datos y la importancia de su documentación. Se explica cómo usar datos de prueba para validar el modelo y cómo construir un diccionario de datos completo.
Definición y Documentación del Diccionario de Datos
Esta unidad explica la importancia de definir y documentar el diccionario de datos, un componente esencial para la gestión y mantenimiento de cualquier base de datos, detallando su contenido y cómo se mantiene actualizado.
Conceptos clave
Diseño físico de bases de datosTablespace (Oracle/PostgreSQL)Filegroup (SQL Server)Lenguaje de Definición de Datos (DDL)CREATE TABLESelección de tipos de datosVerificación en el catálogo del sistemaClave PrimariaClave ForáneaClave ÚnicaRestricciones de IntegridadNOT NULLCHECKDEFAULTIntegridad ReferencialDDLVerificación de la implementaciónDatos de prueba
Errores que conviene evitar
- Asumir que la sintaxis de tablespaces es idéntica entre SGBD: Causa: generalizar un ejemplo de un motor concreto a todos. Corrección: consultar la documentación oficial de la versión exacta del SGBD antes de ejecutar sentencias DDL de almacenamiento.
- Usar tipos de datos genéricos o sobredimensionados (p. ej. VARCHAR(255) por defecto): Causa: falta de análisis previo de la longitud y naturaleza real del dato. Corrección: analizar el rango y precisión esperados y elegir el tipo más ajustado (CHAR para longitud fija conocida, DECIMAL para importes exactos, etc.).
- Omitir claves foráneas: Causa: Falta de comprensión de la integridad referencial. Corrección: Siempre establecer FOREIGN KEYs para mantener la coherencia entre tablas relacionadas.
- No usar restricciones CHECK para validación de datos: Causa: Confiar solo en la lógica de la aplicación. Corrección: Implementar CHECK constraints para asegurar que los datos cumplan reglas de negocio básicas a nivel de base de datos.
- No realizar pruebas exhaustivas con datos de prueba: Causa: Confianza excesiva en la implementación o falta de tiempo. Corrección: Diseñar un plan de pruebas que cubra casos normales, límite y de error para cada restricción.
- Documentación desactualizada o inexistente: Causa: Falta de disciplina o herramientas adecuadas. Corrección: Establecer un proceso de documentación continuo y utilizar herramientas que automaticen la generación del diccionario de datos a partir del esquema.
- No documentar el diccionario de datos o hacerlo de forma incompleta: Causa: Se considera una tarea secundaria o se prioriza la implementación. Corrección: Integrar la documentación del diccionario de datos como parte integral del proceso de diseño y desarrollo. Utilizar herramientas que generen la documentación automáticamente a partir del esquema.
- No mantener el diccionario de datos actualizado: Causa: Los cambios en la base de datos no se reflejan en la documentación. Corrección: Establecer un proceso para actualizar el diccionario de datos cada vez que se realiza un cambio en el esquema de la base de datos. Considerar el uso de herramientas de versionado para la documentación.