2012-04-10 18 views
5

Estoy desarrollando un módulo de reserva para autobuses y tengo problemas para diseñar la estructura de base de datos adecuada para él.Diseño de base de datos para reserva de bus

Tomemos el siguiente caso:
Los autobuses van de la A a la D con escalas en B y C. Un pasajero puede reservar el billete para cualquier ruta, es decir. de A a B, de C a D, de A a D, etc.

De modo que cada ruta puede tener muchos "subroutes", y las más grandes pueden contener otras más pequeñas.

Quiero diseñar una estructura de tabla para rutas y paradas de una manera que ayudaría a buscar fácilmente asientos libres. Entonces, si alguien reserva asiento de A a B, entonces los asientos de B a C o D seguirían estando disponibles.

Todas las ideas serán apreciadas.

+0

¿Qué has probado? Edite su pregunta y pegue las instrucciones DDL (SQL CREATE TABLE) y algunos datos de muestra como instrucciones SQL INSERT. –

Respuesta

8

probablemente iría con una estructura de "fuerza bruta" similar a esta idea básica:.

enter image description here

(Hay muchos más campos que deben existir en el modelo real esto es sólo una versión simplificada que contiene lo esencial necesaria para establecer relaciones entre las tablas.)

el billete "covers" se detiene a través de la mesa TICKET_STOP, Por ejemplo, si un billete incluye 3 paradas, entonces TICKET_STOP contendrá 3 filas relacionadas con ese boleto. Si hay otras 2 paradas que no están cubiertas por ese ticket, no habrá filas relacionadas allí, pero no hay nada que impida que un ticket diferente cubra estas paradas.

El uso liberal o las claves naturales/relaciones de identificación aseguran que dos boletos no puedan cubrir la misma combinación de asiento/parada. Observe cómo LINE.LINE_ID "migra" a lo largo de ambos bordes de la dependencia en forma de diamante, solo para fusionarse en su parte inferior, en la tabla TICKET_STOP.

Este modelo, por sí solo, no lo protegerá de anomalías tales como un ticket único "omitiendo" algunas paradas: tendrá que aplicar algunas reglas a través de la lógica de la aplicación. Pero, debe permitir una determinación bastante sencillo y rápido de los cuales asientos están libres para qué partes del viaje, algo como esto:

SELECT * 
FROM 
    STOP CROSS JOIN SEAT 
WHERE 
    STOP.LINE_ID = :line_id 
    AND SEAT.BUS_NO = :bus_no 
    AND NOT EXIST (
     SELECT * 
     FROM TICKET_STOP 
     WHERE 
      TICKET_STOP.LINE_ID = :line_id 
      AND TICKET_STOP.BUS_ID = :bus_no 
      AND TICKET_STOP.TRIP_NO = :trip_no 
      AND TICKET_STOP.SEAT_NO = SEAT.SEAT_NO 
      AND TICKET_STOP.STOP_NO = STOP.STOP_NO 
    ) 

(Reemplazar el prefijo parámetro : con lo que es apropiado para su DBMS.)

Esta consulta básicamente genera todas las combinaciones de paradas y asientos para una línea y un autobús dados, luego descarta aquellos que ya están "cubiertos" por algún boleto en el viaje dado. Esas combinaciones que permanecen "descubiertas" son gratis para ese viaje.

Puede agregar fácilmente: STOP.STOP_NO IN (...) o SEAT.SEAT_NO IN (...) a la cláusula WHERE para restringir la búsqueda en paradas o asientos específicos.

5

Desde la perspectiva de la compañía de autobuses:

Por lo general, una ruta se considera como serie de secciones, como A a B, B a C, C a D, etc. El relleno se calcula en cada uno de las secciones por separado . Entonces, si el autobús sale de A completo, y la gente sale en C, entonces el usuario puede comprar el boleto en C.

Lo calculamos de esta forma, cada ruta tiene ID y cada sección pertenece a esta ID de ruta. Entonces, si el usuario compra un boleto para más de una sección, entonces cada sección está marcada. Luego, para el siguiente sistema de pasajeros verifica si todas las secciones a lo largo del camino están disponibles.

Cuestiones relacionadas