Fundamentos de bases de

SEMANA 2   DATOS 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 
   

[ FUNDAMENTOS DE BASES DE DATOS ]

  

CONTENIDO 
 
PRESENTACIÓN …………………………….………………………… 3 
 
1. DESARROLLO TEMÁTICO ……………………………………..…… 3 
Diseño Físico de Bases de Datos ………….…....................… 3 
Traducir el esquema lógico para el SGBD Específico ………. 6 
Diseñar el Nivel Físico ……………………………….………. 6 
Diseñar los mecanismos de seguridad ………………………6 
 
BIBLIOGRAFÍA ………………………………………………………... 8 
 
 
 
 
 
 
 
 
 
 

 
2  [ POLITÉCNICO GRANCOLOMBIANO ]
 

 
DISEÑO FÍSICO 
JOHANY ARMANDO CARREÑO GAMBOA 
jcarreno@poli.edu.co  
 

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  del  Sistema  de  Gestión  de  Bases  de  Datos  PostgreSQL  para  la  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  de  los  diferentes  modelos  de  datos, 
como es el físico, que adapta el modelo lógico y es la representación de la base de datos tal 
como la ve el sistema de gestión de bases de datos.  
A partir de esta unidad los participantes tendrán las habilidades básicas para iniciar el diseño 
y desarrollo de sus propios y nuevos sistemas de bases de datos. 
 
1. DESARROLLO TEMÁTICO 
El  diseño  físico  parte  del  esquema  lógico  y  da  como  resultado  un  esquema  físico.  Un 
esquema físico es una descripción de la implementación de una base de datos en memoria 
secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso 
eficiente  a  los  datos.  Por  ello,  el  diseño  físico  depende  del  sistema  de  gestión  de  bases  de 
datos concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.  
La última etapa del proceso es la del diseño físico. En ella, teniendo presentes requisitos de 
los  procesos,  características  de  los  Sistemas  de  Gestión  de  Bases  de  Datos,  del  Sistema 
Operativo y del Hardware se pretende, entre otros, los siguientes objetivos: 
• Disminuir los tiempos de respuesta 
• Minimizar el espacio de almacenamiento 
• Evitar las reorganizaciones 
• Proporcionar la máxima seguridad 
• Optimizar el consumo de recursos 
En  conclusión,  cumplir  con  los  objetivos  del  sistema  y  conseguir  la  optimización 
costo/beneficio. 
 
DISEÑO FÍSICO DE BASES DE DATOS 
Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica 
cómo se guarda. Para ello, los diseñadores deben conocer muy bien toda la funcionalidad del 

 
[ FUNDAMENTOS DE BASES DE DATOS ] 3
  

Sistema  de  Gestión  de  Bases  de  Datos  (SGBD)  concreto  que  se  vaya  a  utilizar,  el  sistema 
operativo, y también el lenguaje de programación sobre el que éste va a trabajar. El diseño 
físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, 
por ejemplo, para mejorar el rendimiento del sistema, pueden provocar una reestructuración 
del esquema lógico. 
El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos: 
 
TRADUCIR EL ESQUEMA LÓGICO PARA EL SGBD ESPECÍFICO 
La primera fase del diseño lógico consiste en traducir el esquema lógico en un esquema que 
se  pueda  implementar  en  el  SGBD  elegido.  Para  ello,  es  necesario  conocer  toda  la 
funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber: 
• Si  el  sistema  soporta  la  definición  de  llaves  primarias,  llaves  foráneas  y  llaves 
alternativas. 
• Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir 
atributos como no nulos). 
• Si el sistema soporta la definición de dominios. 
• Si el sistema soporta la definición de reglas de negocio. 
• Cómo se crean las relaciones base. 
 
