Diseo de base de datos y modelo entidad relacin

Visin general del proceso de diseo de base de datos

La tarea de creacin de aplicaciones de bases de datos es una labor compleja, que implica
varias fases, como el diseo del esquema de la base de datos, el diseo de los programas
que tienen acceso a los datos y los actualizan y el diseo del esquema de seguridad para
controlar el acceso a los datos. Las necesidades de los usuarios desempean un papel
central en el proceso de diseo.
El diseo de un entorno completo de aplicaciones de bases de datos que responda a las
necesidades de la empresa que se est modelando exige prestar atencin a un amplio
conjunto de consideraciones. Estos aspectos adicionales del uso esperado de la base de
datos influyen en gran variedad de opciones de diseo en los niveles fsico, lgico y de
vistas.
Fases de diseo
Para aplicaciones pequeas puede resultar factible para un diseador de bases de datos
que comprenda los requisitos de la aplicacin decidir directamente sobre las relaciones
que hay que crear, sus atributos y las restricciones sobre las relaciones. Sin embargo, un
proceso de diseo tan directo resulta difcil para las aplicaciones reales, ya que a menudo
son muy complejas.
Los modelos de datos de alto nivel sirven a los diseadores de bases de datos
ofrecindoles un marco conceptual en el que especificar de forma sistemtica los
requisitos de datos de los usuarios de la base de datos y una estructura para la base de
datos que satisfaga esos requisitos.
La fase inicial del diseo de las bases de datos:
Es la caracterizacin completa de la necesidad es de datos de los posibles usuarios de la
base de datos. El diseador de la base de datos debe interactuar intensamente con los
expertos y los usuarios del dominio para realizar esta tarea. El resultado de esta fase es
una especificacin de requisitos del usuario.
A continuacin, el diseador elige el modelo de datos y, aplicando los conceptos del
modelo de datos elegido, traduce estos requisitos en un esquema conceptual de la base
de datos. El esquema desarrollado en esta fase de diseo conceptual proporciona una
visin detallada de la empresa.
Un esquema conceptual completamente desarrollado indica tambin los requisitos
funcionales de la empresa. En la especificacin de requisitos funcionales los usuarios
describen los tipos de operaciones (o transacciones) que se llevarn a cabo sobre los
datos. Algunos ejemplos de operaciones son la modificacin o actualizacin de datos, la
bsqueda y recuperacin de datos concretos y el borrado de datos.
El proceso de paso desde el modelo abstracto de datos a la implementacin de la base de
datos se divide en de dos fases de diseo finales.
En la fase de diseo lgico el diseador traduce el esquema conceptual de alto nivel al
modelo de datos de la implementacin del sistema de bases de datos que se va a usar. El
modelo de implementacin de los datos suele ser el modelo relacional, y este paso suele
consistir en la traduccin del esquema conceptual definido mediante el modelo entidad-
relacin en un esquema de relacin.
Finalmente, el diseador usa el esquema de base de datos resultante propio del sistema
en la siguiente fase de diseo fsico, en la que se especifican las caractersticas fsicas de la
base de datos. Entre estas caractersticas estn la forma de organizacin de los archivos y
las estructuras de almacenamiento interno.
El esquema fsico de la base de datos puede modificarse con relativa facilidad una vez
creada la aplicacin. Sin embargo, las modificaciones del esquema lgico suelen resultar
ms difciles de llevar a cabo, ya que pueden afectar a varias consultas y actualizaciones
dispersas por todo el cdigo de la aplicacin. Por tanto, es importante llevar a cabo con
cuidado la fase de diseo de la base de datos antes de crear el resto de la aplicacin de
bases de datos.
Alternativas de diseo
Una parte importante del proceso de diseo de las bases de datos consiste en decidir la
manera de representar en el diseo los diferentes tipos de cosas, como personas,
lugares, productos y similares. Se usa el trmino entidad para hacer referencia a
cualquiera de esos elementos claramente identificables. Las diferentes entidades tienen
algunos aspectos en comn y algunas diferencias.
Se desea aprovechar los aspectos en comn para tener un diseo conciso, fcilmente
comprensible, pero hay que conservar la suficiente flexibilidad como para representar las
diferencias entre las diferentes entidades existentes en el momento del diseo o que se
puedan materializar en el futuro. Las diferentes entidades se relacionan entre s de
diversas maneras, todas las cuales deben incluirse en el diseo de la base de datos.
Al disear el esquema de una base de datos hay que asegurarse de que se evitan dos
peligros importantes:
1-Redundancia.
Un mal diseo puede repetir informacin. En el ejemplo bancario que se ha venido
usando, se tiene una relacin con la informacin sobre los clientes y una relacin separada
con la informacin sobre las cuentas. Supngase que, en lugar de eso, se repitiera toda la
informacin sobre los clientes (nombre, direccin, etc.) una vez por cada cuenta o
prstamo que tuviera cada cliente. Evidentemente, sera redundante. Lo ideal sera que la
informacin apareciera exactamente en un solo lugar.
2-Incompletitud.
Un mal diseo puede hacer que determinados aspectos de la empresa resulten difciles o
imposibles de modelar. Por ejemplo, supngase que se usa un diseo de base de datos
para el escenario bancario que almacena la informacin del nombre y de la direccin del
cliente con cada cuenta y con cada prstamo, pero que no tiene una relacin separada
para los clientes.
Modelo entidad relacin
El modelo de datos entidadrelacin (E-R) se desarroll para facilitar el diseo de bases de
datos permitiendo la especificacin de un esquema de la empresa que representa la
estructura lgica global de la base de datos. El modelo de datos E-R es uno de los
diferentes modelos de datos semnticos; el aspecto semntico del modelo radica en la
representacin del significado de los datos. El modelo E-R resulta muy til para relacionar
los significados e interacciones de las empresas reales con el esquema conceptual.
Debido a esta utilidad, muchas herramientas de diseo de bases de datos se basan en los
conceptos del modelo E-R. El modelo de datos E-R emplea tres conceptos bsicos: los
conjuntos de entidades, los conjuntos de relaciones y los atributos.
Conjunto de entidades
Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las
mismas propiedades, o atributos. El conjunto de todas las personas que son clientes en un
banco dado, por ejemplo, se puede definir como el conjunto de entidades cliente.
Anlogamente, el conjunto de entidades prstamo puede representar el conjunto de
todos los prstamos concedidos por un banco concreto. Cada una de las entidades que
constituyen un conjunto se denomina extensin de ese conjunto de entidades.
 Posibles atributos del conjunto de entidades cliente son id_cliente, nombre_cliente, calle_cliente
