Captulo 1

La importancia de la informacin en la mayora de las organizaciones, y por tanto el valor de

la base de datos, ha llevado al desarrollo de una gran cantidad de conceptos y tcnicas para
la gestin eficiente de los datos. En este captulo presentamos una breve introduccin a los
principios de los sistemas de bases de datos.

Sistema de Ficheros el Origen de los sistemas de bases de datos

Considrese parte de una empresa bancaria de ahorros que guarda la informacin sobre todos
los clientes y cuentas de ahorro en archivos de sistemas permanentes en el banco. Adems,
el sistema tiene diversos programas de aplicacin que permiten al usuario manejar los
archivos, incluyendo:

Un programa para hacer cargos o abonos a una cuenta.

Un programa para aadir una nueva cuenta.
Un programa para obtener el saldo de una cuenta.
Un programa para generar estados mensuales

Estos programas de aplicacin los han escrito programadores de sistemas en respuesta a las
necesidades de la organizacin bancaria.

Segn surge la necesidad, se aaden nuevos programas de aplicacin al sistema. Por ejemplo,
supngase que una nueva ley del Gobierno permite al banco de ahorros ofrecer cuentas de
cheques. Como resultado, se crean nuevos archivos permanentes que contiene informacin
acerca de todas las cuentas de cheques que mantiene el banco, y puede que sea necesario
escribir nuevos programas de aplicacin. As, segn pasa el tiempo, se aaden ms archivos
y programas de aplicacin al sistema.

El tpico sistema de procesamiento de archivos descrito arriba est apoyado por un sistema
operativo convencional. Los registros permanentes se almacenan en varios archivos, y se
escribe un nmero de diferentes programas de aplicacin para extraer registros y aadir
registros a archivos apropiados. Este sistema tiene un nmero de desventajas importante.

Redundancia e inconsistencia de los datos.

o Puesto que los archivos y los programas de aplicacin son creados por
distintos programas durante un perodo largo de tiempo, es probable que los
archivos tengan diferentes formatos y los programas pueden estar duplicados
en varios sitios. Por ejemplo, la direccin y el nmero de telfono de un cliente
determinado pueden aparecer en un archivo que consta de registros de cuentas
de ahorros y en un archivo que consta de registros de cuentas de cheques. Esta
redundancia aumenta los costes de almacenamiento y acceso. Adems, puede
llevar a inconsistencia de los datos, esto es, las diversas copias de los mismos
datos no concuerdan entre s. Por ejemplo, una direccin cambiada de un
cliente puede estar reflejada en los registros de cuentas de ahorros, pero en
ningn sitio ms del sistema. Resultados de inconsistencia de los datos.
 Dificultad para tener acceso a los datos.
o Supngase que uno de los gerentes del banco necesita averiguar los nombres
de todos los gerentes del banco necesita averiguar los nombres de todos los
clientes que viven dentro del cdigo postal de la ciudad 78733. El gerente pide
al departamento de procesamiento de datos que genere la lista
correspondiente. Puesto que esta solicitud no fue prevista cuando se dise el
sistema original, no hay ningn programa de aplicacin a mano que la
satisfaga. Existe, sin embargo, un programa de aplicacin para generar la lista
de todos los clientes. El gerente tiene ahora dos elecciones: O bien tomar la
lista de clientes y extraer la informacin necesaria manualmente, o pedir al
departamento de procesamiento de datos que ponga a un programador de
sistemas a escribir el programa de aplicacin necesario.
o Lo que se trata de probar aqu es que esos entornos convencionales de
procesamiento de archivos no permiten recuperar los datos necesarios de una
forma conveniente y eficiente. Deben desarrollarse sistemas de recuperacin
de datos para uso general.
Aislamiento de los datos.
o Puesto que los datos estn repartidos en varios archivos, y stos pueden tener
diferentes formatos, es difcil escribir nuevos programas de aplicacin para
obtener los datos apropiados.
Anomalas del acceso concurrente.
o Al permitir que mltiples usuarios actualicen los datos simultneamente, la
interaccin de actualizaciones concurrentes puede dar por resultado datos
inconsistentes. Considrese una cuenta bancaria A, con Q.500. Si dos clientes
retiran fondos, Q50 y Q100, respectivamente, de la cuenta A casi al mismo
tiempo, el resultado de las ejecuciones concurrentes puede dejar la cuenta en
un estado incorrecto (o inconsistente). En particular, la cuenta puede contener
Q.450 o Q.400, en vez de Q.350. Para prevenir esta posibilidad, debe
mantenerse alguna forma de supervisin en el sistema. Puesto que se puede
acceder a los datos por medio de diversos programas de aplicacin diferentes
que no han sido previamente coordinados, esta supervisin es muy difcil de
proporcionar.
Problemas de seguridad.
o No todos los usuarios del sistema de base de datos deben poder acceder a
todos los datos. Por ejemplo, en un sistema bancario, el personal de las
nminas slo necesita ver la parte de la base de datos que tiene informacin
acerca de los distintos empleados del banco. No necesitan acceder a
informacin sobre las cuentas de los clientes.
Problemas de integridad.
o Los valores de datos almacenados en la base de datos deben satisfacer ciertos
tipos de restricciones de consistencia. Por ejemplo, el saldo de una cuenta
bancaria nunca debe caer por debajo de una cantidad prescrita, Q.25. Esta
restriccin se hace cumplir en el sistema aadiendo cdigos apropiados en los
diversos programas de aplicacin. Sin embargo, cuando se aaden
restricciones nuevas, es difcil cambiar los programas para hacerlos cumplir.
El problema se complica an ms cuando las restricciones implican varios
elementos de informacin de distintos archivos.
Estas dificultades, entre otras, han fomentado el desarrollo de sistemas de gestin de bases
de datos.

Captulo 2
Definicin de bases de datos (BD)

Un sistema de bases de datos es un sistema computarizado para llevar registros. Es un sistema

computarizado cuya finalidad general es almacenar informacin y permitir a los usuarios
recuperar y actualizar esa informacin basada en peticiones.

La informacin en cuestin puede ser cualquier cosa que sea de importancia para el individuo
u organizacin.

Estrictamente hablando, existe una diferencia entre datos e informacin:

DATOS. - Lo que en realidad se almacena en la base de datos.

INFORMACION. - Significado de esos datos para los usuarios.

Sin embargo, algunos autores los consideran sinnimos por simplicidad. Un sistema de bases
de datos tiene cuatro componentes principales:

-Datos
-Hardware
-Software
- Usuarios

DATOS

Los sistemas de BD estn disponibles en mquinas que van desde las PC ms pequeas hasta
las mainframes ms grandes.

