Unidad 4

Diseño de bases de datos relacionales

4.1 Metodologías de diseño de base de datos.

La metodología de diseño de bases de datos relacionales se ha consolidado a lo largo de los años

satisfaciendo las propiedades de generalidad (independencia de la plataforma hardware/software),
calidad del producto (precisión, completitud y eficacia) y facilidad de uso. Dicha metodología de
diseño consta de las 3 siguientes etapas:

1.Diseño conceptual:

Su objetivo es definir las entidades y las relaciones entre ellos de forma abstracta, sin
centrarse en ningún modelo lógico en concreto (como el relacional, el orientado a objetos,
el jerárquico o el de red).
• Herramienta: Modelo conceptual de datos. Se usa alguna variante del modelo
entidad-relación para las bases de datos relacionales.
• Resultado: Esquema conceptual de la base de datos.

2. Diseño lógico:

Su objetivo es definir el esquema de la base de datos según el modelo que implementa el

SGBD objetivo.

• Herramienta: Modelo lógico de datos. Se usa el modelo lógico que implemente el

sistema de gestión de bases de datos objetivo, pero es independiente de los
aspectos físicos. Se usan técnicas formales para Bases de datos MTIG 3 verificar la
calidad del esquema lógico; la más usual es la normalización. En el modelo
relacional se usan las tablas.

• Resultado: Esquema lógico de la base de datos.

3. Diseño físico:

Su objetivo es definir el esquema físico de la base de datos de forma que se den todas las
instrucciones para que un DBA pueda implementar la base de datos sin ninguna
ambigüedad. Se considera el rendimiento como un aspecto que no se ha tratado en las
etapas anteriores.

• Herramienta: Modelo físico de datos. Se consideran todos los detalles de la

implementación física: organización de archivos e índices para el SGBD considerado.

• Resultado: Esquema físico de la base de datos.

La siguiente figura muestra resumido el ciclo de desarrollo clásico de bases de datos:
Especificaciones (en lenguaje natural) Esquema conceptual (Modelo entidad-relación) Esquema
lógico (Diseño de tablas relacionales) Esquema físico (Organización de archivos e índices) Diseño
conceptual Diseño lógico

4.2 Transformación del esquema conceptual al relacional.

Traducción de conceptos:

Modelo Conceptual Modelo Relacional

Centrado en describir objetos del problema y Describe los mecanismos para tratar el
los vínculos entre ellos. problema deseado en una BD
Entidades (suelen describirse en singular) Tablas (Se suelen nombrar en plural, también
se les llama relaciones)
Atributos Columnas o atributos
Ejemplares o instancias Filas o tuplas
Dominios Tipos de datos
Identificador Clave primaria (Primary key)
Relación 1:N Clave foránea o extranjera (Foreign key)
Relación N:M (muchos a muchos) Tabla intermedia
Relación 1:1 entre 2 entidades Decidimos qué tabla recibe una (FK) o si
unificamos las 2 entidades en 1
Formato gráfico Formato descriptivo (texto)
Algunas entidades débiles Pueden convertirse en restricciones
Tipos de datos predefinidos (dominios)

 Fechas e instantes de tiempo: DATE, TIME y DATE TIME

 Valores numéricos: INT, LFOAT, DECIMAL (n,m)
 Cadenas de texto: CHAR(n), VARCHAR(n)
 Enumeraciones: ENUM(‘v1’,’v2’,’v3’,…, ‘nv’)
 Otros(imágenes, sonidos…):
BLOB(binary large objects)

Restricciones a respetar en un modelo relacional

En una tabla no puede haber 2 filas iguales.

La PK es obligatoria.

El orden de las filas y/o columnas no importa

Cada columna solo puede tomar un valor de su dominio, nunca varios.

Ningún atributo que forme parte se la PK puede ser un valor nulo

Integridad referencial: Los atributos que sean una FK deben tomar valores de filas existentes en la
tabla referenciada.

Incrementando la semántica incluida en el modelo ER

En el modelo referencial se puede reforzar los supuestos semánticos del problema mediante varios
mecanismos:

CHECK (restricciones de verificación)

Ejemplo: “El salario puede oscilar entre los $600 y los $300/día”

TRIGGERS (disparadores) Permiten rechazar o hacer acciones auxiliares antes o después de

cualquier inserción, borrado o modificación de información. Evento -> Condición -> Acción

Ejemplo: “Antes de insertar un árbitro comprobar si su nacionalidad coincide con la de

alguno de los jugadores y en ese caso rechazar la inserción”