Intégration de la dimension temporelle au modèle entité-relation Rafik Bouaziz* — Mohamed Mkaouar* — Mohamed Moalla** * Faculté des Sciences Économiques et de Gestion, Route de l’aérodrome, BP 1088, 3018 Sfax – Tunisie. {Raf.Bouaziz, Mohamed.Mkaouar}@fsegs.rnu.tn ** Faculté des Sciences de Tunis, Campus Universitaire, 2092 Manar II, Tunis – Tunisie. [email protected] L’intégration méthodologique de la dimension temporelle dans les bases de données exige que l’on dispose des primitives qui permettent une spécification rigoureuse et progressive de cette dimension dès les niveaux conceptuel et organisationnel. Dans ce but, nous proposons un ensemble de concepts et de formalismes graphiques, conformes aux abstractions fixées pour les deux niveaux du modèle entité-relation. Ces concepts permettent d’exprimer des besoins en historiques atomiques, locaux et globaux, à travers des composants-types (propriété-type, entité-type, etc.) temporels de validité, des composantstypes temporels de transaction ou des composants-types bitemporels. L’application de ces concepts à la variante MERISE/2 a donné lieu à une extension intitulée MERISE/TEMPO. Des exemples illustratifs des constructions-types proposées, tirés d’une expérimentation sur une application concrète, sont donnés. RÉSUMÉ.

ABSTRACT. The methodological integration of the temporal dimension in databases requires primitives that allow rigorous and progressive specification of this dimension since the conceptual and organizational levels. For this goal, we propose concepts and graphic formalisms, in accordance with the abstractions of the tow levels of the entity-relationship model. These concepts allow the expression of requirements of atomic, local and global histories, through valid-time, transaction-time or bitemporal component-types (property-type, entity-type, etc.). The application of these concepts to the MERISE/2 method gave the MERISE/TEMPO extension. Illustrative examples of the proposed component-types, drawn of an experimentation of a concrete application, are given.

Bases de Données Temporelles, Extension Temporelle, Modèle Entité-Relation, Modélisation.

MOTS-CLÉS :

KEYWORDS: Temporal

Databases, Temporal Extension, Entity-Relationship Model, Modeling.

1. Introduction L’intégration de la dimension temporelle dans les bases de données (BD) a fait l’objet de plusieurs travaux qui ont porté principalement sur le niveau logique et le niveau physique (Wu et al., 1998) : définition de concepts d’historisation pour le modèle relationnel (Adiba et al., 1985, Snodgrass et al., 1985, Jensen et al., 1998, Jensen, 2000), modèle orienté objet des BD temporelles (BDT) (Dumas et al., 2004, Galante et al., 2005), langages de définition et de manipulation des BDT (Chomicki, 1994, Snodgrass, 1995, Fauvet et al., 1999), gestion et cohérence des BDT (Bouaziz et al., 1992, Doucet et al., 1997, Snodgrass, 2000, Makni et al., 2006), implantation des BDT (Mkaouar et al., 2005, Steiner, 2005), etc. Toutefois, les diverses propositions n’ont pas encore mené à la définition d’une démarche de conception « standard » qui intègre cette dimension temporelle d’une manière méthodique et simple. En point de départ d’une telle démarche, il s’agit de définir des concepts appropriés pour l’expression de la dimension temporelle au niveau conceptuel, à travers un formalisme qui facilite et précise la communication entre concepteurs et utilisateurs. Le présent travail traite précisément de l’expression de la dimension temporelle aux niveaux conceptuel et organisationnel. Il s’agit de caractériser les besoins en spécifications temporelles à chacun de ces niveaux d’abstraction et de définir les nouveaux concepts et les représentations graphiques nécessaires à une modélisation efficace de telles spécifications dans le cadre du formalisme entité-relation (E-R) (Chen, 1976), avec application à la méthode MERISE/2 (Rochfeld, 1992, Panet et al., 1994). Une nouvelle version de MERISE, baptisée MERISE/TEMPO, est alors proposée. Nous commençons, à la section 2, par une présentation succincte du domaine d’étude et une synthèse critique des extensions temporelles proposées dans la littérature pour différentes variantes du modèle E-R et pour UML. Nous proposons ensuite, dans la section 3, un ensemble de concepts de base pour la modélisation des faits temporels aux niveaux conceptuel et organisationnel sous le formalisme E-R, avec deux illustrations tirées d’une application concrète. Des concepts temporels complémentaires spécifiques à la variante MERISE/2 sont présentés dans la section 4. Le positionnement de MERISE/TEMPO par rapport aux travaux existants est commenté à la section 5.

2. Domaine d’étude et état de l’art L’historisation des données consiste à réaliser les opérations de mise à jour d’une manière non destructive. Les états concernant le passé sont conservés dans la base ; on ne fait qu’ajouter les nouveaux états. À cet effet, les faits temporels du monde réel sont estampillés par le « temps ». Deux types de temps sont utilisés (Jensen et al., 1998) :