Los sistemas que se encuentran en mquinas grandes (sistemas grandes) tienden a ser
multiusuario. Los sistemas que se ejecutan en mquinas pequeas (sistemas pequeos)
tienden a ser monousuario.

MONOUSUARIO. - Solo un usuario tiene acceso a la base de datos en un momento dado.

MULTIUSUARIO. - Mltiples usuarios tienen acceso simultneo a la base de datos.

Un sistema multiusuario debe permitir que cada usuario se comporte como si estuviera
trabajando en un sistema de un solo usuario. En general los datos de las BD (por lo menos
en un sistema grande) sern tanto integrados como compartidos.

Por integrados queremos decir que podemos imaginar a la BD como una unificacin
de varios archivos que de otro modo serian distintos, con una redundancia entre ellos
eliminada al menos parcialmente.
 Por compartidos queremos decir que las piezas individuales de datos en la BD
pueden ser compartidas entre diferentes usuarios y que cada uno de ellos puede
tener accesos a la misma pieza de datos probablemente con fines diferentes.

HARDWARE

Los componentes del hardware del sistema constan de:

Los volmenes de almacenamiento secundario (discos) que se emplean para contener

los datos almacenados, junto con los dispositivos asociados, controladores de
dispositivos, canales de E/S, etc.
Los procesadores de hardware y la memoria principal asociada para apoyar la
ejecucin del software del sistema de base de datos.

SOFTWARE

Entre la Base de Datos fsica (es decir, los datos almacenados fsicamente) y los usuarios del
sistema, hay una capa de software conocida con el nombre de administrador de base de datos
o servidor de Base de Datos o Sistema de Administracin de Base de datos (DBMS Data
Base Management System-).

Una funcin general que ofrece el DBMS consiste en ocultar a los usuarios de la Base de
Datos los detalles al nivel de Hardware (en forma muy parecida de a como los sistemas de
lenguaje de programacin oculta a los programadores de aplicaciones los detalles a nivel de
Hardware).

Todas las solicitudes de accesos a la BD son manejadas por el DBMS como agregar, eliminar,
recuperar y almacenar desde y en dichos archivos. El DBMS es por mucho el componente
ms importante de software en el sistema en general, aunque no es el nico. Otros
componentes comprenden las utileras, herramientas de desarrollo de aplicaciones, ayuda de
diseo, generadores de informes y el ms importante el administrador de transacciones.

USUARIOS

Hay 3 grandes clases de usuarios (que en cierto modo se traslapan):

1. Programadores de aplicaciones.
Son los responsables de escribir los programas de BD en algn lenguaje de programacin
como Visual, C++, Java o algn lenguaje de alto nivel. Estos programas acceden a la BD
emitiendo la solicitud apropiada al DBMS. Los programas en si pueden ser aplicaciones
convencionales por lotes o pueden ser aplicaciones en lnea, cuyo propsito es permitir al
usuario final el acceso a la BD desde una Estacin de Trabajo o Terminal en lnea.

2. Usuarios finales.
Son quienes interactan con el sistema desde estaciones de trabajo o terminales en lnea. Un
usuario final puede acceder a la base de datos a travs de las aplicaciones en lnea o mediante
una interfaz proporcionada como parte integral del software del sistema de base de datos. La
interfaz puede ser mediante mens, formularios o mediante comandos.

3. Administrador de base de datos (DBA).

Encargado de la administracin de la base de datos (permisos, usuarios, seguridad, etc.).

Algunas definiciones de Bases de Datos (de diferentes autores)

MARTIN, 1975
Es una coleccin de datos interrelacionados, almacenados en un conjunto sin redundancias
perjudiciales o innecesarias, su finalidad es servir a una o ms aplicaciones de la mejor forma
posible; los datos se almacenan de modo que resulten independientes de los programas que
lo usen, se emplean mtodos bien determinados para incluir nuevos datos y para modificar o
extraer los datos almacenados.

FLORY, 1982
Conjunto de datos de la empresa memorizados en un ordenador, que es utilizado por
numerosas personas y cuya organizacin est regida por un modelo de datos.

HOWE, 1983
Coleccin no redundante de datos que son compartidos por diferentes programas de
aplicacin.

ADMIGUEL, 1993
Coleccin de datos integrados con redundancia controlada y con una estructura que refleje
las interrelaciones y restricciones existentes en el mundo real; los datos que han de ser
compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de
estas, y su definicin y descripcin, nicas para cada tipo de datos, han de estar almacenadas
junto con los mismos datos, los procedimientos de actualizacin y recuperacin comunes y
bien determinados habrn de ser capaces de conservar la integridad, seguridad y
confidencialidad del conjunto de los datos.

DEEN, 1985
Coleccin integrada y generalizada de datos, estructurada atendiendo a las relaciones
naturales de modo que suministren todos los caminos de acceso necesarios, a cada unidad de
datos con el objeto de poder atender todas las necesidades de los diferentes usuarios.

REBECCA RIORDAN
La palabra BD puede ser usada para describir cualquier cosa desde un simple conjunto de
datos, como una lista de telfono hasta un complejo juego de herramientas como SQL y todo
lo que existe entre el.

C.J.DATE
Una BD es un conjunto de datos persistentes que es utilizado por los sistemas de aplicacin
de alguna empresa dada.
Funciones del Gestor de Base de Datos (SGBD)

Generalmente, las bases de datos requieren una gran cantidad de espacio de almacenamiento.
Puesto que la memoria principal de las computadoras no puede almacenar esta informacin,
se almacena en discos. Los datos se transfieren entre el almacenamiento en disco y la
memoria principal segn se necesiten. Ya que el movimiento de los datos y del disco es lento
comparado con la velocidad de la unidad central de procesamiento, es imperativo que el
sistema de la base de datos estructure los datos de forma que minimice la necesidad de mover
los datos entre el disco y la memoria principal.

El objetivo de un sistema de bases de datos es simplificar y facilitar el acceso a los datos. Las
vistas de alto nivel ayudan a lograrlo. No se debera cargar innecesariamente a los usuarios
del sistema con los detalles fsicos de la implementacin del sistema. Sin embargo, un factor
importante para la satisfaccin o insatisfaccin del usuario con un sistema de bases de datos
es su funcionamiento. Si el tiempo de respuesta para una solicitud es demasiado largo, el
valor del sistema se reduce. El funcionamiento de un sistema depende de la eficiencia de las
estructuras de datos usadas para representar los datos en la base de datos y de la capacidad
de eficiencia de operar sobre esas estructuras de datos que el sistema tiene. Como es el caso
de muchos otros aspectos de sistemas informticos, se debe llegar a un compromiso no slo
entre espacio y tiempo sino tambin entre la eficiencia de un tipo de operacin y la de otro.

