B3-T1 Diseño de BBDD.pdf
Transcript
1. Diseño de BBDD 1.1. Proceso de modelado ( de un problema) Tipos de modelado Modelo Conceptual: es una representación abstracta de la estructura de la base de datos, que se centra en las entidades y sus relaciones. Modelo lógico: representación más detallada y estructurada...
1. Diseño de BBDD 1.1. Proceso de modelado ( de un problema) Tipos de modelado Modelo Conceptual: es una representación abstracta de la estructura de la base de datos, que se centra en las entidades y sus relaciones. Modelo lógico: representación más detallada y estructurada de cómo se organizan los datos dentro del sistema de gestión de bases de datos (DBMS) ○ Dependiente del tipo de BBDD(objetos, red, jerárquico) ○ Ej: modelo relacional ○ Aparece la normalización Modelo Físico: es la implementación concreta de la estructura de la base de datos en el sistema de almacenamiento subyacente. ○ Dependiente del SGBD concreto ( Ej: Oracle) Arquitectura ANSI/SPARC (De un DBMS(sistema gestor de BBDD)) La arquitectura ANSI/SPARC es un modelo de referencia para los sistemas gestores de bases de datos (DBMS), que define una estructura de tres niveles Busca independencia entre el nivel físico y el lógico: Nivel Externo (vistas): suelen usarse para centrar, simplificar y personalizar la percepción de la base de datos para cada usuario ○ Desacopla la complejidad de las tablas Nivel Conceptual Definición de la estructura lógica de toda la base de datos. Tablas/relaciones Nivel Interno: representación física de la base de datos ○ Detalles de almacenamiento. ○ Índices Nota: No todas las tablas de una BBDD tienen por que ser una clase en java. 1.2. Reglas de transformación del E/R al Relacional Las entidades se transforman en Relación En un modelo relacional no se crean los diccionarios (repositorio centralizado que almacena definiciones y descripciones de los datos, sus estructuras y las relaciones entre ellos) Reglas de transformación en función del tipo de relación: Relaciones de 1 a n. Propagación de la clave: llevarnos la clave del lado 1 hacia el lado n (Autor → Libro) ○ Relaciones M a N. Siempre genera una Relación específica ○ ○ Se le propaga las PK de las entidades ○ La relación puede tener sus propios atributos Relación N-arias: Siempre genera una Relación específica ○ Relacionan más de 2 tipos de entidades 1.3. Relaciones de Especialización. Jerarquía Relaciones de General/Especialización, Jerarquía E/R Relaciones que permiten organizar y estructurar datos o clases de manera jerárquica, reflejando la relación entre un grupo más general y sus subgrupos más específicos. En nuestra empresa una persona o es director o es externo Opción 1: 1 sola relación - Una sola tabla Nombre DNI NCoches Atr.Discriminador Luis 555 5 Juan 666 0 Si lo ponemos todo en una tabla, debe existir un tipo de atributo ” discriminador”. Nos vale para saber que tipo de persona es (Director - Externo). Si una persona es externa, al crear una sola relación, no se rellenará el atributo “número de coches”. Si la persona fuera director, no se rellenará el número de horas extras Opción 2: 1 relación por cada subtipo Ahora se necesitan 2 tablas Ya no se necesita un discriminador, pero si se duplica estructura y no datos Director Externo dni dni Opción 3: 1 relación por cada subtipo y otra por el supertipo 3 Tablas ¿Como se haría para que el sistema sepa que no detecte dni duplicadas en la tabla externo y director? Esto no es propio del SGBD, hay que hacerlo a nivel de código 1.4. El modelo relacional Se basa en el modelo matemático de relación: Esquema ó Intensión (Relación + Atributos + Restricciones + Reglas de seguridad): El esquema es una descripción lógica de toda la estructura de la base de datos. Incluye la definición de las tablas (relaciones), los atributos (columnas) y las restricciones (constraints) que se aplican a los datos. ○ Ejemplo: profesor (NIF, Nombre, Departamento, Teléfono) Teléfono → cada atributo tiene un dominio (valores) Dominio: conjunto de valores que admite un atributo Grado: número de atributos de la relación. Extensión (cardinalidad): conjunto de tuplas de la relación (nº filas de la tabla) Características del modelo relacional Atomicidad de los valores de los atributos No repetición de tuplas. Claves No orden en tuplas y atributos Tipos de claves Superclave: cualquier subconjunto de atributos de la relación, que permite diferenciar a cualesquiera 2 tuplas que forman parte de la misma a partir de los valores de las tuplas para esos atributos. ○ Clave candidata (superclaves mínimas): Conjunto de atributos mínimos que identifican unívocamente a cada tupla. Clave primaria: Una sola de las claves candidatas Claves compuestas: claves formadas por más de un atributo Restricciones Valores nulos: como ausencia de valor (no representa realmente un valor) Integridad de Entidad: ningún atributo de la PK puede tomar un valor nulo Integridad Referencial: Si en una relación existe una clave ajena(FK), sus valores deben coincidir con valores de la clave primaria referenciada o ser nulos ○ Esto lo gestiona el gestor de bbdd por defecto 12 reglas de Codd: todo gestor de BBDD las debe cumplir (Realmente son 13, por que van de la 0 a la 12) Regla 0: Regla fundamental. Todo sistema que se defina como sistema de gestión de base de datos relacional, o se anuncie como tal, ha de poder gestionar las bases de datos exclusivamente con sus capacidades relacionales. Regla 1: Regla de la información. Toda la información en una base de datos debe estar representada como valores en la tabla, lo cual incluye, la propia información del diccionario de datos. Regla 2: Regla del acceso garantizado. Se garantiza que todos y cada uno de los datos (valor atómico) de una base de datos relacional son accesibles lógicamente mediante una combinación de nombre de tabla, valor de clave primaria y nombre de columna. Regla 3: Regla del tratamiento sistemático de valores nulos. Los sistemas de gestión de base de datos admiten los valores nulos (distintos de la cadena vacía, los blancos, los ceros o cualquier otro número) para representar la falta de información o información desconocida. Regla 4: Catálogo dinámico en línea basado en el modelo relacional. ○ Catálogo Dinámico en Línea: El catálogo de la base de datos debe ser accesible en tiempo real, lo que significa que puede ser consultado y modificado sin necesidad de detener o reiniciar el sistema de gestión de bases de datos. ○ Basado en el Modelo Relacional: El catálogo debe estar organizado y ser accesible mediante el mismo modelo relacional que se utiliza para los datos de usuario. Es decir, la información sobre la estructura y el contenido de la base de datos (como las definiciones de tablas, vistas, índices, permisos, etc.) debe almacenarse en formato de tablas relacionales. Regla 5: Regla del sublenguaje de datos completo. Un sistema relacional debe permitir varios lenguajes y varios modos de uso terminal (como rellenar formularios, por ejemplo). Sin embargo, debe haber al menos un lenguaje cuyas declaraciones se puedan expresar, mediante una sintaxis bien definida, como cadenas de caracteres y que respalde de forma integral los siguientes aspectos: ○ Definición de datos ○ Definición de vistas ○ Manipulación de datos (interactiva y por programa) ○ Restricciones de integridad ○ Límites de transacción (begin, commit y rollback). Regla 6: Regla de actualización de vistas. El sistema gestor debe ser capaz de actualizar todas las vistas que sean teóricamente actualizables. Regla 7: Inserción, actualización y borrado de alto nivel. El sistema debe proporcionar operadores no solo para recuperar, sino también para insertar, actualizar y borrar conjuntos de datos. Regla 8: Independencia física de los datos. Los cambios que puedan producirse en la bbdd a nivel físico (ficheros que almacenan los datos, discos en los que se ubican…) no deben implicar cambios en las aplicaciones. Regla 9: Independencia lógica de los datos. Los cambios que puedan producirse en la bbdd a nivel lógico, no deben implicar cambios en las aplicaciones que consultan o manipulan datos. Regla 10: Independencia de la integridad. Las restricciones de integridad deben poder especificarse en un sublenguaje relacional y almacenarse en el catálogo, no siendo por tanto la implementación en las aplicaciones que manipulan los datos Regla 11: Independencia de la distribución. La consulta o manipulación de los datos almacenados debe hacerse de la misma manera independientemente de si la BBDD está centralizada o distribuida.El sistema gestor debe soportar 3 tipos de transparencia ○ Localización ○ Fragmentación ○ Replicación Regla 12: La regla de la no subversión. Si el sistema gestor proporciona un lenguaje de bajo nivel para manipular los datos, este no puede permitir saltarse (subvertir) las reglas de integridad definidas sobre la BBDD en el lenguaje de mas alto nivel 2. Normalización 2.1. Introducción Proceso por el que se organizan los atributos y las tablas de una BBDD relacional con el objetivo de minimizar la redundancia del dato. Gasto de almacenamiento Inconsistencias por actualizaciones: si el usuario cambia de dirección, igual es posible tener que cambiar todos los registros. Nota: El resultado de la normalización será tener más relaciones -- redundancia ++joins (peor rendimiento en consultas): ○ Si está controlado se podría plantear la desnormalización 2.2. Conceptos previos Dependencia funcional entre 2 atributos X e Y, Si y sólo si a todo valor de X le corresponde un único valor de y (X → Y);(DNI → DIRECCIÓN)(DNI determina funcionalmente a DIRECCIÓN) Se dice que Y depende funcionalmente de X a X se le denomina como Determinante(de Y) También es correcto decir que X e Y sean un conjunto de atributos en vez de uno simple ○ Nombre depende funcionalmente de NIF Nota: el uso es bueno siempre y cuando X sea clave Dependencia funcional completa:Se dice que el atributo Y es completamente dependiente de X si depende funcionalmente de X y no depende de ningún subconjunto propio de X Como se dice: DIRECCIÓN está determinada| depende funcionalmente de DNI La dependencia funcional se representa como X => Y. Dependencia transitiva:.cuando un atributo A determina un atributo B, y el atributo B determina un atributo C, creando una relación indirecta donde el atributo A también determina el atributo C a través de B. Dependencia multivaluada (usado en la 4FN): se dice que un atributo A multivaluado determina a un atributo B, si a cada valor de A le corresponde un conjunto definido de valores de B (X→→Y) Un atributo es multivaluado cuando para una misma entidad puede tomar varios valores diferentes, con independencia de los valores que puedan tomar el resto de los atributos. 2.3. 1FN - Primera Forma normales Una tabla estará en 1FN si no contiene grupos repetitivos, es decir, cada atributo de una tupla tiene a lo sumo un valor 2.4. 2 FN SI está en 1FN y todos los atributos no principales tienen dependencia funcional completa de la PK( por simplificar se pone PK, pero debería ser de cualquier clave de la relación) Es necesario eliminar las dependencias parciales Truco: Si la clave es simple, ya está en 2FN 2.5. 3 FN SI está en 2FN y además cada atributo que no forma parte de la PK no depende transitivamente de la PK, es decir, si cada atributo no principal depende solo de la clave (no de otro atributo no principal) ○ Deberíamos llevar a C y D a otra relación Dejar a C en la relación principal 2.6. FNBC Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. Aporta respecto de 3FN, que todos los determinantes son clave la dependencia funcional está prohibida por que A no es ninguna clave candidata 2.7. 4 FN Una tabla está en 4FN si y sólo si está en Tercera forma normal o en FNBC (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. 2.8. 5 FN También llamada forma normal de proyección-unión (join) Se usa para para los casos donde se necesita reducir la redundancia de datos en una tabla Se emplea para facilitar el mantenimiento de determinados esquemas de datos complejos, permitiendo garantizar la integridad de los datos. Es necesario esté en 4FN Ejemplo wikipedia: https://en.wikipedia.org/wiki/Fifth_normal_form 2.9. 6 FN Fs una forma avanzada de normalización que se enfoca en descomponer las tablas en una base de datos de manera que cada tabla represente solo una relación temporal mínima. Los atributos de una tabla están organizados de tal manera que cada dependencia funcional es irreducible, lo que significa que las tablas suelen ser extremadamente pequeñas en términos de columnas Es necesario esté en 5FN No hay un límite máximo teórico sobre la cantidad de atributos que puede tener una tabla, pero en la práctica, las tablas suelen ser extremadamente simples y contener pocos atributos debido a la descomposición de las dependencias
