Question

Je dois stocker des événements planifiés (tels que des heures de cours, par exemple) qui peuvent être organisés sur une base hebdomadaire, quotidienne ou mensuelle. Des événements peuvent se produire, par exemple, tous les lundi et mercredi, ou tous les deuxièmes jeudis du mois. Existe-t-il un moyen de stocker ces informations dans un SGBDR conforme à 3NF?

EDIT: Ce n’est pas un devoir; Je construis quelque chose avec un ami pour notre propre édification et nous le voulons en 3NF.

Pour être précis, j'essaie de stocker les calendriers des temps de masse et de confession dans les paroisses de RC. Celles-ci peuvent être programmées de nombreuses manières différentes, par exemple tous les dimanches à x heure ou tous les mardi et jeudi à des heures différentes. Parfois, nous ne sommes que le troisième vendredi du mois, tandis que d’autres ne sont proposés qu’à une heure donnée une fois par an. Je dois non seulement stocker ces informations, mais aussi les interroger, de manière à pouvoir obtenir rapidement une liste complète des heures disponibles le lendemain, la semaine ou peu importe.

Je suppose que 3NF à proprement parler n'est pas une obligation, mais il serait plus facile pour nous si c'était le cas et il est préférable de corriger le problème dès le départ plutôt que de modifier notre schéma ultérieurement.

Était-ce utile?

La solution

Oui, j'ai résolu ce problème avec mon collègue de la manière suivante:

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] 

Une planification s'étend sur une période de temps et les intervalles se produisent pendant cette période. L’unité d’intervalle de planification détermine la durée de l’intervalle (en jours comme "tous les deux" (2) ou "tous les trois" (3), etc.), semaine (jour de la semaine, comme lundi, mardi, etc.). et mois (de l'année civile). Grâce à cela, vous pouvez effectuer des requêtes et une logique sur votre base de données pour récupérer des planifications.

Si vos calendriers requièrent une meilleure résolution (jusqu'à quelques heures, minutes, secondes), examinez l'implémentation Unix de cron . Au départ, j’ai commencé par cette voie, mais j’ai trouvé que ce qui précède était une approche beaucoup plus simpliste et facile à gérer.

Une seule date / heure (par exemple un semestre défini commençant le 9 septembre et se terminant le 4 novembre) peut contenir plusieurs horaires (donc tous les lundis pour les cours d'art et "tous les deux jours" pour Phys Ed), mais vous Vous devrez faire plus de travail pour prendre en compte les vacances et les week-ends!).

Autres conseils

Pour enregistrer les règles de "répétition périodique", inspirez-vous de crontab < Le format de / a>, sauf bien sûr que vous n’avez pas besoin de contraintes de minutes et d’heures, mais plutôt du jour de la semaine, du jour du mois, etc. Étant donné que plusieurs jours (par exemple, un jour de la semaine peuvent figurer dans la planification), pour les besoins de NF, vous voudrez utiliser des tables intermédiaires typiques pour représenter plusieurs relations, c'est-à-dire avec deux clés étrangères par ligne (une pour la table principale des événements). , un à une table des jours de la semaine) - et de même pour les jours du mois, etc.

Chaque événement programmé aurait probablement aussi une durée, une catégorie, peut-être un lieu, un nom ou une description.

" Comment normal " La forme (une fois que vous avez pris en charge les "ensembles" avec la relation multiple décrite ci-dessus) dépend principalement de la question de savoir si et comment ces différents attributs dépendent les uns des autres - par exemple, si chaque événement d'une catégorie donnée a le même effet. même durée, vous voudrez avoir une table auxiliaire séparée avec id, catégorie et durée, et utiliser des clés étrangères dans cette table plutôt que de répéter les informations appariées. Mais de ce que vous dites, je ne vois aucune violation intrinsèque des règles de forme normale, à l’exception de telles possibilités de dépendance (qui ne sont pas inhérentes à ce que vous avez spécifié à propos de la planification des événements).

scroll top