8/15/2019 MERISE OO

1/16

8/15/2019 MERISE OO

2/16

1. 

Introduction

L’intégration de la dimension temporelle dans les bases de données (BD) a faitl’objet de plusieurs travaux qui ont porté principalement sur le niveau logique et leniveau physique (Wu et al., 1998) : définition de concepts d’historisation pour lemodè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 (Bouazizet al., 1992, Doucet et al., 1997, Snodgrass, 2000, Makni et al., 2006), implantationdes BDT (Mkaouar et al., 2005, Steiner, 2005), etc.

Toutefois, les diverses propositions n’ont pas encore mené à la définition d’unedémarche de conception « standard » qui intègre cette dimension temporelle d’unemanière méthodique et simple. En point de départ d’une telle démarche, il s’agit dedéfinir des concepts appropriés pour l’expression de la dimension temporelle auniveau conceptuel, à travers un formalisme qui facilite et précise la communicationentre concepteurs et utilisateurs.

Le présent travail traite précisément de l’expression de la dimension temporelleaux niveaux conceptuel et organisationnel. Il s’agit de caractériser les besoins enspécifications temporelles à chacun de ces niveaux d’abstraction et de définir lesnouveaux concepts et les représentations graphiques nécessaires à une modélisationefficace 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 domained’étude et une synthèse critique des extensions temporelles proposées dans lalittérature pour différentes variantes du modèle E-R et pour UML. Nous proposonsensuite, dans la section 3, un ensemble de concepts de base pour la modélisation desfaits temporels aux niveaux conceptuel et organisationnel sous le formalisme E-R,avec deux illustrations tirées d’une application concrète. Des concepts temporelscomplémentaires spécifiques à la variante MERISE/2 sont présentés dans lasection 4. Le positionnement de MERISE/TEMPO par rapport aux travaux existantsest 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’unemaniè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 monderéel sont estampillés par le « temps ». Deux types de temps sont utilisés (Jensen etal., 1998) :

8/15/2019 MERISE OO

3/16

 

− Le temps logique ou « temps de validité  » : associé à un fait, il correspond autemps durant lequel ce fait est considéré valide dans le monde réel. Ce type de tempsest géré par l’utilisateur et peut subir des modifications de valeurs.

− le temps physique ou « temps de transaction » : associé à un fait, il correspondau temps durant lequel ce fait est ou était considéré « courant » dans la BDT. Cetype de temps est arrêté par la montre du système. Il est généré automatiquement parle SGBD et n’est jamais modifié par l’utilisateur.

Aussi bien les temps de validité que les temps de transaction peuvent êtrespécifiés comme des instants, des intervalles temporels  ou des ensemblesd’intervalles temporels. Nous adoptons, ici, la spécification sous forme d’intervallestemporels. 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 devalidité. Il permet de conserver la suite des valeurs valides prises successivement parun fait, conformément à ce qui est appliqué dans le monde réel.

− Un fait temporel de transaction, représentant un fait estampillé par un tempsde transaction. Il permet de conserver la suite des valeurs (valides et erronées) d’unfait, saisies successivement dans la BDT.

− Un  fait bitemporel, représentant un fait estampillé à la fois par un temps devalidité et par un temps de transaction. Il permet de conserver l’ensemble desvaleurs 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 devalidité de chaque valeur d’un fait dans le monde réel et le temps de sa prise encharge 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 pourdifférentes variantes du modèle E-R. Certaines de ces propositions sont rappeléesdans (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: SemanticTemporal EER Model”, “ERT: Entity-Relation-Time model”, “TER: Temporal EERmodel”, “TEER: Temporal EER Model” et le modèle de Kraft. (Gregersen et al.,

1998) ont aussi proposé une extension, baptisée “T  IME ER: 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 conceptd’é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écifietextuellement les besoins d’historisation selon les temps de validité, puis de définir

8/15/2019 MERISE OO

4/16

un schéma REERM qui spécifie les événements et modélise lesdits besoins parl’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 forTemporal Facts) (Mkaouar et al., 2006) sont, à notre connaissance, les seulesextensions 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 etdes associations temporels. Le profil UML-TF définit un stéréotype abstrait qui permet une spécification globale des caractéristiques structurelles etcomportementales relatives aux faits temporels. À partir de ce stéréotype abstraitsont 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 plusdirectement :

− le niveau organisationnel, comme par exemple la spécification des temps detransaction, 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écificationau niveau conceptuel, alors que dans les extensions MOTAR et REERM, cettespé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éshistorisées.