y ciudad_cliente. En la vida real habra ms atributos, como el nmero de la calle, el nmero del
piso la provincia, el cdigo postal, y el pas, pero se omiten para no complicar el ejemplo. Posibles
atributos del conjunto de entidades prstamo son nmero_prstamo e importe.

Cada entidad tiene un valor para cada uno de sus atributos. Por ejemplo, una entidad
cliente concreta puede tener el valor 32.112.312 para id_cliente, el valor Santos para
nombre_cliente, el valor Mayor para calle_cliente y el valor Peguerino para
ciudad_cliente. El atributo id_cliente se usa para identificar unvocamente a los clientes,
dado que puede haber ms de un cliente con el mismo nombre, calle y ciudad. E

La Figura 6.1 muestra parte de una base de datos de un banco que consta de dos
conjuntos de entidades, cliente y prstamo.
Las bases de datos para entidades bancarias pueden incluir diferentes conjuntos de
entidades. Por ejemplo, adems del seguimiento de los clientes y de los prstamos, el
banco tambin ofrece cuentas, que se representan mediante el conjunto de entidades
cuenta con los atributos nmero_cuenta y saldo. Adems, si el banco tiene varias
sucursales, se puede guardar informacin acerca de todas las sucursales del banco.
Cada conjunto de entidades sucursal se puede describir mediante los atributos
nombre_sucursal, ciudad_sucursal y activos.
Conjuntos relacionales
Una relacin es una asociacin entre varias entidades. Por ejemplo, se puede definir una
relacin que asocie al cliente Lpez con el prstamo P-15. Esta relacin especifica que
Lpez es un cliente con el prstamo nmero P-15.
Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es
una relacin matemtica con n 2 de conjuntos de entidades (posiblemente no distintos).
Atributos
Para cada atributo hay un conjunto de valores permitidos, denominados dominio o
conjunto de valores de ese atributo. El dominio del atributo nombre_cliente puede ser el
conjunto de todas las cadenas de texto de una cierta longitud. Anlogamente, el dominio
del atributo nmero_prstamo puede ser el conjunto de todas las cadenas de caracteres
de la forma P-n, donde n es un entero positivo.
Los valores de los atributos que describen cada entidad constituyen una parte significativa
de los datos almacenados en la base de datos.
Cada atributo, tal y como se usa en el modelo E-R, se puede caracterizar por los siguientes
tipos de atributo.
Atributos simples y compuestos
En los ejemplos considerados hasta ahora los atributos han sido simples; es decir, no
estaban divididos en sub-partes. Los atributos compuestos, en cambio, se pueden dividir
en sub-partes (es decir, en otros atributos). Por ejemplo, el atributo nombre puede estar
estructurado como un atributo compuesto consistente en nombre, primer_apellido y
segundo_apellido. Usar atributos compuestos en un esquema de diseo es una buena
eleccin si el usuario desea referirse a un atributo completo en algunas ocasiones y, en
otras, solamente a algn componente del atributo.
Atributos monovalorados y multivalorados
Todos los atributos que se han especificado en los ejemplos anteriores tienen un nico
valor para cada entidad concreta. Por ejemplo, el atributo nmero_prstamo para una
entidad prstamo especfica hace referencia a un nico nmero de prstamo. Se dice que
estos atributos son monovalorados. Puede haber ocasiones en las que un atributo tenga
un conjunto de valores para una entidad concreta. Considrese un conjunto de entidades
empleado con el atributo nmero_telfono. Cada empleado puede tener cero, uno o
varios nmeros de telfono, y empleados diferentes pueden tener diferente cantidad de
telfonos. Se dice que este tipo de atributo es multivalorado.
La correspondencia de cardinalidades, o razn de cardinalidad, expresa el nmero de
entidades a las que otra entidad se puede asociar mediante un conjunto de relaciones.
Cada empleado puede tener cero, uno o varios nmeros de telfono, y empleados
diferentes pueden tener diferente cantidad de telfonos.Se dice que este tipo de atributo
es multivalorado. Como ejemplo adicional, el atributo nombre_subordinado del conjunto
de entidades empleado es multivalorado, ya que cada empleado podra tener cero, uno o
ms subordinados.
Atributos derivados
El valor de este tipo de atributo se puede obtener a partir del valor de otros atributos o
entidades relacionados. Por ejemplo, supngase que el conjunto de entidades cliente que
tiene un atributo prstamos que representa el nmero de prstamos que cada cliente
tiene concedidos en el banco. Ese atributo se puede obtener contando el nmero de
entidades prstamo asociadas con cada cliente.
Como ejemplo adicional, supngase que el conjunto de entidades cliente tiene el atributo
edad, que indica la edad del cliente. Si el conjunto de entidades cliente tiene tambin un
atributo fecha_de_nacimiento, se puede calcular edad a partir de fecha_de_nacimiento y
de la fecha actual. Por tanto, edad es un atributo derivado.
Los atributos toman valores nulos cuando las entidades no tienen ningn valor para ese
atributo. El valor nulo tambin puede indicar no aplicable es decir, que el valor no existe
para esa entidad. Por ejemplo, una persona puede no tener un segundo nombre de pila.
Nulo puede tambin designar que el valor del atributo es desconocido.
Restricciones
Un esquema de desarrollo E-R puede definir ciertas restricciones a las que el contenido de
la base de datos se debe adaptar. En este apartado se examinan la correspondencia de
cardinalidades, las restricciones de claves y las restricciones de participacin.
La correspondencia de cardinalidades, o razn de cardinalidad, expresa el nmero de
entidades a las que otra entidad se puede asociar mediante un conjunto de relaciones.
La correspondencia de cardinalidades resulta muy til para describir conjuntos de
relaciones binarias, aunque pueda contribuir a la descripcin de conjuntos de relaciones
que impliquen ms de dos conjuntos de entidades. En este apartado se centrar la
atencin nicamente en los conjuntos de relaciones binarias.
Conjunto de relaciones
La clave primaria de cada conjunto de entidades permite distinguir entre las diferentes
entidades del conjunto. Se necesita un mecanismo parecido para distinguir entre las
diferentes relaciones de cada conjunto de relaciones.

