Duda Entidad Relación: dado polifacético

[Saito_25]

Buenas, chapuzas.

Necesito ayuda para definir una entidad en el diagrama Entidad-Relación. Os estaría muy agradecido si me la brindáis. menciono a josejfernandez , que siempre suele ser de mucha ayuda en esta sección del foro.

Veréis, estoy desarrollando una aplicación para tener una hoja de rol en tu móvil. Entre otras, existe la entidad dado. Pero dicho dado, no tiene por qué tener 6 caras y cada cara un valor numérico. Puede tener tantas caras como quiera y cada cara estará representada por un String (que será el valor que se muestre al usuario) y un valor numérico (que será usado para determinar qué valor ha salido).

La cuestión es que no sé llevar esto a una entidad, porqué creo que no se puede definir algo como list<String>, en el modelo Entidad-Relación, ¿no?

 

[Synchronized]

Yo haría un atributo numeroCaras en la entidad dado y calcular la cara que ha salido de manera pseudoaleatoria mediante una función utilizando dicho número de caras.
Ej: 10 caras, 1 + rand() % 10
Luego puedes ir haciendo un histórico de resultados (entidad), mostrar al usuario o lo que veas conveniente.

 

[josejfernandez]

Hola. Gracias por la mención, compañero

Tú mismo has escrito la solución en tu enunciado: un dado (entidad Dice) puede tener varias caras (entidad DiceSide). La entidad DiceSide tiene un atributo de tipo texto DisplayValue y uno numérico RawValue. Escrito de otro modo:

Dice -- 1:N -- DiceSide

DiceSide
- DisplayValue (text)
- RawValue (number)

La regla -mnemotécnica- general es que cuando te veas almacenando una lista -de longitud variable- de cosas dentro de una misma entidad, probablemente esas cosas son otra entidad en si misma.

 

[Saito_25]

Muchas gracias, jose y syncronized. La verdad es que era una tontería, pero llevo bastante sin ver bases de datos y me estoy dando de palos para realizar la base de datos de la aplicación.

Tengo una duda un poco más compleja a mi parecer. Llevo un tiempo pensando cómo podría hacerse, pero no termino de verla. La pongo por aquí y si puedes (o cualquier otro compañero) ayudarme, lo agradecería bastante.

Verás, la aplicación tiene items/objetos, los cuales tienen unas características comunes: id, nombre, descripción, peso, precio. Dentro de dichos objetos, creo que existen subobjeto (digo creo porque no veo una forma mejor de abordar el tema, sino es usando generalización).

Estos subobjetos los he dividio en armas y armaduras. Por tanto, un objeto puede ser un arma, una armadura o ninguno de los dos.

Podríamos tener: pocima (objeto), espada (objeto -> arma), armadura completa (objeto -> armadura), para que te hagas una idea.

Dentro de las armas, existen dos tipos: a distancia o cuerpo a cuerpo aquí tengo una duda: ¿el tipo de arma, debería ser un subtipo de arma o con un enum basta? Las armas a distancias necesitan munición, la cuál se debería llevar encima para poder usarla. Esta munición no deja de ser un objeto en sí mismo, pero no sé si debería ser un subtip de objeto, ya que solo se debería poder equipar un objeto munición a un arma a distancia.

Esto lo digo porque luego, el usuario podrá especificar qué tipo de munición puede usar un arma a distancia.

Gracias por cualquier ayuda/consejo.

 

[Synchronized]

Arma, armadura y demás yo lo pondría como atributos tipoObjeto en Objeto y haría tabla tipoObjeto con los tipos de objeto que pueden existir, para evitar complicaciones esta tabla podría tener directamente una entrada ArmaADistancia y otra ArmaCuerpoACuerpo haciendo que estos sean simplementes tipos de objetos en lugar de tipos de armas que son a su vez un objeto, aunque también se podría implementar así si quieres.

 

[josejfernandez]

Aunque parezca una obviedad, tu modelo de datos debe adaptarse a los requisitos, no al revés, por lo tanto la primera parte del proceso es definir bien qué quieres almacenar y cómo vas a trabajar con los datos.

Por ejemplo: ¿el tipo de arma debe ser un enum o una entidad? Pues depende de cómo quieras manipular los datos en tu programa.

• ¿Vas a tener tipos de los cuales quieres almacenar información? Podrías querer esto si vas a tener una cantidad inicialmente desconocida de tipos o si vas a aumentarla con el tiempo, de forma que la lógica tratará los tipos como un dato más. En este caso te interesa que el tipo sea otra entidad.
• ¿Vas a tener unos pocos tipos y sólo te interesa saberlos para mapearlos a una lógica concreta? ¿No vas a añadir tipos? Podrías querer esto si simplemente quieres que el tipo sea un atributo (para mostrar un icono, un color, por ejemplo) o si vas a tener un número concreto, definido e invariable de tipos, o si no vas a necesitar almacenar NADA de esos tipos.

La cosa es que no hay una solución correcta o incorrecta desde el punto de vista del modelo de datos. El modelo de datos va después de definir todo lo demás la clave es analizar qué quieres hacer y cómo esperas que cambie con el tiempo, y definir el modelo de datos en base a ello.

¿Un consejo rápido? Yo lo haría una entidad aparte. ¿Por qué? Pues porque si lo haces así desde el principio, tienes el comportamiento enum si quieres (simplemente hardcodea los tipos disponibles) pero también tienes la posibilidad de personalizar los tipos, añadirles metadatos (necesita munición, es intercambiable, posibilidades de aparecer al derrotar a un enemigo... por ejemplo) y modificar la lista de tipos sin tocar el código.

Pero podrías venir y decir "mira, esto es un proyecto rápido, vamos a tener pociones, espadas y arcos, fin, paso de meter otra entidad para eso" y sería correcto y perfectamente razonado.

 

[Saito_25]

Ojalá fuera un proyecto rápido T-T.

Es el proyecto de fin de ciclo de grado superior y llevo como 30 pantallas de diseño hechas y la que me queda. Se me fue la cabeza cuando pensé en qué quería hacer.

Muchas gracias, Jose, por la ayuda. La verdad es que nunca lo había pensado de esa manera y me parece muy útil e interesante lo que me has dicho.

Tengo a medio terminar la base de datos de la aplicación a desarrollar. La dejo por aquí solo por si queréis echarle un vistazo. Y, bueno, lo típico, si véis algo mejorable y me lo decís os lo agradecería mucho.

entidad-relacion.svg

drive.google.com