Cela est critiquable vis-à-vis du principe fondamental de la démarche parniveaux d’abstraction des méthodes systémiques, qui consiste à ne prendre enconsidération, au niveau conceptuel, que des spécifications indépendantes de toutchoix d’ordre organisationnel ou logique.

Le respect strict du principe de la démarche par niveaux d’abstraction estobservé dans les extensions que nous proposons pour la modélisation des faitstemporels 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ôle-type, 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 deGénéralisation/Spécialisation, qui est emprunté de l’orienté objet, et le concept derelation de relations. Elle enrichit aussi l’expression des contraintes d’intégrité parde 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 cequi concerne les faits temporels de validité) qu’au niveau organisationnel (pour ce

8/15/2019 MERISE OO

5/16

 

qui concerne les faits temporels de transaction). Nous retenons donc tous lesconcepts et formalismes graphiques de MERISE/2 pour les spécifications classiqueset nous proposons un certain nombre d’enrichissements en vue de supporter lesdimensions 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 leniveau conceptuel que pour le niveau organisationnel. Les cinq premières sous-sections 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 prenddans 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’uneentreprise serait une suite ordonnée de tuples .De même, un historique atomique déclaré pour un rôle “Activité” d’une entrepriseserait une suite ordonnée de tuples .

Pour toute entité-type ou relation-type, nous donnons la possibilité de spécifierun historique local ou un historique global.

 Définition 2 : Un historique local  est un historique déclaré pour un sous-ensemble (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 ensembled’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 historiqueatomique 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 unmême historique local. Dans la pratique, il est plutôt rare de trouver des entités pourlesquelles on peut déclarer un historique global impliquant toutes les propriétés.

8/15/2019 MERISE OO

6/16

 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é parla spécification explicite de tous les historiques atomiques constitue une lourdeurque 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 à cescomposants-types de supporter la dimension temporelle, amenant ainsi à denouvelles constructions. Nous définissons ces constructions comme suit :

 Définition 4 : Un composant-type temporel de validité (entité-type temporellede validité, relation-type temporelle de validité, propriété-type temporelle devalidité, ou rôle-type temporel de validité) est un composant-type que l’onspé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é-typetemporelle de transaction, relation-type temporelle de transaction, propriété-type temporelle de transaction, ou rôle-type temporel de transaction) est uncomposant-type que l’on spécifie, au niveau organisationnel, par un historique selonles 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-typebitemporel) est un composant-type que l’on spécifie, au niveau conceptuel, par unhistorique selon les temps de validité et, au niveau organisationnel, par un historiqueselon 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 laspécification temporelle. RAKE propose de relier les entités à historiser à des entitéstemporelles (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’agitd’historiser des rôles). Dans MOTAR, il est adopté de représenter en traits doublesles contours des losanges et carrés schématisant respectivement les relations et lesattributs à historiser. Le modèle de Kraft marque par un double « slash » (//) lesentités à historiser, les branches d’attachement des propriétés à historiser et les branches représentant les relations à historiser. C’est TIMEER   qui propose larepré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

8/15/2019 MERISE OO

7/16

 

(lifespan), de temps de validité, de temps de transaction et de ces deux tempsensemble. 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 : lareprésentation « » déclare le besoin d’une historisation avec la granularitémois). Le niveau « jour » constitue l’option par défaut. Le concepteur peut modifierlocalement ce niveau, si nécessaire.

 Proposition 2 : Un besoin d’historisation selon l’axe de transaction  estreprésenté graphiquement par le symbole d’une montre intégrée dans un écran etaccompagnée de la lettre « T  » indicée par le symbole de granularité (Exemple :« »). Étant donné que les intervalles de transaction sont allouésautomatiquement 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’unehistorisation globale) ou, enfin, à côté d’une branche (quand il s’agit d’unehistorisation atomique d’un rôle).

Les représentations ainsi constituées allient la simplicité d’utilisation à uneexpressivité visuelle directe (symboles des montres et précision des types de tempset du niveau d’abstraction). Leur intégration par une icône dans un AGL est trèsaisé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émasd’occurrences et il est courant, dans cet usage, de considérer les termes occurrenceet instance comme étant synonymes. Dans le contexte particulier des modèleshistorisants, 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 historiqueconsidérée et relatives à une même valeur de son identifiant.

 Définition 8 : Une instance d’un composant-type temporel est un sous-ensembledes « données » de l’une de ses occurrences, caractérisé par une période de validitéet/ou de transaction spécifique(s).

Tm 

Vm 

8/15/2019 MERISE OO

8/16

