Bases de Datos - Duda modelo E/R a relaciona

Buenos días,

Me cayó este modelo de E/R en el examen de oposición y no tengo muy claro como pasarlo a modelo relacional.
Sobre todo el tema de la generalización y la parte de la entidad de edición, que me despista que tenga ya un IdCurso, y que tenga que heredar otro de la relación 1:N que tiene con Curso,

¿Alguien podría ayudarme?
Muchísimas gracias de antemano

Para pasar al MER, básicamente debes tener en cuenta esto:

* Las entidades pasan a ser tablas en tu BD, valga decir: Persona, Alumno, Ponente, Curso, Categoria y Edicion.

* Los rombos que vienen a ser tus interrelaciones terminan siendo FK

Ver video en youtube:
https://www.youtube.com/watch?v=joYCYDK_Ndg&list=PLfKXnJPGTzkw2ax5KarYmhUYSWXh4TF8O&ab_channel=Nettorius

Te ayudo con una parte. Por lo que se alcanza a observar la tabla persona te debería quedar así:

CREATE TABLE Persona(
persona_id NUMBER (6) NOT NULL PRIMARY KEY,
nombre varchar (50) NOT NULL,
telefono varchar (11)
correo varchar(25) NOT NULL UNIQUE,
numero_cuenta (15) int NOT NULL,
tipo varchar (1),
CONSTRAINT CHK_Tipo CHECK (TIPO IN('A','P')));

Esto siempre y cuando Alumno y Ponente hereden de Persona, por ello lo del constraint CHK_Tipo para diferenciar uno del otro.

Por su parte Curso y Categoria te deberían quedar parecido a esto:

CREATE TABLE Categoria (
categoria_id NUMBER (4) NOT NULL PRIMARY KEY,
descripcion VARCHAR2 (255));

CREATE TABLE Curso (
curso_id NUMBER (4) NOT NULL PRIMARY KEY,
categoria_id NUMBER (4) NOT NULL,
nombre VARCHAR2 (50) NOT NULL UNIQUE,
precio decimal (5,2) NOT NULL,
horas int (2) NOT NULL),
CONSTRAINT FK_categoria FOREIGN KEY (categoria_id) REFERENCES categoria (categoria_id);

Y desde luego tendrás que crear una intermedia que normalice la relación entre Alumno y Curso, puesto que un alumno debería poder tomar varios curso al tiempo así:

CREATE TABLE Curso_Alumno (
curso_alumno_id NUMBER (10) NOT NULL PRIMARY KEY,
curso_id NUMBER (4) NOT NULL,
persona_id NUMBER (6) NOT NULL,
CONSTRAINT FK_Curso FOREIGN KEY (curso_id) REFERENCES Curso (curso_id),
CONSTRAINT FK_Alumno FOREIGN KEY (persona_id) REFERENCES Persona (persona_id),
CONSTRAINT UQ_Curso_Alumno UNIQUE (curso_id, persona_id));

Bien te queda faltando las relaciones entre curso y quien los dicta, donde también hay una relación muchos a muchos y deberás adecuar esto, y considero que en algunas entidades faltan atributos

Finalmente los scripts de la BD que responde a ese MER que visualizas, deberían quedar así:

CREATE TABLE Persona(
persona_id int (6) NOT NULL PRIMARY KEY AUTO_INCREMENT,
nombre varchar (50) NOT NULL,
telefono varchar (11),
correo varchar(25) NOT NULL UNIQUE,
numero_cuenta int (15) NOT NULL,
tipo varchar (1),
CONSTRAINT CHK_Tipo CHECK (TIPO IN('A','P')));

CREATE TABLE Categoria (
categoria_id int (4) NOT NULL PRIMARY KEY AUTO_INCREMENT,
descripcion VARCHAR (255));

CREATE TABLE Curso (
curso_id int (4) NOT NULL PRIMARY KEY,
categoria_id int (4) NOT NULL,
nombre VARCHAR (50) NOT NULL UNIQUE,
precio decimal (5,2) NOT NULL,
horas int (2) NOT NULL,
CONSTRAINT FK_categoria FOREIGN KEY (categoria_id) REFERENCES Categoria (categoria_id));

CREATE TABLE Especialidad(
especialidad_id int (4) NOT NULL PRIMARY KEY AUTO_INCREMENT,
nombre varchar(50) NOT NULL UNIQUE);

CREATE TABLE Ponente_Especialidad(
Ponente_Especialidad_id int (4) NOT NULL PRIMARY KEY AUTO_INCREMENT,
persona_id int(6) NOT NULL,
especialidad_id int(4) NOT NULL,
CONSTRAINT FK_Ponente FOREIGN KEY (persona_id) REFERENCES Persona (persona_id),
CONSTRAINT FK_Especialidad FOREIGN KEY (especialidad_id) REFERENCES Especialidad (especialidad_id),
CONSTRAINT UQ_Ponente_Especialidad UNIQUE (persona_id, especialidad_id));