Un gestor de base de datos es un mdulo de programas que proporciona el interfaz entre los
datos de bajo nivel almacenados en la base de datos y los programas de aplicacin y consultas
hechos al sistema. El gestor de base de datos es responsable de las siguientes tareas: (mas
informacin en las pginas 21 y 22 de libro de texto).

Interaccin con el gestor de archivos.

o Los datos sin procesar se almacenan en el disco usando el sistema de archivos
que normalmente es proporcionado por un sistema operativo convencional. El
gestor de base de datos traduce las distintas sentencias DML, a comandos del
sistema de archivos de bajo nivel. As, el gestor de base de datos es
responsable del verdadero almacenamiento, recuperacin y actualizacin de
los datos en la base de datos.
Implantacin de la integridad.
o Los valores de los datos que se almacenan en la base de datos deben satisfacer
ciertos tipos de restricciones de consistencia. Por ejemplo, el nmero de horas
que un empleado puede trabajar en una semana no puede exceder un lmite
especfico. El administrador de la base de datos debe especificar
explcitamente estas restricciones. El gestor de la base de datos entonces pude
determinar si las actualizaciones a la base de datos dan como resultado la
violacin de la restriccin; si as es, se debe tomar la accin apropiada.
Implantacin de la seguridad.
o Como se discuti anteriormente, no todos los usuarios de la base de datos
necesitas tener acceso a todo su contenido. Es trabajo del gestor de la base de
datos hacer que se cumplan estos requisitos de seguridad.
Copia de seguridad y recuperacin.
 o Un sistema informtico, como cualquier otro dispositivo mecnico o elctrico,
est sujeto a fallos. Las causas de los fallos incluyen rotura de disco,
problemas del suministro de energa y errores software. En cada uno de estos
casos, se pierde la informacin referente a la base de datos. Es responsabilidad
del gestor de la base de datos detectar tales fallos y restaurar la base de datos
al estado que exista antes de ocurrir el fallo. Esto se lleva a cabo normalmente
a travs de la iniciacin de varios procedimientos de copias de seguridad y
recuperacin.
Control de concurrencia.
o Cuando varios usuarios actualizan la base de datos concurrentemente, es
posible que no se conserve la consistencia de los datos. Controlar la
interaccin entre los usuarios concurrentes es otra responsabilidad del gestor
de la base de datos.

Los sistemas de bases de datos diseados para utilizarse en computadoras personales

pequeos, Access, pueden no tener todas las caractersticas apuntadas arriba. Por ejemplo;

Muchas bases de datos pequeas, imponen la restriccin de que slo se permita

acceder a la base de datos a un usuario en cada momento.
Otros dejan las tareas de copia de seguridad, recuperacin e implantacin de la
seguridad al usuario.
Aunque este enfoque de bajo coste y bajas caractersticas es suficiente para bases de
datos personales pequeas, no es adecuado para cumplir las necesidades de una
empresa de media a gran escala.

Captulo 4
Arquitectura del SGBD

El objetivo principal de la arquitectura ANSI/SPARC (American National Standard Institute

- Standards Planning and Requirements Committee) es definir un SGBD (Sistema de Gestin
de Bases de Datos) con el mximo grado de independencia, separando las aplicaciones de
usuario y la base de datos fsica.

De acuerdo con la arquitectura ANSI/SPARC, deba haber tres niveles de esquemas (tres
niveles de abstraccin). La idea bsica de ANSI/SPARC consista en descomponer el nivel
lgico en dos: el nivel externo y el nivel conceptual. Denominbamos nivel interno lo que
aqu hemos denominado nivel fsico

El esquema de la BD es un elemento fundamental de la arquitectura de un SGBD que permite

independizar el SGBD de la BD; de este modo, se puede cambiar el diseo de la BD (su
esquema) sin tener que hacer ningn cambio en el SGBD.

El nivel lgico nos oculta los detalles de cmo se almacenan los datos, cmo se mantienen y
cmo se accede fsicamente a ellos. En este nivel slo se habla de entidades, atributos y reglas
de integridad.
Por cuestiones de rendimiento, nos podr interesar describir elementos de nivel fsico como,
por ejemplo, qu ndices tendremos y qu caractersticas presentarn, cmo y dnde (en qu
espacio fsico) queremos que se agrupen fsicamente los registros, de qu tamao deben ser
las pginas, etc.

El esquema interno (Fsico) es el ms cercano a la mquina. Es una representacin a

bajo nivel de la BD en la que se define la forma en la que los datos se almacenan
fsicamente. Se definen caractersticas como los dispositivos en donde se almacenan
los datos, el espacio que se reserva, las estrategias de acceso, la creacin de ficheros
de ndices, etc. Es dependiente de la mquina en que se vaya a instalar la BD, del
sistema operativo que exista, etc.
El esquema conceptual (Lgico) tiene un esquema conceptual, que describe la
estructura de los datos que van a ser almacenados en la base de datos. El esquema
conceptual esconde los detalles del almacenamiento fsico y se concentra en describir
entidades, tipos de datos, relaciones, operaciones de usuario y restricciones.
El esquema externo o nivel de vista incluye varios esquemas externos o vistas de
usuario. Cada esquema externo describe la parte de la base de datos en la que est
interesado un grupo de usuarios en particular y esconde el resto de la base de datos
para esos usuarios. La informacin se manipula sin saber cmo est almacenada
internamente (nivel interno) ni su organizacin (nivel conceptual).

Existirn muchas vistas externas distintas, cada una formada por una representacin ms o
menos abstracta (registros y campos lgicos) de alguna parte de la base de datos total, y
existir slo una vista conceptual formada por una representacin igualmente abstracta de la
base de datos en su totalidad (hay que recordar que a la mayora de los usuarios no les
interesar toda la base de datos, sino slo una porcin limitada de ella). De manera similar,
habr slo una vista interna, la cual representar a toda la base de datos tal como est
almacenada fsicamente.

Esquema Externo

El nivel externo es el ms cercano a los usuarios, es decir, es el que se ocupa de la forma en

la que los usuarios perciben los datos. El nivel externo es del usuario individual. Estos
usuarios pueden ser o bien programadores de aplicaciones o usuarios finales con
conocimientos muy variables de informtica. El administrador de la base de datos es un caso
especial (tambin debe interesarse por los dems niveles de la arquitectura). Cada usuario
dispone de un lenguaje:

En el caso del programador de aplicaciones, dicho lenguaje ser o bien un lenguaje

