Diseño de Bases de Datos: Lógico, Físico y Modelo Relacional

Diseño de Bases de Datos: Lógico y Físico

Bloque 3 - Tema 2
DISEÑO DE BASES DE DATOS. DISEÑO LÓGICO Y FÍSICO. EL MODELO LÓGICO
RELACIONAL. NORMALIZACIÓN

Introducción al Diseño de Bases de Datos

1. Diseño de Bases de Datos - Introducción
¿Qué es diseñar una base de datos?

• Es un proceso de abstracción y modelado para representar un problema real
• Se buscan reglas y estructuras para representar la información de forma clara y
  eficiente.

. Implica definir entidades
sus atributos, y como se relacionan entre sí

Etapas del Diseño de Base de Datos

Etapas del diseño de base de datos

Modelo Conceptual (E/R)

1
Modelo Conceptual (E/R) >
· Se estudia el problema y se capta la información clave (requisitos)
· Se representa desde un punto de vista abstracto y sin detalles técnicos
· Herramienta común: Modelo Entidad-Relación (E/R)

Modelo Lógico (Relacional)

2 Modelo Lógico (relacional)
· Se transforma el modelo conceptual en un esquema lógico
· Aquí ya se piensa cómo se organizarán los datos
· ¡ Ojo! No se depende todavía del tipo de base de datos (MySQL, Oracle, etc.)
Diseño lógico = estructura clara que representa los datos sin importar aún el software

Modelo Físico (en SGBD)

3 Modelo Físico (en SGBD)
· Aquí ya se define cómo se implementará la base de datos en un sistema específico
(SGBD)
· Se habla de estructuras de almacenamiento
y métodos de acceso a los datos
· Propósito: asegurar el acceso eficiente y rendimiento del sistema.Modelo
conceptual
(E/R)
Modelo
lógico
(relacional)
Modelo
físico
(en SGBD)

Normalización de Bases de Datos

Normalización
· Técnica para verificar la validez de los esquemas lógicos
· Se convierte el modelo lógico en tablas organizadas y sin redundancias

Proceso Iterativo en el Diseño

Proceso iterativo
El diseño conceptual, lógico y físico no son pasos rígidos.
Se avanza, prueba, ajusta y repite. Es como un ciclo de aprendizaje.

Importancia del Diseño de Bases de Datos

2. DISEÑO DE BASES DE DATOS
¿Por qué es importante ?
· Las bases de datos deben adaptarse a los cambios en el entorno
· Los cambios pueden ser:
○
Físicos: hardware, ficheros, etc.
H
o Lógicos: programas, lenguajes de programación, etc.
· ¡ No debe ser necesario rehacerlo todo cuando algo cambia!

Arquitectura en 3 Niveles (ANSI/SPARC)

Arquitectura en 3 Niveles (ANSI/SPARC)
Una arquitectura que ayuda a organizar y proteger los datos dividiéndolos en 3 niveles:옷 옷
Usuarios
finales
Nivel
Externo
Vista 1
Vista 2
Vista 3
-A cada unario solo
le damos acceso a aquella
información que le es
necesaria, Mínimo privilegia
Nivel
Conceptual
Esquema
Conceptual
- Diagrama Entidad / Relación.
que almacena los datos en el Sistema de Información.
Nivel
Interno
Esquema
Interno
- Descripción de la Base de Datos En
un SGBD.
Organización fisica
de los datos
Base de
datos

Nivel Externo o Lógico

1
Nivel Externo o Lógico
Aquí están las vistas de los usuarios
· Cada persona ve solo los datos que necesita/ver puede
Q
· Protege al usuario de los detalles técnicos
Permite tener diferentes vistas parciales

Nivel Conceptual

2 Nivel Conceptual
· Aquí está el modelo general de la base de datos
· Define toda la estructura lógica (entidades, relaciones, restricciones ... )
Es como el mapa completo de la información
· Lo usan los administradores y diseñadores

Nivel Interno o Físico

3 Nivel Interno o Físico
· Es la organización física de los datos
· Define cómo se almacenan realmente los datos en disco
· Optimiza el acceso y rendimiento del sistema
· Lo maneja el SGBD (Sistema de Gestión de Bases de Datos)

Independencia de los Datos

🔐
Independencia de los Datos
Evita que los cambios en una parte de la base de datos afecten a las demás

Independencia Lógica

