Introduccin

Todas las empresas requieren almacenar informacin. Desde siempre lo han

hecho. La
informacin puede ser de todo tipo. Cada elemento informativo (nombre,
direccin, sueldo, etc.) es lo que se conoce como dato (en ingls data).
Las soluciones utilizadas por las empresas para almacenar los datos son
diversas.
Antes de la aparicin de la informtica se almacenaban en ficheros con
cajones, carpetas y fichas. Tras la aparicin de la informtica estos datos se
almacenan en archivos digitales dentro de las unidades de almacenamiento del
ordenador (a veces en archivos binarios, o en hojas de clculo,...).
Adems, las empresas requieren utilizar aplicaciones informticas para realizar
tareas propias de la empresa a fin de mecanizar a las mismas. Estas
aplicaciones requieren manejar los datos de la empresa.
En los inicios de la era informtica, cada programa almacenaba y utilizaba sus
propios datos de forma un tanto catica. La ventaja de este sistema (la nica
ventaja), es que los procesos eran independientes por lo que la modificacin de
uno no afectaba al resto. Pero tiene grandes inconvenientes:
o
o
o
o

Costo de almacenamiento elevado

Datos redundantes (se repiten continuamente)
Probabilidad alta de inconsistencia en los datos
Difcil modificacin en los datos y facilidad de problemas de
inconsistencia al realizar esas modificaciones (ya que es difcil que esa
modificacin afecte a todos los datos)

Lgicamente la solucin a este problema es hacer que todas las aplicaciones

utilicen los mismos datos. Esto provoca que los datos deban estar mucho ms
protegidos y controlados. Adems los datos forman una estructura fsica y
funcional que es lo que se conoce como base de datos.
De esta forma una base de datos es una serie de datos relacionados que
forman una estructura lgica, es decir una estructura reconocible desde un
programa informtico. Esa estructura no slo contiene los datos en s, sino la
forma en la que se relacionan. Las bases de datos empiezan a aparecer en los
aos 60 y triunfan en los aos setenta y ochenta.

Sistema de bases de datos

Un sistema de bases de datos sirve para integrar los datos. Lo componen los
siguientes elementos:
Hardware. Mquinas en las que se almacenan las bases de datos. Incorporan
unidades del almacenamiento masivo para este fin.
1

Software. Es el sistema gestor de bases de datos. El encargado de

administrar las bases de datos.
Datos. Incluyen los datos que se necesitan almacenar y los metadatos que
son datos que sirven para describir lo que se almacena en la base de datos.
Usuarios. Personas que manipulan los datos del sistema. Hay tres
categoras:
Usuarios finales. Aquellos que utilizan datos de la base de datos para
su trabajo cotidiano que no tiene por qu tener que ver con la informtica.
Normalmente no utilizan la base de datos directamente, si no que utilizan
aplicaciones creadas para ellos a fin de facilitar la manipulacin de los datos.
Estos usuarios slo acceden a ciertos datos.
Desarrolladores. Analistas y programadores encargados de generar
aplicaciones para los usuarios finales.
Administradores. Tambin llamados DBA (Data Base Administrator), se
encargan de gestionar las bases de datos.
Hay que tener en cuenta que las necesidades de los usuarios son muy
diferentes en funcin del tipo de usuario que sean: a los finales les interesa la
facilidad de uso, a los desarrolladores la potencia y flexibilidad de los lenguajes
incorporados del sistema de bases de datos, a los administradores
herramientas de gestin avanzada para la base de datos.

Sistema gestor de bases de datos

Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar ms a
menudo las siglas DBMS procedentes del ingls, Data Base Management
System) es el software que permite a los usuarios procesar, describir,
administrar y recuperar los datos almacenados
en una base de datos.