DISEÑAR LAS RELACIONES BASE PARA EL SGBD ESPECÍFICO 
Las relaciones base se definen mediante el lenguaje de definición de datos (LDD) del SGBD. 
Para ello, se utiliza la información producida durante el diseño lógico: el esquema relacional y 
el  diccionario  de  datos.  El  esquema  relacional  consta  de  un  conjunto  de  relaciones  y  para 
cada una de ellas se tiene: 
• El nombre de la relación 
• La lista de atributos entre paréntesis 
• La llave primaria y las llaves foráneas, si las tiene 
• Las reglas de integridad de las llaves foráneas 
En el diccionario de datos se describen los atributos y, para cada uno de ellos, se tiene: 
• Su dominio: tipo de datos, longitud y restricciones de dominio 
• El valor por defecto, que es opcional 
• Si admite nulos 
• Si es derivado y, en caso de serlo, cómo se calcula su valor 
A continuación, se muestra un ejemplo de la definición de la Base de Datos “Control de Salas 
en un Hospital” con el SGBD PostgreSQL 8.3. 
/*  Inicio de la transacción "definición de las tablas" con sentencias que afectan la estructura 
de la base de datos (DDL). 
El DDL (Data  Definition Language), lenguaje de definición de datos, es la parte del SQL que 
más  varía  de  un  sistema  a  otro,  ya  que  esa  área  tiene  que  ver  con  cómo  se  organizan 
internamente los datos, algo que cada sistema hace de una manera u otra. 
http://www.postgresql.org/docs/8.1/static/ddl‐constraints.html 

 
4  [ POLITÉCNICO GRANCOLOMBIANO ]
 

http://www.ibiblio.org/pub/linux/docs/LuCaS/Postgresql‐
es/web/navegable/todopostgresql/postgres.htm 
*/ 
 
BEGIN; 
SAVEPOINT FIRST; 
 
/*  La  sentencia  CREATE  TABLE  sirve  para  crear  la  estructura  de  una  tabla,  no  para 
completarla  con  datos.  Permite  definir  las  columnas  que  tiene  y  ciertas  restricciones  que 
deben cumplir esas columnas. 
*/ 
 
CREATE TABLE salas1 
(  
 
/* Para mayor información sobre los tipos de datos en PostgreSQL, referirse a: 
http://www.postgresql.org/docs/7.4/interactive/datatype.html 
*/ 
 
cod_sala int4 UNIQUE NOT NULL, 
nombre_sala varchar(20) NOT NULL, 
num_camas int NOT NULL, 
 
/*  La  integridad  referencial  es  un  sistema  de  reglas  que  utilizan  la  mayoría  de  las  bases  de 
datos relacionales para asegurarse que los registros de tablas relacionadas son válidos y que 
no  se  borren  o  cambien  datos  relacionados  de  forma  accidental  produciendo  errores  de 
integridad. 
Si  necesitas  repasar  los  conceptos  de  integridad  referencial,  puedes  visitar  el  siguiente 
enlace: http://www.aulaclic.es/sql/b_8_2_1.htm 
*/ 
   
CONSTRAINT num_camas_chk CHECK (num_camas <= 3), 
 
/*  DEFINICIÓN  DE  LAS  RESTRICCIONES  /  CONSTRAINT:  Esto  permite  seleccionar  una  de  las 
restricciones (CONSTRAINT) de llave primaria (PRIMARY KEY) o única(UNIQUE) definido en 
la columna de referencia.  
Elegir  una  restricción  definirá  las  columnas  de  la  tabla  de  referencia  que  se  utilizarán  en  la 
referencia. 

                                                        
1
 PostgreSQL.  PostgreSQL  Documentation:  Recuperado  de  
http://www.postgresql.org/docs/7.4/interactive/datatype.html. 20 de Abril de 2012. 15h30. 

 
[ FUNDAMENTOS DE BASES DE DATOS ] 5
  

La  cláusula  CONSTRAINT  sirve  para  definir  una  restricción    que  se  podrá  eliminar  cuando 
queramos sin tener que borrar la columna. A cada restricción se le asigna un nombre que se 
utiliza  para  identificarla  y  para  poder  eliminarla  cuando  se  quiera.  Como  restricciones 
tenemos la de llave primaria (llave principal), la de índice único (sin duplicados), la de valor 
no nulo, y la de llave foránea.2 
Las restricciones pueden ser: 
PRIMARY KEY es parte de la llave primaria. 
NOT NULL no puede ser nulo. 
UNIQUE debe ser único. 
DEFAULT valor por defecto. 
CHECK condición que debe cumplirse.   
*/ 
 
  CONSTRAINT cod_sala_pk PRIMARY KEY(cod_sala) 
); 
 