L’on peut ainsi parler de composition d’une occurrence à partir de l’union detoutes les instances ayant la même valeur d’identifiant, ou distinguer, dans unemê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 ordinairesnotée (min,max) et une paire de cardinalités temporelles notée (T: min,max). Etantdonné un rôle défini entre une entité E et une relation temporelle R et deuxoccurrences ‘O1’ de E et ‘O2’ de R :

− (min,max) indiquent respectivement les nombres minimum et maximum deliens possibles qui peuvent exister à chaque instant entre ‘O1’ et ‘O2’ ;

− (T: min,max) indiquent respectivement les nombres minimum et maximum deliens 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 ORGANISMEvers CHEF sont interprétées comme suit : Les chefs d’un organisme se succèdentdans 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éstemporelles (T: 1,n).

La définition des deux types de paires de cardinalités doit respecter lescontraintes 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émantiqueconformé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 devalidité est donc à prendre en compte à ce niveau. Alors que l’axe temporel detransaction n’est utile que pour marquer l’évolution des données dans le systèmeinformatique. Il permet de cadrer les périodes de prise en charge des informationsdans la base de données et constitue, de ce fait, un aspect du niveau organisationnelqui englobe le « Qui fait, Quand et Où ».

La conception de MERISE/TEMPO, partant de MERISE/2, entant coller à cettelogique. Ainsi, l’élaboration d’un modèle de données MERISE/TEMPO commence

8/15/2019 MERISE OO

9/16

 

 par la définition d’un modèle conceptuel de données (MCD) et se limite, à ceniveau, à l’expression des historiques selon l’axe temporel de validité (avec lesmontres de validité).

En passant au niveau organisationnel, le MCD est complété par l’ajout desspécifications d’ordre organisationnel : types et formats des propriétés, droitsd’accès aux données pour chaque type de site et pour chaque type de poste detravail, mode de gestion des données (informatisé ou manuel), données d’origineorganisationnelle 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 detransaction).

Le modèle organisationnel des données (MOrD) ainsi obtenu cumule ladéclaration de tous les besoins d’historisation. Il comporte des constructions-typestemporelles de validité, des constructions-types temporelles de transaction et desconstructions-types bitemporelles, conformément aux exigences du SI.

Par ailleurs, de nouveaux types et formats temporels permettent au concepteur dedé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, pourdécrire la durée d’un emprunt obligataire) peut être sous la forme « AA ans, MMmois, 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 pardes exemples tirés d’une application « Centrale des renseignements » réalisée ausein 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èresen informations utiles pour la prise de décision. Elle s’intéresse aussi bien auxdonné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.

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

1,1

CHEF V j 

T: 1,n 0,n1,n

INDIVIDU ID _ IND  NOM  NAISSANCE 

ORGANISME  V j ID _ ORG CAPITAL VAL _ ACTION 

0,nT: 1,n 

T: 0,n 

T: 0,n 

 NB _ ACTIONS

Ts ACTIONNAIRE V j 

8/15/2019 MERISE OO

10/16

La figure 2 montre un schéma d’occurrences relatives à l’organisme « SNA » etaux 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 lestemps de validité ou la valeur now  (Jensen et al., 1998) pour les temps detransaction. Les deux premières instances de la relation CHEF rattachentl’organisme « SNA » à l’individu « EDAM  », alors que la troisième rattache cetorganisme à l’individu « EYA ». Finalement, les trois instances relatives àl’occurrence « SNA, EYA » de ACTIONNAIRE montrent l’évolution du nombred’actions de « EYA » dans « SNA ».

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, à traversun historique atomique de son rôle « ACTIV ».

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 » etaux activités « ACT 50 » et « ACT 53 ». Le capital et la forme juridique de « SNCPA »comportent chacun deux instances. L’occurrence relative à « SNCPA,  ACT 53  » deSPECIALITE comporte également deux instances avec deux intervalles de validité

: ACTIONNAIRE 

 NB _ ACTIONS = 1 500

: ACTIONNAIRE 

 NB _ ACTIONS = 500

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

2003/12/10: 2005/10/15:15H 3’ 17’’  23H 59’ 59’’

: INDIVIDU 

ID _ IND = 4545220 NOM = “EYA” NAISSANCE = “3 juin 1979”

: ACTIONNAIRE

 NB _ ACTIONS = 1 000: ORGANISME ID _ ORG = “SNA”CAPITAL = 50 000VAL _ ACTION = 10

[2001/11/16 - 2003/12/31] 2002/7/2: 2003/12/31:10H 6’ 25’’  23H 59’ 59’’

: CHEF 

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

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

!

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

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

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