− Le temps logique ou « temps de validité » : associé à un fait, il correspond au temps durant lequel ce fait est considéré valide dans le monde réel. Ce type de temps est géré par l’utilisateur et peut subir des modifications de valeurs. − le temps physique ou « temps de transaction » : associé à un fait, il correspond au temps durant lequel ce fait est ou était considéré « courant » dans la BDT. Ce type de temps est arrêté par la montre du système. Il est généré automatiquement par le SGBD et n’est jamais modifié par l’utilisateur. Aussi bien les temps de validité que les temps de transaction peuvent être spécifiés comme des instants, des intervalles temporels ou des ensembles d’intervalles temporels. Nous adoptons, ici, la spécification sous forme d’intervalles temporels. Ainsi, toute estampille est décrite par un temps de début et un temps de fin spécifiant, respectivement, sa borne inférieure et sa borne supérieure. Ces temps permettent de définir trois types de faits temporels : − Un fait temporel de validité, représentant un fait estampillé par un temps de validité. Il permet de conserver la suite des valeurs valides prises successivement par un fait, conformément à ce qui est appliqué dans le monde réel. − Un fait temporel de transaction, représentant un fait estampillé par un temps de transaction. Il permet de conserver la suite des valeurs (valides et erronées) d’un fait, saisies successivement dans la BDT. − Un fait bitemporel, représentant un fait estampillé à la fois par un temps de validité et par un temps de transaction. Il permet de conserver l’ensemble des valeurs saisies pour un fait, en distinguant celles qui sont valides et celles qui sont erronées. Par ailleurs, il devient possible de connaître l’écart entre le temps de validité de chaque valeur d’un fait dans le monde réel et le temps de sa prise en charge par le système informatique. L’historisation selon l’axe de validité permet aussi la prise en charge des faits provenant en retard (avec effet rétroactif) et des faits futurs (avec effet postactif). L’expression des faits temporels au niveau conceptuel a été étudiée pour différentes variantes du modèle E-R. Certaines de ces propositions sont rappelées dans (Gregersen et al., 1999) : il s’agit de “TERM: Temporal Entity-Relationship Model”, “RAKE: Relationships, Attributes, Keys, and Entities Model”, “MOTAR: Model for Objects with Temporal Attributes and Relationships”, “STEER: Semantic Temporal EER Model”, “ERT: Entity-Relation-Time model”, “TER: Temporal EER model”, “TEER: Temporal EER Model” et le modèle de Kraft. (Gregersen et al., 1998) ont aussi proposé une extension, baptisée “TIMEER: Temporally Extended ER Model”, qui a éliminé certaines limites des propositions antérieures. Récemment, (Jiménez, 2006) a proposé une extension au modèle E-R, baptisé “REERM: Reenhancing the Entity-Relationship Model”, qui intègre le concept d’événement au modèle de données pour mieux modéliser les faits temporels. L’auteur propose de commencer par la définition d’un schéma E-R qui spécifie textuellement les besoins d’historisation selon les temps de validité, puis de définir

