Bonsoir,
Envoyé par
SQLpro
Une remarque d'intérêt général...
ON NE MODÉLISE PAS UNE PÉRIODE AVEC DEUX DATES... On modélise une période avec une date de début et une durée en unité de temps.
Dans l’état de nos SGBD SQL, on ne peut pas te donner tort, mais si l’on se cale sur le modèle relationnel de données, on devrait plutôt modéliser un intervalle de dates !
Ainsi, dans le cadre du modèle relationnel de données, pour historiser les statuts des clients, je n’écris ni :
VAR Client_historique BASE RELATION
{
Client_id INT,
Statut INT,
Date_debut DATE,
Date_fin DATE
}
KEY {Client_id, Date_debut} ;
VAR Client_historique BASE RELATION
{
Client_id INT,
Statut INT,
Date_debut DATE,
Duree_jour INT
}
KEY {Client_id, Date_debut} ;
VAR Client_historique BASE RELATION
{
Client_id INT,
Statut INT,
Durant INTERVAL_DATE
}
USING (Durant) : KEY {Client_id, Durant} ;
Je n’ai pas à savoir si sous le capot la représentation interne (encapsulation) est faite au moyen d’une date de début et d’une date de fin, ou d’une date de début et d’une durée... J’utilise seulement les opérateurs mis à ma disposition pour le type INTERVAL_DATE (INTERVAL est un générateur de type, spécialisable par exemple en INTERVAL_MONEY, INTERVAL INTEGER, INTERVAL_TRUC, ...) Voir Typage des intervalles, opérateurs.
Il est intéressant de constater que la norme SQL:2011 s’y colle :
CREATE TABLE Client_historique
(
Client_id INT NOT NULL,
Statut INT NOT NULL,
Date_debut DATE NOT NULL,
Date_fin DATE NOT NULL,
PERIOD FOR Durant (Date_debut, Date_fin),
UNIQUE (Client_id, Durant WITHOUT OVERLAPS)
) ;
Je ne dispose pas du document officiel de la norme SQL, seulement de la dissertation éclairante que Chris Date, Hugh Darwen et Nikos Lorentzos lui consacrent au chapitre 19 « The SQL Standard » de leur ouvrage Time and Relational Theory, Temporal Databases in the Relational Model and SQL.
Question : Où en est SQL Server quant à cette extension relative aux intervalles ?
Répondre avec citation
Partager