IMAFA O5 LOGO2 PARTIE I - users.polytech.unice.frusers.polytech.unice.fr/~hugues/BDR/LOG2/LOG2.pdf · Mise en œuvre sur mini-projet avec ... Domotique , immotique : SI Temps réel

IMAFA O5LOGO2

PARTIE I BASES DE DONNEES

RELATIONNELLES POUR LE WEB

SI 5 –MAM5 - MS IFI -MS IMAFA2010-2011

Anne-Marie Hugues, Philippe Salvan

[email protected]://www.essi.fr/~hugues/BDR/LOG2

V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 2BD Relationnelles

Sera complétée par SI5 - IFI: bases de données orientées objets IMAFA: informatique distribuée (xml ; .net)

Evaluation: Partie 1: sur Tds et projet réalisé en trinôme compte pour

50% de la note du module Partie 2 : examen sur table individuels et TPS en binômes


Objectifs de la première partie Connaissances:

Comprendre la nécessité de gérer la persistance des données.

Juger de l'adéquation d'un outil de modélisation.

Evaluer la pertinence de la localisation

des traitements des données sur architectures réparties (client/serveur et multi tier ).

Savoir faire: Concevoir

des bases de données relationnelles efficaces (normalisées).

Utiliser ORM et UML. Resin, Postgres

Programmer SQL(SGBD), Java (JSP, JDBC, EJB)


Agenda partie 1

Cours 5/10 : Conception de bases de

données relationnelles ORM (Object Role Modeling), AMH

12/10: Philippe Salvan Mapping objet /relationnel

26/10: Philippe Salvan Transactions et concurrence

d'accès aux données 2/11:Philippe Salvan

EJB

Mise en œuvre sur mini-projet avec Postgresql, resin et IHM web

4 séances de TD 19/10 : TD conception – 4h 26/10 : td- 2h remise d'un

rapport de conception de la bd au début du cours (0.25%) - Td création de la BD Sous Postgres,

2/11 : td – interrogation de la bd

9/11 : maquettage 16/11 et 24/11 : TD 4h codage mini

projet

Partie I : Conception de bases de données relationnelles

Introduction Conception de systèmes d ’informationOutils de modélisation : MERISE, UML

Dépendances fonctionnelles, Formes normales


informations

EnvironnementEntreprise

SIDonnées métiers

Informations véhiculées par

messagespermettant la

prise de décision

Pertinence; Efficacité; Robustesse; Evolutivité; Automatisme

Systèmes d’information définition et critères de qualité

Programmeset

Bases de donnéesDonnées de l’Application

Données de l’environnement

Acteur envoyant des événements

acteur


Systèmes d'informationFonctions?? exemples

Fournir l’information pertinente de manière transparente

mémoriser; retrouver ; déduire

mettre à jour ; gérer protéger l'intégrité

Refléter l’organisation (droit d’accès, . . . )

Supporter l’évolution du système (extensibilité)

Système de paye, reporting de stock, . . .=Systèmes de gestion

Applications bancaire, centrale d’achat, billetterie, . . .= Systèmes transactionnels

Bibliothèque, partage de code source, . . .= Système de documentation

Pages jaunes, Pages blanches, entreprise= Système d’annuaire


Systèmes d'information une histoire de tiers

Modèle 1–Tiers (Mainframe) Approche centralisée Manipulation physique des systèmes

Modèle 2–Tiers (Client / Serveur) Le serveur gère la BD Le client doit traiter l’information cf.TP1

Modèle 3 ou n–Tiers (Serveur d’application) Un serveur gère la BD Un (autre ?) serveur gère le traitement Le client s’occupe de l’interaction cf.TP2


Systèmes d'information une petite histoire

SI Gestion : Depuis années 60-70 Années 80: modèle relationnel, répartition des données Début 90s: rationalisation de la gestion, mode client serveur : ERP Depuis 95: vers le e-business, interopérabilité Groupware (lotus notes); Gestion Electronique de Documents Supply chain (logistique) ; Gestion du workflow Gestion de la relation client (CRM)

SI Décision Depuis 95: tirer profit des données accumulées Analyser de grandes masses de données, agréger

• Datawarehouse, datamining : BD + analyse de données (stats)

Domotique , immotique : SI Temps réel Knowledge management : Bases de données +Intelligence Artificielle

V 1.0 -- 05/10/11 © BD Relationnelles

Systèmes d'informationCloud computing

Les SI perçus comme un service les utilisateurs n'ont plus besoin

de savoir comment ça marche

Agilité, fiabilité, Performance garantie APIs Indépendant de la localisation

(web) Coûts en baisse, partage Scalabilité Maintenance facilitée


Les composants du SI

Organisation e t adm in istration

Techno log ieInd ividus


Les phases du SI - cycle de vie

Construction itérativeConception réfléchie;

viser les qualités

sus-mentionnées

Exploitation

Production

Conception

CodageChoix des supports physiquesDéfinition des droits d'accèsValidationAlimentation du SI

univers du discours Modèle de donnéesArchitecture logiciellePersistance?Interfaces

QualificationDéploiement, diffusionGestion réseauxSupport, évolutions

Définition

Recueil des besoins : (cahier des charges, scénarios)


Cas les plubo

L'entreprise LESPLUBO est spécialisée dans la confection et la vente de vêtements HOMME, FEMME, ENFANT. Son siège est localisé à Nice. On y trouve la direction générale, les locaux administratifs, des ateliers de découpe et d'assemblage de vêtements. La vente des vêtements se fait à travers un réseau de 500 boutiques localisées en France, ne proposant que des produits de la marque.

La marque LESPLUBO sort 6 collections Femme, 2 collections Homme ,2 collections Enfants par an. Chaque collection comprend 25 modèles au maximum, chacun dans 5 tailles différentes. Chaque modèle est proposé dans 5 couleurs différentes pour les collections Femme et 2 couleurs différentes dans les collections Homme et Enfant.

L'entreprise dispose d’un réseau Intranet reliant le siège aux boutiques et souhaite en profiter pour automatiser le processus de réapprovisionnement des articles vendus.