ORGANISME ID _ ORG CAPITAL TELEPH FORM _ JURIDIQ 

Vm 1,n

ACTIV Vm 

ACTIVITE 

ID _ ACT LIBELLE _ ACT 

SPECIALITET: 1,n

1,n

Vm 

: ORGANISME ID _ ORG = “SNA”CAPITAL = 50 000VAL _ ACTION = 20

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

: ORGANISME ID _ ORG = “SNA”CAPITAL = 100 000VAL _ ACTION = 20

[2005/10/16 - ! ] [2005/10/16 - ! ]

: INDIVIDU 

ID _ IND = 3225777 NOM = “EDAM” NAISSANCE = “5 mai 1975”

8/15/2019 MERISE OO

11/16

 

qui ne se chevauchent pas, alors que celle relative à « SNCPA,  ACT 50 » n’en comportequ’une seule.

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 redondanced’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 historiqueglobal est temporellement normalisée si et seulement si toutes ses propriétés-typesont 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é sitoutes ses entités et toutes ses relations spécifiées avec des historiques globaux sonttemporellement normalisées.

Ainsi, pour éviter les redondances, il y a lieu de ne spécifier des déclarationsd’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. Lamê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 concernentles concepts de Généralisation/Spécialisation et de relation-de-relation, rencontrés,entre autres, dans MERISE/2.

[2002/11– ! ]: SPECIALITE

: ORGANISME 

ID _ ORG = “SNCPA”

CAPITAL = 45 000

CAPITAL = 60 000

TELEPH = 216 74 250 250

FORM _ JURIDIQ = “SARL”

FORM _ JURIDIQ = “SA”

: ACTIVITE 

ID _ ACT = “ACT50”LIBELLE _ ACT = “Fabrication

Pneus Auto” 

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

[2002/11 – 2005/11]

[2005/12 – 2007/3]

[2002/12 – 2006/9]

[2006/10– ! ]

: ACTIVITE 

ID _ ACT = “ACT53”LIBELLE _ ACT = “Fabrication

Pneus Cycle” [2004/10– ! ]

[2002/11 – 2003/12]

: SPECIALITE : SPECIALITE

8/15/2019 MERISE OO

12/16

4.1.  Historisation relative à une « Généralisation/Spécialisation »

 Proposition 4 : La déclaration d’une spécification temporelle d’une relation deGénéralisation/Spécialisation ne s’effectue pas d’une manière explicite, mais plutôtd’une manière implicite à travers une spécification temporelle globale de la super-classe ou à travers les spécifications temporelles des sous-classes, qu’elles soientglobales ou locales.

 Proposition 5 : L’expression d’un historique global ou d’un historique local pourune 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écificationsd’historisation conformément aux principes suivants :

− Les propriétés et les rôles historisés d’une manière atomique au sein d’uneentité 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 surtoutes ses entités spécialisées.

− Un historique global d’une entité spécialisée se limite à cette entité et ne serépercute ni sur son entité générique, ni sur les autres entités spécialisées issues decette dernière.

− Dans le cas d’un héritage composé, une entité spécialisée hérite lesspé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’historiqueglobal. Cet historique intègre alors la trace des changements des caractéristiquesspécialisées de chaque organisme. L’entité spécialisée ORGANISME_BANCAIREhérite, en sus, une historisation atomique de la propriété DOMAIN _ ACT  (domained’activité) de l’entité INSTITUTION_FINANCIERE.

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

ORGANISME_COTE_EN_BOURSE 

 NOMINAL _ ACTIONS ORGANISME_BANCAIRE 

 NB _ AGENCES

ORGANISME V j ID _ ORGCAPITAL VAL _ ACTION 

INSTITUTION_FINANCIERE ID _ INST NUM _ AUTORIS DOMAINE _ ACTIVITE  V j 

8/15/2019 MERISE OO

13/16

 