de programacin convencional, o bien un lenguaje de cuarta generacin (4GL)
especfico para el sistema en cuestin.
Para el usuario final ser o bien un lenguaje de consulta, o algn lenguaje de
aplicacin especial, quiz manejado mediante formas o mens, adaptado a los
requerimientos de ese usuario y apoyado por algn programa de aplicacin en lnea
(cuya funcin es servir a un usuario final que tiene acceso a la base de datos desde
una terminal en lnea).
El aspecto importante de todos estos lenguajes es que deben incluir un sub-lenguaje de datos,
es decir, un subconjunto del lenguaje total que se ocupe de manera especfica de los objetos
y operaciones de la base de datos. Se dice que el sub-lenguaje de datos (DSL data sub-
language) est embebido (o inmerso) dentro del lenguaje anfitrin correspondiente. Este
ltimo se encarga de varios aspectos no relacionados con la base de datos, como por ejemplo
variables locales (temporales), operaciones de clculo, lgica condicional, etc. Un sistema
dado puede permitir el empleo de varios lenguajes anfitriones y varios sub-lenguajes de
datos. Un sub-lenguaje de datos en particular cuyo uso es posible en casi todos los sistemas
relacionales actuales es el lenguaje SQL.

En principio, cualquier sub-lenguaje de datos es en realidad una combinacin de por lo menos

dos lenguajes subordinados: un lenguaje de definicin de datos (DDL data definition
language), con el cual es posible definir o declarar los objetos de la base de datos, y un
lenguaje de manipulacin de datos (DML, data manipulation language) con el que es
posible manipular o procesar dichos objetos.

Como ya se ha dicho, al usuario individual (en general), slo le interesar una porcin de la
base de datos total; por lo tanto, la forma como ese usuario percibe dicha porcin casi siempre
ser un tanto abstracta comparada con el almacenamiento fsico de los datos. El trmino
ANSI/SPARC para la vista individual de un usuario es vista externa. As, una vista externa
es el contenido de la base de datos tal como lo percibe algn usuario determinado (es decir,
para ese usuario la vista externa es la base de datos). Por ejemplo, un usuario del
departamento de personal podra contemplar la base de datos como un conjunto de
ocurrencias de registros de departamento unido a un conjunto de ocurrencias de registros de
proveedor y de parte vistas por los usuarios del departamento de compras).

Toda vista externa se define mediante un esquema externo, que consiste bsicamente en
definiciones de cada uno de los diversos tipos de registros externos en esa vista externa. El
esquema externo se escribe con la porcin DDL del sub-lenguaje de datos del usuario (por
ello se le denomina a ese DDL en ocasiones como DDL externo). Por ejemplo, el tipo de
registro externo de empleado puede definirse como un campo de nmero de empleado de seis
caracteres unido a un campo de salario de cinco dgitos, etc. Adems, debe haber una
definicin de la correspondencia entre el esquema externo y el esquema conceptual
subyacente.

Esquema Conceptual

El nivel conceptual es un nivel de mediacin entre el nivel interno y externo. La vista

conceptual es una representacin de toda la informacin contenida en la base de datos,
tambin (como en el caso de una vista externa) en una forma un tanto abstracta si se compara
con el almacenamiento fsico de los datos.

Adems, puede ser muy diferente de la forma como percibe los datos cualquier usuario
individual. A grandes rasgos, la vista conceptual debe ser un panorama de los datos tal como
son, y no como por fuerza los perciben los usuarios debido a las limitaciones del lenguaje o
el equipo especficos utilizados, por ejemplo: La vista conceptual se compone de varias
ocurrencias de varios tipos de registro conceptual. Por ejemplo, puede estar formada por un
conjunto de ocurrencias de registros de departamento unido a un conjunto de ocurrencias de
registro de empleado y a un conjunto de ocurrencias de registros de proveedor y a un conjunto
de ocurrencia de registros de parte... Un registro conceptual no es por necesidad idntico a
un registro externo, por un lado, ni a un registro almacenado, por el otro.

La vista conceptual se define mediante un esquema conceptual, el cual incluye definiciones

