Unidad II. Modelo Relacional (Parte 1)

Modelo Relacional Unidad II Competencia: Interpretar y aplicar el modelo relacional, mediante la teoría de conjuntos y operaciones relacionales, para establecer las bases del diseño de base de datos, de manera organizada y coherente. 2.1....

Modelo Relacional Unidad II Competencia: Interpretar y aplicar el modelo relacional, mediante la teoría de conjuntos y operaciones relacionales, para establecer las bases del diseño de base de datos, de manera organizada y coherente. 2.1. Modelo Relacional: Definición y surgimiento.  Modelo de Datos ▪ Los Modelos de Datos surgieron como una solución de software para almacenar y organizar datos de manera estructurada, permitiendo su persistencia para futuras consultas y procesamiento. ▪ Estos modelos proporcionan un marco para representar las relaciones entre diferentes tipos de datos y facilitar su manejo eficiente en aplicaciones informáticas. Modelo Modelo de Modelo Jerárquico Red Relacional  Modelo Jerárquico y en Red 1960, los modelos de datos predominantes eran en REDES y JERÁRQUICOS. Los registros eran enlazados en forma de grafos o árboles, respectivamente. INFLEXIBLES Para recorrer los árboles en los modelos jerárquicos, debía escribirse un programa que atravesara completamente el modelo de datos en disco, partiendo de su nodo raíz. En los modelos en red, la navegación de los grafos podría ser más compleja dependiendo de las conexiones. Fuente: Team, LearnSQL. com (2021) 53 years of relational databases, LearnSQL.com. Available at: https://learnsql.com/blog/codd-article-databases/ (Accessed: 21 August 2023).  Modelo Jerárquico ▪ Uno de los primeros enfoques desarrollados que organiza los datos en una estructura en forma de árbol. ▪ Cada entidad tiene una relación de padre-hijo claramente definida. ▪ Este modelo fue ampliamente utilizado en los primeros sistemas de gestión de bases de datos debido a su simplicidad y eficiencia en aplicaciones con relaciones de datos bien definidas. MIS (Management Information System) de IBM, uno de los primero SGDB comercialmente disponibles, lanzado en 1968 y popularizado entre 1970 y 1980. Ejemplo 1. Modelo jerárquico que representa la estructura de relaciones en un banco. 2. Este modelo identifica y organiza las siguientes entidades en una estructura de árbol jerárquico (padre-hijo, con relaciones de uno a muchos) de la siguiente manera: 3. Banco -> Cliente -> Cuenta -> Transacción -> Abono. Ejemplo del Modelo Patrón Claro y Estable en Red Tiene Transacc Cliente1 Cuenta1.1 Abono1.1 ión1.1 Transacc Abono1.2 Cuenta1.2 ión1.2 Cuenta2.1 Transacc Abono2.1 Banco Cliente2. ión2.1 Transacc Abono2.2 Cuenta2.2.1 ión2.2.1 Transacc Cliente3 Cuenta3.1 Abono3.1 ión3.1  Modelo en Red ▪ En un Modelo en Red, las relaciones entre las entidades no están limitadas a una estructura de árbol estricta como en el modelo jerárquico. ▪ En lugar de tener solo una relación padre-hijo, una entidad puede estar relacionada con múltiples entidades en diferentes niveles. ▪ Esto permite una mayor flexibilidad, ya que una entidad puede tener múltiples padres o estar relacionada de manera directa con varias otras entidades. Ejemplo 1. Modelo en Red que representa la estructura de relaciones en un banco. 2. Este modelo identifica y organiza las siguientes entidades en una estructura de red (padre-hijo, con relaciones de muchos a muchos (M:N)) de la siguiente manera: 3. Banco -> Cliente (M) -> Cuenta (N)-> Transacción (M)-> Abono (N). Ejemplo del Modelo Relaciones de Muchos a en Red Muchos (M:N) Tiene Transacc Cliente1 Cuenta1.1 Abono1.1 ión1.1 Transacc Abono1.2 Cuenta1.2 ión1.2 Cuenta2.1 Transacc Abono2.1 Banco Cliente2. ión2.1 Transacc Abono2.2 Cuenta2.2.1 ión2.2.1 Transacc Cliente3 Cuenta3.1 Abono3.1 ión3.1  Modelo Relacional ¿Quién lo creó y cuando surgió? Publicado en Junio de 1970 Edgar Frank ‘Ted’ Codd Laboratorio de Investigación Sentó las bases de IBM en San José, Modelo Independencia de Álgebra California. Relacional los Datos Relacional Normalización Integridad Acceso No Procedural a los Facilidad de Uso Datos Después de 50 años, Fuente: Team, LearnSQL. com (2021) 53 years of relational databases, LearnSQL.com. Available at: https://learnsql.com/blog/codd-article-databases/ (Accessed: 21 August 2023). Sigue siendo relevante  Modelo Relacional 1. En 1954, IBM inició el proyecto de System R como prototipo de SGBDR (Sistema de Gestión de Bases de Datos Relacional), el cual tenía como objetivo demostrar que un sistema relacional podría ser tan eficiente y práctico como los sistemas jerárquicos y de red existentes. 2. Codd no formó parte del equipo de System R. 3. Dio origen a SEQUEL (Structured English Query Language), que se convirtió en el estándar de facto para el manejo de bases de datos relacionales. Creado por: Don Ray Chamberlin Boyce 4. En 1976, el nombre de SEQUEL se cambió por SQL debido a problemas de marca registrada.  Modelo Relacional 1. En 1979, Oracle una empresa fundada por Larry Ellison comercializó la primera versión de SGBDR llamada Oracle V2. Larry Ellison 2. Este producto fue uno de los primeros sistemas de bases de datos en implementar el Modelo Relacional desarrollado por Edgar F. Codd, y jugó un papel crucial en la popularización de este enfoque en la industria del software. 3. Oracle V2 no utilizaba el estándar SQL tal como lo conocemos hoy en día, aunque su lenguaje de consulta estaba basado en las ideas de SQL. Es importante señalar que, en 1979, SQL aún no era un estándar oficial.  Modelo Relacional 1. IBM, a pesar de la resistencia inicial interna hacia el paradigma relacional, eventualmente lanzó SQL/DS en 1981, que fue su primer SGBDR disponible comercialmente. 2. Posteriormente, IBM introdujo DB2 en 1983, que se convirtió en uno de los productos más importantes de la compañía en el área de bases de datos relacionales. 3. Actualmente, siendo ampliamente utilizado en muchas grandes empresas, especialmente en sectores como la banca, seguros, y otras industrias que requieren alta disponibilidad, rendimiento y escalabilidad. 4. En 1986, SQL fue adoptado como un estándar por el American National Standards Institute (ANSI) y más tarde por la International Organization for Standardization (ISO).  Modelo Relacional Codd vio esta inflexibilidad como un problema. Propuso un nuevo modelo de base de datos llamado modelo relacional, basado en la noción matemática de relación. Proviene de la teoría de relaciones y la teoría de conjuntos. 𝑺𝒖𝒃𝒄𝒐𝒏𝒋𝒖𝒏𝒕𝒐 𝒅𝒆 Relación Producto cartesiano Conjuntos Fuente: Team, LearnSQL. com (2021) 53 years of relational databases, LearnSQL.com. Available at: https://learnsql.com/blog/codd-article-databases/ (Accessed: 21 August 2023).  Modelo Relacional Ejemplo: Si se tienen dos conjuntos 𝑨𝟏 = ሼ1,3} y 𝑨𝟐 = ሼ𝑎, 𝑏, 𝑐} entonces 𝑨𝟏 × 𝑨𝟐 = ሼ 1, 𝑎 , 1, 𝑏 , (1, 𝑐), 3, 𝑎 , 3, 𝑏 , (3, 𝑐)} 𝑺𝒖𝒃𝒄𝒐𝒏𝒋𝒖𝒏𝒕𝒐 𝒅𝒆 Conjuntos de Tuplas Generado Relación Producto cartesiano Conjuntos Fuente: Team, LearnSQL. com (2021) 53 years of relational databases, LearnSQL.com. Available at: https://learnsql.com/blog/codd-article-databases/ (Accessed: 21 August 2023).  Modelo Relacional ▪ Edgar Codd extendió la noción matemática para aplicarla a las Bases de Datos. 1. Una relación se compone del esquema de relación (o intensión de la relación), que consiste en un nombre de la relación R y un conjunto de campos 𝑐1 , 𝑐2 , … , 𝑐𝑛 , y de la extensión (datos concretos). Esquema de la relación (intensión) Atributo EmpleadoID Nombre FechaContratación 1 Juan Pérez 10-09-2024 2 Sukey Nakasima 10-09-2024 Tuplas Valor (mismo dominio)  Modelo Relacional Empleadoi 𝐸𝑚𝑝𝑙𝑒𝑎𝑑𝑜𝐼𝐷: 𝑒𝑛𝑡𝑒𝑟𝑜, 𝑁𝑜𝑚𝑏𝑟𝑒: 𝑐𝑎𝑑𝑒𝑛𝑎, 𝐹𝑒𝑐ℎ𝑎𝐶𝑜𝑛𝑡𝑟𝑎𝑡𝑎𝑐𝑖ó𝑛: 𝑐𝑎𝑑𝑒𝑛𝑎 Empleado1 (‫𝐷𝐼𝑜𝑑𝑎𝑒𝑙𝑝𝑚𝐸ۦ‬: 1, 𝑁𝑜𝑚𝑏𝑟𝑒: "𝐽𝑢𝑎𝑛 𝑃é𝑟𝑒𝑧", 𝐹𝑒𝑐ℎ𝑎𝐶𝑜𝑛𝑡𝑟𝑎𝑡𝑎𝑐𝑖ó𝑛: "10 − 09 − 2024"ۧ) Empleado2 (‫𝐷𝐼𝑜𝑑𝑎𝑒𝑙𝑝𝑚𝐸ۦ‬: 2, 𝑁𝑜𝑚𝑏𝑟𝑒: "𝑆𝑢𝑘𝑒𝑦 𝑁𝑎𝑘𝑎𝑠𝑖𝑚𝑎", 𝐹𝑒𝑐ℎ𝑎𝐶𝑜𝑛𝑡𝑟𝑎𝑡𝑎𝑐𝑖ó𝑛: "10 − 09 − 2024"ۧ) Lo que habían sido páginas de código en una red o base de datos jerárquica se convirtió en una simple expresión en el lenguaje de consulta de Codd.  Modelo Relacional El Modelo Relacional perseguía los siguientes objetivos: 1. Independencia Física: El modo cómo se almacenan los datos no debe influir en su manipulación lógica y, por tanto, almacenamiento físico. Los usuarios que acceden a esos datos no han de modificar sus programas por cambios en la capa física. Fisico Servidor Datos Archivos  Modelo Relacional 2. Independencia Lógica: Se refiere a la capacidad de cambiar la estructura lógica de la base de datos (agregar, modificar o eliminar tablas y vínculos) sin afectar las aplicaciones que utilizan los datos. Las consultas y operaciones de las aplicaciones siguen siendo válidas independientemente de los cambios en la estructura lógica. Front-End Relación Original Persona (RFC, nombre, apellido, sexo, estadoCivil, fechaNacimiento) Relación Actual Persona (RFC, nombre, apellido, sexo, estadoCivil, fechaNacimiento, ciudad)  Modelo Relacional 3. Flexibilidad: Ofrecer a cada usuario los datos de la forma más adecuada a la correspondiente aplicación. Front-End Relaciones  Modelo Relacional 4. Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme (tablas), lo que facilita la concepción y manipulación de la BD por parte de los usuarios. Alumno Matrícula Nombre1 Nombre2 ApellidoPaterno ApellidoMaterno 12345T Sukey Sayonara Nakasima López 9876M María Guadalupe López Valenzuela  Modelo Relacional 5. Sencillez: Las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo relacional (MR) sea fácil de comprender y de utilizar por parte del usuario final. Los usuarios ven la base de datos relacional como una colección de tablas, y al ser la tabla la estructura fundamental del modelo, éste goza de una gran uniformidad, lo que, unido a unos lenguajes no navegacionales y muy orientados al usuario final, da como resultado la sencillez de los sistemas relacionales.  Modelo Relacional Relación: Es el elemento fundamental del modelo relacional (de ahí el nombre del modelo), y se puede representar en forma de tabla: Cardinalidad Alumno Número de Fila Matrícula Nombre1 Nombre2 ApellidoPaterno ApellidoMaterno 12345T Sukey Sayonara Nakasima López 9876M María Guadalupe López Valenzuela Grado Número de Columnas  Restricciones Relacionales Son reglas o condiciones que se aplican a los datos almacenados en una base de datos relacional para garantizar la integridad, la coherencia y la validez de los mismos. ▪ De dominio: El valor en el campo debe ser de atómico (de un solo tipo), por lo que es importante que exista correspondencia entre Atributo-Valor. Persona Persona Hobbies Hobbies X 123458,leer Leer  Restricciones Relacionales ▪ De Clave: Es una restricción de valor único. Asegura que los valores en una columna sean únicos en toda la relación. Relación Clave ApellidoPate ApellidoMate Primaria Matrícula Nombre1 Nombre2 rno rno (Llave Primaria) 12345 Sukey Sayonara Nakasima López  Restricciones Relacionales ▪ Integridad de Relaciones: Ninguna Clave Primaria puede contener valores nulos. Alumno X Matrícula Nombre1 Nombre2 ApellidoP ApellidoM aterno aterno NULL Sukey Sayonara Nakasima López Alumno Matrícula Nombre1 Nombre2 ApellidoP ApellidoM aterno aterno 12345 Sukey Sayonara Nakasima López  Restricciones Relacionales ▪ Integridad referencial: Una tupla que hace referencia a otra o a la misma relación, debe referirse a una tupla existente en dicha relación. Alumno Matrícula Nombre1 Nombre2 ApellidoPate ApellidoMate Cve_Carrera rno rno 12345 Sukey Sayonara Clave Nakasima López Carrera 2 X Cve_Carre Nombre_Carrera Foránea ra (Llave Foránea) 1 Licenciado en Sistemas Computacionales Impide eliminar un registro si hay registros relacionados en otra relación.  Restricciones Relacionales Alumno Matrícula Nombre1 Nombre2 ApellidoPaterno ApellidoMaterno Cve_Carrera 12345 Sukey Sayonara Nakasima López 2 Se hace referencia a otra tupla Carrera mediante una Clave Foránea (llave Cve_Carr Nombre_Carrera foránea), sin embargo, pudiera era 1 Licenciado en Sistemas contener valores nulos. Computacionales 2 Ingeniería en Computación  Los Catálogos de Opciones en las Bases de Datos Un catálogo es una relación que contiene información relevante sobre las opciones finales para un usuario en una aplicación. Ejemplo: Se solicita incluir un catálogo de Ciudades, ¿Cuál sería su finalidad? 1. Consistencia: Evita errores de escritura, duplicación y discrepancias en los nombres de ciudades.  Los Catálogos de Opciones en las Bases de Datos 2. Eficiencia en Almacenamiento: En lugar de repetir el nombre de una ciudad en múltiples registros (por ejemplo, en una tabla de direcciones), solo necesitas almacenar un identificador único de ciudad en esos registros y hacer referencia al catálogo (integridad referencial). Esto ahorra espacio de almacenamiento y facilita el mantenimiento. Dirección Ciudad Calle Cve_Ciudad Cve_Ciudad Ciudad Abedules 1 1 Tijuana Abetos 1 Claveles 1  Los Catálogos de Opciones en las Bases de Datos 3. Mantenimiento simple: Si en algún momento necesitas cambiar el nombre o detalles de una ciudad, solo necesitas actualizar el catálogo en un solo lugar. Todos los registros que hacen referencia a esa ciudad automáticamente reflejarán el cambio, evitando actualizaciones tediosas en varios lugares.  Los Catálogos de Opciones en las Bases de Datos 4. Estadísticas y Análisis: Podríamos necesitar saber ¿de qué ciudades son nuestros estudiantes?, para determinar foráneos o locales y ofrecerles algún tipo de beca o ayuda. En términos generales, tener catálogos en tu base de datos puede mejorar la consistencia, eficiencia y confiabilidad de los datos, facilitando la administración y el uso de la información relacionada con el en tu sistema.  Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) ▪ Con base a la siguiente información, identifica y define las; relaciones, atributos, clave(s) primaria(s) y foránea(s). ▪ Es importante que respetes las Restricciones de Relación, vistas previamente. ▪ A continuación, se muestran los actores del sistema “Biblioteca UABC”. ✓ Un ALUMNO de la UABC, puede solicitar libros en préstamo. ✓ Información General del Alumno: nombre completo, número de teléfono celular y de casa, semestre actual y la carrera que cursa. ✓ El alumno puede solicitar el o los LIBROS en préstamo. Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) ✓ Los LIBROS están caracterizado por: código de barras, titulo, editorial, año, ISBN y nombre del autor. Con base en las siguientes suposiciones: 1. Un TÍTULO de libro solo tiene un ISBN. 2. Un AUTOR puede tener en su haber uno o más LIBROS. 3. Una EDITORIAL puede publicar muchos LIBROS Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) ✓ Una biblioteca para poder procesar la SOLICITUD DE PRÉSTAMO debe solicitarle al alumno su matrícula, el cual al ser dato único, podrá acceder a la información general del alumno, tal como; nombre completo, número de teléfono celular y de casa, semestre actual y la carrera que cursa. Además, deberá marcar el código de barras de los libros solicitados. Con base en las siguientes suposiciones: 1. Se deberá CONSIDERAR un FOLIO de la SOLICITUD DE PRÉSTAMO, ya que, si el usuario quiere extender la vigencia de préstamo de libro, solo deberá de cambiar el estado de un atributo {E= Entregado, P = Prestado, EP = Extensión de Préstamo} relacionado a este folio. 2. Un ALUMNO puede SOLICITAR EL PRÉSTAMO de N LIBROS. Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) Banco “Tijuana” ✓ El banco “Tijuana” tiene sucursales en sus 7 municipios y por cada municipio las sucursales son distribuidas en las distintas colonias, por ejemplo; La sucursal 017 Tijuana- Otay Otay. Los datos requeridos son; Clave_Sucursal, Nombre_Sucursal, Municipio, Colonia. ✓ A cada sucursal se le asigna un monto por activos (importe en pesos). ✓ Uno de los principales servicios de este banco, es el ofrecer préstamos a sus clientes. Para poder realizar este proceso, el banco debe conocer; código_cliente, nombre_completo_cliente, dirección, correo_electrónico. Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) ✓ El código de cliente está asociado con una cuenta bancaria y dicha cuenta está asociada a una sucursal (donde se realizó su apertura) y la cual cuenta con un saldo. ✓ Finalmente, para realizar el proceso de solicitud de préstamo, el cliente acude a una sucursal del banco “Tijuana”, proporciona su código de cliente y solicita un importe X como préstamo. Práctica #1. Identificar y definir relaciones con sus componentes básicos (atributos, clave(s) primaria(s) y foránea(s)) Requerimientos de Entrega ✓ Con base a la narrativa del contexto, identifique las Relaciones y defina sus atributos, clave(s) primaria(s) y foránea(s), así como las restricciones integridad relacional y de referencia. ✓ Explicar las suposiciones que se realizaron y por qué decidieron diseñarlo de esa manera. ✓ Este ejercicio se realizará en EQUIPO, deberá entregarse en Blackboard en formato PDF, deberá contener una portada. ✓ El EQUIPO #6 presentará en clase las relaciones identificadas acerca de la Biblioteca “UABC”. Hasta aquí lo vamos a dejar…!