Schéma relationnel pour les expressions temporelles de Fowler

Question

Martin Fowler définit un élégant modèle d'objet pour la planification des tâches récurrentes here, qui correspond très bien au code OO. Mapper cela à un schéma de base de données relationnelle pour la persistance, cependant, est difficile. Quelqu'un peut-il suggérer une combinaison schéma + SQL qui encapsule toutes les fonctionnalités qu'il décrit, particulièrement dans l'image de la page 11. Les intersections et les unions sont assez évidentes - la complexité réside dans la représentation des 'expressions temporelles', qui prennent des paramètres variables et doit être interprété différemment, puis en les combinant en un «ensemble temporel». Pour être clair, il existe plusieurs façons de représenter le concept des événements récurrents dans les bases de données relationnelles. Ce que j'aimerais que tout le monde fasse est de savoir comment mapper ce modèle particulier.

Quelques options possibles:

• tables 'Meta' qui définissent plusieurs, et l'utilisation d'arguments. Laid, mais travaille probablement. Cependant, il y a seulement un nombre limité de formes 'Expression Temporelle', donc l'extrême flexibilité que cela offre est probablement trop grande.
• Une forme d'héritage de table, telle que prise en charge par PostgreSQL (et vraisemblablement par d'autres) RBMS.

sérialiser la liste des paramètres et stocker le résultat dans un varchar() ne soit pas une solution telle que cette méthode évite les requêtes basées-ensemble :)

Answer 1

SQL est un langage d'interrogation de séries de données. Il ne supporte pas facilement le codage des opérations logiques spécifiques au domaine. En d'autres termes, "règle à évaluer" n'est pas un type de données dans SQL. C'est un concept orienté objet, que les données et la logique sont des composants d'une instance d'objet. Donc, je dirais que le maximum que vous pourriez faire dans le paradigme SQL serait de stocker 365 lignes, correspondant aux jours de l'année, et une valeur vrai/faux pour savoir si le jour respectif satisfait aux critères de la calendrier récurrent. Vous devez donc utiliser la logique OO implémentant le modèle de Fowler pour effectuer le calcul et stocker les 365 lignes résultantes.

Ensuite, quand vous avez besoin de savoir "est aujourd'hui (ou une date donnée) partie de l'annexe?" Il est très facile de rechercher la ligne appropriée et de vérifier la colonne true/false. Stocker 365 lignes par an est trivial pour n'importe quelle base de données.

Cela peut sembler tricher, mais comme je l'ai dit, SQL est sur les ensembles de données, pas logiques.

Answer 2

Je crains que cette réponse sera beaucoup de références et très peu de code pratique, et il a été un certain temps depuis que je foiré avec ça, mais ...

Je pense que les deux technologies que vous voulez pour mélanger ici sont 'active databases' et 'temporal databases'.

La première serait utile pour évaluer les règles et ainsi de suite, et le second est utile pour stocker des données temporelles et d'évaluer à quand un certain enregistrement est valide. Les deux sont des domaines de recherche assez vastes, mais vous pouvez faire la plupart des choses temporelles en langage SQL (à condition que votre base de données ait un bon support). La partie active est plus difficile en SQL, mais PostgreSQL a au moins des règles pour aider légèrement avec cela. Je ne connais pas les autres bases de données, mais la plupart d'entre elles ont un support de règle/déclencheur/contrainte qui serait capable de traduire ce que vous cherchez.

Les bases de données actives sont des bases de données qui peuvent réagir aux changements dans les faits qu'elle stocke à l'aide de règles. Ces règles sont spécifiées dans les langues spécifiques à l'implémentation, mais pour les discussions quotidiennes, les règles Event-Condition-Action rules (règles ECA) sont courantes. Pour une introduction aux systèmes de bases de données actifs, lisez les articles The Active Database Management System Manifesto et Active Database Systems. Pour plus d'informations sur les règles ECA, consultez Logical Events and ECA Rules (les pages sont dans l'ordre inverse o_0) et Events in an Active Object-Oriented Database System.

Le traitement des événements est un cas particulier de la gestion des règles traitant de la gestion des événements composites et du déclenchement de leurs actions de manière appropriée. Une lecture intéressante à ce sujet est Composite Events for Active Databases: Semantics, Contexts and Detection et Anatomy of a Composite Event Detector. Voir également le site Complex Event Processing et les articles wikipedia Event Stream Processing et Complex Event Processing.

Les bases de données temporelles peuvent être vues comme une base de données qui peut comprendre l'heure, et en particulier deux types de temps spécifiques; temps valide et temps de transaction. L'heure valide d'un enregistrement est la période pendant laquelle cet enregistrement est valide et l'heure de transaction d'un enregistrement est l'heure pendant laquelle il est présent dans la base de données. Comme une bonne introduction pratique, je recommande le livre sur la façon de faire des bases de données temporelles dans SQL: Developing Time-Oriented Database Applications in SQL par Richard T. Snodgrass.

Oterhwise, tout ce que vous pourriez vouloir savoir sur les bases de données temporelles peut être lu dans Temporal Database Entries for the Springer Encyclopedia of Database Systems qui est un document assez complet (je commencerais à l'entrée 'base de données temporelle'), mais pour commencer un peu plus vite, consultez le Temporal Database Glossary qui est plutôt facile à parcourir et à lire, et le site Time Center dont la partie publications a (ou a eu ...) des liens vers les publications les plus remarquables de la région. Donc, maintenant que vous savez tout cela, vous voyez rapidement que l'image de la page 11 peut être exprimée comme un événement composite, et peut être détectée/évaluée en tant que telle à condition que vous ayez implémenté le sous-ensemble requis d'un événement composite détecteur, et le reste pourrait être exprimé comme une entrée dans les tableaux avec des aspects temporels :)

Martin Fowler adresse beaucoup de lui-même dans son Patterns for things that change with time qui résume de nombreux modèles qui traite du temps. En fin de compte, je créerais probablement un schéma de base de données pour les informations temporelles et j'utiliserais les règles DB pour les parties actives ou implémenterais cette partie dans l'application (il y a des dragons cependant). Si vous utilisez PostgreSQL, les mécanismes de règles sont décrits dans The Rule System partie des docs.

Beaucoup à lire, mais si vous comprenez bien tout cela votre valeur professionnelle nette peut aller jusqu'à tout un peu :)

En outre, de bonnes conditions de Google sont « base de données temporelle », « base de données active », la CEA Règle'.