de cada uno de los tipos de registro conceptual. El esquema conceptual se escribe utilizando
otro lenguaje de definicin de datos, el DDL conceptual. Si ha de lograrse la independencia
de los datos, esas definiciones en DDL conceptual no debern implicar consideraciones de
estructura de almacenamiento o de tcnica de acceso. Si el esquema conceptual se hace en
verdad independiente de los datos de esta manera, entonces los esquemas externos, definidos
en trminos del esquema conceptual, sern por fuerza tambin independientes de los datos.
As pues, la vista conceptual es una vista del contenido total de la base de datos, y el esquema
conceptual es una definicin de esa vista. No obstante, sera engaoso sugerir que el esquema
conceptual es slo un conjunto de definiciones similar a las sencillas definiciones de registros
encontradas por ejemplo en un programa en Cobol. Es de esperar que las definiciones en el
esquema conceptual incluyan muchas caractersticas ms, como son las verificaciones de
seguridad y de integridad. Algunos expertos podran llegar a sugerir que el objetivo
primordial del esquema conceptual es describir la empresa en su totalidad (no slo los datos
en s, sino tambin la forma como se utilizan: cmo fluyen de un punto a otro dentro de la
empresa, qu se hace con ellos en cada punto, qu controles de auditora o de otro tipo deben
aplicarse en cada punto, etc.

Debe hacerse hincapi en que en ningn sistema actual es posible mantener realmente un
nivel conceptual que se aproxime siquiera a ese grado de complejidad; en casi todos los
sistemas existentes el esquema conceptual no es mucho ms que una simple unin de todos
los esquemas externos individuales, con la posible adicin de algunas verificaciones sencillas
de integridad y seguridad. Con todo, parece evidente que los sistemas del futuro llegarn a
mantener niveles conceptuales mucho ms complejos.

Esquema Interno

El tercer nivel de la arquitectura es el nivel interno. La vista interna es una representacin de

bajo nivel de toda la base de datos; se compone de varias ocurrencias de varios tipos de
registro interno. Este ltimo trmino es el que utiliza ANSI/SPARC para referirse a la
construccin que hemos estado llamando registro almacenado. La vista interna, por tanto,
todava est a un paso del nivel fsico, ya que no maneja registros fsicos (llamados tambin
pginas o bloques), ni otras consideraciones especficas de los dispositivos como son los
tamaos de cilindros o de pistas. La vista interna se define mediante el esquema interno, el
cual no slo define los diversos tipos de registros almacenados sino tambin especifica que
ndices hay, cmo se representan los campos almacenados, en qu secuencia fsica se
encuentran los registros almacenados, etc. El esquema interno se escribe con otro lenguaje
ms de definicin de datos, el DDL interno.

En algunas situaciones excepcionales podra permitirse a los programas de aplicacin operar

directamente en el nivel interno en vez de hacerlo en el nivel externo. Esta prctica no es
recomendable ya que representa un riesgo para la seguridad (ya que pasan por alto las
verificaciones de seguridad) y para la integridad (hace lo mismo), y el programa ser en
extremo dependiente de los datos; sin embargo, en ciertos casos puede ser la nica forma de
obtener la funcin o desempeo deseados, del mismo modo como el usuario de un lenguaje
de programacin de alto nivel puede verse obligado en ocasiones a descender al lenguaje
ensamblador para satisfacer ciertos objetivos.

Captulo 5
ARQUITECTURAS DE SISTEMAS DE BASES DE DATOS

No debe confundirse el SGBD con la arquitectura que se elige para implantarlo. Algunos
SGBD slo se pueden implantar en una de las arquitecturas y otros en todas ellas.

ARQUITECTURA CENTRALIZADA

Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un nico sistema
informtico sin interaccionar con ninguna otra computadora.

Estos sistemas eran sistema totalmente centralizados, porque utilizaban los S.O. de aquella poca,
as como el hardware para el que estaban hechos, una gran computadora para toda la empresa y
una red de terminales sin inteligencia ni memoria, llamadas mquinas tontas, que son
computadoras de menores caractersticas puesto que se conectan a la estacin de trabajo, y no son
capaces de procesamiento independiente.

ARQUITECTURA CLIENTE-SERVIDOR

Un sistema de bases de datos puede ser visto como un sistema que tiene una estructura muy
sencilla de dos partes, las cuales consisten en un servidor (tambin llamado parte dorsal o
servicios de fondo) y un conjunto de clientes (tambin llamados partes frontales, aplicaciones
para el usuario o interfaces). El servidor es precisamente el propio DBMS. Soporta todas las
funciones del DBMS (definicin de datos, manipulacin de datos, seguridad e integridad de
los datos, etc.) en particular, proporciona todo el soporte de los niveles externo, conceptual e
interno. Por lo tanto, en este contexto, servidor es solo el nombre del DBMS.

Los clientes son las diversas aplicaciones que se ejecutan sobre el DBMS, tanto aplicaciones
escritas por el usuario (en algn lenguaje de programacin) como aplicaciones integradas (es
decir, aplicaciones herramientas- proporcionadas por el fabricante del DBMS o por alguna
otra compaa). Por supuesto, en lo que concierne al servidor, no hay diferencia entre las
aplicaciones escritas por el usuario y las integradas. Todas usan la misma interfaz con el
servidor.

SISTEMA DE BASES DE DATOS DISTRIBUIDAS

El soporte total a la base de datos distribuida implica que una sola aplicacin debe ser capaz
de operar de manera transparente sobre los datos que estn dispersos a travs de una
variedad de bases de datos diferentes, las cuales son administradas por una variedad de DBMs
distintos, operan en varias mquinas distintas, son manejadas por varios sistemas operativos
diferentes y estn conectadas por una variedad de redes de comunicacin distintas; aqu, de
manera transparente significa que la aplicacin opera desde un punto de vista lgico como
si los datos fueran manejados por un solo DBMS y en una sola mquina.

Captulo 6
Modelos de Datos Clsicos

Datos y Modelos de datos

Datos se deriva del vocablo latn Dar; por lo tanto, los datos son en realidad Hechos
dados a partir de los cuales es posible inferir hechos adicionales (Esto lo hace el SGBD
cuando responde a una consulta del usuario). Una base de datos es en realidad una coleccin
de tales proposiciones verdaderas.

Un modelo de datos es una definicin lgica, independiente y abstracta de los objetos,

operadores y dems que en conjunto constituyen la mquina abstracta con la que interactan
los usuarios. Los objetos nos permiten modelar la estructura de los datos. Los operadores nos
permiten modelar su comportamiento. Un modelo de datos es aquello que los usuarios tienen
que conocer. La implementacin de determinado modelo de datos es una realizacin fsica,
en una maquina real, de los componentes de la maquina abstracta que en conjunto constituyen
ese modelo. La implementacin es lo que los usuarios no tienen que conocer.

Modelos Clsicos

Un modelo de bases de datos es un conjunto de ideas lgicas utilizadas para representar la

estructura de datos y las relaciones entre ellos dentro de la base de datos. Estos modelos se
pueden agrupar de la siguiente manera:

Modelos Conceptuales:

Modelo Entidad Relacin

Modelo Orientado a Objetos

Modelos de Ejecucin:

Modelo de base de datos jerrquico

Modelo de base de datos de red
Modelo de base de datos relacional
Modelo de base de datos orientado a objetos

Los modelos conceptuales se enfocan en la naturaleza lgica de la representacin de los

datos. Por consiguiente, este modelo est comprometido con lo que est representado en la
base de datos y no en cmo est representado. Los modelos de ejecucin hacen nfasis en
como los datos estn representados en la base de datos o en cmo se ejecutan las estructuras
de datos para representar lo que est modelado.

Los modelos conceptuales utilizan 3 tipos de relaciones para describir asociaciones entre los
datos: uno a muchos, muchos a muchos y uno a uno. Ejemplos:

Relacin UNO A MUCHOS: Un pintor pinta varios cuadros diferentes, pero cada uno de
ellos es pintado nicamente por l.
Relacin MUCHOS A MUCHOS. Un empleado podra aprender varias especialidades de
trabajo y cada una podran aprenderla muchos empleados.
Relacin UNO A UNO. Una compaa necesita que cada una de sus tiendas sea administrada
por solamente un empleado, y a su vez, un empleado puede administrar solo una tienda.

Modelo de base de datos Jerrquico

stas son bases de datos que, como su nombre indica, almacenan su informacin en una
estructura jerrquica. En este modelo los datos se organizan en una forma similar a un rbol
(visto al revs), en donde un nodo padre de informacin puede tener varios hijos . El nodo
que no tiene padres es llamado raz, y a los nodos que no tienen hijos se los conoce como
hojas.

Las bases de datos jerrquicas son especialmente tiles en el caso de aplicaciones que
manejan un gran volumen de informacin y datos muy compartidos permitiendo crear
estructuras estables y de gran rendimiento.

La principal ventaja que presenta este tipo de base de datos es la rapidez en las consultas de
informacin ya que la propia estructura piramidal de los datos permite un rpido acceso a
ella.

La computadora no ve la estructura de rbol lgica como la ven los humanos. En su lugar,

ve el rbol que est definido por una ruta que rastrea los segmentos padres hacia los
segmentos hijos, comenzando por la izquierda. Esta estructura ordenada de segmentos que
traza la estructura jerrquica se llama ruta jerrquica.

Aunque las bases jerrquicas y sus aplicaciones an existen, este modelo cay en desuso a
finales de los 70 y principio de los 80 por varias razones:

Ejecucin-compleja
Difcil-de-administrar
Carencia-de-independencia-estructural
Complejidad-de-la-programacin-y-uso-de-las-aplicaciones
Limitaciones-de-ejecucin
Falta de estndares

El modelo jerrquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios)
del modelo relacional. Pero a diferencia de ste ltimo, las relaciones son unidireccionales.
En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de
un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre),
pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde
los nodos hoja hacia el nodo raz. La consulta en el sentido contrario requiere una bsqueda
secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los
empleados de un departamento). En las bases de datos jerrquicas no existen ndices que
faciliten esta tarea

