View
5
Download
0
Category
Preview:
Citation preview
Bases de Donnees AvanceesIntroduction & Rappel
Conception et Modelisation
Thierry Hamon
Bureau H202Institut Galilee - Universite Paris 13
&LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/BDA-INFO2-2018-2019/
INFO2 – BDA
1/63
Presentation du cours
Objectif du cours (4 seances de 3h) :Notions avancees en BD : Conception, PL/SQL, UML,SQL2/3, structures complexes
Travaux Pratiques (6 seances de 3h) :Mise en œuvre de concepts vus en cours (PL/SQL, UML →SQL2/3, integrite des donnees, etc.)
2/63
Programme des enseignementsRappels de SQLConception & 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, ...
3/63
Des bases de donneesaux Entrepots de donnees
4/63
HistoriqueGenerations 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
Avancés
SGBD4/5
2004/5 − 2010
2010 − 2020?
Big Data
Puissance
Cohérence
Performance
5/63
HistoriqueApplications 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
Téraoctets par jour, Pétaoctets par an
(Applications analytique,
prise de décision, analyse prédictive)
BigData / Datamasse
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Performance
6/63
HistoriqueApplications 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)
Applications : Génome, Astronomie
Analyse climatique, Physique quantique,
Analyse tendancielle
(Temps réel)
Volu
me
de
don
née
s
Typ
e d
e d
on
née
s
Performance
7/63
HistoriqueStructure 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
Stockage etcalcul distribués
Puissance
Cohérence
Performance
Structure HIERARCHIQUE
des données
Type de données
COMPLEXE
Cloud computing
8/63
HistoriqueExemples 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
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
SGBD4/5
ORACLE 9i, 10g, 11g, 12c
DB2, ...
XML, ...
MapReduce, Hadoop
Teradata, Oracle
Performances
Cohérence
Puissance
9/63
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).
10/63
Le 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: CREATE
sa modification ALTER
sa suppression DROP
11/63
Le 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 : INSERT
la modification de donnees existantes : UPDATE
la suppression de donnees existantes : DELETE
12/63
Le langage de manipulation de donneesExemple
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)> ] ;
13/63
Le 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 : GRANT
l’interdiction de realiser une operation : DENY
Annulation d’une commande de controle precedente : REVOKE
l’autorisation a modifier des enregistrements : UPDATE
l’interdiction de modifier des enregistrements : READ
(consultation en lecture seulement)l’autorisation a supprimer des enregistrements : DELETE
14/63
Conception, 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
Outils : Power AMC, Power Designer WinDev, OracleDesigner Rational Rose, ...
2 Etape logique : Implantation d’une base de donnees
Modele Relationnel / Modele Objet-Relationnel / ModeleObjetOptimisation du schema (Normalisation, Denormalisation ...)
15/63
Conception, Developpement,Utilisation, Administration
3 Etape physique :
SGBD Relationnel / SGBD Objet-Relationnel / SGBD OrienteObjetLangages (SQL, PL/SQL, PRO*C, JDBC, Java, ...)Optimisations (Groupement, Index, ...)Administration
Outils : Oracle, DB2, My SQL
4 Logiciels (SGBD, Interfaces, ...) & Materiels
16/63
Conception 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
17/63
Conception 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.
18/63
Etapes 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
19/63
Remarques
Etape 1 : plutot relative au domaine du genie logiciel
Etapes 2, 3, 4 et 5 : relative au domaine des bases de donnees
20/63
Etape 1Perception 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
21/63
Etape 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
22/63
Etape 3Conception 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.
23/63
Etape 4Affinement 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
24/63
Etape 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
25/63
Elaboration 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
26/63
Phases d’elaboration duschema conceptuel
Identification des entites ou classes
Identification des associations
Identification des attributs pour chacune des entites ou classes
Definition des identifiants
27/63
Identification 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
28/63
Identification 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
29/63
Types 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)
30/63
Cardinalite 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 extremite de larelation
31/63
Cardinalite 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
32/63
Identification 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
33/63
Definition 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
34/63
Remarques 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 extremites ont une cardinalite 1,1 :l’association et les entites liees ne correspondraint-ils pas aune seule entite ?
35/63
Entite-relation et UML
Formalisme ER :
Formalisme UML :
36/63
Retour 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 : une instance d’etudiant peut etre associee aplusieurs formations
37/63
Retour 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 :
38/63
ER ou UML ?
Si conception de bases de donnees : utilisation du modeleentite/relationOn met 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 met l’acent sur les structures de donnees et laprogrammation
39/63
Elaboration 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
40/63
Passage 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, nbheures)Charge(numProf*, numCours*)
41/63
Passage au relationnelTraduction 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 classecibleExemple :
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
42/63
Affiner 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
43/63
Formes 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
44/63
Premiere 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)
45/63
Premiere forme normale (1FN)
Vol(NoVol*, CodeAeroDep#, CodeAeroArr#, HeureDep,HeureArr, Jours)
devient
Vol(NoVol*, CodeAeroDep#, CodeAeroArr#, HeureDep,HeureArr)
VolJour(NoVol*, Jour)
46/63
Deuxieme 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.
47/63
Deuxieme forme normale (2FN)
Avion(Constr*, Modele*, Conso, Capacite, VitesseMax)
→ il y a une dependance fontionnelle entre Modele et Capacite
On divise la table en deux :
Avion(Constr*, Modele#)ModeleAvion(Modele*, Conso, Capacite, VitesseMax)
48/63
Troisieme 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
49/63
Troisieme forme normale (3FN)
Exemple :
Enseignant(Nom*, Categorie, Classe, Salaire)
→ Le salaire depend de la categorie et de la classe
devient
Enseignant(Nom*, Categorie#, Classe#)Salaire(Categorie*, Classe*, Salaire)
50/63
Forme 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 depend d’un at-tribut ne faisant pas partie de la cle primaire
Remarques :
Un modele relationnel en FNBC est considere comme etant dequalite suffisante pour une l’implantationLes cas de relations en 3FN qui ne sont pas deja en FNBCsont tres rares
51/63
Forme normale de Boyce-Codd(BCNF)
Exemple 1 :
R(A, B*, C*, D)
Avec les dependances : B,C → A ; B,C → D ; D → B,(ce qui entraine de nombreuses redondances)On propose les relations :
R(A, B*, C*)R’ (D*, B#)
52/63
Forme normale de Boyce-Codd(BCNF)
Exemple 2 :
ReservationCourtTennis(NomCourt*, HeureDebut*,HeureFin, ClasseTauxHoraire)
La classe du taux horaire (SILVER, GOLD, PREMIUM) determineles courts disponibles.On propose les relations :
ReservationCourtTennis(NomCourt*, HeureDebut*,HeureFin)ClasseCourt(ClassTauxHoraire*, NomCourt#)
53/63
Elaboration 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/63
ExempleSchema 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/63
Schema 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/63
Schema 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/63
Schema 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/63
Schema 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/63
Schema relationnel-objetvoir plus tard en detail
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,DER PROM, SALAIRE BASE , SALAIRE ACTUEL ,Ensemble−de (COURS) )
60/63
Schema physique SQL3voir plus tard en detail
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/63
Bilan
Rappels sur
les langages de definition des donnees, de manipulation desdonnees (et du controle des donnees)
la bonne modelisation et la bonne conception d’une base dedonnees (des differents schemas)
A venir :
utilisation d’un langage procedural sur le BD (PL-SQL)
BD/SQL relationnel-objet et oriente-objet
62/63
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
63/63
Recommended