INSTITUTO
TECNOLOGICO DE
LA ZONA OLMECA.
(ITZO)
ASIGNATURA:
Fundamentos de Base de Datos.
NOMBRE DEL TEMA:
Actividad 3: Investigación Documental de la Unidad 2.
SEMESTRE: 4to. GRUPO: “A”
TURNO:
Matutino
ALUMNO:
Gregorio López Castro
DOCENTE:
Ing. Omar Castro Castro.
Índice.
Introducción…………………………………………………………… Página 3.
2.1 El Proceso de Diseño……………………………………………. Página 4.
2.2 Modelo Entidad-Relación…………..……………………………. Página 7.
2.3 Diseño con diagramas E-R…………………………………..… Página 15.
2.4 Modelo E-R extendido………………………………………….. Página 20.
2.5 La Notación E-R con UML……….…………………………….. Página 27.
Conclusión…………………………………………………………… Página 31.
Referencias bibliográficas……………………………………………. Página 32.
Introducción.
En otras unidades didácticas se estudian las bases de datos relacionales y un
lenguaje relacional, SQL, que nos proporciona mecanismos para crear, actualizar
y consultar estas bases de datos, Es necesario complementar estos
conocimientos con un aspecto que es fundamental para poder utilizar
adecuadamente la tecnología de las bases de datos relacionales: el diseño, éste
será el objeto de estudio de esta unidad, que tratará el diseño de bases de datos
para el caso específico del modelo relacional.
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 más 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.
El modelo E-R se basa en una percepción del mundo real, la cual está formada
por objetos básicos llamados entidades y las relaciones entre estos objetos así
como las características de estos objetos llamados atributos.
Entidades y conjunto de entidades
Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a
sus características llamadas atributos . Las entidades pueden ser concretas como
una persona o abstractas como una fecha.
Un conjunto de entidades es un grupo de entidades del mismo tipo. Por ejemplo
el conjunto de entidades CUENTA, podría representar al conjunto de cuentas de
un banco X, o ALUMNO representa a un conjunto de entidades de todos los
alumnos que existen en una institución.
Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones
llamadas propiedades, que representan las características de una entidad.
Los atributos de una entidad pueden tomar un conjunto de valores permitidos al
que se le conoce como dominio del atributo. Así cada entidad se describe por
medio de un conjunto de parejas formadas por el atributo y el valor de dato.
Habrá una pareja para cada atributo del conjunto de entidades.
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 pré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.
Relaciones y conjunto de relaciones.
Una relación es la asociación que existe entre dos a más entidades.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo.
La cantidad de entidades en una relación determina el grado de la relación, por
ejemplo la relación ALUMNO-MATERIA es de grado 2, ya que intervienen la
entidad ALUMNO y la entidad MATERIA, la relación PADRES, puede ser de grado
3, ya que involucra las entidades PADRE, MADRE e HIJO.
Aunque el modelo E-R permite relaciones de cualquier grado, la mayoría de las
aplicaciones del modelo sólo consideran relaciones del grado 2. Cuando son de tal
tipo, se denominan relaciones binarias.
La función que tiene una relación se llama papel, generalmente no se especifican
los papeles o roles, a menos que se quiera aclarar el significado de una relación.
Diagrama E-R (sin considerar los atributos, sólo las entidades) para los modelos
ejemplificados:
Limitantes de mapeo.
Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales
establecen con cuantas entidades de tipo B se pueden relacionar una entidad de
tipo A:
Tipos de relaciones:
Relación uno a uno.
Se presenta cuando existe una relación como su nombre lo indica uno a
uno, denominado también relación de matrimonio. Una entidad del tipo A
solo se puede relacionar con una entidad del tipo B, y viceversa;
Por ejemplo: la relación asignación de automóvil que contiene a las entidades
EMPLEADO, AUTO, es una relación 1 a 1, ya que asocia a un empleado con un
único automóvil por lo tanto ningún empleado posee más de un automóvil
asignado, y ningún vehículo se asigna a más de un trabajador.
Es representado gráficamente de la siguiente manera:
A: Representa a una entidad de cualquier tipo diferente a una entidad B.
R: en el diagrama representa a la relación que existe entre las entidades.
El extremo de la flecha que se encuentra punteada indica el uno de la relación, en
este caso, una entidad A ligada a una entidad B.
Relación uno a muchos.
Significa que una entidad del tipo A puede relacionarse con cualquier
cantidad de entidades del tipo B, y una entidad del tipo B solo puede estar
relacionada con una entidad del tipo A.
Su representación gráfica es la siguiente:
Nótese en este caso que el extremo punteado de la flecha de la relación de A y B,
indica una entidad A conectada a muchas entidades B.
Muchos a uno.
Indica que una entidad del tipo B puede relacionarse con cualquier cantidad
de entidades del tipo A, mientras que cada entidad del tipo A solo puede
relacionarse con solo una entidad del tipo B.
Muchas a muchas.
Establece que cualquier cantidad de entidades del tipo A pueden estar
relacionados con cualquier cantidad de entidades del tipo B.
A los tipos de relaciones antes descritos, también se le conoce
como cardinalidad.
La cardinalidad nos especifica los tipos de relaciones que existen entre las
entidades en el modelo E-R y establecer con esto las validaciones necesarias para
conseguir que los datos de la instancia (valor único en un momento dado de una
base de datos) correspondan con la realidad.
Algunos ejemplos de cardinalidades de la vida común pueden ser:
Uno a uno.
El noviazgo, el RFC de cada persona, El CURP personal, El acta de nacimiento,
ya que solo existe un solo documento de este tipo para cada una de las diferentes
personas.
Uno a muchos.
Cliente – Cuenta en un banco, Padre-Hijos, Camión-Pasajeros, zoológico-
animales, árbol – hojas.
Muchos a muchos.
Arquitecto – proyectos, fiesta – personas, estudiante – materias.
NOTA: Cabe mencionar que la cardinalidad para cada conjunto de entidades
depende del punto de vista que se le dé al modelo en estudio, claro está,
sujetándose a la realidad.
Otra clase de limitantes lo constituye la dependencia de existencia.
Refiriéndonos a las mismas entidades A y B, decimos que si la entidad A depende
de la existencia de la entidad B, entonces A es dependiente de existencia por B, si
eliminamos a B tendríamos que eliminar por consecuente la entidad A, en este
caso B es la entidad Dominante y A es la entidad subordinada.
Llaves primarias.
Como ya se ha mencionado anteriormente, la distinción de una entidad entre otra
se debe a sus atributos, lo cual lo hacen único. Una llave primaria es aquel
atributo el cual consideramos llave para la identificación de los demás atributos
que describen a la entidad. Por ejemplo, si consideramos la entidad ALUMNO del
Instituto Tecnológico de La Paz, podríamos tener los siguientes atributos: Nombre,
Semestre, Especialidad, Dirección, Teléfono, Número de control, de todos estos
atributos el que podremos designar como llave primaria es el número de control,
ya que es diferente para cada alumno y este nos identifica en la institución.
Claro que puede haber más de un atributo que pueda identificarse como llave
primaria en este caso se selecciona la que consideremos más importante, los
demás atributos son denominados llaves secundarias.
Una llave o llave primaria es indicada gráficamente en el modelo E-R con una
línea debajo del nombre del atributo.
Diagrama Entidad-Relación
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a
través de un esquema gráfico empleando la terminología de entidades, que son
objetos que existen y son los elementos principales que se identifican en el
problema a resolver con el diagramado y se distinguen de otros por sus
características particulares denominadas atributos, el enlace que rige la unión de
las entidades está representada por la relación del modelo.
Recordemos que un rectángulo nos representa a las entidades; una elipse a los
atributos de las entidades, y una etiqueta dentro de un rombo nos indica la
relación que existe entre las entidades, destacando con líneas las uniones de
estas y que la llave primaria de una entidad es aquel atributo que se encuentra
subrayado.
A continuación mostraremos algunos ejemplos de modelos E-R, considerando las
cardinalidades que existen entre ellos:
Relación Uno a Uno.
Problema:
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en
obtener la tarjeta de circulación de un automóvil con los siguientes datos:-
Automóvil- Modelo, Placas, Color - Tarjeta de circulación -Propietario, No_serie,
Tipo.
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno,
ya que existe una tarjeta de circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país.
Relación muchos a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que
una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que
existen cuentas registradas a favor de más de una persona).
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 Llave, descripción, costo.
Cuyo diagrama E-R es el siguiente:
2.3 Diseño con diagramas E-R.
La estructura lógica de una Base de Datos se puede representar gráficamente 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 pueden 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 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.4 Modelo E-R extendido.
Se trata de una técnica cuyo objetivo es la representación y definición de todos los
datos que se introducen, almacenan, transforman y producen dentro de un
sistema de información, sin tener en cuenta las necesidades de la tecnología
existente, ni otras restricciones.
Dado que el modelo de datos es un medio para comunicar el significado de los
datos, las relaciones entre ellos y las reglas de negocio de un sistema de
información, una organización puede obtener numerosos beneficios de la
aplicación de esta técnica, pues la definición de los datos y la manera en que
estos operan son compartidos por todos los usuarios.
Las ventajas de realizar un modelo de datos son, entre otras:
Comprensión de los datos de una organización y del funcionamiento de la
organización.
Obtención de estructuras de datos independientes del entorno físico.
Control de los posibles errores desde el principio, o al menos, darse cuenta
de las deficiencias lo antes posible.
Mejora del mantenimiento.
Aunque la estructura de datos puede ser cambiante y dinámica, normalmente es
mucho más estable que la estructura de procesos. Como resultado, una estructura
de datos estable e integrada proporciona datos consistentes que puedan ser
fácilmente accesibles según las necesidades de los usuarios, de manera que,
aunque se produzcan cambios organizativos, los datos permanecerán estables.
Este diagrama se centra en los datos, independientemente del procesamiento que
los transforma y sin entrar en consideraciones de eficiencia. Por ello, es
independiente del entorno físico y debe ser una fiel representación del sistema de
información objeto del estudio, proporcionando a los usuarios toda la información
que necesiten y en la forma en que la necesiten.
Descripción
El modelo entidad/relación extendida describe con un alto nivel de abstracción la
distribución de datos almacenados en un sistema. Existen dos elementos
principales: las entidades y las relaciones. Las extensiones al modelo básico
añaden además los atributos de las entidades y la jerarquía entre estas. Estas
extensiones tienen como finalidad aportar al modelo una mayor capacidad
expresiva.
Los elementos fundamentales del modelo son los siguientes:
Entidad
Es aquel objeto, real o abstracto, acerca del cual se desea almacenar información
en la base de datos. La estructura genérica de un conjunto de entidades con las
mismas características se denomina tipo de entidad.
Existen dos clases de entidades: regulares, que tienen existencia por sí mismas, y
débiles cuya existencia depende de otra entidad. Las entidades deben cumplir las
siguientes tres reglas:
Tienen que tener existencia propia.
Cada ocurrencia de un tipo de entidad debe poder distinguirse de las
demás.
Todas las ocurrencias de un tipo de entidad deben tener los mismos
atributos.
Relación
Es una asociación o correspondencia existente entre una o varias entidades. La
relación puede ser regular, si asocia tipos de entidad regulares, o débil, si asocia
un tipo de entidad débil con un tipo de entidad regular. Dentro de las relaciones
débiles se distinguen la dependencia en existencia y la dependencia en
identificación.
Se dice que la dependencia es en existencia cuando las ocurrencias de un tipo de
entidad débil no pueden existir sin la ocurrencia de la entidad regular de la que
dependen. Se dice que la dependencia es en identificación cuando, además de lo
anterior, las ocurrencias del tipo de entidad débil no se pueden identificar solo
mediante sus propios atributos, sino que se les tiene que añadir el identificador de
la ocurrencia de la entidad regular de la cual dependen.
Además, se dice que una relación es exclusiva cuando la existencia de una
relación entre dos tipos de entidades implica la no existencia de las otras
relaciones.
Una relación se caracteriza por:
Nombre: que lo distingue unívocamente del resto de relaciones del modelo.
Tipo de correspondencia: es el número máximo de ocurrencias de cada
tipo de entidad que pueden intervenir en una ocurrencia de la relación que
se está́ tratando.
Conceptualmente se pueden identificar tres clases de relaciones:
Relaciones [Link] Cada ocurrencia de una entidad se relaciona con
una y solo una ocurrencia de la otra entidad.
Relaciones 1:N: Cada ocurrencia de una entidad puede estar
relacionada con cero, una o varias ocurrencias de la otra entidad.
Relaciones M:N: Cada ocurrencia de una entidad puede estar
relacionada con cero, una o varias ocurrencias de la otra entidad y
cada ocurrencia de la otra entidad puede corresponder a cero, una o
varias ocurrencias de la primera.
Cardinalidad: representa la participación en la relación de cada una de las
entidades afectadas, es decir, el número máximo y mínimo de ocurrencias
de un tipo de entidad que pueden estar interrelacionadas con una
ocurrencia de otro tipo de entidad. La cardinalidad máxima coincide con el
tipo de correspondencia.
Según la cardinalidad, una relación es obligatoria, cuando para toda ocurrencia de
un tipo de entidad existe al menos una ocurrencia del tipo de entidad asociado, y
es opcional cuando, para toda ocurrencia de un tipo de entidad, puede existir o no
una o varias ocurrencias del tipo de entidad asociado.
Dominio
Es un conjunto nominado de valores homogéneos. El dominio tiene existencia
propia con independencia de cualquier entidad, relación o atributo.
Atributo
Es una propiedad o característica de un tipo de entidad. Se trata de la unidad
básica de información que sirve para identificar o describir la entidad. Un atributo
se define sobre un dominio. Cada tipo de entidad ha de tener un conjunto mínimo
de atributos que identifiquen unívocamente cada ocurrencia del tipo de entidad.
Este atributo o atributos se denomina identificador principal. Se pueden definir
restricciones sobre los atributos, según las cuales un atributo puede ser:
Univaluado, atributo que solo puede tomar un valor para todas y cada una
de las ocurrencias del tipo de entidad al que pertenece.
Obligatorio, atributo que tiene que tomar al menos un valor para todas y
cada una de las ocurrencias del tipo de entidad al que pertenece.
Además de estos elementos, existen extensiones del modelo entidad/relación que
incorporan determinados conceptos o mecanismos de abstracción para facilitar la
representación de ciertas estructuras del mundo real:
La generalización, permite abstraer un tipo de entidad de nivel superior
(supertipo) a partir de varios tipos de entidad (subtipos); en estos casos los
atributos comunes y relaciones de los subtipos se asignan al supertipo. Se
pueden generalizar por ejemplo los tipos profesor y estudiante obteniendo
el supertipo persona.
La especialización es la operación inversa a la generalización, en ella un
supertipo se descompone en uno o varios subtipos, los cuales heredan
todos los atributos y relaciones del supertipo, además de tener los suyos
propios. Un ejemplo es el caso del tipo empleado, del que se pueden
obtener los subtipos secretaria, técnico e ingeniero.
Categorías. Se denomina categoría al subtipo que aparece como resultado
de la unión de varios tipos de entidad. En este caso, hay varios supertipo y
un solo subtipo. Si por ejemplo se tienen los tipos persona y compañía y es
necesario establecer una relación con vehículo, se puede
crear propietario como un subtipo unión de los dos primeros.
La agregación, consiste en construir un nuevo tipo de entidad como
composición de otros y su tipo de relación y así poder manejarlo en un nivel
de abstracción mayor. Por ejemplo, se tienen los tipos de
entidad empresa y solicitante de empleo relacionados mediante el tipo de
relación entrevista; pero es necesario que cada entrevista se corresponda
con una determinada oferta de empleo. Como no se permite la relación
entre tipos de relación, se puede crear un tipo de entidad compuesto
por empresa, entrevista y solicitante de empleo y relacionarla con el tipo de
entidad oferta de empleo. El proceso inverso se denomina desagregación.
La asociación, consiste en relacionar dos tipos de entidades que
normalmente son de dominios independientes, pero coyunturalmente se
asocian.
La existencia de supertipo y subtipos, en uno o varios niveles, da lugar a
una jerarquía, que permitirá́ representar una restricción del mundo real.
Una vez construido el modelo entidad/relación, hay que analizar si se presentan
redundancias. Para poder asegurar su existencia se deben estudiar con mucho
detenimiento las cardinalidades mínimas de las entidades, así como la semántica
de las relaciones.
Los atributos redundantes, los que se derivan de otros elementos mediante algún
calculo, deben ser eliminados del modelo entidad/relación o marcarse como
redundantes.
Igualmente, las relaciones redundantes deben eliminarse del modelo,
comprobando que al eliminarlas sigue siendo posible el paso, tanto en un sentido
como en el inverso, entre las dos entidades que unían.
Notación
Entidad
La representación gráfica de un tipo de entidad regular es un rectángulo
etiquetado con el nombre del tipo de entidad. Un tipo de entidad débil se
representa con dos rectángulos concéntricos con su nombre en el interior.
Relación
Se representa por un rombo unido a las entidades relacionadas por dos líneas
rectas a los lados. El tipo de correspondencia se representa gráficamente con una
etiqueta 1:1, 1:N o M:N, cerca de alguno de los vértices del rombo, o bien situando
cada número o letra cerca de la entidad correspondiente, para mayor claridad.
La representación gráfica de las cardinalidades se realiza mediante una etiqueta
del tipo (0,1), (1,1), (0,n) o (1,n), que se coloca en el extremo de la entidad que
corresponda. Si se representan las cardinalidades, la representación del tipo de
correspondencia es redundante.
Atributo
Un atributo se representa mediante una elipse, con su nombre dentro, conectada
por una línea al tipo de entidad o relación.
En lugar de una elipse puede utilizarse un círculo con el nombre dentro, o un
círculo más pequeño con el nombre del atributo a un lado. También pueden
representarse en una lista asociada a la entidad. El identificador aparece con el
nombre marcado o subrayado, o bien con su círculo en negro.
Exclusividad
En la representación de las relaciones exclusivas se incluye un arco sobre las
líneas que conectan el tipo de entidad a los dos o más tipos de relación.
Jerarquía (tipos y subtipos)
La representación de las jerarquías se realiza mediante un triángulo invertido, con
la base paralela al rectángulo que representa el supertipo y conectando a este y a
los subtipos. Si la division en subtipos viene determinada en función de los valores
de un atributo discriminante, este se representará asociado al triangulo que
representa la relación.
En el triángulo se representará: con una letra del hecho de que los subtipos sean
disjuntos, con un círculo o una O si los subtipos pueden solaparse y con una U el
caso de uniones por categorías. La presencia de una jerarquía total se representa
con una doble línea entre el supertipo y el triángulo.
2.5 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.
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.
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.
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y
diagramas estándar para modelar sistemas orientados a objetos, y describe la
semántica esencial de lo que estos diagramas y símbolos significan. Mientras que
ha habido muchas notaciones y métodos usados para el diseño orientado a
objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos ’business’.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboración para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el
sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de
Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura estática de las clases en el
sistema.
Diagramas de Objetos para modelar la estructura estática de los objetos en
el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usadas
orientados a objetos.
Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh,
e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más
populares.
En 1996, el Object Management Group (OMG), un pilar estándar para la
comunidad del diseño orientado a objetos, publicó una petición con propósito de
un meta modelo orientado a objetos de semántica y notación estándares. UML, en
su versión 1.0, fue propuesto como una respuesta a esta petición en enero de
1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis
promotores de las propuestas, unieron su trabajo y presentaron al OMG un
documento revisado de UML, El OMG llama a este documento OMG UML versión
1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta
especificación, prevista su finalización para el 1 de abril de 1999.
UML ofrece notación y semántica estándar:
UML prescribe una notación estándar y semánticas esenciales para el modelado
de un sistema orientado a objetos. Previamente, un diseño orientado a objetos
podría haber sido modelado con cualquiera de la docena de metodologías
populares, causando a los revisores tener que aprender las semánticas y
notaciones de la metodología empleada antes que intentar entender el diseño en
sí. Ahora con UML,
UML no es un Método:
Aun así, UML no prescribe un proceso o método estándar para desarrollar un
sistema. Hay varias metodologías existentes; entre las más populares se incluyen
las siguientes:
Catalysis: Un método orientado a objetos que fusiona mucho del trabajo
reciente en métodos orientados a objetos, y además ofrece técnicas
específicas para modelar componentes distribuidos.
Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por
Ivar Jacobson.
Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en
marcha por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de
vida de Objetos, modelando el Mundo en Estados y Ciclos de vida de
Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor
continúan actualizando su método continuamente (la actualización más
reciente es el OOA96 report), y recientemente publicaron una guía sobre
cómo usar la notación UML con Shlaer/Mellor.
Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como
primer intento de un método de diseño orientado a objetos estándar.
Combina OMT y Booch con tarjetas CRC y métodos formales.
OMT: La Técnica de Modelado de Objetos fue desarrollada por James
Rumbaugh y otros, y publicada en el libro de gran influencia "Diseño y
Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que
propone análisis y diseño ’iterative’, más centrado en el lado del análisis.
Booch: Parecido al OMT, y también muy popular, la primera y segunda
edición de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamín
Cummings, 1991 y 1994), (Object-Oriented Design, With Applications),
detallan un método ofreciendo también diseño y análisis ’iterative’,
centrándose en el lado del diseño.
Además, muchas organizaciones han desarrollado sus propias metodologías
internas, usando diferentes diagramas y técnicas con orígenes varios.
Extensiones UML:
Los mecanismos de extensibilidad incorporados permiten a UML ser una especie
de especificación abierta que puede cubrir aspectos de modelado no
especificados en el documento 1.1. Estos mecanismos permiten extender la
notación y semántica de UML.
Estereotipos:
Los estereotipos son el mecanismo de extensibilidad incorporado más utilizado
dentro de UML. Un estereotipo representa una distinción de uso. Puede ser
aplicado a cualquier elemento de modelado, incluyendo clases, paquetes,
relaciones de herencia, etc. Por ejemplo, una clase con estereotipo ’actor’ es una
clase usada como un agente externo en el modelado de negocio. Una clase patrón
es modelada como una clase con estereotipo parametrizado, lo que significa que
puede contener parámetros.
Extensiones de Modelado de Negocio:
Un documento separado dentro de la especificación UML define clases y
estereotipos de asociación específicos que extienden UML hasta cubrir conceptos
de modelado de negocio. Esto incluye ’stereotyping’ una clase como un actor, un
trabajador (’both internal and case’), o una entidad, y ’stereotyping’ una asociación
como una comunicación simple, o una suscripción entre un origen y un objetivo.
Lenguaje restrictivo (constraint) de objetos (OCL):
Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico
puede describir una cierta parte del comportamiento, después de la cual es
necesario rellenar detalles adicionales con palabras. Describiendo algo con
palabras, sin embargo, casi siempre desemboca en ambigüedades. (OCL) está
incorporado en UML como un estándar para especificar detalles adicionales, o
precisar detalles en la estructura de los modelos.
Conclusión.
El modelo entidad-relación ER es un modelo de datos que permite representar
cualquier abstracción, percepción y conocimiento en un sistema de información
formado por un conjunto de objetos denominados entidades y relaciones,
incorporando una representación visual conocida como diagrama entidad relación.
Referencias bibliográficas.
Completo, V. mi P. (s/f). UNIDAD 2 DISEÑO DE BADES DE DATOS CON
MODELOS E-R. [Link]. Recuperado el 20 de febrero de 2023, de
[Link]
[Link]
La Notación E-R con UML. (s/f). [Link]. Recuperado el 20 de
febrero de 2023, de [Link]
de-bases-de-datos/421/la-notacion-e-r-con-uml-
León, E., & Perfil, V. T. mi. (s/f). Fundamentos de Bases de Datos.
[Link]. Recuperado el 20 de febrero de 2023, de
[Link]
Modelo Entidad-Relación. (s/f). [Link]. Recuperado el 20 de febrero de
2023, de [Link]
polilibros/Base%20de%20Datos%20I/Contenido/2_2_Modelo_ER.htm
Modelo Entidad/Relación Extendido. (2013, noviembre 18).
[Link]; Manuel Cillero.
[Link]
entidad-relacion-extendido/
Perfil, V. T. mi. (s/f). Fundamentos de Base de Datos. [Link].
Recuperado el 20 de febrero de 2023, de
[Link]