B3-T2_Modelo LÓGICO Relacional Flashcards
Esquematiza el proceso de creación de BBDD:
1º Modelo CONCEPTUAL E/R (estructural) o DFD (funcional) => independiente de todo.
2º Modelo LÓGICO (dependiente del tipo de BD: relacional, en Red y Jerárquico) => tienen sus propias reglas de TRANSFORMACIÓN.
3º Modelo FÍSICO (dependiente del SGBD: Oracle, MySQL, MongoDB, …) => esto se programa con un lenguaje de BD (con las sentencias DDL de SQL u otro lenguaje).
*Un modelo lógico de datos es un modelo que no es específico de una base de datos que describe aspectos relacionados con las necesidades de una organización para recopilar datos y las relaciones entre estos aspectos.
¿Cuáles son los Modelos LÓGICOS de BBDD?
*Relacional (SQL)
*Modelo en Red
*Jerárquico
*Orientado a Objetos
*Documental
*NO-Relacional (NoSQL)
NOTA: el RELACIONAL es el + usado y utiliza SQL, aunque esta siendo superado por el NO-Relacional (NoSQL)
¿En qué se diferencian el Modelo RELACIONAL del de NO-Relacional?
En las bases de datos RELACIONALES la información se organiza de forma estructurada en tablas relacionadas entre sí. Además de SQL, utiliza: MariaDB, MySQL, Oracle, …
Las NO-Relacionales almacena los datos en documentos, por tanto son más flexibles. Al no estar los datos estructurados, permite almacenar y recuperar datos en formatos que no sean tablas, ej: CLAVE/VALOR.
Estos sistemas se conocen como NoSQL (MongoDB, Cassandra, BigTable o Hadoop).
¿Qué objetivo tiene la arquitectura ANSI/SPARC?
También denominada arquitectura de 3 esquemas, y tiene como objetivo separar las BBDD de las aplicaciones de usuario => busca independencia entre el nivel físico y el lógico..
Esta separación en 3 niveles permite al usuario visualizar los niveles de un sistema de BD:
*Nivel EXTERNO (de los usuarios): vistas
*Nivel CONCEPTUAL (del sistema): tablas/relaciones
*Nivel INTERNO (almacenamiento interno para diseñar la BD): detalles de almacén e índices.
¿Qué garantiza el estándar ODBC (Open DataBase Connectivity)?
Es un estándar de acceso a las bases de datos.
El objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin importar qué sistema de gestión de bases de datos (DBMS) almacene los datos.
¿En qué consiste la arquitectura de 3 o n capas?
En añadir una CAPA INTERMEDIA entre la capa del cliente y la del servidor del SGBD.
Esta capa, llamada “Servidor Web” o “Servidor de Aplicaciones”, gestiona las solicitudes o peticiones del cliente (REQUEST) y las respuestas del servidor (RESPONSIVE).
Este sistema esta abierto a futuras divisiones de las capas existentes, y cualquiera podra ejecutarse en plataformas o sistemas independientes.
Ej: ERP o CRM (estas plataformas de gestión empresarial son ejemplos de esta arquitectura).
Expón utilidades del SGBD:
*CARGA DE DATOS: carga y conversión de datos.
*COPIA DE SEGURIDAD: completo, diferencial e incremental (desactiva bit de modificado).
*HERRAMIENTAS PARA LOS DISEÑADORES: CASE (para reducir costo de tiempo y dinero) y Diccionarios de Datos (aumentan los detalles del catálogo).
*ENTORNOS DE DESARROLLO: Eclipse, VS, …
*DB/DC: SW para garantizar la conectividad de usuarios con el SGBD.
*OTROS: Reorganización del almacenamiento o la Monitorización del rendimiento.
Nombre algunos SGBD libres y comerciales:
*LIBRES: MySQL y PostgreSQL, son los + conocidos.
*COMERCIALES: Oracle o Microsoft SQL Server, x ejemplo.
Clasifica los SGBD según el modelo de datos en que esté basado:
*Modelo de datos RELACIONAL: presenta la BD como una colección de TABLAS, cada una puede guardarse como un archivo separado (SQL, MySQL, MariaDB, Oracle, …).
*Modelo de datos de OBJETOS: define la BD como objetos (propiedades y operaciones), organizados en clases jerárquicamente.
*Modelo de datos JERÁRQUICO: ahora se llama HEREDADO, pues representa los datos en forma de una jerarquía de árboles.
*Modelo de datos en RED: representa los datos como tipos de registros.
*Modelo de datos NO RELACIONAL o NoSQL: se ha convertido en tendencia por si gran capacidad de escalado (MongoDB, Cassandra, BigTable, Hadoop, …)
*Modelo de datos XML: para el intercambio de datos a través de internet. El uso de etiquetas permite su anidamiento en estructuras jerárquicas en árbol.
¿Qué es un DBA?
DataBase Administrator o Administrador de Base de datos.
Se encarga de gestionar las cuentas, privilegios, seguridad, monitorización, recursos HW y SW …
¿En qué se diferencian el Modelo E/R y el Modelo RELACIONAL?
En el RELACIONAL sólo hay relaciones, NO hay ni Entidades ni Tipos de Entidad => su objeto principal es la RELACIÓN.
En cambio, en el E/R (Entidad/Relación), si hay Entidad y Tipo de Entidad, además de Relaciones.
EJEMPLO:
E/R:
-Tipo de Entidad: LIBRO
-Atributos: ISBN, Título, …
RELACIONAL:
-LIBRO (ISBN, Título, …) => Esquema o Intensión
¿Cómo se llama al conjunto de RELACIÓN (con sus atributos)?
Esquema o Intensión
-LIBRO (ISBN, Título, …) => Esquema o Intensión
¿Qué son los dominios de valores de los atributos?
El Dominio de Valores es el conjunto de valores posible que puede asumir CADA atributo (cada atributo tiene uno).
Permite limitar el tamaño del atributo.
El mismo dominio puede definirse en diferentes atributos.
Cada atributo de una relación se caracteriza por un nombre y por un dominio.
El dominio indica qué valores pueden ser asumidos por una columna de la relación.
Un dominio describe un conjunto de posibles valores para cierto atributo.
Distintos tipos de dominios son: enteros, cadenas de texto, fecha, sin procedimientos, etc.
¿Qué es el GRADO de la Relación en el Modelo RELACIONAL?
El número de atributos de la relación:
LIBRO (ISBN, Título, Fecha publicación) => GRADO 3
NOTA: en el Modelo E/R, el grado es el número de Tipos de Entidades que relaciona o enlaza la relación (la relación se representaba en u rombo).
CLIENTE —->Relación<——-COMPRAS => Grado 2
¿Qué es la CARDINALIDAD (Extensión) de la Relación en el Modelo RELACIONAL?
El número de tuplas o registros:
LIBRO (ISBN, Título, Fecha publicación) =>
TUPLAS:
(12342, El Elfo Oscuro, 24/06/2003)
(98767, El Nombre del Viento, 10/12/2002)
=> GRADO 3 (nº atributos) y CARDINALIDAD 2 (nº tuplas)
NOTA: en el modelo E/R la cardinalidad representa el número máximo y mínimo de las ocurrencias entre una ENTIDAD y otra.
Realiza una comparación de la terminología o conceptos en el mundo de las BBDD:
RELACIONAL —- TABLA —- FICHERO:
*tupla —- fila —- registro
*atributo —- columna —- campo
*grados —- nº columnas —- nº campos
*cardinalidad —- nº filas —- nº registros
¿En qué se transforma un Tipo de Entidad del Modelo E/R en el Modelo RELACIONAL?
En una RELACIÓN.
CLIENTE —->Relación<——-COMPRAS => estos Tipos de Entidad del E/R se transforman en RELACIONES en el Modelo RELACIONAL.
NOTA RECORDATORIA: la relación se representaba dentro de un rombo y los tipos de entidad, dentro de un cuadrado.
Explica el paso de Clave PRIMARIA a Clave AJENA en la “Relación 1 a N:
Es Relación 1,N, cuando, en el caso, x ejemplo, de un autor que puede escribir n libros o un cliente comprar n PCs.
Entonces usaremos el sistema de “Propagación de Claves” cuando necesitemos usar la clave primaria (primary key) de la tupla de una relación, en la tupla de otra relación, pasando a llamarse “Clave Ajena”.
Ponemos el ejemplo de la foto adjuntada, donde para identificar el autor de cada libro, añadimos otro atributo a la relación “Libro”, que rellenaremos con la clave primaria (DNI) de la relación “Autor” => una vez la tengamos en esta última relación, pasará a llamarse CLAVE AJENA (x ser la clave de otra relación, aunque ahora no la usemos como clave literalmente)
*Esto se conoce como: Propagación de clave del lado del 1 (Autor) al lado de n (Libro) => con este sistema pasamos de relación 1 a N (E/R) a Relacional.
Diferencia entre la relación 1 a N y la M a N:
En las Relaciones M a N, no se puede usar la “Propagación de Clave”, se tiene que hacer una relación NUEVA, donde la clave es compuesta (abarca más de un campo), porque es una relación muchos a muchos.
En el ejemplo de la foto, mostramos una transformación de M, N (E/R) a Relacional.
Vemos la nueva relación: Trabaja, y la clave compuesta de cada tupla seria:
(10, 77) => 1ª tupla
(10, 88) => 2ª tupla
*Indicamos que el empleado Dani trabaja en ambos departamentos.
¿Qué diferencia hay entre las relaciones M a N y las N-arias?
El sistema es el mismo, pero en las N-arias, en lugar de coger 2 claves, coge más claves.
*Ambos relaciones E/R (M, N y N-arias), por medio de dicho movimiento de claves, se transforman en en sistema RELACIONAL.
Expón Reglas de TRANSFORMACIÓN del modelo E/R al Relacional:
- Lo 1º ha tener muy claro es que el Tipo de Entidad (del E/R) se transforma en una Relación (del Relacional).
- Las Relaciones 1 a N (E/R), se transforman a Relacional, por medio de la “Propagación de Clave”: pasando la clave PRIMARIA a otra relación, llamándose ahora “Clave AJENA”.
- La transformación del M a N (E/R) a Relacional, no se puede usar la “Propagación de Clave”, se tiene que hacer una relación NUEVA, donde la clave es compuesta (abarca más de un campo), porque es una relación muchos a muchos.
- Las Relaciones N-arias (E/R), se transforman a Relacional, igual que el M a N, pero en ugar de coger 2 claves, coge más claves.
Expón algunas CARACTERÍSTICAS del modelo RELACIONAL:
*Los valores de los atributos (columnas) tienen que ser atómicos (únicos). Aquí no existe el MultiValor, como en E/R (se representaba en un doble circulo).
*NO repetición de tuplas =>cada tupla tiene que tener su clave PRIMARIA, que es un atributo o conjunto de atributos que identifiquen a la tupla.
*NO hay orden ni en las TUPLAS (filas) ni en los ATRIBUTOS (columnas)
Expón algunas RESTRICCIONES del modelo Relacional:
*Se usa el “valor nulo” como “ausencia de valor”.
*INTEGRIDAD DE ENTIDAD: ninguna clave primaria (PK) puede ser nula y ningún atributo de la PK compuesta puede tomar valor nulo.
*INTEGRIDAD REFERENCIAL: si en una Relación existe una Clave AJENA, sus valores deben coincidir con valores de la clave primaria referenciada o ser NULOS.
NOTA: sólo se puede poner valores NULOS en claves AJENAS, por ejemplo, cuando no tengamos el autor del libro “El Ocho” en la relación de la clave primaria o referencial, porque no lo hubiera escrito ni Pepe ni Luis.
¿Cuáles son las 12 Reglas de Codd (en realidad 13, porque van del 0 al 12) que debe cumplir cualquier SGBD para poderse considerar RELACIONAL?
Regla 0: Regla FUNDAMENTAL.
Todo sistema ha de poder gestionar las bases de datos exclusivamente con sus capacidades relacionales.
Regla 1: Regla DE LA INFORMACIÓN.
La información se representa con valores en tablas.
Regla 2: Regla DEL ACCESO GARANTIZADO.
Todos los datos son accesibles mediante una combinación de nombre de tabla, valor de clave primaria y nombre de columna => SIN AMBIGÜEDAD => requisito fundamental PK.
Regla 3: Regla DEL TRATAMIENTO SISTEMÁTICO DE VALORES NULOS.
Admiten los valores nulos.
Regla 4: CATÁLOGO DINÁMICO EN LINEA BASADO EN EL MODELO RELACIONAL. El sistema debe soportar un catálogo en línea, (catálogo relacional), que da acceso a la estructura de la BD y que debe ser accesible a los usuarios autorizados.
Regla 5: Regla DEL SUBLENGUAJE DE DATOS COMPLETO.
Un sistema relacional debe permitir varios lenguajes. Pero 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 LA ACTUALIZACIÓN DE VISTAS. Todas las vistas que son teóricamente actualizables son también actualizables por el sistema.
Regla 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL => sobre conjuntos de tuplas.
Regla 8: INDEPENDENCIA FÍSICA DE LOS DATOS. Las aplicaciones permanecerán inalteradas cuando se realizan cambios en las representaciones de almacenamiento.
Regla 9: INDEPENDENCIA LÓGICA DE LOS DATOS. Las aplicaciones permanecerán inalteradas cuando se realizan cambios en las tablas.
Regla 10: INDEPENDENCIA DE LA INTEGRIDAD.
Debe ser posible cambiar esas restricciones sin afectar innecesariamente a las aplicaciones existentes.
Regla 11: INDEPENDENCIA DE LA DISTRIBUCIÓN.
Los usuarios deben tener siempre la impresión de que los datos se encuentran en un solo lugar.
Regla 12: La regla DE LA NO SUBVERSIÓN.
Si un sistema relacional tiene un lenguaje de bajo nivel (un registro cada vez), ese nivel bajo no puede utilizarse para subvertir o eludir las reglas y restricciones de integridad expresadas en el lenguaje relacional de alto nivel (varios registros cada vez).
¿Qué se conoce por “clave”?
Una clave es un atributo o conjunto de atributos (clave compuesta), que identifican inequívocamente a una tupla.
EJEMPLO: en el ejemplo de la foto podemos apreciar que la clave es DNI, porque no habrán 2 iguales.
Diferencia entre clave CANDIDATA, ALTERNATIVA y PRIMARIA:
*Clave CANDIDATA: son todas las posibles claves que podemos elegir.
*Clave PRIMARIA (PK): es la clave que ELIGES => PORQUE SÓLO SE PUEDE TENER UNA CLAVE.
*Clave ALTERNATIVA: son las claves que NO eliges.
EJEMPLO: en el ejemplo de la foto podemos ver que las 2 posibles claves son DNI y nº de la Seguridad Social, porque son las únicas que no se pueden repetir.
Entonces las 2 son las claves “candidatas”,
la”primary key” es DNI (la que elegimos) y
la clave “alternativa” es NSS.
¿Qué es una SuperKey?
En el Modelo Relacional, una SuperClave (SuperKey) es cualquier COMBINACIÓN de atributos que identifiquen de manera inequívoca a una tupla de una relación. A diferencia de la PK, que sólo puede ser 1.
*SÓLO sirve para hacer ANÁLISIS.
EJEMPLO (foto): en el ejemplo vemos que {DNI, colorOjos} puede identificar a una tupla, al igual que el resto de combinaciones del ejemplo, excepto {colorojos, fechanacimiento}, que NO identificaría de manera inequívoca a una tupla.
*Las Claves CANDIDATAS (mínimas o irreducibles) son:
{DNI}
{NSS}
¿En qué se diferencian Superkey de Clave Candidata?
La SK comprende todos los atributos para identificar a la tupla, sean o no dispensables (todas las claves), y la CANDIDATA sólo contiene los atributos indispensables.
Es decir, la CANDIDATA es una “mínima” Superkey => NO puede ser reducida a una versión más simple eliminando atributos y la superkey SI.
EJEMPLOS (foto): todas son SK, excepto las que NO se pueden reducir:
{DNI}
{NSS}
Pon un ejemplo de NORMALIZACIÓN:
EJEMPLO DE ELIMINAR REDUNDANCIA => la podemos reducir buscando dichas DEPENDENCIAS FUNCIONALES entre atributos.
Por ejemplo (foto), si en varios campos de diferentes tuplas tenemos el mismo código postal (28040) y/o ciudad (Madrid) => dependen uno de otro.
Estos campos se unificarían creando otra tabla o relación (Localización) para introducir esas redundancias en sus filas.
Es decir, pasamos de 1 relación a 2 relaciones para separar esas redundancias.
Define DEPENDENCIA FUNCIONAL:
Se busca para NORMALIZARLAS y se representa: x —-> y
NOTA: EL ATRIBUTO QUE SEA CLAVE PRIMARIA SIEMPRE DETERMINA AL RESTO.
Una Dependencia Funcional entre 2 atributos (x e y) o grupos de atributos, se da SÓLO si a todo valor de “x” le corresponde un único valor de “y” (x —-> y), es decir, si para cada valor de “x” siempre tenemos el mismo valor en “y”.
En el EJEMPLO de la foto, buscamos que valores determinan a que valores (que valor de un atributo (columna) es siempre = en otra columna y vemos que el atributo “a” DETERMINA a “c” (el valor de “a” siempre es el mismo en “c”).
**La PK (f) siempre va a determinar funcionalmente al resto de los atributos, PORQUE COMO SÓLO HAY 1 POR TUPLA, CADA PK SIEMPRE TENDRÁ LOS MISMOS ATRIBUTOS ASOCIADOS => es decir, cada vez que aparezca la pk 1 aparecerán los atributos: 1, xx, 3, 4.
Para la PK 2 => 1, yy,3, a
y la PK 3 siempre tendrá => 1, xx, 3, b.
En los casos en que la Dependencia Funcional se diera entre atributos normales o no principales (dependencia Transitiva), habría que NORMALIZAR, para luego poder actualizar de manera más rápida al unísono.
¿Cuándo estará una tabla (relación) 3ª Forma Normal (3FN)?
Si está en 2FN y no hay DEPENDENCIAS TRANSITIVAS, es decir, NO pueden haber dependencias que NO sean de la PK (si depende también de otro atributo no principal => no sera 3FN).
DEPENDENCIAS TRANSITIVAS: cuando la PK determina a un atributo no principal y este, a su vez, determina a otro atributo no principal.
Ejemplo en foto.
¿Cuándo estará una tabla (relación) Forma Normal BOYCE-CODD (FNBC)?
Si esta en 3FN y los únicos “determinantes” son claves candidatas (todas las claves), es decir, todo lo que no sea clave NO puede determinar a ningún otro atributo.
Es decir, todo lo que no cumpla esta filosofía se va a otra relación (tabla) => así evitamos redundancias, que es el principio de la Normalización.
NOTA: es lo mismo que la 3FN, pero este también incluye los casos en que un atributo no principal determine a una clave, aunque también acoge el caso de 3FN de NO determinantes entre atributos no principales.
Adjunto foto con ambos casos (arriba: 3FN y debajo: FNBC).
¿Cuándo estará una tabla (relación) 4ª Forma Normal (4FN)?
Sólo estarás en 4FN si, o bien NO hay Dependencias MULTIVALUADAS o sólo hay una Dependencia Multivaluada NO trivial implicada por la clave CANDIDATA
NOTA: Dependencias MULTIVALUADAS (Ej- Matemáticas -> Pepe y Juan) => producen una repetición de información muy grande.
*La finalidad de esta Normalización es romper la multivaluada dividiéndola en 2 relaciones, como se aprecia en la foto adjuntada.
¿Cuáles son las operaciones BÁSICAS del álgebra relacional?
- selección
- proyección
- producto cartesiano
- unión
- diferencia
¿Qué es el cálculo relacional y que dos tipos existen?
- Modelo matemático equivalente al algebra relacional
- Declarativo
- Existen dos tipos: basado en tuplas y en dominios.
