editar una tabla

[gnzsoloyo]

Una entidad débil, es cierto, no tiene una PK propia, sino que la hereda de una entidad superior, pero eso se produce a nivel lógico, en el modelado del sistema, y no es cierto a nivel de implementación física de tablas.
Lo que muy probablemente no tengas claro todavía es que existe un conjunto de pasos entre el modelado de entidades y la creación de una base física. No se puede transportar directamente un modelo E-R a un DBMS.
Por otro lado, el hecho de que herede una clave, no implica que la entidad en sí no la tenga. Todo lo contrario: no sólo tiene la clave heredada, sino que la PK es al mismo tiempo clave foránea (FK), y para ello deben existir los mismos campos de la PK referida, en del mismo tipo (dominio) y en el mismo orden de la clave PK de origen.
A este punto hay que hacer una aclaración más: Si bien es cierto que la entidad Habitación es una entidad débil, dependiente de Hotel, esa circunstancia no hace que la existencia del Hotel como FK/PK sea suficiente para identificar una única habitación en el conjunto de habitaciones. Se requiere sí o sí un discriminante, que compone la propia clave de la habitación: su número, o identificacion.
Este detalle surge inmediatamente a la vista cuando miras las cardinalidades de las relaciones: Un mismo hotel tiene N habitaciones, y cada habitación es de un único Hotel. Por consecuencia, se requieren dos atributos para identificar una habitación: El ID del Hotel, y el Id de la propia habitación.
A nivel de tabla física eso se representa así:

Código MySQL:

CREATE TABLE `habitacion` (
  `ID_HOTEL` INT UNSIGNED NOT NULL,
  `NRO_HABIT` INT UNSIGNED NOT NULL,
  `NOM_HABIT` VARCHAR(15) 
  `CLASE` varchar(15) DEFAULT NULL,
  `TIPO` varchar(15) DEFAULT NULL,
  `PRECIO` int(11) DEFAULT NULL,
  `PLANTA` varchar(8) DEFAULT NULL,
  `ESTADO` varchar(1) DEFAULT NULL,
  PRIMARY KEY(ID_HOTEL, NRO_HABIT),
  KEY `ID_HOTEL` (`ID_HOTEL`),
  CONSTRAINT `habitacion_ibfk_1` FOREIGN KEY (`ID_HOTEL`) REFERENCES `hotel` (`ID_HOTEL`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 

Este modelado requiere que la reserva también respete la consistencia referencial, por lo que la tabla de reservas debe forzosamente ser modificada:

Código MySQL:

CREATE TABLE `reserva_agencia` (
  ``RESERVA_ID` INT UNSIGNED NOT NULL,
  `ID_HOTEL` INT_UNSIGNED NOT NULL,
  `NRO_HABIT` INT UNSIGNED NOT NULL,
  `PLANTA` varchar(8) DEFAULT NULL,
  `CLASE` varchar(15) DEFAULT NULL,
  `TIPO` varchar(15) DEFAULT NULL,
  `PRECIO` int(11) DEFAULT NULL,
  `ID_AGENCIA` int(11) DEFAULT NULL,
  `FECHA_INI` date DEFAULT NULL,
  `FECHA_SALIDA` date DEFAULT NULL,
  PRIMARY KEY(RESERVA_ID), 
  KEY `ID_AGENCIA` (`ID_AGENCIA`),
  CONSTRAINT `reserva_habit_ibfk_1` FOREIGN KEY (ID_HOTEL, NRO_HABIT) REFERENCES `habitacion` (ID_HOTEL, NRO_HABIT)
  CONSTRAINT `reserva_agencia_ibfk_1` FOREIGN KEY (`ID_AGENCIA`) REFERENCES `agencia` (`ID_AGENCIA`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 

Aun hay mucho más, porque ninguna de estas tablas está normalizada, y desde le punto de vista de los sistemas reales, le alta bastante depuración, sin contar con la normalización.