Este documento describe el Modelo Entidad Relación Extendido (MERE). En 3 oraciones o menos:
El MERE permite representar relaciones exclusivas, generalización/especialización, y agregación. Incluye reglas para la inserción y eliminación de datos cuando hay jerarquías de especialización. El documento también explica los tipos de especialización basados en si los subtipos son disjuntos o solapados, y si la especialización es total o parcial.
El documento describe una jerarquía de clases de frutas con la clase padre "Frutas" que tiene el atributo color en cualquier color, y las clases hijas "Pera" y "Manzana" que heredan el atributo color de la clase padre y definen el color específico. También describe una clase "operacion_suma" con dos métodos para sumar enteros y números de punto flotante.
Presentación sobre los Modelos ER y Relacional preparado como parte de la materia de Diseño y Administración de Base de Datos de la carrera de Informática de la UMSA.
Este documento presenta una introducción a las variables aleatorias discretas. Explica que estas variables toman valores de un conjunto finito o infinito numerable. Luego describe tres distribuciones de probabilidad comunes para variables discretas: la distribución uniforme discreta, la distribución binomial y la distribución de Poisson. Para cada una, provee ejemplos ilustrativos y fórmulas para calcular probabilidades.
El documento describe los conceptos clave del Modelo Entidad-Relación Extendido, incluyendo subclases y superclases, herencia, especialización, generalización y tipos de jerarquías. Introduce la noción de que las instancias de una superclase pueden agruparse en subconjuntos significativos llamados subclases, y que las subclases heredan atributos y relaciones de la superclase.
Los métodos constructores se utilizan para instanciar objetos de una clase. Pueden ser por defecto o por parámetros. El método toString se sobreescribe para devolver una representación en cadena de los atributos de un objeto cuando se imprime.
La normalización de bases de datos consiste en el proceso de organizar los datos en tablas relacionadas de acuerdo a reglas específicas para eliminar redundancias, proteger la integridad de los datos y hacer la base de datos más flexible. Esto implica crear tablas independientes y establecer relaciones entre ellas según las diferentes formas normales, como la primera, segunda y tercera forma normal.
El documento describe diferentes técnicas para modelar requerimientos, incluyendo modelos basados en escenarios, casos de uso, diagramas de actividades, clases y atributos. Explica que el objetivo del modelado de requerimientos es describir lo que necesita el cliente y definir requerimientos validables. Los modelos de escenarios ilustran los requerimientos desde la perspectiva del usuario, mientras que los modelos de clases representan los objetos, operaciones y relaciones del sistema.
El documento describe una jerarquía de clases de frutas con la clase padre "Frutas" que tiene el atributo color en cualquier color, y las clases hijas "Pera" y "Manzana" que heredan el atributo color de la clase padre y definen el color específico. También describe una clase "operacion_suma" con dos métodos para sumar enteros y números de punto flotante.
Presentación sobre los Modelos ER y Relacional preparado como parte de la materia de Diseño y Administración de Base de Datos de la carrera de Informática de la UMSA.
Este documento presenta una introducción a las variables aleatorias discretas. Explica que estas variables toman valores de un conjunto finito o infinito numerable. Luego describe tres distribuciones de probabilidad comunes para variables discretas: la distribución uniforme discreta, la distribución binomial y la distribución de Poisson. Para cada una, provee ejemplos ilustrativos y fórmulas para calcular probabilidades.
El documento describe los conceptos clave del Modelo Entidad-Relación Extendido, incluyendo subclases y superclases, herencia, especialización, generalización y tipos de jerarquías. Introduce la noción de que las instancias de una superclase pueden agruparse en subconjuntos significativos llamados subclases, y que las subclases heredan atributos y relaciones de la superclase.
Los métodos constructores se utilizan para instanciar objetos de una clase. Pueden ser por defecto o por parámetros. El método toString se sobreescribe para devolver una representación en cadena de los atributos de un objeto cuando se imprime.
La normalización de bases de datos consiste en el proceso de organizar los datos en tablas relacionadas de acuerdo a reglas específicas para eliminar redundancias, proteger la integridad de los datos y hacer la base de datos más flexible. Esto implica crear tablas independientes y establecer relaciones entre ellas según las diferentes formas normales, como la primera, segunda y tercera forma normal.
El documento describe diferentes técnicas para modelar requerimientos, incluyendo modelos basados en escenarios, casos de uso, diagramas de actividades, clases y atributos. Explica que el objetivo del modelado de requerimientos es describir lo que necesita el cliente y definir requerimientos validables. Los modelos de escenarios ilustran los requerimientos desde la perspectiva del usuario, mientras que los modelos de clases representan los objetos, operaciones y relaciones del sistema.
Este documento describe diferentes tipos de consultas SQL que involucran más de una tabla. Explica composiciones cruzadas (producto cartesiano), composiciones internas (intersección) y composiciones externas. Detalla cómo realizar este tipo de consultas utilizando la sintaxis SQL-1 y SQL-2, incluyendo JOINs internos, externos y cruces. El propósito es mostrar diferentes formas de unir tablas y recuperar información de múltiples tablas relacionadas.
El documento presenta conceptos clave del modelo entidad-relación como entidades, atributos, relaciones y diagramas entidad-relación. Explica que las entidades representan objetos reales, los atributos representan propiedades de dichos objetos y las relaciones representan enlaces entre entidades. Además, muestra ejemplos de diagramas entidad-relación y tipos de atributos, relaciones y restricciones que se pueden modelar.
El documento describe diferentes tipos de restricciones en un modelo entidad-relación extendido, incluyendo exclusividad, exclusión, inclusividad, inclusión, generalización y agregación. La generalización describe la relación entre un supertipo y subtipos, y puede ser total o parcial, exclusiva u overlapante. La agregación permite relacionar una relación con otras entidades mediante la creación de una entidad agregada de nivel superior.
The document discusses enhanced entity-relationship (EER) modeling concepts used to more completely represent requirements of complex database applications. It introduces subclasses/superclasses to represent subgroupings of entities, with subclasses inheriting attributes and relationships from superclasses. Specialization defines subclasses of a superclass based on distinguishing characteristics, while generalization combines entity sets with common features into a higher-level superclass. Constraints on specialization/generalization include predicate-defined subclasses with membership conditions and attribute-defined specializations.
Este documento describe los conceptos clave del Modelo Entidad-Relación Extendido (ERE), incluyendo subclases y superclases, especialización y generalización. La especialización permite definir subconjuntos de entidades (subclases) dentro de una entidad más general (superclase), mientras que la generalización identifica características comunes entre entidades para agruparlas en una superclase. El ERE también incluye categorías y herencia de atributos entre clases y subclases.
El documento describe los conceptos fundamentales del modelo de datos relacional, incluyendo tablas, tuplas, dominios, claves primarias, claves foráneas y diferentes tipos de relaciones entre tablas (1:1, 1:N, N:M). Explica cómo transformar un esquema de clases orientado a objetos a un esquema de base de datos relacional mediante la conversión de clases en tablas y relaciones en tablas y claves foráneas.
El documento describe la estructura y procesos del Rational Unified Process (RUP) y cómo se aplica en el modelo de análisis de requisitos. Explica las fases, iteraciones e iteraciones preliminares del RUP, y describe los elementos clave del modelo de análisis como casos de uso, clases de análisis, diagramas de secuencia y colaboración, y arquitectura del análisis. También incluye ejemplos detallados de cómo se representan y analizan los requisitos funcionales en el modelo de análisis.
Este documento describe cómo convertir un diagrama de clases UML a código Java. Presenta las clases Vehículo y Persona, explicando cómo los atributos y relaciones del diagrama se convierten en atributos de clase en Java. También incluye información sobre la creación de proyectos y clases en Eclipse, y ofrece ejemplos adicionales de conversión de diagramas de clases a código.
Este documento presenta los conceptos fundamentales del modelo entidad-relación (E-R) para el diseño de bases de datos. Explica que el modelo E-R representa la realidad a través de entidades, relaciones y atributos, y describe los elementos clave como las cardinalidades, restricciones, tipos de entidades, y las fases del diseño de bases de datos usando este modelo conceptual. También introduce conceptos avanzados como la herencia y la generalización/especialización en el modelo E-R extendido.
El documento presenta el patrón de diseño Singleton, el cual garantiza que una clase tenga una única instancia y provee un punto de acceso global a dicha instancia. Se explica que el patrón Singleton restringe la creación de objetos a una sola instancia, la cual puede ser accedida de manera global. También se describen los elementos clave del patrón como el constructor privado y el método estático de obtención de instancia.
El documento describe los diferentes tipos de diagramas UML utilizados en el diseño de sistemas de software, incluyendo diagramas de clases, objetos, componentes, actividades, casos de uso, máquinas de estados, secuencia, comunicación, tiempo e interacción. Define los componentes clave de cada diagrama y su propósito en el modelado de sistemas de software.
Este documento explica el concepto de integral definida y sus propiedades. Introduce la integral definida como el límite de una suma de áreas de rectángulos cuando el número de rectángulos tiende a infinito y su tamaño tiende a cero. Explica que la integral definida puede usarse para calcular áreas delimitadas por curvas y rectas. Además, presenta métodos como el de trapecios y Simpson para aproximar el valor de integrales definidas.
Desarrollo de aplicaciones web con casos de usoJosafat Mtz
Este documento presenta casos de uso, descripciones y diagramas de secuencia para tres procesos en un sistema de gestión de una empresa manufacturera: 1) ingreso al sistema, 2) alta de usuarios, y 3) alta de materiales. Se utiliza la metodología UML para modelar cada caso de uso y describir los pasos involucrados. Diagramas de secuencia muestran el flujo de interacción entre actores y el sistema para cada proceso.
Este documento describe el modelo entidad-relación (E/R), propuesto por Peter Chen en 1976-1977. El modelo E/R representa gráficamente las entidades, relaciones, atributos y tipos de entidades de una base de datos. Las entidades representan objetos y elementos de datos, mientras que las relaciones representan asociaciones entre entidades. El modelo incluye conceptos como cardinalidad, roles, herencia y tipos de atributos y entidades.
Los lenguajes de descripción de hardware (HDL) como VHDL y Verilog permiten modelar la arquitectura y comportamiento de sistemas electrónicos de manera independiente de la tecnología. Estos lenguajes soportan la simulación y síntesis lógica para verificar el diseño y convertir la descripción a una implementación física. El HDL es una herramienta útil para el diseño y documentación de circuitos integrados ya que permite describirlos a distintos niveles de abstracción.
El diagrama de clases representa las clases, interfaces y colaboraciones que se utilizarán dentro de un sistema y las relaciones entre ellas. Se utiliza para modelar la vista estática de diseño de un sistema. Incluye clases con atributos, métodos y visibilidad, así como relaciones como herencia, composición, agregación, asociación y uso. Representa la estructura y el comportamiento de un sistema a través de las clases y sus interrelaciones.
El documento describe el modelo de casos de uso y sus elementos. Explica que el modelo de casos de uso describe los requerimientos funcionales de un sistema a través de casos de uso, actores y su interacción. Define conceptos clave como actor, caso de uso, flujo básico y flujo alternativo para la descripción de casos de uso. Además, explica cómo construir un modelo de casos de uso identificando actores, casos de uso y diagramando su interacción.
Este documento presenta una unidad sobre máximos, mínimos y diferenciales de orden superior. Incluye objetivos de aprendizaje, instrucciones para completar actividades, y dos ejemplos detallados - uno sobre máximos y mínimos locales y globales, y otro sobre el uso de diferenciales para estimar el volumen de una esfera con radio cambiante. También incluye dos ejercicios para que el estudiante complete.
El documento describe varios operadores y funciones avanzadas del lenguaje SQL para manipular y consultar datos en bases de datos, incluyendo operadores de concatenación, literales, BETWEEN, IN, LIKE, IS NULL, funciones de agregado como SUM, AVG, COUNT, MAX y MIN, instrucciones GROUP BY y HAVING, diferentes tipos de joins para combinar tablas, y el uso de subconsultas en SELECT anidados. Se proveen ejemplos detallados para ilustrar el uso de cada operador y función.
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Julio Pari
Este documento introduce los conceptos de contenedores y Kubernetes. Explica que los contenedores aíslan los procesos en lugar de máquinas virtuales completas, lo que hace que sean más livianos y portables. Luego describe cómo Kubernetes organiza contenedores en clústeres y los orquesta a través de un master y nodos trabajadores para implementar aplicaciones de manera escalable. Finalmente, proporciona contactos de especialistas de IBM para obtener más información.
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
Este documento anuncia dos talleres virtuales gratuitos sobre despliegue de aplicaciones en Kubernetes y envío de mensajes con Event Streams en IBM Cloud. Los talleres se llevarán a cabo el 28 de julio y el 11 de agosto respectivamente. Los interesados pueden registrarse en un enlace proporcionado para aprender a crear servicios utilizando tecnologías de código abierto en la nube de IBM.
Este documento describe diferentes tipos de consultas SQL que involucran más de una tabla. Explica composiciones cruzadas (producto cartesiano), composiciones internas (intersección) y composiciones externas. Detalla cómo realizar este tipo de consultas utilizando la sintaxis SQL-1 y SQL-2, incluyendo JOINs internos, externos y cruces. El propósito es mostrar diferentes formas de unir tablas y recuperar información de múltiples tablas relacionadas.
El documento presenta conceptos clave del modelo entidad-relación como entidades, atributos, relaciones y diagramas entidad-relación. Explica que las entidades representan objetos reales, los atributos representan propiedades de dichos objetos y las relaciones representan enlaces entre entidades. Además, muestra ejemplos de diagramas entidad-relación y tipos de atributos, relaciones y restricciones que se pueden modelar.
El documento describe diferentes tipos de restricciones en un modelo entidad-relación extendido, incluyendo exclusividad, exclusión, inclusividad, inclusión, generalización y agregación. La generalización describe la relación entre un supertipo y subtipos, y puede ser total o parcial, exclusiva u overlapante. La agregación permite relacionar una relación con otras entidades mediante la creación de una entidad agregada de nivel superior.
The document discusses enhanced entity-relationship (EER) modeling concepts used to more completely represent requirements of complex database applications. It introduces subclasses/superclasses to represent subgroupings of entities, with subclasses inheriting attributes and relationships from superclasses. Specialization defines subclasses of a superclass based on distinguishing characteristics, while generalization combines entity sets with common features into a higher-level superclass. Constraints on specialization/generalization include predicate-defined subclasses with membership conditions and attribute-defined specializations.
Este documento describe los conceptos clave del Modelo Entidad-Relación Extendido (ERE), incluyendo subclases y superclases, especialización y generalización. La especialización permite definir subconjuntos de entidades (subclases) dentro de una entidad más general (superclase), mientras que la generalización identifica características comunes entre entidades para agruparlas en una superclase. El ERE también incluye categorías y herencia de atributos entre clases y subclases.
El documento describe los conceptos fundamentales del modelo de datos relacional, incluyendo tablas, tuplas, dominios, claves primarias, claves foráneas y diferentes tipos de relaciones entre tablas (1:1, 1:N, N:M). Explica cómo transformar un esquema de clases orientado a objetos a un esquema de base de datos relacional mediante la conversión de clases en tablas y relaciones en tablas y claves foráneas.
El documento describe la estructura y procesos del Rational Unified Process (RUP) y cómo se aplica en el modelo de análisis de requisitos. Explica las fases, iteraciones e iteraciones preliminares del RUP, y describe los elementos clave del modelo de análisis como casos de uso, clases de análisis, diagramas de secuencia y colaboración, y arquitectura del análisis. También incluye ejemplos detallados de cómo se representan y analizan los requisitos funcionales en el modelo de análisis.
Este documento describe cómo convertir un diagrama de clases UML a código Java. Presenta las clases Vehículo y Persona, explicando cómo los atributos y relaciones del diagrama se convierten en atributos de clase en Java. También incluye información sobre la creación de proyectos y clases en Eclipse, y ofrece ejemplos adicionales de conversión de diagramas de clases a código.
Este documento presenta los conceptos fundamentales del modelo entidad-relación (E-R) para el diseño de bases de datos. Explica que el modelo E-R representa la realidad a través de entidades, relaciones y atributos, y describe los elementos clave como las cardinalidades, restricciones, tipos de entidades, y las fases del diseño de bases de datos usando este modelo conceptual. También introduce conceptos avanzados como la herencia y la generalización/especialización en el modelo E-R extendido.
El documento presenta el patrón de diseño Singleton, el cual garantiza que una clase tenga una única instancia y provee un punto de acceso global a dicha instancia. Se explica que el patrón Singleton restringe la creación de objetos a una sola instancia, la cual puede ser accedida de manera global. También se describen los elementos clave del patrón como el constructor privado y el método estático de obtención de instancia.
El documento describe los diferentes tipos de diagramas UML utilizados en el diseño de sistemas de software, incluyendo diagramas de clases, objetos, componentes, actividades, casos de uso, máquinas de estados, secuencia, comunicación, tiempo e interacción. Define los componentes clave de cada diagrama y su propósito en el modelado de sistemas de software.
Este documento explica el concepto de integral definida y sus propiedades. Introduce la integral definida como el límite de una suma de áreas de rectángulos cuando el número de rectángulos tiende a infinito y su tamaño tiende a cero. Explica que la integral definida puede usarse para calcular áreas delimitadas por curvas y rectas. Además, presenta métodos como el de trapecios y Simpson para aproximar el valor de integrales definidas.
Desarrollo de aplicaciones web con casos de usoJosafat Mtz
Este documento presenta casos de uso, descripciones y diagramas de secuencia para tres procesos en un sistema de gestión de una empresa manufacturera: 1) ingreso al sistema, 2) alta de usuarios, y 3) alta de materiales. Se utiliza la metodología UML para modelar cada caso de uso y describir los pasos involucrados. Diagramas de secuencia muestran el flujo de interacción entre actores y el sistema para cada proceso.
Este documento describe el modelo entidad-relación (E/R), propuesto por Peter Chen en 1976-1977. El modelo E/R representa gráficamente las entidades, relaciones, atributos y tipos de entidades de una base de datos. Las entidades representan objetos y elementos de datos, mientras que las relaciones representan asociaciones entre entidades. El modelo incluye conceptos como cardinalidad, roles, herencia y tipos de atributos y entidades.
Los lenguajes de descripción de hardware (HDL) como VHDL y Verilog permiten modelar la arquitectura y comportamiento de sistemas electrónicos de manera independiente de la tecnología. Estos lenguajes soportan la simulación y síntesis lógica para verificar el diseño y convertir la descripción a una implementación física. El HDL es una herramienta útil para el diseño y documentación de circuitos integrados ya que permite describirlos a distintos niveles de abstracción.
El diagrama de clases representa las clases, interfaces y colaboraciones que se utilizarán dentro de un sistema y las relaciones entre ellas. Se utiliza para modelar la vista estática de diseño de un sistema. Incluye clases con atributos, métodos y visibilidad, así como relaciones como herencia, composición, agregación, asociación y uso. Representa la estructura y el comportamiento de un sistema a través de las clases y sus interrelaciones.
El documento describe el modelo de casos de uso y sus elementos. Explica que el modelo de casos de uso describe los requerimientos funcionales de un sistema a través de casos de uso, actores y su interacción. Define conceptos clave como actor, caso de uso, flujo básico y flujo alternativo para la descripción de casos de uso. Además, explica cómo construir un modelo de casos de uso identificando actores, casos de uso y diagramando su interacción.
Este documento presenta una unidad sobre máximos, mínimos y diferenciales de orden superior. Incluye objetivos de aprendizaje, instrucciones para completar actividades, y dos ejemplos detallados - uno sobre máximos y mínimos locales y globales, y otro sobre el uso de diferenciales para estimar el volumen de una esfera con radio cambiante. También incluye dos ejercicios para que el estudiante complete.
El documento describe varios operadores y funciones avanzadas del lenguaje SQL para manipular y consultar datos en bases de datos, incluyendo operadores de concatenación, literales, BETWEEN, IN, LIKE, IS NULL, funciones de agregado como SUM, AVG, COUNT, MAX y MIN, instrucciones GROUP BY y HAVING, diferentes tipos de joins para combinar tablas, y el uso de subconsultas en SELECT anidados. Se proveen ejemplos detallados para ilustrar el uso de cada operador y función.
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Julio Pari
Este documento introduce los conceptos de contenedores y Kubernetes. Explica que los contenedores aíslan los procesos en lugar de máquinas virtuales completas, lo que hace que sean más livianos y portables. Luego describe cómo Kubernetes organiza contenedores en clústeres y los orquesta a través de un master y nodos trabajadores para implementar aplicaciones de manera escalable. Finalmente, proporciona contactos de especialistas de IBM para obtener más información.
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
Este documento anuncia dos talleres virtuales gratuitos sobre despliegue de aplicaciones en Kubernetes y envío de mensajes con Event Streams en IBM Cloud. Los talleres se llevarán a cabo el 28 de julio y el 11 de agosto respectivamente. Los interesados pueden registrarse en un enlace proporcionado para aprender a crear servicios utilizando tecnologías de código abierto en la nube de IBM.
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
This document provides instructions for completing a lab tutorial on getting started with IBM Cloud container services. It includes steps to check version numbers for required tools, clone a GitHub repository, log in to IBM Cloud, build and push a Docker image, configure a Kubernetes cluster, deploy a sample application, and expose it via a service. The lab is split into two parts - the first focuses on building and pushing a container image, while the second covers deploying it on Kubernetes and making the application accessible.
Este documento presenta la estructura propuesta para un trabajo de tesis o proyecto profesional. Detalla los diferentes capítulos que debería contener el documento, como la introducción, marco teórico, objeto de estudio, y capítulos para la propuesta de solución, modelo de negocio, requerimientos, arquitectura y construcción del sistema, calidad y pruebas, y gestión del proyecto. El documento provee una guía general para la organización y contenido de cada capítulo con el fin de abordar un tema de investig
El documento describe la arquitectura tecnológica actual y recomendada para el sitio web de la Facultad de Ingeniería de Sistemas e Informática de la UNMSM. Actualmente se hospeda en un servidor dedicado con CentOS y Joomla, pero se recomienda migrar a una plataforma en la nube Jelastic que ofrece escalabilidad automática, balanceo de carga y alta disponibilidad con Liferay.
Jelastic provides a private cloud platform-as-a-service (PaaS) that allows developers to rapidly deploy scalable applications to the cloud without code changes. It delivers a fully managed private cloud infrastructure with automated scaling, high availability, and comprehensive management tools. Jelastic's per-server subscription model offers significant savings over traditional virtualization solutions or cloud building blocks.
El documento presenta la arquitectura de un sistema de ingeniería de software, incluyendo su nombre, objetivo, diagrama de contexto, diagrama de arquitectura general y las tecnologías a utilizar.
Solucion Examen Parcial Sistemas Digitales UNMSM FISIJulio Pari
El documento presenta las soluciones a un examen parcial de Sistemas Digitales impartido en la UNMSM, Facultad de Física, en julio. Contiene las respuestas a 8 preguntas del examen.
Práctica de Inventarios - Investigación Operativa IIJulio Pari
Este documento presenta una discusión sobre la teoría de inventarios a través de 30 páginas. Aborda temas como los modelos de inventarios, los costos asociados con el mantenimiento de inventarios y la toma de decisiones sobre los niveles óptimos de inventario.
Armas silenciosas para guerras tranquilasJulio Pari
Este documento resume la historia y el desarrollo de las "armas silenciosas" para la "guerra tranquila". En 1954, los poderosos decidieron llevar a cabo una guerra silenciosa contra el público estadounidense utilizando nuevas tecnologías como las computadoras para controlar y manipular la sociedad de manera predecible y mantener el poder en manos de unos pocos. El documento introduce las armas silenciosas como una nueva forma de control social a través de la manipulación de datos e información en lugar de armas convenc
Este documento describe el Lenguaje Unificado de Modelado (UML) y sus diagramas. UML es un lenguaje gráfico para modelar sistemas de software desarrollado inicialmente por Grady Booch, Ivar Jacobson y James Rumbaugh. El documento explica los diagramas de clases, casos de uso, estados, secuencias, actividades y la historia del desarrollo de UML. También incluye ejemplos de cómo generar código Java a partir de diagramas UML usando NetBeans.
Formato de presentación de Proyecto UNMSM FISIJulio Pari
El documento presenta un proyecto realizado por 5 estudiantes de la Facultad de Ingeniería de Sistemas e Informática de la Universidad Nacional Mayor de San Marcos en Lima, Perú, e incluye los nombres, códigos y correos electrónicos de los integrantes, así como el nombre del curso, profesor y fecha.
Este cuento habla sobre una familia que vive en una casa en el bosque. La familia está formada por los padres y sus dos hijos, un niño y una niña. Los niños disfrutan jugando en el bosque mientras sus padres los cuidan desde la casa.
Este documento describe los pasos para crear y consultar una base de datos MySQL. Inicialmente se crea la base de datos y las tablas ejecutando un script SQL. Luego se muestran diferentes consultas como listar las bases de datos existentes, listar las tablas de una base y consultar el contenido de una tabla. Finalmente se explica el uso de archivos comunes como una hoja de estilos y una librería para realizar las conexiones a la base de datos.
El documento describe los pasos para instalar MySQL, phpMyAdmin y configurar la conexión entre PHP y MySQL. Explica cómo instalar MySQL, crear bases de datos y tablas, y ejecutar consultas SQL. Luego, detalla la instalación de phpMyAdmin y su configuración. Finalmente, muestra cómo conectar PHP a MySQL mediante funciones como mysql_connect() y mysql_query(), y cómo manejar los resultados de las consultas.
Este documento describe las funciones de usuario en PHP. Explica la sintaxis básica para definir funciones, cómo pasar parámetros a funciones, devolver valores de funciones e incluir archivos. Las funciones se definen usando la palabra clave function, pueden aceptar parámetros y devolver valores. Los archivos pueden incluirse usando las instrucciones require e include.
2. Concepto
Es el resultado de aportaciones de diversos autores
al modelo Entidad-Relación «básico».
Permiten representar:
RELACIONE
RELACIONE GENERALIZACION AGREGACION
GENERALIZACION AGREGACION
S
S //
EXCLUSIVA
EXCLUSIVA ESPECIALIZACIO
ESPECIALIZACIO
S
S NN
2
3. Relaciones Exclusivas
Dos (o más) tipos de relación son exclusivos, respecto de un
tipo de entidad que participa en ambos, si cada instancia del
tipo de entidad sólo puede participar en uno de los tipos de
relación
VEHÍCULO
CONSUME GASTA
GASOIL GASOLINA
CONSUME y GASTA son exclusivas respecto del tipo de entidad
VEHICULO
3
5. Relaciones Exclusivas
Ejemplos
ESTUDIANTE
RESIDE SE ALOJA EN DOMICILIA
RESIDENCIA PISO
VIVIENDA
ESTUDIANTIL COMPARTIDO
FAMILIAR
5
6. Especialización/Generalización (E/G)
Caso especial de relación entre un tipo de entidad y
varios otros tipos de entidad
La jerarquía o relación que se establece entre uno y
otros corresponde a la noción de “es_un” o de
“es_un_tipo_de”
Estas jerarquías pueden formarse por
especialización o bien por generalización
Especialización: Un ANIMAL es un FELINO
Generalización: Un REPTIL es un tipo de ANIMAL;
Un INSECTO es un tipo de ANIMAL
6
7. E/G: Subtipo de un tipo de entidad
Agrupación de instancias dentro de un tipo de
entidad, que debe representarse explícitamente
debido a su importancia para el diseño o aplicación
Subtipos del tipo de entidad VEHÍCULO:
CAMIÓN
TURISMO
AUTOBÚS
CICLOMOTOR
Subtipos del tipo de entidad EMPLEADO:
SECRETARIO
GERENTE
COMERCIAL
El tipo de entidad que se especializa en otros se
llama supertipo ( VEHICULO, EMPLEADO )
7
8. E/G: Relación Supertipo / Subtipo
Es la relación que se establece entre
un supertipo y cada uno de sus
subtipos (noción es_un o EMPLEADO [EN2002]
es_un_tipo_de)
Notaciones:
EMPLEADO
SECRETARIO GERENTE COMERCIAL
EMPLEADO [SKS1998]
SECRETARIO GERENTE COMERCIAL
ES
[MPM1999]
SECRETARIO GERENTE COMERCIAL 8
9. E/G: Relación Supertipo / Subtipo
La extensión de un subtipo es un subconjunto de la
extensión del supertipo
Una instancia de subtipo también es instancia del supertipo y
es la misma instancia, pero con un papel específico distinto
Una instancia no puede existir sólo por ser miembro de un
subtipo: también debe ser miembro del supertipo
Una instancia del supertipo puede no ser miembro de ningún
subtipo
EMPLEADO_HOSPITAL
VEHÍCULO
CAMIÓN TURISMO CICLOMOTOR MÉDICO CELADOR ENFERMERO LIMPIADOR
9
10. E/G: Herencia de tipo
Un subtipo puede tener atributos propios (específicos) y
participar en relaciones por separado
Un subtipo hereda todos los atributos del supertipo, y toda
relación en la que participa el supertipo
Un subtipo, con sus atributos y relaciones específicos, más
los atributos y relaciones que hereda del supertipo, es un
tipo de entidad por derecho propio
numBastidor VEHÍCULO FABRICA FABRICANTE
precio (1,n) (1,1)
N:1
[MPM1999] (1,1) ID (0,1)
CAMIÓN TURISMO MOTOCICLETA SIDECAR
LLEVA
numEjes numPlazas
tonelaje numPuer cilindrada 1:1 10
11. E/G: Especialización
Proceso de definición de un conjunto de subtipos de un tipo
de entidad (» supertipo)
Subtipos suelen estar definidos según característica distintiva de
las entidades del supertipo
Discriminante de la especialización
EMPLEADO [MPM1999]
actividad
SECRETARIO GERENTE COMERCIAL
11
12. E/G: Especialización
Varias especializaciones de un tipo de entidad,
con base en diferentes discriminantes
VEHÍCULO [MPM1999]
motorS/N tipo
VEHÍCULO_A_MOTOR VEHÍCULO_SIN_MOTOR CAMIÓN TURISMO MOTOCICLETA
PELÍCULA
color
[EN2002]
género
DRAMA TERROR COMEDIA BLANCO_Y_NEGRO COLOR
12
13. E/G: Especialización
Conviene incluir relaciones subtipo/supertipo si hay...
Atributos que sólo tienen sentido para algunas instancias de
un tipo y no para todas (atributos específicos)
especialidadMédica «no es aplicable» a CELADOR
Tipos de relación en los que sólo participan algunas
entidades de un tipo y no todas (relaciones específicas)
Relación SUPERVISA entre CELADOR y SECCIÓN_HOSPITAL
1:1
[MPM1999] CELADOR
(1,1)
SUPERVISA
(1,1)
SECCIÓN_HOSPITAL
13
14. E/G: Generalización
Proceso inverso de la especialización
Suprimir diferencias entre varios tipos de entidad: identificar
atributos y relaciones comunes, y formar un supertipo que los
incluya
numBastidor numBastidor
fechaFab VEHÍCULO
precio CAMIÓN fechaFab
precio
numEjes tonelaje
G CAMIÓN TURISMO
fechaFab
numBastidor
numEjes tonelaje numPuer
precio TURISMO numPuer
14
15. E/G: Generalización vs. Especialización
Generalización
Énfasis en las similitudes
Cada instancia del supertipo es también una instancia de
alguno de los subtipos
Especialización
Énfasis en las diferencias
Alguna instancia del supertipo puede no ser instancia de
ningún subtipo
15
16. Restricciones sobre la E/G
Definición
¿Qué instancias del supertipo pertenecen a cada subtipo?
Disyunción/Solapamiento
¿A cuántos subtipos puede pertenecer (a la vez) una
instancia del supertipo?
Completitud/Parcialidad
¿Debe toda instancia del supertipo pertenecer a algún
subtipo?
16
17. Restricciones sobre la E/G
Subtipos definidos por predicado o condición
Condición de pertenencia a cada subtipo
con base en el valor de algún atributo del supertipo
Restricción que especifica que...
Las instancias del subtipo deben satisfacer la condición
Todas las instancias del supertipo que cumplen la condición,
deben pertenecer al subtipo
PERSONA
[EN2002]
estadoLaboral=en_activo matriculado=true
EMPLEADO ESTUDIANTE
17
18. Restricciones sobre la E/G: Definición
Subtipos definidos por atributo
Todas las subclases definen la condición de pertenencia en
términos del mismo atributo
... es el discriminante de la especialización
PERSONA EMPLEADO_HOSPITAL
estadoLaboral claseTrabajo
en_activo en_paro
médico celador
EMPLEADO PARADO enfermero limpiador
MÉDICO CELADOR ENFERMERO LIMPIADOR
[EN2002] [MPM1999]
18
19. Restricciones sobre la E/G: Definición
Subtipos definidos por el usuario
No existe (o no interesa definir) ninguna condición de
pertenencia a los subtipos
El usuario, al insertar una instancia, elige a qué subtipo
pertenece
PROFESOR [MPM1999]
TITULAR AYUDANTE ASOCIADO
19
20. Restricciones sobre la E/G:
Disyunción/Solapamiento
Subtipos disjuntos si una instancia del supertipo puede ser
miembro de, como máximo, uno de los subtipos
VEHÍCULO VEHÍCULO
d
TURISMO CAMIÓN TURISMO CAMIÓN
[EN2002] [MPM1999]
20
21. Restricciones sobre la E/G:
Disyunción/Solapamiento
Subtipos solapados si una instancia del supertipo puede
ser, a la vez, miembro de más de un subtipo
Es la opción «por defecto»
PERSONA PERSONA
o
EMPLEADO ESTUDIANTE EMPLEADO ESTUDIANTE
[EN2002] [MPM1999]
21
22. Restricciones sobre la E/G:
Completitud/Parcialidad
Especialización total (completa) indica que toda instancia
del supertipo también debe ser instancia de algún subtipo
ANIMAL
ANIMAL
d
MACHO HEMBRA HERMAFRODITA MACHO HEMBRA HERMAFRODITA
[EN2002] [MPM1999]
22
23. Restricciones sobre la E/G:
Completitud/Parcialidad
Especialización parcial indica que es posible que alguna
instancia del supertipo no pertenezca a ninguno de los subtipos
Es la opción «por defecto»
La unión de las extensiones de los subtipos no es la extensión
del supertipo en su totalidad
ALIMENTO ALIMENTO
[EN2002] [MPM1999]
d
LACTEO FRUTA VERDURA LACTEO FRUTA VERDURA
23
24. E/G: Tipos de Especialización
Las restricciones de disyunción y completitud son
independientes entre sí
Dan lugar a 4 tipos de especialización:
Disjunta y Total
Disjunta y Parcial
Solapada y Total
Solapada y Parcial
Lo veremos con un ejemplo de una base de datos de una
Universidad
24
25. E/G: Especialización Disjunta y Total
EMPLEADO ESTUDIANTE
claseTrabajo tipo
DOCENTE ADMON_Y_SERV BECARIO BECARIO NO_BECARIO
Especialización Disjunta y Parcial
DOCENTE
cuerpoDocente
AYUDANTE TITULAR CATEDRÁTICO [MPM1999]
26. E/G: Especialización Solapada y Total
PERSONA
ocupación
EMPLEADO ESTUDIANTE [MPM1999]
Especialización Solapada y Parcial
EMPLEADO
dedicación
DOCENTE INVESTIGADOR
27. E/G: Reglas de inserción y eliminación
Deben aplicarse a la Especialización y la Generalización, debido a
las restricciones definidas
Insertar una instancia en un supertipo implica
insertarla en todos los subtipos definidos por predicado o por
atributo, para los cuales satisface el predicado de definición
Insertar una instancia en un supertipo de una
especialización total implica insertarla en, al menos, un subtipo
Y si la especialización es disjunta, entonces la instancia se
insertará en un único subtipo
27
28. E/G: Reglas de inserción y eliminación
Eliminar una instancia de un supertipo implica eliminarla de
todos los subtipos a los que pertenece
Eliminar una instancia de un subtipo implica eliminarla del
supertipo si la especialización es ...
disjunta y total, o bien
solapada y total, y la instancia ya sólo pertenece al
subtipo (se eliminó del resto)
En el resto de casos, la instancia sólo se elimina del subtipo
No del supertipo ( lo haría el usuario, si fuese necesario)
28
29. E/G: Jerarquías y Retículas
Hasta ahora hemos estudiado jerarquías de especialización
en las que se cumple la restricción:
Todo subtipo participa en sólo una relación
supertipo/subtipo
Un subtipo tiene un único supertipo: es el concepto de árbol
En una retícula de especialización...
Un subtipo puede participar en varias relaciones
supertipo/subtipo
Un subtipo puede tener más de un supertipo
29
30. E/G: Jerarquías y Retículas
nombre
[MPM1999] dni PERSONA
dirección
sexo ocupación
jornada jornada
fechaIni DESEMPLEADO salario EMPLEADO ESTUDIANTE carrera
dedicación tipoEstudiante
(1, n) centro DOCENTE ADMÓN_Y_SERV BECARIO NO_BECARIO
puesto beca
cuerpoDocente
CATEDRÁTICO TITULAR NO_NUMERARIO
tipoCátedra tipoPlaza duraciónContrato
31. E/G: Jerarquías y Retículas: Herencia
múltiple
En las jerarquías de especialización
Cada subtipo hereda atributos y relaciones...
de su (único) supertipo directo
y de sus supertipos predecesores, hasta la raíz
TITULAR hereda de DOCENTE, EMPLEADO y PERSONA
En las retículas de especialización
Un subtipo hereda atributos y relaciones...
de sus supertipos (múltiples) directos herencia
múltiple
y de todos sus supertipos predecesores, hasta la raíz
BECARIO hereda directamente de EMPLEADO y ESTUDIANTE,
e indirectamente hereda de PERSONA
» Los subtipos compartidos dan lugar a retículas 31
32. E/G: Jerarquías y Retículas: Herencia
múltiple
En herencia múltiple pueden surgir conflictos al heredar atributos
distintos denominados igual
BECARIO hereda “jornada” de dos predecesores ¡¡ !!
¿Cómo resolver esta situación?
Renombrar algunos de los atributos en conflicto
BECARIO hereda ambos atributos:
– “jornada” corresponde a “jornada” de EMPLEADO y
– “jornadaEstudio” corresponde a “jornada” de ESTUDIANTE
Definir un orden de prioridad en la herencia
BECARIO hereda “jornada” de ESTUDIANTE y no de
EMPLEADO
32
33. E/G: Jerarquías y Retículas:
Inhibición de la herencia
Algunos modelos de datos permiten indicar que ciertos atributos
del supertipo no deben ser heredados por los subtipos
POLÍGONO
[MPM1999]
numVértices
ancho
PENTÁGONO TRIÁNGULO RECTÁNGULO alto
CUADRADO lado
“ancho” y “alto” no deberían ser heredados por el subtipo
33
34. E/G: Jerarquías y Retículas:
Redefinición de atributos heredados
Si un supertipo y un subtipo tienen un atributo con el mismo
nombre, se entiende que el atributo del subtipo redefine el
del supertipo
Se utiliza el mismo nombre y significado semántico
pero se modifica cómo se calcula o cómo se representa el
valor del atributo
Tiene sentido sobre todo para atributos derivados
ancho
[MPM1999]
área RECTÁNGULO alto
área
CUADRADO lado
34
35. E/G: Jerarquías y Retículas:
Tratamiento de la herencia
Consideraremos que en el MERE ...
Los subtipos heredan todos los atributos de los
supertipos
Pero se permite la redefinición de atributos en los
subtipos, y la inhibición de laancho
herencia de atributos
área RECTÁNGULO alto [MPM1999]
área
CUADRADO lado
... y si se da herencia múltiple y existe conflicto de nombres, el
usuario elegirá entre
Renombrar algunos atributos en conflicto, o
Inhibir la herencia de algunos atributos 35
36. Agregación de tipos de entidad
Restricción inherente del MER:
No puede expresar relaciones
entre varias relaciones, ni
entre un tipo de relación y un tipo de entidad
La agregación...
Permite combinar varios tipos de entidad, relacionados
mediante un tipo de relación, para formar un tipo de
entidad agregada de nivel superior
Útil cuando el tipo de entidad agregado debe
relacionarse con otros tipos de entidad
36
37. Agregación de tipos de entidad
EJEMPLO 1:
Esquema en el MERE que almacena información sobre las entrevistas que
una CONSULTORA organiza entre SOLICITANTES de empleo y diferentes
EMPRESAS
nombre
nif
(1,n) (1,m)
EMPRESA ENTREVISTA_A SOLICITANTE
M N
dirección fecha telefContacto nombre
telef
nomContacto
Algunas entrevistas dan lugar a ofertas de empleos y otras no
¿cómo modelamos esto?
37
38. Agregación de tipos de entidad
Solución 1: Relación ternaria
EMPRESA ENTREVISTA_A SOLICITANTE
OFERTA_EMPLEO
¡ERROR!
» Toda entrevista da lugar a un empleo
¡ESO ES FALSO!
38
39. Agregación de tipos de entidad
Solución 2:
EMPRESA ENTREVISTA_A SOLICITANTE
RESULTA_EN
OFERTA_EMPLEO
¡ERROR!
NO es posible establecer una
relación entre varias relaciones,
ni entre relaciones y entidades 39
40. Agregación de tipos de entidad
Solución 3:
EMPRESA ENTREVISTA_A SOLICITANTE
ENTREVISTA
Entidad RESULTA_EN
COMPUESTA o
AGREGADA
OFERTA_EMPLEO
OK!
OFERTA_EMPLEO tiene dependencia en existencia respecto de
RESULTA_EN
40
41. Agregación de tipos de entidad
Solución 4: Relación ternaria « falsa»
nombre nif
(0,n) (0,m)
EMPRESA REALIZA SOLICITANTE
(1,1)
(0,1) (1,1) OFERTA
ENTREVISTA GENERA
fecha EMPLEO
nomContacto telefContacto idOferta
Tipo de entidad débil de otros dos
¿Qué significa que ENTREVISTA tenga fecha como clave parcial?
41
42. Agregación de tipos de entidad
Solución 5:
nombre nif
EMPRESA SOLICITANTE
fecha
(1,1) (1,1)
(0,n) (0,m)
REALIZA ENTREVISTA AFRONTA
(1,1)
(0,1) OFERTA
GENERA idOferta
EMPLEO
Tipo de entidad débil de otros dos
42
43. Agregación de tipos de entidad
Ejemplo 2:
Esquema en el MERE que almacena información acerca de profesores y
las asignaturas que éstos imparten, así como los diversos medios que
utilizan para impartir cada asignatura (pizarra, transparencias, etc.)
M N
PROFESOR EXPLICA ASIGNATURA
M
UTILIZA
N
MEDIO
¡ERROR! no es posible establecer una
relación entre una relación y una entidad 43
44. Agregación de tipos de entidad
Solución:
M N
PROFESOR EXPLICA ASIGNATURA
EXPLICACIÓN
M
Entidad COMPUESTA
o AGREGADA UTILIZA
N
MEDIO
44
45. Agregación
AGREGACIÓN COMPUESTO / COMPONENTE:
Un todo se obtiene por la unión de diversas partes, que
pueden ser objetos distintos y que desempeñan papeles
distintos en la agregación.
COCHE
(1,1) (1,1) (4,4)
CHASIS MOTOR RUEDA
45
46. Agregación
AGREGACIÓN COLECCIÓN / MIEMBRO :
Un todo se obtiene por la unión de diversas partes del mismo
tipo y que desempeñan el mismo papel en la agregación.
Se puede establecer orden entre las partes
BOSQUE ARBOL FLOTA BARCO
{NumBarco}
46
Notas del editor
Los elementos que hemos visto hasta ahora son suficientes para realizar el diseño conceptual de la mayoría de esquemas de base de datos para aplicaciones de base de datos tradicionales (administrativas). Sin embargo, desde los años 80 ha ido en aumento el desarrollo de nuevas aplicaciones de BD, como herramientas CAD, CAM y CASE y aplicaciones multimedia. Los requisitos de base de datos de este tipo de aplicaciones son mayores y más complejos que los de las tradicionales y los conceptos básicos del modelo ER no son suficientes para representarlos. Este hecho hizo que se añadieran nuevos conceptos semánticos de modelado al modelo ER original, dando lugar al modelo entidad-relación extendido (EER: enhanced Entity-Relationship model). CAD: Computer Aided Design CAM: Computer Aided Manufacturing CASE: Computer Aided Software Engineering
Otro ejemplo sería el de un ARTÍCULO que pudiera publicarse en un PERIÓDICO o en una REVISTA, pero nunca en ambos. Un ejemplo más sería el de los domicilios de los estudiantes universitarios durante el curso académico. Un ESTUDIANTE se puede alojar en un DOMICILIO_FAMILIAR, una RESIDENCIA_ESTUDIANTES o en un PISO_COMPARTIDO. Las tres relaciones que unen a ESTUDIANTE con las tres entidades serían exclusivas entre sí.
Otro ejemplo sería el de un ARTÍCULO que pudiera publicarse en un PERIÓDICO o en una REVISTA, pero nunca en ambos. Un ejemplo más sería el de los domicilios de los estudiantes universitarios durante el curso académico. Un ESTUDIANTE se puede alojar en un DOMICILIO_FAMILIAR, una RESIDENCIA_ESTUDIANTES o en un PISO_COMPARTIDO. Las tres relaciones que unen a ESTUDIANTE con las tres entidades serían exclusivas entre sí.
Otro ejemplo sería el de un ARTÍCULO que pudiera publicarse en un PERIÓDICO o en una REVISTA, pero nunca en ambos. Un ejemplo más sería el de los domicilios de los estudiantes universitarios durante el curso académico. Un ESTUDIANTE se puede alojar en un DOMICILIO_FAMILIAR, una RESIDENCIA_ESTUDIANTES o en un PISO_COMPARTIDO. Las tres relaciones que unen a ESTUDIANTE con las tres entidades serían exclusivas entre sí.
(*transparencia de introducción, todo lo que ella indica se trata con profundidad más adelante*) Especialización: Un ANIMAL es un FELINO Generalización: Un REPTIL es un tipo de ANIMAL; Un INSECTO es un tipo de ANIMAL
La entidad del subtipo representa la misma entidad que el supertipo, luego debe poseer valores para los atributos como miembro del supertipo, además de valores para los atributos específicos.
Todo lo que indiquemos en las transparencias siguientes acerca de Jerarquías y Retículas de Especialización es aplicable a Jerarquías y Retículas de Generalización.
Ojo: si un subtipo hereda por varios caminos distintos el MISMO atributo, el subtipo sólo los hereda una vez. Es el caso de los atributos “dni” o “nombre” en el caso de BECARIO, que los hereda por dos caminos: vía EMPLEADO y vía ESTUDIANTE. El conflicto surge cuando se heredan atributos DISTINTOS con el mismo nombre
La definición de un orden de prioridad lleva implícita la inhibición de la herencia de algunos atributos, que tratamos en la transparencia siguiente
Aplicable al caso de relaciones (en lugar de atributos).
Aplicable al caso de relaciones (en lugar de atributos).
Aplicable al caso de relaciones (en lugar de atributos).
IMPORTANTE: para que exista una instancia de una relación, es necesario que existan tres instancias vinculadas, una de cada entidad participante en la relación.
Aplicable al caso de relaciones (en lugar de atributos).
Aplicable al caso de relaciones (en lugar de atributos).
La clave parcial fecha indica que cada entrevista se identifica con (nombre, nif, fecha) lo que significa que un mismo candidato puede pasar varias entrevistas con la misma empresa, en días diferentes. Si la entrevista empresa/solicitante fuera única, ENTREVISTA no necesitaría clave parcial, por lo que “fecha” sería un atributo “normal”
Podemos considerar que esta manera de representarlo es “la mejor” desde nuestro punto de vista.
Podemos considerar que esta manera de representarlo es “la mejor” desde nuestro punto de vista.
El uso de una entidad adicional PROF/ASIG, débil de las otras dos sería equivalente al uso del agregado. Si se intentara solucionar empleando una RELACIÓN TERNARIA entre PROFESOR, ASIGNATURA Y MEDIO: No sería posible representar la situación de una asignatura para cuya explicación no se emplee ningún medio (pues para una instancia de relación se necesita una instancia de cada entidad participante). En el caso de que forzosamente se deba emplear al menos un medio, esta solución sí podría ser correcta. La diferencia entre agregación y relación ternaria es semántica o conceptual : Con la agregación se vincula por un lado a cada profesor con las asignaturas que imparte y, por otro lado, se liga cada par asignatura/profesor con el conjunto de medios empleados. Esto es lo que ocurre en la realidad: MEDIO se relaciona con el par profesor/asignatura, y no con profesor y asignatura por separado. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo ((profe, asig), medio). Con la relación ternaria se vinculan, a la vez, tres instancias: una de cada entidad participante. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo (profe, asign, medio).
El uso de una entidad adicional PROF/ASIG, débil de las otras dos sería equivalente al uso del agregado. Si se intentara solucionar empleando una RELACIÓN TERNARIA entre PROFESOR, ASIGNATURA Y MEDIO: No sería posible representar la situación de una asignatura para cuya explicación no se emplee ningún medio (pues para una instancia de relación se necesita una instancia de cada entidad participante). En el caso de que forzosamente se deba emplear al menos un medio, esta solución sí podría ser correcta. La diferencia entre agregación y relación ternaria es semántica o conceptual : Con la agregación se vincula por un lado a cada profesor con las asignaturas que imparte y, por otro lado, se liga cada par asignatura/profesor con el conjunto de medios empleados. Esto es lo que ocurre en la realidad: MEDIO se relaciona con el par profesor/asignatura, y no con profesor y asignatura por separado. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo ((profe, asig), medio). Con la relación ternaria se vinculan, a la vez, tres instancias: una de cada entidad participante. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo (profe, asign, medio).
El uso de una entidad adicional PROF/ASIG, débil de las otras dos sería equivalente al uso del agregado. Si se intentara solucionar empleando una RELACIÓN TERNARIA entre PROFESOR, ASIGNATURA Y MEDIO: No sería posible representar la situación de una asignatura para cuya explicación no se emplee ningún medio (pues para una instancia de relación se necesita una instancia de cada entidad participante). En el caso de que forzosamente se deba emplear al menos un medio, esta solución sí podría ser correcta. La diferencia entre agregación y relación ternaria es semántica o conceptual : Con la agregación se vincula por un lado a cada profesor con las asignaturas que imparte y, por otro lado, se liga cada par asignatura/profesor con el conjunto de medios empleados. Esto es lo que ocurre en la realidad: MEDIO se relaciona con el par profesor/asignatura, y no con profesor y asignatura por separado. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo ((profe, asig), medio). Con la relación ternaria se vinculan, a la vez, tres instancias: una de cada entidad participante. Para indicar que un profesor para una misma asignatura emplea “tantos” medios, se necesitan “tantas” instancias de la relación de tipo (profe, asign, medio).