SAVEPOINT SECOND; 
 
‐‐ Se requiere gestionar la información de los Pacientes. 
 
CREATE TABLE pacientes 
(  
  ced_reg_paciente int4 UNIQUE NOT NULL, 
  nombre_paciente varchar(45) NOT NULL, 
  salas_cod_sala int4 NOT NULL, 
  CONSTRAINT ced_reg_paciente_pk PRIMARY KEY(ced_reg_paciente), 
  CONSTRAINT  salas_pacientes_fk  FOREIGN  KEY(salas_cod_sala)  REFERENCES 
salas(cod_sala) 
 
/* Llaves foráneas: MATCH FULL, MATCH SIMPLE, DEFAULT 
MATCH  FULL  todos  nulos  o  ninguno.  No  permite  que  una  columna  tenga  el  valor  NULL  en 
una llave foránea compuesta por varias columnas. 
MATCH  SIMPLE  Permite  que  una  columna  tenga  el  valor  NULL  en  una  llave  foránea 
compuesta por varias columnas. 
DEFAULT la llave foránea puede estar incompleta. 
Para mayor información, referirse a: http://www.arpug.com.ar/trac/wiki/sql‐createtable.html  
*/ 
 

                                                        
2
 PostgreSQL. PostgreSQL Documentation: Recuperado de http://www.postgresql.org/docs/8.1/static/ddl‐
constraints.html. 20 de Abril de 2012. 15h30. 

 
6  [ POLITÉCNICO GRANCOLOMBIANO ]
 

   MATCH FULL 
 
/* Llaves foráneas: 
REFERENCES tabla [(columna)] 
ON DELETE acción 
ON UPDATE acción 
Posibles acciones:  
NO ACTION: produce un error indicando que un DELETE ó UPDATE creará una violación de la 
clave foránea definida. 
RESTRICT: produce un error indicando que un DELETE ó UPDATE creará una violación de la 
clave foránea definida. 
CASCADE: borra ó actualiza automáticamente todas las referencias activas. 
SET NULL: define las referencias activas como NULL. 
SET DEFAULT: define las referencias activas como el valor por defecto (si está definido) de 
las mismas. 
Acción por defecto: NO ACTION 
*/ 
 
   ON DELETE NO ACTION 
   ON UPDATE CASCADE 
 
/* Llaves foráneas: 
INITIALLY DEFERRED chequeo de integridad al final de la transacción. 
INITIALLY INMEDIATE chequeo de integridad durante toda la transacción (por defecto). 
NOT DEFERRABLE indica que el chequeo no se puede postergar. 
DEFERRABLE indica que el chequeo se puede postergar (por defecto). 
Para mayor información, referirse a: http://www.arpug.com.ar/trac/wiki/sql‐createtable.html 
http://www.ibiblio.org/pub/linux/docs/LuCaS/Postgresql‐
es/web/navegable/todopostgresql/sql‐createtable.htm 
*/ 
 
  DEFERRABLE INITIALLY DEFERRED 
); 
 
 
‐‐ Se requiere gestionar la información del Personal. 
 
CREATE TABLE personal 
(  
  ced_personal int4 UNIQUE NOT NULL, 
  cod_emp_personal int4 UNIQUE NOT NULL, 
  nombre_personal varchar(45) NOT NULL, 

 
[ FUNDAMENTOS DE BASES DE DATOS ] 7
  

  direccion_personal varchar(255) NOT NULL, 
  telefono_personal int DEFAULT 0, 
  salas_cod_sala int4 NOT NULL, 
  CONSTRAINT ced_personal_pk PRIMARY KEY(ced_personal), 
  CONSTRAINT  salas_personal_fk  FOREIGN  KEY(salas_cod_sala)  REFERENCES 
salas(cod_sala) 
  MATCH FULL 
  ON DELETE NO ACTION 
  ON UPDATE CASCADE 
  DEFERRABLE INITIALLY DEFERRED 
); 
 
