Diseo conceptual

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

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.

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.

Diseo lgico
1. Diseo lgico de datos
2. Transformacin d modelo conceptual a lgico
3. Anlisis relacional de datos
4. Documentacin

1. Diseo lgico de datos

Hoy en da, prcticamente todos los sistemas de informacin almacenan y
organizan los datos en DDBB. Para llevar a cabo la implementacin de la
DDBB que necesita el sistema habr que tener en cuenta todas las fases de
diseo de esta:
- Diseo conceptual: Este diseo es independiente del modelo de DDBB
usado, del ordenador, del sistema gestor de bases de datos, etc
Simplemente se estudia el problema y se seleccionan los elementos del

mundo real que vamos a modelar. Este diseo es al que corresponde el

diagrama E/R
- Diseo lgico: Partiendo del diseo conceptual obtenido en la fase anterior,
llegamos a un diseo lgico. Transformamos las entidades y relaciones
obtenidas del modelo anterior en tablas. Para ello usamos la normalizacin.
- Diseo fsico: Este diseo si depende del ordenador, del sistema gestor de
DDBB, etc En este caso, empleando el gestor de la DDBB, se implementan
las tablas de las DDBB con sus caractersticas, organizacin y estructuras de
almacenamiento interno.
Para evitar la gran dependencia que exista antes entre los ficheros y las
aplicaciones que los utilizaban ( cualquier cambio en la estructura fsica o
lgica de los datos afectaba a las aplicaciones ), el instituto ANSI public un
informe en el que defina una arquitectura de tres niveles para ser utilizada
en el diseo de DDBB, con objeto de minorizar el impacto producido por los
cambios haciendo nfasis en la independencia que debe existir entre las
referencias externas a los datos y la forma fsica de almacenamiento y
organizacin de los mismos. Los tres niveles definidos son:
- Nivel externo: Constituye un nivel con el que interacta el usuario. Este
nivel representa una visin parcial de los datos, de manera que usuarios
diferentes tendrn una visin distinta de los mismos, mostrando solo
aquella parte que interesa al usuario.
- Nivel conceptual: Este nivel representa el esquema lgico de los datos,
reflejando su estructura y relaciones, sin entrar en detalles fsicos. Este nivel
se construye mediante un modelo en el que se define en primer lugar
aquella parte del mundo real que deseamos modelar, excluyendo los datos
que no son necesarios. En este punto debemos decidir que modelo lgico se
va a utilizar, existiendo varias alternativas como puede ser el modelo
relacional, el jerrquico, orientado a objetos, etc
- Nivel fsico: Este nivel debe ser transparente para el usuario. En este nivel
se especifica la estructura de los datos, as como el modo de
almacenamiento empleado.

Este apartado va a depender de varios factores tanto HW como Software,

entre los que se puede sealar: S.O., Sistema de ficheros del sistema gestor
de bases de datos, Unidades de almacenamiento
externos

2. Transformacin d modelo conceptual a lgico

El diseo de las DDBB del sistema se llevara a cabo aplicando la
arquitectura ANSI de tres niveles, por tanto debemos partir del modelo
conceptual y llegar hasta el esquema fsico o interno. El esquema
conceptual representa los recursos del sistema y se define sin tener en
consideracin cuestiones fsicas. Para la definicin de este esquema nos
podemos ayudar de herramientas de modelado como los diagramas. El
modelo E/R (entidad relacin) fue propuesto por Chen y posteriormente
algunas aportaciones de han dado lugar E/R extendido.

Los componentes del modelo E/R son:

