Diseño Lógico

SEMANA 2
  BASE DE DATOS 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 
   

[ BASE DE DATOS ]
  

CONTENIDO 
 
 
 
 
PRESENTACIÓN ……………………………………………………  3 
 
1. DESARROLLO TEMÁTICO ……………………………………….  3 
• Diseño Lógico de bases de datos ……………………………  4 
• Componentes de un diagrama relacional (MER) ………... ..  4 
• Conclusiones .……………………………………..………….      10 
 
1.1. BIBLIOGRAFÍA ……...……………….………………….. ……         10 
 

  

 
2  [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]
 

PRESENTACIÓN 
En  esta  unidad  se  examina  el  modelado  de  datos  en  el  diseño  de  bases  de  datos.  Para 
ayudarle a comprender el proceso de modelado, las sesiones se basarán en estudios de casos 
y  el  uso  de  diferentes  herramientas  software  de  modelado  y  construcción  de  sistemas  de 
bases de datos. 

El  enfoque  de  esta  unidad  está  dirigido  a  los  aspectos  técnicos  del  diseño,  se  tiende  a 
enfatizar  la  visión  del  diseñador  de  los  datos  a  través  del  modelo  lógico:  más  cercano  a  la 
implementación, nos permite definir las estructuras de la base de datos.  

 
En  esta  lectura  se  presenta  la  estática  del  modelo  relacional,  en  el  marco  formal  del 
 
modelo  de  datos  conceptual,  insistiendo  en  aquellos  conceptos,  como  lo  es  la  llave 
  foránea  y  las  restricciones,  que  más  afectan  al  diseño.  Por  último,  exploraremos 
brevemente las ventajas de controlar las restricciones de integridad referencial con el 
  objeto de construir sistemas con mayor tolerancia a fallas. 
   

A  partir  de  esta  unidad  usted  estará  en  capacidad  de  utilizar  su  criterio  profesional  para 
determinar cómo y en qué grado el sistema de bases de datos está sujeto a modificaciones. 

1. DESARROLLO TEMÁTICO 
El proceso de diseño de bases de datos es iterativo y no un proceso lineal o secuencial. La 
construcción  de  un  modelo  lógico  de  bases  de  datos  generalmente  se  inicia  con  la 
transformación  del  modelo  conceptual  de  la  misma.  El  modelo  de  datos  lógico  o  modelo 
relacional (MER) fue presentado por Codd en 1970, que era un experto matemático, utilizó 
una terminología perteneciente a las matemáticas, en concreto de la teoría de conjuntos y de 
la  lógica  de  predicados.  El  objetivo  principal  del  MER  es  aislar  al  usuario  de  las  estructuras 
físicas  de  los  datos,  consiguiendo  así  la  independencia  de  las  aplicaciones  respecto  de  los 
datos, finalidad esperada desde los inicios de las bases de datos. 

 
El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y 
  la  lógica  de  predicados  de  primer  orden.  El  hecho  de  que  el  modelo  relacional  esté 
  basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo 
tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios 
  para  crear  una  base  de  datos  relacional  con  una  buena  estructura,  y  proporcionan  las 
líneas que se utilizan para formular buenas metodologías de diseño.  
 
 

 
[ BASE DE DATOS ] 3
  

La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que 
el  modelo  sea  predecible,  fiable  y  seguro.  La  teoría  describe  los  elementos  básicos  que  se 
utilizan  para  crear  una  base  de  datos  relacional  y  proporciona  las  líneas  a  seguir  para 
construirla.  El  organizar  estos  elementos  para  conseguir  el  resultado  deseado  es  lo  que  se 
denomina diseño. 

Diseño lógico de bases de datos 
El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un 
esquema lógico es una descripción de la estructura de la base de datos en términos de las 
estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje 
usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño 
lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.  

El  modelo  entidad  relación  entre  entidades  (MER)  utiliza  diagramas  ER  (Entidad  Relación) 
para  representar  la  base  de  datos  lógica  e  ilustrar  la  estructura  de  la  base  de  datos  del 
negocio modelado muy cercano a la implementación.  

La estructura básica y única, del modelo relacional es la relación (también llamada tabla), que 
sirve para representar tanto los objetos como las asociaciones entre ellos. Los atributos son 
las propiedades de las relaciones, y se definen sobre los dominios, los cuales, a diferencia de 
los  atributos,  tienen  vida  propia,  es  decir,  existen  con  independencia  de  cualquier  otro 
elemento del modelo, mientras que la existencia de un atributo va unida a la de la relación a 
la que pertenece. 

