Duda esquema entidad-relacion

[Tram]

Hola a todos,

Hasta ahora tengo modelado lo siguiente:
Tengo una página web donde hay usuarios expertos y usuarios normales, y un administrador.
Los usuarios normales y expertos registran sitios web para que sean evaluados, y el administrador hace varias cosas como por ejemplo insertar/borrar/modificar usuarios en la base de datos, i/b/m las noticias que aparecen en la web, i/b/m los sitios web registrados, etc.
Mi problema es que no sé cómo incluir al Administrador en el esquema, puesto que también es un tipo de usuario pero los otros usuarios no tienen esas funciones.

Este es parte del esquema que tengo hasta ahora, aunque me falta incluir la tabla Noticia (el administrador inserta-modifica-borra noticias) y relacionarla con el Administrador.

[santris]

Hola,

Creo que tendrías que hacer una especialización:

[Tram]

Sería válido que normal, admin y experto tuvieran exactamente los mismos atributos que usuario? o deberían tener alguno que los diferencie de la entidad usuario?
Y otra pregunta, cuando un usuario normal o un usuario experto se registre en la aplicación, dónde se guardan sus datos? En sus tablas correspondientes? La tabla usuario no tendría datos almacenados?

[santris]

Iniciado por Tram

Sería válido que normal, admin y experto tuvieran exactamente los mismos atributos que usuario? o deberían tener alguno que los diferencie de la entidad usuario?
Y otra pregunta, cuando un usuario normal o un usuario experto se registre en la aplicación, dónde se guardan sus datos? En sus tablas correspondientes? La tabla usuario no tendría datos almacenados?

Eso ya pertenece a la fase física del diseño:

Todos los usuarios usan los mismos atributos comunes definidos en el entidad USUARIOS (nombre, email, edad, etc....)
En las entidades NORMAL, ADMIN, EXPERTO defines los atributos especificos para estas entidades (experiencia, permisos, etc.).

La forma de definir la relación depende de:
Si todos los usuarios del tipo -por ejemplo admin- tienen los mismos permisos, esperiencia, etc., puedes crear un atributo(Tipo_usuario) en la entidad USUARIO ej. User1 ----- Admin

Si cada usuario del tipo -por ejemplo admin- tienen permisos, experiencia, ete. diferentes, puedes crear otra tabla (especialización) que los relacione ej. User1--- CodeAdmin; User2--- CodeAdmin etc.


Ejemplo de tablas (solo para admin y con pocos atributos).

[Tram]

Gracias por las ideas.

He modificado el esquema y ahora lo tengo así:



Normal, admin y experto tienen también los atributos login y password.

La tabla GRUPO que tenía al inicio, ya no me hace falta en este esquema verdad? Porque si quiero obtener una lista con todos los nombres de usuarios expertos, haría la consulta sobre la tabla EXPERTO, y al inicio tenía que hacerla sobre la tabla USUARIO donde el idgrupo fuera "experto".
La tabla SITIO tendría como clave primaria la url del sitio, y como foránea el login del usuario. Si quisiera saber los sitios registrados por usuarios expertos, cómo sería la consulta?

[santris]

Según el diagrama que has realizado, entiendo que solo tienes un tipo de admin, experto y normal, quiero decir: no existen administradores totales, administradores de grupo, expertos en uno u otro tema etc.

Por otro lado el modelo que estás desarrollando tiene sentido si las entidades o subclases que derivan de la clase USUARIO tienen atributos diferentes, por ejemplo: imagina que solo los administradores del sitio necesitan tener registrado un teléfono de contacto obligatoriamente, puesto que ese atributo no puede pertenecer a la entidad USUARIO creamos una entidad llamada ADMIN donde insertaremos ese atributo.
En resumen, una especialización es una extensión de ciertas instancias de una clase. No tiene sentido incluir atributos en la subclase si ya están definidos en la clase (solo los identificadores para crear la relación).
Con este modelo te aseguras la escalabilidad del proyecto, ya que tienes una estructura definida y preparada para futuros cambios. La idea es definir en cada entidad los atributos necesarios y crear tantas entidades como sea necesario, ya lo dijo JC “Divide et vinces”.

Después de la parrafada te comento como veo tu esquema:

No es necesaria la entidad GRUPO ya que has dividido los usuarios en especializaciones, a lo sumo si quieres puedes poner un atributo en la entidad USUARIO llamado TipoUsuario que coja como posibles valores (admin, experto, normal) aunque no es necesario.

No es necesario incluir de nuevo el atributo passw en las entidades NORMAL, ADMIN y EXPERTO ya que está definido en la entidad USUARIO.

La interrelación registra la veo correcta ya que todos los usuarios 'en principio' pueden registrar un/os sitio/s.

La interrelación gestiona la veo correcta ya que solo los administradores pueden gestionar noticias.

La consulta para saber cuales son los sitios registrados por los usuarios expertos sería:

involucramos tres tablas experto, usuario y sitio

SELECT experto.login, usuario.nombre, sitio.url FROM (experto INNER JOIN usuario ON experto.login = usuario.login) INNER JOIN sitio ON usuario.login = sitio.login

si quieres poner una condición agregas un where al final

SELECT experto.login, usuario.nombre, sitio.url FROM (experto INNER JOIN usuario ON experto.login = usuario.login) INNER JOIN sitio ON usuario.login = sitio.login WHERE experto.login = condición

Saludos

[Tram]

Muchas gracias por la explicación

Entonces si por ejemplo un usuario experto se registra, debería insertarlo en la tabla experto y también en la usuario no? Osea cada vez que se registra alguien, inserto en dos tablas.

En mi caso las entidades que derivan de usuario no tienen más atributos, tienen los mismos que USUARIO. Quizás en este caso sería mejor dejar el esquema inicial y simplemente poner una entidad ADMINISTRADOR aparte relacionada con las noticias?

[Tram]

Otra pregunta, independientemente de si pongo Administrador como derivada de Usuario, o como entidad aparte:
- El administrador inserta/borra/modifica usuarios y noticias. Cómo plasmo esto en el diagrama?
- La relación "gestiona" entre Administrador y Noticias tiene sentido? Es decir, si es una relación N a N y creo una tabla para "gestiona" allí almacenaría el login del administrador y el id de la noticia pero esa información no me serviría para nada.

[elkilate22]

hola amigo pero tengo una duda sobre este E/R.....veamoslo desde este angulo....como pondrias al usuario q solo visita el portal y no se registra...recordemos q tambien es un usuario que no tendria los atributos password ni loggin ayudame en esa.... o tendria q ponerle una entidad a parte para este usuario ya q no caberia en la especializacion.....hecha anteriormente