Lineamientos informales para un buen diseño Paul Leger http://pleger.cl

Un Buen Diseño de base de Datos En el ER, un buen diseño: Es es un modelo que se entienda y represente el dominio de estudio Permite obtener la información suficiente al consultar al modelo En el Relacional, un buen diseño: Evita problemas de actualización, redundancia de datos y mantener la integridad de tablas Lo anterior se puede apreciar a través de cómo se guardan los datos

Pautas Informales Entregar una semántica clara a las entidades y atributos Reducir los valores redundantes en las tuplas Reducir los valores nulos en las tuplas Eliminar la posibilidad de generación de tuplas espurias (falsas)

Considere este modelo relacional con sus datos Dibuje las relaciones entre estas relaciones

Lineamiento Informal 1 Diseñe un esquema que sea fácil de entender. No combine entidades ni atributos que no corresponde al mundo real Unos malos ejemplos: ¿Cómo puedo insertar un trabajador sin un departamento o proyecto?

Ejemplos de Tuplas en Entidades que mezclan conceptos A simple vista ¿Qué problemas tiene este diseño? Uno podría pensar: “Entre menos tablas, menos información/memoria se necesita” ¿o no?

Lineamiento Informal 2 Diseñe una esquema no presente anomalías al momento de insertar, borrar y modificar tuplas

Problemas con anomalías INSERTAR: Insertar en una tupla que pertenecen a dos diferentes entidades ¿Qué pasa si quiero insertar un empleado que no tiene un departamento? ¿Qué pasa si quiero insertar un departamento sin empleados aún? ELIMINAR: Borrar una tupla de una tabla, termina borrando tuplas de otra entidad ¿Qué pasa si borró el último empleado que pertenencia al último departamento? MODIFICAR: La modificación es en cascada Si cambiamos el nombre a un departamento ¿Debemos cambiarlo en todas las tuplas que muestra el nombre del departamento?

Preguntas: ¿Podría haber un valor nulo en una primary key? Lineamiento Informal 3 Evite valores nulos. Si no es posible evitar, que estos valores nulos no estén dentro de atributos que se harán join y/o agregación Preguntas: ¿Podría haber un valor nulo en una primary key? ¿Podría haber un valor nulo en una foreign key?

Valores Nulos en Tuplas Los valores nulos genera los siguientes problemas: Memoria desperdiciada Problemas para hacer el “join” con atributos de supuestos nulos Funciones de agregación no funcionan ¿Qué es un valor nulo? Es un valor que no aplica Se desconoce el valor El valor se conoce, pero no aún no está completo Ejercicio: Considere el caso de la entidad Persona con el atributo opcional teléfono ¿Cómo ustedes se deshacen del posible nulo de teléfono?

Lineamiento Informal 4 Cada vez que realice un join natural, realícelo por primary and foreign keys. Si no lo hace, tendrá un resultados incorrectos y falsos al realizar el “join”

Generación de tuplas espurias Rut Nombre TipoTitulo Telefono 12334512 Paul Universitario 201232 123123 Karla 231232 13123123 María Técnico 234234 Titulo TipoTitulo Doctor Universitario Medico Abogado Electricista Técnico Realice un (natural) join y analice su resultado ¿Qué es lo malo del resultado? ¿Por qué está sucediendo esto? ¡¡ TUPLAS ESPURIAS !!

Resumiendo Estos lineamientos no son formales, pero permiten de manera rápida verificar el estado de un modelo Un beneficio de estos lineamientos es dar argumentos menos subjetivo para evaluar un diseño Otros beneficios de estos lineamientos es permitir para comparar de manera más objetiva dos diseños de base de datos

Paul Leger http://pleger.cl ¿Consultas? Paul Leger http://pleger.cl