Modelos de datos
Un modelo de datos es una serie de conceptos que puede utilizarse para
describir un conjunto de datos y las operaciones para manipularlos. Hay dos
tipos de modelos de datos: los modelos conceptuales y los modelos lgicos. Los
modelos conceptuales se utilizan para representar la realidad a un alto nivel de
abstraccin. Mediante los modelos conceptuales se puede construir una
descripcin de la realidad fcil de entender. En los modelos lgicos, las
descripciones de los datos tienen una correspondencia sencilla con la
estructura fsica de la base de datos.
Los modelos se utilizan en todo tipo de ciencias. Su finalidad es la de simbolizar
una parte del mundo real de forma que sea ms fcilmente manipulable. En
definitiva es un esquema mental (conceptual) en el que se intentan reproducir
las caractersticas de una realidad especfica.
En el caso de los modelos de datos, lo que intentan reproducir es una
informacin real que deseamos almacenar en un sistema informtico. Se
denomina esquema a una descripcin especfica en trminos de un modelo de
datos. El conjunto de datos representados por el esquema forma la base de
datos.

Como se ve aparecen varios esquemas intermedios. Los que estn ms a la

izquierda se alejan ms de las caractersticas fsicas. Los elementos de ese
esquema son:
o

Mundo real. Contiene la informacin tal cual la percibimos como seres

humanos. Es el punto de partida

o
o
o
o

Esquema conceptual. Representa el modelo de datos de forma

independiente del DBMS que se utilizar.
Esquema cannico (o de base de datos). Representa los datos en un
formato ms cercano al del ordenador
Esquema interno. Representa los datos segn el modelo concreto de un
sistema gestor de bases de datos (por ejemplo Oracle)
Base de datos fsica. Los datos tal cual son almacenados en disco.

Algunos ejemplos de modelos conceptuales son:

Modelo E/R
Modelo RM/T
Modelos semntico

Ejemplos de modelos lgicos son:

Modelo relacional
Codasyl
Jerrquico

Modelo entidad relacin

El modelo entidad-relacin es el modelo conceptual ms utilizado para el
diseo conceptual de bases de datos. Fue introducido por Peter Chen en
1976. El modelo entidad-relacin est formado por un conjunto de
conceptos que permiten describir la realidad mediante un conjunto de
representaciones grficas y lingsticas.
Originalmente, el modelo entidad-relacin slo inclua los conceptos de
entidad, relacin y atributo. Ms tarde, se aadieron otros conceptos,
como los atributos compuestos y las jerarquas de generalizacin, en lo
que se ha denominado modelo entidad-relacin extendido.

Entidad
Cualquier tipo de objeto o concepto sobre el que se recoge informacin:
cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas,
empleados, clientes, empresas, oficios, diseos de productos, conciertos,
excursiones, etc. Las entidades se representan grficamente mediante
rectngulos y su nombre aparece en el interior. Un nombre de entidad
slo puede aparecer una vez en el esquema conceptual.
Las entidades que poseen las mismas propiedades forman conjuntos de
entidades. Ejemplos de conjuntos de entidades son los conjuntos: personas,
facturas, coches,...

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido

como conjunto de entidades. De este modo hablaramos de la entidad
PERSONAS. Mientras que cada persona en concreto sera una ocurrencia o un
ejemplar de la entidad persona.
Las entidades se representan grficamente mediante rectngulos y su nombre
aparece en el interior. Un nombre de entidad slo puede aparecer una vez en el
esquema conceptual.

Hay dos tipos de entidades: fuertes y dbiles. Una entidad dbil es una
entidad cuya existencia depende de la existencia de otra entidad. Una
entidad fuerte es una entidad que no es dbil.
Por ejemplo la entidad tarea laboral slo podr tener existencia si existe la
entidad trabajo. Las entidades dbiles se presentan de esta forma:

Relaciones
Representan asociaciones entre entidades. Es el elemento del modelo que
permite relacionar en s los datos del modelo. Por ejemplo, en el caso de que
tengamos una entidad
personas y otra entidad trabajos. Ambas se realizan ya que las personas
trabajan y los trabajos son realizados por personas:

La representacin grfica de las entidades se realiza con un rombo al que se le

unen lneas
que se dirigen a las entidades, las relaciones tienen nombre (se suele usar un
verbo). En el
ejemplo anterior podra usarse como nombre de relacin, trabajar:

Una relacin recursiva es una relacin donde la misma entidad participa

