Modèle navigationnel (Mnav)

Page 1

André Gamache professeur associé, Département d'informatique et de génie logicielFaculté des sciences et de génie, Université Laval. Québec, Qc, Canada, G1K 7P4

Module 2

Modèle navigationnel © Module 2 page 1

Transformation du diagramme de classe UML en un

modèle navigationnel pour un passage à l’objet

Modèle navigationnel (Mnav)

2016-08-26 ©

André Gamache, professeur associéDépartement d'informatique et de génie logicielFaculté des sciences et de génie

Université Laval. Québec, Qc, Canada, G1K 7P4

Courriel: [email protected]


Notions d’objet

Objet physique : objet matériel concret de la vie ou symbolique ayant des attributs de volume, de poids, de matière, de fonctions, de forme, d’apparence, …

Exemples: un avion, un moteur, une ouvre d’art, une photo, …, une réaction moléculaire, …

Objet informatique: représentation des attributs de l’objet physique par une structure informatique disponible par un langage, construit de toute pièce ou une structure de stockage: entier, réel, struct, fichier, …

Exemples: un vecteur de valeurs, une struct complexe, un fichier jpeg, …

Objet informatique complexe: un objet informatique auquel est associé impérativement toute manipulation ou transformation de l’objet au regard de contraintes fortes et élaborées.

Exemples: les plans vectorisés d’un avion et les traitements de création, mise à jour, rotation, translation, coloration, …

Page 2


Module 2


C'est un passage utile pour des fins didactiques seulement.

Comment passer du conceptuel au modèle objet ?

La passage du diagramme de classe de UML à l‘Objet est rendu facile par le modèle dit navigationnel (un outil didactique pour le niveau conceptuel) inspiré de la notation proposée par Christian Soutou (1).

Le système à base d’objets va alléger les lacunes signalées dans le module 1, mais pas toutes!

Ce modèle Mnav joue le rôle de pivot ou d'étape entre le diagramme de classe de UML et le modèle d'implantation objet.

Le Mnav ne remplace pas la vérification et le renforcement des contraintes du modèle, lesquelles devront être prises en charge par les méthodes spécialisées de chaque interface de classe.

Le Mnav fournit une structure qui incorpore explicitement certaines contraintes du modèle mais pas toutes!

(1) Notation graphique proposée par C. Soutou, Objet-Relationnel Eyrolles1999


Modèle navigationnel (Mnav)

Objectifs du Mnav

• Faciliter le passage vers l’Objet par un ensemble de règles de transposition :

Diagramme de classe‐UML => navigationnel => Objet

• Favoriser la visualisation des structures complexes et des chemins de navigation possibles en conservant la notion d’objet.

• Représenter concrètement le plus de contraintes possibles pouvant être spécifiées par le langage DDL du SGBD.

Lacune du Mnav :

• Devient rapidement encombré et encombrant pour des modèles complexes!!!

• Ne représente pas bien le partage des types entre différentes parties d’un modèle UML (classes) complexe.

Pourquoi le navigationnel ? Le modèle introduit les liens de type REF (implémentation avec l’oid + autres informations) entre les classes UML.

Page 3


Module 2


Quelque définitions clés du Mnav

Classe externe

La classe UML sera rendue dans le Mnav par une classe dite externe qui est en

quelque sorte au plan informatique un type (i.e. une structure nommée) défini par

ses attributs. Une classe externe définit des objets autonomes (dont l’existence

ne dépend pas d’un autre objet) dans la base i.e. possède une valeur + un oid

qui rend l’objet persistant.

*** En UML, la classe externe correspond à une classe UML.***Il en sera autrement pour une autre dite interne propre au Mnav.

OID

Un oid est un identifiant d’objet unique, non réutilisable pour toute la vie de la

base. Un objet ayant un oid est persistant dans la base. Il est représenté par un rond blanc ou

noir.

Classe interne

Une classe interne est une classe capable de définir des objets (sans oid propre) mais sans oid dont la

persistance exige son imbrication dans un objet d’une classe externe.

Les classes interne et externe sont nommées et ont chacune une interface.


Les attributs du Mnav

Attribut simple:

L’attribut simple est idem à celui de UML: type atomique avec ses opérations

primitives régulières et implicites:ex. un entier avec ses opérateurs arithmétiques valides

une chaîne avec son opérateur de concaténation, …

Attribut complexe

L’attribut complexe permet d’abandonner la forme normale FN1 du modèle relationnel en ajoutant une structure de tuple pour regrouper plusieurs attributs éventuellement de types différents. (struct)

L’attribut complexe a un type (complexe) mais aucune méthode de traitement associée. Cette carence sera cependant contournée par une autre approche.

Page 4


Module 2


Lien : simple avec une classe interne ou externe

Lien simple:

Un lien est établi entre un attribut et une classe interne ou externe :

Un lien simple associe une valeur d’un attribut à 1 objet de la classe interne ou externe.

lien interne simple interne

Ce lien peut être vide (rond blanc) ou obligatoirement valué par un oid (rond noir)

Employe: employe_t

nasE : int

nomE : string (varchar)

specialite:


Lien multiple avec une classe interne ou externe

Lien multiple:

Un lien multiple est établi entre un attribut et une classe interne ou externe :

Un lien multiple pour un attribut y associe 0 ou plusieurs objets de la classe interne ou externe.

nasE : int

nomE : string

lesSpecialites

Employe: employe_t

lien interne multiple

Ce lien peut être vide (rond blanc) ou obligatoirement valué (rond noir)

Page 5


Module 2


Attribut complexe: tuple et ensemble/classe externe et interne

Tuple

Le tuple est une structure logique linéaire formée d’attributs simples ou complexes mais sans interface.

Un attribut complexe définit des valeurs dont l’existence dépend que de l’objet externe qui les héberge. Il est représenté par une structure non nommée et sans interface. Ce n’est pas une classe interne mais uniquement une structure pour y ranger des valeurs.

Un employé a une spécialité définie par 3 attributs

Exemple d’un attribut de type complexe associée à une structure de tuple.

Employe: employe_t

nasE : int

nomE : string

laSpecialite:specPrinc: string

anExp : number

date: Date

L’attribut « laSpecialite » est associé à une structure de tuple (similaire à une struct).

C’est un tuple et non une

classe interne car sans interface et sans nom de classe

représentation graphique

sans interface


Attribut associé à un seul objet

Un attribut associé à un seul objet d’une classe est représenté par un lien simple vers une classe interne.

Dans cet exemple, l’attribut laSpecialite est obligatoirement valué par un objet qui caractérise chaque Employe et est imbriqué dans la classe externe Employe. Cet objet a une interface et une persistance.

Employe: employe_t

nasE : int

nomE : string

laSpecialite:

spec: string

annee : Date

Specialite:specialite_t

Classe interne nommée et dotée d’une interface

Le nom de la classe avec les : , annonce le type de la classenormalement constituée du nom suffixé par _t _t

Ex en O2:

nasE : int

nomE : varchar

laSpecialite: Specialite

Page 6


Module 2


Attribut d’ensemble ordonné d’objets (v)

Un attribut d’ensemble ordonné d’objets est rendu par un lien interne multiple concrétisée par une structure de type varray.

Les éléments de l’attribut lesSpecialites sont stockés dans un varray (similaire à un tableau ou un array et noté V). Chaque entrée est indicée et peut-être soit une valeur soit un objet interne. Le varray a des attributs propres qui pourraient être considérés comme des fonctions prédéfinies et non modifiables.

Classe interne de type ensemble rendue par unestructure varray (V)nasE : int

nomE : string

lesSpecialitesv

Employe: employe_t


Attribut d’ensemble non ordonné d’objets

Un attribut d’ensemble d’objets est rendu par un lien interne multiple vers une classe interne.

lesSpecialites est un ensemble { } d’objets internes non vide. Chaque objet de l’ensemble est associé à l’interface de la classe interne.

nasE : int

nomE : string

lesSpecialites

Classe interne de type ensemble.

Employe: employe_t

Page 7


Module 2


Persistance d’un objet

La notion de persistance a trait à la capacité d’un objet de devenir permanent dès sa création par une application. Certains objets ne sont pas persistants à leur création (objet de travail) tandis que d’autres le sont car ils sont intégrés à leur création dans un containeur d’objets ou dans un autre objet persistant qui leur confère une persistance. Chaque objet persistant est obligatoirement associé à un oid généré par le système.

Implantation de la persistance BD

Un objet est créé en RAM par une application et devient persistant s’il est transféré dans la cache du serveur. En cas, de panne du serveur un objet persistant encore en cache doit survivre grâce aux techniques bien connues des journaux externes du SGBD (Rollback segments de Oracle):

L’écriture d’un objet n’est pas nécessairement réalisée immédiatement pour des raisons de performance mais est toujours accompagné d’une écriture dans un journal interne ou externe qui est à la base du recouvrement (voir la notion de rollback). Ceci garantit la persistance. ‘


Passage de UML au Relationnel

Le MR privilégie la notion loqique de table qui utilise la structure de tuple.

Atelier (noA*, nomA) FN3; FN4:FN5

Employe (nasE*, nomE, metierE, noA) FN3; FN4:FN5

Rappel:

