¿Cómo se representarían los eventos programados en un RDBMS?

Question

Tengo que almacenar eventos programados, (por ejemplo, horas de clase, por ejemplo) que se pueden organizar de forma semanal, diaria o mensual. Los eventos pueden ocurrir, por ejemplo, todos los lunes y miércoles, o cada segundo jueves del mes. ¿Hay alguna forma de almacenar esta información en un SGBDR que se adhiera a 3NF?

EDITAR: Esto no es tarea; Estoy construyendo algo con un amigo para nuestra propia edificación y lo queremos en 3NF.

Para ser específico, estoy tratando de almacenar los horarios de misas y confesiones en las parroquias de RC. Se pueden programar de muchas maneras, como cada domingo a la vez x o cada martes/jueves a una hora diferente. Algunas veces es solo el tercer viernes del mes, y otras solo se ofrecen en cierto momento una vez al año. Necesito no solo almacenar esta información, sino consultarla, de modo que pueda obtener rápidamente una lista completa de los horarios disponibles en el día o la semana siguientes o lo que sea.

Supongo que, estrictamente hablando, 3NF no es un requisito, pero sería más fácil para nosotros si lo fuera y es mejor corregirlo desde el principio que cambiar nuestro esquema más adelante.

Answer 1

Sí me han resuelto este problema con mi compañero de trabajo de la siguiente manera:

CREATE TABLE [dbo].[Schedule](
    [ID] [int] IDENTITY(1,1) NOT NULL, 
    [StartDate] [datetime] NOT NULL, 
    [EndDate] [datetime] NULL 
) 

CREATE TABLE [dbo].[ScheduleInterval](
    [ID] [int] IDENTITY(1,1) NOT NULL, 
    [ScheduleID] [int] NOT NULL, 
    [ScheduleIntervalUnitID] [int] NOT NULL, 
    [Interval] [smallint] NOT NULL 
) 

CREATE TABLE [dbo].[ScheduleIntervalUnit](
    [ID] [int] NOT NULL, 
    [Name] [varchar](50) NULL 
) 

INSERT INTO ScheduleIntervalUnit (ID, Name) 
SELECT '1' AS [ID], 'Day' AS [Name] UNION ALL 
SELECT '2' AS [ID], 'Week' AS [Name] UNION ALL 
SELECT '3' AS [ID], 'Month' AS [Name] 

Un horario se extiende por un período de tiempo y los intervalos se producen dentro de ese periodo de tiempo. La unidad de intervalo de programación determina la duración del intervalo (días como "todos los demás" (2) o "cada tres" (3) etc.), semana (día de la semana, como lunes, martes, etc.) y mes (del año calendario). Con esto puede realizar consultas y lógica en su base de datos para recuperar programas.

Si sus programaciones necesitan una mejor resolución, hasta horas, minutos, segundos, consulte la implementación de Unix de cron. Originalmente comencé por esa ruta, pero descubrí que lo anterior es un enfoque mucho más simplista y sostenible.

Un lapso de fecha/hora único, como un semestre escolar definido que comienza el 9 de septiembre y finaliza el 4 de noviembre, puede contener varios horarios (por lo que todos los lunes para la clase de arte y "cada dos días" para Phys Ed). ¡Tendré que trabajar más para considerar las vacaciones y los fines de semana!).

Answer 2

Para registrar las reglas de "repetición periódica", puede inspirarse en el formato crontab, excepto, por supuesto, que no necesita restricciones en minutos y horas, sino día de la semana, día del mes y me gusta. Como puede haber más de un día de la semana en la programación, para propósitos de NF querrá que las tablas intermedias típicas se usen para representar muchas relaciones, es decir, una con solo dos claves foráneas por fila (una para la tabla principal de eventos) , uno para una mesa de entre semana) - y, por supuesto, para los días del mes, y similares.

Es de suponer que cada evento programado también tendrá una duración, una categoría, tal vez una ubicación, un nombre o una descripción de descripción.

"How normal" es la forma (una vez que se ha ocupado de los "conjuntos" con la relación many-many mencionada anteriormente) depende principalmente de si y de cómo estos diversos atributos dependen el uno del otro - por ejemplo si cada evento en una cierta categoría tiene la misma duración, querrá tener una tabla auxiliar separada con id, categoría y duración, y usar claves externas en esta tabla en lugar de repetir la información emparejada. Pero por lo que dices, no veo ninguna violación intrínseca de las reglas de forma normal, salvo las posibilidades de dependencia (que no son inherentes a lo poco que has especificado sobre la programación del evento).