un schéma REERM qui spécifie les événements et modélise lesdits besoins par l’annonce des attributs d’estampillage. Pour ce qui concerne les méthodes orientées objet, TUML (Temporal Unified Modeling Language) (Svinterikou et al., 1999) et UML-TF (an UML profile for Temporal Facts) (Mkaouar et al., 2006) sont, à notre connaissance, les seules extensions temporelles d’UML qui permettent la modélisation des faits temporels. TUML propose des stéréotypes pour la représentation des classes, des attributs et des associations temporels. Le profil UML-TF définit un stéréotype abstrait qui permet une spécification globale des caractéristiques structurelles et comportementales relatives aux faits temporels. À partir de ce stéréotype abstrait sont dérivés des stéréotypes spécifiques aux classes, attributs, associations et rôles temporels. Remarquons ici que, aussi bien dans le cas du modèle E-R que dans celui des méthodes orientées objet, les extensions temporelles sont généralement annoncées pour le niveau conceptuel. Cependant, certaines d’entre elles concernent plus directement : − le niveau organisationnel, comme par exemple la spécification des temps de transaction, puisqu’il s’agit des instants de prise en charge des faits par le SGBD. Les extensions TEER, TIMEER et TUML proposent de déclarer cette spécification au niveau conceptuel, alors que dans les extensions MOTAR et REERM, cette spécification est différée au niveau logique ; − le niveau logique, comme par exemple l’adjonction par STEER, TEER et ERT d’un attribut-système, appelé SURROGATE, pour l’identification des entités historisées. Cela est critiquable vis-à-vis du principe fondamental de la démarche par niveaux d’abstraction des méthodes systémiques, qui consiste à ne prendre en considération, au niveau conceptuel, que des spécifications indépendantes de tout choix d’ordre organisationnel ou logique. Le respect strict du principe de la démarche par niveaux d’abstraction est observé dans les extensions que nous proposons pour la modélisation des faits temporels sous le modèle E-R. Ce modèle se base sur les concepts de propriété-type, d’entité-type (ou d’objet-type), de relation-type (ou d’association-type), de rôletype, d’identifiant et de cardinalité. Par abus de langage, ces concepts sont évoqués plus simplement par les termes respectifs de propriété, entité ou objet, relation ou association et rôle. La variante MERISE/2 enrichit ce modèle par le concept de Généralisation/Spécialisation, qui est emprunté de l’orienté objet, et le concept de relation de relations. Elle enrichit aussi l’expression des contraintes d’intégrité par de nouvelles primitives. Par la définition de MERISE/TEMPO, nous visons à étendre MERISE/2 pour la prise en compte des spécifications temporelles, tant au niveau conceptuel (pour ce qui concerne les faits temporels de validité) qu’au niveau organisationnel (pour ce

qui concerne les faits temporels de transaction). Nous retenons donc tous les concepts et formalismes graphiques de MERISE/2 pour les spécifications classiques et nous proposons un certain nombre d’enrichissements en vue de supporter les dimensions temporelles et d’étendre l’interprétation sémantique à ces dimensions. 3. Expression des spécifications temporelles de base Cette section traite des éléments qui peuvent s’appliquer aussi bien pour le niveau conceptuel que pour le niveau organisationnel. Les cinq premières soussections présentent des définitions et propositions de base. La sixième sous-section présente la démarche. Les exemples illustratifs des notations sont regroupés dans la septième sous-section. La dernière sous-section traite la normalisation. 3.1. Principe de spécification des historiques Définition 1 : Un historique atomique est un historique déclaré pour : − une seule propriété afin de mémoriser l’ensemble des « valeurs » qu’elle prend dans le « temps », ou − un seul rôle afin de mémoriser l’ensemble des liens qu’il représente dans le « temps ». Exemples : Un historique atomique déclaré pour la propriété “Capital” d’une entreprise serait une suite ordonnée de tuples . De même, un historique atomique déclaré pour un rôle “Activité” d’une entreprise serait une suite ordonnée de tuples . Pour toute entité-type ou relation-type, nous donnons la possibilité de spécifier un historique local ou un historique global. Définition 2 : Un historique local est un historique déclaré pour un sousensemble (au sens strict du terme) des propriétés d’une entité ou d’une relation, ou pour un sous-ensemble des rôles d’une relation. Il est déclaré à travers un ensemble d’historiques atomiques. Définition 3 : Un historique global est un historique déclaré pour : − une entité entière, englobant toutes ses propriétés, ou − une relation entière, englobant tous ses rôles ainsi que ses propriétés éventuelles. Exemple : Pour une entreprise spécifiée par les propriétés “Identifiant”, “Capital”, “n° téléphone” et “forme juridique”, on peut déclarer un historique atomique pour la propriété “Capital” et un autre pour la propriété “forme juridique”. Si les deux historiques ont les mêmes estampilles, on peut les déclarer à travers un même historique local. Dans la pratique, il est plutôt rare de trouver des entités pour lesquelles on peut déclarer un historique global impliquant toutes les propriétés.

Notons qu’un historique global peut être déclaré à partir d’historiques atomiques. Cela est d’ailleurs l’approche adoptée dans TERM. Cependant, le passage obligé par la spécification explicite de tous les historiques atomiques constitue une lourdeur que l’on peut éviter.

3.2. Définition des composants-types temporels La spécification d’un historique global à une entité-type ou à une relation-type, ou d’un historique atomique à une propriété-type ou à un rôle-type, permet à ces composants-types de supporter la dimension temporelle, amenant ainsi à de nouvelles constructions. Nous définissons ces constructions comme suit : Définition 4 : Un composant-type temporel de validité (entité-type temporelle de validité, relation-type temporelle de validité, propriété-type temporelle de validité, ou rôle-type temporel de validité) est un composant-type que l’on spécifie, au niveau conceptuel, par un historique selon les temps de validité. Il permet de modéliser des faits temporels de validité. Définition 5 : Un composant-type temporel de transaction (entité-type temporelle de transaction, relation-type temporelle de transaction, propriététype temporelle de transaction, ou rôle-type temporel de transaction) est un composant-type que l’on spécifie, au niveau organisationnel, par un historique selon les temps de transaction. Il permet de modéliser des faits temporels de transaction. Définition 6 : Un composant-type bitemporel (entité-type bitemporelle, relation-type bitemporelle, propriété-type bitemporelle, ou rôle-type bitemporel) est un composant-type que l’on spécifie, au niveau conceptuel, par un historique selon les temps de validité et, au niveau organisationnel, par un historique selon les temps de transaction. Il permet de modéliser des faits bitemporels.