- Entidades: representan un objeto real o abstracto sobre el que queremos
almacenar informacin.
- Relacin: define una asociacin entre entidades.
- Grado de una relacin: nmero de entidades que participan en una
relacin, pudiendo ser reflexivas (una entidad se relaciona con ella misma),
binaria (participan 2 entidades) y n-aria (participan n entidades).
- Cardinalidad: define el nmero mximo de ocurrencias de una entidad que
participan en una relacin. Puede ser de uno a uno, de uno a muchos y de
muchos a muchos.
-Atributos: representan propiedades o caractersticas de una entidad o
relacin.
Dentro del modelo E/R extendido aparecen adems otros conceptos:
- Jerarqua: una entidad puede mantener una relacin de supertipo con otras
entidades. Es el caso de la generalizacin y especializacin.
- Agregacin: conversin de una relacin junto con sus entidades
participantes, en una entidad para poder relacionarse con otra entidad.
- Exclusividad: es un tipo especial de relacin en la que una entidad se
asocia con varias entidades. La exclusividad relaciona una entidad con otra
de entre varias posibles. Una vez obtenido el modelo conceptual
(representado en el diagrama E/R) debe ser transformado a un modelo
lgico. Las secuencias de pasos a aplicar para dicha transformacin son:
1. Cada entidad se transforma en una tabla y los atributos de dicha entidad
en atributos de la tabla.
2. Las relaciones de muchos a muchos se transforman en tablas cuya clave
estar formada por la clave primaria de las entidades relacionadas. Las
relaciones de uno a muchos propagan la clave principal de la entidad cuya
cardinalidad es uno a la entidad de cardinalidad n.
Otra herramienta empleada para el diseo lgico de datos es el diagrama
de estructura de datos (DED), en la que se establecen los diferentes
registros que forman la base de datos y las relaciones entre ellos. La forma
tridente apunta a la entidad que acta como muchos.
Este tipo de esquema solo admite relaciones entre dos entidades, en caso
de modelar relaciones en las que intervengan ms de dos entidades
debemos redefinir el esquema reducindolo a relaciones binarias.
Se puede establecer una correspondencia entre diagramas E/R y diagramas
de estructura de datos, pudiendo pasar de un tipo de diagrama al otro.

3. Anlisis relacional de datos

El anlisis relacional de datos se centra en el estudio de la caractersticas
del modelo E/R y de la estructura del modelo lgico (E/R tabla).

El diseo de bases de datos relacionales implica la creacin de un

conjunto de tablas relacionadas entre si. El modelo as obtenido
puede presentar una serie de problemas como son la redundancia de
datos y ambigedades a medida que trabajamos con ellas. Debido a
este problema, se ha definido una teora que indica una serie de
restricciones que hemos de aplicar sobre el modelo para as obtener

un modelo normalizado, que evita los problemas planteados

.Para poder realizar el proceso de normalizacin hay que tener claros
algunos conceptos:
- Se dice que atributo es atmico cuando no puede tener ms de un
valor, en caso contrario, cuando un atributo puede tener varios
valores se dice que es un atributo multivaluado.
- Las claves son atributos que identifican de forma unvoca a las
entidades. Existen varios tipos de clave:
1. Superclave: estar formada por uno o ms atributos que
identificarn de forma nica a una entidad.
2. Clave candidata: es una superclave mnima, es decir, una
superclave que si se le quita un atributo deja de ser superclave.
3. Clave primaria: es la clave candidata que el diseador de la base
de datos ha elegido para diferenciar las entidades.
- Otro concepto que hay que tener en cuenta es el de dependencia
funcional. Existen varios tipos:
1. Dependencia funcional: dado un conjunto B decimos que dicho
conjunto depende funcionalmente de otro conjunto A si para cualquier
valor de A le corresponde un nico valor de B. Se denota A B.
2. Dependencia funcional completa: decimos que un conjunto B tiene
dependencia funcional completa respecto a otro conjunto A, si
depende de dicho conjunto en su totalidad y no de una de sus partes.
Se denota A => B.
3. Dependencia transitiva: se dice que un conjunto B depende de
forma transitiva de otro conjunto A, si existe un conjunto Z que
depende funcionalmente de A y B depende funcionalmente de Z. Se
denota A Z B.
Las principales formas normales de la teora de normalizacin son:
- Primera forma normal ( 1FN ): una tabla est en 1FN si todos los
atributos no clave, dependen funcionalmente de la clave (es decir, si
dada una clave se puede obtener el valor de todos sus atributos), o lo
que es lo mismo, no existen grupos repetitivos para un valor de clave.

