Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
FALLAS BADES DE DATOS
1
Tipos de falla en un SMBDD
INGENIERíA EN SOFTWARE
"Si el diseño de base de datos se realiza correctamente, el desarrollo, la implementación y el desempeño posterior en la producción no causarán muchos problemas"
Tipos de falla en un SMBDD
Una base de datos bien diseñada funciona bien y, por eso, es importante evitar errores que pueden causar problemas a los desarrolladores y a los administradores de bases de datos.
Fallos comunes en el diseño de base de datos
1
Entre los fallos que pueden someterse en el diseño de base de datos están los relacionados con la no utilización de procedimientos almacenados para acceder a los datos o con la falta de pruebas.
Son los siguientes:
- Falta de planificación
- Ignorar la necesidad de normalización
- Estándares de denominación deficientes
- Falta de documentación
- Una tabla para contener todos los valores de dominio
- No proteger la integridad de los datos
Falta de planificación
Dado que la base de datos es la piedra angular de casi todos los proyectos de negocios, si no se toma el tiempo de planificar las necesidades del proyecto y cómo la base de datos las va a cumplir, es probable que todo el proyecto se desvíe.
Falta de planificación
Además, si no se toma el tiempo para comenzar con el diseño correcto de la base de datos, se descubrirá que cualquier cambio sustancial en las estructuras de la database que se necesite para seguir avanzando podría tener un gran impacto en general y provocar aumentos de costes y retrasos en el proyecto.
Ignorar la necesidad de normalización
Ignorar la necesidad de normalización
SQL fue creado para trabajar con estructuras de datos normalizadas.
La normalización es necesaria desde la programación de bases de datos a la de aplicaciones.
Resulta extremadamente importante, no solo para facilitar el desarrollo, sino para mejorar el rendimiento.
Los índices son más efectivos cuando pueden trabajar con el valor clave completo.
Estándares de denominación deficientes
Los nombres, aunque son una elección personal, son la primera y más importante línea de documentación para cualquier aplicación.
Por eso, es preciso asegurar su coherencia.
Estándares de denominación deficientes
Los nombres que se elijan no son solo para permitir identificar el propósito de un objeto, sino para permitir que todos los futuros programadores, usuarios, etc., comprendan rápida y fácilmente cómo una parte componente de la base de datos estaba destinada a ser utilizada y qué datos que almacena.
Ningún usuario futuro debería necesitar leer un documento de 500 páginas elaborado en el momento del diseño de base de datos para determinar el significado de algún nombre raro.
Falta de documentación
Un modelo de datos bien diseñado no solo se adhiere a un estándar de nomenclatura sólido, sino que también contiene definiciones en sus tablas, columnas, relaciones e incluso restricciones predeterminadas y de verificación, para que quede claro para todos cómo están destinados a usarse.
Falta de documentación
El objetivo debe ser proporcionar suficiente información para que cuando se complete el diseño de base de datos y se entregue a un programador de soporte, pueda descubrir los errores menores y corregirlos.
Una tabla para contener todos los valores de dominio
Las bases de datos relacionales se basan en la idea fundamental de que cada objeto representa una y solo una cosa.
Una tabla para contener todos los valores de dominio
Nunca debe haber ninguna duda sobre a qué se refiere un dato.
Al rastrear las relaciones, desde el nombre de la columna hasta el nombre de la tabla y la clave principal, debería ser fácil examinarlas y saber exactamente qué significa una parte de los datos.
Es, por eso mismo, mucho mejor evitar la complejidad y crear estructuras sólidas y mantenibles, en lugar de intentar hacer la menor cantidad de trabajo al comienzo del proyecto de diseño de base de datos
No proteger la integridad de los datos
No proteger la integridad de los datos
Todas las reglas de negocio fundamentales y no cambiantes deben implementarse mediante el motor relacional.
Las reglas básicas de anulabilidad, longitud de cadena, asignación de claves externas, etc., deben definirse en la base de datos
Hay que tener en cuenta que existen muchas formas diferentes de importar datos a SQL Server.
Si las reglas básicas están definidas en la propia base de datos, puede garantizarse que nunca se pasarán por alto.
De esta forma, se podrán escribir las consultas sin tener que preocuparse de si los datos que se muestran cumplen con las reglas de negocio básicas o no.
El diseño de base de datos y su implementación constituyen la piedra angular de cualquier proyecto centrado en los datos y debe ser tratado como tal cuando se está desarrollando.
Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar ilusión de que las transacciones se ejecutan seriamente, una después de la otra, sin ninguna intercalación.
Fallo en la transacción
Error lógico
Error lógico (del programa):
overflow, acceso a
información que no existe, entradas erróneas
Error del sistema:
interbloqueos, no son errores en los programas de la base de datos
Error del sistema
Caída del sistema:
fallo hardware (alimentación), del SGDB, del SO.
Se pierde información volátil
Caída del sistema
Fallo de disco:
Se pierde información
no volátil
Fallo de disco
Los algoritmos de recuperación aseguran la consistencia y
atomicidad de las transacciones aunque se produzcan fallos.
- Guardar información durante el proceso normal para poder realizar una recuperación
- Realizar la recuperación en caso de fallo
Procesó
MAS FALLAS
1. FALLAS DE ALMACENAMIENTO
2. PÉRDIDA DE BASES DE DATOS