Independencia LÓGICAV Puedes cambiar el modelo conceptual
X
Sin afectar las vistas de usuario ni los programas que acceden a los datos

Independencia Física

Independencia FÍSICA
V Puedes cambiar la forma de almacenamiento físico
X
Sin modificar el modelo conceptual ni las vistas

Tipos de Modelos de Datos

Tipos de Modelos de Datos

Modelo Jerárquico

Jerárquico
· Estructura de árbol 1:N
· Simula relaciones padre -> hijos

Modelo CODASYL (en Red)

CODASYL (en Red)
· Estructura más compleja: relaciones N:M
· Flexible pero difícil de implementar

Modelo Relacional

〒 』
& %
Relacional (el más común)
· Basado en álgebra de conjuntos
· Datos en forma de tablas
· Muy usado por su claridad y potencia

Modelo Orientado a Objetos

Orientado a Objetos
· Usa conceptos de programación orientada a objetos
· Ideal para datos complejos

Ventajas del Enfoque por Niveles

V
Ventajas del enfoque por niveles●
Mayor seguridad
●
Flexibilidad ante cambios
●
Personalización por usuario
●
Optimización en rendimiento

Diseño Lógico de Bases de Datos

3. DISEÑO LÓGICO
Una vez tenemos el modelo conceptual, lo transformamos en el modelo lógico, que es el
que se usará con el SGBD elegido.
En este caso, el modelo lógico es relacional (tablas, atributos, claves ... ).

Proceso: Transformaciones y Normalización

Proceso: Transformaciones y Normalización
Para convertir el modelo conceptual al lógico, se aplican una serie de transformaciones que
permiten adaptar los datos al formato relacional (tablas y atributos simples).

Ajustes del Modelo Conceptual

3.1. Ajustes del Modelo Conceptual

Eliminación de Atributos Compuestos

V
Eliminación de Atributos Compuestos
Un atributo compuesto puede descomponerse en varios más simples.
Ejemplo:
Código_Cuenta_Bancaria - se divide en:
- Código_Banco
- Código_Sucursal
- Número_de_Cuenta
¿Por qué?
. Información más precisa y clara
· Modelo más simple y manejable· Se facilita el análisis y tratamiento posterior
Resultado: Diagrama E/R con atributos simples (univalorados) en todas las entidades

Eliminación de Atributos Multivalorados

V
Eliminación de Atributos Multivalorados
Multivalorados = atributos con más de un valor por entidad (por ejemplo,
"Movimientos" en una cuenta bancaria).
Solución:
· Crear una nueva entidad para representar esos valores múltiples
· Establecer una relación con la entidad original
Ejemplo:
CUENTAS BANCO
PK
CodBanco
PK
CodSucursal
Atributos
PK
Num Cuenta
Movimientos
3 Atributo con muchos valores
(multivaluado).
Cuentas Banco tiene "Movimientos" - crear entidad "Movimientos"
Relacionar: Cuenta
Movimiento (1:N)
Resultado: Se eliminan multivalorados
todo queda en atributos univalorados
CUENTAS BANCO
CUENTAS BANCO
PK
CodBanco
PK
Cod Movimiento
Pertenecer
PK
CodSucursal
DescripciónMvto
FechaMvto
En esta relación
voy a guardar
todos Los manimi-
entos sinalador
a esta cuenta.
PK
NumCuenta
HoraMvto
Se elimina el atributo que
tiene muchos valores que
crea una relación que le
Llame " Movimiento"

Eliminación de Relaciones Redundantes

Eliminación de Relaciones Redundantes
Una relación es redundante si su información ya se puede obtener mediante otras
relaciones.
No siempre es un error, pero si no aporta valor adicional, puede eliminarse.
Q Ejemplo:
ZOO - pose - ANIMAL - pertenece - ESPECIE
Si se puede inferir la relación ZOO - ESPECIE a través de ANIMAL,
puede ser redundante.
(1,1)
(1,1)
posee
ANIMAL
pertenece
(1,n)
(1,n)
(1,n)
ZOO
ZAbena
ESPECIE
albergo no me ofrece
ninguna información extra

Obtención del Modelo Lógico a partir del Conceptual

3.2. Obtención del Modelo Lógico a partir del
Conceptual
Una vez tenemos el modelo conceptual, debemos transformarlo en uno lógico compatible
con el modelo relacional (tablas, columnas, claves ... ).

Transformación de Dominios