On désire également, gérer l'activité des vendeurs intra et inter-boutiques et fidéliser les clients. L'activité des vendeurs et des clients sera étudiée à la fois en terme de volume et de chiffre d'affaires


Cas les plubo: Règles (métiers) de réassortiment du stock

Les boutiques fonctionnent en mode push, c’est à dire qu’elles sont réapprovisionnées automatiquement en fonction de leurs ventes selon une politique définie par le siège et non pas selon des commandes dont elles auraient le libre choix.

Démarrage d’une collection Les boutiques sont classifiées en 5 catégories selon le niveau des ventes réalisées pendant les 2 dernières

années. Cette classification est prise en compte pour déterminer le nombre d'articles à livrer au démarrage de toute nouvelle collection Homme, Femme, Enfant.

Au démarrage de chaque collection, une boutique reçoit le même nombre d'articles pour chacune des couleurs retenues pour chaque collection. Le nombre d'articles pour les tailles 2, 3, 4 est le triple de celui pour les tailles 1 et 5.

Réassortiment Plutôt que de se placer dans une logique simpliste de remplacement de chaque article vendu-, l'entreprise

LESPLUBO veut exploiter le cycle de vie d'une collection pour que chaque boutique dispose d'un stock suffisant pour ne pas manquer une vente et ne pas créer un stock excessif préjudiciable à de bons ratios financiers.

Soit D la durée d’une collection exprimée en semaines. Le cycle de vie d'une collection est défini dans le schéma suivant:

Phase 1 , démarrage ,2 semaines : un article vendu est renouvelé par un article Phase 2 ,croissance(D-2 semaines) / 3 : un article vendu est renouvelé par deux articles Phase 3 ,maturité(D-2 semaines) / 3 : un article vendu est renouvelé par un article Phase 4 déclin (D-2 semaines) / 3 : deux articles vendus renouvelés par un article


Univers du discours :processus Identifier les acteurs

Qui utilise? Qui renseigne?

Identifier les scénarios (TOUS) Règles, procédures métiers

ex : règle de réapprovisionnement automatique Contraintes

ex : un vendeur ne travaille que dans une seule boutique Qualité de service

Temps de réponse, espace, logiciels imposés, authentification…


Univers du discours :Données Echantillon de données (cas de données)

étiquette produit annuaire téléphonique des boutiques Listing du personnel Chèques/cartes bleues/tickets de caisse clients

Résultats attendus, informations liste des meilleurs vendeurs facture

Objets métiers concrets ou abstraits,

ex : article, client ensembles d ’objets similaires

Entités, classes


Besoins de Modélisationdifférents niveaux

Niveau conceptuel : Définir et décrire les besoins

Niveau Logique : formaliser les besoins

Niveau physique : implémenter la formalisation


Description des traitements à réaliser : Approche fonctionnelle; objets contrôle; flots de données

MERISE (France) 1980: profondément installé : MCT MOT ; MCC UML : cas d'utilisation; diagrammes d'activités

Description de la dynamique; communication , comportement; UML :

Diagrammes Etats- transition ; diagrammes de séquence Description de la structure du système:

objets métiers ; données persistantes ; contraintes MERISE

MCD UML

Diagrammes de classes; diagrammes de composants;

Modélisation de SI: niveau conceptuel caractéristiques communes


MERISE Méthode de modélisation des SI

franco français (80) très liée à l ’approche BD relationnelles et modèle entités -

relations s ’appuie sur