Restricciones de participacin
Se dice que la participacin de un conjunto de entidades E en un conjunto de relaciones R
es total si cada entidad de E participa, al menos, en una relacin de R. Si slo algunas
entidades de E participan en relaciones de R, se dice que la participacin del conjunto de
entidades E en la relacin R es parcial. Por ejemplo, se puede esperar que cada entidad
prstamo est relacionada, al menos, con un cliente mediante la relacin prestatario. Por
tanto, la participacin de prstamo en el conjunto de relaciones prestatario es total. En
cambio, un individuo puede ser cliente del banco tenga o no tenga concedido algn
prstamo en el banco.
Diagrama entidad relacin
Diagrama de Entidad-Relacin") es una herramienta para el modelado de datos que
permite representar las entidades relevantes de un sistema de informacin as como sus
interrelaciones y propiedades.
El Modelo Entidad-Relacin
1. Se elabora el diagrama (o diagramas) entidad-relacin.
2. Se completa el modelo con listas de atributos y una descripcin de otras
restricciones que no se pueden reflejar en el diagrama.
Los diagramas E-R pueden expresar grficamente la estructuralgica general de las bases
de datos. Los diagramas E-R son sencillos y claros cualidades que pueden ser responsables
en gran parte de la popularidad del modelo E-R. Estos diagramas constan de los siguientes
componentes principales:
Rectngulos,que representan conjuntos de entidades
Rombos, que representan conjuntos de relaciones.
Lneas, que unen los atributos con los conjuntos de entidades y los conjuntos de
entidades con los conjuntos de relaciones.
Elipses dobles, que representan atributos multivalorados.
Elipses discontinuas, que denotan atributos derivados.
Lneas dobles, que indican participacin total de una entidad en un conjunto de
relaciones
Rectngulos dobles, que representan conjuntos de entidades dbiles
Conjunto de entidades dbiles
Un conjunto de entidades puede no tener suficientes atributos para formar una clave
primaria. Tal conjunto de entidades se denomina conjunto de entidades dbiles. Un
conjunto de entidades que tiene una clave primaria se denomina conjunto de entidades
fuertes.
Para que un conjunto de entidades dbiles tenga sentido, debe estar asociada con otro
conjunto de entidades, denominado el conjunto de entidades identificadoras o
propietarias.
Caractersticas del modelo Entidad-Relacin extendido
Aunque los conceptos bsicos de Entidad-Relacin pueden modelar la mayora de las
caractersticas de las bases de datos, algunos aspectos de una base de datos pueden ser
ms adecuadamente expresados mediante ciertas extensiones del modelo Entidad-
Relacin bsico. En este apartado se discuten las caractersticas Entidad-Relacin
extendidas de especializacin, generalizacin, conjuntos de entidades de nivel ms alto y
ms bajo, herencia de atributos y agregacin.
Un conjunto de entidades puede incluir subgrupos de entidades que se diferencian de
alguna forma de las otras entidades del conjunto. El proceso de designacin de subgrupos
dentro de un conjunto de entidades se denomina especializacin.
El refinamiento a partir de un conjunto de entidades inicial en sucesivos niveles de
subgrupos de entidades representa un proceso de diseo descendente en el que las
distinciones se hacen explcitas. Los conjuntos de entidades de nivel ms alto y nivel ms
bajo tambin se pueden llamar superclase y subclase, respectivamente. Una propiedad
crucial de las entidades de nivel ms alto y ms bajo creadas mediante especializacin y
generalizacin es la herencia de atributos. Los atributos de los conjuntos de entidades de
nivel ms alto se dice que son heredados por los conjuntos de entidades de nivel ms
bajo.
Diseo de una base de datos para un banco
Los requisitos para una base de datos de una entidad bancaria requieren mas detalles y se
desarrollan con un diseo mas realista y mas complicado que los que ya hemos visto. Sin
embargo no se intenta modelar cada aspecto del diseo de la base de datos para el banco;
se consideran solo algunos aspectos para el diseo de la misma.
Para esta se aplican las dos fases iniciales del diseo de bases de datos, es decir, la
recopilacin de los requisitos de datos y el diseo del esquema conceptual, al ejemplo de
entidad bancaria. Se usara el modelo de datos E-R para traducir los requisitos de los
usuarios a un esquema de diseo conceptual que se representara como diagrama Entidad-
Relacion (E-R).

