2.1 El Proceso de Diseño
"El diseño de bases de datos es el
proceso por el que se determina la organización de una base de datos,
incluidos su estructura, contenido y las aplicaciones que se han de
desarrollar. Durante mucho tiempo, el diseño de bases de datos fue
considerado una tarea para expertos: más un arte que una ciencia. Sin
embargo, se ha progresado mucho en el diseño de bases de datos y éste
se considera ahora una disciplina estable, con métodos y técnicas
propios. Debido a la creciente aceptación de las bases de datos por
parte de la industria y el gobierno en el plano comercial, y a una
variedad de aplicaciones científicas y técnicas, el diseño de bases de
datos desempeña un papel central en el empleo de los recursos de
información en la mayoría de las organizaciones. El diseño de bases de
datos ha pasado a constituir parte de la formación general de los
informáticos, en el mismo nivel que la capacidad de construir
algoritmos usando un lenguaje de programación convencional."
Si usa un proceso de diseño de base
de datos establecido, puede crear de forma rápida y efectiva una base
de datos bien diseñada que le proporciona acceso conveniente a la
información que desea. Con un diseño sólido tardará menos tiempo en
construir la base de datos y obtendrá resultados más rápidos y
precisos.
Nota Los términos "base de datos" y "tabla" no son sinónimos. El término base de datos se refiere a una base de datos relacional que almacena información sobre una o más tablas.
La clave para obtener un diseño de
base de datos eficaz radica en comprender exactamente qué información
se desea almacenar y la forma en que un sistema de administración de
bases de datos relacionales, almacena los datos. Para ofrecer
información de forma eficiente y precisa, debe tener almacenados los
datos sobre distintos temas en tablas separadas. Por ejemplo, puede
haber una tabla donde sólo se almacenen datos sobre empleados y otra
tabla que sólo contenga datos de ventas.
Al organizar los datos de forma
apropiada, proporciona flexibilidad a la base de datos y tiene la
posibilidad de combinar y presentar información de muchas formas
diferentes.
Al diseñar una base de datos, en
primer lugar debe dividir la información que desea almacenar como temas
distintos y después indicar cómo se relacionan estos temas para que
pueda recuperar la información correcta cuando sea necesario. Si
mantiene la información en tablas separadas facilitará la organización
y el mantenimiento de los datos y conseguirá aplicaciones de alto
rendimiento.
El proceso de diseño consta de los pasos siguientes (pueden variar según la fuente de información):
- Determinar la finalidad de la base de datos
Esto le ayudará a estar preparado para los demás pasos.
- Buscar y organizar la información necesaria
Reúna todos los tipos de información que desee
registrar en la base de datos, como los nombres de productos o los
números de pedidos.
- Dividir la información en tablas
Divida los elementos de información en entidades o
temas principales, como Productos o Pedidos. Cada tema pasará a ser una
tabla.
- Convertir los elementos de información en columnas
Decida qué información desea almacenar en cada
tabla. Cada elemento se convertirá en un campo y se mostrará como una
columna en la tabla. Por ejemplo, una tabla Empleados podría incluir
campos como Apellido y Fecha de contratación.
No incluir datos calculados.
Almacene la información en sus partes lógicas mas pequeñas
- Especificar claves principales
Elija la clave principal de cada tabla. La clave
principal es una columna que se utiliza para identificar inequívocamente
cada fila, como Id. de producto o Id. de pedido.
- Definir relaciones entre las tablas
Examine cada tabla y decida cómo se relacionan los
datos de una tabla con las demás tablas. Agregue campos a las tablas o
cree nuevas tablas para clarificar las relaciones según sea
necesario.
- Ajustar el diseño
Analice el diseño para detectar errores. Cree las
tablas y agregue algunos registros con datos de ejemplo. Compruebe si
puede obtener los resultados previstos de las tablas. Realice los
ajustes necesarios en el diseño.
- Aplicar las reglas de normalización
Aplique reglas de normalización de los datos para
comprobar si las tablas están estructuradas correctamente. Realice los
ajustes necesarios en las tablas.
2.2 Modelo Entidad - Relación
1.Un modelo de datos es una colección de herramientas conceptuales
para la descripción de datos, relaciones entre datos, semántica de los
datos y restricciones de consistencia. Podemos citar dos
modelos de datos —el modelo entidad-relación y el modelo relacional.
El modelo entidad-relación (E-R) es un modelo de datos de alto nivel. Está
basado en una percepción de un mundo real que consiste en una colección de
objetos básicos, denominados entidades, y de relaciones entre estos objetos.
El modelo relacional es un modelo de menor nivel. Usa una colección de tablas
para representar tanto los datos como las relaciones entre los datos. Su simplicidad
conceptual ha conducido a su adopción general; actualmente, una vasta
mayoría de productos de bases de datos se basan en el modelo relacional. Los
diseñadores formulan generalmente el diseño del esquema de la base de datos
modelando primero los datos en alto nivel, usando el modelo E-R, y después
traduciéndolo al modelo relacional.
Otro modelo de
datos es el orientado a objetos, por ejemplo, extiende la representación de entidades
añadiendo nociones de encapsulación, métodos (funciones) e identidad de
objeto. El modelo de datos relacional orientado a objetos combina características
del modelo de datos orientado a objetos y del modelo de datos relacional.
Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación
de un esquema de la empresa que representa la estructura lógica completa de una base
de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el
aspecto semántico del modelo yace en la representación del significado de los datos. El modelo
E-R es extremadamente útil para hacer corresponder los significados e interacciones de las
empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas herramientas
de diseño de bases de datos se basan en los conceptos del modelo E-R.
Hay tres nociones básicas que emplea el modelo de datos
E-R: conjuntos de entidades, conjuntos de relaciones y
atributos.
Una entidad es una «cosa» u «objeto» en el mundo real
que es distinguible de todos los demás objetos. Por ejemplo,
cada persona en un desarrollo es una entidad. Una
entidad tiene un conjunto de propiedades, y los valores
para algún conjunto de propiedades pueden identificar
una entidad de forma unívoca. Por ejemplo, el D.N.I.
67.789.901 identifica unívocamente una persona particular
en la empresa. Análogamente, se puede pensar
en los préstamos bancarios como entidades, y un número
de préstamo P-15 en la sucursal de Castellana identifica
unívocamente una entidad de réstamo. Una entidad
puede ser concreta, como una persona o un libro, o
puede ser abstracta, como un préstamo, unas vacaciones
o un concepto.
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 pueden
definir como el conjunto de entidades cliente.
Las entidades individuales
que constituyen un conjunto se llaman la extensión del
conjunto de entidades. Así, todos los clientes de un banco
son la extensión del conjunto de entidades cliente.
Una entidad se representa mediante un conjunto de
atributos. Los atributos describen propiedades que
posee cada miembro de un conjunto de entidades. La
designación de un atributo para un conjunto de entidades
expresa que la base de datos almacena información
similar concerniente a cada entidad del conjunto de entidades;
sin embargo, cada entidad puede tener su propio
valor para cada atributo. Posibles atributos del conjunto
de entidades cliente son id-cliente, nombre-cliente,
calle-cliente y ciudad-cliente. En la vida real, habría
más atributos, tales como el número de la calle, el número
del portal, la provincia, el código postal, y la comunidad
autónoma, pero no se incluyen en el ejemplo simple.
Posibles atributos del conjunto de entidades
préstamo son número-préstamo e importe.
Para cada atributo hay un conjunto de valores permitidos,
llamados el dominio, o el conjunto de valores,
de ese atributo. El dominio del atributo nombrecliente
podría ser el conjunto de todas las cadenas de
texto de una cierta longitud. Análogamente, el dominio
del atributo número-préstamo podría ser el conjunto de
todas las cadenas de la forma «P-n», donde n es un entero
positivo.
Ejemplo:
Entidad: Empleado
Nombre de atributo: Código
• Descripción: Código único por empleado
asignado por la empresa
• Función: Identificación (+Definición)
• Dominio: Números positivos de dos cifras
Entidad: Empleado
Nombre de atributo: Código
• Descripción: Código único por empleado
asignado por la empresa
• Función: Identificación (+Definición)
• Dominio: Números positivos de dos cifras
Atributos monovalorados y multivalorados. Los
atributos que se han especificado en los ejemplos
tienen todos un valor sólo para una entidad concreta.
Por ejemplo, el atributo número-préstamo
para una entidad préstamo específico, referencia a
un único número de préstamo. Tales atributos se
llaman monovalorados. Puede haber ocasiones en
las que un atributo tiene un conjunto de valores para
una entidad específica. Considérese un conjunto de
entidades empleado con el atributo número-teléfono.
Cualquier empleado particular puede tener cero,
uno o más números de teléfono. Este tipo de atributo
se llama multivalorado. En ellos, se pueden
colocar apropiadamente límites inferior y superior
en el número de valores en el atributo multivalorado.
Como otro ejemplo, un atributo nombresubordinado
del conjunto de entidades empleado sería multivalorado, ya que un empleado en concreto
podría tener cero, uno o más subordinados.
Cuando sea apropiado se pueden establecer
límites superior e inferior en el número de valores
de un atributo multivalorado. Por ejemplo, un banco
puede limitar el número de números de teléfono
almacenados para un único cliente a dos. Colocando límites en este caso, se expresa que el atributo número-teléfono del conjunto de entidades cliente puede tener entre cero y dos valores.
almacenados para un único cliente a dos. Colocando límites en este caso, se expresa que el atributo número-teléfono del conjunto de entidades cliente puede tener entre cero y dos valores.
Considérese que el conjunto
de entidades empleado tiene un atributo edad,
que indica la edad del cliente. Si el conjunto de
entidades cliente tiene también un atributo fechade-nacimiento, se puede calcular edad a partir de
fecha-de-nacimiento y de la fecha actual. Así, edad
es un atributo derivado.
Un atributo toma un valor nulo cuando una entidad
no tiene un valor para un atributo. El valor nulo también
puede indicar «no aplicable», es decir, que el valor
no existe para la entidad. Por ejemplo, una persona puede
no tener segundo nombre de pila. Nulo puede también
designar que el valor de un atributo es desconocido.
Un valor desconocido puede ser, bien perdido (el
valor existe pero no se tiene esa información) o desconocido
(no se conoce si el valor existe realmente o no).
Por ejemplo, si el valor nombre para un cliente particular
es nulo, se asume que el valor es perdido, ya que
cada cliente debe tener un nombre. Un valor nulo para
el atributo piso podría significar que la dirección no
incluye un piso (no aplicable), que existe piso pero no
se conoce cuál es (perdido), o que no se sabe si el piso
forma parte o no de la dirección del cliente (desconocido).
Una relación es una asociación entre diferentes entidades.
Por ejemplo, se puede definir una relación que
asocie al cliente López con el préstamo P-15. Esta relación
especifica que López es un cliente con el préstamo
número P-15.
Un conjunto de relaciones es un conjunto de relaciones
del mismo tipo. Formalmente es una relación
matemática con n > = 2 de conjuntos de entidades (posiblemente
no distintos). Si E1, E2,…,En son conjuntos de
entidades, entonces un conjunto de relaciones R es un
subconjunto de:
{(e1, e2,…,en) | e1 ∈ E1, e2 ∈ E2,…,en ∈ En}
donde (e1,e2,…en) es una relación.
Considérense las dos entidades cliente y préstamo. Se define el conjunto de relaciones
prestatario para denotar la asociación entre clientes y
préstamos bancarios que los clientes tengan. Esta asociación
se describe en la siguiente figura:
La función que desempeña una entidad en una relación
se llama papel de la entidad.
Debido a que los conjuntos de entidades que participan
en un conjunto de relaciones son generalmente distintos,
los papeles están implícitos y no se especifican
normalmente. Sin embargo, son útiles cuando el significado
de una relación necesita aclaración. Tal es el caso
cuando los conjuntos de entidades de una relación no
son distintos; es decir, el mismo conjunto de entidades
participa en una relación más de una vez con diferentes
papeles. En este tipo de conjunto de relaciones, que se
llama algunas veces conjunto de relaciones recursivo,
es necesario hacer explícitos los papeles para especificar
cómo participa una entidad en un ejemplar de relación.
Por ejemplo, considérese una conjunto de entidades
empleado que almacena información acerca de todos
los empleados del banco. Se puede tener un conjunto de
relaciones trabaja-para que se modela mediante pares
ordenados de entidades empleado. El primer empleado
de un par toma el papel de trabajador, mientras el segundo
toma el papel de jefe. De esta manera, todas las relaciones
trabaja-para son pares (trabajador, jefe); los pares (jefe, trabajador) están excluidos.
trabaja-para son pares (trabajador, jefe); los pares (jefe, trabajador) están excluidos.
El número de conjuntos de entidades que participan
en un conjunto de relaciones es también el grado del
conjunto de relaciones. Un conjunto de relaciones binario
tiene grado 2; un conjunto de relaciones ternario tiene
grado 3.
Otro ejemplo:
Una relación tiene sentido al
expresar las entidades que relaciona. En el ejemplo anterior, un
huesped(entidad), se aloja(relación) en una habitacion(entidad).
Dados los conjuntos de entidades
"Habitación" y "Huésped", todas las relaciones de la forma
habitación-huésped, permiten obtener la información de los huéspedes y
sus respectivas habitaciones.
La dependencia o asociación entre los conjuntos de entidades es llamada participación. En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en el conjunto de relaciones habitación-huésped.
2.3 Restricciones
Una restricción es una condición 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 método 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 restricción o no.
Las restricciones no son parte formal del modelo
relacional, pero son incluidas porque juegan el rol de organizar mejor
los datos.
Un esquema de desarrollo E-R puede definir ciertas restricciones
a las que los contenidos de la base de datos
se deben adaptar.
Examinemos la correspondencia
de cardinalidades y las restricciones de participación,
que son dos de los tipos más importantes de
restricciones.
La correspondencia de cardinalidades, o razón de cardinalidad,
expresa el número de entidades a las que otra
entidad puede estar asociada vía un conjunto de relaciones.
Uno a uno. Una entidad en A se asocia con a lo
sumo una entidad en B, y una entidad en B se asocia
con a lo sumo una entidad en A.
Ej. Una persona tiene un coche y un coche es de una sola persona.
Uno a varios. Una entidad en A se asocia con cualquier
número de entidades en B (ninguna o varias).
Una entidad en B, sin embargo, se puede asociar con
a lo sumo una entidad en A
Ej. Una persona tiene varios coches y un coche es de una sola persona.
Varios a uno. Una entidad en A se asocia con a lo
sumo una entidad en B. Una entidad en B, sin embargo,
se puede asociar con cualquier número de entidades
(ninguna o varias) en A
Ej. Una persona tiene un coche y un coche es de varias personas.
Varios a varios. Una entidad en A se asocia con
cualquier número de entidades (ninguna o varias)
en B, y una entidad en B se asocia con cualquier
número de entidades (ninguna o varias) en A.
Ej. Una persona tiene varios coches y un coche es de varias personas.
Como ilustración considérese el conjunto de relaciones
prestatario. Si en un banco particular un préstamo
puede pertenecer únicamente a un cliente y un cliente
puede tener varios préstamos, entonces el conjunto
de relaciones de cliente a préstamo es uno a varios. Si
un préstamo puede pertenecer a varios clientes (como
préstamos que se toman en conjunto por varios socios
de un negocio) el conjunto de relaciones es varios a
varios.
Restricciones Parciales
La participación de un conjunto de entidades E en un
conjunto de relaciones R se dice que es total si cada
entidad en E participa al menos en una relación en R.
Si sólo algunas entidades en E participan en relaciones
en R, la participación del conjunto de entidades E en la
relación R se llama parcial. Por ejemplo, se puede esperar
que cada entidad préstamo esté relacionada con al primamenos
un cliente mediante la relación prestatario. Por
lo tanto, la participación de préstamo en el conjunto de
relaciones prestatario es total. En cambio, un individuo
puede ser cliente de un banco tenga o no tenga un préstamo
en el banco. Así, es posible que sólo algunas de
las entidades cliente estén relacionadas con el conjunto
de entidades préstamo mediante la relación prestatario,
y la participación de cliente en el conjunto de relaciones
prestatario es por lo tanto parcial.
• Una línea dirigida desde el conjunto de relaciones
prestatario al conjunto de entidades préstamo especifica que prestatario es un conjunto de relaciones
uno a uno, o bien varios a uno, desde cliente a préstamo;
prestatario no puede ser un conjunto de relaciones
varios a varios ni uno a varios, desde cliente
a préstamo.
• Una línea no dirigida desde el conjunto de relaciones prestatario al conjunto de relaciones préstamo especifica que prestatario es o bien un conjunto de relaciones varios a varios, o bien uno a
varios, desde cliente a préstamo. Volviendo al diagrama E-R de la figura anterior, se ve que el conjunto de relaciones prestatario es varios a varios.
Si el conjunto de relaciones
prestatario fuera uno a uno, entonces ambas líneas
desde prestatario tendrían flechas: una apuntando
al conjunto de entidades préstamo y otra apuntando al
conjunto de entidades cliente
Observe el siguiente modelo E-R y analicelo:
a) La entidad superclase nos permite modelizar las características comunes de la entidad vista de una forma genérica.
Es necesario que se cumpla que toda ocurrencia de una entidad subclase sea también una ocurrencia de su entidad superclase.
Denotamos la generalización/especialización con una flecha que parte de las entidades subclase y que se dirige a la entidad superclase.
La generalización/especialización de los empleados es total porque suponemos que todo empleado debe ser directivo, técnico o administrativo. Se denota con la etiqueta T.
Lectura del tema 2.8 Diseño de un esquema de
Bases de Datos E-R, del libro Fundamentos de Bases de Datos de Abraham
Silberschatz.
Lectura del tema 2.9 Reducción de un esquema E-R a Tablas, del libro Fundamentos de Bases de Datos de Abraham Silberschatz.
Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una línea que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de relaciones adyacente a la línea. También se puede especificar el papel que juega un conjunto de entidades en un conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto con los atributos del conjunto de relaciones, y conectar el cuadro con una línea discontinua a la línea que describe el conjunto de relaciones. Este cuadro se puede tratar entonces como un conjunto de entidades, de la misma forma que una agregación en los diagramas E-R puede participar en relaciones con otros conjuntos de entidades. La relaciones no binarias no se pueden representar directamente en UML se deben convertir en relaciones binarias (vease Apartado 2.4.3). Las restricciones de cardinalidad se especifican en UML de la misma forma que en los diagramas E-R, de la forma i..s, donde i denota el mínimo y s el máximo número de relaciones en que puede participar una entidad. Sin embargo, se debería ser consciente que la ubicación de las restricciones es exactamente el inverso de la ubicación de las restricciones en los diagramas E-R, como muestra la figura. La restricción 0..* en el lado E2 y 0..1 en el lado E1 significa que cada entidad.
Tiempo de TAREA, ups!!!!!!!, revisar el partado de tareas y elaborar la nùmero 3.
2.4 Diagramas E-R
2.5 Diseño con Diagramas E-R
La estructura lógica de una Base de Datos se puede
representar graficamente a través de un diagrama, el cual llamaremos
Diagrama E-R. Estos diagramas se apoyan de diferentes símbolos los
cuales tienen un significado particular. Los diagramas se usan para que
la información se presente de forma clara y sencilla. Los componentes
principales son:
Breve recordatorio:
Entidad: Representa un objeto que
tiene vida propia en el sistema que se está modelando, tanto tangible
como intangibles. Ejemplo: cliente, producto, estudiante, vacación.
Conjunto de entidades: Grupo
(conjunto) de entidades del mismo tipo. Ejemplo: Todos los estudiantes
de un curso, representan el conjunto de entidades estudiante.
Relación: Asociación o vinculación
entre dos o más entidades. Ejemplo: La relación comprar entre las
entidades cliente y producto. Generalmente representa acciones entre las
entidades.
Conjunto de relaciones: Son relaciones del mismo tipo.
Atributos: Características o
propiedades asociadas al conjunto de entidades o relaciones y que toman
valor en una entidad en particular. Ejemplo: nombre, cédula, teléfono.
Los posibles valores puede tomar un atributo para un conjunto de
entidades se denomina dominio.
Los atributos se pueden clasificar en:
- Simples o atómicos: Son aquellos que no contienen otros atributos- Compuestos: Son los que incluyen otros atributos simples.. Ejemplo: dirección (Se puede dividir en calle, número, ciudad).- Monovalorados o Univalorados: Atributo que toma un solo valor, para una entidad en particular.- Multivalorados: Atributo que para una misma entidad puede tomar muchos valores.- Derivados o calculados: Son aquellos atributos cuyos valores se pueden conseguir con operaciones sobre valores de otros atributos.- Nulos: Son aquellos atributos para los cuales en algún momento no existe o no se conoce su valor.
Diagrama Entidad - Relación.
Es la representación gráfica del Modelo
Entidad-Relación y permite ilustrar la estructura de la base
de datos del negocio modelado.
Escribe Johnson "los diagramas ER constituyen una notación
para documentar un diseño tentativo de bases de datos. Los
analistas los utilizan para facilitar el proceso de diseño"
[Joh00].
Está compuesto por los siguientes elementos.
• Rectángulos: representan conjuntos de entidades.
• Elipses: representan atributos.
• Rombos: representan relaciones.
• Líneas: unen atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones.
• Elipses dobles: representan atributos multivalorados.
• Elipses discontinuas: que denotan atributos derivados.
• Líneas dobles: indican participación total de una entidad en un conjunto de relaciones.
• Rectángulos dobles: representan conjuntos de entidades débiles.
Tomaremos el ejemplo del Libro, Fundamentos de Bases de Datos
Considérese el diagrama entidad-relación de la siguiente figura, que consta de dos conjuntos de entidades, cliente
y préstamo, relacionadas a través de un conjunto de
relaciones binarias prestatario. Los atributos asociados
con cliente son id-cliente, nombre-cliente, calle-cliente,
y ciudad-cliente. Los atributos asociados con préstamo
son número-préstamo e importe. Como se muestra
en la figura, los atributos de un conjunto de
entidades que son miembros de la clave primaria están
subrayados.
El conjunto de relaciones prestatario puede ser varios
a varios, uno a varios, varios a uno o uno a uno. Para
distinguir entre estos tipos, se dibuja o una línea dirigida
(→) o una línea no dirigida (—) entre el conjunto de
relaciones y el conjunto de entidades en cuestión.
• Una línea no dirigida desde el conjunto de relaciones prestatario al conjunto de relaciones préstamo especifica que prestatario es o bien un conjunto de relaciones varios a varios, o bien uno a
varios, desde cliente a préstamo. Volviendo al diagrama E-R de la figura anterior, se ve que el conjunto de relaciones prestatario es varios a varios.
Si el conjunto de relaciones prestatario fuera
uno a varios, desde cliente a préstamo, entonces la línea
desde prestatario a cliente sería dirigida, con una flecha
apuntando al conjunto de entidades cliente.
Si el conjunto de relaciones prestatario fuera varios a uno desde cliente a préstamo,
entonces la línea desde prestatario a préstamo tendría
una flecha apuntando al conjunto de entidades préstamo.
Diagrama E-R con un atributo unido a un conjunto de relaciones.
Diagrama E-R con atributos compuestos, multivalorados y derivados.
Diagrama E-R con indicadores de papeles.
Los conjuntos de relaciones no binarias se pueden
especificar fácilmente en un diagrama E-R. La siguiente figura consta de tres conjuntos de entidades cliente, trabajo
y sucursal, relacionados a través del conjunto de
relaciones trabaja-en.
Se pueden especificar algunos tipos de relaciones
varios a uno en el caso de conjuntos de relaciones no
binarias. Supóngase un empleado que tenga a lo sumo
un trabajo en cada sucursal (por ejemplo, Santos no puede
ser director y auditor en la misma sucursal). Esta restricción
se puede especificar con una flecha apuntando
a trabajo en el borde de trabaja-en.
Límites de cardinalidad en conjuntos de relaciones.
Veamos otra forma de poder representar las relaciones:
2.6 Conjunto de entidades débiles
Las entidades que hemos considerado
hasta ahora tienen un conjunto de atributos que forman su claves
primarias y que permiten identificarlas completamente. Estas entidades
se denominan, de forma más específica, entidades fuertes. En este subapartado consideraremos otro tipo de entidades que denominaremos entidades débiles.
Una entidad débil es una entidad
cuyos atributos no la identifican completamente, sino que sólo la
identifican de forma parcial. Esta entidad debe participar en una
interrelación que ayuda a identificarla.
Una entidad débil se representa con un rectángulo doble, y la interrelación que ayuda a identificarla se representa con una doble línea.
Una entidad débil se representa con un rectángulo doble, y la interrelación que ayuda a identificarla se representa con una doble línea.
Para que un conjunto de entidades débiles tenga sentido,
debe estar asociada con otro conjunto de entidades,
denominado el conjunto de entidades identificadoras
o propietarias. Cada entidad débil debe estar
asociada con una entidad identificadora; es decir, se dice
que el conjunto de entidades débiles depende existencialmente
del conjunto de entidades identificadoras. Se
dice que el conjunto de entidades identificadoras es propietaria
del conjunto de entidades débiles que identifica.
La relación que asocia el conjunto de entidades débiles
con el conjunto de entidades identificadoras se
denomina relación identificadora. La relación identificadora
es varios a uno del conjunto de entidades débiles
al conjunto de entidades identificadoras y la participación
del conjunto de entidades débiles en la relación
es total.
Ejemplo: Consideremos las entidades edificio y despacho de
la figura siguiente. Supongamos que puede haber despachos con el
mismo número en edificios diferentes. Entonces, su número no
identifica completamente un despacho. Para identificar completamente
un despacho, es necesario tener en cuenta en qué edificio está
situado. De hecho, podemos identificar un despacho mediante la
interrelación situación, que lo asocia a un único edificio. El nombre
del edificio donde está situado junto con el número de despacho lo
identifican completamente.
La interrelación situación nos
ha permitido completar la identificación de los despachos. Para toda
entidad débil, siempre debe haber una única interrelación que permita
completar su identificación. Esta interrelación debe ser binaria con
conectividad 1:N, y la entidad débil debe estar en el lado N. De este
modo, una ocurrencia de la entidad débil está asociada con una sola
ocurrencia de la entidad del lado 1, y será posible completar su
identificación de forma única. Además, la entidad del lado 1 debe ser
obligatoria en la interrelación porque, si no fuese así, alguna
ocurrencia de la entidad débil podría no estar interrelacionada con
ninguna de sus ocurrencias y no se podría identificar completamente.
Veamos y anilicemos el siguiente ejemplo:
El discriminante de un conjunto de entidades
débiles es un conjunto de atributos que permite
que sea distinguido. Por ejemplo, el discriminante
del conjunto de entidades débiles pago es el atributo
número-pago, ya que, para cada préstamo, un
número de pago identifica de forma única cada pago
para ese préstamo. El discriminante de un conjunto de
entidades débiles se denomina la clave parcial del conjunto
de entidades.
La clave primaria de un conjunto de entidades débiles
se forma con la clave primaria del conjunto de entidades
identificadoras, más el discriminante del conjunto
de entidades débiles. En el caso del conjunto de
entidades pago, su clave primaria es {número-préstamo,
número-pago}, donde número-préstamo es la clave
primaria del conjunto de entidades identificadoras,
es decir, préstamo, y número-pago distingue las entidades
pago dentro del mismo préstamo.
2.7 Modelo E-R extendido
En algunos casos, hay ocurrencias de
una entidad que tienen características propias específicas que nos
interesa modelizar. Por ejemplo, puede ocurrir que se quiera tener
constancia de qué coche de la empresa tienen asignado los empleados
que son directivos; también que, de los empleados técnicos, interese
tener una interrelación con una entidad proyecto que indique
en qué proyectos trabajan y se desee registrar su titulación.
Finalmente, que convenga conocer la antigüedad de los empleados
administrativos. Asímismo, habrá algunas características comunes a
todos los empleados: todos se identifican por un DNI, tienen un
nombre, un apellido, una dirección y un número de teléfono.
La generalización/especialización permite reflejar el hecho de que hay una entidad general, que denominamos entidad superclase, que se puede especializar en entidades subclase:
a) La entidad superclase nos permite modelizar las características comunes de la entidad vista de una forma genérica.
b) Las entidades subclase nos permiten modelizar las características propias de sus especializaciones.
Es necesario que se cumpla que toda ocurrencia de una entidad subclase sea también una ocurrencia de su entidad superclase.
Denotamos la generalización/especialización con una flecha que parte de las entidades subclase y que se dirige a la entidad superclase.
Ejemplo de entidades superclase y subclase
En la figura siguiente están representadas la entidad
superclase, que corresponde al empleado del ejemplo anterior, y las
entidades subclase, que corresponden al directivo, al técnico y al
administrativo del mismo ejemplo.
En la generalización/especialización, las
características (atributos o interrelaciones) de la entidad superclase
se propagan hacia las entidades subclase. Es lo que se denomina
herencia de propiedades.
En el diseño de una generalización/especialización, se puede seguir uno de los dos procesos siguientes:
1) Puede ocurrir que el diseñador
primero identifique la necesidad de la entidad superclase y,
posteriormente, reconozca las características específicas que hacen
necesarias las entidades subclase. En estos casos se dice que ha
seguido un proceso de especialización.
2) La alternativa es que el
diseñador modelice en primer lugar las entidades subclase y, después,
se dé cuenta de sus características comunes e identifique la en- tidad
superclase. Entonces se dice que ha seguido un proceso de
generalización.
La generalización/especialización puede ser de dos tipos:
a) Disjunta. En este caso no puede suceder que una
misma ocurrencia apa rezca en dos entidades subclase diferentes. Se
denota gráficamente con la etiqueta D.
b) Solapada. En este caso no tiene lugar la restricción anterior. Se denota gráficamente con la etiqueta S.
Además, una generalización/especialización también puede ser:
1) Total. En este caso, toda ocurrencia de la
entidad superclase debe pertenecer a alguna de las entidades subclase.
Esto se denota con la etiqueta T.
2) Parcial. En este caso no es necesario que se cumpla la condición anterior. Se denota con la etiqueta P.
La generalización/especialización de los empleados es total porque suponemos que todo empleado debe ser directivo, técnico o administrativo. Se denota con la etiqueta T.
Notaciones usadas en el Modelo E-R
Notaciones del Modelo E-R alternativas
Tarea: Lectura del tema 2.7
Características del modelo E-R Extendido del libro Fundamentos de Bases
de Datos de Abraham Silberschatz
2.8 Otros aspectos del diseño de bases de datos
Reducción de diagramas E-R a tablas
Un diagrama E-R, puede ser representado también a
través de una colección de tablas. Para cada una de las entidades y
relaciones existe una tabla única a la que se le asigna como nombre el
del conjunto de entidades y de las relaciones respectivamente, cada
tabla tiene un número de columnas que son definidas por la cantidad de
atributos y las cuales tienen el nombre del atributo.
La transformación de nuestro ejemplo Venta en la
que intervienen las entidades de Vendedor con los atributos RFC,
nombre, puesto, salario y Artículo con los atributos Clave,
descripción, costo.
Cuyo diagrama E-R es el siguiente:
Nótese que en la tabla de relación - Venta -,
contiene como atributos a las llaves primarias de las entidades que
intervienen en dicha relación, en caso de que exista un atributo en las
relaciones, este atributo es anexado como una fila más de la tabla.
Por ejemplo si anexamos el atributo fecha a la relación venta, la tabla que se originaria sería la siguiente:
Reglas que se deben seguir para poder crear dicho esquema.
Modelo e-r conversión a tablas
- una tabla por cada conjunto de entidades
- nombre de tabla = nombre de conjunto de entidades
- una tabla por cada conjunto de relaciones m-m
- nombre de tabla = nombre de conjunto de relaciones
- definición de columnas para cada tabla
- conjuntos fuertes de entidades
- columnas = nombre de atributos
- conjuntos débiles de entidades
- columnas = llave_primaria (dominante) U atributos(subordinado)
- conjunto de relaciones R (m-m) entre A, B
- columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R)
- conjunto de relaciones R (1-1) entre A y B
- columnas (A) = atribs(A) U llave primaria(B) U atributos(R)
- conjunto de relaciones R (1-m) entre A y B
- columnas (B) = atribs(B) U llave primaria(A) U atributos(R)
- conjuntos fuertes de entidades
2.9 La Notación E-R con UML
Los diagramas entidad-relación ayudan a modelar el
componente de representación de datos de un sistema
software. La representación de datos, sin embargo,
sólo forma parte de un diseño completo de un sistema.
Otros componentes son modelos de interacción
del usuario con el sistema, especificación de módulos
funcionales del sistema y su interacción, etc. El
lenguaje de modelado unificado (UML, Unified
Modeling Language) es un estándar propuesto para la
creación de especificaciones de varios componentes
de un sistema software. Algunas de las partes de UML
son:
Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R. Más adelante en este apartado se mostrarán algunas características de los diagramas de clase y cómo se corresponden con los diagramas E-R.
Diagrama de caso de uso. Los diagramas de caso de uso muestran la interacción entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario (tales como prestar dinero o matricularse de una asignatura).
Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre varios componentes de un sistema.
Diagrama de implementación. Los diagramas de implementación muestran los componentes del sistema y sus interconexiones tanto en el nivel del componente software como el hardware.
La figura siguiente muestra varios constructores de diagramas
E-R y sus constructores equivalentes de los
diagramas de clase UML. Más abajo se describen estos
constructores. UML muestra los conjuntos de entidades
como cuadros y, a diferencia de E-R, muestra los atributos
dentro del cuadro en lugar de como elipses separadas. UML modela realmente objetos, mientras que
E-R modela entidades. Los objetos son como entidades
y tienen atributos, pero además proporcionan un conjunto
de funciones (denominadas métodos) que se pueden
invocar para calcular valores en términos de los atributos
de los objetos, o para modificar el propio objeto.
Los diagramas de clase pueden describir métodos además
de atributos.
Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una línea que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de relaciones adyacente a la línea. También se puede especificar el papel que juega un conjunto de entidades en un conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto con los atributos del conjunto de relaciones, y conectar el cuadro con una línea discontinua a la línea que describe el conjunto de relaciones. Este cuadro se puede tratar entonces como un conjunto de entidades, de la misma forma que una agregación en los diagramas E-R puede participar en relaciones con otros conjuntos de entidades. La relaciones no binarias no se pueden representar directamente en UML se deben convertir en relaciones binarias (vease Apartado 2.4.3). Las restricciones de cardinalidad se especifican en UML de la misma forma que en los diagramas E-R, de la forma i..s, donde i denota el mínimo y s el máximo número de relaciones en que puede participar una entidad. Sin embargo, se debería ser consciente que la ubicación de las restricciones es exactamente el inverso de la ubicación de las restricciones en los diagramas E-R, como muestra la figura. La restricción 0..* en el lado E2 y 0..1 en el lado E1 significa que cada entidad.
no entendi bien lo ultimo pero despues me lo estudio por mi cuenta
ResponderEliminarMEJOR VETE ALV
EliminarLe respondiste un comentario a alguien de hace 9 años?
EliminarNo entendi nada, pero despues me lo estudio por mi cuenta
ResponderEliminar