Diseño Físico

SEMANA 2
  BASE DE DATOS 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 

 
 
 
 

 
 
 
   

[ BASE DE DATOS ]
  

CONTENIDO 
 
 
 
 
PRESENTACIÓN ……………………………………………………  3 
 
1. DESARROLLO TEMÁTICO ……………………………………….  3 
• Diseño Físico de bases de datos ……………………………  4 
• Traducir el esquema lógico para el SGBD específico ……. .  4 
• Diseñar el nivel físico ……...……………….………………         10 
• Diseñar los mecanismos de seguridad .……………………        12 
 
1.1. BIBLIOGRAFÍA ……...……………….………………….. ……         13 
 

  

 
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  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  el  modelo  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 el cual, 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 pretenden 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. 

 
[ BASE DE DATOS ] 3
  

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 
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. 

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

• 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 y eso, cada sistema lo hace de una manera u otra. 
 
http://www.postgresql.org/docs/8.1/static/ddl‐constraints.html 
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,  nos  permite  definir  las  columnas  que  tiene  y  ciertas  restricciones  que  deben 
cumplir esas columnas. 
*/ 
 
CREATE TABLE salas 
(  
 
/* Para mayor información sobre los tipos de datos en PostgreSQL, referirse a: 
http://www.postgresql.org/docs/7.4/interactive/datatype.html 

 
[ BASE DE DATOS ] 5
  

*/ 
 
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. 
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. 
http://www.postgresql.org/docs/8.1/static/ddl‐constraints.html 
 
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; 
 

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

‐‐ 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  
*/ 
 
   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 
 

 
[ BASE DE DATOS ] 7
  

/* 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, 
  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 

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

*/ 
 
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. 

 
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. 

 
[ BASE DE DATOS ] 9
  

Todas  las  restricciones  que  se  definan  deben  estar  documentadas.  Si  hay  varias  opciones 
posibles  para  implementarlas,  hay  que  explicar  porqué  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 

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

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.  

- 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: 

 
[ BASE DE DATOS ] 11
  

• 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  en 
cuanto  a  seguridad  que  en  esta  fase  se  deben  implementar.  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. 

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

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 monitorizar 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 monitorizar y afinar el sistema para obtener 
el  mejor  “performance”  y  satisfacer  los  cambios  que  se  puedan  producir  en  los 
requisitos. 

1.1. BIBLIOGRAFÍA 
 

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

 
[ BASE DE DATOS ] 13
  

- 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. 

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