Resumen para Practicar 10 Paginas PDF

-Modelo relacional: nos permite expresar conceptos del mer pero con un nivel ya superior de abstracción, los conceptos y vínculos los transformamos posteriormente. Una base de datos para el modelo relacional es una colección de relaciones. Aquí una relación significa una relación matemática e inform...

-Modelo relacional: nos permite expresar conceptos del mer pero con un nivel ya superior de abstracción, los conceptos y vínculos los transformamos posteriormente. Una base de datos para el modelo relacional es una colección de relaciones. Aquí una relación significa una relación matemática e informalmente una tabla donde guardamos los datos que necesitamos. Las tablas están compuestas por filas, esas filas contienen una colección de valores que en conjunto representan un hecho del mundo real. Lo que en el Mer era una instancia de una entidad acá es una fila (un ejemplar) (una fila es tanto una entidad como vinculo que era en el mer). No existe el concepto de vinculo como tal, acá solo existen las relaciones. Columnas: además de las filas tenemos columnas que se entrelazan con las filas. En las columnas debe haber coincidencias con el tipo de dato almacenado en cada lugar, no puedo tener un desorden de filas y columnas en una misma columna todas las filas deben guardar el mismo tipo de dato. Conceptos: Dominio Este término se refiere al conjunto de valores posibles que puede tomar una columna específica en una tabla (también llamado atributo). Los valores de un dominio son atómicos, lo que significa que no pueden dividirse más y representan la unidad mínima de información para ese atributo y ese valor posible no se puede dividir, es el mínimo valor presentable. o Tipos de datos: La manera más común de representar un dominio es a través de los tipos de datos Ej: cadena, entero, etc. El valor mínimo representable de un entero es el digito o Agrupación lógica: hay veces que es útil darles un nombre a los tipos de datos o hacer agrupaciones lógicas a esos tipos de datos subyacentes ej: Dni, num de teléfono, etc. Entonces al momento de definir el atributo de mi dominio o columna deja de ser un tipo abstracto como una cadena y se convierte en algo que tiene cierta lógica y que es mas entendible. Entonces en si en el tipo de dato yo voy a tener una columna nombre mi dominio será una cadena y n una cadena lo mínimo que puedo representar es un carácter. Pero si por ejemplo quiero representar los colores disponibles de un determinado producto entonces puedo definir un dominio que este compuesto por azul, rojo y verde y el valor atómico acá será una de estas posibilidades. Entonces es atómico en base a lo que yo defina para representar ese hecho. o Formato: Además de lo anterior se puede tener un formato que acompañe a los demás, en general cuando hay un formato existe un tipo de dato Ej: formato de los numero telefónicos. No es necesario que estos tres que conforman el dominio existan si o si, pueden existir uno, pero no el otro, aunque lo mínimo es que exista el tipo de dato Esquema de la relación Es la estructura o "cabecera" de una tabla, que define su nombre y los atributos (columnas) que la componen. Cada atributo está asociado a un dominio. Por ejemplo, en una tabla llamada Alumno con los atributos Legajo, Nombre y Teléfono, los dominios de esos atributos podrían ser entero para Legajo y cadena para Nombre y Teléfono. La lista de atributos es la que se vincula con el dominio R1(A1, A2,…An) siendo n la cantidad de columnas que va a tener Atributo: Un atributo en una tabla representa un rol específico de un dominio dentro de esa tabla. Por ejemplo, en el esquema de la tabla Alumno, el atributo Legajo juega el rol de "identificador numérico del alumno", mientras que Nombre representa "nombre del alumno". La asociación entre el atributo y el dominio se representa como D(Ai), donde Ai es el nombre del atributo y D(Ai) su dominio. Ej: Alumno (legajo: entero, Nombre:cadena, teléfono:cadena) donde alumno es el nombre de la relación, Legajo, nombre y teléfono son los atributos y entero y cadena los dominios del atributo respectivamente. Entonces el esquema es como la cabecera de la tabla y como está definida. Relación o estado de relación: Este es el conjunto de datos o "tuplas" que hay en la tabla en un momento específico. Cada tupla es una fila, y el conjunto de todas las tuplas conforma el estado actual de la relación (o la "extensión de la relación"). Por otro lado, el esquema de la relación (la cabecera de la tabla) se conoce como la "intención de la relación". Es decir r(R)={t1, t2,…tm} siendo m el numero de filas y r(R) el estado o la relación en si misma n-tuplas tj: Una tupla es una lista ordenada de valores (como una fila en una tabla), donde cada valor pertenece a un atributo específico y corresponde a su dominio. Por ejemplo, en una tupla , el valor 1 corresponde al Legajo (con dominio entero), Juan al Nombre (con dominio cadena), y 123-4567 al Teléfono (también cadena). Representa una lista ordenada de n valores tj= es una lista ordenada de valores vi y n es la cantidad de columnas, m no es necesariamente debe coincidir porque la cantidad de coincidencias puede ser cualquiera, entonces voy a tener M tuplas pero cuando me meto en cada tupla en particular si o si cada tupla debe tener n valores. Coincide con la cantidad de columnas por eso coincide R(A1, A2, …, An) y además debe ser ordenada porque debe coincidir el tipo con cada columna Valor vi: Cada valor en una tupla debe pertenecer al dominio de su respectivo atributo, o puede ser nulo si no tiene un valor específico. Esto asegura que todos los valores de una columna respeten las restricciones de su dominio. Es decir dom(Ai) Grado de R: corresponde a la cantidad de atributos existentes en el esquema por lo que el grado es igual a n. Por ejemplo, en Alumno (Legajo, Nombre, Teléfono), el grado sería 3, ya que tiene tres atributos. Características de la relación: Orden de las tuplas en R: En teoría de conjuntos, el orden de los elementos no importa, así que el orden en que se presentan las tuplas (filas) en un conjunto tampoco tiene importancia en el modelo relacional de bases de datos. En una base de datos real, sin embargo, sí existe un orden en el que las tuplas se muestran en una  tabla, pero este orden es dado por la implementación del sistema y no afecta el significado de la relación. Ejemplo: Imaginemos una tabla Estudiantes que contiene los estudiantes de una clase. No importa si el estudiante "Ana" aparece primero y "Carlos" después, o viceversa; ambos están presentes en el conjunto, y el orden de aparición no afecta la información de la tabla en sí. Sin embargo, al visualizarlo en una base de datos, la lista de estudiantes puede aparecer en un orden específico, por ejemplo, ordenado por nombre o por fecha de ingreso. Orden de los valores en cada tupla: Cada tupla en una relación debe tener un orden de valores específico, como , que coincide con el orden de los atributos (columnas) en el esquema de la tabla. Este orden es importante porque permite que cada valor de la tupla se corresponda con el atributo adecuado en el esquema. Aunque en el diseño relacional el orden de las columnas no es fundamental, sí debe haber una coincidencia entre los atributos y los valores. Ejemplo: Supongamos que tenemos una tabla Empleados con columnas ID, Nombre, Teléfono. Una tupla como tiene sentido porque el valor 123 corresponde a ID, Juan a Nombre y 987654321 a Teléfono. Sin embargo, si el orden cambia a , la información no tiene sentido sin una referencia clara, porque los valores no coinciden con sus atributos. Cuando se dice que "no importa el orden que tenga si consigo tener una definición alternativa porque lo que realmente importa es que el atributo coincida con el valor", se está refiriendo a que, en un modelo alternativo (como un conjunto de mapeos), el orden estricto de las columnas o los valores no es necesario siempre que cada valor se asocie correctamente con su atributo correspondiente. Esto quiere decir que podemos definir la relación de una forma que permita intercambiar el orden de las columnas sin perder el significado, porque cada valor sigue correspondiendo a su atributo. Ejemplo Práctico Imaginemos una tabla Empleados con tres columnas: ID (Identificación) Nombre (Nombre del empleado) Teléfono (Número de teléfono del empleado) Una tupla en esta tabla podría ser: (123, "Juan", "987654321") En esta representación, el orden de los valores (ID, Nombre, Teléfono) importa, ya que el primer valor es el ID, el segundo el Nombre, y el tercero el Teléfono. Pero en un modelo de mapeo, podríamos representar esta tupla de la siguiente manera: {"ID": 123, "Nombre": "Juan", "Teléfono": "987654321"} Aquí, los valores están asociados explícitamente con sus atributos, por lo que el orden ya no importa: podríamos escribir {"Teléfono": "987654321", "ID": 123, "Nombre": "Juan"} y la relación seguiría teniendo el mismo significado, ya que cada atributo apunta al valor correcto. En conclusión: El orden de las columnas es importante en la estructura relacional típica porque no se incluye un mapeo explícito en cada tupla. Sin embargo, en un modelo alternativo, como el de un conjunto de mapeos, el orden de los valores se vuelve irrelevante, siempre que cada atributo tenga su valor correspondiente. Valores en las tuplas: En el modelo relacional, los valores de las tuplas deben ser atómicos, es decir, cada casilla de la tabla tiene un solo valor indivisible (o un valor  nulo si no hay un valor definido). No se permiten valores múltiples ni compuestos en una sola celda. Nulo: Un valor puede ser nulo si es inaplicable o desconocido: o Inaplicable: No existe ese valor para una entidad específica. Por ejemplo, un empleado puede no tener un título universitario, entonces su valor es nulo. o Desconocido: No conocemos el valor en ese momento, pero podría existir. Por ejemplo, el número de teléfono de un cliente puede ser nulo porque no se ha proporcionado aún. Otra razón es que puede ser desconocido que dentro de esta es porque hay un valor faltante o porque existe duda sobre su existencia, en el faltante estoy seguro que debe tener un valor, pero no se cual es, en el desconocido no estoy seguro si siquiera tiene un valor o Ejemplo: En una tabla de Clientes, si un cliente no tiene segundo nombre, la celda correspondiente al segundo nombre será nula para ese cliente. Esto no significa que todos los clientes deban tener ese campo vacío, solo que para ese cliente específico, el segundo nombre no aplica. Interpretación: cada relación es una aserción/declaración de algo es decir que en mi modelo relacional, en el esquema de base de datos que estoy haciendo en base al modelo relacional cuando yo digo que un alumno tiene legajo, nombre, apellido y teléfono es porque siempre los alumnos se van a representar de esa manera en el modelo relacional en ese esquema en particular que estoy armando para mi dominio, son hechos que representan entidades o vínculos, cada tupla es una instancia de esa declaración/aserción Restricciones: Dominio: todo valor posible debe ser atómico (un solo valor) Clave: en un conjunto de tuplas cada una debe ser diferente, tiene que tener distintos valores, no puede existir 2 tuplas con igual combinación de valores para todos sus atributos esto es porque en un conjunto no puedo tener valores repetidos, la combinación debe ser distinta (combinación de cada casillero en la tupla). esto es general para todo estado de la relación r(R). Generalmente existe un subconjunto de atributos SK que cumplen con esa propiedad, entonces para que tomar todos los atributos de la tabla si puedo tomar un subconjunto para hacerlo más manejable entonces ahí aparece el concepto de superclave en donde dado 2 tuplas cualesquiera de este estado de relación t1 y t2 para ese subconjunto de atributos sus valores son distintos es decir t1[SK]t2[Sk] El problema que existe con el concepto de SK es que es redundante entonces debo tomar un concepto mas optimo para identificar a cada tupla y ahí aparece el concepto de clave La clave K de R cumple con 2 condiciones: 1) Dos tuplas distintas en cualquier estado de relación no pueden tener valores idénticos para todos los atributos claves: Esto significa que, si tenemos una clave K, ninguna fila o tupla en la tabla puede tener el mismo valor que otra tupla para los atributos que forman la clave K. Esto asegura la unicidad de la clave, lo cual es esencial en una base de datos. Ejemplo: Si tenemos una tabla Empleados con la clave ID_Empleado, cada ID_Empleado debe ser único en toda la tabla. Si ID_Empleado es 123 para un registro, ningún otro registro puede tener ID_Empleado igual a 123.  Esta condición asegura que no se repitan registros en la tabla, haciendo que la clave K actúe como un identificador único para cada tupla en la tabla. 2) Una clave K es una superclave mínima: Para entender esta segunda condición, es importante primero entender el concepto de superclave: Superclave (SK): Una superclave es cualquier conjunto de atributos en una tabla que garantiza la unicidad, lo que significa que ningún otro registro en la tabla puede tener el mismo valor para los atributos en ese conjunto. Una tabla puede tener muchas superclaves, incluso algunas que contienen atributos innecesarios o redundantes. La clave K es una superclave mínima, lo que significa que no se pueden eliminar atributos de K sin perder la propiedad de unicidad. En otras palabras, la clave K contiene solo los atributos esenciales necesarios para asegurar que cada registro en la tabla sea único. Es decir que en el modelo relacional debe existir un atributo clave en cada esquema de relación (tabla) Ejemplo: Supongamos que tenemos una tabla Estudiantes con los atributos ID Estudiante, Nombre, y Apellido. Podríamos considerar que la combinación ID Estudiante + Nombre es una superclave (porque, en teoría, ninguna combinación de estos valores se repetiría). Sin embargo, ID Estudiante por sí solo es suficiente para identificar cada estudiante de manera única, y quitar Nombre no afectaría la unicidad. En este caso, la clave K sería ID Estudiante, ya que es el conjunto mínimo de atributos necesario para asegurar la unicidad en esta tabla. Resticcion de integridad de entidad: esta vinculada a la clave, todo valor en la clave primaria no debe ser nulo, no permite representar la entidad del mundo real si ese es el caso entonces si un atributo se define como clave todas sus tuplas en ese lugar deben tener algún valor no nulo Integridad referencial: acá se habla de restricciones entre relaciones (tablas), para eso se utiliza la clave foránea, una tupla en una relación que haga referencia a otra relación debería referirse a una tupla existente en esa relación es decir que si digo que un alumno cursa TUP yo debo asegurarme de que en la entidad carrera exista como tupla (fila) el valor TUP. Si no existe la tupla correspondiente en la tabla referenciada (en este caso, la carrera TUP en la tabla carreras), se violaría la integridad referencial (relaciones entre tablas sean coherentes y válidas). Esto implica que la base de datos no permitirá que la operación se complete, ya sea que se trate de una inserción o una actualización. Si la clave foránea tiene un valor nulo, la restricción de integridad referencial no se aplica. Esto significa que no es necesario que exista una fila correspondiente en la tabla referenciada. Si permites nulos, debes asegurarte de que el diseño de tu base de datos y las consultas posteriores contemplen la posibilidad de que estos valores no estén definidos. Clave foránea: es un subconjunto de atributos. Entonces una FK entre los esquemas de relación R1 y R2 debe cumplir que: 1) Los atributos en FK de R1tienen los mismos dominios que los atributos de la clave principal pk de R2, los atributos Fk se dicen que referencia a la relación R2 es decir si la PK es entero (su dominio) la FK también  2) Un valor de Fk en una tupla t1 del estado actual r1(R1) o bien se representa como un valor de PK de alguna tupla t2 en r2(R2) o es null. En el primer caso tenemos que t1[FK] = t2[PK] y decimos que la tupla t1 se refiere a la tupla t2 (ósea que una fila refiere a otra fila y si tiene un valor nulo no existe esa referencia) habría una violación de la integridad referencial si por ejemplo la FK tiene un valor que no se encuentra en una columna de las pk de la otra tabla, la FK apunta a la PK Integridad referencial: La integridad referencial es una regla en bases de datos relacionales que asegura la consistencia de los datos al definir relaciones entre tablas. Su propósito principal es garantizar que cualquier referencia entre tablas sea válida, es decir, que no existan valores "colgados" o sin correspondencia. Clave foránea y su rol en la integridad referencial Para implementar la integridad referencial, se utiliza un tipo de clave llamada clave foránea (foreign key, FK). Una clave foránea es un atributo (o conjunto de atributos) en una tabla que referencia la clave primaria de otra tabla. La clave foránea asegura que cada valor que aparece en ella corresponda a un valor existente en la clave primaria de la otra tabla. Por ejemplo, en una base de datos que tiene dos tablas: Estudiantes y Cursos: Estudiantes tiene una clave primaria ID Estudiante. Inscripciones tiene una columna ID Estudiante como clave foránea que apunta a ID Estudiante en la tabla Estudiantes. Reglas de integridad referencial Para que la integridad referencial se cumpla, deben respetarse las siguientes reglas: 1. Existencia de los valores: o Cada valor en la clave foránea de la tabla que hace la referencia (en el ejemplo, la tabla Inscripciones) debe coincidir con un valor existente en la clave primaria de la tabla referenciada (Estudiantes). o Esto significa que no puedes tener un valor en Inscripciones en ID Estudiante que no exista en Estudiantes. Si intentas insertar un valor en Inscripciones sin un correspondiente ID Estudiante en Estudiantes, se violará la integridad referencial. 2. Opciones de actualización y eliminación: o Cuando se elimina o actualiza una tupla en la tabla referenciada (Estudiantes), se deben definir reglas sobre cómo esto afectará a la tabla que hace referencia (Inscripciones). o Estas reglas suelen ser: ▪ RESTRICT: Prohíbe la eliminación o actualización si existen referencias.  ▪ CASCADE: Permite que la eliminación o actualización en la tabla referenciada se refleje en todas las tablas que la referencian. ▪ SET NULL: Asigna un valor nulo en la clave foránea cuando la referencia en la tabla principal es eliminada. ▪ NO ACTION: Similar a RESTRICT; solo que difiere en el tiempo en que se valida la restricción (a nivel de transacción). RESTRICT valida inmediatamente, justo en el momento en que se intenta ejecutar la operación. Si se detecta una violación, la operación falla de inmediato. En cambio, NO ACTION permite la operación siempre que la integridad referencial quede intacta al final de la transacción. Ejemplo de integridad referencial Imaginemos que la tabla Estudiantes tiene un estudiante con ID Estudiante = 1001. Si existe una inscripción en la tabla Inscripciones con ID Estudiante = 1001, la integridad referencial garantiza que: Si eliminas al estudiante con ID Estudiante = 1001 en la tabla Estudiantes, también deberás manejar la inscripción en Inscripciones de acuerdo con las reglas definidas (RESTRICT, CASCADE, SET NULL, etc.). Si intentas insertar en Inscripciones una fila con ID Estudiante = 9999, pero ID Estudiante = 9999 no existe en Estudiantes, la base de datos no lo permitirá y generará un error de integridad referencial. En resumen La integridad referencial asegura que todas las referencias en las relaciones entre tablas sean válidas y consistentes, evitando errores y manteniendo la coherencia de los datos.