Modelo entidad-relacin

Un diagrama o modelo entidad-relacin (a veces denominado por su siglas,

E-R "Entity relationship") es una herramienta para el modelado de datos de un
sistema de informacin. Estos modelos expresan entidades relevantes para un
sistema de informacin, sus interrelaciones y propiedades.

Cuando se utiliza una base de datos para gestionar informacin, se est

plasmando una parte del mundo real en una serie de tablas, registros y campos
ubicados en un ordenador; crendose un modelo parcial de la realidad. Antes
de crear fsicamente estas tablas en el ordenador se debe realizar un modelo
de datos.

Se suele cometer el error de ir creando nuevas tablas a medida que se van

necesitando, haciendo as el modelo de datos y la construccin fsica de las
tablas simultneamente. El resultado de esto acaba siendo un sistema de
informacin parcheado, con datos dispersos que terminan por no cumplir
adecuadamente los requisitos necesarios.

Modelado Entidad-Relacin
El Modelo Entidad-Relacin es un concepto de modelado para bases de
datos, propuesto por Peter Chen en 1976, mediante el cual se pretende
'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se
corresponde al concepto de objeto de la Programacin Orientada a Objetos) las
cuales tienen unos atributos y se vinculan mediante relaciones.

Es una representacin conceptual de la informacin. Mediante una serie de

procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el
modelo relacional.

El modelado entidad-relacin es una tcnica para el modelado de datos

utilizando diagramas entidad relacin. No es la nica tcnica pero s la
ms utilizada. Brevemente consiste en los siguientes pasos:

1. Se parte de una descripcin textual del problema o sistema de

informacin a automatizar (los requisitos).

2. Se hace una lista de los sustantivos y verbos que aparecen.

3. Los sustantivos son posibles entidades o atributos.

4. Los verbos son posibles relaciones.

5. Analizando las frases se determina la cardinalidad de las relaciones y

otros detalles.

6. Se elabora el diagrama (o diagramas) entidad-relacin.

 7. Se completa el modelo con listas de atributos y una descripcin de otras
restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta tcnica se necesita cierto entrenamiento y

experiencia para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta tcnica. Son necesarias

otras tcnicas para lograr un modelo directamente implementable en una base
de datos. Brevemente:

Transformacin de relaciones mltiples en binarias.

Normalizacin de una base de datos de relaciones (algunas relaciones

pueden transformarse en atributos y viceversa).

Conversin en tablas (en caso de utilizar una base de datos relacional).

Etc.

Base Terica y Conceptual

El modelo entidad-relacin se basa en los conceptos descritos a continuacin
para representar un modelo de la vida real.

Entidad
Representa una cosa u "objeto" del mundo real con existencia independiente,
es decir, se diferencia unvocamente de cualquier otro objeto o cosa, incluso
siendo del mismo tipo.

Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automovil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos
diferentes, por ejemplo el numero de motor).
Una casa (Aunque sea exactamente igual a otra, aun se diferenciara en su direccin).
Una entidad puede ser un objeto con existencia fsica (una persona, un animal,
un casa ...), o un objeto con existencia conceptual (Un puesto de trabajo, una
asignatura de clases, un nombre ...).

Una entidad est descrita y se representa por sus caractersticas o atributos.

Por ejemplo, la entidad Persona puede llevar consigo las caractersticas:
Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc.

Conjunto de entidades (tambin denominado instancia u ocurrencia)

Es una coleccin de entidades que comparten los mismos atributos o
caractersticas.

Ejemplos:

Todos los atletas que participan en los juegos olimpicos, comparten sus atributos: nombre,
numero de identificacin, edad, peso, categoria...
Todos los paises del mundo, comparten las caracteristicas: nombre, continente, area, lengua
principal, lengua secundaria, moneda...
Atributos
Los atributos son las propiedades que describen a cada entidad.

Una entidad dentro de un conjunto de entidades, tiene valores especficos

asignados para cada uno de sus atributos, de esta forma, es posible su
identificacin univoca.

Ejemplos:

A la coleccin de entidades Alumnos, con el siguiente conjunto de atributos en comn, (id,

nombre, edad, semestre), pertenecen las entidades:

(1, Sophie, 18 aos, 2)

(2, Penny, 19 aos, 5)
(3, Sophie, 20 aos, 2)
...
Cada una de las entidades pertenecientes a este conjunto se diferencia de las
dems por el valor de sus atributos. Ntese que dos o mas entidades diferentes
pueden tener los mismos valores para algunos de sus atributos, pero nunca
para todos.

En particular, los atributos identificativos son aquellos que permiten

diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo
identificativo que distingue a un alumno de otro es su nmero de id.