/* La sentencia CREATE INDEX sirve para crear un índice sobre una o varias columnas de una 
tabla. Para repasar conceptos básicos sobre índices puede referirse a:  
http://www.aulaclic.es/sql/b_8_4_1.htm 
http://www.postgresql.org/docs/8.2/static/sql‐createindex.html 
http://www.ibiblio.org/pub/linux/docs/LuCaS/Postgresql‐
es/web/navegable/todopostgresql/sql‐createindex.html 
*/ 
 
CREATE INDEX ced_personal_index ON personal(nombre_personal ASC); 
CREATE INDEX cod_emp_personal ON personal(nombre_personal ASC); 
 
‐‐ Fin de la transacción "definición de las tablas" 
END; 
 
DISEÑAR LAS REGLAS DE NEGOCIO PARA EL SGBD ESPECÍFICO 
Las actualizaciones que se realizan sobre las relaciones de la base de datos deben observar 
ciertas  restricciones  que  imponen  las  reglas  de  negocio  de  la  empresa.  Algunos  SGBD 
proporcionan  mecanismos  que  permiten  definir  estas  restricciones  y  controlan  que  no  se 
violen. Por ejemplo: 
• El número de camas por sala debe ser menor que 3. 
CONSTRAINT num_camas_chk CHECK (num_camas <= 3) 
• Una sala no puede tener asignados más de 3 pacientes. 
CONSTRAINT  pacientes_por_sala  CHECK  (NOT  EXISTS  (SELECT  salas_cod_sala                     
FROM   pacientes GROUP BY salas_cod_sala HAVING COUNT(*)<3)) 
• Si  no  se  quiere  que  una  sala  tenga  más  de  diez  empleados  (personal)  asignados,  se 
puede definir una restricción en la sentencia CREATE TABLE de la relación personal. 
CONSTRAINT  personal_por_sala  CHECK  (NOT  EXISTS  (SELECT  salas_cod_sala                     
FROM   personal GROUP BY salas_cod_sala HAVING COUNT(*)<10)) 
Otro  modo  de  definir  las  restricciones  es  mediante  un  disparador,  tema  que  estaremos 
tratando en otra lectura. 

 
8  [ POLITÉCNICO GRANCOLOMBIANO ]
 

Hay  algunas  restricciones  que  no  las  pueden  manejar  los  SGBD,  como  por  ejemplo  “a  las 
23:50 horas del último día laboral de cada año archivar los pacientes atendidos y borrarlos”. 
Para estas restricciones habrá que escribir programas de aplicación específicos. Por otro lado, 
hay SGBD que no permiten la definición de restricciones, por lo que éstas deberán incluirse 
en los programas de aplicación. 
Todas  las  restricciones  que  se  definan  deben  estar  documentadas.  Si  hay  varias  opciones 
posibles  para  implementarlas,  hay  que  explicar  por  qué  se  ha  escogido  la  opción 
implementada. 
 
DISEÑAR EL NIVEL FÍSICO 
Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. 
Para medir la eficiencia hay varios factores que se deben tener en cuenta: 
• Productividad de transacciones. Es el número de transacciones que se quiere procesar 
en un intervalo de tiempo. Para cada transacción hay que especificar: 
 La frecuencia con que se va a ejecutar. 
 Las relaciones y los atributos a los que accede la transacción y el tipo de acceso: consulta, 
inserción,  modificación  o  eliminación.  Los  atributos  que  se  modifican  no  son  buenos 
candidatos para construir estructuras de acceso. 
 Los  atributos  que  se  utilizan  en  los  predicados  del  WHERE  de  las  sentencias  SQL.  Estos 
atributos pueden ser candidatos para construir estructuras de acceso dependiendo del tipo 
de predicado que se utilice. 
 Si  es  una  consulta,  los  atributos  involucrados  en  el  join  de  dos  o  más  relaciones.  Estos 
atributos pueden ser candidatos para construir estructuras de acceso. 
 Las  restricciones  temporales  impuestas  sobre  la  transacción.  Los  atributos  utilizados  en 