3.3. Formalisme graphique pour la spécification temporelle Différentes représentations graphiques sont proposées dans la littérature pour la spécification temporelle. RAKE propose de relier les entités à historiser à des entités temporelles (Time_period). ERT utilise des boîtes temporelles que l’on peut placer, au besoin, au niveau des branches reliant les propriétés à leur entité (quand il s’agit d’historiser des propriétés) et au niveau des branches des relations (quand il s’agit d’historiser des rôles). Dans MOTAR, il est adopté de représenter en traits doubles les contours des losanges et carrés schématisant respectivement les relations et les attributs à historiser. Le modèle de Kraft marque par un double « slash » (//) les entités à historiser, les branches d’attachement des propriétés à historiser et les branches représentant les relations à historiser. C’est TIMEER qui propose la représentation graphique la plus claire. Il utilise les symboles « LS », « V », « T » et « BT » pour exprimer respectivement un besoin de spécification de durée de vie

(lifespan), de temps de validité, de temps de transaction et de ces deux temps ensemble. Néanmoins, cette représentation gagne à être plus expressive. Proposition 1 : Un besoin d’historisation selon l’axe de validité est représenté graphiquement par le symbole d’une montre accompagnée de la lettre « V » indicée par « a », « m », « j », « h », « n » ou « s » pour préciser le niveau de granularité, respectivement année, mois, jour, heure, minute ou seconde (Exemple : la représentation « žVm » déclare le besoin d’une historisation avec la granularité mois). Le niveau « jour » constitue l’option par défaut. Le concepteur peut modifier localement ce niveau, si nécessaire. Proposition 2 : Un besoin d’historisation selon l’axe de transaction est représenté graphiquement par le symbole d’une montre intégrée dans un écran et accompagnée de la lettre « T » indicée par le symbole de granularité (Exemple : « ž Tm »). Étant donné que les intervalles de transaction sont alloués automatiquement par le SGBD, le niveau de granularité généralement utilisé est la « seconde ». C’est donc l’option par défaut. Cependant, l’administrateur du système peut le raffiner davantage.



Proposition 3 : Dans un schéma MERISE/TEMPO, une montre de validité (respectivement une montre de transaction) est à placer à droite (respectivement à gauche) du nom d’une propriété (quand il s’agit d’une historisation atomique d’une propriété) ou du nom d’une entité ou d’une relation (quand il s’agit d’une historisation globale) ou, enfin, à côté d’une branche (quand il s’agit d’une historisation atomique d’un rôle). Les représentations ainsi constituées allient la simplicité d’utilisation à une expressivité visuelle directe (symboles des montres et précision des types de temps et du niveau d’abstraction). Leur intégration par une icône dans un AGL est très aisée. Il s’agit de même pour la manipulation des niveaux de granularité.

3.4. Notions d’occurrence et d’instance La validation des modèles passe souvent par la construction de schémas d’occurrences et il est courant, dans cet usage, de considérer les termes occurrence et instance comme étant synonymes. Dans le contexte particulier des modèles historisants, nous proposons de donner à chacun de ces termes une signification distincte. Définition 7 : Une occurrence d’un composant-type temporel est l’ensemble des « données » de ce composant-type se rapportant à toute l’étendue historique considérée et relatives à une même valeur de son identifiant. Définition 8 : Une instance d’un composant-type temporel est un sous-ensemble des « données » de l’une de ses occurrences, caractérisé par une période de validité et/ou de transaction spécifique(s).

L’on peut ainsi parler de composition d’une occurrence à partir de l’union de toutes les instances ayant la même valeur d’identifiant, ou distinguer, dans une même occurrence, des instances ayant chacune une période de « temps » particulière. Les figures 2 et 5 décrivent quelques occurrences avec leurs instances.

3.5. Spécifications temporelles des cardinalités Nous proposons de généraliser aux relations n-aires les définitions de TER (Tauzovich, 1991) concernant deux types de cardinalités pour les relations binaires. Ainsi, nous associerons à tout rôle temporel une paire de cardinalités ordinaires notée (min,max) et une paire de cardinalités temporelles notée (T: min,max). Etant donné un rôle défini entre une entité E et une relation temporelle R et deux occurrences ‘O1’ de E et ‘O2’ de R : − (min,max) indiquent respectivement les nombres minimum et maximum de liens possibles qui peuvent exister à chaque instant entre ‘O1’ et ‘O2’ ; − (T: min,max) indiquent respectivement les nombres minimum et maximum de liens possibles qui peuvent exister dans toute l’étendue historique entre ‘O1’ et ‘O2’. Dans l’exemple de la figure 1, les cardinalités du rôle qui part de ORGANISME vers CHEF sont interprétées comme suit : Les chefs d’un organisme se succèdent dans le temps mais, à un instant donné, l’organisme n’est dirigé que par un seul chef. Ainsi, à la paire de cardinalités ordinaires (1,1) correspond la paire de cardinalités temporelles (T: 1,n). La définition des deux types de paires de cardinalités doit respecter les contraintes suivantes : (C1) Si T: min = 0 alors min = 0 (optionalité de participation) ; (C2) Si min = 1 alors T: min = 1 (obligation de participation) ; (C3) Si max = n alors T: max = n (multiplicité des participations).

3.6. Démarche de la modélisation Le niveau conceptuel se restreint aux spécifications relevant de la sémantique conformément au monde réel. Le concepteur ne doit retenir, à ce niveau, que les aspects relatifs au « Quoi » du système d’information (SI). Seul l’axe temporel de validité est donc à prendre en compte à ce niveau. Alors que l’axe temporel de transaction n’est utile que pour marquer l’évolution des données dans le système informatique. Il permet de cadrer les périodes de prise en charge des informations dans la base de données et constitue, de ce fait, un aspect du niveau organisationnel qui englobe le « Qui fait, Quand et Où ». La conception de MERISE/TEMPO, partant de MERISE/2, entant coller à cette logique. Ainsi, l’élaboration d’un modèle de données MERISE/TEMPO commence

par la définition d’un modèle conceptuel de données (MCD) et se limite, à ce niveau, à l’expression des historiques selon l’axe temporel de validité (avec les montres de validité). En passant au niveau organisationnel, le MCD est complété par l’ajout des spécifications d’ordre organisationnel : types et formats des propriétés, droits d’accès aux données pour chaque type de site et pour chaque type de poste de travail, mode de gestion des données (informatisé ou manuel), données d’origine organisationnelle et critères classiques d’archivage. C’est alors que l’on spécifie les besoins en historiques selon l’axe temporel de transaction (avec les montres de transaction). Le modèle organisationnel des données (MOrD) ainsi obtenu cumule la déclaration de tous les besoins d’historisation. Il comporte des constructions-types temporelles de validité, des constructions-types temporelles de transaction et des constructions-types bitemporelles, conformément aux exigences du SI. Par ailleurs, de nouveaux types et formats temporels permettent au concepteur de déclarer des propriétés TDU (temps défini par l’utilisateur) : date, point temporel, intervalle temporel, durée et période. Le format d’une durée (par exemple, pour décrire la durée d’un emprunt obligataire) peut être sous la forme « AA ans, MM mois, JJ jours » permettant de maintenir toute valeur exprimant un nombre d’années, un nombre de mois et un nombre de jours.

3.7. Illustration de l’expression des spécifications temporelles Nous allons illustrer la spécification d’historiques sous MERISE/TEMPO par des exemples tirés d’une application « Centrale des renseignements » réalisée au sein d’un organisme financier. Ladite application a pour objectif de suivre l’activité économique en Tunisie et de répondre aux besoins d’autres institutions financières en informations utiles pour la prise de décision. Elle s’intéresse aussi bien aux données courantes qu’aux données historiques des organismes (sociétés, coopératives, associations, etc.) exerçant dans le pays. Exemple 1 : La figure 1 illustre des spécifications d’historiques globaux relatives à l’entité temporelle de validité ORGANISME, la relation temporelle de validité CHEF et la relation bitemporelle ACTIONNAIRE. ORGANISME ID_ORG CAPITAL VAL_ACTION

žV

j

T: 1,n 1,1 T: 1,n 1,n

CHEF

žV

j

ž  T ACTIONNAIRE žV s

NB_ACTIONS

j

T: 0,n 0,n

INDIVIDU

ID_IND T: 0,n NOM 0,n NAISSANCE

Figure 1. Exemples de spécifications d’historiques globaux sous MERISE/TEMPO

La figure 2 montre un schéma d’occurrences relatives à l’organisme « SNA » et aux individus « EYA » et « EDAM ». Les trois instances de l’occurrence « SNA » montrent l’évolution des données relatives à son capital et à la valeur de son action. Notons que le symbole « ! » représente la valeur « non connu a priori » pour les temps de validité ou la valeur now (Jensen et al., 1998) pour les temps de transaction. Les deux premières instances de la relation CHEF rattachent l’organisme « SNA » à l’individu « EDAM », alors que la troisième rattache cet organisme à l’individu « EYA ». Finalement, les trois instances relatives à l’occurrence « SNA, EYA » de ACTIONNAIRE montrent l’évolution du nombre d’actions de « EYA » dans « SNA ». [2001/11/16 - 2003/12/31]

2002/7/2: H 10 6’ 25’’

2003/12/31: H 23 59’ 59’’

: ACTIONNAIRE NB_ACTIONS = 1

: ORGANISME ID_ORG = “SNA” CAPITAL = 50 000 VAL_ACTION = 10

2003/12/10: H 15 3’ 17’’

[2004/1/1 - 2005/10/15]

2005/10/15: H 23 59’ 59’’

: ACTIONNAIRE

[2004/1/1 - 2005/10/15]

NB_ACTIONS = 500

: ORGANISME ID_ORG = “SNA” CAPITAL = 50 000 VAL_ACTION = 20

[2005/10/16 - ! ]

2005/9/5: H 17 25’ 55’’

: ACTIONNAIRE

!

[2005/10/16 - ! ]

NB_ACTIONS = 1 500

: ORGANISME ID_ORG = “SNA” CAPITAL = 100 000 VAL_ACTION = 20

[2005/1/1 – 2005/10/15]

: CHEF [2004/1/1 – 2004/31/12]

: CHEF

[2001/11/16 – 2003/12/31]

: CHEF

[2002/6/16 - 2003/12/31]

000

: INDIVIDU ID_IND = 4545220 NOM = “EYA” NAISSANCE = “3 juin

1979”

: INDIVIDU ID_IND = 3225777 NOM = “EDAM” NAISSANCE = “5 mai

1975”

N.B. : Conformément aux conventions de représentation des modèles, les intervalles de validité et les intervalles de transaction sont présentés respectivement à droite et à gauche de chaque instance concernée.

Figure 2. Exemple d’un schéma d’instances relatives à des historiques globaux Exemple 2 : Le modèle de la figure 3 spécifie un historique local pour l’entité ORGANISME, à travers les historiques atomiques de ses deux attributs « CAPITAL » et « FORM_JURIDIQ », et un historique local pour la relation SPECIALITE, à travers un historique atomique de son rôle « ACTIV ». ORGANISME ID_ORG CAPITAL Vm TELEPH FORM_JURIDIQ

ž

žV

T: 1,n 1,n ACTIV

žV

m

SPECIALITE

ACTIVITE ID_ACT 1,n LIBELLE_ACT

m

Figure 3. Exemples de spécifications d’historiques locaux sous MERISE/TEMPO La figure 4 montre un schéma d’occurrences relatives à l’organisme « SNCPA » et aux activités « ACT50 » et « ACT53 ». Le capital et la forme juridique de « SNCPA » comportent chacun deux instances. L’occurrence relative à « SNCPA, ACT53 » de SPECIALITE comporte également deux instances avec deux intervalles de validité

qui ne se chevauchent pas, alors que celle relative à « SNCPA, ACT50 » n’en comporte qu’une seule. : ORGANISME ID_ORG = “SNCPA”

N.B. : “SARL” signifie une société à responsabilité limité ; “SA” signifie une société anonyme.

[2002/11 – 2005/11]

CAPITAL = 45

000 000 TELEPH = 216 74 250 250 FORM_JURIDIQ = “SARL” FORM_JURIDIQ = “SA”

[2005/12 – 2007/3]

CAPITAL = 60

[2002/11 –

: SPECIALITE

[2002/12 – 2006/9] [2006/10 –

! ]

!

] [2004/10 –

[2002/11 – 2003/12]

!

]

: ACTIVITE ID_ACT = “ACT50” LIBELLE_ACT = “Fabrication

Pneus Auto” : ACTIVITE

ID_ACT = “ACT53” LIBELLE_ACT = “Fabrication

Pneus Cycle”

: SPECIALITE

: SPECIALITE

Figure 4. Exemple d’un schéma d’instances relatives à des historiques locaux

3.8. Normalisation temporelle Comme le montre la figure 2 pour l’exemple des instances de l’occurrence « SNA », l’historique global d’une entité peut provoquer une redondance d’information ; deux instances sont utilisées pour une même valeur du capital (50 000 Dinars). La normalisation temporelle, du type défini dans (Navathe et al., 1987) pour le paradigme relationnel, permet d’éviter de telles redondances. Elle peut être définie dans le cadre du modèle E-R comme suit : Définition 9 : Une entité-type (ou une relation-type) spécifiée avec un historique global est temporellement normalisée si et seulement si toutes ses propriétés-types ont le même comportement temporel, c’est-à-dire qu’à chaque fois qu’une propriété change de valeur, les autres le font. Un modèle est dit temporellement normalisé si toutes ses entités et toutes ses relations spécifiées avec des historiques globaux sont temporellement normalisées. Ainsi, pour éviter les redondances, il y a lieu de ne spécifier des déclarations d’historiques globaux que pour des entités ou relations temporellement normalisées. Quand ce n’est pas le cas, on se limitera à des déclarations d’historiques locaux. La même remarque peut être faite concernant les historiques locaux.

4. Spécifications temporelles complémentaires au niveau conceptuel Les spécifications temporelles complémentaires proposées ci-dessous concernent les concepts de Généralisation/Spécialisation et de relation-de-relation, rencontrés, entre autres, dans MERISE/2.

4.1. Historisation relative à une « Généralisation/Spécialisation » Proposition 4 : La déclaration d’une spécification temporelle d’une relation de Généralisation/Spécialisation ne s’effectue pas d’une manière explicite, mais plutôt d’une manière implicite à travers une spécification temporelle globale de la superclasse ou à travers les spécifications temporelles des sous-classes, qu’elles soient globales ou locales. Proposition 5 : L’expression d’un historique global ou d’un historique local pour une entité générique ou une entité spécialisée se réalise de la même manière que pour n’importe quelle entité-type. Cependant, l’héritage s’étend aux spécifications d’historisation conformément aux principes suivants : − Les propriétés et les rôles historisés d’une manière atomique au sein d’une entité générique sont hérités en tant que tels par toutes les entités spécialisées. − Un historique global d’une entité générique se répercute globalement sur toutes ses entités spécialisées. − Un historique global d’une entité spécialisée se limite à cette entité et ne se répercute ni sur son entité générique, ni sur les autres entités spécialisées issues de cette dernière. − Dans le cas d’un héritage composé, une entité spécialisée hérite les spécifications d’historisation de toutes ses entités génériques. Exemple : Le schéma de la figure 5 spécifie un historique global de l’entité générique ORGANISME. Les entités spécialisées de cette dernière héritent aussi bien les propriétés et les rôles de ORGANISME que la spécification de l’historique global. Cet historique intègre alors la trace des changements des caractéristiques spécialisées de chaque organisme. L’entité spécialisée ORGANISME_BANCAIRE hérite, en sus, une historisation atomique de la propriété DOMAIN_ACT (domaine d’activité) de l’entité INSTITUTION_FINANCIERE. ORGANISME ID_ORG CAPITAL VAL_ACTION

ORGANISME_COTE_EN_BOURSE NOMINAL_ACTIONS

žV

j

INSTITUTION_FINANCIERE ID_INST NUM_AUTORIS DOMAINE_ACTIVITE Vj

ž

ORGANISME_BANCAIRE NB_AGENCES

Figure 5. Exemple d’héritage de spécifications d’historisation

4.2. Historisation relative à une relation de relations Proposition 6 : L’historisation d’une relation de relations se traite de la même manière que celle d’une relation-type ordinaire, qu’elle soit locale (pour certains de ses propriétés et/ou rôles) ou globale. Exemple : Le schéma de la figure 6 spécifie un historique global pour la relation de relations GAIN. Une occurrence de GAIN concerne un actionnaire donné pour un exercice donné. Une telle occurrence peut avoir plusieurs instances, chacune correspondant à un intervalle de validité spécifique, exprimé avec la granularité « année ». ORGANISME ID_ORG CAPITAL Vj VAL_ACTION

ž

ž  T ACTIONNAIRE žV

0,n

j

s

NB_ACTIONS

0,n

EXERCICE T: 0,n CHIF_AFF

ANNEE AN

T: 1,n 1,n

BENEFICE

0,n

GAIN

žV

T: 1,n 1,n

INDIVIDU

T: 0,n 0,n ID_IND

NOM NAISSANCE

a

MONTANT_G TYP_G

Figure 6. Exemple de spécification d’un historique pour une relation de relations

4.3. A propos de l’historisation des entité relatives Les extensions RAKE et TIMEER traitent à part le cas des entités relatives, appelées aussi entités faibles, s’agissant d’entités qui n’ont pas d’existence propre. Par exemple, un avenant (instance de l’entité AVENANT) ne peut exister que par rapport à un contrat (instance de l’entité CONTRAT). Cependant, formellement, ce cas ne se distingue que par la particularité de son identifiant. Nous considérons alors que son historisation ne nécessite aucune extension particulière. D’ailleurs, une telle information gagne à être modélisée à travers le concept de relation.

5. Positionnement par rapport à l’état de l’art MERISE/TEMPO supporte, comme STEER, TEER, TIMEER, TUML, REERM et UML-TF, les trois dimensions temporelles (temps de validité, temps de transaction et temps défini par l’utilisateur). Par contre, TERM, RAKE, MOTAR, ERT, TER et le modèle de Kraft ne supportent que les temps de validité et les temps définis par l’utilisateur. Du point de vue application, ce sont MERISE/TEMPO et UML-TF qui respectent le plus le principe d’abstraction ; ils permettent une spécification progressive des spécifications temporelles, d’abord celles relevant du niveau conceptuel, puis celles relevant du niveau organisationnel. D’un autre côté, MERISE/TEMPO adopte, comme toutes les autres extensions, sauf STEER et TEER, une vision standard de l’historisation. Elle introduit, pour les

aspects temporels, des concepts et des représentations graphiques très avancés, comparativement à ceux proposés par les extensions antérieures. Elle supporte, comme MOTAR, STEER, TEER, TIMEER et REERM, des relations n-aires étendues. Elle généralise aux relations n-aires la proposition de TER concernant l’expression des cardinalités temporelles pour les relations binaires. Contrairement à TERM, STEER, TER et TEER, qui modifient les interprétations sémantiques des constructions de base, MERISE/TEMPO, comme RAKE, MOTAR, ERT, le modèle de Kraft, TIMEER, TUML, REERM et UM-TF, assure la compatibilité ascendante avec les concepts et les représentations de la méthode objet de l’extension. Par rapport à UML-TF, qui propose des estampilles non figées à travers la définition d’un stéréotype abstrait permettant la modification des caractéristiques structurelles et comportementales des estampilles, MERISE/TEMPO ne permet de modifier que les nivaux de granularité. Rappelons que les deux méthodes relèvent de paradigmes différents.

6. Conclusion L’extension du modèle entité-relation que nous venons de présenter propose de nouveaux concepts et outils pour rendre l’expression des spécifications temporelles aisée et efficace. Elle se distingue par sa conformité au principe de la démarche par niveau d’abstraction des méthodes systémiques. Les spécifications temporelles sont placées à côté des autres spécifications sémantiques, d’une manière conforme à l’objet et à l’étendue de chaque niveau d’abstraction. Au niveau conceptuel, elles permettent au concepteur de marquer les données à historiser conformément à l’évolution du monde réel par une « montre de validité ». Au niveau organisationnel, elles permettent de marquer les données à historiser conformément à leur évolution dans la BDT par une « montre de transaction ». Ce marquage est souple ; il peut être effectué d’une manière locale ou d’une manière globale. La définition d’une nouvelle paire de cardinalités, notée (T: min,max), permet de spécifier les conditions d’existence de plusieurs instances pour une même occurrence d’une relation historisée. La mise en œuvre de cette extension est concrétisée à travers MERISE/TEMPO qui étend la méthode MERISE/2 à l’environnement temporel tout en préservant ses atouts de puissance et de rigueur. Il est aisé de remarquer, à travers la présentation que nous venons de donner, que la plupart des enrichissements temporels proposés peuvent être mis en œuvre dans le cadre de toute autre variante du modèle E-R. Les notions d’historique global, d’historique local, d’occurrence, d’instance et de normalisation temporelle d’une entité ou d’une relation sont définies dans un cadre général et ne dépendent d’aucune variante. Les montres de validité et de transaction peuvent être utilisées pour toutes les variantes ; seuls les endroits caractérisant les spécifications temporelles varieront en fonction du formalisme graphique propre à

chacune d’elles. Les différentes interprétations sémantiques des spécifications temporelles peuvent être adoptées par les autres variantes, sous réserve qu’elles supportent les concepts considérés tels que ceux de relation n-aire, de généralisation/spécialisation et de relation de relations. Mais, la définition de la paire de cardinalités temporelles peut ne pas convenir à certaines variantes, sachant que le concept de cardinalité ordinaire est lui même défini de différentes manières. Nous envisageons maintenant d’affiner l’étude de certains concepts d’historisation, tels que ceux relatifs aux rôles et aux relations de Généralisation/Spécialisation, et d’étudier les contraintes d’intégrité et les impacts temporels sur les modèles de traitement. La méta-modélisation et la validation formelle de ces concepts constituent une autre perspective de nos travaux.

7. Bibliographie Adiba M., Quang N. B., de Oliveira José Palazzo M., « Notion de temps dans les bases de données généralisées », Actes des 1ères Journées Bases de Données Avancées, 1985. Bouaziz R., Moalla M., Rolland C., « Approche globale pour la gestion de l’historisation dans les bases de données temporelles », Actes des 10èmes journées INFORSID, 1992. Chen P., « The Entity-Relationship Model – Toward a Unified View of Data », ACM Transactions on Database Systems, vol. 1, n° 1, 1976, p. 9-36. Chomicki J., « A Temporal Query Languages: A Survey », Proceedings of the First International Conference on Temporal Logic, Bonn, Germany, 1994, p. 506-534. Doucet A., Gançarski S., Jomier G., Monties S., « Maintien de la Cohérence dans une Base de Données Multiversion », Ingénierie des Systèmes d’Information, vol. 5 n° 1, 1997. Dumas M., Fauvet M. C., Scholl, P. C., « TEMPOS: A Platform for Developing Temporal Applications on top of Object DBMS », IEEE Transactions on Knowledge and Data Engineering, vol. 16, n° 3, mars 2004, p. 354-374. Fauvet M. C., Canavaggio J. F., Scholl, P. C., « A representation-independent temporal extension of ODMG’s Object Query Language », Actes des 15èmes Journées Bases de Données Avancées, Bordeaux, France, octobre 1999. Galante R. M., dos Santos C. S., Edelweiss N., Moreira Á. F., « Temporal and versioning model for schema evolution in object-oriented databases », Data & Knowledge Engineering, vol. 53, n° 2, mai 2005, p. 99-128. Gregersen H., Jensen C. S., Conceptual Modelling of Time-Varying Information, Technical Report TR-35, TIMECENTER, septembre, 1998. Gregersen H., Jensen C. S., « Temporal Entity-Relationship Models – A Survey », IEEE Transactions on Knowledge and Data Engineering, vol. 11, n° 3, 1999, p. 464-497. Jensen C. S., Dyreson C.E., « The Consensus Glossary of Temporal Database Concepts », in Etzion O., Jajodia S., Sripada S. M., Temporal Databases: Research and Practice, LNCS 1399, Spring-Verlag, 1998.

Jensen C. S., « Temporal Database Management », dr.techn. thesis by C. S. Jensen, defended April 2000, disponible en ligne à www.cs.auc.dk/~csj/Thesis. Jiménez L. G., « REERM: Reenhancing the entity-relationship model », disponible en ligne à www.sciencedirect.com, à paraître à Data & Knowledge Engineering, 2006. Makni A., Bouaziz R., Gargouri F., « Formal verification of an optimistic concurrency control algorithm using SPIN », International Symposium on Temporal Representation and Reasoning, TIME 2006, Budapest, Hungary, juin, 2006. Mkaouar M., Bouaziz R., « L’édification de framework pour l’aide au développement d’applications temporelles », revue ISDM (Information Science for Decision Making), http://isdm.univ-tln.fr/, vol. 21, 2005. Mkaouar M., Bouaziz R., « UML-TF : Un profil UML pour la représentation des faits temporels », Technique et Science Informatiques, à paraître, 2006. Navathe S. B., Ahmed R., « TSQL: A Language Interface for History Database », Proceedings of the Conference on Temporal Aspects in Information Systems, AFCET, France, mai 1987, p. 113-128. Panet G., Letouche R., MERISE/2 : Modèles et techniques MERISE avancés, éditions d’organisation, 1994. Rochfeld A., « Présentation des évolutions de MERISE », Journées Internationales des Sciences de l’Informatique (JISI), Tunis, 1992. Snodgrass R. T., Ahn I., « A taxonomy of time in databases », ACM Transactions on Database Systems, 1985. Snodgrass R. T., The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995. Snodgrass R. T., Developing time-oriented database applications in SQL, Morgan Kaufmann Publishers, 2000. Steiner A., « TimeDB 2.2 », A TimeConsult Product, 2005, www.TimeConsult.com. Svinterikou M., Theodoulidis C. I., « The Temporal Unified Modeling Language », Proceedings of the 11th International Conference on Advanced Systems Engineering, CAiSE’99, Heidelberg, juin 1999, Germany. Tauzovich B., « Toward Temporal Extensions to the Entity–Relationship Model », Proceedings of the International Conference on the Entity Relationship Approach, 1991. Wu Y., Jajodia S., Wang X. S., « Temporal Database Bibliography Update », in Etzion O., Jajodia S., Sripada S. M., Temporal Databases: Research and Practice, LNCS 1399, Spring-Verlag, 1998.