Conceptos Fundamentales de Bases de Datos

Llaves en Bases de Datos

Llave Primaria: Es un atributo o conjunto de atributos que identifican de manera única cada fila en una tabla.

Ejemplo: En una tabla Clientes, el atributo id_cliente podría ser la llave primaria.

Llave Secundaria: Es un atributo que no es único, pero que se usa para buscar registros de forma más eficiente. No identifica de manera única una fila.

Ejemplo: En una tabla Vehículos, el atributo modelo podría ser una llave secundaria, ya que varios vehículos pueden tener el mismo modelo.

Llaves Candidatas: Son atributos que pueden servir como llaves primarias. Cada llave candidata puede identificar de manera única una fila en la tabla.

Ejemplo: En la tabla Clientes, tanto id_cliente como email podrían ser llaves candidatas si cada cliente tiene un correo electrónico único.

Llaves Foráneas

Ejemplo: En el modelo de una base de datos de ventas, si la tabla Facturas tiene un atributo id_cliente que referencia el id_cliente en la tabla Clientes, id_cliente en Facturas sería una llave foránea.

Diseño de Bases de Datos

Etapas del Proceso de Diseño

a) Modelo Conceptual

Descripción: Esta fase se centra en representar la estructura de alto nivel de los datos sin preocuparse por cómo se implementarán. Se utiliza para identificar las entidades, relaciones y restricciones.

Abstracción: Alta, ya que no se consideran detalles técnicos.

Ejemplo: Un diagrama ER (Entidad-Relación) que representa clientes, vehículos y ventas.

b) Modelo Lógico

Descripción: Esta fase define la estructura de los datos de manera más detallada, incluyendo entidades, atributos y relaciones, pero sin especificar detalles de implementación física.

Abstracción: Media, ya que comienza a incluir detalles sobre cómo se relacionan los datos.

Ejemplo: Definir tablas como Clientes, Vehículos, y las relaciones entre ellas.

c) Modelo Físico

Descripción: Esta fase se enfoca en la implementación concreta de la base de datos, incluyendo la selección del sistema gestor de bases de datos (SGBD), la definición de tipos de datos, índices y restricciones de integridad.

Abstracción: Baja, ya que se centra en la implementación concreta.

Ejemplo: Crear scripts SQL para la creación de tablas y establecer claves primarias y foráneas.

Modelo Entidad-Relación (ER) para un Sistema de Restaurante

Para construir el modelo ER de este sistema de administración de restaurante, identificaremos las entidades principales y sus relaciones, así como sus cardinalidades y posibles atributos.

Entidades e Identificación de Atributos

1. Plato

   • Atributos: código, nombre, tipo, tiempo de cocción, foto, descripción.
   • Relación con Precio: cada plato tiene múltiples precios históricos con fechas de inicio y fin (1:N).

2. Precio

   • Atributos: monto, fecha_inicio, fecha_fin.

3. Cliente

   • Atributos: código, nombre, dirección, teléfonos (múltiples).
   • Relación con Cuenta: un cliente puede tener múltiples cuentas (1:N).

4. Cajero

   • Atributos: código, nombre, dirección, teléfono.
   • Relación con Cuenta y Factura: un cajero atiende y cobra múltiples cuentas (1:N).

5. Cuenta

   • Atributos: nombre_cliente, nombre_cajero, fecha, hora, detalle (platos y precios, cantidad de cada plato), suma_total.
   • Relación con Plato: una cuenta puede tener múltiples platos (N:M).

6. Factura

   • Atributos: NIT_cliente, código_orden.
   • Relación con Cuenta: 1:1 (cada cuenta genera una factura).

Relaciones y Cardinalidades