Una de las principales limitaciones de este modelo es su incapacidad de representar

eficientemente la redundancia de datos. De la misma manera, otra limitacin es, no garantiza
la inexistencia de registros duplicados. Esto tambin es cierto para los campos clave. Es
decir, no se garantiza que dos registros cualesquiera tengan diferentes valores

En los aos 70, los profesionales de las bases de datos convocaron a una serie de reuniones
que culminaron con la publicacin de un conjunto de estndares de bases de datos que a
condujeron al desarrollo de modelos alternos. El ms notable es el modelo de base de datos
de red.

Modelo de Base de datos de Red

El modelo de base de datos de red fue creado para representar relaciones de datos complejas
ms eficientes de lo que el modelo jerrquico poda, para mejorar el desempeo de las bases
de datos y para imponer un estndar de base de datos.

En muchos aspectos el modelo de bases de datos de red se parece al modelo jerrquico. Por
ejemplo, as como en el modelo jerrquico, el usuario percibe la base de datos de red como
un conjunto de relaciones uno a muchas. Sin embargo, a diferencia del modelo jerrquico, el
de red permite que un registro tenga ms de un padre.

Aunque el modelo de bases de datos de red ofreci ventajas importantes comparadas con el
modelo jerrquico, an estaba sujeto a desventajas significativas:

Complejidad del sistema.

Falta de independencia estructural

Debido a sus desventajas, fue reemplazado en gran medida por el modelo relacional en los
aos 80.

Modelo de Bases de Datos Relacional

El modelo de bases de datos relacional fue desarrollado por Edgar Frank Codd (padre del
modelo de bases de datos relacional) de IBM en 1970. Represent un gran avance. Su
simplicidad conceptual prepar el camino para una genuina revolucin en el campo de las
bases de datos.
En 1970 el trabajo de Codd fue considerado ingenioso pero poco prctico. La simplicidad
del modelo relacional se consigui a expensas de computadoras ms costosas; las
computadoras carecan de poder para ejecutar el modelo relacional. Por fortuna el poder de
las computadoras creci exponencialmente a la par de la eficiencia de los sistemas operativos.
Es ms, el costo de las computadoras disminuy rpidamente, pese a que su poder iba
creciendo. Actualmente, incluso las microcomputadoras que cuestan una fraccin de lo que
costaban sus antecesoras mainframe, pueden ejecutar software de bases de datos relacional
tan complejo como el Informix, Oracle, Ingress, DB y otros tipos de software relacional para
computadoras mainframe.

El modelo de bases de datos relacional se ejecuta mediante un sistema de administracin de

base de datos relacional (RDBMS Relational DataBase Management System-) muy
complejo. El RDBMS realiza las mismas funciones bsicas de los DBMS jerrquico y de red,
pero adems, realiza otras funciones ms que hacen que el modelo relacional se mas fcil de
entender y ejecutar.

La ventaja ms importante del RDBMS es que permite que el usuario y el diseador operen
en un ambiente lgico humano. El RDBMS maneja todos los detalles fsicos complejos. De
este modo la base de datos relacional es percibida por el usuario como un conjunto de tablas
en las que se guardan datos. Cada tabla es una matriz compuesta por una serie de
intersecciones de filas y columnas. Las tablas tambin llamadas relaciones estn relacionadas
entre s porque comparten una caracterstica de entidad comn.

Una tabla relacional guarda un conjunto de entidades relacionadas. Al respecto, la tabla de

base de datos relacional se parece a un archivo. Pero hay una diferencia crucial entre una
tabla y un archivo: una tabla produce una independencia de los datos y de la estructura
completa, porque es una estructura puramente lgica. La manera en que los datos estn
fsicamente guardados en la base de datos no interesa al usuario ni al diseador, la percepcin
es lo que cuenta en este caso. Y esta propiedad del modelo de bases de datos relacional, se
convirti en el detonador de una verdadera revolucin en el campo de las bases de datos.

Modelo de Base de Datos Orientada a Objetos

El modelo de base de datos orientada a objetos est basado en por lo menos los siguientes
componentes:

Los objetos del modelo de datos son abstracciones de entidades o eventos del mundo real.
Los atributos describen las propiedades de un objeto; por ejemplo, un objeto PERSONA
incluye los atributos nombre, nmero de seguro social y fecha de nacimiento.
Los objetos que comparten caractersticas similares se agrupan en clases. Una clase es un
conjunto de objetos similares con estructura (atributos) y comportamiento (mtodos)
compartidos.
Las clases se organizan en una jerarqua de clase, que se parece a un rbol invertido donde
cada clase tiene solo un padre.
La herencia es la capacidad de un objeto dentro de la jerarqua de clase de heredar los
atributos y mtodos de las clases que estn sobre l.
A pesar del impresionante poder del modelo de datos orientado a objetos, no ha podido ganar
la batalla contra el modelo de base de datos relacional. Existen muchas razones, entre ellas:

Carencia de estndares (especialmente en el mtodo de acceso a datos).

Acceso navegacional a los datos complejos parecido al modelo jerrquico y de red.
Curva de aprendizaje pronunciada.
Transacciones lentas.

Diferencias entre SGBD y SGBDOO

Un Sistema de Gestin de Bases de Datos (SGBD) es un conjunto de datos relacionados entre

s y un grupo de programas para tener acceso a esos datos.

Un Sistema de Gestin de Bases de Datos Orientadas a Objetos (SGBDOO) se puede decir

que es un SGBD que almacena objetos, permitiendo concurrencia, recuperacin. Para los
usuarios tradicionales de bases de datos, esto quiere decir que pueden tratar directamente con
objetos, no teniendo que hacer la traduccin a registros o tablas.

La estructura que podra tener la clase Coche. De esta forma, cada objeto de tipo Coche que
manejemos, ser almacenado automticamente en la base de datos sise declara como objeto
persistente. Vemos que un objeto Coche puede ser, a su vez, un Turismo, un Camin o un
Remolque; un Turismo puede ser Monovolumen o Deportivo. Dependiendo del lenguaje que
se emplee, podremos tener objetos que sean simplemente Turismos sin necesidad de
pertenecer a Monovolumen o a Deportivo, o sea, podemos tener tanto objetos de clases
finales como de clases intermedias.

Modelo Entidad - Relacin