cycle de décision (schéma directeur) cycle d ’abstraction (conceptuel/logique/physique) cycle de vie (va jusqu'au déploiement) renforce la séparation données - traitements

bien installée (surtout pour l'aspect données) en voie d ’être remplacée par UML?


informations comptes clients

chéquier et lettre ouverture

réponses

rejet ou acceptation

demande d'informations clients

demande infos ouverture cpte

renseignements

client

guichet

ServiceInformatique

Banque deFrance MCC

tâche

Conception de SI : MERISEaxe traitements : MCC,MCT, MOT

RaffinerL’Univers du discours

arrivéeclient

(1)

guichetlibre(2)

1 et 2

vérifier conditions clientsvérifier 500F(a)vérifier majeur (b)vérifier aval(c)

conditions initiales pas vérifiées a et(b ou c)

vérifier banque de france

OK KO

vérifier comptesvérifier client banquevérifier comptes clients

client connu KO client connu OK client inconnu

rejetmanuel

condinitiales

satisfaites

rejetBanque

déjà client(1)

nouveauclient

OK BDF(2)

interditbancaire

1 et 2

ouverture de comptecréer nouveau comptedemander chéquieréditer lettre

lettre

chéquier

compteouvert

demandechéquier

émission chéquiers

PROCESSUS OUVERTURE DE COMPTE

Réalisation

Analyse fonctionnellePériode client guichet service info bdf Type

arriveeclient

remise formulairet Manuel

dechargement batcht le soir Temps différé

analyse interdits bancaires

KO OK

t +1 le matin Automatique

lettre

formulaire

analyse client

connu KO connu OK inconnu

t Interactif

formulairerempli

rejetlitige

1 ou 2

ouvertureouverture comptedemande chéquierédition lettre

Automatique

clientconnu

(2)

listeinconnus

listeinconnus

retours

rejetinterdit

bancaireclient ok

(1)

chéquier

édition chéquierhebdomadaire Temps différé

demandechéquier

comptes

Deploiement

Execsupport

ARTICLECLE_ARTICLECLE COLLECTIONNUMERO ARTICLETAILLE ARTICLECOULEUR ARTICLEPRIX

CLE CLIENTPRENOM CLIENTNOM CLIENTADRESSE CLIENTMONTANT ANNUEL EN COURSMONTANT ANNUEL PRECEDENT

CLIENT

COLLECTION

CLE COLLECTIONANNEE COLLECTIONGENREDATE DEBUTDUREE

BOUTIQUENUMERO_BOUTIQUEADRESSE_BOUTIQUECATEGORIE_BOUTIQUECA_ENCOURSCA_MOINS1CA_MOINS2

VENDEURNUMERO_VENDEURNOM_VENDEURPRENOM_VENDEURNB_ARTICLES_VENDUSCA_REALISE

VENTESNUMERO_FACTUREECLE_CLIENTNUMERO_BOUTIQUENUMERO_VENDEURDATE_FACTUREMONTANT_FACTURE

CONCERNERNUMERO_FACTURE

CLE_ARTICLEQUANTITE

LIVRERCLE_ARTICLENUMERO_BOUTIQUENOMBREDATE_LIVRAISON

MOT


Modèle Conceptuel de Communication MERISE

informations comptes clients

chéquier et lettre ouverture

réponses

rejet ou acceptation

demande d'informations clients

demande infos ouverture cpte

renseignements

client

guichet

ServiceInformatique

Banque deFrance


arrivéeclient

(1)

guichetlibre(2)

1 et 2

vérifier conditions clientsvérifier 500F(a)vérifier majeur (b)vérifier aval(c)

conditions initiales pas vérifiées a et(b ou c)

vérifier banque de france

OK KO

vérifier comptesvérifier client banquevérifier comptes clients

client connu KO client connu OK client inconnu

rejetmanuel

condinitiales

satisfaites

rejetBanque

déjà client(1)

nouveauclient

OK BDF(2)

interditbancaire

1 et 2

ouverture de comptecréer nouveau comptedemander chéquieréditer lettre

lettre

chéquier

compteouvert

demandechéquier

émission chéquiers

PROCESSUS OUVERTURE DE COMPTE

Modèle Conceptuel des Traitements MERISE


modèle logique Access,



CLIENT

COLLECTION






CLE_ARTICLEQUANTITE


Collection femme

clientVendeur de la boutique

Costume homme taille 5

Dictionnaire des donnéesdépendances fonctionnelles

Analyse des domaines

Conception

Conception de SI :MERISE structure,données, objets métiers

1,n

1,n

1,1

1,n

0,n

1,n0,n

1,1

0,n

1,11,1

1,n

article

clé articlenuméro articletaille articlecouleur articleprix

boutiquenuméro boutiqueadresse boutiquecatégorie boutiqueCA encoursCA moins1CA moins2

clientclé clientprénom clienttel clientnom clientprénom clientadresse clientmontant annuel en coursmontant annuel précédent

collection

clé collectionannée collectionnuméro collectiongenre

date débutdurée

vendeurnuméro vendeurnom vendeurprénom vendeurnb articles vendusCA réalisé

ventesnuméro facturedate facturemontant facture

acheter

concernerquantité

faire partie

livrernombredate livraison

réaliser

se situer

MCD Merise

a r r iv é ecl i e n t

(1 )

g u ic h e tlib r e(2 )

1 e t 2

v é ri f i e r co n d itio n s cl i e n t své r ifie r 5 0 0 F ( a )vé r ifie r m a je u r ( b )vé r ifie r a va l( c )

c o n d i t i o n s in it i a le s p a s vé r if ié e s a e t( b o u c )

vé r ifie r b a n q u e d e f r a n c e

O K K O

v é r ifi e r co m p t e své r ifie r cli e n t b a n q u evé r ifie r co m p t e s clie n t s

cli e n t co n n u K O cli e n t co n n u O K cli e n t in c o n n u

re je tm a n u e l

co n din it ia l e s

s a t i sf a it e s

re je tB a n q u e

d é jà cl i e n t(1 )

n o u v e a ucl i e n t

O K B D F(2 )

in te rd itb a n c a ir e

1 e t 2

o u v e rt u r e d e co m p t e

cr é e r n o u v e a u co m p t ed e m a n d e r ch é q u ie ré d it e r le tt r e

le t t r e

ch é q u ie r

co m p t eo u ve r t

d e m a n d ec h é q u ie r

é m is s io n c h é q u ie r s

P R O C E S S U S O U V E R T U R E D E C O M P T E

Execsupport

L’univers du discours


Modèle Conceptuel des Données MERISE

1,n

1,n

1,1

1,n

0,n

1,n0,n

1,1

0,n

1,11,1

1,n

article

clé articlenuméro articletaille articlecouleur articleprix

boutiquenuméro boutiqueadresse boutiquecatégorie boutiqueCA encoursCA moins1CA moins2

clientclé clientprénom clienttel clientnom clientprénom clientadresse clientmontant annuel en coursmontant annuel précédent

collection

clé collectionannée collectionnuméro collectiongenre

date débutdurée

vendeurnuméro vendeurnom vendeurprénom vendeurnb articles vendusCA réalisé

ventesnuméro facturedate facturemontant facture

acheter

concernerquantité

faire partie

livrernombredate livraison

réaliser

se situer

MCD Merise


Modèle Logique



CLIENT

COLLECTION






CLE_ARTICLEQUANTITE



Modèle Organisationnel des Traitements MERISE

Période client guichet service info bdf Type

arriveeclient

remise formulairet Manuel

dechargement batcht le soir Temps différé

analyse interdits bancaires

KO OK

t +1 le matin Automatique

lettre

formulaire

analyse client

connu KOconnu OKinconnu

t Interactif

formulairerempli

rejetlitige

1 ou 2

ouvertureouverture comptedemande chéquierédition lettre

Automatique

clientconnu(2)

listeinconnus

listeinconnus

retours

rejetinterditbancaire

client ok(1)

chéquier

édition chéquierhebdomadaire Temps différé

demandechéquier

comptes


Analyse fonctionnelle

Conception

Conception de SI en UML : modélisation des traitements

livrer

commander

fabriquer

John Doe : Consumer

Banking Screen : AccountApplet

User : UserServant Account : BankAccountServant

1: init( )

2: enter name, password

3: ok_Action

4: checkAccount(String, String)

5: getFullName( )

6: getAccount(String)

7: AcctNumber( )

9: Balance( )

8: Type( )

Raffiner

stop

Event 1State 1 State2

Event2

Simulation

L’Univers du discourstâche

diagramme états transitions;

Cas d’utilisation

diagramme de sequence;


diagramme de composants

Collection femme

Van

Vendeur de la boutique

Costume homme taille 5

Objets métiers; contraintes; (OCL)


Exec

collection

Homme Femme Enfant

Conception

support

RealisationCode

Conception de SI en UML : structure,données,objets métiers

Deploiement

stop

Event 1State 1 State2Event2


Diagramme de classes,


La recherche des dépendances fonctionnelles permet de normaliser la base de données


Code

Conception de SI : analyse conceptuelle des données

df1 = N0coll,type Date début colldf2 = NoVendeur,N0Boutique MtTotal

Dépendances fonctionnelles



Données persistantes, Schéma relationnel Normalisation par synthèse avec MERISE (ou UML),

Etablir le dictionnaire des données Etablir l'ensemble des dépendances fonctionnelles

sous forme d'une couverture canonique. En déduire

les entités et leurs attributs (tables) Pour chaque dépendance X A, on crée une table par projection sur

les attributs XA où X est la clé les relations entre entités (clés étrangères)

Exprimer les contraintes non fonctionnelles dans un fichier texte

Vérifier que la base est en 3NF (ou BCNF)


Dictionnaire des données, cas lesplubo Année collection sur 4 chiffres No de collection sur 1 chiffre (1à 6) Genre de la collection: une lettre (H, F, E) No du modèle dans la collection 2 chiffres No de la taille sur un

chiffre (1 à 5) Référence de la couleur : chiffre de 1à 3 Nom de la boutique et l'adresse de livraison La taille de l'article La catégorie de la boutique Le niveau de ventes réalisé par une boutique Identification du vendeur (nom, prénom, date naissance et/ou no

vendeur) identification de la boutique (numéro de boutique et adresse) où

a lieu la vente nombre d'articles vendus et prix de vente de chaque article pour

pouvoir calculer le montant de la vente Identification client : Nom, Prénom, Adresse du client, et/ ou

numéro client (n° carte fidélité) Le volume (en francs) des achats de chaque client

Quelques contrainteson suppose qu'un vendeur ne travaille que dans une seule boutique à la fois

les règles de réapprovisionnement définies dans l'énoncé

une vente n'est réalisée que par un seul vendeur et concerne un seul client


Dépendance fonctionnelle : Définition formelle

Soient r une instance de la relation R, X et Y deux sous-ensembles d'attributs de R.

On dit que r satisfait la dépendance fonctionnelle XY et l'on note r | XY

ssi.t1r t2r (t1.X = t2.X t1.Y = t2.Y ).

Si r satisfait plusieurs dépendances fonctionnelles, df1, df2, ..., on note alors : r | df1, df2, …

La contrainte X est toujours satisfaite. La contrainte X signifie que la projection de la relation r sur X est

constante


Inférences de dépendances fonctionnelles; couverture

Réflexivité | XX

Augmentation XY | XZY

Additivité XY, XZ | XYZ

Projectivité XYZ | XY

Transitivité XY, YZ | XZ

Pseudo-transitivité XY, YZW | XZW

Eliminer la redondance.

Représenter ces dépendances sous une forme minimale.

établir une couverture canonique de dépendances fonctionnelles

se doter d'un outil de "déduction" de dépendances.


Exemple : le cas lesplubo

Quelques dépendances vérifiées par les donnéesdf1 = Année,NoColl,Genre,NoModèle,Taille,Couleur Stock, PrixVentedf2 = NumBoutique AdresseBoutique

df3 = Numvendeur Numboutique, Montant

autres dépendances "déduites" (redondantes ). exemple :

df4 = Numvendeur Adresseboutique df1 = Année,NoColl,Genre,NoModèle,Taille,CouleurStock


Formes Normales. Simplifier (?)

les relations d'un schéma les rendre "indépendantes".

Faciliter la compréhension, Eliminer les redondances, Améliorer

les aspects incrémentaux la distribution en des sites

répartis.

1ère forme normale : valeurs des attributs atomiques

2ème forme normale: aucun attribut non clé ne dépend

fonctionnellement d ’une sous clé 3ème forme normale:

aucun attribut ne dépend fonctionnellement d ’un attribut non clé

Boyce Codd NF chacun des attributs ne dépend

fonctionnellement que des clés pas toujours possible de décomposer

une relation en un schéma équivalent composé de relations en BCNF


Normalisation par synthèse Exemple

Quelques dépendances vérifiées par les donnéesdf1 = Année,NoColl,Genre,NoModèle,Taille,Couleur Stock, PrixVentedf2 = NumBoutique AdresseBoutique

df3 = Numvendeur Numboutique, Montant

Relations déduitesArticle(Année,Nocoll,Genre,Nomodèle,Taille,Couleur,Stock, PrixVente)

Boutique (Numboutique, Nomboutique, AdresseBoutique)

Vendeur (NumVendeur, NumBoutique, Montant, Volume)


SchémaCours (NoCours, NomProf, Libéllé)

Profs (NomProf, Dept)

Département (Dept, Immeuble)

Batiments(Immeuble Adresse)

Inscription NoCours, NoElève)

Élèves (NoElève NomElève, Cursus)

Normalisation par synthèseExemple

Dépendances minimalesNomProf DeptDept ImmeubleNoCours, NoElève Inscription Immeuble AdresseNoCours NomProf , LibélléNoElève NomElève, Cursus

Contraintes Un professeur est responsable de

3 cours au plus Un élève est inscrit dans 10 cours

au plus et 5 cours au moins


Normalisation par décompositionsur modèle de BD déjà réalisé

Exemple Schéma1 pas 2NF

Représentant( Nom, Entreprise, Adresse)Entreprise Adresse

pas en 2ème forme normale redondances, le même couple (Entreprise_x,

Adresse_y) va apparaître autant de fois que Entreprise X apparaîtra.

Schéma2, en 2NFReprésente( Nom , Entreprise) Localisé( Entreprise, Adresse)

oùReprésente= πNom, Entreprise(Représentant)Localisé= πEntreprise Adresse (Représentant)

La table originale Représentant peut alors être retrouvée par la formuleReprésentant = Représente▷◁ Localisé

Pour ne pas perdre d'informations il faut :

pouvoir reconstruire la table initiale par jointure

pouvoir reconstituer les contraintes initiales portant sur cette table.


Normalisation par décompositionExemple2

Schéma1 non 3NFlocal(Prof, Dept, Immeuble)avec Prof DeptProf ImmeubleDept Immeuble

n'est pas en 3NF, puisque Prof est la seule clé et que (3) est une dépendance concernant des attributs nonclés.

Couverture non minimale

Pour normaliser, il suffit de remplacer local par les deux relations obtenues par projection :Profs (Prof, Dept)Departement(Dept, Immeuble).

La table originale local est la jointure de ces deux tables.


Conclusion Etude des dépendances fonctionnelles

formelle, peu intuitive peu éloquente pour non matheux, loin du langage naturel possibilité de dérivation d ’un schéma normalisé si couverture

canonique ne suffit pas à tout exprimer

Introduction d ’une méthode d ’analyse ORM : Object Role Modeling plus intuitive, plus expressive fournissant méthode de dérivation automatique


Modélisation des SI: modélisation des données avec ORM

La méthode ORM (Object Role Modeling intervient en amont du modèle conceptuel de données de

MERISE ou du diagramme de classes UML permet de traduire directement dans un formalisme

approprié la notion de rôle et d'objets présents dans l'univers du discours ou encore dans les scénarios UML

ainsi que les contraintes s'appliquant sur ceux ci. La méthode ORM s'applique essentiellement à la

modélisation de données persistantes.



Conception

Code

Conception de SI : Analyse des données avec ORM

Collection

Homme Femme Enfant

Objets, rôles, faits élémentaires




CLIENT

COLLECTION






CLE_ARTICLEQUANTITE


Analyse des donnéesavec ORM (et UML) à l'aide d'un exemple

Cas d ’utilisation et Faits élémentairesPrédicats; rôles

ContraintesSous typage


Etude de cas: réservation voyages web

On se propose de réaliser un logiciel de réservations d'hôtels et d'avions à destination d'un usager du web. On prévoit plus tard d’intégrer les réservations de voitures.

Carte de fidélisation : tout usager peut adhérer à un programme de fidélisation lui ouvrant un compte personnel comportant ses informations personnelles, ses dossiers en cours, les points accumulés. Il reçoit un numéro de carte et un mot de passe.


logiciel de réservation web Réservation : Un usager devra pouvoir parcourir la liste des possibilités en fonction

de sa destination, de la qualité de service souhaitée (nombre d'étoiles d'un hôtel, option non-fumeur, classe affaire en avion, option menu végétarien ...). Les possibilités affichées devront tenir compte des disponibilités en temps réel. Il doit pouvoir réserver pour une ou plusieurs personnes, avec des tarifs spéciaux le week-end, ainsi que pour les juniors (moins de 25 ans) et les seniors (plus de 60 ans). La réservation est soumise à vérification comptable.

Plusieurs types de paiements sont possibles : carte bancaire, chèque, virement, ou points obtenus par fidélisation. Il devra recevoir par fax ou mail une confirmation de sa réservation récapitulant tous les services obtenus, avec un détail de ses points de fidélisation acquis, et un numéro de dossier lui permettant d'effectuer des modifications par la suite.


logiciel de réservation web Consultation et modification du dossier : L'usager devra pouvoir consulter la liste

de ses réservations en cours en donnant son numéro de dossier. Toute annulation implique le paiement des frais de dossier pour une somme dépendant de la distance à l'échéance (plus de 30 jours, 15 jours, 8 jours, no-show). Un no-show est un passager qui ne se présente pas avant l'heure de réservation (hôtel ou avion). Toute modification entraîne également des coûts forfaitaires. Il faut également générer un récapitulatif comptable de ces coûts.

Administration : On réalisera une interface simple à destination des hôteliers et compagnies aériennes permettant de modifier les disponibilités en fonction d'aléas et récapitulant les réservations sur plusieurs critères de tris (par jour, semaine, mois, par catégorie, par type de clients).


Etape1 : Univers du discours Recenser les cas d’utilisation du problème

Acteurs Scénarios

Recenser pour chaque cas les données utilisées modifiées et produites -> dictionnaire des données

Identifier leur structure , si possible étudier la structure des fichiers, états existants

ORM fournit un cadre pour l'analyse des données : "cas d'utilisation pour les données"


Etape1 : Univers du discoursRecenser les cas d ’utilisation

Acteurs : toute personne ou système interagissant avec le produit

Internaute, usager, client, gestionnaires, système comptable Un acteur primaire est celui qui impulse le cas d'utilisation

Pour chaque acteur décrire brièvement ce qu'il attend/produit du système , on identifie les cas d'utilisation de plus haut niveau qui seront décomposés par la suite

Réserver, consulter, gérer…


Internaute

Gestionnaire HotelsGérer Hotels

Client fidélisé

Client

Administrateur site de réservation

Gérer Suivi Résa

Gestionnaire Fidélité Gérer Fidélité

Gestionnaire VolsGérer Vols

Système comptableGérer Session Internaute

Cas d'utilisation de plus haut niveau


Etape1 : Univers du discours CU Gérer Session Internaute : Scénario informel

L'internaute peut réserver sur le site web des vols secs ou des nuits d'hôtels pour un ou plusieurs voyageurs, à partir de critères de choix. Pour ce faire il doit obligatoirement s'identifier et donner ses moyens de paiement. Le système lui renvoie un numéro de réservation et mémorise sa commande.

L'internaute peut vouloir modifier une réservation faite précédemment ou l'annuler.

L'internaute peut s'abonner à programme de fidélisation et bénéficier d'avantages particuliers.


Etape1 : Univers du discours CU Gérer Session Internaute : Décomposition en sous cas d'utilisation

Gérer Session Internaute

Réserver

Consulter Réservation

Gérer Fidélité

<<include>>

<<include>>

<<include>>


Etape1 : Univers du discours CU Réserver : Scénario informel

L'internaute choisit de consulter les horaires et disponibilités de vols secs, ou de nuits d'hôtels.

Le système indique les réponses à sa requête sous forme de liste de résultats.

L'internaute peut visualiser les informations propres à chaque objet de la liste et réserver pour un ou plusieurs voyageurs. Cette réservation est mise dans un panier d'achats.

L'internaute peut ensuite réserver autre chose, qui s'ajoutera à son panier d'achats.

Quand il a fini, il valide son panier d'achats et il doit alors obligatoirement s'identifier et donner ses moyens de paiement pour que sa commande devienne effective. Le système comptable valide la commande.Le système renvoie un numéro de dossier contenant toutes les réservations du client et mémorise sa commande.


Etape1 : Univers du discours CU Réserver : Décomposition en sous cas d'utilisation

Enregistrer/Modifier InfosclientPayerRéserver HotelRéserver Avion

<<include>>

Réserver

<<include>> <<include>><<include>>


Etape1 : Univers du discours CU Payer : Décomposition en sous cas d'utilisation

Payer

Payer par chèque

Payer par pointsPayer par CB

Payer par Virement


Etape1 : Univers du discours CU Gérer Session Internaute, vue globale

Gérer Session Internaute

RéserverConsulter Réservation

<<include>><<include>>

Gérer Fidélité

<<include>>

Enregistrer/Modifier Infosclient

<<include>>

Réserver Avion Réserver Hotel Payer

Payer par chèque

Consulter par no de dossierConsulter par client

Payer par CB Payer par Virement

Consulter Fidélité

<<include>>

Payer par points

<<include>> <<include>>

<<include>>

<<include>>

<<include>>


Cas d'utilisation Gérer Suivi Réservations

Ce use case sert de "back office" au use case "gérer session internaute.

Il envoie les mails ou fax au client pour confirmer les réservations.

Il confirme les réservations lors des réceptions de chèque par l'administrateur du site de réservation.

Il relance les clients n'ayant pas envoyé de chèque une semaine après leur réservation prévenant que celle ci est devenue caduque.

Il rembourse les clients en cas d'annulation, déduction faite des frais de dossiers en liaison avec les services comptables.


Cas d'utilisation Gérer Suivi Fidélité

Ce use case élabore les cartes de fidélité et les envoie au client. Ce use case permet également au gestionnaire de fidélisation de

décider des promotions, de faire des statistiques, d'établir les tarifs en nombre de points fidélité, de décider des nombres de points de fidélité attribués pour chaque achat....


Cas d'utilisation Gérer Hôtels, Gérer vols…

Gérer hôtels Ce use case permet au gestionnaire hôtels de définir ses

disponibilités, de modifier ses tarifs.., d'obtenir des statistiques....

Gérer vols Ce use case permet aux compagnies aériennes d'actualiser

leurs plans de vols, leurs tarifs, leurs promos.. Gérer parc automobile

Sera traité ultérieurement


Etape1 : Univers du discours Etablir le dictionnaire des données

Comment? Recenser les données nécessaires/produites en

relisant/écrivant tous les scénarios associés à chaque cas d'utilisation

Identifier les données existantes déjà formalisées Tables, fichiers, documents, annuaires, répertoires…


Etape 1: Recenser les données nécessaires/produites en relisant les scénarios; ex: CU Réserver Hôtel

Scénario typique L'internaute recherche un hôtel en entrant des

critères de choix, le système retourne une liste hôtels correspondants

L'internaute prépare sa réservation en donnant le nombre de nuits et le nombre de voyageurs, le système retourne le prix à payer et propose à l'internaute de valider

L'internaute valide sa réservation qui est ajoutée au panier d'achats et notifiée au gestionnaire d'hôtels.

DONNEES en ENTREE : Hôtels et critères de choix, nb nuits, voyageurs

DONNEES en SORTIE: Réservation hôtels, Panier d'achat, Hôtels

Réserver Hotel

Rechercher un Hotel

<<include>>

Préparer Réservation Hotel

<<include>>

ValiderReservationHotel

<<include>>


Etape1 : Identifier les données existantes déjà formalisées

Exemple : table des vols des compagnies adhérentes

Chaque vol a un tarif différent en fonction du jour et du pays de départ. Le tarif varie en fonction de la catégorie du passager.

Chaque vol est accessible a certaines classes de voyageurs Une catégorie de passager peut accéder à certaines classes

NoVol Jour HDepart HArrivée VilleDépart Ville Arrivée Places

Totales

AF310 Q 9h30 10h45 Nice Paris 150

AF510 L 10h00 14h Nice NewYork 300

……


Recenser les données nécessaires/produites en relisant tous les scénarios

Panier d'achats, Liste résultat, commande, dossier , réservation d'hôtel, réservation de vol, identification client, identification passager, carte fidélité….

Identifier les données existantes déjà formalisées Horaires des vols (table existant dans chaque compagnie) et places

disponibles dans chaque classe Planning des chambres avec leur type Catégorie passager permettant de bénéficier de tarifs réduits Tarification hôtels en fonction de la période Tarification vol..

Etape1 : Univers du discours Etablir le dictionnaire des données persistantes


Etape1 : Univers du discours Etablir la structure des données

Comment modéliser les liens entre les données? UML : classes et associations Modèle relationnel: tables et clés étrangères ORM: pas de structure a priori, organisation

grâce aux faits élémentaires


UML : classes et associations

VolNoVolDateHeureDepartHeureArriveeVilleDepartVilleArriveePlacesDisponiblesStatut

TarifPrixenFPrixen$Prixen£

Possibilité de définir ici les opérations s'appliquant sur Vol

Remarque: il vaudrait mieux associer le tarif de base à un trajet


Vol

NoVoldate

PKPK

Heure DepartHeure arrivéeVilleDépartVille ArrivéePlacesDisponiblesStatut

Tarif

NoTarifPKFK Tarif

Schéma Relationnel :Tables et clés étrangères


ORM UML Entité relation

Entité classe métier Entité

Valeur Type de données Type

— * Attribut Attribut

relation unaire — ** — **

Relation binaire (et plus) Association rel. bin.seule

Objets imbriqués Association class —

Co-reference § Association qualifiée. —

type d'objet

* relation type ** attribut booléen § incomplètement couvert

ORM : notation orientée par les faits élémentaires


Etape 1 : ORM lister les faits élémentaires

Langage naturel Le vol ayant pour no AF310 décolle de

Nice à 9h30 Le vol ayant pour no AF310 est complet

Assertion Un objet a une propriété ou un rôle Un ou plusieurs objets dans une relation

Le fait ne peut être éclaté en faits plus simples sur même objet sans

perte d'information Pas de regroupement en structure

NICE

N0 AF310


Quelques faits élémentaires Un dossier de réservation peut regrouper plusieurs réservations (avion ou hôtel) Un dossier de réservation concerne un client (fidélisé ou pas) Un client possède un nom, un prénom, une adresse, un email Un client fidélisé est un client qui possède en outre un numéro de carte de fidélité et

sur lequel on connaît d'autres critères (âge, RIB, catégorie socio professionnelle…) Une réservation d'hôtel concerne un hôtel et une ou plusieurs chambres d'un type

donné pour une ou plusieurs nuits Un hôtel de catégorie X possède Y chambres disponibles de type Z au tarif T Une réservation d'avion concerne un ou plusieurs passagers appartenant chacun à une

catégorie donnée (senior, couple..) sur un vol donné. Un vol propose un certain nombre de place disponibles pour une classe donnée

(économique, affaires, business..). La classe C (économique) est accessibles aux passagers de la catégorie CC (junior,

sénior, couple..)


Rôles et Objets ORM Rôle d'ORM unifie

concepts UML terminaison d'association attributs

Objet ORM unifie les notions

entité valeur


Etape 2 : ORMdiagramme des faits élémentaires

VOL(N°)

valeur

Ville

Décolle deEst complet

Identifiant, clé

HeureDepart

Décolle à

Objet, entitéPrédicat unaire,

Prédicat binaire

rôle: utilise/est utilisé

Mais est ce bien vrai dans notre exemple?


Etape 2 : ORMdiagramme des faits élémentaires

Vérifier la cohérence sur l ’échantillon de données

VOL(N°)

Ville

Décolle deEst complet

HeureDepart

Décolle à

AF310

Nice

9h30


Etape 3 : ORMCombiner les entités (objets) qui apparaissent dans plusieurs cas d ’utilisation (de données)

Les rendre cohérentes Exemple: commande et dossier

Vérifier celles qui peuvent être déduites et les marquer d’un *

Exemple : durée de vol; heure de départ, heure d'arrivée

Les données redondantes seront par la suite contraintes à être cohérentes


Etape 4Contraintes unicité

Vol

NoVol

Date

Compagnie(CodeCompagnie)

Le triplet constitué par le code compagnie, le numéro de vol et la date constitue un identifiant de l'objet vol

P

a

Vole à

Est affrété

Un vol est affrété par une seule compagnie, a un seul no de vol, vole à une seule date


Etape 4Contraintes unicité

Passager

(No Passeport)

a /

a /

a /

NomPassager

PrenomPassager

DateNaissance

U

Un passager est identifié par son numéro de passeport mais le tripletNom+Prénom+DateNaissance est unique


Etape 4Contraintes unicité, arité

Vol

est accessible

Classe(Code)

Chaque couple Vol/Classe est uniqueP


Etape 5Contraintes , obligation

Passager

(No Passeport)

a /

a /

a /

NomPassager

PrenomPassager

DateNaissance

U

Les valeurs Noms, Prénoms, DateNaissance sont obligatoires


a

Nombre de places dispo

Etape 6Objectivisation

Vol

est accessible

Classe(Code)

Comment faire si on veut indiquer le nombre de places disponibles sur un vol dans une classe donnée

P

"Dispoparclasse"

Réponse : Objectiviser "est accessible" pour pouvoir lui attribuer un rôle


Etape 7Autre contraintes

Vol

est accessible

Classe(Code)

Ensemble de valeurs

P

{'Affaires','Première','Economique'} Taux{ '10' .. '90' }

a pour reduction

concerne

CategoriePassager(code)

LibelleCategorie

{ 'junior' .. 'senior' }

se nomme


Etape 7Autre contraintes : sous typage

Un dossier est payé par un moyen de paiement

Dossier(Numero)

payé parMoyenDePaiement

(code)

CB(NumeroCarte)

Points !(nbpoints)

RIB !(NumeroRib)

Chèque(nocheque)

Dateexp

a

EstRecu

Un moyen de paiement est une carte, un chèque, des points, un virement par RIB



Vérifications finales Contraintes

non réflexivité (irreflexivité) exclusivité (exclusive or) ensembles inclus dans d'autres...


Modèle final Ne pas hésiter à multiplier les vues pour simplifier la

lecture Ici 3 vues

Internautes Hotels Vols


Client(NumeroClient)

Dossier(Numero)

payé par /is of MoyenDePaiement(code)

MontantTotalcoute

Carte(NumeroCarte)

NomClient PrénomClient Adresse

a /is of a /is of a /is of

Email

has /is of

has /is of

TelClient

a

InfosComplementaireshas /is of

a

Montant

Nbpoints

Datehas /is of

Etat(code)

{ 'encours' .. 'archivé' }

has /is ofU

ReservationHotel(NoRéservation)

/aa

BilletAvion(NoBillet)

historiqueis of /has

a

contient /est dans

Nbvoyageurs NbchambresReservées

NbNuits

DateJourMois !(Date)

concerne concerne

dure

réserve

has /is of

has /is of

has /is of has /is of

Hotel(NoHotel)

Passager(Identite)Vol

TypeChambre(CodeTypeChambre)

contient /est dans

CB(NumeroCarte) RIB

(NumeroRib)

Chèque(NoCheque)

Dateexp

dure /is of

EstRecu

RIB(NumeroRib)

Carte(NumeroCarte)


"Tarifs !""Disponibilités"

"HotelTypeChambre"

Hotel(NoHotel)

Ville(Code)

a

TypeChambre(CodeTypeChambre)

CategorieHotel(Code)

{ '*' .. '*****' }

a


PrixDeBase

coute /

NombreChambreDisponiblesoffre

Periode(Nb)

{ 'bleu' .. 'rouge' }

Reduction

Region(Code)

Pays(Code)

Fumeur

est dans

est dans /est dans /Metro

(Code)

est_au /is of

NomVillea

LibelleTypeChambre

{ 'lavabo 1 lit simple' .. 'bainwc 1 lit double' }

has /is of

P

propose /is of

P

offre

P

proposehas /is of

NbtotalChambres

has /is of

a /

Nbchambresdutypemis_a_jour

Hotelier(login)

Password

has /is of


"Dispoparclasse"

Vol

Passager(Identite)

Créneau horaire !(Code)

Heure{ '0' .. '23' }

Aeroport(Code)

part de /

arrive à /a

NumeroVola


part à

dureDuree

part à

composer /

composer /

P

Nombre de places dispo

has /is of

Tarif plein

Trajet(Nb)

a pour trajet /

coute

a pour reduction /Taux

{ '10' .. '90' }

se nomme /LibelleCategorie

{ 'junior' .. 'senior' }

a /

a /

a /

NomPassager

PrenomPassager

AgePassager

Compagnie(CodeCompagnie)a

P

est accessible /is of

U

has /is of

CategoriePassager(code)

/hasis of

Classe(Code)

Nbtotalplacesa

Minutes{ '00' .. '50' }

Ville(Code)


Traduction en schéma relationnel Entité associée uniquement à des valeurs

Table et attributs ayant pour nom les valeurs (ex Passagers) Clés

Clé simple une contrainte d'unicité sur un seul rôle (no client)

Clé composite contrainte d'unicité sur plusieurs rôles (nom+prénom+age)

Entité associée à une autre entité avec contrainte d'unicité Clé étrangère sur autre table (ex catégorie passager)

Objet composite identifiable un type d'objet co-référencé sans contraintes d'unicité : ex Hotel type

chambre un objet dont une partie de la clé contient une clé étrangère: ex: Vol


AeroportAeroport CodePKVille CodeFK

Créneau horaireCodeCreneauPKHeureMnutes

DateJourMoisDateJourMois DatePKPeriode

PassagerIdentitePKNomPassagerU1PrenomPassagerU1AgePassagerU1CategoriePassager codeFK

BilletAvionBilletAvion NoBilletPKVolCompagnieFKVol NumeroVolFKVolDateJourMois DateFKIdentiteFKContient Dossier NumeroFK

TrajetTrajet NbPKTarifPleinDureeAeroportArriveeFKAeroportDepartFK

/arrive à /part de

VolNumeroVolPKCompagniePKDateJourMois DatePK,FKCodeTrajetFKHeureDepartFKNbtotalplaces /a pour trajet

has /par t à

DispoparclasseNumeroVolPK,FKCodeCompagniePK,FKDateJourMois DatePK,FKClasse CodePKNombreDePlacesDispo

Categorie_passagerCode_Categorie_passagerPKLibelleCategorieTauxReductionClasse Code

is of

/ha

s

is of

/es

t acc

essib

le

is of /has

is of /

has

has /part à


DisponibilitésHotelPK,FKCodeTypeChambrePK,FKDateJourMois DatePK,FKNombreChambreDisponibles

HotelHotelPKCategorieHotel CodeVille CodeFKMetro est_au CodeNbtotalChambresHotelierFK

HotelierloginPKPassword

has /mis_a_jour

HotelTypeChambreHotelPK,FKTypeChambrePK,FKCoute PrixDeBaseNbchambresdutype

prop

ose

/is

of

has

/o f

fre

RegionRegion CodePKEst dans Pays Code

TarifsHotelPK,FKTypeChambrePK,FKPeriodePKReduction

propose

TypeChambreTypeChambrePKFumeurLibelleTypeChambre

is of

/pro

pose

VilleVille CodePKNomVilleEst dans Region CodeFK

/es

t dan

sha

s /

a

ReservationHotelReservationHotel NoRéservationPKRéserve DateJourMois DateFKNbchambresReservées concerneConcerne NbvoyageursMontantDossier contient NumeroFKHotelFKTypeChambreFKDure NbNuits

is of /has

is of /

has


CarteNumeroCartePKInfosComplementairesRIB NumeroRibFKClientFK,U1NbpointsCodeU2

ClientNumeroClientPKTelClientNomU1PrénomClientU1AdresseU1Email

DossierNumeroDossierPKDatePayé par MoyenDePaiementMontantTotalClientFKCarte historiqueFKEtat code

a /a

historique

BilletAvionBilletAvion NoBilletPKVolCompagnieFKVol NumeroVolFKVolDateJourMois DateFKIdentiteFKContient Dossier NumeroFK

ReservationHotelReservationHotel NoRéservationPKRéserve DateJourMois DateFKNbchambresReservées concerneConcerne NbvoyageursMontantDossier contient NumeroFKHotelFKTypeChambreFKDure NbNuits

contie

nt /

est d

ans

est dans /

contie

nt

is of /

has


Objets sous types Plusieurs possibilités

Une table pour le type et une par sous type Pas de table pour le surtype et une par sous type Pas de table pour les sous type et une pour le surtype Génération Visio assez pauvre:

CBCB NumeroCartePKCodeMoyen de PaiementU1Dateexp

ChèqueChèque NoChequePKCodeMoyende PaiementU1EstRecu

DossierNumeroDossierPKDatePayé par MoyenDePaiementU1MontantTotalClientFKCarte historiqueFKEtat code


Quelques éléments pour juger un outil de modélisation

Pouvoir d'expression Clarté, lisibilité, simplicité Orthogonalité

pas de recouvrement de concepts Stabilité sémantique Pertinence sémantique

modélisation intuitive Abstraction Formalisme , bases théoriques

permettant la validation, la génération automatique de code


Conclusion Comparaison MERISE, UML, ORM

Pas au même niveau; ORM en amont d'UML et MERISE, traduit simplement les

faits, rôles, assertions Les + ORM

plus expressif pour les données (persistantes) plus proche de l'utilisateur non informaticien

Les - ORM Confidentiel, un seul outil VISIO (microsoft) pas (encore?) normalisé


Quelques références Modélisation objets avec UML

Pierre-Alain Muller, Nathalie Gaertner 2e édition, Eyrolles, 2000

De Merise à UML Nasser Kettani, Dominique Mignet, Pascal Paré,

Camille Rosenthal-SabrouxEyrolles, 1998

Database Modeling with Microsoft Visio for Enterprise Halpin, T., Evans, K., Hallock, P. & MacLean B. Architects, Morgan

Kaufmann Publishers: San Francisco, 2003, http://www.orm.net/