implémentation du diagramme de classe uml et des ...agamache/ift3202/pagesweb... · diagramme de...

Implantation des contraintes du MCD ©

Modélisation UML et base de données objets

Implémentation du diagramme de classe UML et des contraintes sémantiques

2012-03-01 ©

André Gamache, professeur associéDépartement d'informatique et de génie logicielFaculté des sciences et de génieUniversité Laval. Québec, Qc, Canada, G1K 7P4Courriel: [email protected]


Modélisation des donnéesLa modélisation des données est antérieure à la modélisation des systèmes que l’on met en œuvre aujourd’hui. En cette période pionnière des années 1975, l’accent portait sur le stockage et la recherche des données. Les applications étaient autonomes et leurs interactions minimales.

De nos jours, les systèmes sont très complexes et sont au cœur de la gestion des grandes organisations. Diverses méthodologies de développement des logiciels ont été proposées dans la lignée de la modélisation des données éprouvée dans le cadre des BD. Elles intègrent la modélisation des données (MD) parmi d’autres modèles dits de traitement. UML est un archétype de cette démarche.

Le MD est souvent central dans l’exploitation des données car l’implantation doit garantir la cohérence et l’intégrité des données indépendamment des nombreuses applications qui y accèdent. Le contraire conduit à des erreurs parfois lourdes de conséquences.


Avantages de la modélisation

Pour le système:

Représentation formelle d'un système et de ses traitements;Outil de validation plus formelle des traitements (notamment celui des données) par le

client;Dveloppement et mise en service d’applications conformes aux contraintes

spécifiées.

Pour les données:

De formuler un modèle de données qui précise les structures de données et leur comportement en cours d’exploitation. C’est le Diagramme de classe (DC) de la méthodologie UML.

Cibler prioritairement :la cohérence, l’intégrité et l’exploitation efficace des données;


Modèle conceptuel de données : MCD

Le MCD sépare les spécifications formelles de l’analyse de celles de l'implémentationafin de les rendre indépendantes des matériels et des logiciels (=> favorise ainsi lapérennité des systèmes)

Conception d'une BD de type OR en 2 phases :

• Modélisation par les données (MCD) selon un formalisme porteur d’une sémantique: E/A (ou Merise) ou avec le diagramme de classe UML;

• Transposition du modèle conceptuel en un modèle d'implantation (logique) : MR, MOR

1, MOO;

1Passage par le un modèle intermédiaire : Modèle navigationnel (Mnav) (C. Soutou, Objet-Relationnel, Eyrolles 1999)


UML : Quelques définitions

UML (Unified Modeling Language) des auteurs : G. Booch, J. Rumbaugh, et I. Jacobson réunis au sein de la société Rational Software (IBM, 2002); intégration des diverses méthodes d'analyse objet. Version de la norme UML 2.0. Le développement se poursuit …

Le langage de modélisation objet définit un diagramme de classe, essentiel pour représenter les données et leurs structures. Notre intérêt en BD porte principalementsur le diagramme de classe (DC).

OID : chaque objet a un identifiant unique généré par le système peu importe son implémentation.

Objet d'analyse (de métier) : instance d'une classe UML du modèle; représente des entités concrètes ou abstraites, distinctes par leur oid…

Is everything an object ? Quel encombrement alors.

Ex. Un entier est un objet en Smalltalk, en GemStone, .. Deux entiers de même valeur (ex 5) créés en des temps distincts sont des objets différents! Cette multiplication des objets finit par encombrer l'espace objet disponible qui est limité par la taille de l'oid. À la saturation de cet espace, que faire? …. Un oid de 64 bits repousse cette limite!

Alternative: utilisez pour cette entité de travail, la notion de valeur simple ou complexe, mais sans oid.


Diagramme de Classe : structure et méthode

Un objet UML est l'instanciation d'une classe du diagramme de classe UML Chaque classe a une structure et des opérations (méthodes). Une classe est abstraite, si <<elle ne peut pas ou n'est jamais instanciée>> :

elle est source d'attributs et de signatures dans une hiérarchie de classes; (voir aussi la notion d'interface)

<< RessourceHum >>

attributsméthodes

Actionnaire Cadre Ouvrier

Classe abstraite

Classe concrète

Attributs et opérations Attributs et opérationsAttributs et opérations


Opération UML : l’interface

L'ensemble des opérations forme l'interface d'une classe UML.

Une opération a un nom et une signature. L'implémentation de l'opération est le bodyde l'opération (ou corps de la méthode).

ActionnairenomAct : string

nasAct: string

capital: real

augmenteCapital(nc)

modifNomAct(nvNom)

…- augmenteCapital() est le nom de l'opération et avec les paramètres constituent la signature qui

doit normalement inclure son type.

Interface


Création et rangement des objets d'analyse

Un objet est généré à l'image d'une classe. La classe est une sorte de template (un moule) d'objets doté de méthodes. Un objet devrait être manipulé uniquement par les méthodes de sa classe.

Classe: description générique pour un ensemble d'objets qui partage une même structure et un même comportement (même type) présents dans le monde à modéliser (le domaine d'application).La classe permet de faire une classification des instances (les objets de métier);

Un container (ou containeur) est associé à chaque classe d'objets (son extension pour ranger les objets) :

-- Extension implicite (GemStone) création automatique lors de la définition d'une classe;

-- Extension explicite (O2 et Oracle 10g). Création par le DBA avec une structure données appropriée : Une liste nommée (O2), une table (Oracle).


Nom de la classe

Notation graphique de la Classe et signature

Signature := (nom méthode + nom des paramètres et leur type)

Type d'un objet = Classe + Interface

