imafa o5 logo2 partie i -...
TRANSCRIPT
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 3BD Relationnelles
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 4BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 6BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 7BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 8BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 9BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 11BD Relationnelles
Les composants du SI
Organisation e t adm in istration
Techno log ieInd ividus
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 12BD Relationnelles
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 13BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 14BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 15BD Relationnelles
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…
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 16BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 17BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 18BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 19BD Relationnelles
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?
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 20BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 21BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 22BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 23BD Relationnelles
modèle logique Access,
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
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 24BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 25BD Relationnelles
Modèle Logique
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 26BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 27BD Relationnelles
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;
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 28BD Relationnelles
diagramme de composants
Collection femme
Van
Vendeur de la boutique
Costume homme taille 5
Objets métiers; contraintes; (OCL)
Analyse des domaines
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
L’univers du discours
Diagramme de classes,
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 29BD Relationnelles
La recherche des dépendances fonctionnelles permet de normaliser la base de données
Analyse des domaines
Code
Conception de SI : analyse conceptuelle des données
df1 = N0coll,type Date début colldf2 = NoVendeur,N0Boutique MtTotal
Dépendances fonctionnelles
L’univers du discours
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 30BD Relationnelles
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 31BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 32BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 33BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 34BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 35BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 36BD Relationnelles
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 37BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 38BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 39BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 40BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 41BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 42BD Relationnelles
Analyse des domaines
Conception
Code
Conception de SI : Analyse des données avec ORM
Collection
Homme Femme Enfant
Objets, rôles, faits élémentaires
L’univers du discours
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
Analyse des donnéesavec ORM (et UML) à l'aide d'un exemple
Cas d ’utilisation et Faits élémentairesPrédicats; rôles
ContraintesSous typage
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 44BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 45BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 46BD Relationnelles
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).
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 47BD Relationnelles
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"
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 48BD Relationnelles
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…
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 49BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 50BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 51BD Relationnelles
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>>
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 52BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 53BD Relationnelles
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>>
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 54BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 55BD Relationnelles
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>>
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 56BD Relationnelles
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.
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 57BD Relationnelles
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....
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 58BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 59BD Relationnelles
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…
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 60BD Relationnelles
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>>
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 61BD Relationnelles
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
……
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 62BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 63BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 64BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 65BD Relationnelles
Vol
NoVoldate
PKPK
Heure DepartHeure arrivéeVilleDépartVille ArrivéePlacesDisponiblesStatut
Tarif
NoTarifPKFK Tarif
Schéma Relationnel :Tables et clés étrangères
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 66BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 67BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 68BD Relationnelles
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..)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 69BD Relationnelles
Rôles et Objets ORM Rôle d'ORM unifie
concepts UML terminaison d'association attributs
Objet ORM unifie les notions
entité valeur
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 70BD Relationnelles
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?
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 71BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 72BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 73BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 74BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 75BD Relationnelles
Etape 4Contraintes unicité, arité
Vol
est accessible
Classe(Code)
Chaque couple Vol/Classe est uniqueP
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 76BD Relationnelles
Etape 5Contraintes , obligation
Passager
(No Passeport)
a /
a /
a /
NomPassager
PrenomPassager
DateNaissance
U
Les valeurs Noms, Prénoms, DateNaissance sont obligatoires
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 77BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 78BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 79BD Relationnelles
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 1.0 -- 05/10/11 Anne-Marie Hugues © -- 80BD Relationnelles
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 81BD Relationnelles
Vérifications finales Contraintes
non réflexivité (irreflexivité) exclusivité (exclusive or) ensembles inclus dans d'autres...
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 82BD Relationnelles
Modèle final Ne pas hésiter à multiplier les vues pour simplifier la
lecture Ici 3 vues
Internautes Hotels Vols
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 83BD Relationnelles
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
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 84BD Relationnelles
"Tarifs !""Disponibilités"
"HotelTypeChambre"
Hotel(NoHotel)
Ville(Code)
a
TypeChambre(CodeTypeChambre)
CategorieHotel(Code)
{ '*' .. '*****' }
a
DateJourMois !(Date)
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 85BD Relationnelles
"Dispoparclasse"
Vol
Passager(Identite)
Créneau horaire !(Code)
Heure{ '0' .. '23' }
Aeroport(Code)
part de /
arrive à /a
NumeroVola
DateJourMois !(Date)
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)
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 86BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 87BD Relationnelles
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 à
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 88BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 89BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 90BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 91BD Relationnelles
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
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 92BD Relationnelles
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é
V 1.0 -- 05/10/11 Anne-Marie Hugues © -- 93BD Relationnelles
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/