los predicados de la transacción pueden ser candidatos para construir estructuras de acceso. 
• Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el 
punto de vista del usuario, este tiempo debería ser el mínimo posible. 
• Espacio en disco. Es la cantidad de espacio en disco que hace falta para los archivos de 
la base de datos. Normalmente, el diseñador debe minimizar este espacio. 
Para  mejorar  el  rendimiento,  el  diseñador  del  esquema  físico  debe  saber  cómo  interactúan 
los dispositivos involucrados y cómo esto afecta al sistema: 
• Memoria  principal.  Los  accesos  a  memoria  principal  son  mucho  más  rápidos  que  los 
accesos a memoria secundaria (decenas o centenas de miles de veces más rápidos). 
Generalmente,  cuanta  más  memoria  principal  se  tenga,  más  rápidas  serán  las 
aplicaciones.  Sin  embargo,  es  aconsejable  tener  al  menos  un  5%  de  la  memoria 
disponible, pero no más de un 10%. Si no hay bastante memoria disponible para todos 
los  procesos,  el  sistema  operativo  debe  transferir  páginas  a  disco  para  liberar 
memoria  (paging).  Cuando  estas  páginas  se  vuelven  a  necesitar,  hay  que  volver  a 
traerlas  desde  el  disco  (faltas  de  página).  A  veces,  es  necesario  llevar  procesos 
enteros  a  disco  (swapping)  para  liberar  memoria.  El  hacer  estas  transferencias  con 
demasiada frecuencia empeora el rendimiento.  

 
[ FUNDAMENTOS DE BASES DE DATOS ] 9
  

• CPU.  La  CPU  controla  los  recursos  del  sistema  y  ejecuta  los  procesos  de  usuario.  El 
principal  objetivo  con  este  dispositivo  es  lograr  que  no  haya  bloqueos  de  procesos 
para conseguirla. Si el sistema operativo o los procesos de los usuarios hacen muchas 
demandas de CPU, ésta se convierte en un cuello de botella. Lo anterior suele ocurrir 
cuando hay muchas faltas de página o se realiza mucho swapping. 
• Acceso a disco. Los discos tienen una velocidad de entrada/salida. Cuando se requieren 
datos a una velocidad mayor que ésta, el disco se convierte en un cuello de botella. 
Dependiendo  de  cómo  se  organicen  los  datos  en  el  disco,  se  conseguirá  reducir  la 
probabilidad  de  empeorar  el  rendimiento.  Los  principios  básicos  que  se  deberían 
seguir para repartir los datos en los discos son los siguientes: 
 Los archivos del sistema operativo deben estar separados de los archivos de la 
base de datos. 
 Los archivos de datos deben estar separados de los archivos de índices. 
 Los archivos con los logs de transacciones deben estar separados del resto de 
los archivos de la base de datos. 
Por otra parte, los archivos dispersos (hashing) son apropiados cuando se accede a las tuplas 
a  través  de  los  valores  exactos  de  alguno  de  sus  campos  (condición  de  igualdad  en  el  
WHERE).  Si  la  condición  de  búsqueda  es  distinta  de  la  igualdad  (búsqueda  por  rango,  por 
patrón,  etc.),  la  dispersión  no  es  una  buena  opción.  Existen  mecanismos  de  organización, 
como  la  ISAM  o  los  árboles  B+.  La  organización  de  archivos  apropiada  y  definida  debe 
documentarse, justificando en cada caso la opción seleccionada. 
• Red. La red se convierte en un cuello de botella cuando tiene mucho tráfico y cuando 
hay muchas colisiones. 
Existen  otros  elementos  importantes  en  el  diseño  físico,  aunque  no  todos  los  SGBD 
comerciales  disponen  de  ellos.  O,  si  disponen  de  los  mismos,  a  veces  no  se  le  brinda  al 
diseñador  la  posibilidad  de  actuar  sobre  los  mismos  ajustándolos  a  cada  caso  concreto. 
Algunos de estos elementos son: 
• Registros físicos 
• Punteros 
• Direccionamiento calculado (hashing) 
• Agrupamiento (cluster) 
• Bloqueo y compresión de datos 
• Asignación de espacios de almacenamiento como memorias intermedias (buffers) 
• Asignación de conjuntos de datos a particiones y a dispositivos físicos, entre otros. 
Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos 
puede provocar mejoras en otros. 
 