Componentes de un Diagrama Relacional (MER) 
Una relación es una tabla con columnas y filas. Un Sistema de Gestión de Bases de Datos –
SGBD‐  sólo  necesita  que  el  usuario  pueda  percibir  la  base  de  datos  como  un  conjunto  de 
tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos (en el nivel 
externo  y  conceptual  de  la  arquitectura  de  tres  niveles  ANSI‐SPARC).  No  se  aplica  a  la 
estructura física de la base de datos, que se puede implementar con distintas estructuras de 
almacenamiento. Una relación se representa gráficamente como una tabla bidimensional en 
la  que  las  filas  corresponden  a  registros  individuales  y  las  columnas  corresponden  a  los 
campos  o  atributos  de  esos  registros.  Los  atributos  pueden  aparecer  en  la  relación  en 
cualquier orden. 

Un dominio es un conjunto nominado, finito, con valores homogéneos porque son todos del 
mismo tipo, e indivisible en lo que respecta al modelo relacional; no puede, por tanto, ser a 
su vez una relación, ni un grupo repetitivo, etc. de uno o varios atributos. Cada dominio se 
especifica  lógicamente  mediante  un  nombre  y  un  formato,  el  cual  puede  definirse  por 
extensión (dando sus posibles valores) o por intención (mediante un tipo de datos). A veces 
se asocia al dominio su unidad de medida (kilos, metros, etc.) y ciertas restricciones (como 
un rango de valores). 

 
4  [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]
 

Por  ejemplo,  iniciando  la  transformación  del  modelo  conceptual  diseñado  en  la  lectura  1, 
relacionado  con  “Control  de  salas  en  un  hospital”,  podemos  definir  el  dominio  Personal, 
cuyo  conjunto  de  valores,  definido  por  extensión,  podría  ser:  servicios,  administrativos  y 
médicos  generales,  entre  otros.  Otro  dominio  podría  ser  Códigos,  definido  por  intensión 
como caracter. 

Un  atributo  es  el  nombre  de  una  columna  de  una  relación,  es  la  interpretación  de  un 
determinado dominio en una relación, es decir, el papel que desempeña en la misma; si D es 
el dominio de A se denota: 

D=Dom(A). 

Por  ejemplo,  en  la  relación  Personal,  un  atributo  puede  ser  nombre  (nom)  y  otro  teléfono 
(tel) definidos, respectivamente, sobre el dominio Personal. 

Un atributo y un dominio pueden llamarse igual, pero hay que tener en cuenta que: 

• Un  atributo  está  siempre  asociado  con  una  relación,  mientras  que  un  dominio 
tiene existencia propia con independencia de las relaciones. 

• Un atributo representa una propiedad de una relación. 

• Un atributo toma valores de un dominio. 

• Varios atributos distintos (de la misma o de diferentes relaciones) pueden tomar 
sus valores del mismo dominio. 

Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la 
tabla.  En  la  relación  Pacientes,  cada  tupla  tiene  dos  valores,  uno  para  cada  atributo.  Las 
tuplas de una relación no siguen ningún orden. 

El grado de una relación es el número de atributos que contiene. La relación Salas es de grado 
dos porque tiene dos atributos. Esto quiere decir que cada fila de la tabla es una tupla con 
dos valores. El grado de una relación no cambia con frecuencia.  

La cardinalidad de una relación es el número de tuplas que contiene. Ya que en las relaciones 
se  van  insertando  y  borrando  tuplas  a  menudo,  la  cardinalidad  de  las  mismas  varía  en  el 
transcurso del tiempo. 

Para  precisar  mejor  el  concepto  de  relación  lo  definimos  en  base  a  sus  atributos, 
distinguiendo entre esquema de relación y relación: un esquema de relación se compone de 
un nombre de relación R, de un conjunto de n atributos {Ai} y de un conjunto de n dominios 
(no necesariamente distintos) {Di}, donde cada atributo será definido sobre un dominio: 

          R(A1:D1, A2:D2,…An:Dn) 

 
[ BASE DE DATOS ] 5
  

Una  relación  r(R)  es  un  conjunto  de  m  elementos  denominados  tuplas  {tj}.  Cada  tupla  es 
conjunto de pares (<A1:v1j>,…<Ai:vij>,…<An:vnj>) donde cada Ai es el nombre de un atributo y 
vij es un valor del correspondiente dominio Di sobre el que está definido el atributo: 

r(R)= tj {(<A1:v1j>,…<Ai:vij>,…<An:vnj>): vij ϵ Di} 

Los conceptos de tabla y relación no deben ser confundidos, puesto que: 

 Una tabla es un forma de representar una relación. 

 Una  relación  tiene  unas  propiedades  intrínsecas  que  no  tiene  una  tabla,  y  que  se 
derivan  de  la  misma  definición  matemática  de  relación,  ya  que,  al  tratarse  de  un 
conjunto, en una relación: 

• No puede haber dos tuplas iguales. 

• El orden de las tuplas no es significativo. 

• El orden de los atributos no es significativo. 