Dans le MR, la normalisation est appliquée jusqu’en FN3 (ou mieux en FNBC) pour éviter l’incohérence. Idéalement, il faudrait avoir des relations en FN5 pour éviter certaines et dernières anomalies de mise à jour. Ces dernières anomalies sont cependant rares et leur évitement par un éclatement poussé des relations n’est pas toujours justifié. Important: on énonce qu’un employé a UNseul métier pour justifier la FN3.

Modèle UML: les classes UML sont des concepts logiques apparentés à la notion de type (avec la technologie Oracle).

Atelier:

noA* : int

nomA : string

Employe:

nasE*: int

nomE: string

metierE: string

0..*0..1

Embauche >Conventions:

* == 0..*

1 == 1,1

Page 8


Module 2


Passage de l’UML Atelier‐Employe au Mnav

Lien externe multiple représente le type ensemble (set) pour l’attribut lesEmbaucheset est formé de oids des objets de type employé.

L’association UML est rendue par un lien externe qui utilise une référence pour associer un ou plusieurs objets de la classe Employe. La multiplicité minimale 0 du côté Atelier est représentée par le cercle blanc. La multiplicité minimale de 1 le serait par le rond noir.

Atelier: atelier_t

noA* : int

nomA : string

lesEmbauches:

Employe:employe_t

nasE*: int

nomE: string

metierE: string

Classe externe de type objet

La multiplicité 0..* est explicitement représentée

* lesEmbauches

*


En l’absence d’un attribut d’association

Atelier: atelier_t

noA* : int

nomA : string

lesEmbauches:

Employe:employe_t

nasE*: int

nomE: string

metierE: string

lesEmbauches est un attribut d’ensemble dont les éléments sont des oids et non des objets. Ces derniers étant rangés dans le containeur de la classe externe Employe.

La spécification de lesEmbauches peut être en principe un ensemble de type set, list, bag, table, …

lesEmbauches est un attribut d’ensemble ayant un type d’ensemble et dont les éléments sont des objets internes ou des oids référant à des objets externes.

Page 9


Module 2


Autre représentation du modèle Atelier‐Employe (sans attribut)

Atelier:atelier_t

noA* : int

nomA : string

lesEmbauches:

Employe: employe_t

nasE*: int

nomE: string

metierE: string

OidEmploye: refrefEmpl

L’attribut lesEmbauches est associé par un lien interne à un ensemble d’oids, chacun référant à un d’objet externe.

Pour simplifier la représentation, cette table d’objets internes peut être enlevée du modèle graphique.


Traversée du Mnav au moyen du lien simple

Pour faire des recherches il faut parcourir l’association UML donc exploiter le lien externe simple avec SQL:

1‐ Quels sont les employés qui travaillent dans l’atelier 120?

Le lien externe multiple permet de répondre à ces questions sans avoir à formuler explicitement une jointure. En pseudoSQL:

Sélection de l’atelier 120 fournit l’ensemble des oids dont chacun permet de référer à l’objet de Employé associé.

Select {oid de employé} from Atelier a where a.noA =120

2‐ Quel est l’atelier où travaille l’employé dont le nasE est 50?

Il faut afficher l’objet Atelier dont l’attribut lesEmbauches renferme l’oid du nasE50.

select a.noA from Atelier a

Where (oid de l’employe de nasE =50) ) IN

(les oids de l’ensemble des employés de Atelier);

Page 10


Module 2


Ajout d’un attribut d’association: classe interne et lien multiple

Ce modèle représente l’embauche à une certaine date d’un employé par un atelier.

** L’attribut lesEmbauches désigne un ensemble d’objets de la classe refEmployedont les obets sont de type REF et dont la définition comprend un attribut d’association: dateEmbauche

Atelier: atelier_t

noA* : int

nomA : string

lesEmbauches:

refEmpl

dateEmbauche

nasE*: int

nomE: string

metierE: string

refEmploye: refNouvel attribut possible

Employe:employe_t


Renforcement de la 2e multiplicité : 0..1 du côté Atelier?

Lien externe multiple pour représenter le type ensemble (set). Aucun sens de parcours privilégié.

nasE*: int

nomE: string

metierE: string

refAtelier

Employe:

Atelier:

noA* : int

nomA : string

lesEmbauches:

Classe externe de type objet

Boucle interdite:

Pour définir l’objet Employe, il faut se référer à l’objet Atelier dont le type sera incomplet car il réfère par son lien multiple à un ensemble d’objets dont le type est déjà incomplet.

Page 11


Module 2


Renforcement de la contrainte 0..1 du côté Atelier

Comment faire?

Par les méthodes :

*- Prévoir la vérification de toutes les contraintes par une méthodeexécutée dans une transaction avec synchronisation et validation des diverses modifications faites sur les données.


Représentation de Atelier‐Employe sans classe externe

Lien interne de type ensemblepour modéliser l’association 0,* (pointe double).Ce lien sous-tend l’imbrication des objets Employe dans un objet Atelier.

Mnav représente visuellement et directement les données complexes sans exiger la normalisation des structures de 1er niveau.

Caractéristiques de ce modèle: accès direct à un atelier et à ses employés;

Sauf: la multiplicité du côté Atelier : En créant un employé il faut aussi obligatoirement créer au préalable un Atelier : (1..1) du côté Atelier

Classe interne de type objet

La classe UML devient une classe externe ou un type externe avec 3 attributs.

Attribut d’ensemble référant à des d’objets d’une classe interne.

Atelier: atelier_t

noA* : int

nomA : string

lesEmbauches:

nasE: int

nomE: string

metierE: string

Employe :employe_t

modifNomA( )

Page 12


Module 2


Représentation multiple pour un modèle

Pour un même modèle UML il peut dont y avoir plusieurs modèles Mnav possibles.

Comment choisir?

Le plus complexe n’est pas nécessairement le pire comme le plus simple le meilleur.

Critère de choix:

Le choix se fera entre plusieurs représentations de la même réalité sur la base de l’efficacité des principales opérations à mettre en œuvre pour effectuer les traitements lourds. L’importance relative des questions est aussi à prendre en compte (mais souvent difficile à estimer). Il faudra souvent attendre de connaître les structures physiques utilisées pour l’implantation du modèle pour faire un choix judicieux!


Réification : construction d’un objet [informatique]

Un objet est structuré par l’entremise de son constructeur. Après sa création un objet peut acquérir un oid le rendant persistant.

Quel est le constructeur?Chaque classe externe, interne a un type qui porte le même son nom suffixé par _t :

L’objet :employe := [ 234, ‘Paul’, 34, 85, ...] ∊ classe de type employe_t

Avec Oracle, cet objet est construit avec le constructeur qui porte le nom du type: employe_t ( 234, ‘Paul’, 34, 85, ...)

L’objet construit est rangé dans son extension ou son containeur qui est une table-objet de Oracle et devient alors persistant, acquérant un oid.

L’extension peut être toute autre structure de type ensemble utilisée avec d’autres systèmes: list(), bag(), set(), ….

Page 13


Module 2


Résumé des conventions d'écriture pour le Mnav

La notion de classe externe correspond à une structure de données complexe équivalente à la classe UML. La classe interne est aussi un type ou une structure de données mais imbriquée dans une classe externe. Elle peut représenter une structure d’ensemble ou de tuple selon la nature du lien (multiple ou simple)

Le lien externe est de type REF représente une référence logique sans égard à leur implantation physique. Le lien peut-être simple ou multiple et réfère à des objets.

Les objets d’une classe interne sont dits objet-colonne.

Par convention:

Le nom d'une classe externe commence par une lettre majuscule : Employe

Le nom d'un attribut ou d'une méthode commence par une minuscule: matriculeE. Ce nom n'a pas d'accents, ni autres symboles orthographiques;

Le nom d'une association UML commence par une majuscule : EffectueS;


Ensemble vide: création et suppression des objets

Attribut lesEmbauches est un lien interne multiple sur des objets internes (sans oid) de Employe (objet-colonne de Oracle) inclus dans la classe Atelier.

La référence non obligatoire suppose que l’ensemble peut être vide, i.e. il peut y a voir un atelier sans employé!

La suppression du dernier employé d’un atelier n’implique pas la disparition de ce dernier!

noA : int

nomA : string

lesEmbauches :

nasE : int

nomE : string

metierE : string

Employe: employe_t

Atelier : atelier_t

Les opérations (méthodes)

Page 14


Module 2


Information ajoutée par la référence obligatoire (ou non vide)?

La référence obligatoire impose qu’un atelier à sa création a obligatoirement au moins 1 employé.

La suppression du dernier employé sous-tend la suppression de l’atelier.

** Source d’incohérence si l’atelier n’est pas supprimé avec la suppression du dernier employé.

noA : int

nomA : string

lesEmbauches :

Les opérations

nasE : int

nomE : string

metierE : string

Employe:employe_t

Atelier: atelier_t

Dans cet exemple, le lien interne multiple représente un ensemble d’objets internes

nommé lesEmbauches. En Oracle cet ensemble imbriqué correspond à une sous-table .


Représentation (Oracle) TABULAIRE du lien interne multiple

Atelier: noA: string nomA: string

nasE : int nomE: string metierE: string

A20 Atelier B 123 Arthur fraîseur

234 Sylvie tourneur

A30 Atlier C 256 Pierre perceur

