El dí­a a dí­a del modelado Entidad-Relación. Enunciado.

[Actualizado a 05/10/2008]
A continuación os planteo un tí­pico problema de modelo entidad-relación en base de datos, en el que se debe modelar una situación bastante comíºn en un desarrollo de software. Os pedirí­a que intentarais resolver el problema sin ver antes las tres soluciones que marco al “ejercicio” en la parte final del post, y comprobar así­ finalmente cuál ha sido el tipo de solución más habitual. Os agradecerí­a además que razonarais la respuesta. En el caso de que vuestra solución no se ajuste a ninguna de las tres descritas, por favor, enviadme un diagrama a info@miguelmatas.es para que pueda adjuntarla al artí­culo. Serí­a estupendo además que en el razonamiento de vuestra solución no se limitara a las razones estrí­ctamente del modelo y la base de datos, si no que estuviera acompañada de algíºn razonamiento relacionado con arquitectura de software, orientación al negocio, eficiencia a nivel de datos, protección del dato, etc. En el caso de que no queráis “perder” tanto tiempo, me doy por satisfecho si contestáis al post indicando si vuestra solución se acerca a una de las tres primeras o ha sido otra 🙂
Gracias!
Enunciado:
Una conocida empresa de Rent a Car quiere informatizar su sistema de gestión de vehí­culos. En esencia, dicha empresa alquila de forma temporal los coches de los que dispone, y, en un primer proceso de ingenierí­a necesita contar con una descripción técnica de cómo se almacenarí­an el repositorio de los diferentes coches con los que cuenta en cartera.
La empresa cuenta con diferentes tipos de coches, son realmente los tipos de coches que maneja lo que la diferencia de los Rent a Car al uso, ya que los usuarios tienen la oportunidad de alquilar coches anfibios, coches voladores y coches oficiales blindados. Estos tres tipos de coche tienen algunas caracterí­sticas en comíºn que se desean conocer, como son la matrí­cula, el níºmero de puertas y la marca. Además, de forma especí­fica se necesita conocer el máximo de nudos a la hora a la que puede navegar un coche anfibio, los milí­metros de blindaje y el tipo de blindaje de un coche oficial blindado, y la autonomí­a de horas de vuelo con las que cuenta un coche volador.
Posibles soluciones de modelado entidad-relación:
Os pedirí­a por favor que no consultarais las soluciones hasta que hayáis desarrollado vuestra propia solución, para así­ no interferir en el resultado.
Solución 1
Solución 2
Solución 3
Solución 4 [nuevo 05/10/2008]
Saludos y gracias 🙂
Miguel.

4 thoughts on “El dí­a a dí­a del modelado Entidad-Relación. Enunciado.”

  1. Yo habí­a pensado algo que se parece claramente a la tercera opción, está claro que habrí­a que saber algo más del proyecto como dimensiones y demás para poder tomar ese tipo de decisiones, pero yo apuesto por la tercera, es la fácil de implementar.
    Un saludo

  2. Añado una cuarta posible solución al problema, esta vez, utilizando un campo del tipo XML donde almacenar la información especí­fica del coche (gracias David).
    Como reflexión y para seguir enriqueciendo el artí­culo, tal vez el tipo de blindaje podrí­a ser una caracterí­stica propia de cualquier coche, ya que a priori cualquier tipo de coche podrí­a ser blindado en un momento dado. Por este motivo, IdTipoBlindaje podrí­a añadirse directamente a la tabla Coche, en lugar de ser una caracterí­stica propia de los coches oficiales. Realmente aumenta la flexibilidad del modelo (gracias Roberto).
    Son bienvenidas nuevas reflexiones, ya sé que la información para tomar la decisión es bastante reducida, pero podéis incorporar a vuestras decisiones ciertos condicionantes propios para definir en qué casos tomarí­ais cada una de vuestras decisiones.
    Saludos y gracias por las aportaciones.
    Miguel.

  3. He pensado una cosa parecida a la del xml pero con una pequeña mejora.
    Propongo 3 tablas.
    La primera serí­a parecia a la de coche desnormalizado, con caracteristicas comunes a todos los coches.
    La segunda seria una tabla de textos o propiedades. Guardarí­a las propiedades especificas de todos los coches.
    Hasta aqui no aporto ninguna mejora al xml.
    La tercera, podriamos añadir una tabla de parametrización. En esta tabla guardarí­amos la información de las propiedades por tipo de coche o por ejemplo si son obligatorias u opcionales o cualquier otra cosa que podamos necesitar.
    Un procedimiento almacenado se encargaria de garantizar la integridad de los datos introducidos.
    Esta forma nos permite que por ejmplo podamos añadir propiedades nuevas obligatorias o incluso definir nuevos tipos dinamicamente.
    Saludos.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.