4.2.  Historisation relative à une relation de relations

 Proposition 6 : L’historisation d’une relation de relations se traite de la mêmemanière que celle d’une relation-type ordinaire, qu’elle soit locale (pour certains deses propriétés et/ou rôles) ou globale.

 Exemple : Le schéma de la figure 6 spécifie un historique global pour la relationde relations GAIN. Une occurrence de GAIN concerne un actionnaire donné pour unexercice donné. Une telle occurrence peut avoir plusieurs instances, chacunecorrespondant à un intervalle de validité spécifique, exprimé avec la granularité« année ».

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 parrapport à un contrat (instance de l’entité CONTRAT). Cependant, formellement, cecas ne se distingue que par la particularité de son identifiant. Nous considérons alorsque son historisation ne nécessite aucune extension particulière. D’ailleurs, une telleinformation 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, REERMet UML-TF, les trois dimensions temporelles (temps de validité, temps detransaction 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 tempsdéfinis par l’utilisateur. Du point de vue application, ce sont MERISE/TEMPO etUML-TF qui respectent le plus le principe d’abstraction ; ils permettent unespécification progressive des spécifications temporelles, d’abord celles relevant duniveau 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

ACTIONNAIRE V j  NB _ ACTIONS 

0,n

0,n

0,n1,nINDIVIDU 

ID _ IND  NOM  NAISSANCE 

GAIN Va MONTANT _ GTYP _ G 

1,n

ANNEE AN  0,n

EXERCICE CHIF _ AFF BENEFICE 

T: 1,n 

T: 0,n 

ORGANISME ID _ ORG CAPITAL VAL _ ACTION

V j 

T: 1,n  T: 0,n Ts 

8/15/2019 MERISE OO

14/16

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 concernantl’expression des cardinalités temporelles pour les relations binaires.

Contrairement à TERM, STEER, TER et TEER, qui modifient les interprétationssémantiques des constructions de base, MERISE/TEMPO, comme RAKE, MOTAR,ERT, le modèle de Kraft, TIMEER, TUML, REERM et UM-TF, assure lacompatibilité ascendante avec les concepts et les représentations de la méthode objetde l’extension.

Par rapport à UML-TF, qui propose des estampilles non figées à travers ladéfinition d’un stéréotype abstrait permettant la modification des caractéristiquesstructurelles et comportementales des estampilles, MERISE/TEMPO ne permet demodifier 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 denouveaux concepts et outils pour rendre l’expression des spécifications temporellesaisée et efficace. Elle se distingue par sa conformité au principe de la démarche parniveau 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 évolutiondans la BDT par une « montre de transaction ». Ce marquage est souple ; il peut êtreeffectué d’une manière locale ou d’une manière globale. La définition d’unenouvelle paire de cardinalités, notée (T: min,max), permet de spécifier les conditionsd’existence de plusieurs instances pour une même occurrence d’une relationhistorisée.

La mise en œuvre de cette extension est concrétisée à travers MERISE/TEMPOqui é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ésentationque 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. Lesnotions d’historique global, d’historique local, d’occurrence, d’instance et denormalisation temporelle d’une entité ou d’une relation sont définies dans un cadregé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 lesspécifications temporelles varieront en fonction du formalisme graphique propre à

8/15/2019 MERISE OO

15/16

 

chacune d’elles. Les différentes interprétations sémantiques des spécificationstemporelles peuvent être adoptées par les autres variantes, sous réserve qu’ellessupportent les concepts considérés tels que ceux de relation n-aire, degénéralisation/spécialisation et de relation de relations. Mais, la définition de la pairede cardinalités temporelles peut ne pas convenir à certaines variantes, sachant que leconcept de cardinalité ordinaire est lui même défini de différentes manières.

 Nous envisageons maintenant d’affiner l’étude de certains conceptsd’historisation, tels que ceux relatifs aux rôles et aux relations deGénéralisation/Spécialisation, et d’étudier les contraintes d’intégrité et les impactstemporels sur les modèles de traitement. La méta-modélisation et la validationformelle 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 dedonné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 dansles 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 »,  ACMTransactions 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 deDonné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 TemporalApplications on top of Object DBMS »,  IEEE Transactions on Knowledge and DataEngineering, vol. 16, n° 3, mars 2004, p. 354-374.

Fauvet M. C., Canavaggio J. F., Scholl, P. C., « A representation-independent temporalextension 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 versioningmodel for schema evolution in object-oriented databases »,  Data & KnowledgeEngineering, vol. 53, n° 2, mai 2005, p. 99-128.

Gregersen H., Jensen C. S., Conceptual Modelling of Time-Varying Information, TechnicalReport TR-35, TIMECENTER , septembre, 1998.

Gregersen H., Jensen C. S., « Temporal Entity-Relationship Models – A Survey »,  IEEETransactions 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 », inEtzion O., Jajodia S., Sripada S. M., Temporal Databases: Research and Practice, LNCS1399, Spring-Verlag, 1998.

8/15/2019 MERISE OO

16/16

Jensen C. S., « Temporal Database Management », dr.techn. thesis by C. S. Jensen, defendedApril 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 controlalgorithm 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éveloppementd’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 faitstemporels », 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, éditionsd’organisation, 1994.

Rochfeld A., « Présentation des évolutions de MERISE »,  Journées Internationales desSciences 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.