456 Serge ponceur

{lesEmbauches} oulesEmbauches: { }

Cette vision de la classe instanciée repose sur la notion de table comme containeur. La table Atelier a un attribut d’ensemble, lesEmbauches tune sous-table (imbriquée) formée avec les attributs typés : nasE, nomE, metierE.

Nested TableAvec 2 collections (sets)

Page 15


Module 2


Lien externe : avec le type REF

La navigation entre les classes externes se fait avec un lien défini par un attribut de type REF.

Le lien externe spécifie une référence à un objet (matérialisée par un oid ou l'équivalent). L’oid n’est pas une adresse physique mais le deviendra lorsque l’objet sera transféré dans la cache du serveur d’objets (swizzling ou mutation de la référence).

Il est possible de contraindre le lien REF pour le limiter à cibler qu’une sorte d'objets (via la REF) et au besoin à être null (attribut scopé avec le SCOPE)

oid + objets

Cache en RAM

Adr_RAM oid

Objets associés à des adresses physiques de la RAM

Espace exécution du SGBD


Inconvénient du Mnav: partage difficile d’une classe interne

Le partage d’une classe interne avec plusieurs autres classes externes est difficile à

représenter dans le Mnav : partage de Adresse par les classes Atelier et Domicile.

Possibilité d'utiliser une astuce comme un lien fait d'un pointillé ?? Devient rapidement

lourd avec plusieurs partages dans de gros modèles !

Atelier: adresse_t

noA : int

nomA : string

adresseA :

no: int

rue:

Ville:

Adresse:

paysD : string

adresseD:

Domicile:domicile_t

(mais sous-entend un oid pour adresseD??

Or les objets de Adresse n’ont pas de oid!)

Page 16


Module 2


Résumé: attributs et liens du Mnav

Un attribut peut être:

• Simple (chaîne de caractères, nombre, …)

• Composé (complexe) avec une structure de tuple [..]

• Une référence (logique et basée sur l’oid : Ref)

• Collection ou un set (d’objets ou des références)

• Combinaisons des types précédents : TAD (Type Abstrait défini par l’usager)

Lien interne et externe:

Externe (inter): entre deux classes externes (explicite) incluant un ou des valeurs de Ref. C'est un lien navigationnel. Ex.: Oracle : un attribut de type REF.

Interne (intra): à l'intérieur d'une même classe externe et donnant accès représentant une structure de tuple; c'est un lien non‐navigationnel ‐‐ (avec Oracle: ce lien référence un objet‐colonne, OC, intégré dans la classe externe;


Lien simple et multiple (sommaire)

Un lien simple peut être:

1. Interne: pour associer à un attribut ayant une valeur complexe ou à un objet d’une classe interne (avec son interface)

2. Externe: pour associer un objet à un seul objet externe appartenant à une autre classe.

Un lien multiple (sous‐tend l’ensemble*) associe un objet à plusieurs instances d’un objet regroupé dans un ensemble (ordonné ou pas)

1. Interne multiple pour associer plusieurs objets‐colonnes inclus dans la classe interne.

2. Externe multiple pour associer plusieurs objets autonomes référés via un ensemble de oid

*En Oracle, un ensemble est une collection (terme générique pour Oracle!).

Page 17


Module 2


Avantages escomptés du modèle navigationnel (Mnav)

Le passage du DC‐UML vers le modèle objet est plus simple via le Mnav surtout avec les petits modèles UML .

Favorise un choix plus judicieux des liens entre les classes d’objets en prenant en compte les accès anticipés;

Une description plus explicite des associations

La visualisation des chemins par les liens rendant (souvent) plus facile la formulation des requêtes complexes multi‐classes;

*** Une recherche plus performante des objets de la base


Inconvénients du modèle navigationnel

Le partage d'un même type par plusieurs classes n'est pas représenté simplement voire adéquatement par le Mnav.

Il demeure possible (mais déconseillé ) de débuter la conception d'une base objet par l'élaboration directe d'un schéma navigationnel, donc sans DC‐UML. Danger de simplification ! C'est un modèle didactique … qu’il faudra abandonner par la suite!

Peut être parfois plus difficile de raisonner avec le Mnav complexe que de le faire le modèle relationnel, notamment pour les mises à jour des attributs de type ensemble.

Toutes les contraintes du diagramme de classe UML ne sont pas implémentées implicitement par la structure du Mnav. Il faudra le compléter dans le modèle objet par l’usage des méthodes.

Etape non essentielle ajoutée : passage direct du DC‐UML vers l’objet est possible sans transiter par le modèle Mnav.

Page 18


Module 2


Sommaire des symbolesLien simple

** L’absence de cercle signifie obligatoire

Lien simple obligatoire

Classe C1attribClé

attrib1

struct

Classe C1attribClé

attrib1

Avec les liens interne et externe :

Lien simple pouvant être null (facultatif)

Lien simple obligatoirement valué* (not null)

*Valuation: signifie donner une valeur à un attribut conformément à son type

La valuation de attrib1 donne une valeur représentée par la struct interne ou celle correspondant à un objet de la classe externe.


Sommaire des symbolesLien multiple

** L’absence de cercle signifie obligatoire

Lien multiple

Classe C1attribCle

attrib1

Classe int.

Classe C1attribCle

attrib1

Classe externe

Avec les liens multiples

interne et externe :

Lien multiple pouvant être null (ensemble pouvant être vide)

Lien multiple obligatoirement valué (ensemble obligatoirement non vide)

1-La valuation de attrib1 donne un ensemble d’objet internes2- dans le 2e cas, l’attribut est valué par un ensemble d’objets externes..

Page 19


Module 2


Suite : Sommaire de la représentation graphique (1)

Dans un Mnav, le lien simple est représenté par une flèche simple () et le lien multiple par une flèche a double pointe.

Le lien interne (intra) associe un attribut de structure complexe participant à la définition de la classe hôte et dont les données sont intégrées dans l’objet hôte.

Le choix entre un lien interne ou externe est basé sur des considérations d'exploitation : efficacité et le sens privilégié de la navigation exprimé par la flèche dans le diagramme de classe UML.

En bref: le lien externe évite la formulation explicite des jointures par l’application, mais peut rendre les mises à jour et les ajouts plus complexes : les Ref doivent être ajoutées et des contraintes sur les Ref doivent être gérées correctement.

Le lien Interne facilite la suppression des objets : suppression d'une instance de Chercheur entraîne celle de Adresse (son adresse).


Cascade de liens dans le modèle navigationnel (Mnav)

Représentation explicite par les liens externes: des structures de données complexes, des hiérarchies et des agrégations;

noA*: int

nomA : string Employe: employe_t

nasE*: string

nomE : string

Les opérations

Le type { } est sous-entendu par le lien externe multiple

refMetier

lesEmbauchesMetier: metier_t

noM*: int

corpoM: int

cotisation: real

Atelier: atelier_t

At Em Me

Création 1 objet 2 3 1

mise à jour 1 objet 2 2 1

Suppression 1 objet 1 2 2

lesEmbauches est le nom d’un ensemble de références (oid)

La difficulté est évaluée au regard de la gestion des liens.

Page 20


Module 2


Cascade d’associations UML: 1..* ‐ 1..* (liens)

Region:region_tnoR*: int

nomR : string

Ville:ville_tnomV: string1..*1..1

Reunit > (Interface) (Interface)

1..1

Formée >

Arrondis:arrondis_t

nomA: stringpresA: stringpopA: int

(Interface)

1..*L’insertion d’une région ne peut pas se faire sans celle d’au moins une ville laquelle ne peut pas être créée dans la base sans la création d’au moins un arrondissement.

Pour y arriver il faudra retarder la vérification des contraintes de ce modèle géré par le SGBD.


Mnav avec deux liens externes

Region: region_t

noR*: int

nomR:string

lesVilles:

Ville:ville_T

nomV*: stringlesArrondis:

La multiplicité 1..1 du côté Region sera renforcée par la méthode d’ajout d’une ville afin de vérifier qu’il y a obligatoirement une région associée à une ville au moins un arrondissement.

Le lien renforce la contrainte qu’une région est obligatoirement associée à au moins une ville.

Arrondis:arrondis_t

nomA: string

presA:string

popA: intTrois classes, cela sous-tend normalement un stockagedes objets dans des tablespaces de Oracle différents, ce qui peut alourdir l’exploitation.

R V A

création 2 2 1

mise à jour 2 3 2

suppression 1 3 2AjoutV

delaRegion

?

Page 21


Module 2


Pourquoi ne pas définir aussi un lien inverse?

Ce 2e lien de Ville vers Region (delaRegion) serait pratiquement inutile s’il n’est pas justifié par le parcours privilégié du lien.

Exemple avec un lien inverse ajouté:

Ajout du lien delaRegion dans Ville:

- créer un 1er lien de Region vers Ville avec l’insertion d’une REF.

Region: region_t

noR*: int

nomR:string

lesVilles:

Ville:ville_T

nomV: stringlesArrondis:

AjoutV

delaRegion:

Le parcours préférentiel d’une association détermine la nature du lien à privilégier.

?Select r.nomR

From Region r

Where (oid de la ville dont le nomV = ) IN lesVilles


Mnav avec deux liens : externe et interne

L'attribut lesVilles est une collection ou set() de oids (ref) sur les objets de la classe externe Ville.

Avec un lien interne entre Ville et Arrondis. Cela sous-tend que les objets de Arrondis sont stockés dans les pages de l’objet de Ville associé.

R V

création 2 3

Mise à jour 2 2

suppression 2 2

Region: region_t

noR* : int

nomR : string

lesVilles:

Ville: ville_tnomV : string lesArrondis

Arrondis:nomA: stringpresA: stringpopA: int

En découle une plus grande performance dans l’accès

aux arrondissements.

Page 22


Module 2


Mnav avec deux liens et imbrication des classes

Le lien est interne et multiple pointant sur une classe interne ce qui sous-tend un ensemble.

Par contre ce Mnav ne permet pas d’avoir une ville sans qu’elle soit associée à un une région. La contrainte 1..1 est renforcée par ce modèle navigationnel.La suppression d'une instance de Region entraîne aussi celle de ses villes et arrondissements.

Impact au niveau de la performance?

Quels sont les arrondissements de la région R1?

noR*: string

nomR: string

lesVilles:

Region: region_t

Ville:ville_t

nomV* : int

lesArrondis:

Arrondis:

nomA*:string

presA: string

popA: int

R V A

création 3 2 1

mise à jour 3 2 1

suppression 1 2 2

lecture 1 2 3


Modèle UML CSP

La suppression d'un objet Chercheur nécessairement la suppression de sa subvention entraîne (si elle existe) mais pas des projets qu’elle finance.

Chercheur:

noC*: string

nomC: string

Subvention :

noS : int

nomPgm : string

Projet : projet_t

noP* : int

montant : real

organisme : string

0..*1..1

1..*

0..1

Gere >

Finance >

Page 23


Module 2


Combinaison de lien interne simple et externe multiple

Le dernier projet ne pourrait-être supprimé sans faire disparaître la subvention obtenue; sinon il y a violation de la contrainte sur le lien externe.

Si une subvention est supprimée, le chercheur ne l’est pas de facto. Idem pour Projet

L’ajout d’un chercheur peut se faire sans subvention ni projet.

Si le chercheur a une subvention, celle-ci est obligatoirement associée à 1 ou plusieurs projets.

C P

création 2 1

Mise à jour 2 1

suppression 1 2

Chercheur:

noC*: string

nomC: string

lesSubventions:

Subvention :

noS : int

nomPgm : string

lesProjets

Projet:

noP* : int

montant : real

organisme : string


Mnav avec deux liens externes et multiples

Avec ce modèle il devient plus difficile d’obtenir le chercheur travaillant sur un projet subventionné particulier. La suppression du dernier projet entraîne celle de la subventionmais pas celle du chercheur.

Chercheur:

noC*: string

nomC: string

lesSubventions:

Subvention :

noS : int

nomPgm : string

lesProjets

Projet:

noP* : int

montant : real

organisme : string

Page 24


Module 2


Les interfaces dans un Mnav

Les classes externe et interne peuvent avoir leur propre interface.

Avec la technologie Oracle:

• L’interface d’une classe externe permet le traitement des objets de table (OT).

• L’interface d’une classe interne permet le traitement des objets imbriqués (objets-colonnes (OC)).

Dans les deux cas: objets à part entière: interface et persistance.


Les interfaces dans un Mnav

PC:

noSerie*: intadrIP: stringcpu: string

installerPC(…)

brancherPC(…)

Logiciel:

nomL* : string

versionL: int

editeurL: string

lesInstallations:

Installation:datateI: string

refPosteI:

installerLog(…)

noD*: int

nomD: string

adresseD:

lesLogiciels:

budget : real

Departement:

creerDep

achatLogiciel(…)

Adresse:rue : string

ville : string

Dans un modèle les signatures sont identifiéesglobalement comme une interface: avec Oracle, l’interface n‘est pas nommée.

L’interface est factorisée au regard des instances et rangée dans le dictionnaire de la base, lui-même structuré en objets.

Page 25


Module 2


Accès aux objets ou aux données ?

En phase d’exploitation, l’application peut faire une recherche et obtenir soit un objet soit les valeurs de l’objet en provenance de la base de données.

Cas 1: La recherche renvoie à l’application des objets que celle-ci doit stocker dans une structure d’objet préalablement définie par l’application.

Ces objets peuvent ensuite être traités par les méthodes propres à l’application par le programme JAVA, C++, …

Cas 2: La recherche renvoie que les valeurs des objets trouvés par la SGBD. Ces valeurs sont stockées dans des variables typées locales à l’application.

Le traitement se poursuit et se fait par l’application.

Pour obtenir que ces valeurs avec une BDOO de Oracle: il faut souvent aplatir les tables contenant les objets-colonnes.

C’est le unnesting des objets qui se fait par le SGBD sur le serveur avec SQL.


Classe interne et UnNesting (sous‐table)

Une classe interne avec un lien multiple incident correspond à une sous-table dans une vision tabulaire des données.

Pour avoir accès aux données des objets de la classe interne avec SQL, donc aux données de la sous-table avec celles de l’objet externe associé , il faut faire une opération spéciale de unNesting.Ce traitement ramène les objets-colonnes (les objets de la classe interne) au 1er niveau, exploitables directement par SQL (et les curseurs de PL/SQL) comme des valeurs (et non comme des objets).

lesEmpl

Depart: noD: int

nomD: varchar

Empl:

noE : int

nomE: varchar

lesEmpl.noE : int

lesEmpl.nomE: varchar

Depart: noD: int

nomD: varcharUnnestDepart noD nomD lesEmpl.noE lesEmpl.nomE

Select d.noD, e.noE

From Departement d, Table(d.lesEmpl) e

Where d.Empl.noE > 135;Select lesEmpl

From Departement d

Where d.lesEmpl.noE >135;

Page 26


Module 2


Représentation tabulaire d’une classe externe et interne

Avec la technologie objet de Oracle, le container ou l’extension des objets est la table laquelle doit pouvoir stocker des valeurs et des objets en cohabitation.

Une classe interne est rendue par une table imbriquée peu importe le niveau et doit être aplatie

(Unnested) suivi d’une jointure pour permettre l’accès aux valeurs avec SQL. Les valeurs de la classe

externe est rendue par une table de base du genre relationnelle.

A lesBC D

a1 c1 d1 c3 d2

a2 c4 d5

A B.C B.Da1 c1 d1

a1 c3 d2

a2 c4 d5

a1 c4 d4

T1: T1*:

Impossible : Insert into T1 ( A, B.C, B.D) values (a1, c4, d4); Mais …

Insert into T1* ( A, B.C, B.D) values (a1, c4, d4); si et seulement si la table préalablement aplatie

Select * from T1; -- fournit les valeurs de A et les objets-colonnes

Mais : Select A, B from T1 ne peut pas être calculé! Donc pas de réponse!

+


Unnesting d'une table (classe interne) en Oracle : la fonction Table()

SQL‐DML manipule seulement des valeurs de tables de premier niveau, car SQL implémente les opérateurs de l’algèbre relationnelle.

SQL doit donc exploiter des tables aplaties pour obtenir des valeurs!

Une table imbriquée est aplatie (Unnested) par la fonction Table() qui implique l’usge d’ une clé interne entre la table et la sous‐table ramenée au 1er niveau!

On peut aussi interpréter le unnesting comme une pseudo «désencapsulation»de l’ensemble imbriqué* pour amener au 1er niveau les attributs et les valeurs des objets de l’ensemble.

L’accès et l’affichage SEULEMENT des valeurs d’attribut des objets‐colonnes ne

nécessitent pas la jointure: seule la Table() de l’attribut d’ensemble est «unnesté».

* L’attribut associé à un lien multiple en est un d’ensemble contenant des objets imbriqués

Page 27


Module 2


Représentation tabulaire du Mnav et un lien interne

T1

A : int

lesB

B

c : int

d: int

A: lesB:lesB_tC D

a1 c1 d1 c3 d2

a2 c4 d5

T1


Unnesting et le Stockage physique d’une table imbriquée

A lesB: lesB_tC D

a1 c1 d1 c3 d2

a2 c4 d5

A cle‐Interne

a1 p0001

a2 p0002

C D cle‐interme

c1 d1 p0001

c3 d2 p0001

c4 d5 p0002

T1a

T1

T1b

Jointure implicite: T1 := T1a |x| T1b

Select x.A , w.C, w.D

From T1 x , Table (x.lesB) w;

Pour accéder à des valeurs particulières de l’ensemble imbriqué seulement:

Select w.C

From Table (lesB) w ;

Pour afficher les valeurs de tous les attributs, il faut recourir au unnesting avec la fonction Table() suivi d’une jointure entre la table parent et la sous-table pour obtenir une table temporaire aplatie:

Stockage d’une table imbriquée:

Page 28


Module 2


Le Unnesting et la classe interne

Pour chaque modèle navigationnel ayant une table interne, cela suppose au niveau de l’implantation et de l’exploitation une opération de Unnesting pour avoir accès aux valeurs.

Select

Select x.A, w.C

From T1 x , Table (x.lesB) w;

Select w.D /* lecture que des valeurs de la sous-table */

From Table (lesB) w ;

Select x.A /* unnesting non necessaire pour afficher que cette valeur A */

From T1 x;

Select * from lesB -- invalide car lesB n’a pas de containeur associé


Résumé pour aide‐mémoire

Le passage du DC-UML au Mnav peut se faire de diverses façons. Le critère de choix du modèle cible est que le modèle navigationnel obtenu se conforme le plus possible :

1- avec la sémantique du DC-UML et de ses contraintes.

2- avec l’exploitation des données

Plus il y aura de contraintes renforcées par la structure et la sémantique du modèle Mnav, plus ce dernier sera à privilégier.

Les contraintes qui ne sont pas renforcées par le Mnav, le seront par une méthode.

Passage du diagramme de classe UML au modèle navigationnel (Mnav)

Page 29


Module 2


Du DC‐UML vers le navigationnel: règles de passage

Transformation d'une classe UML :

• Chaque classe du DC‐UML, sauf les classes‐associations, est transformée en une

classe externe du Mnav.

• Chaque attribut composé de type tuple UML devient une classe interne avec un lien interne simple vers un seul objet. Il peut aussi être transformé en un attribut complexe sans être un objet.

• Chaque attribut d’ensemble est rendu par un lien interne multiple ou un lien externe multiple (avec Ref) selon l’existence autonome ou pas des objets au regard de la suppression. Le choix estaussi fonction de la performance d’accès recherchée.

Identifiant facultatif pour la classe du Mnav :

• Chaque classe du Mnav (sauf les sous‐classes dans l’arbre d’héritage) et la classe d'association, peut avoir un identifiant de valeur. Souvent pratique pour la recherche, mais non obligatoire.

• Si aucun attribut ne convient pas comme clé, on peut ajouter une clé, si possible significative. Ce n’est cependant pas une exigence du modèle.

Transformation des associations :

Plusieurs possibilités selon le genre d'association : 1‐1, 1‐* et *‐*…

La contrainte d’une association étant spécifiée de préférence par le DDL‐SQL du SGBD

utilisé. Autrement, elle sera renforcée par une méthode.


Transformation de l'association 0..1 – 1..1

1ère solution :

L'attribut de type Ref peut être nul dans C2. L'accès privilégié est par C2.

C1

as1op1

C2

as2op2Asso

0..1 1,1

En lisant l'attribut ar2 de C2 (1 ref ) il y a un accès direct à l'instance correspondante dans C1. Le ar2 est de type REF et peut être null.

C2

as2

ar2

C1

as1

Toutes les multiplicités de la classe UML ne sont pas représentées par ce Mnav!

< A

as : attribut simplear: attribut de type REFop: interface

Page 30


Module 2


2ème solution avec le parcours inverse : accès via C1 et accès à C2 via l'attribut de référence ar1 qui ne peut pas être nul.

(Suite) Transformation des associations: 0..1 – 1..1

Le sens de la navigation est indiqué dans le DC-UML suggérant la transformation appropriée.

Si le sens de la navigation est absent dans l'association : on peut assumer alors que les 2 sens sont équiprobables

C1

as1op1

C2

as2op2A >

0..1 1..1

C2as2

C1

as1

ar1

La multiplicité du côté de C1 n’est pas représentée !


(suite) Transformation des associations UML : 0..1 – 1..1

3e solution pour les 2 sens de parcours: 2 liens simples (aucun sens privilégié)

ar1 de C1 est du type REF monovalué non null qui réfère à C2 (donc aux objets de la classe C2).

ar2 : est un attribut REF qui réfère à un objet de C1 et qui peut être null.• La suppression de C2 sous-tend 1 mise à jour de ar1.

• La suppression de C1 est suivie d’une mise à jour de ar2Ce Mnav exprime le renforcement des 2 contraintes par le modèle sans égard au sens privilégié du parcours de l’association. Il faut recourir cependant au shadowing ou type incomplet pour définir ce modèle.

C2as2

ar2

C1as1

ar1

Page 31


Module 2


4e solution (dite universelle): utilisation d'une 3e classe CA avec 2 liensexternes. Toutes les multiplicités sont renforcées par le modèle.

(suite) Transformation des associations: 0..1 – 1..1

Évolution du modèle:Le modèle peut évoluer en intégrant un attribut pour la classe d’association sans pénaliser l'interrogation et la manipulation de la base d’objets.

C2as2*

CAar2

ar1

C1as1*

La suppression de C2 entraîne celle de C1 qui lui serait associé.


Interrogation avec SQL: cas lien simple

Stages étudiants (UML) :

Etudiant(e):matricule* : string

nom : string

Stage:noS* : int

themeS: string

respS : string

Effectue >0..1 1..1

Solution avec une REF simple: Etudiant(e):

matricule* : string

nom : string

refStage

Stage:noS* : int

themeS: string

respS : string

Un lien peut être parcouru grâce à la référence et via la notation pointée.

Page 32


Module 2


Quelques interrogations du modèle Mnav (via le lien simple)

1‐ Quels sont les étudiants (matricule) sans stage?

Aucun car pour être dans la base il faut être associé à un stage.

2‐ Quels sont les stages disponibles?

Select s.noSFrom Stage s

‐ (minus)

Select e.refStage.noSFrom Etudiant e[ Where e.refStage is not null ]

Notez le parcours de l’association par la notation pointée.

Etudiant(e):matricule* : string

nom : string

refStage

Stage:noS* : int

themeS: string

respS : string


(Suite) interrogation avec SQL

3‐ Quels sont les thèmes des stages choisis?

Select e.refStage.themeS

From Etudiant e ;

4‐ Quel est le matricule des étudiants et le numéro de stage choisi dont le thème porte sur l’analyse?

Select e.matricule, e.refStage.noS

From Etudiant e

Where e.refStage.themeS = "analyse";

Page 33


Module 2


Association de multiplicités 0..* et 1..1

1ère solution : un lien multiple. La multiplicité minimale 0 figure à la source du lien ar2 de C2. Le parcours privilégié est pris en compte.

C1

as1*op1

C2

as2*op2

< A0..* 1..1

(enfants) (parent)

L'accès par C2 est privilégié (<). La suppression d'un objet C2 doit entraîner s’il y a lieu les objets C1 associés (contrainte 1..1 du côté C2). La suppression de C1 ?

C2C1as2*ar2

as1*(<)

c1 c2

création 2 1

Mise à jour 1 2

suppression 2 2

recherche 1 1

as : attribut simplear: attribut de type REFop: action d’interface

op1 op2


Association 0..* ‐‐ 1..1 (suite)

2e solution *** : un lien monovalué non nul vers le parent C2

Chaque instance de C1 est liée à une instance de C2 par la référence ar1 obligatoire.

La suppression de C1 se limite à cette opération.

La suppression de C2 doit être bloquée si elle est référée par un objet de C1.

La ref ar1 doit avoir obligatoirement une référence valide.

La suppression de C2 devrait donc éventuellement entraîner aussi celle de C1 qui s'y réfère et cela au cours d’une même transaction.

C2as2*

C1as1*

ar1

c1 c2

création 2 1

Mise à jour 2 1

suppression 1 2

recherche 1 1

Page 34


Module 2


Interrogation avec le modèle de la solution no 1

Quels sont les objets C1 associés à un objet C2 dont as2 = 5 ?

Select s.as1.*

From C1 s

Where s.ar1.as2 = 5

La variable objet associée à C1 , s est obligatoire

Le parcours avec le lien externe simple est fait grâce avec la notation pointée.


L’ajout d’un objet C2 ne présume de lacréation d’un objet C1.En supprimant un objet C2, les objets C1. associés sont aussi supprimés.

L’ajout d’un objet de C1 suppose l’existence d’un objet hôte C2.

Association (C1) 0..* ‐ 1..1 (C2) avec un lien interne multiple

Le lien interne multiple pour ar2 sous-tend un ensemble formé avec des objets-colonnes de type C1 imbriqués. La réalisation physique en Oracle prend la forme d’une sous-table d’objets imbriqués. ** L'accès est privilégié par C2 pour trouver les C1. La suppression de C1 n’entraîne pas celle de C2, la classe hôte.

C2as2

ar2

(ou lesar2)

C1

as1

Page 35


Module 2


Attribut d’ensemble sous‐tend la notion de oid

La notion d’ensemble pour l’attribut ar2:

En raison du lien multiple, le ar2 est un ensemble de oids se référant à autant

d’objets de la classe CA. L’implantation physique de cet ensemble dépend du

SGBD. En Oracle, cet ensemble prendra la forme d’une sous-table imbriquée de

oids par exemple. Avec d’autres, cela peut-être une liste, un bag,…


Exemple avec une association: (C) 1..* ‐ 1..1 (P)

Exemple : Cours‐Prof

Cours:

noC* : int

titreC :string

nbCred : int

Prof:

noP*:int

nomP :

gradeP:int

Enseigne 1..11..*

Avec Oracle, ce Mnav est inacceptable en raison de l’impossibilité de référer à un type incomplet via un lien multiple

Prof:noP* : int

nomP : string

gradeP : int

lesCours

Cours:noC* : int

titreC : string

nbCred : int

refProf

Page 36


Module 2


Mnav avec (C) 1..* ‐ 1..1 (P) : lien multiple

Prof:noP* : int

nomP : string

gradeP : int

lesCours

Cours:noC* : int

titreC : string

nbCred : int

Pour un professeur donné, il sera facile d’obtenir tous les cours dont il est responsable.

Prof:noP* : int

nomP : string

gradeP : int

Cours:noC* : int

titreC : string

nbCred : int

refProf

1- Avec un lien externemultiple:

2- Avec un lien externe simple:


Quelles sont les contraintes associées à l'ajout et à la suppression d'un cours / prof?

Avec le Mnav 1:

À l’ajout d’un cours:

Le cours ajouté doit être associé à un prof : pas renforcé dans le Mnav 1

À la suppression d’un cours:

Le cours est supprimé suivi d’une suppression dans lesCours.

À l’ajout et d’un professeur:

Ajout d’un prof implique l’ajout d’un ou plusieurs cours (contrainte de multiplicité).

Suppression: ‐ suppression de tous les cours enseignés par ce prof.

et ‐ suppression du prof.

Ces contraintes devront être implémentées dans une méthode de suppression qui prendra en charge la vérification de ces contraintes dans une même transaction.

Page 37


Module 2


CoursnoC* : int

titreC: string

nbCred : int

Etudiantmatricule:*

nom:string

Inscrit 1..*0..*

Association (C) 0..* ‐ 1..* (E) sans attribut d’association

Avec Oracle, la circularité des liens multiples interdit la définition des types lesCours et lesEtudiants. Donc le modèle ci-dessus doit être abandonné!

Etudiant:Cours: cours_tmatricule* : int

nom : string

lesCours

noC* :int

titreC : string

nbCred : int

lesEtudiants

La définition de 2 liens circulaires ne peut pas être faite si la classe cible renferme aussi une définition multiple inverse (voir type incomplet).

Solution 1:


CoursnoC* : int

titreC: string

nbCred : int

Etudiantmatricule:*

nom:string

Inscrit 1..*0..*

Association (C) 0..* ‐ 1..* (E) sans attributs d’association

Solution 2: Avec préférence de parcours: 1 liens multiple avec un nouvel attribut de type ensemble de REF .

Etudiant:Cours: cours_tmatricule* : int

nom : string

noC* :int

titreC : string

nbCred : int

lesEtudiants

>

Quels sont les matricules d’étudiant inscrits au cours 124?

La sélection du cours identifie les références les étudiants inscrits via le lien externe multiple.** Avec le lien multiple: l’attribut a le type d’un ensemble (Table of) de références vers les type etudiant_t

Page 38


Module 2


Afficher les cours suivis par un étudiant

Select c. noC

From Cours c

Where (select ref(e) from Etudiant e where e.matricule=123) IN

(select e.* from table(lesEtudiants) e );

NOC

50

n.b. Le 2e select fournit que les oids de l’ensemble lesEtudiants; il n’est nécessaire de faire une jointure et le unnesting car la projection implique que les oids.

Les oids de l’ensemble lesEtudiants


Quelques interrogations sur ce Mnav (2)

Select *

From Cours c

Where c.lesEtudiants is not empty; -- prédicat d’ensemble

NOC TITREC NBCRED LESETUDIANTS

50 Java 3 LESETUDIANTS_T(0000220208E938BD8BE15C46F3A8544ADB258D6A9E19FF34467AEE448EAF2B2D401B8701)

Select c.noC

From Cours c

Where c.lesEtudiants is not empty ; NOC50

Page 39


Module 2


Définition de cette structure en objet Oracle

Demo pour l’association 0..* ‐ 1..*

Create type etudiant_t as object (matricule varchar(10), nom varchar(50))

/

*** le lien multiple externe est spécifié comme un ensemble de références de type etudiant_t

Create type lesEtudiants_t as table of REF etudiant_t ‐‐ as SET OF refétudiant_t

/

Create type cours_t as object ( noC int, titreC varchar(50), nbCred int, lesEtudiants lesEtudiants_t)

/

Create table Etudiant of etudiant_t;

Create table Cours of cours_t Nested table lesEtudiants Store as Table_lesEtudiants ;


Suite …Les objets:

Insert into Etudiant values (etudiant_t(‘123’, ‘Luce’));

Insert into Etudiant values (etudiant_t(‘456’, ‘Jacques’));

Insert into Cours values cours_t(50, 'Java', 3, (lesEtudiants_t(

(select ref(e) from Etudiant e Where e.matricule = ‘123')

)

));

SQL> select lesEtudiants from Cours;

LESETUDIANTS

LESETUDIANTS_T(0000220208E938BD8BE15C46F3A8544ADB258D6A9E19FF34467AEE448EAF2B2C4D401B8701)

***************************************************

Select c.noC, c.lesEtudiants from Cours c;

NOC LESETUDIANTS

50 LESETUDIANTS_T(0000220208E938BD8BE15C46F3A8544ADB258D6A9E19FF34467AEE448EAF2B2C4D401B8701

Page 40


Module 2


Association: (C) 0..*‐ 1..* (E) Avec au moins un attribut à la classe‐association

Solution 3 : 2 liens simples imposés par la présence d’un attribut d’association

Recherche aussi possible si la classe-association a aussi les clés des classes externes concernées..

La classe CA, et les 2 liens s'imposent si l'association Inscrit a des attributs.

Etudiant: matricule* : string

nom : string

Cours: noC* :int

titreC : string

nbCred : int

Inscription: refEtudiant

refCours

dateInsc : DateAttribut de l’association


Recherche avec la classe d’association (avec notation pointée et lien simple)

Quels sont les matricules étudiants inscrits au cours 134FT en 2012?

Select In.refEtudiant.matricule

From Inscription In

Where In.refCours.noC = ‘134FT’ and In.dateInsc = ‘2012’;

Quels sont les cours suivis par l’étudiante Elise?

Select I.refEtudiant.noC

From Inscription I

Where I.reEtudiant.nom = ‘Elise’;

Quels sont les cours suivis par chaque étudiant inscrit dans la BD?

Select I.refCours.*

From Inscription I

Page 41


Module 2


Recherche avec l’attribut d’ensemble

Quels sont les matricules étudiants inscrits à aucun cours?

(Select e.matricule

From Etudiant e)

–

( Select Ins.refEtudiant.matricule

from Inscription Ins)

`


Est-ce que ce Mnav est spécifiable en objet?

Usine: usine_t

noU* : int

nomU : varchar

lesProduits

Produit: produit_t

noP* : int

leDepot

VilleDepot:villeDepot_t

nomV *:varchar

popV : int

maireV : varchar

La définition du lien multiple est possible dans ce modèle car les liens ne forment pas une boucle avec un lien multiple.

Est-il possible de supprimer un produit sans supprimer aucun autre objet?

Page 42


Module 2


Association 0..* ‐ 0..* avec un attribut pour l’association

Solution 1 (universelle) : une 3e classe avec le nom de l'association est formée avec les attributs de l'association, deux liens monovalués vers les classes participantes. Les multiplicités ne sont pas renforcées par le Mnav.

Le CA12 peut avoir un identifiant composé de as1 et as2 représentés dans le CA12.

Propriété de la classe association

C1

as1*C2

as2*

0..* 0..*

CA12

as3

C2:

as2*C1:

as1* CA12:as3

ar3

ar4

Un objet de C2 (:C2) non associé à un objet de C1 n’aura pas d’objet d’association du type CA12.

1..1


Recherche avec une classe d’association

Quels sont les C1 associés à une valeur clé k2 de C2?

1- recherche dans CA12

Select o.ar3.*, o.as3

From CA12 o

Where o.ar4.as2 = k2

C2:

as2*C1:

as1* CA12:as3

ar3

ar4

Quels sont les C1 non associés à un objet C2?

2- Les C1 moins les CA12:

Select x.* From C1

-- (moins)

Select o.ar3.*

From CA12 o

Where o.ar3 is not null;

Page 43


Module 2


Association 0..* ‐ 0..* avec un attribut (suite)

Solution 2: une classe interne avec un lien interne multiple et un lien externe simple.

La suppression d'une instance de C1 sous-tend la suppression de l'instance de CA12 associée.

Que donnerait: Select o.* from CA12 o?Un ensemble d’objets-colonnes CA12 exploitables en PL/SQL avec un curseur!

as2*

ar2

C1:as1*

CA12:as12

ar4 :

C2:


Exemple : Association UML 0..* ‐ 0..* avec attribut d’association

Depart

codeD*: int

nomD:string

Logiciel

codeLog*:int

nomLog:stringAchat

dateAchat:

0..*0..*

Les achats de logiciels distincts faits par un département sont représentés par la classe interne dont les éléments ont la structure achat_t . La suppression d’un logiciel fait disparaître toute l’information au sujet de son achat.

Logiciel:

codeLog* : int

nomLog : varchar

lesAchats

Depart:depart_t

codeD*: int

nomD: varchar

Achat :achat_tdateAchat : DaterefDep

1..1

Page 44


Module 2


Création de la base objet

Create type depart_t as object (codeD int, nomD varchar(50))

/Create type achat_t as object ( dateAchat Date, refDep REF depart_t)

/create type lesAchats_ as table of achat_t

/Create type logiciel_t as object (codeLog int, nomLog varchar(50), lesAchatslesAchats_t)

/Create table logiciel of logiciel_t nested table lesAchats store as Table_lesAchats;

Create table Depart of depart_t;

1* insert into Logiciel values(logiciel_t(100,'youpi', lesAchats_t(achat_t(sysdate,null))))


Interrogation de la classe externe: Logiciel

Important

Il est possible d’interroger ce modèle notamment les classes qui ont un containeur d’objets en propre (table).

Ainsi, il est possible d’interroger la table-objet Logiciel mais pas directement la classe interne qui correspond à des objets-colonnes imbriqués.

Select * from lesAchatsERROR at line 1:

ORA-00942: Table ou vue inexistante

Select lesAchats -- fournit les objets imbriqués.

from Logiciel

Page 45


Module 2


Affichage des objets de la classe interne

CODELOG NOMLOG LESACHATS(DATEACHAT, REFDEP)

100 youpi LESACHATS_T(ACHAT_T('14-09-16', NULL))

Select * from Logiciel -- fournit tous les objets y compris les imbriqués.

Affichage des données de la classe interne avec Unnesting:

Select L.codeLog, v.dateAchat

from Logiciel L, Table(L.lesachats) v

CODELOG DATEACHAT

1 1799


Fonction REF()

Une fonction essentielle pour établir le lien externe et permettre la navigation associative avec SQL : REF(x)

où x est un objet et la fonction fournit l’oid de cet objet.

*** ne pas confondre la fonction REF() et le type REF qui est le type oid

L’association entre deux objets de classes différentes A et B est établie avec la référence soit l’oid.

Page 46


Module 2


Fonction REF(): initialisation de l’attribut de type ref

Créer un objet A dont la valeur x = 15 avec une association avec l’objet B dont c=5 .

x* : int

w :

Insertion des objets associés:

Insert into B values (b_t( 5 , 10 ));

Insert into A values (a_t ( 15 , (select REF(b) from B b where b.c =5)));

* Lors du «parsing» du DML, il y a évaluation en priorité les expressions entre parenthèses.

A: B:c : int

d: int


Exemple comportant plusieurs classes navigationnelles

Modélisation des randonnées effectuées par des personnes qui visitent des lieux touristiques situés dans diverses régions.

Page 47


Module 2


Exemple d'une classe d'association participant à une autre association (solution universelle)

Rando:

noR* : intPersonne:

nasP*: int0.. * 0…*

RandoPerso:

lieuDepart:

dateDepart:

LieuTourist

lieuT*:string

regionT:

RL:

dateVisite:

prix: :real

1..*0..*

UML

Rando

noR*:intPersonne

nasP*: int

RandoPerso:

lieuDepart:

dateDepart:

refRando

refPersonne

LieuTourist:

lieuT: string

regionT: charRL:

dateVisite: Date

prix: real

refLieuTourist

refRandoPerso

Mnav

Tant que les classes Mnav sont concrétisées par des classes d'objets dotés d’un oid, la clé primaire n'est pas essentielle, mais utile pour la recherche des objets.

Les liens sont tous simples.

Ils sont traversés avec la notation pointée.

1..1

1..1


Quelques interrogations avec parcours par référence ?

Dans le choix de la transformation, il ne faut pas perdre de vue l’exploitation subséquente du modèle. Cela peut justifier la classe d’association.

Voici quelques clauses SQL pour interroger et mettre à jour cette base.

Quels sont les régions de départ pour les randos effectués par le randonneur dont le nasP est 3456?

Select rp.refRando.noR

From RandoPerso rp

Where rp.refPersonne.nasP = 3456;

Quels sont les lieux touristiques visités par le randonneur dont le nasP est 3456?

Select t.refLieuTourist.lieuT

From RL t

Where t.refRandoPerso.refPersonne.nasP = 3456; ‐‐ double indirection

Page 48


Module 2


Mise à jour du modèle RANDO avec les références

Le randonneur 3456 qui a quitté le 15‐09‐2010 n’a pas parcouru la région 5 mais la région 6. Une mise à jour s’impose.

Update RandoPerso rp set rp.refRando =

(select Ref(r) From Rando r Where r.noR = 6)

Where rp.dateDepart = to_date(2010‐09‐15 , ‘YYYY‐MM‐DD’)

and rp.refPersonne.nasP = 3456

and rp.refRando.noR = 5 ;

Remarque:

Dans ce Mnav, une randonnée d’une personne ne peut pas être ajoutée s’il n’y a pas aussi la visite d’un lieu touristique. Cela est imposé par la contrainte de multiplicité. Le Mnav ne renforce pas cette contrainte!


Pour l'association Modèle navigationnel

1..1 – 1..1 Un lien simple obligatoire

1..1 – 0..*(sans préférence de navigation) Un lien simple de enfant vers le parent

0..* - 1..* sans attributs 2 liens simples

0..* - 1..* avec attributs 2 liens simples + CA

Les contraintes non explicitées et renforcées par le Mnav le seront par les méthodes.

Les choix à privilégier pour les associations (Best Practices)

Page 49


Module 2


Association réflexive 1..1 – 0.. * Modèle Ouvrier spécialisé

OuvriernasO* : int

adrO : string

metierO: string

chef

Ouvrier 0..*

1..1

Solution 1 : 1 lien externe simple:

rôle

Ouvrier:ouvrier_tnasO*: intadrO: stringmetierO: stringrefChef

dirig

éPar

>

* Un chef est aussi un ouvrier

NB: Un chef est aussi un ouvrier


Lien simple et le suivi avec la notation pointée

• Quel est le chef de l’ouvrier 50?

Select o.refChef.nasO

From Ouvrier o

Where o.nasO = 50 (and o.refChef.nasO is null);

Quels sont les ouvriers dont le chef est 25?

Select o.*

From Ouvrier o

Where o.refChef .nasO = 25;

Quel est le chef du chef 25?Select o. refChef.nas.O

From Ouvrier o

Where o.nas = 25;

Ouvrier:ouvrier_tnasO* : intadrO : stringmetierO : stringrefChef

Page 50


Module 2


Select et Curseur PL/SQL

Quels sont les ouvriers dirigés par le chef 25

Select o.nas. o.metierO (1)

From Ouvrier o

Where o.refChef = 25;

(1) Un ensemble d’objets sera formé par le calcul de la réponse. Cet ensemble sera exploré par la suite avec une proc PL/SQL exploitant un curseur*.

*Curseur est l’équivalent du ResultSet. Cet espace permet de parcourir les objets un à un avec une proc PL/SQL.

Ouvrier:ouvrier_tnasO* : intadrO : stringmetierO : stringrefChef


Modèle à deux liens externes

Modèle exclu evec Oracle:

Ce Mnav ne peut pas être implémenté avec Oracle en raison de la présence dans le Mnav d’une boucle comprenant un lien multiple qui aboutit à un type incomplet (ouvrier_t).

Ouvrier:ouvrier_tnasO* : intadrO : stringmetierO : stringrefCheflesOuvriers

Page 51


Module 2


Ajout d’un ouvrier (25) et son chef (100) (modèle à un seul lien)

Ouvrier:ouvrier_tnasO*: intadrO: stringmetierO: stringrefChef

Avec ce modèle, un ouvrier qui est un chef réfère à lui-même.

Create type ouvrier_t as object(nasO int, adrO varchar(50), metierO varchar(50), refChef REF ouvrier_t);

Insert into Ouvrier values (ouvrier_t(25, 'rue des pignes', 'soudeur', null));

L’ouvrier 25 a l’ouvrier 100 comme chef:

Update Ouvrier o Set o.refChef =

( select Ref(x) From Ouvrier x where x.nasO = 100)

Where o.nasO = 25 ;


Insertion d’un ouvrier‐chef (nasO = 100) avec qui est chef

-- Insertion d’un ouvrier-chef dont le nasO = 100: (2 opérations)

Insert into Ouvrier values (ouvrier_t(100, 'rue des guignols', 'soudeur', null));

Insertion de son chef qui est lui-même:

Update Ouvrier o set o.refchef=

(select Ref(w) from Ouvrier w where w.nasO = 100);

Page 52


Module 2


Agrégation des classes


Agrégation : composition et partage

Agrégation de composition et de partage : ce sont d’abord des associations dotées de contraintes supplémentaires au regard de la suppression.

• Composition (forte) : la suppression de l'agrégat doit entraîner celle des instances agrégées (qui composent ..). Chaque instance du composant ne peut être qu’en association qu'avec une seule instance de l'agrégat. Donc pas de partage du composant!

• Faible (ou partagée) : la suppression de l'agrégat n'entraîne pas nécessairement celle d'un composant qui peut être éventuellement en association avec une autre instance de l’agrégat ou avec une entité d’une autre classe.

La représentation d'une agrégation :

• Soit par imbrication de la classe du composant dans laclasse composée (agrégat) avec des liens simples ou multiples;

• Soit par une classe composée reliée aux différentes classes (externes) avec des liens simples ou multiples externes.

Page 53


Module 2


Agrégation de composition forte

La suppression d'une instance de C1 entraîne celle des instances de C2 associées. Dans cet exemple la création de C1 peut ou pas se faire dans la même transaction que la création de C2.

Quel est le Mnav pour l'agrégation ci-dessous ?

Ordinateur:

noSerie: int

Ecran :

noEcr*:int

Disque:

noDisq*:int

0..*1..1

1..1

C1as1

C2as20..*1..1

C1

c2

as2

as1

ast1


Agrégation de composition pour une association 1.. * – 1..1 orientée

La suppression de C2 entraîne de facto celle des C1.

La suppression de C1 est possible mais s’il est le dernier, l’opération est refusée.

La composition sous-tend un accès par C2.

C1:as3:

C2:as2:

1..* 1..1 C2:

as2:

ar2:

C1:

as3:

as4

C2: as2 ar2

as3 as4

t90 10 as

23 sig

28 Low

R45 12 dig

Page 54


Module 2


Mnav pour l’agrégation avec 2 composants

Solution avec 2 liens internes :

La modélisation avec une agrégation forte sous-tend la suppression dans la BD de l’écran et des disques qui le composent lorsque l’ordinateur est supprimé de la BD.

De même un écran ou un disque ne peut pas être dans la base sans être associé à un ordinateur. Par contre, un ordinateur peut agréger qu’un écran (sans disque 0..* ).

Ecran:

noEcr*:

Ordinateur

noSerie*:

Disque:

noDisq*:

0..*1..1

1..1

Ordinateur:

noSerie*:

refEcran

lesDisques

noEcr*:

Disque:

noDisq*:

Ecran:


Quelle est la vision tabulaire de ce Mnav?

Ordinateur:

noSerie*:

refEcran

lesDisques

noEcr*:

Disque:

noDisq*:

fourn

Ecran:

Ordinateur noSerie refEcran lesDisques

noEcr noDisq fourn

2345 e34 D2 F1

D3 F2

34712 e89 D7 F2

D9 F1

D12 F4

562 E23 Null null

Dans cet exemple, tous les objets internes sont physiquement imbriqués dans la classe externe Ordinateur.

Page 55


Module 2


Composition forte avec une multiplicité de 0..1

En ajout: un écran est inscrit dans la BD sans obligation d’être associé à un ordinateur. Idem pour le disque.

Un ordi est fait de 0 ou 1 écran et de 0 ou plusieurs disques .

En suppression : enlèvement obligatoire, s’ils existent , de l'écran et des disques associés à l’ordinateur.

NB: Avec la composition, la suppression a priorité sur la cardinalité (0..1) ou (1..1). Résultat idem mais différent avec l’ajout.

Ordinateur

noSerie:int

Ecran

noE*: int

capaciteD:

marqueD:

Disque

noD: int

tailleE:

0..*0..1

0..1


Mnav de l'agrégation forte avec (0..*) avec deux classes externes

Gestion plus lourde avec l’agrégation forte

La suppression d'un ordinateur doit aussi entraîner la suppression de l'écran et des disques de la base. Ce sont des objets dans des containeurs distincts.

3 opérations de suppression sont nécessaires pour supprimer un ordi!!

Pour ajouter un ordi, 3 opérations d’ajout sont éventuellement nécessaires:

• ajout un objet ordinateur

• ajout d’un ou plusieurs objets (disque)

• ajout d’un objet écran

Ordinateur:

noSerie* : intlesDisquesrefEcran

Disque:noD*: int

capaciteD:

marqueD:

Ecran:noE*:int

tailleE:

Page 56


Module 2


Quelle est la vision tabulaire de cette agrégation?

Ordinateur: noSerie prix refEcran lesDisques

noEcr noDisq

34712 oid9 oid7

oid19

oid8

562 oid3 Null

Disque: noD capaciteD marqueD

(oid7) d67 456 Digital

(oid19) D5 897 LaCie

(oid8) D1 67845 IBM

Ecran: noE tailleE

(oid9) e9 760

(oid3) e8 1024


Agrégation partagée (ou faible) avec une multiplicité 1..*‐‐ 0..*

L’accès se fait sur C2 pour avoir accès à C1.

Le point d'entrée est C2:

La suppression de C2 ne doit pas entraîner automatiquement celle de C1 qui peut être partagée avec une autre occurrence de C2 (exclusion de l’intégration de C1 dans C2).

Exige éventuellement une mise à jour de ar2. Le partage de C2 est à vérifier de préférence par la méthode utilisée pour la suppression.

C1as1:

C2as2:

1..* 0..*

C2as2:

ar2

C1as1:

<

Page 57


Module 2


Sur la nature des réponses …

En cours d’exécution, une application ( browser, pgm Java, ….) peut obtenir du SGBD des données typées ou des objets.

La nature de la réponse dépendra des structures disponibles dans l’application pour stocker la réponse ainsi que des méthodes « invokées » en cours d’exploitation.

Si une application appelle l’exécution d’une méthode qui retourne des objets, l’application devra avoir généré les structures « natives » nécessaires pour les ranger et les manipuler.


Clin d’œil sur la Spécialisation/généralisationHéritage dans le DC‐UML

L’héritage est une notion qui réfère aux classes d’une hiérarchie et non aux containeurs des objets.

Page 58


Module 2


Héritage et ses propriétés dans le Mnav

L'héritage du Mnav se formalise avec la même sémantique que celle de UML; il est spécifié directement avec le schéma objet avec une clause DDL. L'héritage aura des propriétés : exclusivité (d), overlapping (o), total (c) et partiel (i). Chacune exprime une contrainte entre les classes spécialisées.

{complete, disjoint}

{incomplete, overlapping} : card(BDO) = card(C1) +card(C2) – card(C2) ⋂ card(C3)

{incomplete, disjoint}: card(BDO) = card(C1) + card(c1) + card(C2)

{complete, overlapping} : card(BDO) = card(c2) + card(c3) – card(c2) ⋂ card(c3)

Le Mnav conserve la notation UML pour l'héritage ainsi que ses caractéristiques.

C1

as1* : int

C2

as2: C3

as3:

{complete, disjoint} : card (BDO) = card(c2) + card(c3)

Le nombre d’objets dans leur containeur respectif de type C1 est égal au nombre d’objets de C2 plus ceux de C3

Remarque: cette hiérarchie n’exclut pas que des objets de type C2 et C3 cohabitent dans le même containeur que C1.


Héritage avec une association incidente : 1..1 et 1..1

Une association avec une superclasse est aussi l’objet d’un héritage spécialisé

{complete, disjoint}L’association Asso1-5 se fait avec une superclasse (concrète ou abstraite).

Comme il y a héritage, un objet de C5 peut-être en association soit avec un objet de C2 ou C3 via une REF

NB: cela en raison du « complete» pour l’héritage: C5 ne pas être en association avec un objet de type C1, mais peut l’être avec un objet de type C2 ou C3.

C1

as1* : int

C2

as2: C3

as3:

C5

as5* : int1..1 1..1Asso1-5

Page 59


Module 2


Mnav pour l’héritage impliquant une Ref sur une superclasse


L’attribut lesRefC5est une ensemble de références à des objets soit de C2 ou de C3.

** refC5 pourrait avoir aussi une contrainte propre comme par exemple une limite sur le nombre total d’objets référés peu importe sa nature.

C1

as1* : int

C2

as2: C3

as3:

C5

as5* : int

lesRefC5

C5 aura donc un ensemble de ref soit sur C1, soit sur C2 soit sur C3 selon la couverture de l’héritage.


Mnav pour l’héritage impliquant une ref sur une classe autre que la racine


L’attribut refC5 est une ensemble de références à des objets soit de C3 ou de C4.

Aucune référence à un objet de la classe C1 et C2 n’est alors autorisée.

C1

as1* : int

C2

as2: C3

as3:

C5

as5* : int

lesRefC5

C4

as6* : int

{i, d}

Page 60


Module 2


Conclusion

Le Mnav a pour but de visualiser plusieurs structures conduisant à l’objet et en évitant autant que possible les jointures explicites.

Renforcement par la structure:

Il permet aussi de renforcer par la structure même certaines contraintes du modèle, mais pas toutes. Les autres seront renforcées par les méthodes de l’interface.

Renforcement par les méthodes:

Les contraintes de multiplicité autres que les classiques, par exemple une contrainte de multiplicité du genre (0..5) , restent à être renforcées par la logique même des méthodes de l’interface.

Ces méthodes peuvent aussi s’appeler l’une l’autre afin de profiter de leur logique propre par le partage. La notion de transaction est sous-tendue dans la logique de la méthode. La transaction doit donc être définie dans chaque méthode.

Le Mnav met aussi en évidence la notion de type d’ensemble sans toutefois préciser s’il s’agit d’un ensemble ordonné ou pas: Varray() , le set ou la sous-table.


Commentaire sur le diagramme UML proposé pour le développement du logiciel au regard de celui des données

Un diagramme de classe pour le développement du logiciel se distingue de celui des données par le fait que la partie supérieure d’une classe, celle des données, est moins élaborée et surtout n’est pas obligatoirement persistante (à moins que le langage de développement le soit). Les langages de programmation persistants ne sont pas nombreux!

L’interface

C’est la partie des opérations qui correspond aux différentes fonctions ou procédures nécessaires pour exploiter les données. Ce sont les constituants du logiciel qui est l’objet d’un développement.

Page 61


Module 2


Modèle Navigationnel

Passage de UML au Mnav

Exercices


Fin

Documents

Modèle navigationnel (Mnav)