Para cada atributo, existe un dominio del mismo, este hace referencia al tipo
de datos que ser almacenado o a restricciones en los valores que el atributo
puede tomar (Cadenas de caracteres, nmeros, solo dos letras, solo nmeros
mayores que cero, solo nmeros enteros...).

Cuando una entidad no tiene un valor para un atributo dado, este toma el valor
nulo, bien sea que no se conoce, que no existe o que no se sabe nada al
respecto del mismo.

Relacin
Describe cierta dependencia entre entidades o permite la asociacin de las
mismas.

Ejemplo:

Dadas dos instancias de entidades "Habitacin 502" y "Mark", es posible relacionar que la
habitacion 502 se encuentra ocupada por el husped de nombre Mark.
Una relacin tiene sentido al expresar las entidades que relaciona. En el
ejemplo anterior, Un Husped (entidad), se aloja (relacin) en una habitacin
(entidad).

Cardinalidad de las relaciones

Dado un conjunto de relaciones, en el que participan dos o ms entidades, la
cardinalidad indica el nmero de entidades con las que puede estar relacionada
una entidad dada. La cardinalidad puede ser:
 Relacin 1 a 1: Una elemento de A se relaciona nicamente con una
elemento en B y viceversa. (Ej: la entidad HOMBRE, la entidad MUJER
y entre ellos la relacin MATRIMONIO).

Relacin 1 a n: Un elemento en A se relaciona con cero o muchas

elementos en B. Pero un elemento en B se relaciona con un nica
elemento en A. (Ej: la entidad EMPRESA y la entidad TRABAJADOR y
entre ellos la relacin TRABAJA EN).

n a n: Una elemento en A se puede relacionar con 0 o muchas

elementos en B y viceversa. (Ej: la entidad ALUMNO, la entidad
ASIGNATURA y entre ellos la relacin MATRCULA).

Clave
Es un subconjunto del conjunto de atributos comunes en una entidad, que
permite identificar unvocamente cada una de las ocurrencias pertenecientes a
dicha coleccin. As mismo, permiten distinguir entre si las relaciones de un
conjunto de relaciones.

Clave ajena. Cuando una entidad hereda la clave de otra entidad con la que se
relaciona.

Entidades fuertes y dbiles

Cuando una entidad participa en una relacin puede adquirir un papel fuerte o
dbil. Una entidad dbil es aquella que no puede existir sin participar en la
relacin, es decir, aquella que no puede ser unvocamente identificada
solamente por sus atributos. Una entidad fuerte (tambin conocida como
entidad regular) es aquella que s puede ser identificada unvocamente. En los
casos en que se requiera, se puede dar que una entidad fuerte "preste"
algunos de sus atributos a una entidad dbil para que esta ltima se pueda
identificar.

Las entidades dbiles se representan mediante un doble rectngulo, es decir,

un rectngulo con doble lnea.

Diagrama entidad-relacin
Formalmente, los diagramas E-R son un lenguaje grfico para describir
conceptos. Informalmente, son simples dibujos o grficos que describen la
informacin que trata un sistema de informacin y el software que lo
automatiza.
Ejemplo de diagrama E-R

Entidad
Se representa mediante un rectngulo o "caja" etiquetada en su interior
mediante un identificador. Ejemplos de entidades habituales en los sistemas
de informacin son: factura, persona, empleado, etc.

Atributo
Se representan mediante un crculo o elipse etiquetado mediante un nombre en
su interior. Cuando un atributo es identificativo (clave) de la entidad se suele
subrayar dicha etiqueta.

Relaciones
Se representa mediante un rombo etiquetado en su interior con un verbo. Este
rombo se debe unir mediante lneas con las entidades (rectngulos) que
relaciona.

Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la
relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del
lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma
de expresar la cardinalidad es situando un smbolo cerca de la lnea que
conecta una entidad con una relacin:

"0" si la entidad no est obligada a participar en la relacin.

"1" si la entidad est obligada a participar en la relacin y, adems, cada

instancia solamente participa una vez.

"N" , "M", "*" si la entidad no est obligada a participar en la relacin

y cada instancia puede participar cualquier nmero de veces.

Ejemplos de relaciones que expresan cardinalidad:

Una factura (entidad) se emite (relacin) a una persona (entidad) y slo

una, pero una persona puede tener varias facturas emitidas a su
nombre. Es una relacin 1:N.
 Un cliente (entidad) puede comprar (relacin) varios artculos (entidad) y
un artculo puede ser comprado por varios clientes distintos. Es una
relacin N:M.