· Transformación de Dominios
Un dominio en el modelo conceptual se convierte en un dominio lógico.
Se usa: CREATE DOMAIN
También es importante:
· Usar tipos de datos apropiados (INT, VARCHAR, DATE, etc.)
· Definir restricciones como longitud, rango de valores, etc.

Transformación de Entidades

· Transformación de Entidades
Cada entidad del modelo conceptual se convierte en una tabla
La clave primaria se deriva directamente del identificador de la entidad.
Ejemplo: Dado el siguiente diagrama conceptual
Nombre
Dirección
Teléfono
NIF
CLIENTE
Corno MF va abrazado
deberal que es la clave
principal, el identificador.
Daría como resultado:
CLIENTE (NIF [PK], Nombre, Dirección, Teléfono)

Transformación de Atributos

· Transformación de Atributos
Cada atributo del modelo conceptual pasa a una columna en la tabla.
Tipos de atributos:
●
Primarios (PK): pasan como claves primarias con PRIMARY KEY
●
B Candidatos: pueden ser usados como alternativas, no se descartan. En su
implementación deberá añadirse la restricción UNIQUE
●
Convencionales: atributos normales, simplemente se incluyen como columnas
●
Compuestos y multivalorados: se transforman como ya vimos antes,
descomponiéndose o creando nuevas entidades

Transformación de Relaciones

Transformación de Relaciones

Relaciones 1:1

. Relaciones 1:1En una relación 1:1, puede decidir si crear una nueva tabla o no.
1. Se crea una nueva tabla si:
1. Ambas cardinalidades mínimas son cero (evita nulos en claves).
2. La relación tiene atributos propios.
3. Se prevé que pueda variar en el futuro (flexibilidad).
Ejemplo:
· DNI
· nº sarie
horario
0
nombre
(0, 1)
(0,1)
0
apelidos o
EMPLEADO
wiliza
ORDENADOR
1:1
Se crearán tres tablas:
EMPLEADO(DNI (PK), Nombre, Apellido)
ORDENADOR(NumSerie (PK), Memoria)
UTILIZA(NumSerie+DNI (PK), horario)
suma de los
identificador
de ambas tables (clave primente).
2. Si una entidad tiene cardinalidad minima cero y la otra no, conviene propagar la clave
desde la que tiene obligación (mínima # 0).
De ese modo:
· La entidad obligatoria mantiene su propia clave primaria intacta.
· La entidad opcional incorpora esa clave como foránea, permitiendo que exista sin
obligación de tener siempre un enlace (min = 0).
3. Si ambas tienen cardinalidad mínima uno:
. a. Si comparten el mismo identificador, se usa una sola tabla.
· b. Si tienen identificadores distintos, se usa una tabla para cada entidad, y se
propaga la clave más frecuente.
. Relaciones 1:N
memoria
0

Relaciones 1:N

· No se crea tabla extra (a no ser que la relación tenga atributos propios)
· Se propaga la clave desde la entidad con cardinalidad 1 hacia la que tiene
cardinalidad N.
· Las claves foráneas se definen con FOREIGN KEY.

Relaciones N:M y Ternarias

Relaciones N:M y ternarias
· Se crea una nueva tabla con claves primarias formadas por la concatenación de las
claves primarias de las entidades involucradas.

Relaciones de Agregación

· Relaciones de Agregación
. Se transforman igual que las relaciones 1:N.

Relaciones de Dependencia (Entidades Débiles)

· Relaciones de Dependencia (Entidades Débiles)
· Si dependen por existencia, se propaga la clave desde la fuerte.
· Si dependen por identificador, la clave primaria de la entidad débil se forma con la
clave de la fuerte + su propia clave.

Relaciones Reflexivas

· Relaciones Reflexivas
. Si la relación es 1:N, se añade una clave foránea a la misma tabla que apunta al
identificador de otra fila de la misma entidad.

Relaciones Exclusivas

. Relaciones Exclusivas
. Se transforman como relaciones 1:N, pero es importante comprobar si hay claves
ajenas ya existentes en tablas relacionadas para evitar conflictos.

Transformación de Jerarquías (Supertipo - Subtipo)

· TRANSFORMACIÓN DE JERARQUÍAS (Supertipo - Subtipo)
En el modelo relacional no existen subtipos/supertipos directamente, por lo que se
transforman de las siguientes maneras:
Opción 1; Tabla para el supertipo + tabla por subtipo