• Cada atributo sólo puede tomar un único valor del dominio simple subyacente; no 
se  admiten  grupos  repetitivos  (ni  otro  tipo  de  estructuras)  como  valores  de  los 
atributos de una tupla. 

En  toda  relación  siempre  hay  una  llave  primaria.  Una  llave  primaria  es  un  atributo  o  un 
conjunto de atributos que identifican de modo único las tuplas de una relación. Los atributos 
que  forman  la  llave  primaria  no  pueden  tomar  valores  nulos.  Una  llave  secundaria  o 
alternativa  es  aquella  llave  candidata  que  no  ha  sido  elegida  como  llave  primaria  de  la 
relación. Una llave foránea es un atributo o un conjunto de atributos de una relación cuyos 
valores  coinciden  con  los  valores  de  la  clave  primaria  de  alguna  otra  relación  (puede  ser  la 
misma). Las llaves foráneas representan relaciones entre datos. Se dice que un valor de llave 
foránea representa una referencia a la tupla que contiene el mismo valor en su llave primaria 
(tupla referenciada). 

Dentro de las restricciones propias del modelo MER se encuentra la de integridad referencial, 
que  es  condición  y  acción  específicas  y  que  afirma:  “si  una  relación  R2  tiene  descriptor  FK 
(foreing key) que es llave foránea que referencia a la llave primaria PK de la relación R1, todo 
valor de FK debe coincidir con un valor de PK (primary key), o ser nulo”. Ésta es la condición 
de la restricción, la cual puede expresarse como un predicado: 

            R2.FK = R1.PK 

 
6  [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]
 

Los  descriptores  FK  y  PK  han  de  estar  definidos  sobre  el  mismo  dominio  y  se  permite  que 
sobre FK se defina, si es necesario, la restricción de obligatoriedad (si no se define, la llave 
foránea admitirá valores nulos). 

En  cuanto  a  la  acción  es  de  tipo  específico.  Si  se  intenta  eliminar  una  tupla  en  la  tabla  que 
referencia  R2,  que  no  cumpla  la  condición,  la  acción  es  de  rechazo.  Si  la  condición  falla 
debido  a  una  operación  de  borrado  de  tuplas  o  de  modificación  de  la  llave  primaria  en  la 
tabla  referenciada  R1,  existe  la  posibilidad  de  elegir  entre  cuatro  opciones,  tanto  para  la 
operación de borrado como para la de modificación: 

- NO ACTION: rechazar la operación. 

- CASCADE: propagar la modificación o borrar las tuplas de la tabla que referencia. 

- SET NULL: poner valor nulo en la CA de la tabla que referencia. 

- SET DEFAULT: poner valor por defecto en la CA de la tabla que referencia. 

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la 
base  de  datos  pueden  imponer  ciertas  restricciones  específicas  sobre  los  datos, 
denominadas  reglas  de  negocio.  Por  ejemplo,  si  en  una  sala  del  hospital  sólo  puede  haber 
hasta  tres  pacientes,  el  SGBD  debe  dar  la  posibilidad  al  usuario  de  definir  una  regla  al 
respecto  y  debe  hacerla  respetar.  En  este  caso,  no  debería  permitir  el  registro  de  más 
pacientes en una sala que ya tiene los tres permitidos.  

 
Cuando  en  una  tupla  un  atributo  es  desconocido,  se  dice  que  es  nulo.  Un  nulo  no 
  representa el valor cero ni la cadena vacía, éstos son valores que tienen significado. El 
nulo  implica  ausencia  de  información,  bien  porque  al  insertar  la  tupla  se  desconocía  el 
  valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido. La primera 
  regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de los 
atributos que componen la clave primaria puede ser nulo.  
 
 
En cuanto a la implementación de la llave foránea y la integridad referencial, hay que darle 
prioridad  también  a  la  eficiencia,  y,  desafortunadamente,  el  mecanismo  para  la 
comprobación  de  la  integridad  referencial  compromete  los  tiempos  de  respuesta  de  las 
aplicaciones. 

Por ejemplo, basta con pensar que el borrado de un registro en la tabla Salas puede provocar 
el  borrado  (en  CASCADA)  de  varios  registros  de  otras  tablas,  y  así  sucesivamente,  con  el 
siguiente aumento de tiempo, lo que es grave en caso de uso interactivo del sistema. Puede 
ser,  por  tanto,  inviable  en  ciertas  aplicaciones  y  bajo  determinadas  circunstancias  (como 
grandes  volúmenes  de  datos,  hardware  poco  eficiente,  entre  otros)  implementar  la 

 
[ BASE DE DATOS ] 7
  

integridad referencial en línea, siendo preferible hacerlo en un programa que se ejecute en 
diferido (por lotes) y no de forma interactiva. 