ms de una vez en la relacin con distintos papeles. El nombre de estos
papeles es importante para determinar la funcin de cada participacin.
La cardinalidad con la que una entidad participa en una relacin
especifica el nmero mnimo y el nmero mximo de correspondencias
en las que puede tomar parte cada ocurrencia de dicha entidad. La
participacin de una entidad en una relacin es obligatoria (total) si la
existencia de cada una de sus ocurrencias requiere la existencia de, al
menos, una ocurrencia de la otra entidad participante. Si no, la
participacin es opcional (parcial). Las reglas que definen la cardinalidad
de las relaciones son las reglas de negocio.

Atributo
Es una caracterstica de inters o un hecho sobre una entidad o sobre
una relacin. Los atributos representan las propiedades bsicas de las
entidades y de las relaciones. Toda la informacin extensiva es portada
por los atributos. Grficamente, se representan mediante elipses que
cuelgan de las entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado
dominio. El dominio define todos los valores posibles que puede tomar
un atributo. Puede haber varios atributos definidos sobre un mismo
dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es
un atributo que tiene un solo componente, que no se puede dividir en
partes ms pequeas que tengan un significado propio. Un atributo
compuesto es un atributo con varios componentes, cada uno con un
significado por s mismo. Un grupo de atributos se representa mediante
un atributo compuesto cuando tienen afinidad en cuanto a su
8

significado, o en cuanto a su uso. Un atributo compuesto se representa

grficamente mediante un valo.
Los atributos tambin pueden clasificarse en monovalentes o
polivalentes. Un atributo monovalente es aquel que tiene un solo valor
para cada ocurrencia de la entidad o relacin a la que pertenece. Un
atributo polivalente es aquel que tiene varios valores para cada
ocurrencia de la entidad o relacin a la que pertenece. A estos atributos
tambin se les denomina multivaluados, y pueden tener un nmero
mximo y un nmero mnimo de valores.
La cardinalidad de un atributo indica el nmero mnimo y el nmero
mximo de valores que puede tomar para cada ocurrencia de la entidad
o relacin a la que pertenece. El valor por omisin es

Por ltimo, los atributos pueden ser derivados. Un atributo derivado es

aquel que representa un valor que se puede obtener a partir del valor de
uno o varios atributos, que no necesariamente deben pertenecer a la
misma entidad o relacin.

Cardinalidad
Indica el nmero de relaciones en las que una entidad puede aparecer. Se
anota en
trminos de:
o cardinalidad mnima. Indica el nmero mnimo de asociaciones en las
que aparecer cada ejemplar de la entidad (el valor que se anota es de
cero o uno)
o cardinalidad mxima. Indica el nmero mximo de relaciones en las
que puede aparecer cada ejemplar de la entidad (puede ser uno o
muchos)
En los esquemas entidad / relacin la cardinalidad se puede indicar de muchas
formas.
Actualmente una de las ms populares es como se muestra en la siguiente
figura.

En el ejemplo, cada equipo cuanta con varios jugadores. un jugador juega

como mucho en un equipo y podra no jugar en ninguno. Cada entrenador
entrena a un equipo (podra no entrenar a ninguno), el cual tiene un solo
entrenador
A veces en las lneas de la relacin se indican roles. Los roles representan el
papel que juega una entidad en una determinada relacin. Ejemplo:

10

Describen propiedades de las entidades y las relaciones. En este modelo se

representan con un crculo, dentro del cual se coloca el nombre del atributo.

Ejemplo:

11

Metodologa de diseo conceptual

El primer paso en el diseo de una base de datos es la produccin del
esquema conceptual. Normalmente, se construyen varios esquemas
conceptuales, cada uno para representar las distintas visiones que los
usuarios tienen de la informacin. Cada una de estas visiones suelen
corresponder a las diferentes reas funcionales de la empresa como, por
ejemplo, produccin, ventas, recursos humanos, etc.
Estas visiones de la informacin, denominadas vistas, se pueden
identificar de varias formas. Una opcin consiste en examinar los
diagramas de flujo de datos, que se pueden haber producido
previamente, para identificar cada una de las reas funcionales. La otra
opcin consiste en entrevistar a los usuarios, examinar los
procedimientos, los informes y los formularios, y tambin observar el
funcionamiento de la empresa.
A los esquemas conceptuales correspondientes a cada vista de usuario
se les denomina esquemas conceptuales locales. Cada uno de estos
esquemas se compone de entidades, relaciones, atributos, dominios de
atributos e identificadores. El esquema conceptual tambin tendr una
documentacin, que se ir produciendo durante su desarrollo. Las tareas
a realizar en el diseo conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
12