Corps (body) de la méthode (n'est pas représenté dans le DC) (implémentation)Les visibilités : + Publique # Protégée - Privée le défaut => +

La classe schématise une structure des instances (objets) regroupées sur la base de la structure et d'un comportement similaires.

Visibilité de l'attribut

Classe

Attribut

Signature de méthode

Poste_travail+ noSerie : int

# adrIP : string

- typePoste : char

+ ajoutPoste( noS: int)

+ getAdrIP(noSerie : string)Interface de la classe


Un attribut a une visibilité : privée ou private (-), protégée ou read (#) et publique ou public (+).

Un objet de la classe C1 peut utiliser tous les attributs et méthodes de sa classe (C1) (+, #, -).

Un objet de C1 peut aussi utiliser les attributs protégés obtenus par héritage des classes supérieures (# +) à C1 mais pas les privés (–) de C0;

Un objet de C4 n'a pas accès aux attributs (-) de C1 qui est hors de sa hiérarchie d'héritage, mais a accès aux attributs + de C1;

Classe : Visibilité des attributs (et des méthodes)

C0

C1

C2

C3

C4


Encapsulation et constructeur d’un objet

L'encapsulation complète d'une classe exige la manipulation des objets (par une application) que par ses opérations (ses méthodes).

L'interface de la classe est définie comme l'ensemble des signatures. L’interface peut être enrichie subséquemment avec des nouvelles méthodes.

Une méthode se distingue d'une procédure cataloguée par le fait qu'elle est strictement associée aux données d'une classe et n'est partageable que par héritage.

Toute application ou procédure stockée peut référer à une méthode via son nom et sa signature;

Tout objet est créé par un constructeur et est persistant s'il a un OID ou s'il est incorporé dans un autre objet persistant. Autrement, il est transitoire (objet de travail).

La désencapsulation : accès aux données en contournant les méthodes: avec l'opérateur * (affaiblit l'idée de l'objet)


Attribut ( idem à la notion de propriété de ODMG)

Attribut : sert à caractériser les classes et les associations; chaque attribut est associé à un nom de domaine : syntaxique ou/et sémantique.

Domaine : ensemble nommé et structuré de valeurs, de références ou de oid typés (oid d'une classe d'objets):

Ex. domaine College_Qc : { 'Garneau', 'Limoilou', 'Groulx',…}

Le domaine constitue une contrainte sémantique pour un attribut. Il peut être partagé entre les attributs.

Niveau variable de l’ implémentation du domaine de l’attribut college:- Create Domain d_college_Qc varchar(50) ; essentiellement syntaxique- Constraint c_college Check college IN ('Garneau', 'Groulx', ..); (SQL-2 + Oracle)

- Create Domain d_college varchar(50) Check ( college IN(Select Distinct college From Registre));


Attribut du MCD : sans contrainte

Attribut : atomique, composé, complexe

Atomique : age => 32Composé : adresse => (no, rue, ville) -- composéComplexe : histoAdresses : {adresse} -- composé d'un ensemble d'adresses.

Référence (REF) :

Une sorte de pointeur logique sur un objet construit principalement avec l'oid (OO) +éventuellement d'autres infos intégrées comme le oid de la classe )Object IDentifier .

NB: En OR, la référence peut être composée du oid + rowid (du tuple).En objet, la référence est seulement l’OID.


Attribut d'instance et de classe

Attribut d'instance; a une valeur puisée dans un domaine et cela pour chaque instance :

Classe Personne : nas, nom, ….Une instance est définie ainsi =>

:Personne oid5 := '234567890', 'Gingras', …** le symboleobjet5 pourrait être le oid de cet objet

Une classe aussi peut avoir un (ou plusieurs) attributs de classe associés à l'ensemble des objets de la classe. Cet attribut n’est cependant pas partagé par ses instances de la classe. (Voir implémentation dans les systèmes experts).Exemples :

SalMoyen des personnes, TotalSalPaye des employés de tous les départements,...

Attribut de classe : Plus rarement implanté dans les modèle de données:valeur d’attribut associée à une classe et non aux instances.


Association : permet de relier une classe avec une ou plusieurs autres;Sur le plan sémantique : met en relation les objets des classes impliquées dans l'association comme cela est observé dans la réalité.

Multiplicité: chaque extrémité d'une association A — B, a une contrainte de multiplicité(CM) qui exprime le nombre minimum et maximum d'objets d'une classe A pouvant être reliés à un objet de classe B lorsque présent dans la base.

Entité-Association UMLEntité ClasseAssociation Association (relation)Occurrence Objet (instance)Cardinalité Multiplicité*Modèle Conceptuel de données Diagramme de classe

Cardinalité Multiplicité UML0, 1 0..11, 1 1..1 ou 1 (le défaut)0, N 0..* ou * (le défaut)1, N 1..*N, N *..*

Association entre classes

* La multiplicité impose des contraintes à vérifier en-ligne pour garantir la cohérence du modèle.


Cours

noCours* : int

Titre : varchar

nbCred : int

Gradues

mat

nomSupervise> *

Professeur

matProf*: int

Nom : varchar

statut

EstResponsable > 1

1..1

0..*

1..*

UML: Association: multiplicité par défaut

Absence de multiplicité sur une association : [1..1 ou 1 ] et [ 0..* ou * ]

- Une association est souvent nommée par une expression verbale


Modèle de données et transaction logique

Un MCD représente les données structurées dans leur état stable i.e. qu’il modélise l’état de l’ensemble des données à un moment t lorsqu’il y a aucune action ou manipulation en cours.

Transaction logique (TL)Les manipulations de données (ajout, mise à jour et suppression sur un ou plusieurs objets declasses différentes) sont exécutées par une suite d’actions élémentaires présumant la validationultérieure des contraintes de multiplicité du MCD. Chaque TL est présumée en exécution

concurrente avec d’autres transaction logiques. Les propriétés ACID sont assumées.

Exemples:- Ajout d’un employé : une seule action d’insertion dans la BD compose la transaction logique; à

la fin de cette action les contraintes de multiplicité du MCD seront vérifiées.

- Ajout d’un employé et ajout d’un département dans la même transaction logique; à la fin de la TL les contraintes de multiplicité seront présumées vérifiées.

Important: Si la cohérence est mise en péril, la TL doit être annulée.


Exemple d’incohérence avec une TL

Professeur

matProf* : string

nom : string

statut : char

Cours

noCours* : string

titre : string

nbCred : integer

EstResponsable > 1..11..*

1- Si un applicatif veut ajouter seulement un professeur dans la base:TL1 : Ajout professeur ( 'mat45 ', ' Tremblay’, ' P') ;

Cet ordre Ajout constitue une transaction logique simple. Si l’insertion est autorisée par le SGBD, labase sera alors dans un état incohérent au regard du MCD dont la multiplicité est 1..1 du côté Cours.

2- Si deux actions sont incorporées dans 1 transaction logique:TL2: Ajout professeur ( 'mat45 ', ' Tremblay ', ' P ') ;

Ajout cours values (45, ' C++ ', 3);

A la fin de la TL2, la cohérence du modèle est respectée (donc de la BD) parce que les multiplicitéssont validées conformément au modèle. Cette cohérence découle de la transaction logique (TL).** L’implémentation de l’association dans le modèle relationnel exige en sus une clé étrangère dans l’instance de Cours.


Transaction logique et transaction physique

Une transaction logique devient une transaction (physique) dans un SGBD particulieravec un marquage particulier du début et de la fin de la transaction qui varie selon leSGBD. Avec Oracle :

• Début : l’exécution d’un 1er DML• Fin: Commit

Les contraintes de table sont vérifiées qu’à la fin de la transaction,si et seulement si les contraintes de table dont dites reportables (Deferrable) dans le schéma.

Exemple: SET Constraints ALL Deferred

NB Les transactions longues sont préjudiciables aux autres utilisateurs


Navigabilité des associations

Par défaut: toute association a un parcours bidirectionnel. Il est possible de privilégier une direction par le symbole ou >

ClubDeSport

noCS* : int

siteCS

abonnementCS

Abonne

nasA :string

nomA

periodeA

< Est_Inscrit0..* 1..*

Navigabilité

Le modèle privilégie l'accès au club sportif via le nasA. Cela implique que nasA utilisé dans l'implantation de l'association soit indexé .

Présomption que les applicatifs accèdent de préférence, (mais non limités à)au Club sportif via le nasA de l'abonné.

N.B. L’ajout d’un nouveau club se fait dans une TL qui doit aussi comprendre l’ajout d’au moins 1 abonné à ce nouveau club!

A la fin seulement de la TL, la multiplicité 1..* du côté Abonné est ainsi vérifiée.


Importance de déterminer correctement la multiplicité, car les schémas OR et OO repose sur la transformation des classes et des associations en tenant compte des multiplicités UML.

Contraintes du modèle:1. Ajout d'un poste de travail ne résulte pas nécessairement en une connexion à un

segment du réseau;

2. Ajout d'un segment exige cependant une connexion obligatoire à au moins un poste de travail existant ou au cours de la TL d’un nouv même TL l’ajout d’un poste pour créer l’association ;

UML : Multiplicité des associations et contraintes implicitesUn segment (de réseau) connecte au minimum 1 ou plusieurs postes de travail

PosteTravailnoSeriePT*: int

adrIPT : varchar

typePT : char

SegmentadrS: varchar

nomS: varchar

longueurS: int

1..* 0..1Connecte


Lecture du modèle

Suppression d'un segment entraîne la déconnexion des postes, mais les postes de travail peuvent demeurer dans la base.

Suppression d’un poste de travail peut ou pas exiger la suppression du segment:

1- si le poste de travail est le dernier relié à ce segment, alors suppression du segment;

2- Si le poste de travail n’est pas le dernier, alors aucun segment ne doit être supprimé;

PosteTravailnoSeriePT*: int

adrIPT : varchar

typePT : char

SegmentadrS: varchar

nomS: varchar

longueurS: int

1..* 0..1Connecte


UML: Association 1-1 (1 relation) avec multiplicité 1..1

Si implanté avec une seule relation: StageEtudiant (noS*, themeS, respS, matriculeE, nomE)

Contraintes de ce modèle relationnel:Il ne peut pas y avoir un étudiant sans stage et inversement!1. Le matriculeE et noS ne peuvent pas être null (clé);2. La suppression d'un stage entraîne nécessairement celle de l'étudiant qui l'avait choisi.* L’ajout d'un stage par une TL ne sous-tend pas nécessairement une violation de la multiplicité si dans la même TL, il y a ajout d’un étudiant pour ce stage. Les contraintesétant reportées à la fin de la TL.1. ** L’ajout d'un étudiant dans une TL sans l’associer à un stage sous-tend une

violation de la multiplicité 1..1!2. La suppression de l'étudiant doit entraîner celle de son stage.

EtudiantmatriculeE* : int

nomE : string

StagenoS* : int

themeS : string

respS: string

1..1 1..1EffectueUn >


Script DDL-Oracle pour implémenter l'association 1-1 avec 1 relationCreate table EtudiantStage (

noS number(3),themeS varchar(40) not null,respS varchar(40),matriculeE varchar(6),nomE varchar (40),

Constraint Pk_Stage Primary Key (noS) Deferrable,Constraint U_matricule Unique (matriculeE) Deferrable,Constraint PK_non_null Check( noS is NOT NULL) Deferrable,Constraint FK_non_null Check( matriculeE is NOT NULL) Deferrable);

Remarques: La clé primaire noS est NOT NULL par une contrainte de table et peut être

Deferrable. La clé candidate matriculeE est NOT NULL par contrainte de table et peut

être Deferrable.

Impossible d’ajouter un étudiant qui n’a pas encore choisi son stage!

Clé candidate spécifiée comme une contrainte de table.


Définition de la transaction et report des contraintes

Pour réaliser ces ajouts dans l’applicatif il faut utiliser une TL et reporter la validationdes contraintes:

SET Constraints ALL Deferred; -- toutes les contraintes Deferrable sont reportées y compris le Check spécifié comme une contrainte de table. (sauf les triggers)

Début de TL: Insertion d’un stage sans titulaire étudiant;Insert into StageEtudiant values( 120,' info', 'Jacques' null, null);

Insertion d’un étudiant titulaire du stage 120:Update StageEtudiant set matriculeE = 1145, nomE = 'Savard' Where noS= 120;

Fin TL: COMMIT – vérification de toutes les contraintes. Dans ce cas-ci, c’est validé.


EtudiantmatriculeE*

nomE

StagenoS*

themeS

respS


UML: Association 0..1--1 ..1 ( MR1: avec 2 relations)

Modèles relationnels:MR1: Stage (noS*, themeS, respS)

Etudiant (matriculeE*, nomE, noS) -- FK du côté de 0..1

Contraintes conjontives du MR1:1. Dans Etudiant, noS est une clé étrangère NOT NULL.2. La suppression d'un étudiant n'entraîne pas celle du stage;3. La suppression d'un stage entraîne celle de l'étudiant. 4. Ajout d'un étudiant doit obligatoirement entraîner une association à un

stage via la FK! Si noS est valué c’est OK; sinon, faut retarder la contrainte référentielle car le stage doit-être mis à jour dans la TL!

5. Ajout d’un stage est possible sans l’ajout obligatoire d’un étudiant.

noStage


Script DDL pour l'association 0..1– 1..1 implémentée par 2 relations (le MR1)

Avec 2 TL:Insert into Stage values (1, 'mecano', 'Paul') ; -- ok pas de contrainteInsert into Etudiant values ('mat12', 'Fortin', 1); -- CR OK

Avec 1 TL: Execute immediate ‘Set Constraints all deferrred’ ;Insert into Etudiant values ('mat12', 'Fortin', 2); -- le stage 2 inexistant

Update Etudiant set noS = 1 Where matriculeE = 'mat12';

Create table Stage (noS number(3), -- table parent

themeS varchar2(40) not null,respS varchar2(40) not null,Constraint pk1_StageE Primary Key (noS));

Create table Etudiant (matriculeE varchar(40) not null, nomE varchar(40), noS number(3),

Constraint pk_Etudiant Primary Key (matriculeE),Constraint C_noSNotNull Check ( noS is not null) initially deferred Deferrable,Constraint fk_matriculeE Foreign Key(noS) References Stage(noS) On Delete

Cascade Deferrable) ;


EtudiantmatriculeE* : int

nomE:

StagenoS* : int

themeS:

respS:


Autre implémentation: Association avec multiplicité 0..1 --1..1 (MR2: 2 relations)

MR2: Etudiant (matriculeE*, nomE)Table enfant: Stage (noS*, themeE, respE, matriculeE) – la FK du côté 1..1

Contraintes du MR2:1. Dans la relation Stage, matriculeE est un attribut qui peut-être NULL tout en étant une clé

étrangère.2. Impossible d’ajouter un étudiant sans en même temps lui assigner un stage!3. Ajout d'un stage peut se faire sans l’assigner à un étudiant4. La suppression d'un stage choisi doit entraîner celle de l'étudiant ou son association à un

autre stage. 5. * Ajout d'un étudiant est correct qu’en créant dans la même TL une association avec un

stage!

matriculeE


Script DDL pour l'association 0..1--1..1 implémentée par 2 relations (MR2)

Create table Stage (noS number(3),themeS varchar2(40) not null,respS varchar2(40) not null,matriculeE varchar2(40),

Constraint pk1_StageE Primary Key (noS),Constraint N_MatriculeE Check ( matriculeE is NULL), -- C1Constraint fk_matriculeE Foreign Key(matriculeE) References Etudiant(matriculeE)

On Delete Cascade Deferrable) ; -- C4

Set constraint all deferred;Insert into Etudiant values ('mat12', 'Fortin'); -- Insertion réalisée, mais pas d’association avec un stage. -- C2??

Donc incohérence au regard du modèle!

==> supposons un ajout de stage avec un null :Insert into Stage values(1, 'mecano', 'Jean', null ); -- ok mais pas de stage pour l’étudiant mat12!Commit; -- fin de TLes 2 ajouts sont faits dans 2 transactions distinctes violation de la C2

Comment renforcer la contrainte C2 du MR2?

Create table Etudiant (matriculeE varchar(40), -- table parentnomE varchar(40),

Constraint pk_Etudiant Primary Key (matriculeE),Constraint C_nonNull Check (matriculeE is not null) Deferrable);


En utilisant une transaction composée de 2 ou + actions inséparables (atomiques):

1- Execute immediate ‘SET constraints ALL deferred’ ;2- Ajout d'un étudiant en 1er: toute l'info sur l’étudiant doit être connue et

disponible; (sans vérification des contraintes)Insert into Etudiant values ('mat12', 'Fortin');

3- Ensuite, ajout de son association avec un stage choisi : Insert into Stage values(1, 'mecano', 'Jean', null);

4- Update Stage set matriculeE ='mat12';5- COMMIT;

Si la mise a jour est faite correctement (sans erreur), la contrainte C2 est alorsvérifiée:C2: card(Etudiant[matriculeE]) =< card(Stage[matriculeE])

MR2: Transaction : définition pour l'applicatif


La table mutante

La contrainte précédente C2 peut être aussi implémentée par un trigger mais nonsans difficultés notamment celle du mutating table qui est contournée par l’usage d’une variable globale et des packages du SGBD Oracle.


Essai d’implémentation de C2 avec un trigger (=> mutating table)

Create or replace trigger valideAssoStageEtudiant After Update OR Insert on Stagefor each row

DeclarenbMatS int;nbMatE int;Begin

Select Count(matriculeE) into nbMatSFrom Stage Where matriculeE = :NEW.matriculeE;

Select Count(matriculeE) into nbMatEFrom Etudiant Where matriculeE = :NEW.matriculeE;

IF nbMatS != nbMatE Then Raise_Application_Error(-21400, 'C2 invalidée');End If;

End;/


Incohérence suite à l'insertion de données avec une transaction

SQL> insert into Etudiant values ('123A', 'Paul');

1 row created.-- Sans faire de commit pour que la transaction soit considérée comme toujours active

-- Dernière partie de la transaction:

SQL> insert into stage values (1, 'technico-commercial', 'Fortin', null) *

ERROR at line 1:ORA-04091: la table ANGAM.STAGE est en mutation ; le déclencheur ou la fonction ne peut pas la voir.

ORA-06512: à "ANGAM.VALIDEASSOETUDIANT", ligne 5ORA-04088: erreur lors d'exécution du déclencheur 'ANGAM.VALIDEASSOETUDIANT1'

Cet ajout (insert) qui a déclenché le trigger est défait automatiquement.La transaction n'est pas exécutée en totalité! Le stage est absent et l'étudiant

est cependant présent! Incohérence au regard de C2.


Solution: contourner le mutating table généré par le trigger avec une variable globale

Création d'une variable globale (voir package) initialisée lors l'insertion de l'étudiant.

Initialisation de la variable globale crée au préalable : varG:

Create or replace trigger initStage BEFORE INSERT or UPDATE On Etudiant for each rowBeginIf :new.matricule is not null then

packvarGlobale.v_matricule := :new.matricule; -- init de la varGEnd if;ExceptionWhen NO_DATA_FOUND THENRaise_Application_Error (-20050, ‘non initialisation de matricule'); End;


Validation par trigger : contrainte de la mutation de table

Rappel :Un trigger associé à une table ne peut pas lire, via son propre code, le contenu de cette même table à laquelle il est relié. (mutating Table). De même, un trigger associé à une table ne peut lire pas dans la table contrainte par une référentielle (constrainedtable).

Un trigger n'est pas Deferrable. (ne peut pas être reporté ou retardé)

Mutation conséquence de l'appropriation des verrous par une transaction distincte du processus associé au trigger dont le propriétaire est la BD ou le DBA.Exception : trigger BEFORE INSERT si un seul objet est inséré.

Solution:Par l'usage d'une variable globale déclarée par le biais d'un package ou utilisation d’un

trigger de statement (table).


Trigger pour renforcer la participation obligatoire de l'étudiant à un stage

L'ajout d'un étudiant doit nécessairement entraîner son association à un stage. La contrainte référentielle est insuffisante, il faut une transaction et un trigger pour valider que:

C2 soit tel que: Etudiant[matricule] = Stage[matricule] .

/* Création d'une variable globale avant la spécification des fonctions et procédures du package*/Create Or Replace package packvarGlobale as v_matricule varchar2(40); -- variable globale publique, var déclarée dans la spec. du pack.End;

/* initialisation de la variable globale */Create or replace trigger initStage BEFORE INSERT or UPDATE ON Etudiant for each rowBeginIf :new.matricule is not null then

varGlobale.v_matricule := :new.matricule; -- ajout étudiantEnd if;ExceptionWhen NO_DATA_FOUND THENRaise_Application_Error (-20050, 'Pas initialisation de matricule');End;/


Transaction : ajout dans Stage

Validation que l'étudiant soit associé à un seul stage (suivant un ajout à Stage)Create or Replace trigger ControleEtudiant AFTER INSERT OR UPDATE On StageDeclarev_totalMatriculeDansEtudiant Number (2);v_totalMatriculeDansStage Number (2);BeginIf packVarGlobale.v_matricule is not null thenBeginSelect Distinct Count(matricule) into v_totalMatriculeDansEtudiantFrom Etudiant Where matricule = packVarGlobale.v_matricule;Select Count(matricule) into v_totalMatriculeDansStage From StageWhere matricule = packVarGlobale.v_matricule;IF v_totalMatriculeDansEtudiant != v_totalMatriculeDansStage THEN packVarGlobale.v_matricule := null;

Raise_Application_Error(-20330, 'multiplicité 1 violée'); -- erreur à traiter par l'applicatifEnd If;End; -- un trigger n'est jamais DEFERRABLE et est Initially Immediate

End If;End;/

Transaction :

1. Ajout d'un étudiant en 1er, (avec initialisation de la variable globale) et ensuite, 2. Ajout de son association avec un stage choisi, (par un Update sur la FK de Stage ou un

Insert dans Stage avec une FK ) et COMMIT.


Essai d'insertion sans une association avec stage (avec MR2)Insert into Etudiant values ('123A', 'Pierre'); --OKInsert into Stage values (1, 'technico-commercial', 'Fortin', '123A'); -- OKCommit; -- contraintes vérifiées

Insert into Etudiant values ('7B', 'Hélène');

Insertion d'un stage non choisi:Insert into Stage values (2, 'Techno', 'Germain', null); -- erreur

ERROR at line 1:ORA-20330: multiplicité 1 violéeORA-06512: à "ANGAM.CONTROLEETUDIANT", ligne 12ORA-04088: erreur lors d'exécution du déclencheur 'ANGAM.CONTROLEETUDIANT'

-- la transaction n'est pas complétée et l'applicatif doit supprimer l'ajout dans Etudiant

Insert into stage values (2, 'Techno', 'Germain', null);1 ligne créée.SQL> commit;Validation effectuée. -- ajout réussi d'un stage non choisi. Validation``a compléter par Commit

Est-ce possible de faire la transaction suivante?

Insertion dans Stage (avec une valeur pour FK)Insertion ensuite dans Etudiant ?

Non, car le trigger ControleEtudiant s'exécute immédiatement avec l'ajout d'un tuple dans Stage


Tableau synthèse des triggers et des lectures autorisés avec Oracle sur la table associée à un trigger ou avec la table parent impliquée dans une contrainte

référentielle

Trigger

DML(table) DML (Statement: ligne/objet- For each row)

Before After

InsertUpdate

Delete

InsertUpdate

Delete

InsertUpdate

Delete

InsertUpdate

Delete

InsertUpdate

Delete

Before After Instead Of

Mutation: pas avec le select

Figure du document de D. Donsez, Triggers SQL, 2003

En rouge: le DML qui active la table mutante


Exercice avec les triggers

Soit la base suivante :

VenteArticle (noArt* number(5) , qte number(4) , prix number(6,2), dateV Date ) et VolumeVente (total number(8,2), dateVV Date)

1- Formulez un trigger pour mettre à jour VolumeVente qui contient qu’une ligne pour chaque jour et reflétant le total des ventes à tout instant de cette journée (Insert VenteArticle).

2- Formulez un trigger pour mettre à jour VolumeVente afin de refléter l’annulation d’une vente d’article dans la table VenteArticle (Delete d’une vente dans VenteArticle).

***ici


Solution: : trigger After Insert et After Delete

(à suivre)


Suite du survol des modèles UML


UML rôle d’une association : aide à la conceptualisation

L'extrémité d'une association peut être enrichie d'un rôle qui décrit comment la classe (d’origine) perçoit l'autre classe :• Un professeur à titre d'enseignant est responsable de 0 à plusieurs cours

du 1er cycle (le rôle ici contraint le niveau des cours)• Rare de nommer association et ses rôles sur le même lien, mais cela est

utile avec l'association réflexive.

Le rôle est rendu de préférence par un nom.Les cours de plusieurs niveaux sont des objets de la même classe (donc même

description), mais seuls ceux du 1er cycle participent à l'association EstResponsable. (du moins dans cet exemple!).

Que conclure pour les cours si la multiplicité du côté de Cours est 1..* ?

ProfesseurmatProf*

nom

statut

CoursnoCours*

titre

niveau0..1 *

EstResponsable >

enseignant 1erCycle


UML: Autre exemple de rôle d'une association

1. La notion de rôle est conceptuelle et absente au niveau physique.2. Le département dans son rôle d'employeur embauche les personnes comme

travailleurs. Une personne dans son rôle de travailleur est donc embauchée par un département qui agit comme un employeur.

3. Une personne dans son rôle de travailleur est embauchée par un département.

4. La suppression d'une personne n'entraîne pas celle du département.5. Un département est inscrit dans la base avec ou sans employés.

rôle

Departement

noDep*

Personne

Matricule*employeur

travailleur

Embauche> 0..*

1..1

Departement (noDep*)

Personne (matricule*, noDep)


Script DDL pour cette association 0..*

Create table Departement (noDep number (3) not null Check (noDEP >1 and noDep <125),

Constraint pk_Dep Primary key (noDep));

Create table Personne (matricule number(4) not null Check (matricule < 5000 and matricule >1000),nomPers varchar(40) not null,noDep not null Check (noDEP >1 and noDep <125), Constraint pk_Personne Primary key (matricule),Constraint fk_Personne Foreign Key (noDep) References Departement (noDep)

On Delete Cascade);

Autre écriture de la contrainte sémantique pour l'attribut noDep:noDep Constraint c_noDep,…Constraint c_noDep (noDep > 1 and noDep < 125 and is NOT NULL)

La multiplicité 0..* pour Personne ne requiert pas un trigger pour valider l'association avec un département, car elle autorise tout.


UML: Multiplicité de la classe d'association (CA)• Classe pour représenter les attributs et les opérations d'une association UML *.. *

• La CA est reliée par une ligne pointillée et est idem à une classe : avec une multiplicité par défaut de 1 (soit 1..1);• La représentation de la clé de la CA dans le modèle UML st non obligatoire; elle est implicitement présente, formée notamment de chaque clé des classes participantes : nas, noMd;

OrdonnancenoMed*pharma

MedecinnoMd*nomhopital

0..*Personne

nas*nomville

ConsultationdateCdiagnostic

0..* Consulte >

Prescrit > 0..*1

< EstConsulte_Par

1Ajoutmodif

AjoutChangement


Classe d'association: Passage de UML au modèle relationnelMR:

Personne( nas*, nom, ville)Medecin (noMd*, nom, hopital)Consultation (nas*, noMd*, dateC*, diagnostic)

Contraintes du MR: Ajout d'une personne dans la base avec association facultative avec un médecin. Si

cette association existe alors il y a obligatoirement une consultation à une dateC. Ajout d'un médecin avec association facultative avec Personne et donc idem pour

Consultation. La multiplicité de 1 pour la CA traduit le fait que pour chaque consultation qui existe

entre une personne et un médecin, car il y a obligatoirement une consultation faite à une date précise : 2 contraintes d'inclusion en découlent pour la CA:

noMd, nas, dateC diagnostic- Projection de Consultation sur noMd projection de Medecin sur noMD.- Projection de Consultation sur nas projection de Personne sur nas.

C4: Suppression d'une personne ou d'un médecin entraîne une suppression dans la CA.


Script DDL pour implémenter la CA Consultation et ses contraintes

Create table Personne (nas varchar(6) not null, nom varchar(40) not null, ville varchar(40), Constraint pk_Personne Primary Key (nas));

Create table Medecin (noMd Number(4) not null, nom varchar(40), hopital varchar(40),Constraint pk_Mededin Primary Key (noMd));

Create table Consultation nas varchar(6) not null, noMd Number(4) not null,dateC Date, Diagnostic varchar(100) not null,

Constraint pk_Consultation Primary Key (nas, noMd, dateC),Constraint fk_Personne Foreign Key (nas) References Personne (nas) On Delete Cascade Deferrable Initially Immediate,Constraint fk_Medecin Foreign Key (noMd) References Medecin (noMd) On Delete Cascade Deferrable Initially Immediate);

C4


Validation de la contrainte d'inclusion entre Consultation et Personne

Par la contrainte référentielle, tout nas de Consultation est aussi un nas de Personne. De même, tout noMed de la CA est aussi un noMed dans Medecin.

Les autres nas de Personne et Medecin (non présents dans la CA Consultation peuvent être présents sans contrainte sémantique particulière du moins dans ce modèle). C’est le cas d’une personne ou d’un médecin sans encore de consultations

Le nas doit cependant vérifier toute autre contrainte syntaxique définie dans le schéma.


Pour l’association *..* il y aura obligatoirement une classe-association (CA):

DepartementcodeDep*

nomDep

budget

LogicielnomLogiciel*

editeur1,N 0,NAchete

dateAchat

E/A (Merise)

Avec Merise: Autre exemple de CA: Association binaire 0..*- 1..*

Classe-Association

UMLDepartement

codeDep*

nomDep

budget


editeur1..* 0..*

AutorisationnoAuto*signature

2..2< Requiert

1

AchatdateAchat

1

Achete > Autre associationavec une classe


Modèle relationnel avec la CA

1. Ajout dans CA :Lorsqu'un département achète un logiciel, cela se fait à une date précise et celle-ci est inscrite dans une instance créée de facto (tuple) de type CA.

A- Tout nomLogiciel dans Logiciel est aussi dans Achat puisqu'une telle instance doit être en association avec Departement.

card(Logiciel[nomLogiciel]) = card(Achat[nomLogiciel])

B- Tout codeDep de Achat est aussi dans Departement sans égalité des projections

C- Il peut y avoir un département sans logiciel, il n'apparaît donc pas dans la CA.

Departement (codeDep*, nomDep, budget) Logiciel (nomLogiciel*, editeur)Achat (codeDep*, nomLogiciel*, dateAchat*)


(Suite) Association entre une autre classe et la CA

Avec la classe Autorisation en association avec la CA, la sémantique devient plusriche:

Lors de l'inscription de la date d'achat, il doit y avoir deux signatures obligatoiresinscrites dans l'autorisation associée.

3- Suppression: Si un logiciel est supprimé de la base, tous ses achats le sont aussi dans la table Achat, mais le département qui l’avait acheté peut y rester.

Si un département est supprimé, toutes ses fiches d'achat le sont aussi, ainsi que les logiciels dont il est le proprio. Les autorisations sont aussi entraînées dans la suppression!

Report de la validation d'une contrainte:Une contrainte (d'attribut, clé primaire, référentielle,… sauf le trigger) peut êtrereportée à la fin d'un transaction marquée par le COMMIT (Deferrable).Par défaut, elle est Initially Immediate ou est rendue par la directive:

SET CONSTRAINT All Deferred.


Script DDL et implémentation des contraintes

Create table Departement (codeDep Number (2) not null, nomDep varchar(40) null,budget number (6,2) null, Constraint pk_Departement Primary Key (codeDep));

Create table Logiciel (nomLogiciel varchar(40) not null, editeur varchar(40) null,Constraint pk_Logiciel Primary Key (nomLogiciel));

Create table Achat (codeDep Number (2) not null, nomLogiciel varchar(40) not null,dateAchat Date null,Constraint pk_Achat Primary Key (codeDep, nomLogiciel, dateAchat),Constraint fk_Achat_Logiciel Foreign Key (nomLogiciel) References Logiciel(nomLogiciel)

ON Delete Cascade Deferrable initially Deferred, -- validée au commit Constraint fk_Achat_Dep Foreign Key (codeDep) References Departement(codeDep) On

Delete Cascade Deferrable initially Deferred – validée au commit);


Implémentation de la validation de la multiplicité 1..* pour Logiciel et AchatPour chaque insertion dans Logiciel et Departement, il faut que:

card(Achat[nomLogiciel]) = card(Logiciel[nomLogiciel]) etcard(Achat[codeDep]) card(Departement [codeDep])

La mutation des tables est évitée par l'usage d'une variable globale./* Création d'une variable globale */

Create or Replace package varGlobale2 as v_logiciel varchar(40);End; /

/* initialisation de la variable globale du package lors de l'insertion d'un logiciel */Create or replace trigger initLogiciel BEFORE INSERT On Logiciel for each row

BeginvarGlobale2.v_logiciel := :new.nomLogiciel; -- init de la varGlobaleExceptionWhen NO_DATA_FOUND THEN

Raise_Application_Error (-20050, 'pas de logiciel');DBMS_OUTPUT.PUT_LINE(varGlobale2.v_logiciel); End;/


Trigger de validation de la multiplicité 1 pour la CA, Achat

L'insertion d'un logiciel établit une association avec un département et sous-tend aussi la création d'une instance de Achat.

Create or Replace trigger ControleMulti AFTER INSERT On LogicielDeclarev_totalLogicielDansAchat Number (2);v_totalLogicielDansLogiciel Number (2);BeginSelect Count(Distinct nomLogiciel) into v_totalLogicielDansAchat

From Achat Where nomLogiciel = varGlobale2.v_logiciel;Select Count(nomLogiciel) into v_totalLogicielDansLogiciel

From Logiciel Where nomLogiciel = varGlobale2.v_logiciel;IF v_totalLogicielDansLogiciel != v_totalLogicielDansAchat Then

Raise_Application_Error(-20530, 'multiplicité 1 violée pour la CA Achat');End If;End;/


Blocage de l'insertion dans Logiciel qui ne participerait pas à l'association

• SQL> Insert into Logiciel values ('L1', null); • Insert into Logiciel values ('L1', null)• *• ERREUR à la ligne 1 :• ORA-20530: multiplicité 1 violée pour la classe Achat• ORA-06512: à "ANGAM1.CONTROLEMULTI", ligne 10• ORA-04088: erreur lors d'exécution du déclencheur 'ANGAM1.CONTROLEMULTI‘

Comment procéder pour insérer un logiciel et le relier obligatoirement à un achat (CA)?

Avec la transaction suivante:

Set Constraint all Deferred; /* ou Deferrable initially Deferred dans le schéma */

Insert into Achat values (1, 'L3', Sysdate); -- insert en premierInsert into Departement values(1, 'D2', 2500.00);Insert into Logiciel values ('L3', 'E1'); -- déclenchement du triggerCommit;

Validation Effectuée


Procédure pour encapsuler l'ajout

Pour renforcer la notion de transaction, l'ajout pourrait être fait par un appel d'une Procédure PL/SQL stockée dans le dictionnaire du SGBD :** Les utilisateurs sont alors interdits de Insert, Update et Delete sur les 3 tables:

CREATE OR REPLACE Procedure Ajout_LogicielAssocieAchat(codeD IN int,nomL IN varchar, editeur IN varchar, dateA IN date) asBeginIF codeD is not null and nomL is not null and editeur is not null Then

BeginInsert into Achat values(codeD, nomL, dateA);Insert into Departement values(codeD,null, null);Insert into Logiciel values(nomL, editeur);End;

End if;DBMS_output.put_line ('association établie')End; --avec Set Constraints All Deferred;

/SQL> CALL Ajout_LogicielAssocieAchat (2, 'L8', 'editeur9', SYSDATE);


UML: Deux associations entre les 2 classes

• 2 associations entre les mêmes classes: 1 association avec propriétés et une autre sans propriétés.• Plus de 2 associations, cela indique un couplage fort et probablement une décomposition inadéquate;

MR: Stage ( noStage*, sujet, resp)Etudiant (matricule*, nom, noStage) – affecté à StageSouhaite (noStage*, matricule*, dateDepot*) -- souhaite réaliser

Etudiant

matricule*: int

nom

Stage

noStage* :int

sujet

resp

AffecteA >

< Souhaite 0..*1..*

0..10..1

StageSouhaite

dateDepot


MR avec deux associations entre les mêmes classes

Contraintes :

1. Ajout d'un stage qui n'est pas contraint de participer à une ou l'autre des associations.

2. Ajout possible d'un étudiant pour exprimer son souhait (choix), même si l'affectation n'est pas précisée.

3. La suppression d'un stage entraîne celle de l'association de l'étudiant qui le réalise et le ou les souhaits impliquant ce stage.

4. La suppression d'un étudiant implique celle de ses souhaits de stage mais pas l'affectation et ni le stage lui-même.

Etudiant [noStage] StageSouhaite [noStage] => FK


Table des associations en relationnelle

Create table Stage (noStage int, sujet varchar2(50), resp varchar2(50), Constraint pk_Stage Primary Key (noStage));

Create table Etudiant (matricule int, nom varchar2(50), noStage int,Constraint pk_Etudiant Primary Key (matricule),Constraint fk1_Stage Foreign Key (noStage) References Stage(noStage) On

Delete Set Null);

Create table StageSouhaite (noStage int, matricule int, dateDepot Date,Constraint pk_Souhaite Primary key (noStage, matricule, dateDepot),Constraint fk2_Stage Foreign Key (noStage) references Stage(noStage)

On Delete Set Cascade,Constraint fk3_Etudiant Foreign Key (matricule) references Etudiant(matricule)

On Delete Cascade);


Suite

insert into Stage values (1, 'b', 'r1');insert into Stage values (2, 'c', 'r1');insert into Etudiant values (50, 'nom1', 1);insert into StageSouhaite values (1, 50, Sysdate);

Delete Stage where noStage = 1;

SQL> Select * from StageSouhaite; -- suppression par effet de cascade** aucune ligne sélectionnée

SQL> Select * from Etudiant;** 1 ligne sélectionnée


Multiplicité d'association définie avec des multiplicités bornées : 0..5

Create table Societe (nomS varchar2(50), villeS varchar2(50), Constraint pk_Societe Primary Key (nomS));

Create table Stage (noStage int not null check (noStage <9999), lieu varchar2(50), duree int not null Check( duree >15 and duree < 90), nomS varchar2(50),Constraint pk_Stage1 Primary key (noStage), Constraint fk_Societe Foreign Key (nomS) References Societe(nomS) On Delete Cascade);

Une société peut avoir jusqu'à 5 stages; elle peut momentanément en avoir aucun.

StagenoStage*lieuduree

SocietenomS*villeS

0..5 1< Heberge


Vérification de la multiplicité: limite de 5 stages

La multiplicité de 0..5 vérifiée par un trigger associé à Stage.

Create or replace trigger CheckMaxStage Before Insert On Stage For Each RowDeclare nb number(2);max_err Exception;Begin

Select Count(*) + 1 into nb From Stage Where nomS = :new.nomS;IF nb Not Between 1 and 5 Then raise max_err;End If ExceptionWhen max_err Then Raise_Application_error (-20010, ‘aura plus de 5 stages après

ajout');End;/

insert into stage1 values (6,null, 25, 'DMR') -- trigger ON si c'est le 6e stage proposé par DMR.


Contrainte de contingence (ou conditionnelle) et la note UML

L'autorisation du vol est exigée que si l'avion est du genre passager.Comment traduire en UML cette contrainte de contingence qui n'est pas valablepour tous les vols, mais seulement pour certains?

- En utilisant une note UML

Cette contrainte de contingence ne peut pas être formulée par un Check() d'attribut ou une contrainte de table , mais plutôt par un trigger.

VolnoV* : intautorisationVdestinationV

AvionnoA* :intgenreAcapaciteA

10..* EffectuerPar >

Une autorisation de vol est

exigée si l'avion est du genre

passager.


Trigger pour valider la contrainte de contingence

Avion (noA*, genreA, capaciteA) Vol (noV*, autorisationV, destinationV, noA)

Create Table Avion (noA int, genreA int, capaciteA int,Constraint pk_Avion Primary key (noA));

Create Table Vol (noV int , autorisationV int, destination varchar2(50), noA int, Constraint pk_Vol Primary Key (noV),Constraint fk_Avion Foreign key(noA) References Avion(noA));

insert into Avion values (100, 1, 500); -- genreA = 1 => genre passagerinsert into Vol values (50, 0, null, 100);


Suite… contrainte de contingence

A toute insertion d'un vol, il faut vérifier l’autorisation si l'avion est du genre passager.

Create or Replace trigger avionPass Before INSERT On Vol For each rowDeclare

genre int; --1 pour avion de passagersBegin

Select genreA into genre From AvionWhere noA = :NEW.noA ;If genre = 1 And :New.autorisationV = 0 Then Raise_Application_Error( -20001, 'autorisation requise pour un avion de passagers') ;End If;

End;/


1 couple logiciel-département peut être associé à 1..* serveurs.1 couple serveur-département peut être associé à 0..* logiciels.1 couple logiciel-serveur peut être associé à 0..* départementsCas particulier: Contrainte d’Unicité avec UML (pour avoir une CIF de E/A).

UML : Association n-aire et instances de la ternaire avaec 2 contraintes (*..*)

Departement:codeDep* : int

nomDep

budget

Serveur:nomServ*: string

typeServ

Installation:dateInstal

Logiciel:nomLogiciel*: string

Editeur: string

1..*0..*

0..*

Classe association

3 instances de la ternaire

1..1

Les objets reliés par un traitTerminé à chaque extrémité par unpetit cercle noir appartiennent à la même instance de l’association ternaire.


Association ternaire valide sur la base des dépendances fonctionnelles (DF)

Une association ternaire est valide si les DF ci-dessous ne sont pas validées:

codeDep, nomLogiciel -/-> nomServnomLogiciel, codeDep -/-> nomServnomServ, nomLogiciel -/-> codeDepetcodeDep -/-> nomLogiciel nomLogiciel -/-> codeDepcodeDep -/-> nomServ nomLogiciel -/-> nomServnomServ -/-> nomLogicielnomServ -/-> codeDep

Sinon, c'est une fausse ternaire qui pourrait être représentée par deux associationsbinaires.

** L’interprétation d’une ternaire est difficile et justifie facilement son abandon


UML et Contrainte d'unicité (U): cas particulier d'une association ternaire avec *

DepartementcodeDep*:

nomDep

budget

ServeurnomServ:

typeServ

InstallationdateInstal

LogicielnomLogiciel:

editeur

0..***

• Contraindre un logiciel d'un département à être installé sur un seul serveur: (s1, l1,d1) et non (s2, l1, d1) ?

• Combien de serveurs associés à 1 couple Departement-Logiciel ? 1 seul par la contrainte U qui contraint la multiplicité 0..* à se comporter comme 1..1

Contrainte U_DLS

Comment contraindre la ternaire pour qu'un logiciel d'un département soit installé que sur un seul serveur (cas particulier du 0..* ?

Le U étant un cas particulier du 0..*


Schéma relationnel de la ternaire avec la contrainte Unique

La contrainte d'unicité UML est définie sur la classe d'association de la ternaire.

Classe d'association:

Create Table Installation (codeDep int, nomLogiciel varchar2(50), nomServ varchar2(50), dateInstal Date, Constraint pk_Installation Primary key (codeDep, nomLogiciel, nomServ),Constraint U_DLS Unique(codeDep, nomLogiciel));

NB : La contrainte d'unicité du modèle pourrait être levée sans changer les multiplicités, seulement en supprimant le U_DLS.

La contrainte U_DLS implémente ainsi la clé candidate


E/A: Association n-aire Merise avec contrainte CIF En E/A sans CIF: 1 serveur peut faire tourner plusieurs couples <logiciel, departement>• Comment contraindre l'installation d'un <l1, d1> sur un seul serveur s1? Par une CIF.

Par la contrainte CIF : (s1, l1,d1) et non (s2, l1,d1) ou l’inverse

Sans CIF avec

s1 l1 d1 ok

s1 l1 d2 ok ok

s1 l2 d1

s1 l2 d2

s2 l1 d1 ok x

Par la CIF : nomLogiciel, codeDepnomServ

DepartementcodeDep*

nomDep

budget

ServeurnomServ*

typeServ


editeur

0,n0,n

0,n

Installation

dateInstal

E/A


En UML: Association n-aire avec une DF inter-classe ( Ξ CIF)

• Un couple Logiciel, Departement est installé sur * serveurs• Comment contraindre avec UML l'installation d'un (L,D) sur un seul serveur s1? Par

Par la DF ci-dessus : (s1, l1,d1) et non (s2, l1,d1)

Sans DF avec

s1 l1 d1

s1 l1 d2

s1 l2 d1

s1 l2 d2

s2 l1 d1 x

nomLogiciel, codeDep nomServ

À modifier pour 1..1

DepartementcodeDep*:

nomDep

budget

ServeurnomServ*:

typeServ

LogicielnomLogiciel*:

editeur

**

*

Installation

dateInstal


4 instances de l'association ternaire Installer: *-*-*

1

2

3

departement

logiciel serveur1 instance de la ternaire

*

*

*l1

s3s2

s1

d2

d1

l2

-- De par l'instance ternaire 1: l1 du d1 installé sur le serveur s1.- De par l'instance 2: l1 du d1 est aussi installé sur s2 .

- s1 fait tourner le logiciel l1 de d1 et l2 de d2.

d3 Accéder à une instance de la ternaire peut fournir dans un seul accès, 3 instances des classes participantes respectives.

4

l4

S1 est associé à 2 logiciels via 2 instances (1 et 2) de la ternaire


UML: Contrainte Unicité implicite avec la multiplicité 1

• Un couple (Logiciel, Departement) est obligatoirement installé sur 1 serveur• Comment contraindre avec UML l'installation d'un (L,D) sur un seul serveur s1 Sans utiliser l'unicité? Par la multiplicité 1 du côté Serveur.

Par la DF ci-dessus : (s1, l1,d1) et non (s2, l1,d1)

nomLogiciel, codeDepnomServdans table Installer

DepartementcodeDep*

nomDep

budget

ServeurnomServ*

typeServ


editeur

1*

*

Installation

dateInstal


Modèle relationnel avec l'association n-aire

MR: Departement (codeDep*, nomDep, budget)Logiciel (nomLogiciel*, editeur)Serveur (nomServ*, typeServ) <= insert intoInstallation(codeDep*, nomLogiciel*, nomServ*, dateInstal) <=

Contraintes du MR:1. Ajout possible d'un logiciel ou d'un département sans contrainte; sans avoir une

installation associée; (table parent)2. Ajout d'un serveur ssi aussi associé à une installation; (validation par trigger)3. Suppression d'un logiciel, département ou d'un serveur entraîne celle de tous les

tuples dans Installer qui y référent; (ON DELETE action référentielle )


Création du schéma relationnel avec contrainte reportée

Create table Departement (codeDep Number (2) not null, nomDep varchar(40) null, budget number (6,2) null, Constraint pk_Departement Primary Key (codeDep) Deferrable);

Create table Logiciel (nomLogiciel varchar(40) not null,Editeur varchar(40) null,Constraint pk_Logiciel Primary Key (nomLogiciel) Deferrable);

Create table Serveur (nomServ varchar(40) not null, typeServ char(1),Constraint pk_Serveur Primary Key (nomServ) Deferrable);


(Suite) Création du schéma avec clé primaire composée

Create table Installation(codeDep Number (4) not null,nomLogiciel varchar(40) not null,nomServ varchar(5) not null,dateInstal Date not null,Constraint pk_Installation Primary Key (codeDep, nomLogiciel, nomServ),Constraint fk_Serveur Foreign Key (nomServ) References Serveur(nomServ)

On Delete Cascade Deferrable,Constraint fk_Logiciel Foreign Key (nomLogiciel) References

Logiciel(nomLogiciel) On Delete Cascade Deferrable,Constraint fk_Dep Foreign Key (codeDep) References

Departement(codeDep) On Delete Cascade Deferrable,[Constraint U_DL Unique (nomL, codeDep) Deferrable]);

-- Un trigger remplace la contrainte Unique U_DL


Valider que 1 seul serveur associé à 1 couple de (logiciel,département) au moyen d'une procédure

CREATE OR REPLACE Procedure DSLI(nomL in Varchar, editeurL in varchar, codeD innumber,nomD in varchar,budgetD in number,nomSV in varchar, typeS IN char,DateIin Date,rep Out int) as

nbDSL number(2); nbs number(2);beginSelect count(*) into nbDSL from Installer WHERE nomLogiciel=nomL and

codeDep=codeD;if nbDSL=0 then

beginInsert into Logiciel values(nomL,editeurL);Insert into Departement values(codeD,nomD,budgetD);Insert into Serveur values(nomSV,typeS);Insert into Installer values(CodeD,nomL,nomSV,dateI);Rep:=1; --la multiplicité est valide après les ajouts

end;else rep:=0;end if;

end;

Difficile de valider cette contrainte par trigger qui ne peut pas être différé. Uneprocédure peut être appropriée. Ajout dans Logiciel, Departement et Serveur parl'usage OBLIGATOIRE d'une procédure DSLI.


Suite … Appel de la procédure transactionnelle DSLI

…variable v_rep number;set constraints All deferred; __ pendant la transactionCALL DSLI('L4','E1',1,'D1',1500.00,'S1','1',SYSDATE,:v_rep);Commit; -- marque la fin de la trasaction


Trigger pour valider l'association d'un seul couple logiciel et département avec un seul serveur (solution non opérationnelle car il y a mutating table)

Create or replace trigger DLSurUnServeur After Insert on InstallationDeclarev_nbLD Number(2); -- nombre de logiciel-départBegin

Select count(*) into v_nbLDFrom InstallationWhere nomLogiciel = varGlobale.v_nomL and

codeDep = varGlobale.v_codeD;If v_nbLD != 1 thenRaise_Application_Error(-20010, ' logiciel pas associé à 1 seul serveur ');End if;End;

*** SOLUTION :Les variables globales sont créées avec un package….

Il y a ajout d'un logiciel appartenant à un département; vérification qu'il soit associé à un seul serveur après ajout dans Installer.


Création des variables globales : initialisation avec ajout dans Logiciel et Departementpour le trigger DLSurUnServeur

/* Création des variables globales */Create or replace package varGlobale as v_nomL varchar(40);v_codeD number(2);v_nomS varchar(40);End;

/* initialisation des variables globales */Create or replace trigger initvarGlobaleServeur BEFORE INSERT On Logiciel for each

rowBeginvarGlobale.v_nomL := :new.nomLogiciel;ExceptionWhen NO_DATA_FOUND THENRaise_Application_Error (-20050, 'pas de logiciel');End;

Idem avec Departement…


(Suite) Ajout d'un serveur et validation de son association obligatoire à InstallerCreate or replace trigger initvarGlobaleDep BEFORE INSERT On Departement for

each rowBeginvarGlobale.v_codeD := :new.codeDep;ExceptionWhen NO_DATA_FOUND THEN

Raise_Application_Error (-20050, 'pas de dep');End;

Create or replace trigger initvarGlobaleServeur BEFORE INSERT On Serveur for each rowBeginvarGlobale.v_nomS := :new.nomServ;ExceptionWhen NO_DATA_FOUND THENRaise_Application_Error (-20050, 'pas de serveur');End;


Un logiciel l1 acheté par le département d1 ne doit être installé que sur un seul serveur, s2.

DepartementcodeDep*

nomDep

budget

ServeurnomServ : varchar

typeServ

InstallationdateInstal


editeur

1*

*

*

UML: Tranformation d’une ternaire en 2 bin + 1 CA

1 installation (pour chaque couple (Dep-Log)) par serveur distinct.

1


1 poste de travail EstClient d'un seul autre poste (obligatoire) qui agit comme serveur;

1 poste de travail EstServeur de 0 à plusieurs postes de travail client

UML: Association réflexive 1-* et *-*

Machine:noM*: int

adrIP

systExp

EstClient >

EstServeur >

0..*

1

Cours:titre*: string

nbCred

responsable

APrerequis >

EstPrerequis >

0..*

0..*


Ajout d'une machine client qui doit être associée à une machine serveur.Ajout d'une machine serveur à laquelle zéro ou plusieurs clients sont liés.Suppression: si la machine est un serveur, les clients sont alors supprimés;Si la machine supprimée est un client, la suppression est sans impact.

UML: Contraintes de l'association réflexive

MachinenoServ*

adrIP

sysExp

EstClient >

EstServeur >

0..*

1

CoursTitre*

nbCred

responsable

APrerequis >

EstPrerequis >

0..*

0..*


Transformation de la réflexive par spécialisation

<<Machine>>noM* : int

adrIP : varchar

sysExp

< EstClientDe 0..*1Serveur Client

c, d

La classe UML devient abstraite par la spécialisation


Contraintes ENTRE les associationsrenforcées avec la technologie relationnelle


1. Partition (P) : Chaque objet d'une classe DOIT participer à l'une des deux associations ci-dessous. Un contrat donné intervient soit avec une personne, soit avec une société, mais pas avec les deux simultanément et cela, conformément aux multiplicités des associations.

UML: Contrainte ENTRE deux associations : partition, exclusion et totalité

ContratnoC*

montantC

classeCSociete

noS*

nomS

catS

PersonnenasP*

nomP0..1

0..1

1..*

1..*

{Partition}

Signer >

Autoriser >La seule multiplicité 0..1 n'exclut pas qu'un contratait une association ni avec Personne ni avec Societe.


Exemple de la contrainte de partition : niveau des instances

Personne

Societe

ContratTotal des contrats = total des deux associations


Schéma relationnel avec la contrainte de partition

- Create table Personne( nasP int, nomP varchar2(50));- Create table Societe( noS int, nomS varchar2(50), catS int);

La présence d'une valeur pour nasP signifie qu'une personne autorisée a signé.

- Create table Contrat ( noC int, montantC number (10,2), catC char(1),nasP int Null, noS int Null,

Constraint pk_Contrat Primary Key (noC), Constraint fk1_Personne Foreign Key (nasP) References Personne(nasP) On

Delete Cascade,Constraint fk2_Personne Foreign Key (noS) References Societe(noS) On DeleteCascade);

*** La contrainte de partition est renforcée par le trigger PersonneOrSociete.


Suite … trigger pour le renforcement de la partition entre 2 associations

Create or Replace Trigger PersonneOrSociete Before Insert or Update On ContratFor each Row

Declare DeuxSignatures Exception;AucuneSignature ExceptionBeginIf :New.nasP Is not null And :New.noS Is Not Null Then

Raise DeuxSignatures;ElseIF :New.nasP Is Null And :New.noS IS Null Then Raise AucuneSignature;End If;ExceptionWhen DeuxSignatures Then Raise_Application_Error ('-20200', 'Un contrat doit

avoir une seule signature de par la partition');When AucuneSignature Then Raise_Application_Error ('-20200', 'Un contrat doit

avoir une seule signature');End;/


UML : Contrainte d'exclusion entre deux associations

Chaque objet d'une classe (Contrat) PEUT participer à l'une des deux associations seulement. Il peut y avoir un contrat avec une signature ou une autorisation corporative. Ou un contrat sans aucune signature de personne ou de société. Notation UML

ContratnoC*

montantC

classeCSociete

noS*

nomS

catS

PersonnenasP*

nomP0..1

0..1

1..*

1..*

{Exclusion}

Signer >

Autoriser >

La seule multiplicité 0..1 permet qu'un contratait une association ni avec Personne ni avec Societe.


Exemple d'exclusion : niveau des instances

Total des contrats != total des deux associations

personne 2

societe 1

Contrat 1


Tout contrat participe AU MOINS à une association: tout contrat doit être signé parune personne autorisée et éventuellement par une société.

UML: Contrainte de Totalité (T) entre 2 associations

Tout contrat doit participer au moins à une association émergeant de la classe.

ContratnoC*

montantC

classeCSociete

noS*

nomS

catS

PersonnenasP*

nomP0..1

0..1

1..*

1..*

{Totalité}

Signer >

Autoriser >


Exemple de totalité : niveau des instances

Total des contrats <= total des deux associations

personne 2

societe 1

Contrat 1


Si un étudiant effectue un stage alors ce stage était parmi ceux demandésexplicitement.

UML : Contrainte d'inclusion entre 2 associations {SE}

Etudiantmatricule*

nom

ville

programme

StagenoS*

sujetS

responsableS

0..1

1..*

0..*

0..*

Effectuer>

Demande >

{Sous-ensemble}

Toutes les occurrences (instances) d'une association doivent être incluses dans les occurrences d'une autre association.

Stage (noS, sujetS, responsableS)Etudiant (matricule, nom, ville, programme, noSE) -- stage effectué Demande (matricule, noSD) --stage demandé par un étudiant


Contrainte d'inclusion et le MR

Create Table Stage (noS int, sujetS varchar2(50), responsableS varchar2(50),Constraint pk_Stage Primary Key(noS));

Create Table Etudiant (matricule int, nom varchar2(50),ville varchar2(50), programme varchar2(50),noS int Null,Constraint pk_Etudiant Primary Key (matricule),Constraint fk1_Stage Foreign key (noSE) References Stage(noS));

Create Table Demande (matricule int Not null, noS int Not null,Constraint pk_EtSt Primary Key (matricule, noS),Constraint fk_Stage Foreign key (noSD) References Stage(noS));


Contrainte d'inclusion renforcée par triggerAjout de l'association pour concrétiser la réalisation d'un stage par un Update del'étudiant déjà dans la base.

Create or Replace trigger InclusionSEdansSD After Update Or Insert OF noSE On Etudiant For each Row

DeclarenbStageD int;stageNonDemande exception;BeginIF :new.noSE is NOT null Then Begin

Select Count(*) into nbStageD From DemandeWhere noSD = :New.noSE;If nbStageD = 0 Then Raise StageNonDemande;End IF; End;

ExceptionWhen StageNonDemande Then Raise_Application_Error(-20500, 'Le stage est non

demandé');End;/


Exemple du fonctionnement

Insert into Stage values ( 1,'analyse', 'Paul');

Insertion d'un étudiant sans choix de stage:Insert into Etudiant5 values ( 100, 'Hélène', 'Québec', 'IFT', null );

Insert into EtSt values (100, 1);

Update Etudiant5 set noSE = 1 Where matricule = 100;

Update Etudiant5 set noSE = 2 Where matricule = 100;ERROR at line 1:ORA-06512: à "ANGAM.INCLUSIONSEDANSSD", ligne 10ORA-04088: erreur lors d'exécution du déclencheur

'ANGAM.INCLUSIONSEDANSSD'


La contrainte d'inclusion entre trois associations binaires se traduit par une note qui porte sur la classe Logiciel.

Si le d1 achète le l1 et si le d1 utilise le serveur s1, alors l1 doit être sur le serveur, s1 (si la contrainte I est formulée).

UML : Contrainte d'inclusion entre 3 associations binaires Inclusion : le logiciel doit être installé sur un serveur utilisé par le département qui a acheté le logiciel.

Installation

DepartementcodeDep*

nomDep

budgetDep

ServeurnomServ*

typeServ

AchatdateAchat


editeur

1..*0..*

1..*

1..*

1..*

0..*

Utilisation


UML : Association directionnelle

Une association peut être directionnelle pour indiquer (de manière facultative) le sens privilégié du parcours par navigation; (sans exclure l'autre sens cependant);

VisitedateVisite* Secteur

nomSect*

region

ResultatnoRapport*

RepresentantnomRep* varchar

ageRep : int

1*

*

*


L'agrégation est une forme particulière de l'association; elle renforce le couplage entre les classes concernées.

Elle est en premier une association caractérisée par les multiplicités auxquelles se superpose une contrainte de suppression.

Deux formes d'agrégation :• La composition (stricte ou agrégation forte) requiert qu'un objet appartienne au

plus à 1 composition d'objet à un instant donné. (la destruction du composé entraîne la destruction des composants). (Symbole: losange noir)

• L'agrégation partagée (faible) autorise qu'un objet appartienne simultanément a plusieurs compositions d'objets (losange vide) ou si la multiplicité le permet à plusieurs objets de l'agrégé.

UML : Agrégation (association d'agrégation))


L'agrégation de A pour composer B est une association forte : utilisée à chaque fois quel'accès à un objet B présume l'accès obligatoire et incontournable à une instance de A.

Agrégation versus association

Cas 1 : L'agrégation forte (composition) représente le fait que A est une partie de B. Accès à B présume celui à A. Durée de vie De A : si une instance de B est supprimée, la ou les instances de A agrégées le sont aussi. B peut être créé sans créer A immédiatement. B a un attribut qui est une ou plusieurs instances de A. La multiplicité du côté de l'agrégé est (1..1) ou (0..1).

Cas 2 : L'association entre A et B ne présume pas que l'accès à B sera suivi d'un accès à A(point fort de cette abstraction). La suppression de B n’entraîne toujours celle de A. Cela dépend de la multiplicité de B.

B

A

B

A1..* 1..*

1 0..1Cas 2Cas 1

AB

AssociationAgrégation


L'agrégation de composition ne s'impose que lorsque l'association entre objets est du genre «composé/composant» ou «fait partie de»;

Un objet a un attribut dont la valeur est une instance d'une autre classe (par agrégationde couplage fort). Il peut y avoir une opération sur Ordinateur qui peut aussi s'appliquer àl'écran.

Ecrantaille

PeripheriquetypeP

Disquecapacite

marque

OrdinateurnoSerie*: int

prix

0..*1..*1

UML : Agrégation de composition

Suppression d'un ordiImplique la suppression de l'écran,des disques, et de ses périphériques de la base.

Ajout d'un ordi suppose la création d'un Écran, d'un disque et pas nécessairement unpériphérique

1..1


Caractéristiques de l'agrégation forte dite aussi de composition1. La suppression du composé entraîne celle des composants.

2. Les attributs du composé sont acccessibles et utilisés par l'interface (les méthodes) des composants.

3. Les composants peuvent être des instances du composé (réflexivité).

4. Un objet composant ne peut pas être en association avec d'autres classes que celle du composé.

Est-ce que cette agrégation forte est justifiée dans la gestion de la relation avec lesclients par un centre de commerce?

Boutique

nomB*total_Inv

Personne

nomP* coteCr

GereLaRelationClient >

AugInv() ModifCote()


Modélisation inadéquate avec l'agrégation forte?1. La suppression du composé entraîne celle des composants. La fermeture d'une boutique ne

supprime pas la personne (qui est un client) et sa cote personnelle de crédit !

2. Les attributs du composé sont utilisés par l'interface des composants. L'objet Personne a une interface qui peut avoir accès aux attributs de Boutique.

3. Les composants peuvent être des instances du composé (réflexivité). Non

4. Un objet composant ne peut pas être en association avec d'autres classes que celle du composé. Faux. Une personne cliente d’une boutique peut aussi l’être avec une autre boutique située dans le même centre d’affaires.

Alors, est-ce que cette agrégation forte est justifiée?

Boutique

nomB*total_Inv

Personne

nomP* coteCr

GereLaRelationClient >

Aug_Inv() ModifCote()0..*


Les objets du type CoPropriétaire peuvent exister sans un Comité-Immeuble; voire même êtrepartagés comme co-propriétaire participant à d’autres comités-immeubles ou commecopropriétaires d’objets d'une autre association de co-propriété ( ex. copropriété d’un camion).En raison de la multiplicité 1..*, l'ajout d'un comité-Immeuble suppose qu'il soit rattachéimmédiatement à 1 ou * co-propriétaires.

Une procédure cataloguée Ajout_Immeuble(noI int, adresse varchar, q int) pourrait ajouter un immeuble et le rattacher à une instance de coPropriétaire.

Caractéristique essentielle de l'agrégation partagée (En suppression):La suppression d'un immeuble n'entraîne pas obligatoirement celle d'un co-propriétaire car cedernier peut participer à un comité-immeuble d’autre immeuble. La multiplicité mimimum del'agrégation faible est donc 0 du côté du losange.

Agrégation partagée (losange vide = agrégation faible)

CoProprietairenas* : string

adresse : string

Comité-ImmeublenoIm* : string

adresseIm : string

quartierIm : string

0..*1..*Gère >


Implantation relationnelle d'une agrégation faible

Create Table CoProprietaire (nas char(9), adresse varchar(15),Constraint pk_CoProprietaire Primary key (nas));

Create Table Comite-Immeuble (noIm int, adresseIm varchar2(50), quartierIm int,Constraint pk_Immeuble Primary Key (noIm));

La multiplicité 1..* - 0..* est rendue par une nouvelle table (dite d'association) :Gere qui peut avoir éventuellement ses propres attributs. La suppression d'uncomité-immeuble ou d'un copropriétaire doit entraîner celle des lignes de Gere.

Create Table Gere (nas char(9), noIm int,Constraint pk_Gestion Primary Key (nas, noIm),Constraint fk1_GestionCoProprietaire Foreign Key (nas) References CoProprietaire

(nas) On Delete Cascade,Constraint fk2_GestionCoProprietaire Foreign Key (noIm) References Comite-

Immeuble(noIm) On Delete Cascade);

-- en cas de suppression d’un comité-immeuble, le propriétaire reste dans la base.-- en cas de suppression d’un co-propriétaire, l’immeuble reste dans la base.


Exemple d'agrégation partagée (losange vide = agrégation faible)

Segment commun

P57

P23

Les points du segment commun sont partagésentre 2 polygones

La suppression d'un polygone adjacent n'entraîne pas celle des points partagés avec unautre polygone.

(1) Pour simplifier, les coordonnées sont un entier formé par juxtaposition des coordonneés

PolygonenoP* : string

couleur : int

PointPolygonexy* : int (1)

origineX0Y0: int

couleurPoint : int

100...*6..*

FormeDe >

P15


Autre exemple d'agrégation : cohabitation forte et faible Universite

nomU* :string

FacultenomF* :str

Institut nomI* : str

Service noServ* :int

BatimentnomB* :str

DepartementnomD* : string Salle

noS* : string

Dans > 1..*0..1

OffreD

es >

0..1

*

1

1..20

Comprend >

L'association entre Salle et Bâtiment est du type agrégation de composition :L'ajout d'un bâtiment implique l'ajout de salles (max20). L'ajout d'une sallene peut se faire sans la création préalable d'un bâtiment.

1

1..* 1..*0..*

L'agrégation faible Comprend sous-tend que lors de la création d'unefaculté, il peut y avoir création de départements. Avec la suppression d'unefaculté, les départements qui sont financés par un organisme seront laissésdans la base et les autres supprimés.

Les salles sont dans labase et existent que dansle contexte de la classeBatiment.

Organisation nomO* : string 0..* 1..*

Finance >


Autre exemple : agrégation faible

1. Un contrat est amendé par des avis de modification au contrat.

2. Périodiquement, les avis sont revus et refondus pour composer un avenant qui est intégré au contrat.

1. La suppression d'un avenant n'entraîne pas celle des avis de modification au contrat si celles-ci ont modifié le contrat. (Agrégation faible)

2. La classe SectionRefondue comprend un attribut de l'instance qui est éventuellement partagée avec l'association Modifie.

3. La refonte est effectuée périodiquement après que plusieurs avis de modification aient été faites aux contrats.

AvisModifContrat

noAvis * : int

Texte : varchar

Contrat noC* : int

1

*

Modifie >SectionRefondue

noAvenant: int

*

0..1

1

Refonte >

Integre >*


E/A : Exerccie de modélisation de l'Entité faible en E/A

Pavillon:

noP* : int

nomP : string

respP : string

Salle:

noS : int (d)

capaciteS : int

Appartient

0,n

1,1

Chaque salle a un no unique au sein d'un même pavillon seulement.

Pour distinguer une salle d'une autre, il faut aussi connaître le no du pavillon. Il y a une dépendance fonctionnelle inter-relation: de Salle sur le Pavillon.

Modélisez en UML l'association faible de E/A

discriminant

Les instances de salle sont distinctes que pour un même pavillon.

d: discriminant


Version UML : Modélisation de l'Entité Faible

Dans chaque pavillon, un noS identifie une salle de cours.

Pavillon:

noP* :int

nomP: string

respP : string

Salle:

(noS)

capaciteS : int

1

noS

Qualificatif(discriminant)

DF interclasse :noP, noS -> capaciteS

Implantation relationelle:Pavillon(noP*, nomP, respP)Salle (noS*, noP*, capacite)

Dépendance de l'existence d'une instance sur celle d'une autre : Salle dépend de Pavillon


Permet d'organiser les classes en les ordonnant en hiérarchie (arborescence) d'abstraction croissante (bottom up) évitant ainsi la duplication de attributs et de méthodes (concentration et partage du code);

Héritage des attributs et des méthodes (ou opérations) en tenant compte de leur visibilité;

Toute modification à un attribut ou à une méthode se propage par l'héritage vers les sous-classes sauf s'il y a redéfinition dans les sous-classes.

Héritage dans le diagramme de classe UML


Exemple d'héritage avec une Gen/Spec

Autre écriture

ChercheurnomLabo : varchar

nbArticles: int

annee: Date

moyennePub(an)

EnseignantnoCours : int listerCours()

calculSalE(nbH)

Personnelnas* : int

nom : string

adresse : string

tauxHoraire : realcalculSal(p1)

Opérations


UML : Héritage multiple avec conflit de nom

Employematricule* : intadrProf : string

Etudiantmatricule* : intnom : stringadrLocale : string

{c, d}

1erCycle

progr :int

2eCycle

dirRech : string

{i, o}

Professeur

specialite : string

Moniteur

noLabo : int

Héritage multiple

Dans Moniteur : Employe.matricule et Etudiant.matricule sont 2 attributs différents.On peut imaginer (!!!) qu'un individu a un matricule comme étudiant et un autre comme employé. C'est en quelque sorte le partage de classe par 2 hiérarchies distinctes par leur racine.


UML: Héritage - spécialisation

ServeurnomServ: varchar

disque : varchar

ClientadrIP : varchar

masque : varchar

PosteTravailnoSerie* : int

typePoste : varchar

- Les attributs de Poste sont l’objet d’un héritage par chaque sous-classe.- La clé primaire de chaque sous-classe est fournie par héritage.- La ligne horizontale indique les propriétés de la spécialisation

{c, d}


A- Tous des postes soit client, soit serveur mais pas les deux {c, d};

B- Certains postes clients sont des postes serveurs ou des postes isolés et d’autres ne sont ni clients ni serveurs { i, d};

C- Tous des postes clients, des postes serveurs et des postes qui sont à la fois clients et serveurs {c, o};

D- Une partie des postes clients, sont des postes serveurs, d’autres sont des postes qui sont à la fois clients et serveurs et des postes isolés {i, o} .

Propiétés de la spécialisation (héritage)


Spécialisation (c,d)


L'union des postes clients et des serveurs constitue le parc informatique modélisé par ce diagrammeLa classe Poste est abstraite donc non instanciée.

UML: Héritage- spécialisation {c, d}

En OR: La classe Poste n'est pas instanciable (NOT INSTANTIABLE) et est sourced'héritage (NOT FINAL). Elle est utile pour l'héritage des attributs et des méthodes.


disque: varchar


masque : varchar

<<Poste>>noSerie* : inttypePoste : varcharmodifTypeP()

{complete, disjoint}


Avec une implantation relationnelle push-down ou descendante (c,d) de la spécialisation

Le passage push-down pour obtenir le MR :• Client (noSerie*, typePoste, adrIP, masque)• Serveur(noSerie*, typePoste, nomServ, disque)

c: ∀ poste est client ou serveur d: ∄ poste à la fois client et serveur

Create table Client (noSerie int not null,typePoste varchar(3) Check ( typePoste in ('NT', 'WIN', 'LX')),adrIP varchar(11), masque char(11),Constraint pk_Client Primary Key (noSerie));

Create table Serveur (noSerie int not null,typePoste varchar(3) Check ( typePoste in ('NT', 'WIN', 'LX')),nomServ varchar(11), disque char(11),Constraint pk_Serveur Primary Key (noSerie));


Implémentations relationnelles de la spécialisation (c,d)


Validation de la contrainte disjoint de la spécialisation avec 2 tables

d: Un poste peut être client et non un serveur et inversement.

La contrainte d est validée par un trigger sur serveur et un autre sur client

-- trigger sur ServeurCreate or Replace trigger excluServeur Before Insert Or Update of noSerie On

Serveur For each RowDeclare nb number;BeginSelect noSerie Into nb From Client Where noSerie = :New.noSerie;If nb != 0 Then Raise_Application_Error (-20040, 'le poste est déjà client');Else NULL;End If;End;/


Suite… 2e trigger pour valider la contrainte disjoint entre les tables

-- trigger 2 sur ClientCreate or Replace trigger excluClient Before Insert Or Update of noSerie On ClientFor each Row When (new.client is not null)Declare nb number;BeginSelect noSerie Into nb From Serveur Where noSerie = :New.noSerie;If nb != 0 Then Raise_Application_Error (-20040, 'le client est déjà serveur');Else NULL;End If;End;/

Si un trigger lance le package Raise_Application_Error(), l'insertion en cause estdéfaite.


Validation de la contrainte complete de la spécialisation avc 2 tables

Pour la contrainte c: ∀ poste est client ou serveur

Aucune table créée pour Poste car <<abstraite>>

Toute insertion est donc faite dans Client ou Serveur et aucune dans Poste quin'est pas instanciable.

En OR: la notion de NOT INSTANTIABLE sera mise en œuvre pour le type Poste.


Iplémentation de la hiérarchie par puch-up des sous-classes

• Client (noSerie*, adrIP, masque, typePoste)• Serveur(noSerie*, typePoste, nomServ, disque)

Le passage au MR par push-up donne une seule relation:

PosteCS (noSerie*, adrIP, masque, typePoste, nomServ, disque)

Les contraintes de cette relatio sont alors:

c: ∀ posteCS est client ou serveur d: ∄ posteCS ni client et ni serveur


Implémentation push-up avec 1 table {c,d} pour un schéma relationnel

Create table PosteCS ( noSerie int not null,typePoste varchar(3) Check ( typePoste in ('NT', 'WIN', 'LX'), adrIP varchar(11), masque char(11) ,nomServ varchar(11), disque char(11),Constraint pk_Client Primary Key (noSerie));

Validation des contraintes par l'ajout d’une contrainte complexe de table:

Constraint c1_disjoint Check( (adrIP is Null and masque is Null) OR (nomServ is Null and disque is Null));

-- client ou serveur (c)

Constraint c2_disjoint Check((adrIP is not Null OR masque is not Null) OR (nomServ is not Null OR disque is

not Null)); -- ni client ni serveur (d)

Les deux contraintes doivent être vérifiées (AND sous-entendu) pour qu’un tuple soit validé.


Filtre par des contraintes de table (PosteCS)Attendu Résultat

C1 and C2C1 C2 adrIP masque nomServ disque

T T T T √ √ o o

T T T T o √ o o

T T T T √ o o o

T T T T o o √ √

T T T T o o √ o

T T T T o o o √

F F T F o o o o

F F F F √ √ √ √

F F F F √ o √ O

F F F F O √ √ O

T T T T √ O O √

Constraint c1 : ( (adrIP is Null and masque is Null) OR (nomServ is Null and disque is Null)); ANDConstraint c2: ((adrIP is not Null OR masque is not Null) OR (nomServ is not Null OR disque is not Null)); (d)


Implémentation de la hiérarchie par distinction :3 tables avec validation des contraintes (c,d)

Le MR est obtenu par distinction des postes clients et des postes serveurs décrits SEULEMENT par le noSerie et leurs attributs propres. C'est le MR dit par distinction. La classe Poste devient alors concrète.

Tables avec contrainte référentielle :• Poste (noSerie*, typePoste) -- tout poste C ou S est une instance de cette classe• Client (noSerie*, adrIP, masque)• Serveur (noSerie*, nomServ, disque)

c: ∀ poste est client ou serveur et d: ∄ poste à la fois client et serveur

Validation de la contrainte d : l'ajout d'un client déclenche le trigger 1 et l'ajout d'un serveur, déclenche le trigger 2.

Validation de la contrainte c: L'insertion d'un poste est obligatoirement suivie par une insertion dans Client ou Serveur (mais pas les deux). La suppression d'un client ou d'un serveur se répercute obligatoirement par la suppression du poste correspondant dans surclasse Poste. Contraintes implémentées par des procédures.


Schéma du MR obtenu par distinction

L'accès à tous les attributs d'un poste Client ou Serveur exige une jointure :

Create Table Poste (noSerie int,typePoste varchar(3),Constraint pk_Poste Primary Key (noSerie));

Create Table Client (noSerie int, adrIP varchar(11), masque varchar(11),,Constraint pk_Client Primary Key(noserie),Constraint fk_Poste Foreign Key (noSerie) References Poste(noSerie) On Delete Cascade);

Create Table Serveur (noSerie int, nomServeur varchar(11), disque varchar(11),Constraint pk_Serveur Primary Key(noSerie),Constraint fk_Serveur Foreign Key (noSerie) References Poste(noSerie) On Delete Cascade);

La contrainte référentielle est nécessaire dans une telle implémentation.


Suppression en cascade

Insert into Poste values(100, 1);Insert into Serveur values (100, 'S1', 2);

SQL> Delete Poste where noSerie = 100;

1 ligne supprimée ( au total 2 tuples après l’action du trigger)

La suppression d'un poste entraîne celle du serveur (ou du client) en raison de lacontrainte référentielle.


Implémentation par distinction sans contrainte référentielle avec CascadeProcédures pour SUPPRIMER un poste-client et un poste-serveur

Create Procedure supprimerPosteETClient (noS IN int) ISBegin

Delete From Client Where noSerie = noS;Delete From Poste Where noSerie = noS;

End;/Create Procédure supprimerPosteETServeur (noS IN int) ISBegin

Delete From Serveur Where noServ = noS;Delete From Poste Where noSerie = noS;

End;/

1. Call procedure supprimeETClient (noS);2. Call procedure supprimeETServeur (noS);


Implémentation par distinction sans contrainte référentielle avec Cascade Procédures pour AJOUTER un poste avec propagation sur Client ou Serveur

Create Procedure ajouterPosteETClient (noS IN int, tPoste IN varchar, adrIP IN varchar, masque varchar) IS

BeginInsert into Poste values (noS, tPoste);Insert into Client values (noS, adrIP, masque);End;

/Create Procédure ajouterPosteETServeur (noS IN int, tPoste IN varchar, nomS IN

varchar, disq IN varchar) ISBegin

Insert into Poste values (noS, tPoste);Insert into Serveur values (noS, nomS, disq);

End;/

Call procedure ajouterPosteClient (noS int, tPoste varchar, adrIP char, masque char);Call procedure ajouterPosteServeur(noS int, tPoste varchar, nomS varchar, disq char);


Suite… Trigger pour propager toute modification du noSerie d'un poste

-- Propagation de la modification faite au noSerie de Poste vers Client ou Serveur.

Create or Replace Trigger PropagnoSerie Before Update of noSerie On PosteFor eachRowBegin

BeginUpdate Client Set noSerie = :New.noSerie Where noSerie = :Old.noSerie;Exception When NO_DATA_FOUND Then NULL;

End;Update Serveur Set noSerie = :New.noSerie Where noSerie = :Old.noSerie;Exception When NO_DATA_FOUND Then NULL;

End;/ -- en cas erreur suite à l'exception qui suit


Spécialisation (i,d)


Un poste de travail peut n'être ni client, ni serveur. L'union des clients et des serveurs ne représentepas le total du parc informatique:

i: ∃ poste ni serveur, ni client d: ∄ poste à la fois client et serveur

En OR: Poste est une classe instantiable (le défaut) et NOT FINAL.

UML: Héritage {i,d}

ServeurnomServ : varchar

disque: varchar


masque: varchar

PostenoSerie* : int

typePoste: varchar

{incomplete, disjoint}


{i,d} : Modèle relationnel par distinction

Le MR est obtenu par distinction des postes-clients et des postes-serveurs par leur noSerie respectif. C'est l'approche par distinction.

• Poste (noSerie*, typePoste) -- Tout poste est une instance de cette classe• Client (noSerie*, adrIP, masque)• Serveur (noSerie*, nomServ, disque)

i: ∃ poste ni serveur, ni client d: ∄ poste à la fois client et serveur

Create table Poste (noSerie int not null,typePoste varchar(3) Check ( typePoste in ('NT', 'WIN', 'LX'),Constraint pk_Poste Primary Key (noSerie) );

Create table Client (noSerie int not null,adrIP varchar(11), masque char(11),Constraint pk_Client Primary Key (noSerie),Constraint fk1_Poste Foreign Key(noSerie) References Poste(noSerie) On Delete Cascade);


Validation des contraintes {i, d}

Create table Serveur (noSerie int not null,nomServ varchar(11), disque varchar(11),Constraint pk_Client Primary Key (noSerie),Constraint fk2_Poste Foreign Key(noSerie) References Poste(noSerie) On Delete Cascade);


Autre MR pour un spécialisation {i, d} avec push-down

i: Il peut y avoir un poste qui est ni client, ni serveur.d: Un poste est client sans être aussi serveur et inversement.

• Poste (noSerie*, typePoste) -- poste ni client, ni serveur• Client (noSerie*, typePoste, adrIP, masque)• Serveur(noSerie*, typePoste, nomServ, disque)

La contrainte d est validée par un trigger sur Serveur et un autre sur Client.i: ∃ poste ni client, ni serveur,

En ajout d'un poste, il n'y a pas de contrainte obligatoirement exécutablepuisque le poste ajouté peut être un poste non spécialisé.

L'absence de contraintes correspond à incomplete (i).


Spécialisation (c, o)


Il existe des postes de travail à la fois client et serveur. L'union des clients, des serveurs et desclients-serveurs forme la totalité du parc informatique. Poste est NOT INSTANTIABLE et NOTFINAL.

c: ∀ poste est client ou serveur o: ∃ poste à la fois client et serveur

UML: Héritage {c, o}


disque: varchar

ClientadrIP:varchar

masque: varchar

<<Poste>>noSerie* : int

typePoste: varchar

{complete, overlapping}

<<Poste>> dénote une classe abstraite


Le MR avec contraintes (c,o)

• Client (noSerie*, typePoste, adrIP, masque)• Serveur(noSerie*, typePoste, nomServ, disque)

Create table Client (noSerie int not null,adrIP varchar(11), masque char(11),Constraint pk_Client Primary Key (noSerie));

Create table Serveur (noSerie int not null,nomServ varchar(11), disque char(11),Constraint pk_Client Primary Key (noSerie));

Un même noSerie peut être à la fois dans Client et Serveur. Absence dedéclencheur sur les tables Client et Serveur.

La contrainte c : validée par absence d'instances de type Poste, classe spécifiée Abstraite.La contrainte o: absence de trigger sur Client et Serveur.


Spécialisation (i, o)


UML: Héritage {i, o}

Certains postes sont des serveurs d'imprimante! i: ∃ poste, ni serveur, ni client o: ∄ poste, à la fois client et serveur


disque: varchar


masque: varchar

PostenoSerie* : int

typePoste: varchar

{incomplete, overlapping}


Implantation relationnelle de la spécialisation (i,o)

Le MR :• Poste (noSerie*, typePoste) -- seuls les postes ni serveur ni client• Client (noSerie*, adrIP, masque)• Serveur(noSerie*, nomServ, disque)

i: ∃ poste, ni serveur, ni client o : ∄ poste, à la fois client et serveur

Les contraintes (i,o) sont larges et du ressort de l'applicatif :• Ajout d'un poste seulement dans Poste;

• Ajout dans Client ET/OU Serveur : par une procédure ajoutPosteClient() et/ou ajoutPosteServeur() selon le cas.

Sauf si l'instance comporte un attribut sorte qui indique si c'est une instance de Client ou de Serveur.


Blocage partiel de matricule; causé par sa redéfinition (pas implanté en Oracle)Blocage de ListerAdr() causé par sa redéfinition

VendeurnoRegion

matricule : Intbonus

Gerantspecialite

bonus

<<Personne>>matricule* :string

adresseListerAdr(x,y)

{c, d}

ClientServeurnomDernierCli

nomDernierServListerAdr(x,y,z)

UML: Héritage multiple bloqué par redéfinition


UML: Généralisation avec classe abstraite, obtenue de bas en haut

VendeurOcca

CalculPaieO()

VendeurPerm

CalculPaieP()

<<Personne>>nas*: string

adresse: stringListerAdr()

{c, d}

VendeurCandidnoRef: string

Une classe abstraite ne génère pas d'objets à son image dans la base, mais elle estsource d'attributs et de méthodes

Les objets des sous-classes 1 et 3 partagent la même structure d'attribut, tandis quela 2e a une structure plus riche. En sus, le vendeur candidat n'a pas de méthodepour le calcul de la paie, mais partage avec les autres la méthode ListeAdr().


UML: classe abstraite avec seulement des opérations : Interface

VendeurOcca

CalculPaieO()

VendeurPerm

CalculPaieP()

<<Affiche>>ListerAdr()

ModifAdr()

SuppAdr ()

{c, d}

VendeurCandidnoRef: string

Une classe abstraite a une interface, mais aucune implémentation.

Les objets des sous-classes partagent la même interface, tandis que la sous-classe 1et 3 ont une structure plus riche. Le vendeur candidat n'a pas de méthode pour leCalcul de la paie, mais partage avec les autres, les méthodes héritées de l'interface dela classe abstraite.


D'autres classes peuvent être ajoutées: la spécialisation {i} rend le schéma ouvert..Si (c,d) : l'ajout d'une classe suppose un moyen de filtrer les instances déjà stockées

dans Client et Serveur et de disposer des attributs non pertinents à la nouvelle classe.


disqueS : varchar

ClientadrIP: varchar

masqueC: varchar

PosteTravailnoSerie* : int

typePoste : archar

UML: Évolution du schéma rendu possible avec spécialisation {i, d}

{i,d}

Ajout et suppression de sous-classes sont possibles et facilesavec (i, d)

PareFeuadrIPpf : varchar

portPf : int

Classe ajoutée


Passage au modèle d'implantation selon la technologie disponible

Le MCD OO permet une représentation incluant :La structure et le comportement des objets.

Les modèles d'implantation : le relationnel (MR) : table, primaire, étrangère l'objet-relationnel (MOR) : cohabitation des tuples et des objets, méthodes, héritage et OID dans la même BD. l'objet pur (MO) : Classes, méthodes et héritage et OID

Le passage du MCD au MOR ou MO est fait par des règles.


Évolution du modèle (du schéma)

Rien n'est figé ! : le MCD devra donc évoluer car le design est une activité incrémentale et évolutive.

Cette évolution doit pouvoir être implémentée sans fermer le système ou mettre en péril les applications ??

Alter table ADD Attribute …. ( avec null pour les tuples déjà créés)

Modif de la classe : attribut et méthode :Personne

mat* : char(9)

nom : varchar(50)

Personne

mat* : char(9)

nom : varchar(50)

dateNaiss : Date

Ajout attribut


Évolution du modèle (schéma) (suite1)

Personne

mat* : char(9)

nom : varchar(50)

afficher()

Personne

mat*:char(9)

nom: varchar(50)

dateNaiss: Date

calculAge()

afficher()

Ajout d'une nouvelle méthode


Évolution du modèle (schéma) (suite2)

3. Création de nouvelles sous-classes (par spécialisation)

2. Modification de l'héritage : création/suppression d'une nouvelle superclasse.

?


Conventions d'écriture UML (suggestions d'écriture)

1. Évitez le croisement des liens d'association;2. Tracez les liens d'association horizontalement ou verticalement;3. Classe de multiplicité * placée en haut ou à gauche de celle de

multiplicité 1;4. Pour éviter les croisements : tracez des classes larges ou hautes et

fines;5. Limitez à 15 classes sur un même diagramme;6. Utilisez la notion de package de UML pour regrouper les15 classes

UML.7. Le modèle de la base de données est alors représenté par les

packages et des liens entre eux;


Exercices avec UML

Modélisation UML : DC pour l’activité d’affrètement d'avions

Lecture d'un DC de UML

Modélisation avec l'agrégation


1- Affrètement par Avion (AFA) (Soutou 1999)

La gérance d'un aéroport désire connaître la propriété des avions par des sociétés (SPA) et l'affrètement par des compagnies organisateurs de voyages (COV). Une compagnie, soit COV ou SPA est caractérisée par un noC et une raison sociale, le nomC. Une compagnie SPA peut posséder plusieurs avions, tandis qu'un avion n'a qu'un seul propriétaire. Chaque avion a un matricule et un constructeur . Les avions sont aussi répertoriés dans un document classés par genre et capacité. Un avion peut être affrété par un COV à différentes dates (dateV) affrètements identifiées par des numéros de vols distincts. L'avion peut être affrété plusieurs fois par jour par différents COV. Pour chaque affrètement, il faut stocker le nombre de passagers (nbP) et le coût total du vol. Chaque avion fait l’objet d’une description maintenue par l'aéroport : nomA, genreA, nbMaxPlace. Un même COV ne peut pas affréter le même avion plusieurs fois le même jour. Un affrètement est défini comme un COV qui utilise un avion pour effectuer un transport de passagers d’un aéroport à un autre. Le vol est défini par trajet un numéro, point de départ, un point d’arrivée et une date.


UML : solution pour AFA

CompagnienoC* : int

nomC : varchar

AvionmatAv* : int

genreA

nbMaxPlaceA

nomA : varchar

VolnoV*: int

dateV : Date

departV

arriveeV

0..*

0..*

1

ProprietaireDe

Organise Effectue

Utilise

AffretementnbPasscout

1

1Les DF:noVol, matAvion noCompagnienoCompagnie, matAvion -/-> noVolnoCompagnie, noVol -> noAvionmatAvion noCompagnie


Les instances possibles de la ternaire

COV

avion

vol

affretement


UML : Autre solution pour AFA avec classe-association

Compagnie

noC* : int

nomC : varchar

Avion

matAv* : int

capaciteAv :int

Vol

noV* : int

dateV: date

routeV

Affretement

nbPas : int

Cout : int

0..* *

*1

1

1

ProprietaireDe

Utilise

Affrete


Exercice de lecture d'un diagramme de classe UML

Segment:noSeg* : int

longueur

Installation:dateInstall

PosteTravail:noSerie* : intadrIPtypePoste

Logiciel:codeLogi* : intnomLogiversiondateAchattypeOSediteur

1..*

*

*Bureau:

noBureau* :int

Etage

telB

*

*

Traverse

Contient>1..*

1

1Personne:

nas* :varchartelPmetiers

1

0..1InstalleSur


Interprétation des associations du DC-UML

Traverse: 1 segment de réseau peut traverser plusieurs bureaux et un bureau peut être traversé par plusieurs segments distincts.

Contient: il peut (0..*) y avoir plusieurs postes de travail dans un bureau.

Connecte: 1 segment peut connecter plusieurs postes de travail (workstation), mais un poste de travail doit être connecté à 1 segment.

InstalleSur: 1 logiciel et 1 poste de travail font l'objet 1 installation; mais à 1 date d'installation, il peut y avoir plusieurs logiciel-poste Travail en cause.

Agrégation: 1 installation est faite par une personne et la suppression d'une installation ne supprime pas la personne. Lors de la réalisation d'une installation, cette dernière est obligatoirement associée à une personne.


Conclusion

Le DC-UML représente les objets d'analyse et des contraintes essentielles pour la cohérence de la base de données;

La création d'une BD relationnelle avec un diagramme de classe se fait avec le DDL, les triggers et au besoin, les packages;

Une BD à caractère OO est construite à partir d'un DC-UML. Une BDOR à partir du Mnav correspondant au DC-UML;

Le passage au modèle d'implantation se fait par des règles précises et en tenant compte des caractéristiques du modèle d'implantation géré par le SGBD. Le MR, MOR et le MO sont tous des modèles d'implantation différents.


Références

1. Oracle, Design Using UML object modeling by Paul DORSEY, Oracle Presse, 2002

2. UML de la collection Schaum's par Simon Bennett, Jogn Skelton et Ken Lunn, Collection Schaum's Outline, 360p., 2001.

3. Penser Objet avec UML et Java par Michel Lai, 2e édition, Dunod, 201p., 2000.

4. Data Modeling and Design: Logical Design by Toby Teorey, 5th edition, Morgan Kaufman, 2011.


Exercices de modélisation UMLDiagramme de classe


Petit exercice de modélisation d'un document utilisant l'agrégation

Un document comprend une table de matières, un index et plusieurschapitres. Chaque chapitre comprend plusieurs paragraphes. Le documentpeut utiliser jusqu'à 3 polices normalisées pour la publication des documentschez cet éditeur.

Si un document est supprimé, les chapitres, les paragraphes, l'index et la tabledes matières le sont aussi. Les images de chaque paragraphe illustrent lecontenu et sans ce dernier, elles n'ont pas de sens.

Le chapitre est identifié par un numéro (noChap), l'index par un nom (nomIdx), la table des matières par un nom (nomPM), le paragraphe par un no (noPara) qui débute à 1 et se termine avec le dernier paragraphe du chapitre.

La police de caractères est identifiée par un noPolCar.

-- Faire un diagramme de classe UML pour ce document en utilisant que l’agrégation.


Solution avec l’agrégation

Document:

noDoc*

Chapitre

noChapitre* :int

nbMots

Paragraphe

noPara* : int

Index

nomIdx* : string

nbEntrees

TableMatieres

nomTM* : string

PoliceCaractere

noPolCar* : int

1..* 1..3

1..* L’agrégation forte sous-tend la suppression d'une partie lorsque le tout est supprimé (document).

Image

URL* : string

1 1

1..*

L’agrégation faible sous-tend que la suppression du document ne supprime pas les polices de caractères qui peuvent être aussi utilisées par d'autres documents.


Quelques opérations sur les tableSpaces utilisés pour le rangement des objets** RAPPEL **

select object_name from user_objects;select object_name, object_type from user_objects;

drop type &type from user_objects;

Pour avoir le nom des tablespace:select tablespace_name, file_name from dba_data_files;

Pour supprimer tables et schéma dans le DD: Drop user angam4 CASCADE;

Pour créer une nouvelle tablespace:CREATE TABLESPACE storage2 DATAFILE 'C:\ORADATA\ORCL\SYSTEM02.DBF'SIZE 1M DEFAULT STORAGE ( INITIAL 256K NEXT 256K PCTINCREASE 0);

Pour mettre off-line une tablespace:ALTER TABLESPACE storage1 OFFLINE;ALTER TABLESPACE storage2 ONLINE;

Pour ranger les données dans une autre tablespace:Alter user angam default tablespace storage2;


FIN

implémentation du diagramme de classe uml et des ...agamache/ift3202/pagesweb... · diagramme de...

Documents