• Plato – Precio: 1:N, un plato puede tener múltiples precios a lo largo del tiempo.
• Cuenta – Plato: N:M, una cuenta incluye varios platos, y un plato puede estar en varias cuentas.
• Cuenta – Cliente: N:1, un cliente puede tener varias cuentas.
• Cuenta – Cajero: N:1, un cajero atiende varias cuentas.
• Cuenta – Factura: 1:1, cada cuenta genera una única factura.
• Factura – Cliente: N:1, un cliente puede tener varias facturas.

Diagrama ER (Paso Resumido)

1. Dibuja las entidades con sus atributos.
2. Usa conectores y escribe las relaciones, marcando las cardinalidades.
3. Asegura las dependencias.

Normalización de la Tabla POSEEAUTOMOVIL

Tabla Original:

GUSTA AUTOMOVIL(placaA, marcaA, modeloA, colorA, codPer, nomPer, dirPer, telPer, calificaciónGusto)

Dependencias Funcionales

1. df1: placaA → marcaA, modeloA, colorA
2. df2: codPer → nomPer, dirPer, telPer
3. df3: placaA, codPer → calificaciónGusto

Segunda Forma Normal (2FN)

• Primera FN: La tabla ya está en 1FN, ya que no tiene atributos multivaluados.
• Clave Primaria: (placaA, codPer) para identificar de forma única cada gusto de auto.

Pregunta 2: Normalización de la Tabla POSEEAUTOMOVIL

Tabla Original: GUSTA AUTOMOVIL

Dependencias Funcionales

Las dependencias funcionales (DF) proporcionadas son:

1. DF1: placaA → marcaA, modeloA, colorA: La placa del automóvil determina su marca, modelo y color.
2. DF2: codPer → nomPer, dirPer, telPer: El código de la persona determina el nombre, dirección y teléfono.
3. DF3: placaA, codPer → calificaciónGusto: La combinación de placa y código de persona determina la calificación del gusto.

Paso 1: Verificar 1FN

Ya se menciona que la tabla está en 1FN, es decir, todos los valores son atómicos y no hay datos repetidos en una columna.

Paso 2: Aplicar la Segunda Forma Normal (2FN)

Para que una tabla esté en 2FN:

• Debe estar en 1FN.
• Cada atributo no clave debe depender de toda la clave primaria.

Aquí, la clave primaria sería la combinación de placaA y codPer. Ahora aplicamos las dependencias:

1. Dependencia Parcial (DF1 y DF2): Las columnas marcaA, modeloA, colorA dependen solo de placaA, no de codPer.

2. Solución: Creamos una nueva tabla AUTOMOVIL con los atributos relacionados a la placa:

   AUTOMOVIL
   placaA (PK)
   marcaA
   modeloA
   colorA

3. Dependencia Parcial (DF2): nomPer, dirPer, telPer dependen solo de codPer.

   • Creamos una tabla PERSONA para almacenar estos atributos.

   PERSONA
   codPer (PK)
   nomPer
   dirPer
   telPer

4. Tabla GUSTA: Finalmente, en la tabla GUSTA dejamos solo las dependencias completas de la clave primaria:

   GUSTA
   placaA (FK)
   codPer (FK)
   calificaciónGusto

Estas tres tablas ahora cumplen con la 2FN.

Pregunta 3: ¿El modelo ER tiene llaves foráneas?

Respuesta: Sí, el modelo ER tiene llaves foráneas. Las llaves foráneas se utilizan para relacionar las entidades y mantener la integridad referencial entre ellas. Por ejemplo:En la relación entre Cuenta y Cliente, el codCliente se utiliza como llave foránea en la entidad Cuenta para asociar cada cuenta con un cliente específico.En la relación entre Cuenta y Cajero, el codCajero actúa como llave foránea en la entidad Cuenta para identificar al cajero que atendió cada cuenta.Las llaves foráneas son esenciales en el modelo ER para representar y garantizar las relaciones entre entidades, evitando que se pierda consistencia en la base de datos.

Etiquetas: 2FN, Bases de datos, llave foránea, llave primaria, modelo entidad-relación, normalización