4. Determinar los dominios de los atributos.

5. Determinar los identificadores.
6. Determinar las jerarquas de generalizacin (si las hay).
7. Dibujar el diagrama entidad-relacin.
8. Revisar el esquema conceptual local con el usuario.
1. Identificar las entidades
En primer lugar hay que definir los principales objetos que interesan al
usuario. Estos objetos sern las entidades. Una forma de identificar las
entidades es examinar las especificaciones de requisitos de usuario. En
estas especificaciones se buscan los nombres o los sintagmas nominales
que se mencionan (por ejemplo: nmero de empleado, nombre de
empleado, nmero de inmueble, direccin del inmueble, alquiler,
nmero de habitaciones). Tambin se buscan objetos importantes como
personas, lugares o conceptos de inters, excluyendo aquellos nombres
que slo son propiedades de otros objetos. Por ejemplo, se pueden
agrupar el nmero de empleado y el nombre de empleado en una
entidad denominada empleado, y agrupar nmero de inmueble,
direccin del inmueble, alquiler y nmero de habitaciones en otra
entidad denominada inmueble.
Otra forma de identificar las entidades es buscar aquellos objetos que
existen por s mismos. Por ejemplo, empleado es una entidad porque los
empleados existen, sepamos o no sus nombres, direcciones y telfonos.
Siempre que sea posible, el usuario debe colaborar en la identificacin
de las entidades.
A veces, es difcil identificar las entidades por la forma en que aparecen
en las especificaciones de requisitos. Los usuarios, a veces, hablan
utilizando ejemplos o analogas. En lugar de hablar de empleados en
general, hablan de personas concretas, o bien, hablan de los puestos
que ocupan esas personas.
Para liarlo an ms, los usuarios usan, muchas veces, sinnimos y
homnimos. Dos palabras son sinnimos cuando tienen el mismo
significado. Los homnimos ocurren cuando la misma palabra puede
tener distintos significados dependiendo del contexto.
No siempre es obvio saber si un objeto es una entidad, una relacin o un
atributo. Por ejemplo cmo se podra clasificar matrimonio? Pues de
cualquiera de las tres formas. El anlisis es subjetivo, por lo que distintos
13

diseadores pueden hacer distintas interpretaciones, aunque todas

igualmente vlidas. Todo depende de la opinin y la experiencia de cada
uno. Los diseadores de bases de datos deben tener una visin selectiva
y clasificar las cosas que observan dentro del contexto de la empresa u
organizacin. A partir de unas especificaciones de usuario es posible que
no se pueda deducir un conjunto nico de entidades, pero despus de
varias iteraciones del proceso de anlisis, se llegar a obtener un
conjunto de entidades que sean adecuadas para el sistema que se ha de
construir.
Conforme se van identificando las entidades, se les dan nombres que
tengan un significado y que sean obvias para el usuario. Los nombres de
las entidades y sus descripciones se anotan en el diccionario de datos.
Cuando sea posible, se debe anotar tambin el nmero aproximado de
ocurrencias de cada entidad. Si una entidad se conoce por varios
nombres, stos se deben anotar en el diccionario de datos como alias o
sinnimos.
2. Identificar las relaciones
Una vez definidas las entidades, se deben definir las relaciones
existentes entre ellas. Del mismo modo que para identificar las
entidades se buscaban nombres en las especificaciones de requisitos,
para identificar las relaciones se suelen buscar las expresiones verbales
(por ejemplo: oficina tiene empleados, empleado gestiona inmueble,
cliente visita inmueble). Si las especificaciones de requisitos reflejan
estas relaciones es porque son importantes para la empresa y, por lo
tanto, se deben reflejar en el esquema conceptual.
Pero slo interesan las relaciones que son necesarias. En el ejemplo
anterior, se han identificado las relaciones empleado gestiona inmueble
y cliente visita inmueble. Se podra pensar en incluir una relacin entre
empleado y cliente: empleado atiende a cliente, pero observando las
especificaciones de requisitos no parece que haya inters en modelar tal
relacin.
La mayora de las relaciones son binarias (entre dos entidades), pero no
hay que olvidar que tambin puede haber relaciones en las que
participen ms de dos entidades, as como relaciones recursivas.
Es muy importante repasar las especificaciones para comprobar que
todas las relaciones, explcitas o implcitas, se han encontrado. Si se
tienen pocas entidades, se puede comprobar por parejas si hay alguna
relacin entre ellas. De todos modos, las relaciones que no se identifican
ahora se suelen encontrar cuando se valida el esquema con las
transacciones que debe soportar.
14