El modelo de datos entidad-relacin (E-R) se basa en una percepcin de un mundo real que
consiste en una coleccin de objetos bsicos llamados entidades, y relaciones entre estos
objetos.

Una entidad es un objeto distinguible de otros por medio de un conjunto de atributos. Por
ejemplo, los atributos nmero y saldo describen una cuenta particular. Una relacin es una
asociacin entre varias entidades. Por ejemplo, una relacin Ctacli asocia a un cliente con
cada cuenta que posee. El conjunto de todas las entidades del mismo tipo y relaciones del
mismo tipo se denomina conjunto de entidades y conjunto de relaciones.

Adems el modelo E-R representa ciertas restricciones a las que deben ajustarse los
contenidos de una BD. Una restriccin importante es la cardinalidad de asignacin, que
expresa el nmero de entidades a las que puede asociarse otra entidad mediante un conjunto
de relacin. La estructura lgica global de una BD puede expresarse grficamente por un
diagrama E-R que consta de :

Rectngulos, que representan conjuntos de entidades.

Elipses, que representan atributos.
 Rombos, que representan relaciones entre conjunto de entidades.
Lneas, que conectan atributos a conjuntos de entidades y conjuntos de entidades a
relaciones.

Cada componente se etiqueta con el nombre de lo que representa.

El modelo Entidad Relacin tiene muchas ventajas:

Simplicidad conceptual
Representacin visual
Es una herramienta de comunicacin efectiva
Est plenamente integrado al modelo de base de datos relacional.

Desventajas del modelo Entidad-Relacin:

Representacin de restricciones limitada. - Algunas restricciones como: La calificacin

promedio de un estudiante oscila entre 0.0 y 10.0 o un piloto no puede ser programado
para ms de 10 horas consecutivas de trabajo no pueden ser representadas. Estas
restricciones deben ser manejadas al nivel de la aplicacin.
Representacin de relaciones limitada. - Las relaciones se representan entre entidades,
pero no entre atributos.
No tiene lenguaje de manipulacin de datos.
Los diagramas pueden resultar confusos en grandes escenarios.

Captulo 7
Tareas del Administrador de Base de Datos DBA

El administrador de la base de datos de una empresa es siempre considerado como la persona

con ms experiencia en el rea de bases de datos. Por lo anterior, es conveniente tener muy claras las
expectativas que se generan en torno a su trabajo y cules son los principales roles que debe asumir dentro del
marco corporativo o de un proyecto.

Definir el esquema conceptual Es trabajo del administrador decidir exactamente qu

informacin contendr la base de datos. Por lo regular a este proceso se le conoce
como diseo lgico de la base de datos.
Definir el esquema interno El administrador tambin debe decidir la forma en que
van a ser representados los datos en la base de datos almacenada. A este proceso se
le conoce comnmente como diseo fsico de la base de datos. Una vez realizado el
diseo fsico, el administrador deber crear la definicin de la estructura de
almacenamiento correspondiente utilizando el DDL interno.
Establecer un enlace con los usuarios El administrador debe enlazarse con los
usuarios para asegurar que los datos necesarios estn disponibles y para escribir los
esquemas externos necesarios, utilizando el DDL externo aplicable.
 Definir las restricciones de seguridad y de integridad Las restricciones de
seguridad y de integridad pueden ser vistas como parte del esquema conceptual. El
DDL conceptual debe incluir facilidades para especificar dichas restricciones.
Definir las polticas de vaciado y recarga Una vez que una empresa se compromete
con un sistema de base de datos, se vuelve drsticamente dependiente del
funcionamiento exitoso de dicho sistema. En el caso de que se produzca un dao en
cualquier parte de la base de datos ocasionado por un error humano o por una falla en
el hardware o en el sistema operativo resulta esencial poder reparar los datos
afectados con el mnimo de demora y con tan poco efecto como sea posible sobre el
resto del sistema.
Supervisar el rendimiento y responder a los requerimientos cambiantes El
administrador es el responsable de organizar el sistema de tal manera que se obtenga
el rendimiento ideal para la empresa y de hacer los ajustes apropiados conforme las
necesidades cambien.

Simbologa Modelo Entidad Relacin

El modelo entidad relacin est formado por esta simbologa:

El modelo Entidad relacin entre sus caractersticas principales son:

Reflejan tan slo la existencia de los datos sin expresar lo que se hace con ellos.

Es independiente de las bases de datos y de los sistemas operativos (por lo que puede
ser desarrollado en cualquier base de datos).

Est abierto a la evolucin del sistema.

Incluye todos los datos que se estudian sin tener en cuenta las aplicaciones que se van
a tratar.
No tienen en cuenta las restricciones de espacio y almacenamiento del sistema.

Entidad
Son objetos concretos o abstractos que presentan inters para el sistema y sobre los que se
recoge informacin que ser representada en un sistema de bases de datos. Por ejemplo,
clientes, proveedores y facturas seran entidades en el entorno de una empresa.

Tambin son entidades otros elementos del mundo real de inters, menos tangibles pero
igualmente diferenciables del resto de objetos; por ejemplo, una asignatura impartida en una
universidad, un prstamo bancario, un pedido de un cliente, etc.

Atributo
Es una unidad bsica e indivisible de informacin acerca de una entidad o una relacin, es
decir, son las propiedades o caractersticas de los objetos que nos interesan. Por ejemplo la
entidad proveedor tendr los atributos nombre, direccin, Nit, telfono.

Otro ejemplo; de una entidad empleado se puede listar; Nit, nombre, apellido, sueldo, fecha
de nacimiento, direccin, telfono.

Nota: El trmino entidad se utiliza tanto para denominar objetos individuales como para hacer
referencia a conjuntos de objetos similares de los que nos interesan los mismos atributos; es
decir, que, por ejemplo, se utiliza para designar tanto a un empleado concreto de una empresa
como al conjunto de todos los empleados de la empresa. Ms concretamente, el trmino
entidad se puede referir a instancias u ocurrencias concretas (empleados concretos) o a tipos
o clases de entidades (el conjunto de todos los empleados).

El modelo ER proporciona una notacin diagramtica para representar grficamente las

entidades y sus atributos:

Las entidades se representan con un rectngulo. El nombre de la entidad se escribe en

maysculas dentro del rectngulo.

Los atributos se representan mediante una elipse y dentro de esta el

nombre en minsculas, esta elipse ir unida al rectngulo de la entidad a la que pertenecen.
Muchas veces, dado que hay muchos atributos para cada entidad, se listan todos aparte del
diagrama para no complicarlo.

Cada uno de los atributos de una entidad toma valores de un cierto dominio o conjunto de
valores (conjunto de valores permitidos para cada atributo). Los valores de los dominios
deben ser atmicos; es decir, no deben poder ser descompuestos. Adems, todos los atributos
tienen que ser univaluados. Un atributo es univaluado cuando solo puede admitir un solo
valor.

