ACRÓNIMO DE PARÍS PARA SU OLIMPIADA 2024. Por JAVIER SOLIS NOYOLA
Modelamiento de-entidad relacion
1. “Año de la Consolidación del Mar de Grau”
TEMA: MODELAMIENTO ENTIDAD-RELACIÒN (ER)
INTEGRANTES:
LEON RUIZ ANTHONY MARCOS.
BAZAN GARCIA LEYLA PAOLA.
CURSO: MODELAMIENTO DE BASE DE DATOS.
DOCENTE: PORRO CHULLI MARCO
2. Modelo Entidad-Relación
DEFINICION:
• El Modelo Entidad-Relación
• Se elabora el diagrama (o diagramas) entidad-relación.
• Se completa el modelo con listas de atributos y una descripción de otras restricciones que
no se pueden reflejar en el diagrama.
• El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas
para lograr un modelo directamente implementable en una base de datos. Brevemente:
• Permite mostrar resultados entre otras entidades pertenecientes a las existentes de
manera que se encuentre la normatividad de archivos que se almacenarán
• Transformación de relaciones múltiples en binarias.
• Normalización de una base de datos de relaciones (algunas relaciones pueden
transformarse en atributos y viceversa).
• Conversión en tablas (en caso de utilizar una base de datos relacional).
3. TIPOS DE ENTIDAD:
• El Modelo de Datos Entidad-Relación (E/R)
• Cuando se utiliza una base de datos para gestionar información, se está
plasmando una parte del mundo real en una serie de tablas, registros y
campos ubicados en un ordenador; creándose un modelo parcial de la
realidad. Antes de crear físicamente estas tablas en el ordenador se debe
realizar un modelo de datos.
• Se suele cometer el error de ir creando nuevas tablas a medida que se van
necesitando, haciendo así el modelo de datos y la construcción física de las
tablas simultáneamente. El resultado de esto acaba siendo un sistema de
información parcheado, con datos dispersos que terminan por no cumplir
adecuadamente los requisitos necesarios.
4. Entidades y Relaciones
• El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el
modelo E/R se parte de una situación real a partir de la cual se
definen entidades y relaciones entre dichas entidades:
• Entidad.- Objeto del mundo real sobre el que queremos almacenar información ( Ej: una
persona). Las entidades están compuestas de atributos que son los datos que definen el
objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los
atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de
atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En
toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por
todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una,
lo haremos atendiendo a estas normas:
• Que sea única.
• Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada
cliente un número de cliente?
• Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
5. Relación.- Asociación entre entidades, sin existencia propia en el mundo real que
estamos modelando, pero necesaria para reflejar las interacciones existentes
entre entidades. Las relaciones pueden ser de tres tipos:
Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a
una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación
MATRIMONIO).
Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n)
de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la
relación TRABAJAR-EN).
Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la
relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la
entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).
6. Representación gráfica de Entidades y Relaciones
Para asimilar fácilmente un diseño de datos cuando se emplea el modelo
E/R se utilizan los siguientes elementos gráficos:
7. La utilización de estos elementos dará como resultado lo que se denomina
el esquema entidad-relación de la base de datos. Los ejemplos que se incluyen en el
apartado anterior, gráficamente quedarían como sigue:
8. ¿Cómo se pasa del esquema E/R a las tablas?
Para cada entidad del esquema se creará una tabla con tantos campos como atributos
tenga la entidad. Ejemplo:
Tabla 'TRABAJADOR'
DNI NUM_SS nombre-apellidos ...
11111111 XXXXXXXXXXX Fulano de tal ...
22222222 YYYYYYYYYYY Mengano de cual ...
...... ...... ...... ......
9. Las relaciones 1-1 se pueden reflejar incluyendo en una de las dos tablas un campo
en el que poder colocar la clave del elemento de la otra tabla con el que se está
relacionado. Ese nuevo campo que se incluye en la tabla recibe el nombre de clave
ajena. Ejemplo:
DNI Nombre ...
11111111 ... ...
22222222 ... ...
... ... ...
DNI Nombre ... DNI-ESPOSO
33333333 ... ... 11111111
44444444 ... ... (nulo)
... ... ... ...
10. Tabla Asignatura
Y la entidad Asignatura definida como:
Tabla Matricula
Y sabiendo que un alumno se puede matricular de muchas asignaturas y que una asignatura a su vez
puede tener muchos alumnos matriculados, podemos definir entre ambas entidades la relación (n-m)
matricula como:
Y la tabla quedaría como:
14. Y por último sólo falta arrastrar los campos relacionados de la tabla con la relación 1 a la tabla
con la relación muchos, es decir crear las relaciones, en las que seleccionaremos siempre:
Exigir Integridad Referencial
Actualizar en cascada los campos relacionados
Eliminar en cascada los registros relacionados
En el caso de Alumno-Matricula (1 Alumno. DNI se puede repetir n veces en Matricula. DNI)
arrastramos el Alumno. DNI sobre la Matricula. DNI:
Y si repetimos la misma operación entre Asignatura. Código y Matricula.Codigo_asig queda el
esquema E-R en Access según se muestra en la figura siguiente:
15.
16. ATRIBUTOS:
Los atributos son las características que definen o identifican a una entidad.
Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que
considere más relevantes.
En un conjunto de entidades del mismo tipo, cada entidad
tiene valores específicos asignados para cada uno de sus atributos, de esta
forma, es posible su identificación unívoca.
Ejemplos:
A la colección de entidades «alumnos», con el siguiente conjunto de atributos
en común, (id, nombre, edad, semestre), pertenecen las entidades:
(1, Sophia, 15 años, 2)
(2, Josefa, 19 años, 5)
(3, Carlos, 20 años, 2)
Cada una de las entidades pertenecientes a este conjunto se diferencia de las
demás por el valor de sus atributos. Nótese que dos o más entidades
diferentes pueden tener los mismos valores para algunos de sus atributos,
pero nunca para todos.
17. Entidades fuertes y débiles
Cuando una entidad participa en una relación puede adquirir un
papel fuerte o débil. Una entidad débil es aquella que no puede existir sin
participar en la relación; es decir, aquella que no puede ser unívocamente
identificada solamente por sus atributos.
Una entidad fuerte (también conocida como entidad regular) es aquella que
sí puede ser identificada unívocamente. En los casos en que se requiera, se
puede dar que una entidad fuerte "preste" algunos de sus atributos a una
entidad débil para que esta última se pueda identificar.
Las entidades débiles se representan mediante un doble rectángulo; es
decir, un rectángulo con doble línea.
Se puede hablar de la existencia de 2 tipos de dependencias en las
entidades débiles:
18. Dependencia por existencia
Las ocurrencias de la entidad débil pueden identificarse mediante
un atributo identificador clave sin necesidad de identificar la
entidad fuerte relacionada.
Dependencia por identidad
La entidad débil no puede ser identificada sin la entidad fuerte
relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra
relacionada EDICIÓN, para identificar una edición necesitamos
conocer el identificador del libro).
19. Cardinalidad de las relaciones
Cardinalidad es el número de entidades con la cual otra entidad puede asociar mediante
una relación binaria; la cardinalidad puede ser: Uno a uno, uno a muchos ó muchos a uno y
muchos a muchos. El tipo de cardinalidad se representa mediante una etiqueta en el
exterior de la relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende
del lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de
expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad
con una relación:
"0" si cada instancia de la entidad no está obligada a participar en la relación.
"1" si toda instancia de la entidad está obligada a participar en la relación y, además,
solamente participa una vez.
"N”, "M", o "*" si cada instancia de la entidad no está obligada a participar en la relación
y puede hacerlo cualquier número de veces.
20. Ejemplos de relaciones que expresan cardinalidad:
Un policía (entidad) tiene (relación) un arma (entidad) siempre y cuando
no realice funciones de oficina, pudiendo entonces tenerla o no asignada.
Es una relación 0:1.
Cada esposo (entidad) está casado (relación) con una única esposa
(entidad) y viceversa. Es una relación 1:1.
Una factura (entidad) se emite (relación) a una persona (entidad) y sólo
una, pero una persona puede tener varias facturas emitidas a su nombre.
Todas las facturas se emiten a nombre de alguien. Es una relación 1:N.
Un cliente (entidad) puede comprar (relación) varios servicios (entidad) y
un servicio puede ser comprado por varios clientes distintos. Es una
relación N:M.
21. Atributos en relaciones
Las relaciones también pueden tener atributos asociados. Se
representan igual que los atributos de las entidades. Un
ejemplo típico son las relaciones de tipo "histórico" donde debe
constar una fecha o una hora. Por ejemplo, supongamos que
es necesario hacer constar la fecha de emisión de una factura
a un cliente, y que es posible emitir duplicados de la factura
(con distinta fecha). En tal caso, el atributo "Fecha de emisión"
de la factura debería colocarse en la relación "se emite".
22. Herencia
La herencia es un intento de adaptación de estos diagramas al
paradigma orientado a objetos. La herencia es un tipo de
relación entre una entidad "padre" y una entidad "hijo". La
entidad "hijo" hereda todos los atributos y relaciones de la
entidad "padre". Por tanto, no necesitan ser representadas dos
veces en el diagrama. La relación de herencia se representa
mediante un triángulo interconectado por líneas a las
entidades. La entidad conectada por el vértice superior del
triángulo es la entidad "padre". Solamente puede existir una
entidad "padre" (herencia simple). Las entidades "hijo" se
conectan por la base del triángulo.
24. Ejemplo agregación
Es una abstracción a través de la cual las relaciones se
tratan como entidades de un nivel más alto. Se utiliza para
expresar relaciones entre relaciones o entre entidades y
relaciones. Se representa englobando la relación abstraída
y las entidades que participan en ella en un rectángulo. En
la figura se muestra un ejemplo de agregación en el que se
representa la situación en la que un profesor, cuando está
impartiendo una clase, puede poner una incidencia ocurrida
a lo largo de ésta (se fue la luz, falta la configuración de un
determinado software, etc.).
25. RESUMEN:
Existen muchos tipos de restricciones de
Integridad que pueden ser expresados en
ER:
Restricciones de claves
Restricciones de participación
Algunas restricciones, en particular,
Dependencias funcionales no pueden ser
Expresadas en el modelo ER
Modelos ER son subjetivos
Esquema relacional resultante debe ser
Analizado y refinado. Información de
Dependencias funcionales y técnicas de
Normalización son muy útiles para ello.
26. RECOMENDACIONES:
1. Haga un análisis adecuado y diseñe en etapas tempranas
Se recomienda tener en cuenta todas las limitaciones, las
posibilidades de integración y el diseño adecuado para el modelado
de datos (en análisis y en las fases de diseño de la implementación
del proyecto).
2. Siempre mapee sus atributos y relaciones de Bizagi
(considerar las referencias a las claves compuestas)
Es estrictamente requerido mapear los atributos a los
campos en la fuente externa (los que usted va a utilizar).
Tenga en cuenta que las relaciones creadas en Bizagi
también deben ser mapeadas.
27. Para terminar no olvidemos que ésta sólo es una
metáfora visual, no sólo es cuestión de tirar caños
entre cualquier par de entidades. Aquí se acaba la
metáfora, como dijimos desde un principio es un
modelo semántico y para que el caño sea viable
debe haber un verbo o acción que lo justifique y le
dé sentido.
CONCLUSIONES:
28. APRECIACION DEL EQUIPO:
Si no tuve éxito, espero que la metáfora del agua
les ayude a visualizar rápidamente las
posibilidades de ejecutar una consulta en un
modelo existente o deficiencias de información.
Es sólo un recurso didáctico, pero creo que aquí
si hay un poco más de originalidad.
29. BIBLIOGRAFIA O LINKOGRAFIA:
https://es.wikipedia.org/wiki/Modelo_entidad-
relacion#Atributos_en_relaciones
http://www.belgrano.esc.edu.ar/matestudio/car
peta_de_access_introduccion.pdf