Atributos en relaciones
Las relaciones tambin pueden tener atributos asociados. Se representan igual
que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo
"histrico" donde debe constar una fecha o una hora. Por ejemplo,
supongamos que es necesario hacer constar la fecha de emisin de una
factura a un cliente, y que es posible emitir duplicados de la factura (con
distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera
colocarse en la relacin "se emite".

Herencia
La herencia es un intento de adaptacin de estos diagramas al paradigma
orientado a objetos. La herencia es un tipo de relacin entre una entidad
"padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y
relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos
veces en el diagrama. La relacin de herencia se representa mediante un
tringulo interconectado por lneas a las entidades. La entidad conectada por el
vrtice superior del tringulo es la entidad "padre". Solamente puede existir una
entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base
del tringulo.

Transformacin del modelo entidad-relacin al modelo relacional.

Para transformar un modelo entidad-relacin a modelo relacional
seguiremos las siguientes reglas:

Para cada entidad del esquema se crear una tabla con tantos campos
como atributos tenga la entidad. Ejemplo:

Tabla 'TRABAJADOR'
DNI NUM_SS nombre-apellidos ...
11111111 XXXXXXXXXXX Fulano de tal ...
22222222 YYYYYYYYYYY Mengano de cual ...
...... ...... ...... ......
Las relaciones 1-1 se pueden reflejar incluyendo en una de las dos tablas un
campo en el que poder colocar la clave del elemento de la otra tabla con el que
se est relacionado. Ese nuevo campo que se incluye en la tabla recibe el
nombre de clave ajena. Ejemplo:

Tabla 'HOMBRE'
DNI Nombre ...
11111111 ... ...
22222222 ... ...
... ... ...
Tabla 'MUJER'
DNI Nombre ... DNI-ESPOSO
33333333 ... ... 11111111
44444444 ... ... (nulo)
... ... ... ...
Donde el campo DNI-ESPOSO es clave ajena de la tabla HOMBRE. Aqu hay
que hacer notar que el campo DNI-ESPOSO puede tomar o bien un valor nulo,
en el caso de aquellas mujeres que no estn casadas, o bien el valor de alguno
de los DNI de la tabla HOMBRE, en el caso de las mujeres casadas; en este
segundo caso, ese DNI (la clave ajena) no se deber repetir en ningn otro
registro de la tabla MUJER.

Las relaciones 1-n se representan de forma muy parecida a como se ha

explicado para las relaciones 1-1. La diferencia est en que ahora no es
indiferente donde se coloque la clave ajena, esta debe estar obligatoriamente
en la tabla del 'mucho' (n); y adems, para este caso si se permitir que haya
valores repetidos en dicho campo. Ejemplo:

Tabla 'EMPRESA'
CIF Nombre ...
XX-1111-AA ... ...
YY-2222-BB ... ...
... ... ...
Tabla 'TRABAJADOR'
DNI Nombre ... CIF
11111111 ... ... XX-1111-AA
22222222 ... ... YY-2222-BB
33333333 ... ... YY-2222-BB
44444444 ... ... XX-1111-AA
... ... ... ...
Para representar las relaciones n-n en tablas lo que se hace es crear una
nueva tabla solamente para la relacin. Esta nueva tabla tendr dos claves
ajenas y su propia clave estar formada por la unin de las claves ajenas.
Ejemplo:

Tabla 'ALUMNO'
DNI Nombre ...
11111111 ... ...
22222222 ... ...
... ... ...
Tabla 'ASIGNATURA'
COD-ASIGNATURA Nombre ...
01 ... ...
02 ... ...
... ... ...
Tabla 'MATRCULA'(esta es la relacin)
DNI COD_ASIGNATURA NOTA
11111111 01 7.5
11111111 02 6.25
22222222 01 5.5
22222222 02 8
... ... ...
En la tabla MATRCULA es donde se refleja la relacin. La clave de dicha
tabla est formada por los campos DNI y COD-ASIGNATURA ; y cada uno de
ellos es clave ajena, el primero de ALUMNO y el segundo de ASIGNATURA.
Hacer ver aqu que la tabla MATRICULAS puede tener ms campos adems
de los que son clave ajena como ocurre en el ejemplo; la tabla aade adems
un campo NOTA.

En el caso de las relaciones reflexivas supondremos que se trata de una

relacin binaria con la particularidad que las dos entidades son iguales y
aplicaremos las reglas vistas en los puntos anteriores.

Ejemplos.
Relaciones N:M
Supongamos el siguiente modelo entidad-relacin.

En este caso la relacin compra se transforma en una nueva tabla cuya clave
primaria estar formada por los atributos dni, que es la clave primaria de
cliente, y cdigo, que es la clave primaria de producto. Adems tendr como
campo fecha compra, ya que este atributo forma parte de la relacin.

El modelo relacional quedara de la siguiente forma (en negrita las claves

primarias):
 CLIENTE(dni,nombre,apellidos)

PRODUCTO(cdigo,descripcin)

COMPRAS(dni_cliente,cdigo_producto,fecha_compra)

Relaciones 1:N
Veamos ahora el caso de una relacin 1:N. En el siguiente modelo entidad-
relacin un empleado pertenece a un nico departamento (debe pertenecer a
uno obligatoriamente), y un departamento tiene 1 o ms empleados.

En este caso se propaga el atributo cdigo de departamento a la tabla

EMPLEADO. El modelo relacional quedara de la siguiente manera:

EMPLEADO(dni,nombre,salario,cdigo_departamento)

DEPARTAMENTO(cdigo,nombre,localizacin)

Relaciones 1:1
Veamos ahora el caso de una relacin 1:1 a travs del siguiente ejemplo. En el
siguiente modelo entidad-relacin un equipo de ftbol tiene a un nico
presidente y un presidente preside a un nico club de ftbol.
En este ejemplo, tal y como dicen las reglas, podemos propagar la clave de
cualquier tabla a la tabla resultante de la otra. Es decir, tenemos dos opciones,
o mover la clave de PRESIDENTE a EQUIPO o mover la clave de EQUIPO a
PRESIDENTE. El modelo relacional podra quedar de cualquiera de las dos
formas siguientes:

EQUIPO(cdigo,nombre,ao_fundacin)

PRESIDENTE(dni,nombre,cdigo_equipo)

EQUIPO(cdigo,nombre,ao_fundacin,dni_presidente)

PRESIDENTE(dni,nombre)

Relaciones reflexivas
Veamos ahora como quedara en el modelo relacional la siguiente relacin
reflexiva. En el siguiente modelo entidad-relacin un ALUMNO es delegado de
varios ALUMNOS y un ALUMNO tiene obligatoriamente un delegado y slo a
uno.
Como podemos observar en las reglas de transformacin, en este caso la
relacin reflexiva se trata como si fuera una relacin binaria con la
particularidad de que las dos entidades son iguales. Al tratarse de una relacin
1:N se propagar la clave de la entidad ALUMNO a la entidad ALUMNO,
quedando el modelo relacional de la siguiente forma:

ALUMNO(num_expediente,nombre,num_expediente_delegado)

Ejemplo de una Universidad (Access)

Creacin de Tablas

Tabla Alumno
En una Universidad, si tenemos la entidad Alumno que definimos como:
Tabla ALUMNO(DNI, Nombre, Apellido1, Apellido2, Telefono, Calle, Ciudad, Provincia,
FNacimiento, EstadoCivil)
CP: DNI
Creando la tabla en vista "Diseo" obtenemos:

Tabla Asignatura
Y la entidad Asignatura definida como:
ASIGNATURA(Codigo, Nombre, Creditos, Dni_prof, Observaciones)
CP:Codigo
Tabla Matricula
Y sabiendo que un alumno se puede matricular de muchas asignaturas y que
una asignatura a su vez puede tener muchos alumnos matriculados, podemos
definir entre ambas entidades la relacin (n-m) matricula como:

MATRICULA(DNI, Codigo_asig, Fecha, Nota)

CP:DNI,Codigo_asig,Fecha
Y la tabla quedara como:

Creacin de Relaciones
Seleccionamos la opcin Relaciones del men Herramientas:

Agregamos las tablas (Alumno,Asignatura y Matricula):

Que son:
Y por ltimo slo falta arrastrar los campos relacionados de la tabla con la
relacin 1 a la tabla con la relacin muchos, es decir crear las relaciones, en las
que seleccionaremos siempre :

Exigir Integridad Referencial

Actualizar en cascada los campos relacionados

Eliminar en cascada los registros relacionados

En el caso de Alumno-Matricula (1 Alumno.DNI se puede repetir n veces en
Matricula.DNI) arrastramos el Alumno.DNI sobre la Matricula.DNI:
Y si repetimos la misma operacin entre Asignatura.Codigo y
Matricula.Codigo_asig queda el esquema E-R en Access segn se muestra en
la figura siguiente:
Normalizacin de bases de datos
Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir
que una base de datos est en la forma normal N es decir que todas sus tablas
estn en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayora de las bases de datos. El creador de estas 3
primeras formas normales (o reglas) fue Edgar F. Codd.[1]

Primera Forma Normal (1FN)

Se dice que una tabla se encuentra en primera forma normal si y solo si cada
uno de los campos contiene un nico valor para un registro determinado.
Segunda Forma Normal (2FN)
Una tabla est en Segunda Forma Normal si y solo si todos los campos
dependen directamente de la clave.
Tercera Forma Normal (3FN)
Se dice que una tabla est en tercera forma normal si y solo si los campos de
la tabla dependen nicamente de la clave.
Ejemplo 1 Normalizacin
A travs del siguiente ejercicio se intenta afirmar los conocimientos de
normalizacin con un ejemplo simplificado de una base de datos para una
pequea biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev

Variable Murray McGraw Prez Gmez,

1001 15/04/2005
compleja Spiegel Hill Juan

Visual Basic E. Ros Tern,

1004 Anaya 17/04/2005
5 Petroustsos Ana

Murray McGraw
1005 Estadstica Roca, Ren 16/04/2005
Spiegel Hill

Nancy
Oracle Oracle Garca Roque,
1006 Greenberg y 20/04/2005
University Corp. Luis
Priya Nathan

McGraw Prez Gmez,

1007 Clipper 5.01 Ramalho 18/04/2005
Hill Juan

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo

tener campos atmicos, pues el nombre del lector es un campo que puede (y
conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal
como se muestra en la siguiente tabla.

1NF

CodLibr Titulo Autor Editoria Patern Matern Nombre FechaDev

o l o o s

Variable Murray McGraw 15/04/200

1001 Prez Gmez Juan
compleja Spiegel Hill 5

1004 Visual E. Anaya Ros Tern Ana 17/04/200

Basic 5 Petroustso 5
CodLibr Titulo Autor Editoria Patern Matern Nombre FechaDev
o l o o s

Estadstic Murray McGraw 16/04/200

1005 Roca Ren
a Spiegel Hill 5

Oracle Nancy Oracle 20/04/200

1006 Garca Roque Luis
University Greenberg Corp. 5

Oracle Priya Oracle 20/04/200

1006 Garca Roque Luis
University Nathan Corp. 5

Clipper McGraw 18/04/200

1007 Ramalho Prez Gmez Juan
5.01 Hill 5

Como se puede ver, hay cierta redundancia caracterstica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales

o dicho de otra manera, todos los atributos no clave deben depender por
completo de la clave primaria. Actualmente en nuestra tabla tenemos varias
dependencias parciales si consideramos como atributo clave el cdigo del libro.

Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero
el nombre del lector en realidad no tiene dependencia de este cdigo, por tanto
estos datos deben ser trasladados a otra tabla.

2NF

CodLibro Titulo Autor Editorial

Variable Murray McGraw

1001
compleja Spiegel Hill

E.
1004 Visual Basic 5 Anaya
Petroustsos

Murray McGraw
1005 Estadstica
Spiegel Hill

1006 Oracle Nancy Oracle

CodLibro Titulo Autor Editorial

University Greenberg Corp.

Oracle Priya Oracle

1006
University Nathan Corp.

McGraw
1007 Clipper 5.01 Ramalho
Hill

La nueva tabla slo contendr datos del lector.

CodLec Pater Mater Nombr

tor no no es

Gme
501 Prez Juan
z

502 Ros Tern Ana

503 Roca Ren

Garc
504 Roque Luis
a

Hemos creado una tabla para contener los datos del lector y tambin tuvimos
que crear la columna CodLector para identificar unvocamente a cada uno. Sin
embargo, esta nueva disposicin de la base de datos necesita que exista otra
tabla para mantener la informacin de qu libros estn prestados a qu
lectores. Esta tabla se muestra a continuacin:

CodLib CodLec FechaD

ro tor ev

1001 501 15/04/2

 CodLib CodLec FechaD
ro tor ev

005

17/04/2
1004 502 005

16/04/2
1005 503 005

20/04/2
1006 504 005

18/04/2
1007 501 005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems
los atributos no clave deben ser mutuamente independientes y dependientes
por completo de la clave primaria. Tambin recordemos que dijimos que esto
significa que las columnas en la tabla deben contener solamente informacin
sobre la entidad definida por la clave primaria y, por tanto, las columnas en la
tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del

libro, los autores y editoriales, por lo que debemos crear nuevas tablas para
satisfacer los requisitos de 3NF.

3NF

CodLibro Titulo

Variable
1001 compleja

Visual Basic
1004 5

1005 Estadstica

1006 Oracle
CodLibro Titulo

University

1007 Clipper 5.01

CodAutor Autor

Murray
801 Spiegel

E.
802 Petroustsos

Nancy
803 Greenberg

Priya
804 Nathan

806 Ramalho

CodEditorial Editorial

McGraw
901 Hill

902 Anaya

Oracle
903 Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo
informacin acerca de una entidad, tambin hemos perdido la informacin
acerca de qu autor ha escrito qu libro y las editoriales correspondientes, por
lo que debemos crear otras tablas que relacionen cada libro con sus autores y
editoriales.
CodLibr codAuto
o r

1001 801

1004 802

1005 801

1006 803

1006 804

1007 806

CodLibr codEditori
o al

1001 901

1004 902

1005 901

1006 903

1007 901

Y el resto de las tablas no necesitan modificacin.

 CodLec Pater Mater Nombr
tor no no es

Prez Gme Juan

501 z

502 Ros Tern Ana

503 Roca Ren

Garc Roque Luis

504 a

CodLibro CodLector FechaDev

1001 501 15/04/2005

1004 502 17/04/2005

1005 503 16/04/2005

1006 504 20/04/2005

1007 501 18/04/2005

Ejemplo 2 Normalizacin
usuarios

nombre empresa direccion_empresa url1 url2

Joe ABC 1 Work Lane abc.com xyz.com

Jill XYZ 1 Job Street abc.com xyz.com

Diramos que la anterior tabla esta en nivel de Formalizacion Cero porque
ninguna de nuestras reglas de normalizacin ha sido aplicada. Observa los
campos url1 y url2 -- Qu haremos cuando en nuestra aplicacin necesitemos
una tercera url ? Quieres tener que aadir otro campo/columna a tu tabla y
tener que reprogramar toda la entrada de datos de tu cdigo PHP ?
Obviamente no, tu quieres crear un sistema funcional que pueda crecer y
adaptarse fcilmente a los nuevos requisitos. Hechemos un vistazo a las reglas
del Primer Nivel de Formalizacin-Normalizacin, y las aplicaremos a nuestra
tabla.

1FN

1. Eliminar los grupos repetitivos de la tablas individuales.

2. Crear una tabla separada por cada grupo de datos relacionados.

3. Identificar cada grupo de datos relacionados con una clave primaria.

Ves que estamos rompiendo la primera regla cuando repetimos los

campos url1 y url2? Y que pasa con la tercera regla, la clave primaria?
La regla tres bsicamente significa que tenemos que poner una campo
tipo contador autoincrementable para cada registro. De otra forma, Qu
pasaria si tuvieramos dos usuarios llamados Joe y queremos
diferenciarlos. Una vez que aplicaramos el primer nivel de F/N nos
encontrariamos con la siguiente tabla:

usuarios

userId nombre empresa direccion_empresa url

1 Joe ABC 1 Work Lane abc.com

1 Joe ABC 1 Work Lane xyz.com

2 Jill XYZ 1 Job Street abc.com

2 Jill XYZ 1 Job Street xyz.com

Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos
solucionado el problema de la limitacin del campo url. Pero sin
embargo vemos otros problemas....Cada vez que introducimos un nuevo
registro en la tabla usuarios, tenemos que duplicar el nombre de la
empresa y del usuario. No slo nuestra BD crecer muchsimo, sino que
 ser muy facil que la BD se corrompa si escribimos mal alguno de los
datos redundantes. Aplicaremos pues el segundo nivel de F/N:

2 FN

1 Crear tablas separadas para aquellos grupos de datos que se aplican a

varios registros.

2 Relacionar estas tablas mediante una clave externa.

Hemos separado el campo url en otra tabla, de forma que podemos

aadir ms en el futuro si tener que duplicar los dems datos. Tambin
vamos a usar nuestra clave primaria para relacionar estos campos:

usuarios

userId nombre empresa direccion_empresa

1 Joe ABC 1 Work Lane

2 Jill XYZ 1 Job Street

urls

urlId relUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Vale, hemos creado tablas separadas y la clave primaria en la tabla

usuarios, userId, esta relacionada ahora con la clave externa en la
tabla urls, relUserId. Esto esta mejor. Pero que ocurre cuando
queremos aadir otro empleado a la empresa ABC ? o 200
empleados ? Ahora tenemos el nombre de la empresa y su direccin
duplicandose, otra situacin que puede inducirnos a introducir errores en
nuestros datos. As que tendrmos que aplicar el tercer nivel de F/N:
3 FN

1 Eliminar aquellos campos que no dependan de la clave.

Nuestro nombre de empresa y su direccin no tienen nada que ver con

el campo userId, asi que tienen que tener su propio empresaId:

usuarios

userId nombre relEmpresaId

1 Joe 1

2 Jill 2

empresas

emprId empresa direccion_empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

urls

urlId RelUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Ahora tenemos la clave primaria emprId en la tabla empresas

relacionada con la clave externa recEmpresaId en la tabla usuarios, y
podemos aadir 200 usuarios mientras que slo tenemos que insertar el
nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer
todo lo que quieran sin duplicacin ni corrupcin de datos. La mayoria de
los desarrolladores dicen que el tercer nivel de F/N es suficiente, que
nuestro esquema de datos puede manejar facilmente los datos
obtenidos de una cualquier empresa en su totalidad, y en la mayoria de
los casos esto ser cierto.

Pero hechemos un vistazo a nuestro campo urls - Ves duplicacin de

datos ? Esto es perfectamente aceptable si la entrada de datos de este
campo es solicitada al usuario en nuestra apliacin para que teclee
libremente su url, y por lo tanto es slo una coincidencia que Joe y Jill
teclearon la misma url. Pero que pasa si en lugar de entrada libre de
texto usramos un men desplegable con 20 o incluso ms urls
predefinidas ? Entonces tendramos que llevar nuestro diseo de BD al
siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por
alto porque depende mucho de un tipo muy especfico de relacin, la
relacin 'varios-con-varios', la cual an no hemos encontrado en nuestra
aplicacin.

Relaciones entre los Datos

Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones
entre los datos: uno-a-uno, uno-con-varios y varios-con-varios. Mira la
tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba. Por un
momento imaginmos que ponemos el campo url en una tabla separada,
y cada vez que introducimos un registro en la tabla usuarios tambien
introducimos una sola fila en la tabla urls. Entonces tendramos una
relacion uno-a-uno: cada fila en la tabla usuarios tendra exactamente
una fila correspondiente en la tabla urls. Para los propsitos de nuestra
aplicacin no sera til la normalizacin.

Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras
tablas permiten a un slo usuario tener asociadas varias urls. Esta es
una relacin uno-con-varios, el tipo de relacin ms comn, y hasta que
se nos present el dilema del Tercer Nivel de F/N. la nica clase de
relacin que necesitamos.

La relacin varios-con-varios, sin embargo, es ligeramente ms

compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que
tenemos a un usuario relacionado con varias urls. Como dijmos, vamos
a cambiar la estructura para permitir que varios usuarios esten
relacionados con varias urls y as tendremos una relacin varios-con-
varios. Veamos como quedaran nuestras tablas antes de seguir con
este planteamiento:

usuarios

userId nombre relEmpresaId

 1 Joe 1

2 Jill 2

empresas

emprId empresa direccion_empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

urls

urlId url

1 abc.com

2 xyz.com

url_relations

relationId relatedUrlId relatedUserId

1 1 1

2 1 2

3 2 1

4 2 2

Base de datos relacional

Una base de datos relacional es una base de datos que cumple con el
modelo relacional, el cual es el modelo ms utilizado en la actualidad para
modelar problemas reales y administrar datos dinmicamente. Tras ser
postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM
en San Jos (California), no tard en consolidarse como un nuevo paradigma
en los modelos de base de datos.[1]
Caractersticas

Una base de datos relacional se compone de varias tablas o

relaciones.

No pueden existir dos tablas con el mismo nombre.

Cada tabla es a su vez un conjunto de registros, filas o tuplas.

Cada registro representa un objeto del mundo real.

Cada una de estos registros consta de varios campos, columnas o

atributos.

No pueden existir dos campos con el mismo nombre en la una misma

tabla.

Los valores almacenados en una columna deben ser del mismo tipo de
dato.

Todas las filas de una misma tabla poseen el mismo nmero de campos.

No se considera el orden en que se almacenan los registros en las

tablas.

No se considera el orden en que se almacenan las tablas en la base de

datos.

La informacin puede ser recuperada o almacenada por medio de

sentencias llamadas consultas.

Elementos
Relaciones base y derivadas
En una base de datos relacional, todos los datos se almacenan y se acceden a
ellos por medio de relaciones. Las relaciones que almacenan datos son
llamados "relaciones base" y su implementacin es llamada "tabla". Otras
relaciones no almacenan datos, pero que son calculadas al aplicar operaciones
relacionales. Estas relaciones son llamadas "relaciones derivadas" y su
implementacin es llamada "vista" o "consulta". Las relaciones derivadas son
convenientes ya que expresan informacin de varias relaciones actuando como
si fuera una sola.

Restricciones
Una restriccin es una condicin que obliga el cumplimiento de ciertas
condiciones en la base de datos. Algunas no son determinadas por los
usuarios, sino que son inherentemente definidas por el simple hecho de que la
base de datos sea relacional. Algunas otras restricciones las puede definir el
usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.
Las restricciones proveen un mtodo de implementar reglas en la base de
datos. Las restricciones restringen los datos que pueden ser almacenados en
las tablas. Usualmente se definen usando expresiones que dan como resultado
un valor booleano, indicando si los datos satisfacen la restriccin o no.

Las restricciones no son parte formal del modelo relacional, pero son incluidas
porque juegan el rol de organizar mejor los datos. Las restricciones son muy
discutidas junto con los conceptos relacionales.

Dominios
Un dominio describe un conjunto de posibles valores para cierto atributo. Como
un dominio restringe los valores del atributo, puede ser considerado como una
restriccin. Matemticamente, atribuir un dominio a un atributo significa "todos
los valores de este atributo deben de ser elementos del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha, etc.

Clave nica
Cada tabla puede tener uno o ms campos cuyos valores identifican de forma
nica cada registro de dicha tabla, es decir, no pueden existir dos o ms
registros diferentes cuyos valores en dichos campos sean idnticos. Este
conjunto de campos se llama clave nica.

Pueden existir varias claves nicas en una determinada tabla, y a cada una de
stas suele llamrsele candidata a clave primaria.

Clave primaria
Una clave primaria es una clave nica elegida entre todas las candidatas, para
especificar los datos que sern relacionados con las dems tablas. La forma de
hacer esto es por medio de claves forneas.

Slo puede existir una clave primaria por tabla y ningn campo de dicha clave
puede contener valores NULL.

Clave fornea
Una clave fornea es una referencia a una clave en otra tabla. Las claves
forneas necesitan no ser claves nicas.

Clave ndice
Las claves ndice surgen con la necesidad de tener un acceso ms rpido a los
datos. Los ndices pueden ser creados con cualquier combinacin de campos
de una tabla. Las consultas que filtran registros por medio de estos campos,
pueden encontrar los registros de forma no secuencial usando la clave ndice.

Las bases de datos relacionales incluyen mltiples tcnicas de ordenamiento,

cada una de ellas es ptima para cierta distribucin de datos y tamao de la
relacin.
Los ndices generalmente no se consideran parte de la base de datos, pues
son un detalle agregado. Sin embargo, las claves ndices son desarrolladas por
el mismo grupo de programadores que las otras partes de la base de datos.

Procedimientos almacenados
Un procedimiento almacenado es cdigo ejecutable que se asocia y se
almacena con la base de datos. Los procedimientos almacenados usualmente
recogen y personalizan operaciones comunes, como insertar un registro dentro
de una tabla, recopilar informacin estadstica, o encapsular clculos
complejos. Son frecuentemente usandos por un API por seguridad o
simplicidad.

Los procedimientos almacenados no son parte del modelo relacional, pero

todas las implementaciones comerciales los incluyen.

Estructura
La base de datos se organiza en dos marcadas secciones; el esquema y los
datos (o instancia).

El esquema es la definicin de la estructura de la base de datos y

principalmente almacena los siguientes datos:

El nombre de cada tabla

El nombre de cada campo

El tipo de dato de cada campo

La tabla a la que pertenece cada campo

Las bases de datos relacionales pasan por un proceso al que se le conoce

como normalizacin, el resultado de dicho proceso es un esquema que permite
que la base de datos sea usada de manera ptima.

Los datos o instancia es el contenido de la base de datos en un momento dado.

Es en si, el contenido de todos los registros.

Manipulacin de la informacin
Para manipular la informacin utilizamos un lenguaje relacional, actualmente se
cuenta con dos lenguajes formales el lgebra relacional y el clculo relacional.
El lgebra relacional permite describir la forma de realizar una consulta, en
cambio, el clculo relacional slo indica lo que se desea devolver.

El lenguaje ms comn para construir las consultas a bases de datos

relacionales es SQL (Structured Query Language), un estndar implementado
por los principales motores o sistemas de gestin de bases de datos
relacionales.

En el modelo relacional los atributos deben estar explcitamente relacionados a

un nombre en todas las operaciones, en cambio, el estndar SQL permite usar
columnas sin nombre en conjuntos de resultados, como el asterisco
taquigrfico (*) como notacin de consultas.

Al contrario del modelo relacional, el estndar SQL requiere que las columnas
tengan un orden definido, lo cual es fcil de implementar en una computadora,
ya que la memoria es lineal.

Es de notar, sin embargo, que en SQL el orden de las columnas y los registros
devueltos en cierto conjunto de resultado nunca est garantizado, a no ser que
explcitamente sea especificado por el usuario.

sin embargo, todo lo dicho es dicho y una base de datos relacional es utilizada
para la formacion de el ingreso de datos de forma sistematizada, "facil", y
ordenada

Manejadores de base de datos relacionales

Existe software exclusivamente dedicado a tratar con bases de datos
relacionales. Este software se conoce como SGBD (Sistema de gestin de
base de datos relacional) o RDBMS (del ingls Relational database
management system).

Entre los gestores o manejadores ms actuales y populares encontramos:

MySQL, PostgreSQL, Oracle y Microsoft SQL Server.

Ventajas y desventajas
Ventajas

Provee herramientas que garantizan evitar la duplicidad de registros.

Garantiza la integridad referencial, as, al eliminar un registro elimina

todos los registros relacionados dependientes.

Favorece la normalizacin por ser ms comprensible y aplicable.

Desventajas

Presentan deficiencias con datos grficos, multimedia, CAD y sistemas

de informacin geogrfica.

No se manipulan de forma manejable los bloques de texto como tipo de

dato.

Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo

de satisfacer las necesidades de las aplicaciones anteriores y as,
complementar pero no sustituir a las bases de datos relacionales.