Una vez identificadas todas las relaciones, hay que determinar la

cardinalidad mnima y mxima con la que participa cada entidad en
cada una de ellas. De este modo, el esquema representa de un modo
ms explcito la semntica de las relaciones. La cardinalidad es un tipo
de restriccin que se utiliza para comprobar y mantener la calidad de los
datos. Estas restricciones son aserciones sobre las entidades que se
pueden aplicar cuando se actualiza la base de datos para determinar si
las actualizaciones violan o no las reglas establecidas sobre la semntica
de los datos.
Conforme se van identificando las relaciones, se les van asignando
nombres que tengan significado para el usuario. En el diccionario de
datos se anotan los nombres de las relaciones, su descripcin y las
cardinalidades con las que participan las entidades en ellas.
3. Identificar los atributos y asociarlos a entidades y relaciones
Al igual que con las entidades, se buscan nombres en las
especificaciones de requisitos. Son atributos los nombres que identifican
propiedades, cualidades, identificadores o caractersticas de entidades o
relaciones.
Lo ms sencillo es preguntarse, para cada entidad y cada relacin, qu
informacin se quiere saber de ...? La respuesta a esta pregunta se debe
encontrar en las especificaciones de requisitos. Pero, en ocasiones, ser
necesario preguntar a los usuarios para que aclaren los requisitos.
Desgraciadamente, los usuarios pueden dar respuestas a esta pregunta
que tambin contengan otros conceptos, por lo que hay que considerar
sus respuestas con mucho cuidado.
Al identificar los atributos, hay que tener en cuenta si son simples o
compuestos. Por ejemplo, el atributo direccin puede ser simple,
teniendo la direccin completa como un solo valor: `San Rafael 45,
Almazora'; o puede ser un atributo compuesto, formado por la calle
(`San Rafael'), el nmero (`45') y la poblacin (`Almazora'). El escoger
entre atributo simple o compuesto depende de los requisitos del usuario.
Si el usuario no necesita acceder a cada uno de los componentes de la
direccin por separado, se puede representar como un atributo simple.
Pero si el usuario quiere acceder a los componentes de forma individual,
entonces se debe representar como un atributo compuesto.
Tambin se deben identificar los atributos derivados o calculados, que
son aquellos cuyo valor se puede calcular a partir de los valores de otros
atributos. Por ejemplo, el nmero de empleados de cada oficina, la edad
de los empleados o el nmero de inmuebles que gestiona cada
empleado. Algunos diseadores no representan los atributos derivados
15

en los esquemas conceptuales. Si se hace, se debe indicar claramente

que el atributo es derivado y a partir de qu atributos se obtiene su
valor. Donde hay que considerar los atributos derivados es en el diseo
fsico.
Cuando se estn identificando los atributos, se puede descubrir alguna
entidad que no se ha identificado previamente, por lo que hay que
volver al principio introduciendo esta entidad y viendo si se relaciona
con otras entidades.
Es muy til elaborar una lista de atributos e ir eliminndolos de la lista
conforme se vayan asociando a una entidad o relacin. De este modo,
uno se puede asegurar de que cada atributo se asocia a una sola
entidad o relacin, y que cuando la lista se ha acabado, se han asociado
todos los atributos.
Hay que tener mucho cuidado cuando parece que un mismo atributo se
debe asociar a varias entidades. Esto puede ser por una de las
siguientes causas:

Se han identificado varias entidades, como director, supervisor y

administrativo, cuando, de hecho, pueden representarse como una
sola entidad denominada empleado. En este caso, se puede
escoger entre introducir una jerarqua de generalizacin, o dejar
las entidades que representan cada uno de los puestos de
empleado.

Se ha identificado una relacin entre entidades. En este caso, se

debe asociar el atributo a una sola de las entidades y hay que
asegurarse de que la relacin ya se haba identificado
previamente. Si no es as, se debe actualizar la documentacin
para recoger la nueva relacin.

Conforme se van identificando los atributos, se les asignan nombres que

tengan significado para el usuario. De cada atributo se debe anotar la
siguiente informacin:

Nombre y descripcin del atributo.

Alias o sinnimos por los que se conoce al atributo.

Tipo de dato y longitud.

Valores por defecto del atributo (si se especifican).

16

Si el atributo siempre va a tener un valor (si admite o no nulos).

Si el atributo es compuesto y, en su caso, qu atributos simples lo

forman.

Si el atributo es derivado y, en su caso, cmo se calcula su valor.

Si el atributo es multievaluado.

4. Determinar los dominios de los atributos

El dominio de un atributo es el conjunto de valores que puede tomar el
atributo. Por ejemplo el dominio de los nmeros de oficina son las tiras
de hasta tres caracteres en donde el primero es una letra y el siguiente
o los dos siguientes son dgitos en el rango de 1 a 99; el dominio de los
nmeros de telfono y los nmeros de fax son las tiras de 9 dgitos.
Un esquema conceptual est completo si incluye los dominios de cada
atributo: los valores permitidos para cada atributo, su tamao y su
formato. Tambin se puede incluir informacin adicional sobre los
dominios como, por ejemplo, las operaciones que se pueden realizar
sobre cada atributo, qu atributos pueden compararse entre s o qu
atributos pueden combinarse con otros. Aunque sera muy interesante
que el sistema final respetara todas estas indicaciones sobre los
dominios, esto es todava una lnea abierta de investigacin.
Toda la informacin sobre los dominios se debe anotar tambin en el
diccionario de datos.
5. Determinar los identificadores
Cada entidad tiene al menos un identificador. En este paso, se trata de
encontrar todos los identificadores de cada una de las entidades. Los
identificadores pueden ser simples o compuestos. De cada entidad se
escoger uno de los identificadores como clave primaria en la fase del
diseo lgico.
Cuando se determinan los identificadores es fcil darse cuenta de si una
entidad es fuerte o dbil. Si una entidad tiene al menos un identificador,
es fuerte (otras denominaciones son padre, propietaria o dominante). Si
una entidad no tiene atributos que le sirvan de identificador, es dbil
(otras denominaciones son hijo, dependiente o subordinada).
Todos los identificadores de las entidades se deben anotar en el
diccionario de datos.
17

6. Determinar las jerarquas de generalizacin

En este paso hay que observar las entidades que se han identificado
hasta el momento. Hay que ver si es necesario reflejar las diferencias
entre distintas ocurrencias de una entidad, con lo que surgirn nuevas
subentidades de esta entidad genrica; o bien, si hay entidades que
tienen caractersticas en comn y que realmente son subentidades de
una nueva entidad genrica.
En cada jerarqua hay que determinar si es total o parcial y exclusiva o
superpuesta.
7. Dibujar el diagrama entidad-relacin
Una vez identificados todos los conceptos, se puede dibujar el diagrama
entidad-relacin correspondiente a una de las vistas de los usuarios. Se
obtiene as un esquema conceptual local.
8. Revisar el esquema conceptual local con el usuario
Antes de dar por finalizada la fase del diseo conceptual, se debe revisar
el esquema conceptual local con el usuario. Este esquema est formado
por el diagrama entidad-relacin y toda la documentacin que describe
el esquema. Si se encuentra alguna anomala, hay que corregirla
haciendo los cambios oportunos, por lo que posiblemente haya que
repetir alguno de los pasos anteriores. Este proceso debe repetirse hasta
que se est seguro de que el esquema conceptual es una fiel
representacin de la parte de la empresa que se est tratando de
modelar.

http

18