Summary of Information Systems: Concepts and Digital Strategy

Information Systems: Concepts & Digital Strategy Summary

Introducción

Las bases de datos relacionales permiten almacenar y organizar información en tablas relacionadas entre sí. En este material aprenderás cómo modelar relaciones entre tablas (1:1, 1:∞, ∞:∞), cuándo usar tablas de unión (join tables) y cómo diseñar claves y campos para mantener una estructura normalizada y eficiente.

Definición: Una base de datos relacional organiza los datos en tablas que se relacionan mediante claves primarias y claves foráneas.

Conceptos básicos desglosados

Tablas, registros y campos

  • Tabla: conjunto de registros con la misma estructura.
  • Registro (fila): una instancia concreta con valores para cada campo.
  • Campo (columna): atributo que describe cada registro.
  • Clave primaria (PK): identificador único de cada registro en una tabla.
  • Clave foránea (FK): campo en una tabla que referencia la PK de otra tabla para establecer una relación.

Definición: Clave primaria es el campo o conjunto de campos que identifica de manera única una fila en una tabla.

Tipos de relaciones entre tablas

Usaremos ejemplos sencillos (CUSTOMERS, ORDERS, PRODUCTS, ORDER_LINE) para ilustrar los tipos de relaciones.

  1. Relación 1:∞ (uno a muchos)
  • Descripción: Un registro en la tabla A puede relacionarse con varios registros en la tabla B, pero cada registro en B sólo se relaciona con un registro en A.
  • Implementación: Añadir la PK de A como FK en B.
  • Ejemplo: Un cliente (CUSTOMER) puede tener muchas órdenes (ORDERS). La tabla ORDERS incluye el campo CustomerID como FK.

Definición: Relación 1:∞: cada registro de la tabla del “uno” puede tener muchas correspondencias en la tabla del “muchos”.

  1. Relación 1:1 (uno a uno)
  • Descripción: Cada registro en A se relaciona con un único registro en B y viceversa.
  • Implementación: Se puede poner la FK en cualquiera de las tablas; se acostumbra a ponerla en la tabla cuyo registro se genera después (criterio de temporalidad).
  • Ejemplo: Si cada pedido genera un único envío (SHIPMENT) y viceversa, podemos almacenar OrderID como FK en SHIPMENTS.
  1. Relación ∞:∞ (muchos a muchos)
  • Descripción: Un registro en A puede relacionarse con varios de B y un registro en B con varios de A.
  • Problema: No se puede resolver añadiendo la PK de A a B o viceversa sin repetir campos y violar la normalización.
  • Solución: Crear una tabla intermedia llamada tabla de unión o join table.

Definición: Relación ∞:∞: cuando varios registros de una tabla pueden asociarse con varios registros de otra tabla simultáneamente.

Tablas de unión (JOIN tables)

  • Propósito: Materializar relaciones ∞:∞ creando una tabla que contiene las claves de ambas tablas relacionadas.
  • Clave de la tabla de unión: suele ser la combinación compuesta de las dos FKs (PK compuesta).
  • Campos adicionales: pueden incluir atributos que dependan de la combinación de ambas entidades (atributos de la relación).

Ejemplo práctico: ORDERS, PRODUCTS y ORDER_LINE

  • ORDERS (OrderCode PK, otros campos)
  • PRODUCTS (ProductCode PK, otros campos)
  • ORDER_LINE (OrderCode FK, ProductCode FK, Quantity, otros campos)

La tabla ORDER_LINE guarda una fila por cada producto incluido en cada pedido. Su PK puede ser la combinación $(\text{OrderCode},\ \text{ProductCode})$.

Definición: Tabla de unión: tabla que contiene las claves primarias de las dos tablas relacionadas en una relación ∞:∞ y puede incluir campos propios de la relación.

Atributos dependientes de la relación

Algunos campos dependen de la combinación de dos registros, no de uno solo. Por ejemplo, la cantidad pedida de un producto en un pedido no pertenece ni a ORDERS ni a PRODUCTS; pertenece a ORDER_LINE. Esos campos deben almacenarse en la tabla de unión.

Diseño y normalización: buenas prácticas

  • Evitar campos repetidos que representen el mismo concepto (p. ej. OrderCode1, OrderCode2) — eso rompe la normalización.
  • Cada relación debe representarse mediante FKs: el número de FKs en el modelo debe corresponder
Zaregistruj se pro celé shrnutí
FlashcardsKnowledge testSummaryPodcastMindmap
Start for free

Already have an account? Sign in

Modelado de Bases de Datos Relacionales