Por ejemplo, un atributo univaludo "sueldo" toma valores del dominio de los reales
(decimales) y nicamente toma un valor para cada empleado en especfico; por lo tanto,
ningn empleado puede tener uno o dos valores para el sueldo.

TIPOS DE ATRIBUTOS:

Simples y compuestos
o Simples: No divisibles.
Ejemplo: NOTA
o Compuestos: Formado por varios atributos.
Ejemplo: DIRECCION formado por CALLE, CIUDAD,
DEPARTAMENTO, CODIGO_POSTAL.
Monovaluado y multivaluados
o Monovaluados/Univaluados: Pueden admitir un solo valor.
Ejemplo: NOTA, NOMBRE,TELEFONO
 o Multivaluados: Pueden admitir varios valores.
Ejemplo: TELEFONOS de una persona, COLORES de un vestido (se
ingresan varias datos)
Almacenados y derivados
o Almacenados: Se almacenan como tal.
Ejemplo: NOTA, PAGO_BRUTO, IVA
o Derivados: Se calculan de informacin ya existente.
Ejemplo: PAGO_NETO (se calcula como
PAGO_BRUTO+PAGO_BRUTO * IVA)
Opcional y obligatorio
o opcional: Puede no tener valor (admite NULL).
Ejemplo: ALTURA_EMPLEADO
o Obligatorio: Debe tener un valor (ser NOT NULL).
Ejemplo: NIT

Claves o Llaves
Candidatas y Primarias
Es el atributo de una entidad que no se repite y distingue a otros elementos de uno en
especfico.

Entidad Empleado con atributos (dpi, nombres, apellidos, direccin, telfono, nit,
fecha_nacimiento)

La entidad empleado tiene una clave que consta del atributo dpi porque todos los empleados
tienen un cdigo nico de identificacin ( Cui ) que lo hace diferente o distinguible hacia los
dems. Esta sera una llave Candidata.

Tambin una determinada entidad puede tener ms de una clave; es decir, puede tener varias
claves candidatas.

Por ejemplo, la entidad empleado tiene dos claves candidatas, la que est formada por el
atributo dpi y el nit, teniendo en cuenta que el nit tambin ser diferente para cada uno de
los empleados, es otra llave candidata.

El diseador de base de datos elige una clave primaria entre todas las claves candidatas. Es
decir, debe de decidir cul de estas dos debiese ser la llave primaria de la entidad Empleado.
Deber realizar este proceso de anlisis para cada entidad.

Relaciones
Las relaciones se representan en los diagramas del modelo ER mediante un rombo. Junto al
rombo se indica el nombre de la interrelacin con letras maysculas.
Ejemplo; al considerar una entidad empleado y una entidad despacho y supongamos que a
los empleados se les asignan despachos donde trabajar. Entonces hay una relacin entre la
entidad empleado y la entidad despacho.

Esta relacin, a veces se le denomina asignacin, asocia a los empleados con los despachos
donde trabajan.

Tipos de Relaciones o Cardinalidad de asignacin

Expresan el nmero de entidades a las que puede asociarse otra entidad mediante un conjunto
relacin. Las cardinalidades de asignacin se describen nicamente para conjuntos binarios
de relaciones. Segn los valores normales de la cardinalidad mxima de la entidad puede
haber tres tipos de interrelaciones binarias:

Las cardinalidades de asignacin son las siguientes:

De 1:1 o uno a uno:

A cada elemento de la primera entidad le corresponde slo uno de la segunda entidad, y a la

inversa. Por ejemplo, un cliente de un hotel ocupa una habitacin y cada habitacin es
ocupada por un cliente titular; o por ejemplo, cada curso de alumnos tiene un nico tutor, y
ese tutor es nicamente tutor de ese curso.

De 1:N o uno a muchos:

A cada elemento de la primera entidad le corresponde uno o ms elementos de la segunda

entidad, y a cada elemento de la segunda entidad le corresponde uno slo de la primera
entidad. Por ejemplo, un mismo proveedor suministra varios artculos a una empresa, y cada
artculo que adquiere la empresa siempre es pedido al mismo proveedor.

De N:M o muchos a muchos:

A cada elemento de la primera entidad le corresponde uno o ms elementos de la segunda

entidad, y a cada elemento de la segunda entidad le corresponde
uno o ms elementos de la primera entidad. Por ejemplo, cada vendedor de una tienda vende
muchos artculos y cada artculo es vendido por varios vendedores.

Antes de Empezar a Disear

El diseo de una base de datos no es un proceso sencillo. Habitualmente, la complejidad de

la informacin y la cantidad de requisitos de los sistemas de informacin hacen que sea
complicado. Por este motivo, cuando se disean bases de datos se deben de considerar
factores bsicos, as como proponer un diseo que acepte cambios hacia futuro.

Para disear una base de datos se realizar por medio del Modelo Entidad Relacin. ( ER )
El modelo ER es uno de los enfoques de modelizacin de datos que ms se utiliza actualmente
por su simplicidad y legibilidad. Su legibilidad se ve favorecida porque proporciona una
notacin diagramtica muy comprensiva. Es una herramienta til tanto para ayudar al
diseador a reflejar en un modelo conceptual los requisitos del mundo real de inters como
para comunicarse con el usuario final sobre el modelo conceptual obtenido y, de este modo,
poder verificar si satisface sus requisitos.

El modelo ER resulta fcil de aprender y de utilizar en la mayora de las aplicaciones.

Adems, existen herramientas informticas de ayuda al diseo (herramientas CASE) que
utilizan alguna variante del modelo ER para hacer el diseo de los datos.

El nombre completo del modelo ER es entity-relationship, y proviene del hecho de que los
principales elementos que incluye son las entidades y las interrelaciones (entities y
relationships).

El origen del modelo ER se encuentra en trabajos efectuados por Peter Chen en 1976.
Posteriormente, muchos otros autores han descrito variantes y/o extensiones de este modelo.
As pues, en la literatura se encuentran muchas formas diferentes del modelo ER que pueden
variar simplemente en la notacin diagramtica o en algunos de los conceptos en que se basan
para modelizar los datos.

Cuando se quiere utilizar el modelo ER para comunicarse con el usuario, es recomendable

emplear una variante del modelo que incluya slo sus elementos ms simples como los seran
entidades, atributos e interrelaciones.

Segn la nocin de modelo de datos que hemos utilizado en los otros mdulos, un modelo
de datos tiene en cuenta tres aspectos de los datos: la estructura, la manipulacin y la
integridad. Sin embargo, el modelo ER habitualmente se utiliza para reflejar aspectos de la
estructura de los datos y de su integridad, pero no de su manipulacin.