En  este  caso  se  van  almacenando  los  cambios  que  afectan  a  la  integridad  referencial  en  la 
base  de  datos,  aprovechando  cuando  el  sistema  esté  menos  cargado  para  ejecutar  un 
procedimiento  que  vaya  comprobando  y  realizando  las  acciones  pertinentes.  Como 
contrapartida  a  la  mejora  de  la  eficiencia  tenemos  que  ser  consistentes  de  que  la  base  de 
datos queda semánticamente inconsistente durante ciertos periodos de tiempo. 

La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos 
fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.  

 Construir y validar los esquemas lógicos para cada vista de usuario.  

• Convertir los esquemas conceptuales en esquemas lógicos.  

• Derivar un conjunto de relaciones (tablas) para cada esquema lógico.  

• Validar cada esquema mediante la normalización.  

• Validar cada esquema frente a las transacciones del usuario.  

• Dibujar el diagrama entidad‐relación.  

• Definir las restricciones de integridad.  

• Revisar cada esquema lógico con el usuario correspondiente.  

 Construir y validar el esquema lógico.  

• Validar el esquema lógico global.  

• Estudiar el crecimiento futuro.  

• Dibujar el diagrama entidad‐relación final.  

• Revisar el esquema lógico con los usuarios. 

Para  terminar,  nos  corresponde  realizar  el  diseño  lógico  de  la  base  de  datos  (ver  Figura  1. 
Modelo  Lógico  Relacionado  con  Control  de  Salas  en  un  Hospital),  a  través  del  uso  de  la 
notación correspondiente para plasmar modelos MER usando la herramienta DBDesigner: 

 
8  [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]
 

Figura 1. Modelo Lógico Relacionado con Control de Salas en un Hospitali 

El esquema relacional de la base de datos de Control de Salas en un Hospital es el siguiente: 

SALAS(cod_sala, nombre_sala, num_camas) 

PERSONAL(ced_personal,  Salas_cod_sala,  cod_emp_personal,  nombre_personal, 

direccion_personal, telefono_personal) 

  LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS 

PACIENTES(ced_reg_paciente, Salas_cod_sala, nombre_paciente) 

  LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS 

En  el  esquema,  los  nombres  de  las  relaciones  aparecen  en  mayúsculas  y  seguidos  de  los 
nombres de los atributos encerrados entre paréntesis. Las llaves primarias son los atributos 
en negrilla y subrayados. Las llaves foráneas se representan mediante cursivas y subrayados. 
Las llaves alternativas aparecen en color anaranjado y subrayado. 

 
[ BASE DE DATOS ] 9
  

Conclusiones
- Un  paso  importante  es  la  conversión  del  esquema  conceptual  a  un  esquema  lógico 
adecuado  al  modelo  relacional.  Para  ello,  se  deben  hacer  algunas  transformaciones: 
eliminar  las  relaciones  de  muchos  a  muchos,  eliminar  las  relaciones  complejas, 
eliminar  las  relaciones  recursivas,  eliminar  las  relaciones  con  atributos,  eliminar  los 
atributos  multievaluados,  reconsiderar  las  relaciones  de  uno  a  uno  y  eliminar  las 
relaciones redundantes. 

- El  modelo  lógico  es  el  resultado  de  transformar  el  modelo  conceptual  y  puede 
expresar  varios  tipos  de  restricciones  de  integridad:  las  llaves,  las  restricciones  de 
participación, entre otras. Algunas restricciones de llave foránea son implícitas en la 
definición de la relación. 

- Las  restricciones  juegan  un  papel  importante  en  la  definición  del  mejor  diseño  de  la 
base de datos para una empresa. 

- Un  buen  diseño  de  una  base  de  datos  se  asegura:  utilizando  y  refinando  el  diseño 
lógico resultante. La información de las dependencias funcionales y la normalización 
son esencialmente útiles. 

1.1. BIBLIOGRAFÍA 
- C.J. Date, Introducción a los Sistemas de Bases de Datos, 5.ª edición, Adison Wesley 
Iberoamericana, 1993. 

- Korth  y  A.  Siulberschatz,  Fundamentos  de  Bases  de  Datos,  4.ª  edición,  McGraw‐Hill, 
Madrid, 2002. 

- Elmasri,  R.  &  Navathe,  S.B.  “Fundamentals  Of  Database  Systems”  Third  Edition. 
Addison‐ Wesley Pubs. 2000. 

- Rob, Peter.; Coronel, Carlos. “Sistemas de Bases de Datos: diseño, implementación y 
administración”, Quinta Edición, THOMSON, 2002. 

                                                        
i
 Carreño. G. Johany. A. Modelo Lógico Relacionado con Control de Salas en un Hospital. Diseño desarrollado en 
la herramienta DBDesigner. 2010. 

 
10  [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]