DISEÑAR LOS MECANISMOS DE SEGURIDAD 
Los datos constituyen un recurso esencial para la empresa; por lo tanto, su seguridad es de 
vital  importancia.  Durante  el  diseño  lógico  se  habrán  especificado  los  requerimientos  de 

 
10  [ POLITÉCNICO GRANCOLOMBIANO ]
 

seguridad que se debe implementar en esta fase. Para llevar a cabo esta implementación, el 
diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya a utilizar. 
• Diseñar las vistas de los usuarios: el objetivo de este paso es diseñar las vistas de los 
usuarios correspondientes a los esquemas lógicos. Las vistas, además de preservar la 
seguridad,  mejoran  la  independencia  de  datos,  reducen  la  complejidad  y  permiten 
que los usuarios vean los datos en el formato deseado. 
• Diseñar las reglas de acceso: el administrador de la base de datos asigna a cada usuario 
un identificador que tendrá una palabra secreta asociada por motivos de seguridad. 
Para  cada  usuario  o  grupo  de  usuarios  se  otorgarán  permisos  para  realizar 
determinadas acciones sobre determinados objetos de la base de datos. Por ejemplo, 
los usuarios de un determinado grupo pueden tener permiso para consultar los datos 
de una relación base concreta y no tener permiso para actualizarlos. 
 
MONITOREAR EL SISTEMA 
Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para 
observar  sus  prestaciones.  Si  éstas  no  son  las  deseadas,  el  esquema  deberá  cambiar  para 
intentar satisfacerlas. Una vez afinado el esquema no permanecerá estático, ya que tendrá 
que  ir  cambiando  conforme  lo  requieran  los  nuevos  requisitos  de  los  usuarios.  Los  SGBD 
proporcionan herramientas para monitorear el sistema mientras está en funcionamiento. 
 
CONCLUSIONES 
• El diseño físico es el proceso de producir una descripción de la implementación de la 
base de datos en memoria secundaria. Describe las relaciones base y las estructuras 
de almacenamiento y métodos de acceso que se utilizarán para acceder a los datos de 
modo  eficiente.  El  diseño  de  las  relaciones  base  sólo  se  puede  realizar  cuando  el 
diseñador conoce perfectamente toda la funcionalidad que presenta el SGBD que se 
vaya a utilizar. 
• El  primer  paso  consiste  en  traducir  el  esquema  lógico  de  modo  que  pueda  ser 
fácilmente  implementado  por  el  SGBD  específico.  A  continuación,  se  escogen  la 
organización  de  archivos  más  apropiadas  para  almacenar  las  relaciones  base  y  los 
métodos  de  acceso,  basándose  en  el  análisis  de  las  transacciones  que  se  van  a 
ejecutar sobre la base de datos. Se puede considerar la introducción de redundancias 
controladas para mejorar el rendimiento. Otra tarea a realizar en este paso es estimar 
el espacio en disco. 
• La seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste 
en  diseñar  las  medidas  de  seguridad  necesarias  mediante  la  creación  de  vistas  y  el 
establecimiento de permisos para los usuarios. 
• El  último  paso  del  diseño  físico  consiste  en  monitorear  y  afinar  el  sistema  para 
obtener el mejor performance y satisfacer los cambios que se puedan producir en los 
requisitos. 
 

 
[ FUNDAMENTOS DE BASES DE DATOS ] 11
  

BIBLIOGRAFÍA 
 
• DATE, Christopher J. Introducción a los Sistemas de Bases de Datos. 7ma ed. México: 
Pearson Publications Company, 2001. 
• ELMASRI,  R.  y  NAVATHE,  S.B.  Fundamentals  of  Database  Systems.  6ta  ed.  United 
States of America: Addison Wesley, 2010. 
• KORTH  y  SIULBERSCHATZ,  A.  Fundamentos  de  Bases  de  Datos.  Cuarta  edición. 
Madrid: McGraw‐Hill, 2002. 
• ROB, Peter y CORONEL, Carlos. Sistemas de Bases de Datos: diseño, implementación 
y administración. 5 ed. México: Thomson, 2003. 
 
 
 
 
 

 
12  [ POLITÉCNICO GRANCOLOMBIANO ]