Pasos a seguir:
A. Se crea a partir de la tabla inicial una nueva tabla con los atributos
que dependen funcionalmente de la clave (Que tendrn la misma
clave que la tabla inicial ). Esta tabla ya est en primera forma
normal.
B. Se crea una nueva tabla con los atributos restantes, eligiendo de
entre estos uno como clave de la tabla ( o ms de uno ). Los criterios
de eleccin de clave sern los mismos que se expusieron para los
tipos de clave.

C. Se comprueba si esta tabla est en primera forma normal. Si es as,

la tabla inicial ya est normalizada y finaliza el proceso. Si no,
tomamos esta tabla como tabla inicial y volvemos a realizar el
apartado A.
- Segunda Forma Normal ( 2FN ): Una tabla est en segunda forma
normal si est en primera forma normal y adems todos los atributos
que no pertenecen a la clave dependen funcionalmente de forma
completa de ella. De esta definicin se desprende que de una tabla
en primera forma normal y cuya clave est compuesta por un nico
atributo est en segunda forma normal.
El proceso de normalizacin es como sigue:
A. Se crea a partir de la tabla inicial una nueva tabla con los atributos
que dependen funcionalmente de forma completa de la clave (Que
tendrn la misma clave que la tabla inicial) . Esta tabla ya est en
segunda forma normal.
B. Se crea una nueva tabla con los atributos restantes, siendo su
clave el subconjunto de atributos de la clave inicial de los que
dependen de forma completa.
C. Se comprueba si esta tabla est en segunda forma normal. Si es
as, la tabla inicial ya est normalizada y finaliza el proceso. Si no,
tomamos esta tabla como tabla inicial y volvemos a realizar el
apartado A.
- Una tabla esta en tercera forma normal est en tercera forma
normal y adems no existen atributos no claves que dependan
transitivamente de la clave, es decir, no debe haber atributos no
clave que dependan de otros atributos no primos ( que no pertenecen
a la clave ).
El proceso de normalizacin es como sigue:
A. Se crea a partir de la tabla inicial una nueva tabla con los atributos
que no poseen dependencias transitivas. (Que tendrn la misma clave
que la tabla inicial ) . Esta tabla ya est en segunda forma normal.
B. Se crea una nueva tabla con los atributos restantes, siendo su
clave el subconjunto de atributos de la clave inicial de los que
dependen de forma completa.
C. Se crea una nueva tabla con los dos atributos no clave, que
intervienen en la dependencia transitiva, seleccionando entre ambos
a aquel que cumpla los requerimientos de clave. Esta nueva tabla
est ya en tercera forma normal
Existen ms formas normales: Forma normal bice Codd ( FNBC ),
( 4FN ), ( 5FN ), . Pero algunos autores opinan que a partir de todas
estas formas normales se puede producir perdida de dependencias

4.Documentacion
Durante el desarrollo de un proyecto software se genera un importante
volumen de documentacin en las diferentes fases que componen su
anlisis y su diseo. Durante la fase de diseo lgico de datos se generar
informacin en forma de diagrama entidad relacin y Diagrama de
estructuras de datos segn la metodologa empleada. Dichos diagramas
deben formar parte de la documentacin del proyecto. Pero adems de
dichos diagramas necesitaremos alguna herramienta que sirva para
recopilar los elementos de datos con los que trabajaremos en el proyecto,
as como una descripcin detallada de dichos elementos. La herramienta
que nos sirve para este propsito es el Diccionario de datos.
El diccionario de datos nos sirve para tomar nota de todos los elementos a
los que hacemos referencia en los diagramas empleados para modelar el
sistema que queremos construir. En el tomaremos nota de los datos,
objetos, entidades, almacenes y elementos de control a los que hacemos
referencia E/R, DED, DFD, DFC,