CREATE TABLE Edicion(
edicion_id int (4) NOT NULL PRIMARY KEY AUTO_INCREMENT,
alumno int(6) NOT NULL,
ponente int(6) NOT NULL,
curso_id int(4) NOT NULL,
fecha_inicio date NOT NULL,
fecha_fin date NOT NULL,
pagado bit NOT NULL default 0,
fecha_inscripçion timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT FK_CursoED FOREIGN KEY (curso_id) REFERENCES Curso (curso_id),
CONSTRAINT FK_AlumnoED FOREIGN KEY (alumno) REFERENCES Persona (persona_id),
CONSTRAINT FK_PonenteED FOREIGN KEY (ponente) REFERENCES Persona (persona_id));

Y te darían un MER similar a este implentado en MariaDB

Gracias por la respuesta,
Pero mi principal duda es en la entidad de edicion, si observas, tiene en el modelo E/R, como calve primaria, el numero de edicion y el IDCurso, pero luego por la relacion 1:N que tiene de curso, debería hereredar otro IdCurso, no?
Con lo cual, nos juntaríamos con dos IDCurso en la tabla Edicion, que podría pasar, pero no le encuentro mucho sentido.

Gracias

El número de edición es el que se llamó como edición_id y por supuesto actúa como clave primaria.

Efectivamente puede aparecer el mismo curso_id, pero desde luego con un ponente diferente.

Es posible que un curso X con fecha y hora de inicio se repita en esa misma fecha y horario pero nunca con el mismo tutor.

Es decir, podría perfectamente darse esto:

Curso 01 = Informática Básica
Tutor (Ponente) =101: Alejandro Vargas
Fecha Inicio: 22/03/2023
Hora: 8.00 .A.M.

Curso 01 = Informática Básica
Tutor (Ponente) = 102: Jorge Palomino
Fecha Inicio: 22/03/2023
Hora: 8.00 .A.M.

Tu tabla quedaría así:

edicion_id alumno ponente curso_id fecha_inicio fecha_fin pagado fecha_inscripçion
1, 200, 101, 01, 2023-03-22 08:00:00.000, 22/04/2023, 1, 22/03/2023
1, 300, 102, 01, 2023-03-22 08:00:00.000, 22/04/2023, 1, 22/03/2023

Conveniente es crear un constraint de tipo unique para el curso, el tutor y la fecha, que queda actuando igual como otra clave primaria de tipo unique, así:

CONSTRAINT UQ_Horario UNIQUE (curso_id, ponente, Fecha)

Desde luego esta ni es la única ni la mejor manera de modelar lo que pretendes, hay muchas más, todo depende del enfoque que tengas y las restricciones propias de este sistema.

Pero lo que si es indiscutible es que categóricamente en una hora y fecha especifica, un tutor solo puede estar dictando UNO y SOLO UN curso.

Bueno, lo he resuelto y a mi me saldría algo como esto, no es parecido a lo vuestro:

Muy malo eso que estás planteando

Tiene la entidad alumno con un solo atributo

Si te preguntan por los datos del estudiante x que esté matriculado en un curso y

Cómo construyes el query.

SI consideras que lo que tienes está bueno, intenta construir los querys haber como te devuelven algo.....

Un alumno solo puede estar cursando uno y solo un curso en una hora especifica
Un ponente solo puede dictar uno y solo un curso en una hora especifica
Otra cosa es que yo como alumno pueda matricular varios cursos (Pero siempre en horas diferentes), igual ocurre con el tutor que puede dictar varios cursos pero en horas diferentes

NO has entendido nada verdad?

Suena un poco borde tu comentario.
Me ha generado así el modelo, aunque en realidad la entidad alumno no existe, más bien sería:

create table alumno (
id int primary key auto_increment,
nombre varchar(200),
telefono varchar (20),
correo varchar(200),
numeroCuenta varchar(200)
);

create table ponente (
id int primary key auto_increment,
nombre varchar(200),
telefono varchar (20),
correo varchar(200),
numeroCuenta varchar(200),
especialidad varchar(200)
);

create table categoria (
id int primary key auto_increment,
descrpcion varchar(255)
)
;
create table curso (
id int primary key auto_increment,
horas int,
precio double,
nombre varchar(200),
id_categoria int,
foreign key (id_categoria) references categoria (id)
);

create table edicion (
id_curso int,
num_edicion int,
fechaInicio date,
fechaFin date,
id_ponente int,
organizada_en_curso_id int,
primary key (id_curso, num_edicion),
foreign key (id_ponente) references ponente(id),
foreign key (organizada_en_curso_id) references curso(id)

);


create table participacion (
id_alumno int,
id_curso int,
num_edicion int,
pagado boolean,
fechaInsc date,
primary key (id_alumno, id_curso, num_edicion),
foreign key (id_alumno) references alumno(id),
foreign key (id_curso, num_edicion) references edicion(id_curso, num_edicion)
);


Es más , lo he he hecho estrictamente sacado el modelo relacional del entidad relacion, aplicando las normas de transformación.
¿Dónde está el error?

Por cierto..... se escribe A VER.....

Te falta mucho camino por recorrer

Cuando se modela un MER se visualiza internamente como se comportará, que devuelven los querys, que información trae con base en ese modelo

A VER.....

vaya a darle clases de gramática a su gran...