Embed Size (px)
Citation preview
Bases de Donnees AvanceesIntroduction & Rappel
Conception et Modelisation
Thierry Hamon
Bureau H202 - Institut GalileeTel. : 33 1.48.38.35.53
Bureau 150 – LIM&BIO – EA 3969Universite Paris 13 - UFR Leonard de Vinci
74, rue Marcel Cachin, F-93017 Bobigny cedexTel. : 33 1.48.38.73.07, Fax. : 33 1.48.38.73.55
http://www-limbio.smbh.univ-paris13.fr/membres/hamon/BDA-20102011
INFO2 – BDA
1/61
Sources des transparents
M.P. Dorville/F. Goasdoue, LRI, Universite Paris Sud
V. Mogbil, LIPN, Universite Paris Nord
J. Ullman http://infolab.stanford.edu/~ullman/
C. Rouveirol, LIPN, Universite Paris Nord
F. Boufares, LIPN, Universite Paris Nord
2/61
Presentation du coursPresentation du cours
Objectif du cours (12 seances de 1h30) :Des Bases de Donnees aux Entrepots de Donnees ExploitationIntelligente des Donnees
Travaux Pratiques (12 seances de 1h30) :Mise en œuvre de concepts vus en cours (PL/SQL, UML →SQL2/3, integrite des donnees, etc.)
3/61
Presentation du coursProgramme des enseignements
Rappels de SQL
Conception & Modelisation de Bases de Donnees
Meta-Modelisation, Formalismes utilises (ER, EER, UML, ...)Expression & Coherence des contraintes (SQL2/3, PL/SQL,OCL, ...)
Implantation de Bases de DonneesRelationnel-etendu, Oriente Objet (de UML a SQL2/3, JDBC,Java, PL/SQL J...)Optimisation de Requetes, Evaluation de RequetesArchitecture de SGBD, Administration de BD
Autres (Bases de Donnees, Entrepots de donnees, XML)
Gros volumes de donnees / Entrepots de donnees / DonneesMultiDimensionnellesDonnees Homogenes & Heterogenes,Donnees Reparties/Web, Donnees de type documents, ...
4/61
Presentation du coursDes bases de donnees aux Entrepots de donnees
5/61
HistoriqueHistoriqueGenerations de SGBD
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Ind
épen
dan
ce p
hysi
qu
e
Port
ab
ilit
é
Hiérarchies, Réseaux
SGBD 1
1960 − 1970 − 1980
1970 − 1980 − 1990
Relationnels
SGBD 2
SGBD 3
1980 − 1990 − 2000
Avancés
2004/5 − 2010
Avancés
SGBD4/5
Puissance
Cohérence
Performance
6/61
HistoriqueHistoriqueExemples de SGBD
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Ind
épen
dan
ce p
hysi
qu
e
Port
ab
ilit
é
SGBD 1COADSYL,
SOCRATE,
...
ORACLE 5/6
INGRES,
DB2, ...
SGBD 2
SGBD4/5
ORACLE 9i, 10g, 11
DB2, ...
XML, ...
SGBD 3
ORACLE 7/8,
INGRES, DB2, Sybase,
Verssant Enjin (O2),
ObjectStore, Orlent,
SQLServer, ACCESS, ...
MySQL, PostGreSQL,
Bases de données
Entrepôts de données
Intégration de Données
Performances
Cohérence
Puissance
7/61
HistoriqueHistoriqueApplications BD, ED, FD
Entrepôts de Données
Intégration de Données
Bases de Données
Applications : Paie, Marketing, Financière
(50 tables de quelques milliers de lignes) 50 Mo
Fouille de données
(Analyse du comportement des clients, etc.)
Intégration de plusieurs systèmes d’information nationaux et internationnaux)
Entrepôts de données (grosses masses de données)
(milliers de tables de quelques millions de lignes) > 100 Go
Applications : Gestion des risques, Analyse des ventes
(100 tables de quelques millions de lignes) 2 Go
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Performance
8/61
HistoriqueHistoriqueApplications BD, ED, FD
Entrepôts de Données
Intégration de Données
Bases de Données
Applications : Paie, Marketing, Financière
(OLTP: quelques secondes) (Batch : < 1 heure)
Entrepôts de données
(OLTP : < 10 secondes) (OLAP < 1 heure)
( MV : agrégation, ...) (Batch : Quotidien ou mensuel < 1h)
Grosse volumétrie : travail d’optimisation et suivi des activités
du DWh nécéssaire
Par expérience, certains traitements ne se terminent pas
Nécessité de modifications techniques et fonctionnelles
au bout de quelques jours
Applications : Gestion des risques, Analyse des ventes
(Batch : < 1 heure)
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Performance
9/61
HistoriqueHistoriqueStructure et type de donnees
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Ind
épen
dan
ce p
hysi
qu
e
Port
ab
ilit
é
Relationnelle
& objet
Structure de données
TABULAIRE
Relations
Hiérarchique
& RéseauStructure de données
en RESEAU
Puissance
Cohérence
Performance
Structure HIERARCHIQUE
des données
Type de données
COMPLEXE
10/61
Commandes SQL
Plusieurs sortes de commandes SQL parmi lesquelles :
LDD (langage de definition de donnees),
LMD (langage de manipulation des donnees) c’est-a-dire duLMJ (langage de mise a jour) et du LID (langaged’interrogation des donnees),
LCD (langage de controle des donnees).
11/61
Le Langage de Definition de Donnees : LDDLe Langage de Definition de Donnees (LDD)
Ensemble de commandes qui definit une base de donnees etles objets qui la composent
la definition d’un objet inclut
sa creation: CREATEsa modification ALTERsa suppression DROP
12/61
Le langage de manipulation de donnees : LMDLe langage de manipulation de donnees : LMD
Ensemble de commandes qui permet la consultation et la misea jour des objets crees par le langage de definition de donnees
Consultation : SELECT
La mise a jour inclut :
l’insertion de nouvelles donnees : INSERTla modification de donnees existantes : UPDATEla suppression de donnees existantes : DELETE
13/61
Le langage de manipulation de donnees : LMDLe langage de manipulation de donnees : LMDExemple
SELECT < l i s t e champ ( s)> FROM < l i s t e no m ta b le ( s)>[WHERE c o n d i t i o n ( s ) ] [ o p t i o n s ] ;
INSERT INTO <nom table> [(< l i s t e champ ( s ) >)]VALUES (< l i s t e v a l e u r s >);
UPDATE <nom table> SET <champ> = <e x p r e s s i o n >[WHERE < l i s t e c o n d i t i o n ( s)> ] ;
DELETE FROM <nom table> [WHERE < l i s t e c o n d i t i o n ( s)> ] ;
14/61
Le langage de controle de donnees : LCDLe langage de controle de donnees : LCD
Ensemble de commandes de controle d’acces aux donnees
Le controle d’acces inclut :
l’autorisation a realiser une operation : GRANTl’interdiction de realiser une operation : DENYAnnulation d’une commande de controle precedente : REVOKEl’autorisation a modifier des enregistrements : UPDATEl’interdiction de modifier des enregistrements : READ(consultation en lecture seulement)l’autorisation a supprimer des enregistrements : DELETE
15/61
IntroductionConception, Developpement, Utilisation, Administration
1 Etape conceptuelle : Conception et Modelisation de bases dedonneesUtilisation de
Methodes, Modeles, FormalismesModele Entite-Association E/A / Modele Entite-AssociationetenduModeles Objet, Formalisme UML
Power AMC, Power Designer WinDev, Oracle DesignerRational Rose, ...
2 Etape logique : Implantation d’une base de donnees
Modele Relationnel / Modele Objet-Relationnel / ModeleObjetOptimisation du schema (Normalisation, Denormalisation ...)
16/61
IntroductionConception, Developpement, Utilisation, Administration
3 Etape physique :
SGBD Relationnel / SGBD Objet-Relationnel / SGBD OrienteObjetLangages ( SQL, PL/SQL, PRO*C, JDBC, Java, ...)Optimisations (Groupement, Index, ...)Administration
Oracle, DB2, My SQL
4 Logiciels (SGBD, Interfaces, ...) & Materiels
17/61
IntroductionConception du schema des bases
→ Une des taches essentielles des developpeurs de bases dedonnees
Objectif : structuration du domaine d’application afin de
de le representer sous forme de types et de tables
d’accompagner ces structures de contraintes sur les donneesafin de tirer plus de semantique
18/61
IntroductionConception du schema des bases
La representation doit etre :
juste pour eviter les erreurs semantiques, notamment dans lesreponses aux requetes ;
complete pour permettre le developpement des programmesd’application souhaites ;
evolutive afin de supporter la prise en compte rapide denouvelles demandes.
19/61
IntroductionEtapes de conception
Demarche de conception traditionnelle :
par abstractions successives
en descendant depuis les problemes de l’utilisateur vers leSysteme de Gestion de Bases de Donnees.
Cinq etapes :
1 Perception du monde reel et capture des besoins
2 Elaboration du schema conceptuel
3 Conception du schema logique
4 Affinement du schema logique
5 Elaboration du schema physique
20/61
IntroductionRemarques
Etape 1 : plutot relative au domaine du genie logiciel
Etapes 2, 3, 4 et 5 : relative au domaine des bases de donnees
21/61
IntroductionEtape 1 : Perception du monde reel et capture des besoins
Etude des problemes des utilisateurs
Comprehension de leurs besoins
→ Mise en place d’entretiens, d’analyses des flux d’information etdes processus metier
Difficulte : comprehension du probleme dans son ensemble
→ Realisation des etudes de cas partiels par les concepteurs
Resultat : ensemble de vues ou schemas externes devant etreintegres dans l’etape suivante
Vues exprimees dans un modele de de donnees : de typeentite-association ou objet, selon la methode choisie
22/61
IntroductionEtape 2 : Elaboration du schema conceptuel
Integration des schemas externes obtenus a l’etape precedente
Chaque composant est un schema conceptuel : diagrammeentite-association ou diagramme de classes
Resultat : modele de probleme representant une partie del’application
Difficulte : integration de toutes les parties dans un schemaconceptuel global complet, non redondant et coherent
NB : des allers et retours avec l’etape precedente sont souventnecessaires
23/61
IntroductionEtape 3 : Conception du schema logique
Transformation du schema conceptuel en structures de donneessupportees par le systeme choisi : le schema logique.
Avec un SGBD relationnel : passage a des tables.
Avec un SGBD relationnel-objet : Generation de types et detables,NB : les types sont reutilisables
Avec un SGBD objet : generation de classes et de associations
NB : Cette etape peut etre completement automatisee.
24/61
IntroductionEtape 4 : Affinement du schema logique
Verification : le schema logique est-il un � bon � schema ?
Definition en premiere approximation : un � bon schema� est un schema sans oublis ni redondances d’informations
Plus precisement : un schema est � bon � si le modelerelationnel associe respecte au moins la troisieme formenormale et la forme normale de Boyce-Codd (voir plus loin)
Objectif en relationnel : regrouper ou decomposer les tablesde maniere a representer fidelement le monde reel modelise
25/61
IntroductionEtape 5 : Elaboration du schema physique
Etape necessaire pour obtenir de bonnes performances
Prise en compte de toutes les transactions concernant lesapplications traiteesPermet de determiner les acces frequents
Choix des bonnes structures physiques : groupement oupartitionnement de tables, index, etc.point essentiel pour obtenir de bonnes performances
26/61
Elaboration du schema conceptuelElaboration du schema conceptuel
Modelisation du probleme en utilisant les specifications des besoinsobtenues a l’etape 1 (capture des besoins)
Deux possibilites :
utilisation du formalisme Entite Relation (ou EntiteAssociation)→ production d’un diagramme ER/EA
utilisation du formalisme UML→ production de classe
Independance du modele conceptuel par rapport au schemaphysique
27/61
Elaboration du schema conceptuelPhases d’elaboration du schema conceptuel
Identification des entites ou classes
Identification des associations
Identification des attributs pour chacune des entites ou classes
Definition des identifiants
28/61
Elaboration du schema conceptuelIdentification des entites ou classes
Entites : element abstrait ou concret (objet, evenement, etc.)reconnu distinctementExemples : Jean Dupont, Michel Durant
Type-entites : Ensemble des entites ayant les memescaracteristiquesExemple : Personne(nom, prenom)
NB : Par abus de langage, on parle souvent d’entites a laplace de type-entites
Dans l’etape 1, il s’agit de la description des elements
29/61
Elaboration du schema conceptuelIdentification des associations
Association : Lien logique entre deux entites
Type-Association : Ensemble d’association ou de relationspossedant les memes caracteristiques.
Association/type-association : meme abus de langage
A l’etape 1 : une phrase simple reliant deux entitesExemple : un professeur est en charge de cours (lien entreles entites professeur et cours)
Plusieurs types d’association existent
30/61
Elaboration du schema conceptuelTypes d’association
unaire : relation au sein d’une meme entiteExemple : un employe supervise un employe
binaire : relation entre deux entites (differentes)Exemple : un client passe plusieurs commandes
ternaire : relation entre trois entites (differentes)Exemple : un internaute note un film a differentes date (onveut conserver l’historique des notes)
31/61
Elaboration du schema conceptuelCardinalite d’un type-association
Cardinalite : nombre minimal et maximal de fois qu’une entitepeut intervenir dans une association de ce type
Exemple : un client peut commander 1 a n produits
Remarques :
la cardinalite minimal doit etre inferieure a la cardinalitemaximalela cardinalite doit etre associee a chaque patte de la relation
32/61
Elaboration du schema conceptuelCardinalite minimale/maximale
Cardinalite minimale :
0 : une entite peut exister tout en etant impliquee dansaucune association1 : une entite ne peut exister que si elle est impliquee dans aumoins une associationn : une entite ne peut exister que si elle est impliquee dansplusieurs associations (cas rare,a eviter car cela pose desproblemes)
Cardinalite maximale :
0 : une entite ne peut pas etre impliquee dans une association(normalement inexistant sinon probleme de conception)1 : une entite peut etre impliquee dans au maximum uneassociationn : une entite peut etre impliquee dans plusieurs associations
33/61
Elaboration du schema conceptuelIdentification des attributs
Attribut : caracteristique associee a une entiteExemples : nom, prenom, age
Domaine associe a un attribut : ensemble des valeurs possibles
Chaque attribut doit posseder une valeur compatible avec sondomaine
Remarque : Eviter absolument les attributs calcules.Toujours utiliser des donnees primaires – les attributs quiservent a les calculer
34/61
Elaboration du schema conceptuelDefinition de l’identifiant
Identifiant : liste des attributs devant avoir une valeur uniquechaque entite
Exemple : numero d’immatriculation d’une voiture, numero desecurite sociale
Remarques :
On utilise plutot le terme cle que identifiantChaque type doit posseder un identifiant (forme d’un ouplusieurs attributs)L’identifiant d’une association est la concatenation desidentifiants des entites liesNB : on peut definir un identifiant plus naturel
35/61
Elaboration du schema conceptuelRemarques sur la conception
Un attribut ne peut etre partage entre deux entites ouassociations (probleme de redondance)
En cas de difficulte a choisir entre entite et association (parexemple, mariage) : utiliser le contexte pour y repondre
En cas de difficulte a trouver un identifiant pour untype-entite : ne s’agirait-il pas une association ?
Association dont toutes les pattes ont une cardinalite 1,1 :l’association et les entites liees ne correspondraint-ils pas aune seule entite ?
36/61
Elaboration du schema conceptuelEntite-relation et UML
Formalisme ER :
Formalisme UML :
37/61
Elaboration du schema conceptuelRetour sur les cardinalitesinterpretation – Formalisme ER
(une des cardinalites est volontairement absente)
Tout etudiant participe au moins une fois a l’association est inscrit.Tout etudiant est inscrit dans au moins une formation
Autrement dit : a une instance d’etudiant peut etre associe aplusieurs formations
38/61
Elaboration du schema conceptuelRetour sur les cardinalitesGeneralisation
Formalisme ER :
Interpretations :
A est lie 0 a n fois a B
La connaissance de B permet de definir A
La cle de B definit l’instance de A
Formalisme UML :
39/61
Elaboration du schema conceptuelER ou UML ?
Si conception de bases de donnees : utilisation du modeleentite/relationOn mets l’accent sur le systeme d’information (stockage,traitement, reception, diffusion de l’information)
Si conception objet et programmation : utilisation de UML(2– incluant l’heritage)On mets l’acent sur les structures de donnees et laprogrammation
40/61
Elaboration du schema logiqueElaboration du schema logique
Transformation du modele conceptuel en une structure de donneesbasee sur un modele de donnees specifique (par exemple, modelerelationnel)
Realisation de la transformation a l’aide de regles formelles→ Possibilite d’automatisation de cette etape (Objecteering,Rational Rose)
Independant de la couche physique
Resultat : modele logique de la base de donnees
41/61
Elaboration du schema logiquePassage au relationnel
Implementation des entites et associations sous forme detables
Les attributs correspondent aux colonnes des tables
le nom de l’attribut est le nom de la colonnel’ensemble des valeurs possibles est le domaine
Exemple :
Professeur(numProf, nom, prenom)Cours(nomCours, nom)Charge(numProf, numCours)
42/61
Elaboration du schema logiquePassage au relationnel
Traduction des associations :Regle de base : representation des associations par une tabledont
le schema est le nom de l’associationla liste des cles des entites participantes suivie des attributs del’association
Amelioration : Regrouper les associations 1..n avec la classecible
Exemple :
Voiture(numV, Marque, modele)Possede(numProp, numV, Date)
→ les deux tables peuvent etre regroupees si toutes lesvoitures n’ont qu’un et un seul proprietaire
43/61
Affinement des requetesAffiner les requetesrespecter les formes normales
Pourquoi normaliser ?
pour limiter les redondances de donnees
pour limiter les pertes de donnees
pour limiter les incoherences au sein des donnees
pour ameliorer les performances des traitements
44/61
Affinement des requetesFormes normales
8 formes normales :
Formes normales 1 a 3
Forme normale de Boyce-Codd
Formes normales de 4/5(/6)
Forme normale de domaine-cle
Objectifs des trois premieres formes normales : permettre ladecomposition de relations sans perdre d’informations
Une relation en forme normale de niveau N est forcement de formenormale de niveau N − 1
45/61
Affinement des requetesPremiere forme normale (1FN)
Une relation est en premiere forme normale si tous ses attributscontiennent des valeurs
simples et non-decomposables (utiliser une liste ou une tableexterne)
non-repetitives
constantes dans le temps (date de naissance plutot que l’age)
46/61
Affinement des requetesPremiere forme normale (1FN)
Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep,HeureArr, Jours)
devient
Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep,HeureArr, Jour)
Vol(NoVol*, Jour)
47/61
Affinement des requetesDeuxieme forme normale (2FN)
Une relation est en deuxieme forme normale si et seulement si :
elle est en premiere forme normale
tout attribut non cle est totalement dependant de toute la cleAutrement dit, une des trois conditions doit etre respectee :
La cle primaire n’est formee que d’un seul attributLa cle primaire contient tous les attributs de la tableSi la cle a plus d’un attribut, une dependance fonctionnelle nedoit jamais exister entre une partie seulement de la cle et unautre attribut de la table.
48/61
Affinement des requetesDeuxieme forme normale (2FN)
Avion(Constr*, Modele*, Conso, Capacite, VitesseMax)
→ il y a une dependance fontionnelle entre Constr et Modele
On divise la table en deux :
Avion(Constr*, Modele*)ModeleAvion(Modele*, Conso, Capacite, VitesseMax)
49/61
Affinement des requetesTroisieme forme normale (3FN)
Une relation est en troisieme forme normale si et seulement si :
elle est en deuxieme forme normale
tout attribut n’appartenant pas a une cle ne depend pas d’unattribut non cle
→ les dependances fonctionnelles entre deux attributs ordinaires(ne faisant par partie de la cle) ne sont pas autorisees
50/61
Affinement des requetesTroisieme forme normale (3FN)
Exemple :
Voiture(Modele, Couleur, Annee, Cote)
→ il y a une dependance entre l’annee et la cote
devient
Voiture(Modele, Couleur, Annee)Cote(Annee, Cote)
51/61
Affinement des requetesForme normale de Boyce-Codd (BCNF)
Extension plus rigide de la troisieme forme normale (definiepar R.F. Boyce et E.F. Codd – en partant du constat que la3FN comportait certaines anomalies)
Une relation est en forme normale de Boyce-Codd si etseulement si :
aucun attribut faisant partie de la cle ne dependd’un attribut ne faisant pas partie de la cle primaire
Remarques :
Un modele relationnel en FNBC est considere comme etant dequalite suffisante pour une l’implantation
Les cas de relations en 3FN qui ne sont pas deja en FNBCsont tres rares
52/61
Affinement des requetesForme normale de Boyce-Codd (BCNF)Exemple :soit la relation Vins(Cru, Pays, Region)
Cru Pays Region
Chenas France BeaujolaisJulienas France BeaujolaisMorgon France BeaujolaisBrouilly France BeaujolaisChablis Etats-Unis Californie
Attention : de nombreuses redondances
On propose les relations :
Crus (Cru, Region)Regions (Region, Pays)
53/61
Elaboration du schema physiqueElaboration du schema physique
Objectifs :
Rechercher de bonnes performances
Prendre en compte les transactions
Indexer, denormaliser, grouper, partitionner les tables
Resultat : modele physique optimise de la base de donnees
54/61
Elaboration du schema physiqueExempleSchema relationnel
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,DER PROM, SALAIRE BASE , SALAIRE ACTUEL )
CHARGE( NUM PROF∗ , NUM COURS∗ )
55/61
Elaboration du schema physiqueSchema physique (SQL2)
c r e a t e t a b l e COURS(NUM COURS NUMBER( 2 ) NOT NULL ,NOMC VARCHAR( 2 0 ) NOT NULL ,NBHEURES NUMBER( 2 ) ,ANNE NUMBER( 1 ) ,c o n s t r a i n t PK COURS pr imary key (NUM COURS) ) ;
c r e a t e t a b l e PROFESSEURS(NUM PROF NUMBER( 4 ) NOT NULL ,NOMP VARCHAR2( 2 5 ) NOT NULL ,SPECIALITE VARCHAR2( 2 0 ) ,DATE ENTREE DATE,DER PROM DATE,SALAIRE BASE NUMBER,SALAIRE ACTUEL NUMBER,c o n s t r a i n t PK PROFESSEURS pr imary key (NUM PROF) ) ;
56/61
Elaboration du schema physiqueSchema physique (SQL2)
c r e a t e t a b l e CHARGE(NUM PROF NUMBER( 4 ) NOT NULL ,NUM COURS NUMBER( 4 ) NOT NULL ,c o n s t r a i n t PK CHARGE pr imary key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
57/61
Elaboration du schema physiqueSchema physique (SQL2)Ajout de contraintes
c r e a t e t a b l e COURS(NUM COURS NUMBER( 2 ) ,NOMC VARCHAR( 2 0 ) ,NBHEURES NUMBER( 2 ) ,ANNE NUMBER( 1 ) ,c o n s t r a i n t PK COURS pr imary key (NUM COURS) ,c o n s t r a i n t NN COURS NOMC check (NOMC I S NOT NULL ) ) ;
c r e a t e t a b l e PROFESSEURS(NUM PROF NUMBER( 4 ) ,NOMP VARCHAR2( 2 5 ) ,SPECIALITE VARCHAR2( 2 0 ) ,DATE ENTREE DATE,DER PROM DATE,SALAIRE BASE NUMBER,SALAIRE ACTUE NUMBER,c o n s t r a i n t PK PROFESSEURS pr imary key (NUM PROF) ,c o n s t r a i n t NN PROFESSEURS NOMP check (NOMP I S NOT NULL ) ) ;
58/61
Elaboration du schema physiqueSchema physique (SQL2)Ajout de contraintes
c r e a t e t a b l e CHARGE(NUM PROF NUMBER( 4 ) ,NUM COURS NUMBER( 4 ) , ,c o n s t r a i n t PK CHARGE pr imary key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGEadd c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
59/61
Elaboration du schema physiqueSchema relationnel-objet
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,DER PROM, SALAIRE BASE , SALAIRE ACTUEL ,Ensemble−de (COURS) )
60/61
Elaboration du schema physiqueSchema physique SQL3
c r e a t e t y p e c o u r s t y p e as o b j e c t( num cours number ( 2 ) , nomc v a r c h a r 2 ( 2 0 ) , n b h e u r e s number ( 2 ) ,
annee number ( 1 ) )/c r e a t e t y p e l e s c o u r s t y p e as t a b l e o f c o u r s t y p e/c r e a t e t y p e p r o f e s s e u r t y p e as o b j e c t( num prof number ( 4 ) , nom v a r c h a r 2 ( 2 5 ) , s p e c i a l i t e v a r c h a r 2 ( 2 0 ) ,
c o u r s l e s c o u r s t y p e . . . )/c r e a t e t a b l e p r o f e s s e u r o f p r o f e s s e u r t y p e( pr imary key ( num prof ) )n e s t e d t a b l e c o u r s s t o r e as tabemp/
61/61
