Fundamentos de Bases de Datos

Página principal Unidad I Unidad II Unidad III Unidad IV Unidad V Unidad VI

Unidad II Archivo del blog

▼ 2012 (1)
2.1 El Proceso de Diseño ▼ agosto (1)
Instituto Tecnológico de
"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 Pachuca/Presentación
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
Datos personales
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
Eric Leon
general de los informáticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de
programación convencional." Ver todo mi perfil
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.

Div idir 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.

Conv ertir 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 clav es 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.

Aj ustar 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

[Link] 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 conj unto de v alores, 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

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.

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.

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 conj untos 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.

Tiempo de TAREA, ups!!!!!!!, rev isar 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).
- Monov alorados o Univ alorados: Atributo que toma un solo valor, para una entidad en particular.
- Multiv alorados: Atributo que para una misma entidad puede tomar muchos valores.
- Deriv ados 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 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 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.

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

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.

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 clav e 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.

Observe el siguiente modelo E-R y analicelo:

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

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.

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 conv ersió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)

Lectura del tema 2.9 Reducción de un esquema E-R a Tablas, del libro Fundamentos de Bases de Datos de Abraham
Silberschatz.

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.

4 comentarios:

Jesus Figueroa (Shadow Myst) 23 de marzo de 2013, 18:25

no entendi bien lo ultimo pero despues me lo estudio por mi cuenta

Responder

Respuestas

Unknown 11 de marzo de 2022, 21:53

MEJOR VETE ALV

LuisRComentarP 8 de marzo de 2023, 7:40

Le respondiste un comentario a alguien de hace 9 años?

Responder

Unknown 30 de enero de 2016, 15:32

No entendi nada, pero despues me lo estudio por mi cuenta

Responder

Inicio

Suscribirse a: Entradas (Atom)

Tema Fantástico, S.A.. Con la tecnología de Blogger.