Entidad:
Representa una cosa, "objeto" o "concepto" del mundo real con existencia
independiente, es decir, se diferencia nicamente de otro objeto o cosa, incluso
siendo del mismo tipo, o una misma entidad.

Relacin:
Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza.
Reduccin a esquemas relacionales

Las bases de datos que se ajustan a un esquema de bases de datos E-R se pueden
representar mediante conjuntos de esquemas de relacin. Para cada conjunto de
entidades y para cada conjunto de relaciones de la base de datos hay un solo
esquema de relacin a la que se asigna el nombre del conjunto de entidades o del
conjunto de relaciones correspondiente.
Tanto el modelo E-R de bases de datos como el relacional son representaciones
abstractas y lgicas de empresas del mundo real. Como los dos modelos usan
principios de diseo parecidos, los diseos E-R se pueden convertir en diseos
relacionales.

En este apartado se describe la manera de representar los esquemas E-R mediante

esquemas de relacin y el modo de asignar las restricciones que surgen del modelo
E-R a restricciones de los esquemas de relacin.
El lenguaje de modelado unificado UML
Los diagramas entidad-relacin ayudan a modelar el componente de representacin de
datos de los sistemas de software. La representacin de datos, sin embargo, slo forma
parte del diseo global del sistema. Otros componentes son los modelos de interaccin
del usuario con el sistema, la especificacin de los mdulos funcionales del sistema y su
interaccin, etc. El lenguaje de modelado unificado (Uni- fied Modeling Language, UML) es
una norma desarrollada bajo los auspicios del Grupo de Administracin de Objetos (Object
Management Group, OMG) para la creacin de especificaciones de diferentes
componentes de los sistemas de software.
Algunas de las partes de UML son:
Diagramas de clase. Los diagramas de clase son parecidos a los diagramas E-R. Ms
adelante en este apartado se mostrarn algunas caractersticas de los diagramas
de clase y del modo en que se relacionan con los diagramas E-R.
Diagramas de caso de uso. Los diagramas de caso de uso muestran la interaccin
entre los usuarios y el sistema, en especial los pasos de las tareas que llevan a cabo
los usuarios (como retirar dinero o matricularse en una asignatura).
Diagramas de actividad. Los diagramas de actividad describen el flujo de tareas
entre los diferentes componentes del sistema.
Diagramas de implementacin. Los diagramas de implementacin muestran los
componentes del sistema y sus interconexiones, tanto en el nivel de los
componentes de software como en el de hardware.