Entidad sin clave foránea

[elchapitas]

Estoy representando un diagrama entidad relación y en él aparece una entidad que almacenará datos temporales. Por ejemplo, supongamos una entidad para almacenar temporalmente datos de una una persona.

¿Sería correcto representar el diagrama Entidad-Relación con esa clase suelta, sin ninguna interrelación con otra entidad?

¿Y en el modelo relacional, teniendo en cuenta que no tendrá ninguna clave foránea?

[gnzsoloyo]

Una tabla temporal no existe en el modelo de datos. Es una representación del funcionmiento de los procesos del sistema, y la base sólo contiene los objetos persistentes.
Más alla de que no tenga una FK, si no tiene persistencia, ni relación con el resto de las entidades, no pertenece a la base.
Es lo mismo que plantearse si las tablas creadas en un SP y destruidas lueg de su terminación corresponden a la base: NO. No son parte del ssitema sino de un proceso, y la base no representa procesos.

[elchapitas]

Iniciado por gnzsoloyo

Una tabla temporal no existe en el modelo de datos. Es una representación del funcionmiento de los procesos del sistema, y la base sólo contiene los objetos persistentes.
Más alla de que no tenga una FK, si no tiene persistencia, ni relación con el resto de las entidades, no pertenece a la base.
Es lo mismo que plantearse si las tablas creadas en un SP y destruidas lueg de su terminación corresponden a la base: NO. No son parte del ssitema sino de un proceso, y la base no representa procesos.

Respecto a lo de temporal, no me refiero a que no tenga persistencia, si que la tendría, durante un par de días por ejemplo. La idea es usar una tabla "JugadorTemp" que almacene los datos de un jugador que se registre en una plataforma hasta que este se valide, durante este periodo la información es persistente. Cuando el jugador se valide, la información del jugador en "JugadorTemp" se borrará y se guardará en la tabla "Jugador".

¿Aún especificando esto último no se consideraría la clase "JugadorTemp" como parte del modelo de datos?

Muchas gracias.

[gnzsoloyo]

Lo que no debería existir es la tabla JugadorTemp, sino un atributo en Jugador que establezc su validación o su baja por falta de validación...
A mi entender lo estás planteando mal, incluso procedimentalmente, porque la eliminacion de la primera etapa de datosimpediría cualquier trazabilidad posterior de los registros y actividades de ese jugador.

[Libras]

aqui lo que se podria sugerir es que la tabla temporal no se elimine de la base de datos, sino que simplemente se borren los datos que tiene, estarias usando una famosa tabla de "stage" :P aunque la idea de gnzsoloyo me parece mejor

[elchapitas]

Lo que comentas, fue mi primer opción pero la deseche cuando pensé que tendría que añadir dos atributos a la entidad "Jugador", uno sería el código de verificación y otro uno que establezca su validación. El problema es que cuando se fueran validando los jugadores tendría multitud de registros con dos atributos nulos, quizás reservando de alguna forma espacio.

De la forma que te comentaba tendría la tabla "Jugador" con dos atributos menos, y la tabla "JugadorTemp" solo con los jugadores no validados.

En cuando a la trazabilidad no sería problema, primero se registra la información del jugador en la tabla "Jugador" y luego se borra el registro de la tabla "JugadorTemp".

Entiendo tú respuesta, y me está ayudando mucho a pensar, pero en aras de aprender, sigo con la duda de que si lo que planteo es posible, o por mucho que me empeñe es inviable. Funcionar funciona, el problema sería a la hora de "documentar".

[gnzsoloyo]

En primer lugar, los datos indicados serían numéricos, por lo que el espacio usado no representa un problema, ni aunque tengas 20 millones de asociados.
En segundo, no serían nulos en ningún momento, por cuando si están validados sería 1, y si no, 0. Con un campo BIT alcanza y sobra para ese estado, que además permitiría otro tipo de reportes. El de fecha, adiciona trazabilidad, y sería un DATE (3 bytes), con lo que no afecta la performance.
La verdad me parece innecesria la tabla tempora, porque no agrega nada de ventajas, y sólo sirve para complicar las consutlas y procesos que existan.
El que se agregue o no al diagrama es irrelevante en ese punto, y contraproducente porque adiciona un riesgo de consistencia si hay fallas de procesamiento eventuales, pro las razones que fuesen.
Entre otras objeciones, cualquier alta requiererá una doble valdiación, una apra cada tabla, porque no podrías asegurar que el nuevo jugador no se haya registrado sin validar todavía anteriormente...
Como dije, no le encuentro utilidad, y si muchos riesgos para la performance y la consistencia.

[elchapitas]

Pues viéndolo así con mas detalle, no tengo nada más que decir, tienes toda la razón del mundo.

Me has ayudado mucho, muchísimas gracias.