Klíčové pojmy: Relación 1:∞: FK en la tabla del “muchos”, Relación 1:1: FK en la tabla creada después por temporalidad, Relación ∞:∞: resolver con tabla de unión (join table), Tabla de unión: PK compuesta por las dos FKs, Atributos de la relación deben ir en la tabla de unión, Evitar repetir campos (no normalizar), Validar diseño con integridad referencial y dependencia de atributos, Usar claves apropiadas: PK para identidad y FK para relaciones, En 1:∞ cada orden pertenece a un solo cliente, En 1:1 elegir FK según cuándo se genera el registro

## Introducción Las bases de datos relacionales permiten almacenar y organizar información en tablas relacionadas entre sí. En este material aprenderás cómo modelar relaciones entre tablas (1:1, 1:∞, ∞:∞), cuándo usar tablas de unión (join tables) y cómo diseñar claves y campos para mantener una estructura normalizada y eficiente. > Definición: Una base de datos relacional organiza los datos en tablas que se relacionan mediante claves primarias y claves foráneas. ## Conceptos básicos desglosados ### Tablas, registros y campos - **Tabla**: conjunto de registros con la misma estructura. - **Registro (fila)**: una instancia concreta con valores para cada campo. - **Campo (columna)**: atributo que describe cada registro. - **Clave primaria (PK)**: identificador único de cada registro en una tabla. - **Clave foránea (FK)**: campo en una tabla que referencia la PK de otra tabla para establecer una relación. > Definición: Clave primaria es el campo o conjunto de campos que identifica de manera única una fila en una tabla. ### Tipos de relaciones entre tablas Usaremos ejemplos sencillos (CUSTOMERS, ORDERS, PRODUCTS, ORDER_LINE) para ilustrar los tipos de relaciones. 1. Relación 1:∞ (uno a muchos) - Descripción: Un registro en la tabla A puede relacionarse con varios registros en la tabla B, pero cada registro en B sólo se relaciona con un registro en A. - Implementación: Añadir la PK de A como FK en B. - Ejemplo: Un cliente (CUSTOMER) puede tener muchas órdenes (ORDERS). La tabla ORDERS incluye el campo CustomerID como FK. > Definición: Relación 1:∞: cada registro de la tabla del “uno” puede tener muchas correspondencias en la tabla del “muchos”. 2. Relación 1:1 (uno a uno) - Descripción: Cada registro en A se relaciona con un único registro en B y viceversa. - Implementación: Se puede poner la FK en cualquiera de las tablas; se acostumbra a ponerla en la tabla cuyo registro se genera después (criterio de temporalidad). - Ejemplo: Si cada pedido genera un único envío (SHIPMENT) y viceversa, podemos almacenar OrderID como FK en SHIPMENTS. 3. Relación ∞:∞ (muchos a muchos) - Descripción: Un registro en A puede relacionarse con varios de B y un registro en B con varios de A. - Problema: No se puede resolver añadiendo la PK de A a B o viceversa sin repetir campos y violar la normalización. - Solución: Crear una tabla intermedia llamada **tabla de unión** o **join table**. > Definición: Relación ∞:∞: cuando varios registros de una tabla pueden asociarse con varios registros de otra tabla simultáneamente. ### Tablas de unión (JOIN tables) - Propósito: Materializar relaciones ∞:∞ creando una tabla que contiene las claves de ambas tablas relacionadas. - Clave de la tabla de unión: suele ser la combinación compuesta de las dos FKs (PK compuesta). - Campos adicionales: pueden incluir atributos que dependan de la combinación de ambas entidades (atributos de la relación). Ejemplo práctico: ORDERS, PRODUCTS y ORDER_LINE - ORDERS (OrderCode PK, otros campos) - PRODUCTS (ProductCode PK, otros campos) - ORDER_LINE (OrderCode FK, ProductCode FK, Quantity, otros campos) La tabla ORDER_LINE guarda una fila por cada producto incluido en cada pedido. Su PK puede ser la combinación $(\text{OrderCode},\ \text{ProductCode})$. > Definición: Tabla de unión: tabla que contiene las claves primarias de las dos tablas relacionadas en una relación ∞:∞ y puede incluir campos propios de la relación. ### Atributos dependientes de la relación Algunos campos dependen de la combinación de dos registros, no de uno solo. Por ejemplo, la **cantidad** pedida de un producto en un pedido no pertenece ni a ORDERS ni a PRODUCTS; pertenece a ORDER_LINE. Esos campos deben almacenarse en la tabla de unión. ## Diseño y normalización: buenas prácticas - Evitar campos repetidos que representen el mismo concepto (p. ej. OrderCode1, OrderCode2) — eso rompe la normalización. - Cada relación debe representarse mediante FKs: el número de FKs en el modelo debe corresponder