Bases de Donnees

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.
com
Bases De Donnes
. Conception dune BDD Relationnelle
Modle Conceptuel de Donnes Passage au Modle Logique de Donnes
. Construction dune BDD

Langage de dfinition SQL : create, drop, alter SQBD : SQL Anywhere
. Manipulation dune BDD

Modle relationn elle Langage de manipulation SQL : insert, update, delete, select Langage de dfinition SQL : create view
. Traitements dans les BDD

Triggers Procdures stockes
. Scurits des BDD

Journalisation, transactions : commit, rollback Droits daccs : grant, revoke
. Accs aux BDD dans les langages htes

Visual Basic SQL Server
afpa Roubaix Didier DENRY
BDD 1/77
14/01/07
Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com
1 - Conception dune BDD Relationnelle Modle Conceptuel de Donnes
OBJET : reflet dune ENTITE statique manipule par lorganisme, dote dune existence propre, dont chaque occurrence est identifiable par une donne particulire.
RELATION : ENTITE dont lexistence des occurrences dpend de lexistence des occurrences dobjets qui la composent.
PROPRIETE : plus petit ELEMENT logique dinformation, qui a un sens en lui-mme et dont la valeur caractrise partiellement une occurrence dOBJET ou de RELATION. Remarque : tout objet doit comporter une proprit chaque valeur de laquelle ne correspondra quune occurrence de lOBJET : cest lIDENTIFIANT.
CARDINALITE : nombre mini et maxi doccurrences dune RELATION pour une occurrence dOBJET ; seuls 3 chiffres sont significatifs : 0, 1 et n.
Client Numro client Raison sociale Adresse rue Code postal Bureau distributeur Tlphone
0,n
NO6 A30 A30 N5 A30 A15
OBJET CLIENT
facturer
RELATION FACTURER
1,1
Facture Numro facture Date facture

1,n
NO6 D
OBJET FACTURE
concerne Qt achete N6
RELATION CONCERNER
0,n
Produit Numro produit Dsign ation Prix unitaire Qt en stock NO6 A30 M N8,2 N8
OBJET PRODUIT
BDD 2/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Note

Soit la liste des donnes recenses dans un tablissement scolaire et prsentes par ordr e alphabtique : Adresse de llve Matire enseigne Nombre dheures Nom de la classe Nom de llve Nom du professeur Note Numro de salle Prnom de llve
Rgles de gestion : A chaque classe est attribue une et une salle de cours Chaque matire nest enseigne que par un et un seul professeur Pour chaque classe et chaque matire est dfini un nombre fixe dheures de cours A chaque lve est attribue une seule note par matire
Ltablissement gre les emplois du temps des professeurs et des lves ainsi que le contrle de connaissances.
BDD 3/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Niche

Liste des proprits : Adresse du propritaire Date dachat Date de concours Date de dcs du chien Date de naissance du chien Nom du chien Nom du propritaire Numro de matricule du chien Race Rsultat du concours Sexe du chien Type de concours Ville de concours
Il sagit de construire un systme permettant de connatre le cursus honorum des chiens de race participant des concours, ainsi que leur gnalogie.
BDD 4/77
14/01/07
1 - Conception dune BDD Relationnelle Cas FAP

Lorganisme FAP pour un type dactivit dentreprise donn est habilit collecter le 1% de la formation professionnelle, cet organisme ralise lui-mme de la formation. Les entreprises versent 1% des salaires bruts FAP pour lanne coule avant le 1er mars en un ou plusieurs versements, ce qui leur octroie un crdit de formation du mme montant. FAP organise des stages de formation dont la dure varie de 1 10 jours ; chaque stage a des dates de stage, un nombre dheures global, un cot, ... Les entreprises y inscrivent des stagiaires (membres de lentreprise), le cot correspondant du stage est dbit du compte de lentreprise, si le crdit de lentreprise nest pas suffisant une facture de formation (avec TVA) est adresse lentreprise lissue du stage (facture complte ou partielle). Les stagiaires ntant pas toujours prsents durant toute la dure du stage, il est ncessaire partir des feuilles de prsence signes par les stagiaires de saisir les dates dabsences et le nombre dabsences correspondant. En fin de stage, on dite une attestation de prsence par entreprise ayant eu des stagiaires dans ce stage, donnant le nom du stage, les dates, le nombre dheures du stage, et par stagiaire le nombre dheures de prsence, les dates dabsences avec les nombres dheures dabsences correspondant chaque date dabsence. Cette dition est faite tous les mois pour les stages se terminant durant le mois et dont les absences furent enregistres. Tous les mouvements comptables doivent tre conservs pour toutes les entreprises : - versement du 1% - enregistrement des dbits - rglements complmentaires Suppression de lhistorique une fois par an avec dition des positions de compte (reflet pour chaque entreprise des diffrentes critures comptables). En cours d anne on peut vouloir diter une position de compte pour une entreprise, une plage de numros dentreprise ou toutes les entreprises. La suppression des critures ne se fait pas dans ce type ddition.
BDD 5/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Rservation Htel

Champ de ltude : rservation des chambres dhtel des stations de sport dhiver connues par un organisme de voyages.
Liste des proprits :

Adresse du client Capacit de lhtel Capacit de la chambre Catgorie de lhtel Date dbut de sjour Date fin de sjour Date mission de la rservation Degr de confort Distance gare SNCF Station de ski Exposition de la chambre Gare SNCF Montant des arrhes verses Nom du client Nom de lhtel Numro de client Numro de la chambre Numro de la rservation Numro de tlphone du client Priode tarifaire Prix journalier de la chambre Station de ski Type de chambre
Rgles de gestion : Le prix est dtermin dans chaque station par la catgorie de lhtel, la priode tarifaire et
le type de chambre.
Le type de chambre dpend de la capacit, du degr de confort et de lexposition de la

chambre.
BDD 6/77
14/01/07
1 - Conception dune BDD Relationnelle Passage au Modle Logique
Contexte Relationnel :
ATTRIBUT : correspond la dfinition de donne ou de proprit DOMAINE : ensemble des valeurs que peut prendre un attribut TABLE : sous-ensemble du produit cartsien dune liste de domaines ; toute occurrence, appele TUPLE, est une suite value des ATTRIBUTS qui composent la TABLE
Rgles de passage :
. Tout OBJET devient une TABLE ; sil ne porte que son identifiant, il peut ne pas donner lieu transformation. La proprit identifiante devient alors la cl primaire de la table. . Une RELATION BINAIRE de cardinalits x,1 x,n (x valant 0 ou 1) provoque lajout dans la TABLE issue de lOBJET de cardinalit x,1, dun ATTRIBUT supplmentaire correspondant lidentifiant de lOBJET de cardinalit x,n nomm cl trangre ; si la relation est porteuse de donnes, celles-ci passent dans cette mme TABLE. . Dans le cas dune relation dappartenance, la cl trangre sintgrera la cl primaire. . Une RELATION BINAIRE de cardinalits x,n x,n donne lieu la cration dune TABLE dont 2 des ATTRIBUTS correspondront aux identifiants des 2 objets. . Par extension, une RELATION n-aire donnera une TABLE dont n des ATTRIBUTS correspondront aux identifiants des n OBJETS.
BDD 7/77
14/01/07
Modle Logique de Donnes :
Client Numro client Raison sociale Adresse rue Code postal Bureau distributeur Tlphone <pk> numeric(6) char(30) char(30) numeric(5) char(30) char(15) not null not null not null not null not null null
facturer
Facture Numro facture Numro client Date facture <pk> <fk> numeric(6) not null numeric(6) not null date not null
lien_24
concerne Numro facture Numro produit Qt achete <pk,fk> <pk,fk> numeric(6) not null numeric(6) not null numeric(6) null
lien_25
Produit Numro produit Dsignation Prix unitaire Qt en stock <pk> numeric(6) char(30) numeric(8,2) numeric(8) not not not not null null null null
BDD 8/77
14/01/07
2 - Construction dune BDD Langage de dfinition SQL
DBTOOL CREATE DATABASE DBTOOL DROP DATABASE CREATE TABLE DROP TABLE ALTER TABLE
%% ============================================================ %% Nom de la base : FACTURE %% Nom de SGBD : Sybase SQL Anywhere %% Date de cration : 02/11/99 11:55 %% ============================================================ %% ============================================================ %% Nom de la base : FACTURE %% ============================================================ dbtool create database 'facture.db' transaction log to 'facture.log'; connect to 'facture.db' user "dba" identified by sql; %% ============================================================ %% Table : CLIENT %% ============================================================ create table CLIENT ( NUMERO_CLIENT numeric(6) not null default AUTOINCREMENT, RAISON_SOCIALE char(30) not null, ADRESSE_RUE char(30) not null, CODE_POSTAL numeric(5) not null, BUREAU_DISTRIBUTEUR char(30) not null, TELEPHONE char(15) , primary key (NUMERO_CLIENT) ); %% ============================================================ %% Table : PRODUIT %% ============================================================ create table PRODUIT ( NUMERO_PRODUIT numeric(6) not null default AUTOINCREMENT, DESIGNATION char(30) not null, PRIX_UNITAIRE numeric(8,2) not null, QTE_EN_STOCK numeric(8) not null, primary key (NUMERO_PRODUIT)
BDD 9/77
14/01/07
); %% ============================================================ %% Table : FACTURE %% ============================================================ create table FACTURE ( NUMERO_FACTURE numeric(6) not null default AUTOINCREMENT, NUMERO_CLIENT numeric(6) not null, DATE_FACTURE date not null, primary key (NUMERO_FACTURE) ); %% ============================================================ %% Table : CONCERNE %% ============================================================ create table CONCERNE ( NUMERO_FACTURE numeric(6) not null, NUMERO_PRODUIT numeric(6) not null, QTE_ACHETEE numeric(6) , primary key (NUMERO_FACTURE, NUMERO_PRODUIT) ); alter table FACTURE add foreign key FK_FACTURE_ASSOC_3_CLIENT (NUMERO_CLIENT) references CLIENT (NUMERO_CLIENT) on update restrict on delete cascade; alter table CONCERNE add foreign key FK_CONCERNE_LIEN_24_FACTURE (NUMERO_FACTURE) references FACTURE (NUMERO_FACTURE) on update restrict on delete cascade; alter table CONCERNE add foreign key FK_CONCERNE_LIEN_25_PRODUIT (NUMERO_PRODUIT) references PRODUIT (NUMERO_PRODUIT) on update restrict on delete cascade;
BDD 10/77
14/01/07
3 - Manipulation dune BDD Langage de manipulation SQL INSERT
BDD 11/77
14/01/07
BDD 12/77
14/01/07
3 - Manipulation dune BDD Langage de manipulation SQL SELECT TRI

Opration consistant trier les lignes
PRODUIT
DESIGNATION
BDD 13/77
14/01/07
PROJECTION
Opration consistant liminer les colonnes non utilises
CLIENT
RAISON_SOCIALE TELEPHONE
BDD 14/77
14/01/07
PROJECTION
Opration consistant liminer les colonnes non utilises et liminer les lignes en double
CLIENT
BUREAU_DISTRIBUTEUR
DISTINCT
BDD 15/77
14/01/07
SELECTION
Opration consistant slectionner les lignes en fonction dune condition
CLIENT
CODE_POSTAL = 59000
BDD 16/77
14/01/07
REGROUPEMENT
Opration consistant regrouper les lignes et a effectuer des calculs lis au regroupement tels que moyenne, comptage et cumul.
CLIENT
Regroupement sur CODE_POSTAL
CODE_POSTAL COUNT(*)
BDD 17/77
14/01/07
EQUI-JOINTURE
Opration consistant rapprocher les lignes de 2 tables en fonction dune condition dgalit
FACTURE
CLIENT
=
NUMERO_FACTURE NUMERO_FACTURE
NUMERO_FACTURE DATE_FACTURE RAISON_SOCIALE BUREAU_DISTRIBUTEUR
BDD 18/77
14/01/07
DIFFERENCE
Opration consistant ne conserver que les lignes dune table ne figurant pas dans une autre table FACTURE CLIENT
NUMERO_CLIENT
BDD 19/77
14/01/07
3 - Manipulation dune BDD Langage de manipulation SQL UPDATE
BDD 20/77
14/01/07
3 - Manipulation dune BDD Langage de manipulation SQL DELETE
BDD 21/77
14/01/07
3 - Manipulation dune BDD Langage de dfinition SQL CREATE VIEW
BDD 22/77
14/01/07
3 - Manipulation dune BDD Langage de dfinition SQL Base De Donnes Pubs Modle Conceptuel de Donnes:
auteurs id_auteur nom_auteur pn_auteur telephone adresse ville pays code_postal titreauteur 1,n cmd_auteur droits_pourcent 1,n titres id_titre titre prix 1,1 ventes Assoc_54 0,n num_cmd date_cmd 1,1 qt modepaiements (1,1)
est dit par
Assoc_66
0,n diteurs id_diteur nom_diteur ville rgion pays
0,n magasins id_mag nom_mag adresse_mag ville pays code_postal
Modle Logique de Donnes :

auteurs id_auteur nom_auteur pn_auteur telephone adresse ville pays code_postal titreauteur id_auteur id_titre cmd_auteur droits_pourcent titres id_titre id_diteur titre prix ventes id_mag num_cmd id_titre date_cmd qt modepaiements
lien_29
lien_30
Assoc_54
est dit par
Assoc_66
diteurs id_diteur nom_diteur ville rgion pays
magasins id_mag nom_mag adresse_mag ville pays code_postal
BDD 23/77
14/01/07
3 - Manipulation dune BDD Langage de dfinition SQL Base De Donnes Pubs Exercices :
. Liste des magasins franais (FR) dans lordre alphabtique des villes . Liste des titres des auteurs trangers . Nombre de titres par auteur tranger . Dans quel pays sont vendus les titres des auteurs trangers (liste par auteur et par pays) . Hit parade des ventes par auteur (liste dcroissante, les ventes sont apprcies en quantit) . Chez quels diteurs sont publis les auteurs (liste par auteur et diteur) . Cumul des ventes par magasin et par mois
BDD 24/77
14/01/07
3 - Manipulation dune BDD
Base de donnes PROFOR
FILIERE_SECTEUR = UEP_SECTEUR FILIERE_NO = UEP_NO
TUEP UEP_ETAB UEP_SECTEUR UEP_NO RESPUEP NBPROF char(3) char(2) char(2) char(5) int AN NBMOIS NBSEMAN TDG int decimal(5,3) decimal(5,3)
TREG REG REGNOM char(2) char(30)
REG = REG
TDEPT DEPT DEPTNOM REG char(2) char(30) char(2) TSTATUT

PERS = RESPUEP
NIVEAU = NIVEAU DEPT = DEPT ETAB = UEP_ETAB
NIVEAU HEBDO TXSUP TXRET NIVNOM
char(2) int int int char(20)
TETAB ETAB RESPETAB DEPT ETABNOM char(3) char(5) char(2) char(30)

ETAB = UEP_ETAB PERS = PERS
TPERS PERS UEP_ETAB UEP_SECTEUR UEP_NO FILIERE_SECTEUR FILIERE_NO NIVEAU PERSNOM PERSPREN DATNAIS ETATCIVIL NBENF SALMENS DATEENT DATEETAB char(5) char(3) char(2) char(2) char(2) char(2) char(2) char(30) char(30) date char(1) int decimal(8,3) date date TACT PROG char(3) PERS char(5) DATEACT date DUREE integer NBSTAG integer
PERS = RESPETAB ETAB = CPTA
PROG = PROG PERS = RESPPROG
PERS = RESPSECTEUR
TSECTEUR SECTEUR RESPSECTEUR SECTNOM CPTA char(2) char(5) char(20) char(3)
TPROG PROG SPECIA RESPPROG DATEDEBUT DATEFIN CAPPROG char(3) char(5) char(5) date date int
SECTEUR = FILIERE_SECTEUR
TGTS FILIERE_SECTEUR FILIERE_NO FILIERENOM char(2) char(2) char(30)
FILIERE_SECTEUR = FILIERE_SECTEUR FILIERE_NO = FILIERE_NO SPECIA = SPECIA
FILIERE_SECTEUR = FILIERE_SECTEUR FILIERE_NO = FILIERE_NO
TSPECIA SPECIA char(5) FILIERE_SECTEUR char(2) FILIERE_NO char(2) SPENOM char(20) DURMIN int DURMAX int CHST decimal(4,3) RATENCADR int NIVQUALIF char(3)
BDD 25/77
14/01/07
BDD 26/77
14/01/07
BDD 27/77
14/01/07
BDD 28/77
14/01/07
BDD 29/77
14/01/07
BDD 30/77
14/01/07
BDD 31/77
14/01/07
BDD 32/77
14/01/07
BDD 33/77
14/01/07
BDD 34/77
14/01/07
BDD 35/77
14/01/07
BDD 36/77
14/01/07
BDD 37/77
14/01/07
BDD 38/77
14/01/07
BDD 39/77
14/01/07
BDD 40/77
14/01/07
BDD 41/77
14/01/07
BDD 42/77
14/01/07
BDD 43/77
14/01/07
BDD 44/77
14/01/07
BDD 45/77
14/01/07
BDD 46/77
14/01/07
BDD 47/77
14/01/07
4 - Traitements dans les BDD

1 - Procdures Une procdure stocke ou procdure mmorise ou stored procedure est un ensemble dinstructions SQL prcompiles et mmorises dans le dictionnaire. Elle sera excute chaque fois quon lappelle. Cration dune procdure : CREATE PROCEDURE new_dpt (IN id INT, IN nom CHAR(35), IN reg INT) BEGIN INSERT INTO departement(dept_id, dept_nom, dept_reg) VALUES(id, nom, reg) ; END Appel de la procdure : CALL new_dpt (59, Nord, 15) ; Suppression de la procdure : DROP PROCEDURE new_dpt ; Procdure retournant un rsultat paramtr: CREATE PROCEDURE SalaireMoyen (OUT salmoy DECIMAL(12,2)) BEGIN SELECT AVG(salaire) INTO salmoy FROM employ ; END Appel de la procdure : CREATE VARIABLE moyenne NUMERIC(12,2) CALL SalaireMoyen (moyenne) ; Procdure paramtre retournant une srie : CREATE PROCEDURE ListeSalaire (IN dpt INT) RESULT ( Numro INT, Salaire NUMERIC(12,2)) BEGIN SELECT emp_num, emp_salaire FROM employ WHERE emp_dept = dpt; END Appel de la procdure : CALL ListeSalaire (59) ;
BDD 48/77
14/01/07

2 - Fonctions Cration dune fonction : CREATE FUNCTION nomComplet (prenom CHAR(20), nom CHAR(20)) RETURNS CHAR(41) BEGIN DECLARE varNom CHAR(41) ; SET varNom = prenom || || nom ; RETURN (varNom) ; END Utilisation de la fonction : SELECT nomComplet(emp_prenom, emp_nom) FROM employe ; Suppression de la fonction : DROP FUNCTION nomComplet ;
BDD 49/77
14/01/07

3 - Triggers Un trigger est une procdure compile, catalogue dans le dictio nnaire, qui sexcute automatiquement chaque fois que lvnement dclenchant associ se produit : before update, after update, before insert, after insert, before delete, after delete. Cration dun trigger : CREATE TRIGGER controleDate AFTER INSERT, UPDATE ON employe REFERENCING NEW AS new_employe FOR EACH STATEMENT BEGIN DECLARE erreur EXCEPTION FOR SQLSTATE 99999 ; IF new_employe.dateNais > now THEN SIGNAL erreur ; END IF ; EXCEPTION WHEN erreur THEN MESSAGE Date naissance suprieure date du jour ! ; SIGNAL erreur ; WHEN OTHERS THEN MESSAGE Problme de maj de la table employe ; RESIGNAL ; END Excution du Trigger : INSERT INTO employe (, dateNais, .) VALUES () ; UPDATE employe SET dateNais = ; Suppression du Trigger : DROP TRIGGER controleDate
BDD 50/77
14/01/07
6 - Accs aux BDD dans les langages htes

Techniques abordes : - ODBC - SGBD : SQL Server (Windows NT) - Visual Basic : contrle ADODC - Transaction : BeginTrans, CommitTrans, RollBack - ordres SQL : Select, Insert, Update, Delete
Ralisations : Raliser une application permettant de grer un fichier rpertoire sur SQL Server via OLEDB. - Structure de la Base De Donnes "repertoire" : Table "individu" reprenant les champs suivant : - id_individu num(4,0) cl primaire (autoincrement) - nomprenom char(30) - adresse char (90) not null - telephone char (15) not null - A partir du contrle ADODC, crer une chane de connexion OLE DB permettant daccder la Base De Donnes SQL Server "repertoire" se trouvant sue le serveur PC093 :
BDD 51/77
14/01/07
Script de connexion :
Provider=MSDASQL.1;Persist Security Info=False;User ID=invit;Extended Properties="DRIVER=SQL Server;SERVER=pc093;APP= Visual Basic;WSID=PC093;DATABASE=repertoire;Trusted_Connection=Yes"
BDD 52/77
14/01/07
Projet : Ajouter le composant Microsoft ADO Data Control 6.0 (SP3) OLE DB
Module : Crer une instance dobjet de type global partir de la classe ADODB.Connection
Feuille de connexion :
Sur Click du bouton OK, ouvrir la connexion de la BDD repertoire et afficher la feuille de consultation. En cas dchec, envoyer un message derreur.
Feuille de consultation : des zones de texte pour la gestion des donnes du fichier Individu. un contrle ADODC pour l'accs au fichier "INDIVIDU". un bouton Quitter pour fermer la Base de Donnes et quitter l'application. un bouton Supprimer pour supprimer lenregistrement en cours. un bouton Modifier pour modifier lenregistrement en cours. un bouton Nouveau pour ajouter un nouvel individu.
Sur le contrle ADODC, prciser la chane de connexion et crire la requte permettant de slectionner tous les individus de la table individu dans lordre croissant des nom/prnom.
BDD 53/77
14/01/07
Feuille de modification : Sur le bouton Valider, excuter l'instruction SQL Update
Feuille de Confirmation de suppression : Sur le bouton Ok, excuter l'instruction SQL Delete
Feuille de cration : Sur le bouton Valider, excuter l'instruction SQL Insert
Vrifier la prsence du nom sur les crans de modification et d'ajout d'un nouvel individu :
BDD 54/77
14/01/07
BDD 55/77
14/01/07
Bases De Donnes Elments de correction

. Conception dune BDD Relationnelle
. Construction dune BDD
. Manipulation dune BDD
. Traitements dans les BDD
. Scurits des BDD
. Accs aux BDD dans les langages htes
BDD 56/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Note
Elve appartient
1,1
id_lve Nom Prnom Adresse
0,n
a pour note note
1,n
0,n
Classe id_salle classe

1,n
a pour matire nbre heures
Matire
1,n
id_matire matire
1,1
est enseigne par
Professeur
1,n
id_prof professeur
Elve
appartient
id_lve id_salle Nom Prnom Adresse
lien_35
a pour note id_lve id_matire note
lien_36
Classe id_salle classe

lien_29
a pour matire id_salle id_matire nbre heures

lien_30
Matire id_matire id_prof matire

est enseigne par
Professeur id_prof professeur
BDD 57/77
14/01/07
%% ============================================================ %% Nom de la base : CAS_NOTE %% Nom de SGBD : Sybase SQL Anywhere %% Date de cration : 24/08/100 18:06 %% ============================================================ dbtool create database 'CAS_NOTE.db' transaction log to 'CAS_NOTE.log'; connect to 'CAS_NOTE.db' user "dba" identified by sql; %% ============================================================ %% Table : CLASSE %% ============================================================ create table CLASSE ( ID_SALLE char(10) not null, CLASSE char(10) not null, primary key (ID_SALLE) ); %% ============================================================ %% Table : PROFESSEUR %% ============================================================ create table PROFESSEUR ( ID_PROF numeric(3) not null, PROFESSEUR char(40) not null, primary key (ID_PROF) ); %% ============================================================ %% Table : ELEVE %% ============================================================ create table ELEVE ( ID_ELEVE numeric(6) not null, ID_SALLE char(10) not null, NOM_ELEVE char(20) not null, PRENOM_ELEVE char(20) not null, ADRESSE_ELEVE char(80) , primary key (ID_ELEVE) ); %% ============================================================ %% Table : MATIERE %% ============================================================ create table MATIERE ( ID_MATIERE numeric(4) not null, ID_PROF numeric(3) not null,
BDD 58/77
14/01/07
MATIERE char(40) primary key (ID_MATIERE) );
not null,
%% ============================================================ %% Table : A_POUR_MATIERE %% ============================================================ create table A_POUR_MATIERE ( ID_SALLE char(10) not null, ID_MATIERE numeric(4) not null, NBRE_HEURES numeric(2) , primary key (ID_SALLE, ID_MATIERE) ); %% ============================================================ %% Table : A_POUR_NOTE %% ============================================================ create table A_POUR_NOTE ( ID_ELEVE numeric(6) not null, ID_MATIERE numeric(4) not null, NOTE numeric(4,2) , primary key (ID_ELEVE, ID_MATIERE) ); alter table ELEVE add foreign key FK_ELEVE_APPARTIEN_CLASSE (ID_SALLE) references CLASSE (ID_SALLE) on update restrict on delete restrict; alter table MATIERE add foreign key FK_MATIERE_EST_ENSEI_PROFESSE (ID_PROF) references PROFESSEUR (ID_PROF) on update restrict on delete res trict; alter table A_POUR_MATIERE add foreign key FK_A_POUR_M_LIEN_29_CLASSE (ID_SALLE) references CLASSE (ID_SALLE) on update restrict on delete restrict; alter table A_POUR_MATIERE add foreign key FK_A_POUR_M_LIEN_30_MATIERE (ID_MATIERE) references MATIERE (ID_MATIERE) on update restrict on delete restrict; alter table A_POUR_NOTE add foreign key FK_A_POUR_N_LIEN_35_ELEVE (ID_ELEVE) references ELEVE (ID_ELEVE) on update restrict on delete restrict; alter table A_POUR_NOTE add foreign key FK_A_POUR_N_LIEN_36_MATIERE (ID_MATIERE) references MATIERE (ID_MATIERE) on update restrict on delete restrict;
BDD 59/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Niche
BDD 60/77
14/01/07
1 - Conception dune BDD Relationnelle Cas FAP
BDD 61/77
14/01/07
1 - Conception dune BDD Relationnelle Cas Rservation Htel
BDD 62/77
14/01/07
3 - Manipulation dune BDD Langage de dfinition SQL Base De Donnes Pubs

1 - Select nom_mag, ville from magasins where pays = FR order by ville 2 - Select titre, nom_auteur, pn_auteur, pays From titres a, titreauteur b, auteurs z Where a.id_titre = b.id_titre and b.id_auteur = c.id_auteur and pays <> FR Order by pays, nom_auteur, pn_auteur 3 - Select nom_auteur, pn_auteur, pays, count(*) From titreauteur a, auteurs b Where a.id_auteur = b.id_auteur and pays <> FR Group by nom_auteur, pn_auteur, pays Order by pays, nom_auteur, pn_auteur 4 - Select distinct a.pays, nom_auteur, pn_auteur, d.pays From magasins a, ventes b, titreauteur c, auteurs d Where a.id_mag = b.id_mag and b.id_titre = c.id_titre and c.id_auteur = d.id_auteur and d.pays <> FR Order by nom_auteur, pn_auteur, a.pays 5 - Select nom_auteur, pn_auteur, sum(qt) From auteurs a, titreauteur b, ventes c Where a.id_auteur = b.id_auteur and b.id_titre = c.id_titre Group by nom_auteur, pn_auteur Order by 3 desc 6 - Select distinct nom_editeur, nom_auteur, pn_auteur From editeurs a, titres b, titreauteur c, auteurs d Where a.id_editeur = b.id_editeur and b.id_titre = c.id_titre and c.id_auteur = d.id_auteur Order by nom_auteur, pn_auteur, nom_editeur 7 - Select month(date_cmd) as mois, nom_mag, sum(qt) From magasins a, ventes b Where a.id_mag = b.id_mag Group by mois, nom_mag Order by 2, 1
BDD 63/77
14/01/07
3 - Manipulation dune BDD Langage de dfinition SQL Base De Donnes Profor

% Exo 1 % Liste des noms de personnes des tablissements 1 et 74 select persnom from tpers where uep_etab = '001' or uep_etab = '074'
% Exo 2 % Liste des numros et noms des personnes de l'tablissement 001 % entrs dans cet tablissement entre 75 et 80 select pers, persnom, dateetab from tpers where uep_etab = '001' and dateetab between '1975/01/01' and '1980/12/31'
% Exo 3 % Liste des personnels ayant un T et un O dans leur nom select persnom from tpers where persnom like '%T%' and persnom like '%O%'
% Exo 4 % Liste des personnels ayant deux E dans leur nom select persnom from tpers where persnom like '%E%E%'
% Exo 5 % Liste des personnels ayant un code filire qui le mme que le code UEP select persnom, pers, filiere_secteur, filiere_no, uep_secteur, uep_no from tpers where filiere_secteur = uep_secteur and filiere_no = uep_no and filiere_secteur is not null
BDD 64/77
14/01/07
% Exo 6 % Liste des noms des personnels, numro d'tablissement, salaire et numro d'UEP % tris par numro d'tablissement en croissant, % numro d'UEP en dcroissant, % salaire en dcroissant % et ceci uniquement quant le numro d'UEP est fourni. select distinct uep_etab, uep_secteur, uep_no, salmens, persnom from tpers where uep_secteur is not null and uep_no is not null order by uep_etab, uep_secteur desc, uep_no desc, salmens desc
% Exo 7 % Liste des personnels travaillant dans l'tablissement de Saint-Avold % Le code de Saint- Avold est suppos non connu. select pers, persnom, perspren from tpers, tetab where uep_etab = etab and etabnom = 'Saint-Avold' % Exo 7 bis % Liste des personnels travaillant en Seine et Marne
select pers, persnom, perspren from tpers, tetab, tdept where uep_etab = etab and tetab.dept = tdept.dept and deptnom = 'Seine et Marne'
% Exo 8 % Liste des personnes rattaches une UEP (GTS) avec le nom de cette UEP % et le nom du secteur de rattachement. select persnom, perspren, filierenom, sectnom from tpers p, tgts u, tsecteur where p.filiere_secteur = u.filiere_secteur and p.filiere_no = u.filiere_no and u.filiere_secteur = secteur
BDD 65/77
14/01/07
% Exo 9 % Liste des noms de personne qui sont entrs dans l'organisme avant Dominique PESSON select a.persnom, a.dateent, b.dateent from tpers a, tpers b where b.persnom = 'PESSON' and a.dateent < b.dateent
% Exo 10 % Liste des noms de personne qui sont entres la mme anne que Dominique PESSON select a.persnom, a.dateent from tpers a, tpers b where b.persnom = 'PESSON' and b.perspren = 'Dominique' and year(a.dateent) = year(b.dateent) and a.pers <> b.pers
% Exo 11 % Liste des noms de spcialits qui ont le mme niveau de quallification que OVNI select spenom, nivqualif from tspecia where nivqualif in (select nivqualif from tspecia where spenom = 'OVNI') and spenom <> 'OVNI'
% Exo 12 % Liste des personnes qui sont entres avant toutes celles qui sont dans % l'tablissement 001 select persnom,pers, dateent from tpers where dateent < all (select dateent from tpers where uep_etab = '001')
BDD 66/77
14/01/07
% Exo 13 % Liste des personnes ayant le mme niveau dans le mme tablissement que % Jacques DEODAT select persnom,pers, niveau, uep_etab from tpers where persnom <> 'DEODAT' and niveau in (select niveau from tpers where persnom = 'DEODAT') and uep_etab in (select uep_etab from tpers where persnom = 'DEODAT')
% Exo 13 bis % Liste des personnes ayant le mme niveau dans un mme tablissement select a.persnom, a.pers, nivnom, etabnom from tpers a, tpers b, tstatut c, tetab d where a.niveau = b.niveau and a.pers <> b.pers and a.uep_etab=etab and a.niveau=c.niveau and a.uep_etab = b.uep_etab
% Exo 14 % Liste des noms des responsables d'tablissement dans lesquels %certaines uep n'ont pas de responsable, en indiquant les uep select persnom, etabnom, a.uep_secteur, a.uep_no from tpers , tetab , tuep a where respuep is null and a.uep_etab = etab and pers = respetab
% Exo 15 % Liste des noms des responsables d'tablissement dans lesquels %certaines uep n'ont pas de responsable, en indiquant le nombre d'uep % par tablissement select persnom, etabnom, nbuepvide = count(a.uep_secteur+a.uep_no) from tpers , tetab , tuep a where respuep is null and a.uep_etab = etab and pers = respetab group by persnom, etabnom
BDD 67/77
14/01/07
% Exo 16 % Liste des noms des personnes avec leur salaire arrondi au millier de francs infrieur % que l'on nommera salmil select persnom, salmil=ceiling("truncate"(salmens,0)) from tpers
% Exo 17 % Liste des salaires des personnels en masquant ceux de l'tablissement 112 % avec des toiles select persnom, salaire = ('***************') from tpers where uep_etab='112' union select persnom, salaire=string(salmens) from tpers where uep_etab<>'112'
% Exo 18 % Liste des codes et noms de dpartement qui ont plus d'un tablissement rattach select dept, deptnom from tdept where dept in (select dept from tetab group by dept having count(etab)> 1)
% Exo 19 % Liste des numros de programmes des actions lmentaires avec les dates %de dbut de mois de l'action, classes par dates de dbut d'action select mois = date(dateact - day(dateact)+1), prog from tact where dateact is not null order by mois
BDD 68/77
14/01/07
% Exo 20 % Liste des personnels( numro nom tat civil nombre d'enfants) avec le nombre %de mois depuis leur entre dans l'tablissement, classe par tablissement %et par ancinnet dans l'tablissement select pers, persnom, etatcivil, nbenf, uep_etab, nbmois = (months(now(*)) - months(dateetab)) from tpers order by uep_etab, nbmois
% Exo 21 %Donner par tablissement et par uep d'un tablissement, les salaires annuels %moyens en 1991. L e nombre de mois de paye dans l'anne de rfrence %est dans la table des donnes gnrales select uep_etab, uep_secteur, uep_no, moysal =cast(avg(salmens*nbmois) as integer) from tpers, tdg where an = 1991 group by uep_etab, uep_secteur, uep_no order by 1, 2, 3
% Exo 22 %Liste des n et noms de personnes qui sont entres dans l'organisme avant d'entrer %dans l'tablissement en indiquant leur anciennet en mois ce moment l select pers, persnom, perspren, anciennete = months(dateetab) - months(dateent) from tpers where dateetab > dateent
% Exo 23 %Tout le personnel de niveau 40 va voir son salaire augmenter de 10%. %remettre la base de donnes en tat commit; update tpers set salmens = salmens*1.1 where niveau = 40; select persnom, perspren, salmens from tpers where niveau = 40; rollback
BDD 69/77
14/01/07
% Exo 24 %Crer une vue avec nom de rgion, rfrence, et noms des spcialits %pratiques dans cette rgion %utiliser cette vue pour obtenir le nombre de spcialits par rgion, %puis la liste de ces noms de spcialits par rgions. %ensuite dtruire la vue create view regspe as select specia, spenom, regnom from tspecia, tgts, tuep, tetab, tdept, treg where tspecia.filiere_secteur = tgts.filiere_secteur and tspecia.filiere_no = tgts.filiere_no and tuep.uep_secteur = tgts.filiere_secteur and tuep.uep_no = tgts.filiere_no and tuep.uep_etab = tetab.etab and tetab.dept = tdept.dept and tdept.reg = treg.reg; select regnom, nbspe = count(*) from regspe group by regnom; drop view regspe;
% Exo 25 %donner par tablissement et par uep, les salaires annuels moyens de 1990. %A chaque tablissement, associer son nom et chaque uep, le nom de la %filire correspondante. drop view moyetab; drop view moyuep; create view moyetab(etab, smae) as select uep_etab, moysaletab = cast(round(avg(salmens*nbmois),3) as integer) from tpers, tdg where an = 1990 group by uep_etab; create view moyuep(etab, uep_secteur, uep_no, smau) as select uep_etab, uep_secteur, uep_no, moysaluep = cast(round(avg(salmens*nbmois),3) as integer) from tpers, tdg where an = 1990 group by uep_etab, uep_secteur, uep_no; select tetab.etab, tetab.etabnom, tgts.filierenom, moyuep.smau, moyetab.smae from tetab, moyetab, moyuep left outer join tgts on ( moyuep.uep_secteur = tgts.filiere_secteur and
BDD 70/77
14/01/07
moyuep.uep_no = tgts.filiere_no) where moyetab.etab = tetab.etab and moyuep.etab = tetab.etab order by tetab.etab;
% Exo 26 %Crer la procdure stocke lstetab qui renvoie les n, nom % et prnom des personnes d'un tablissement donn. % Le n tablissement est le paramtre. %Les colonnes retournes s'appelleront ppersno, ppersnom, pperspren. % Essayer la procdure. create procedure lstetab (in etabno char(3)) result ( " ppersno" char(5), "ppersnom" char(30), "pperpren" char(30) ) begin select pers, persnom, perspren from tpers, tetab where etab = etabno and etab = uep_etab; end
% Exo 27 % Crer une fonction permettant de concatner le prnom et le nom d'une personne % en supprimant les espaces inutiles %Essayer cette fonction sur les personnes de Saint Avold create function fullname (perspren char(30), persnom char(30)) returns char(61) begin declare nom char(61); set nom = perspren || ' ' || persnom; return(nom); end
% Exo 28 % Crer une fonction permettant de concatner le secteur et le no d'une filire create function filiere (sec char(2), no char(2)) returns char(4) begin declare nfiliere char(4); set nfiliere = sec + no; return(nfiliere); end
BDD 71/77
14/01/07
% Exo 29 % Lister les personnes (nom et prnom) en indiquant le nom deleur filire. % Utiliser les fonctions des exos 27 et 28 select personne = fullname(perspren, persnom), filiere = filierenom from tpers, tgts where filiere(tpers.filiere_secteur, tpers.filiere_no) = filiere(tgts.filiere_secteur, tgts.filiere_no)
%exo30 %Crer un trigger permettant de contrler que la date d'tablissement est suprieure %ou gale la date d'entre lors de la mise jour d'une personne (insert, update) create trigger verif_entre_majpers before update, insert on tpers referencing new as new_tpers for each row begin declare err_1 exception for sqlstate '99999'; if new_tpers.dateetab < new_tpers.dateent then signal err_1; end if; exception when err_1 then message 'Erreur: Trigger(verif_entre_majpers) de la table TPERS'; message ' La date tablissement infrieure date entre !'; signal err_1; when others then message 'Exception dans trigger(verif_entre_majpers) avant insertion de la table TPERS'; resignal; end
BDD 72/77
14/01/07
6 - Accs aux BDD dans les langa ges htes

Module Module1 Global cnn As New ADODB.Connection
Page de connexion frmLogin Option Explicit Sub ouvertureBdd() On Error GoTo ErreurConnexion cnn.Open "Provider=MSDASQL.1;Persist Security Info=False;User ID=pc093\invit;Extended Properties='DRIVER=SQL Server;SERVER=pc093;APP=Visual Basic;WSID=PC093;DATABASE=repertoire;Trusted_Connection=Yes'" Exit Sub ErreurConnexion: MsgBox "Erreur " & Err & ": " & Error End Sub Private Sub cmdCancel_Click() End End Sub Private Sub cmdOK_Click() MousePointer = vbArrowHourglass ouvertureBdd Me.Hide FrmIndividu.Show End Sub
Page de consultation frmIndividu Dim book As Variant Private Sub CmdModifier_Click() With Adodc1.Recordset vMyBookMark = .Bookmark End With FrmModifier.Show End Sub Private Sub CmdNouveau_Click() FrmNouveau.Show End Sub
BDD 73/77
14/01/07
Private Sub CmdQuitter_Click() End End Sub Private Sub CmdSupprimer_Click() Dim Rponse As Integer Dim strDelete As String On Error GoTo ErreurDelete Rponse = MsgBox("Confirmez-vous la suppression ?", vbOKCancel, "Suppression") If Rponse = vbOK Then cnn.BeginTrans With cnn strDelete = "delete from INDIVIDU where id_individu = " & Adodc1.Recordset.Fields(0) .Execute strDelete End With cnn.CommitTrans MousePointer = vbArrowHourglass Adodc1.Refresh MousePointer = vbDefault FrmIndividu.Caption = "Rpertoire de " & Adodc1.Recordset.RecordCount & " individus" End If Exit Sub ErreurDelete: cnn.RollbackTrans MsgBox "Incident lors du Delete : " & Err & " " & Error End Sub Private Sub Form_Activate() MousePointer = vbArrowHourglass With Adodc1 .Refresh FrmIndividu.Caption = "Rpertoire de " & .Recordset.RecordCount & " individus" If vMyBookMark <> 0 Then .Recordset.Bookmark = vMyBookMark End If End With MousePointer = vbDefault End Sub Private Sub Form_Load() MousePointer = vbDefault End Sub Private Sub Form_Terminate() cnn.Close
BDD 74/77
14/01/07
End Sub Public Property Get id() As Double id = Adodc1.Recordset.Fields(0) End Property
Public Property Get vMyBookMark() As Variant vMyBookMark = book End Property Public Property Let vMyBookMark(ByVal vNewValue As Variant) book = vNewValue End Property
Page de cration frmNouveau Private Sub CmdQuitter_Click() End End Sub Private Sub CmdRetour_Click() Unload Me End Sub Private Sub CmdValider_Click() Dim strInsert As String If txtNomPrnom = "" Then MsgBox "Nom obligatoire" txtNomPrnom.SetFocus Exit Sub End If On Error GoTo ErreurInsert With cnn .Beg inTrans strInsert = "insert into INDIVIDU values('" & txtNomPrnom.Text & "', '" strInsert = strInsert & txtAdresse.Text & "', '" & TxtTlphone.Text & "')" .Execute strInsert .CommitTrans End With txtNomPrnom = "" txtAdresse = "" TxtTlphone = "" Exit Sub ErreurInsert: cnn.RollbackTrans MsgBox "Incident lors de l'Insert" & Err & ": " & Error
BDD 75/77
14/01/07
End Sub
Page de modification frmModifier Private Sub CmdQuitter_Click() End End Sub Private Sub CmdRetour_Click() Unload Me End Sub Private Sub CmdValider_Click() Dim strUpdate As String If TxtNomPrnom.Text = "" Then MsgBox "Nom obligatoire" TxtNomPrnom.SetFocus Exit Sub End If On Error GoTo ErreurUpdate With cnn .BeginTrans strUpdate = "update INDIVIDU " strUpdate = strUpdate & "set nomprenom = '" & TxtNomPrnom.Text & "', " strUpdate = strUpdate & "adresse = '" & TxtAdresse.Text & "', " strUpdate = strUpdate & "telephone = '" & TxtTlphone.Text & "' " strUpdate = strUpdate & "where id_individu = " & FrmIndividu.id .Execute strUpdate .CommitTrans End With Unload Me Exit Sub ErreurUpdate: cnn.RollbackTrans MsgBox "Incident lors de l'Update" & Err & ": " & Error End Sub Private Sub Form_Load() Dim strSelect As String Set rs = New ADODB.Recordset With rs strSelect = "select * from individu where id_individu = " & FrmIndividu.id .Open strSelect, cnn TxtNomPrnom.Text = .Fields(1) TxtAdresse.Text = .Fields(2) TxtTlphone.Text = .Fields(3) End With End Sub
BDD 76/77
14/01/07
BDD 77/77
14/01/07

Base de donnes SGBDgeneralitesralits
Gnralits SGBD :
Systmes de Gestion de Base de Donnes
Afpa-St Brieuc
14/01/07
Page 1

SYSTEME DE GESTION DE BASE DE DONNEE
Les bases de donnes : PRESENTATION Pourquoi une base de donnes ? Une entreprise doit conserver la trace dun volume lev dinformations. Ces dernires peuvent tre, par exemple, les noms et salaires des employs, les adresses des fournisseurs, le montant des stocks ou le montant des produits de lexercice. Traditionnellement, diffrentes parties de ces informations sont conserves par diffrents dpartements et/ou diffrents individus, chacun ayant la charge des donnes quil utilise le plus souvent. Pour obtenir une information, il faut dabord dterminer o elle est stocke, puis sadresser au dpartement ou la personne concerne. Les comptables utilisent trs frquemment un grand nombre de donnes concernant lentreprise. Quand il prpare les bilans ou un relev financier, le comptable dispose habituellement de la plupart des informations ncessaires, qui sont le plus souvent contenues dans les grands livres ou les journaux. Cependant, certaines donnes supplmentaires (en particulier lors de la prparation des budgets), telles que les cots standards et unitaires, peuvent ne pas apparatre dans ces documents financiers et comptables. Il faut consulter dautres dpartements pour obtenir des prcisions ou des renseignements supplmentaires. Les entreprises qui ont informatis une grande part de leurs fonctions de gestion ont souvent de nombreux programmes dapplication diffrents, chacun ayant un but diffrent, comme la prparation des bulletins de salaire, la gestion des stocks, la facturation etc. Chacun de ces programmes utilisera vraisemblablement ses propres fichiers contenant les donnes ncessaires.
Afpa-St Brieuc
14/01/07
Page 2

Les systmes manuels ou informatiss en partie ou en totalit que nous venons dvoquer ont plusieurs dfauts majeurs. Dans tous ces systmes, il peut tre ncessaire de s adresser plusieurs dpartements avant de trouver celui qui peut effectivement fournir les donnes. Dautre part, les informations utilises par plusieurs dpartements peuvent tre conserves en plusieurs endroits, ce qui entrane une redondance de stockage, Ceci entrane un gaspillage au niveau du volume des fichiers et des cots supplmentaires souvent levs. En outre, sil y a redondance dans les donnes, toute modification doit tre faite plusieurs fois, afin de maintenir la cohrence entre les diffrents fichiers. Sil se produit une erreur, des incohrences peuvent apparatre. Par exemple, le directeur de la production et le directeur des ventes peuvent conserver tous les deux une trace du stock courant dun article. Au moment de la vente, les deux enregistrements doivent tre mis jour, pour reflter la baisse du stock. Si un des enregistrements indique un stock infrieur ou suprieur la ralit, il peut en rsulter une sous ou surproduction, ou une vente peut tre perdue, avec chaque fois un cot supplmentaire pour lentreprise. Dautres soucis concernent la scurit des donnes et les accs non autoriss des informations confidentielles. Accder linformation est simple sil suffit pour cela douvrir un tiroir de bureau; cependant, les donnes stockes dans une application informatise sont disponibles chaque fois que cette application est utilise. Les programmes d'application tendent aussi utiliser des mthodes de stockage des donnes assez complexes et l'utilisateur doit souvent se proccuper de savoir quel format utiliser pour ses donnes. Pour ces raisons une tendance sest dveloppe pour combiner toutes les informations importantes de lentreprise dans une base de donnes intgre. Dans une base de donnes, le stockage des donnes est entirement centralis. Dans lidal, il nexiste quun exemplaire de chaque lment de donnes. Les mises jour ne sont donc excutes quune seul fois et les problmes dincohrence sont limits.
Afpa-St Brieuc
14/01/07
Page 3

Chaque utilisateur peut ensuite avoir accs aux donnes spcifiques dont il a besoin. On inclut des mesures de protection pour viter que quelquun puisse accder des informations quil nest pas autoris connatre (par exemple, les salaires des employs), et pour rendre immdiatement disponibles les donnes voulues. Chaque dpartement dispose dun ou plusieurs programmes dapplication, pour lire les donnes, traiter les transactions et effectuer les mises jour. Les complexits du stockage ne sont pas apparentes pour lutilisateur, qui na connaissance que des donnes dont il a besoin.
Quest-ce quune base de donnes? Le premier problme auquel on se trouve confront est de dterminer prcisment ce que recouvrent les termes "base de donnes" et "systme de gestion de bases de donnes" (SGBD). Un usage non-averti de ces termes peut se rfrer en fait toute une collection de donnes accessible par lintermdiaire dun ordinateur. Une base de donnes a trois caractristiques essentielles. Cest dabord un ensemble organis et intgr de donnes. Elle correspond ensuite une reprsentation fidle des donnes et de leur structure, avec le minimum possible de contraintes imposes par le matriel. On doit enfin pouvoir lutiliser pour toutes les applications pratiques dsires sans duplication de donnes. Il existe trois types de bases de donnes : hirarchiques, rseaux, relationnelles. Les caractristiques lies chacun de ces types sont dveloppes plus loin. Le Systme de Gestion de Base de Donnes est le logiciel qui supporte une telle organisation des donnes. On peut le dfinir plus prcisment comme, un ensemble de logiciels fournissant l'environnement pour dcrire, mmoriser, manipuler et traiter des ensembles de donnes tout en assurant pour celle-ci la scurit, la confidentialit et lintgrit (la notion d'intgrit est proche de celle dexactitude de cohrence), sachant quun grand nombre dutilisateurs ayant des besoins varis interagit avec ces ensembles de donnes.
Afpa-St Brieuc
14/01/07
Page 4

Les dfinitions sont cependant de peu dintrt pour dterminer si un systme est vraiment un SGBD ou s'il sagit simplement dun systme dinformation classique ou dun systme de fichiers. Il faut mieux dfinir le SGBD en prcisant certaines des fonctions quil doit remplir : lintgration des donnes afin dviter lincohrence dventuelles donnes dupliques (tout est intgr dans un seul ensemble cohrent) ; la sparation entre les moyens de stockage physique des donnes et la logique des applications ; un contrle unique de toutes les donnes afin de permettre lutilisation simultane par plusieurs utilisateurs ; la possibilit dutiliser des structures de fichiers et des mthodes daccs complexes, de faon ce que les relations correctes entre les donnes puissent tre exprimes et les donnes utilises le plus efficacement dans un grand nombre dapplications ; des facilits pour le stockage, la modification, le rorganisation, lanalyse et la consultation des donnes, sans que le systme impose des restrictions lutilisateur ; des contrles de scurit afin dempcher laccs illgal certaines donnes ; des contrles dintgrit pour prvenir une modification indue des donnes (exemple: contrle dexactitude, de validit) ; la compatibilit avec les principaux langages de programmation, les programmes-sources existants, et les donnes extrieures la base. Les SGBD les plus volus actuellement disponibles disposent de la plupart de ces fonctions, mais pas toutes. Il en rsulte des diffrences significatives entre leurs caractristiques, leur fonctionnement et leurs usages possibles.
Afpa-St Brieuc
14/01/07
Page 5

Il convient de signaler galement que les bases de donnes sont plus quune nouvelle technique de stockage et de manipulation des donnes. Elles impliquent une nouvelle approche de la conception et de lutilisation des systmes dinformation et peuvent avoir des consquences organisationnelles qui sortent largement du cadre du service informatique. Elles obligent les utilisateurs considrer les donnes comme une ressource de l'entreprise qui doit tre gre comme le sont les ressources traditionnelles (personnel, locaux, moyens de production, capitaux) pour tre accessible un grand nombre dutilisateurs.
Diffrences entre les bases de donnes et les systmes traditionnels de gestion des fichiers Les caractristiques principales dune base de donnes sont : lindpendance de la structure des donnes par rapport aux programmes de traitement (cette structure de donnes est prvue une fois pour toutes, pour tous les programmes : une base de donnes peut et doit voluer mais doit vivre des priodes stables assez longues de 6 mois un an) ; la prise en compte des relations entre les diffrentes donnes (chanages) ; la non-redondance des donnes (en principe !) ; le partage simultan des donnes entre les programmes dapplications ; lentit lmentaire que lon peut lire dans une base de donnes est beaucoup plus petite quun enregistrement de fichier : elle correspond un segment ou record. Compte tenu de ces caractristiques, il est vident que l'approche des systmes traditionnels de fichiers diffre considrablement du concept de base de donnes
Avantages et inconvnients des SGBD
Les gestionnaires de base de donnes de type hirarchique sont apparus la fin des
annes 1960 (comme DL/1, IMS ou Systme 2000). Ces gestionnaires permettent de traiter de faon lgante et efficace une situation trs frquemment rencontre dans la pratique : la dpendance Mono-dimensionnelle. Un exemple type est le problme CLIENT-COMMANDE : chaque client est "propritaire" dun certain nombres de commandes quil a passes.
Afpa-St Brieuc
14/01/07
Page 6

Pourtant, s i on ajoute un tage cette construction, on atteint les limites du hirarchique. En effet, chaque commande se dcompose en "ligne de commande" qui rfrencent un produit et une quantit commande pour ce produit. Le schma hirarchique ne permet dtablir un lien fonctionnel entre la ligne commande et le produit command qu travers une redondance de donne (le code "produit" figure dans la liste des items de lenregistrement LIGNE). On retombe dans la mme ornire quavec un gestionnaire de fichiers. Pourquoi ? Essentiellement parce que le hirarchique ne peut traiter que des situations de dcomposition mono-dimensionnelle alors que nous sommes en prsence dun problme deux dimensions : la quantit dpend la fois de la commande dans laquelle elle existe et aussi du produit qui est rfrenc. Or, un gestionnaire hirarchique interdit un enregistrement davoir plusieurs parents : cest une limitation fonctionnelle, dont nous voyons ici les consquences pratiques
Structure hirarchique
Client
Commande 1
Cde 2
Cde 3
Cde 4
C'est pour lever ce genre de 1 Cde 1 Cde 1 Cde restrictions quun nouveau type de gestionnaire de base de donnes a t dfini en 1971, avec la publication, par un groupe de travail runissant fabricants dordinateurs et utilisateurs, du rapport connu sous le nom de "Codasyl Data Base Task Group Report". Ce rapport reprenait, en les dveloppant, des ides qui venaient dtre mises en uvre par Charles Bachman dans la conception du SGBD IDS sur le matriel Honeywell. Ce rapport eut un retentissement suffisant pour que, peu aprs, deviennent disponibles des SGBD de types rseau, "aux normes Codasyl" aussi clbres maintenant que: IDMS (de Cullinane), IDS II (sur Honeywell), DMS 1100 (Univac), DSMS (Data General) et DBMS (Prime). Dans cette nouvelle gnration de SGBD, on parle dsormais de : type denregistrement et de relation (set) ; toute relation a (au moins) un propritaire et un membre, qui sont des types denregistrement ; et les types d'enregistrement peuvent tre la fois membre et propritaire de relations, sans limitation fonctionnelle. Il faut noter que, dans les deux modles de base dj tudis (hirarchique et rseaux), la souplesse apparente due la possibilit de faire crer par le systme
Afpa-St Brieuc 14/01/07 Page 7
Ligne 1
Ligne 2
Ligne 3

tous les pointeurs dsirs est en fait limite par la ncessit de dfinir , au moment de la cration de la base, lensemble des pointeurs et chemins daccs voulus. Toute modification ultrieure impliquant gnralement une refonte de la base et des programmes dexploitation.
Structure rseau
Afpa-St Brieuc
14/01/07
Page 8

Dautre part, il existe, en plus des problmes techniques, une "composante humaine" fort importante. En effet, si la comprhension dun systme de gestion de base de donnes (SGBD), est la porte de tous ceux qui ont une culture informatique normale, il nen demeure pas moins que la mise en uvre de ce systme est complexe, laborieuse et, tout le moins, riche en embches de toutes sortes et en problmes de dernire minute, mme si lanalyse a t bien mene. On peut distinguer deux types de difficults : dune part, celles qui ont trait la conception et la mise sur pied de la base ; dautre part, celles qui sont lies son utilisation et son volution. Dans le premier cas, lutilisateur est confront au double problme de la dfinition de son application et de la comprhension du SGBD choisi. Il suffit de voir la taille de la documentation technique fournie avec certains produits, IMS dIBM par exemple, pour se rendre compte de la complexit dun logiciel de base de donnes. Lutilisateur va devoir assimiler le langage de commande de son SGBD pour pouvoir dfinir sa base et les chemins daccs. Pas toujours simple ! Dans le second cas, il va sagir des ennuis habituels rencontrs lors de la mise en route dune application informatique, quelle quelle soit. Toutefois, ils vont revtir souvent un caractre de gravit car, contrairement aux applications classiques, celles qui utilisent des bases de donnes seront gnralement dans un contexte "temps rel" avec de nombreux utilisateurs en ligne. Dans ce cas la mise au point est dlicate, car toute modification de la structure de la base entrane automatiquement un "arrt" temporaire de lactivit de la base en question. Il est, en effet, impensable quun utilisateur puisse travailler sur une base que l'on est train de transformer. Une des raisons pour lesquelles ces problmes existent est sans aucun doute lexistence de liens physiques qui doivent tre spcifis au moment de la construction de la base et dont la modification ultrieure nest pas permise par le SGBD sans reconstruction de la base. Cest en effet le systme qui va constituer la base de donnes en stockant les informations que lon va lui fournir dans un ordre li la structure qui aura t dfinie. Les index vont tre construits et stocks galement d'une faon lie lorganisation hirarchique.
On a donc imagin une autre organisation de base de donnes dans laquelle ces
contraintes nexisteraient plus. Pour cela, une notion nouvelle doit se faire jour, celle de base de donnes "relationnelle". Terme la mode, sans doute un peu sotrique pour beaucoup, mais qui finalement va se comprendre sans trop de difficults pour la bonne raison quil est beaucoup plus proche du raisonnement humain, que le terme hirarchique ou arborescent.
Afpa-St Brieuc
14/01/07
Page 9

Prenons donc un exempte calqu sur le raisonnement humain. Un adulte normalement cultiv possde "en mmoire" des millions dinformations ranges dans le cerveau, selon des mcanismes qui, pour la plupart, nous chappent encore totalement. Ces informations peuvent tre de nature diffrentes : mots, sensations, odeurs, bruits et sons, notions abstraites, etc. Lorsque lon nous pose une question ou que la discussion implique une recherche, il va de soi que nous nallons pas consulter la totalit de notre mmoire, ni mme toutes les informations que nous possdons sur le sujet donn, avant de donner notre rponse. Premirement, nous en serions bien incapables et ensuite il nous faudrait un temps rdhibitoire. La raison en est fort simple : le cerveau humain nest absolument pas construit selon les concepts de linformatique actuelle. Sa structure nest pas celle dun disque magntique et sa mmoire nest pas "adressable". Chose curieuse dailleurs puisquil est quand mme possible de retrouver instantanment une information ! Pour lhomme, cest le contenu de la question qui va servir pour dduire la rponse. Il y a un processus dductif qui est loppos du processus inductif utilis dans la recherche sur une base de donnes hirarchise. Lorsquon nous demande quelle est notre profession, il est vident que nous navons pas besoin de passer mentalement en revue tous les mtiers que nous connaissons pour trouver le ntre. Nous le trouvons immdiatement parce que la question est pose de telle faon que les mots "profession" et "ntre" rduisent le champ de recherche son strict minimum. Notons encore quil est possible de poser la mme question sous une bonne centaine de formes diffrentes quant lordre des mots, leur nombre, ou bien la langue employe.
Les bases de donnes relationnelles fonctionnent donc selon ce principe : cest le contenu de la question qui va dterminer quels sont les chemins daccs utiliser, les liens tablir. Ces liens, ou pointeurs, ne seront plus fixs une fois pour toutes dans le SGBD mais ils seront fabriqus dynamiquement selon les besoins. Mais cela nest pas suffisant car il faudra que le langage dinterrogation du systme soit capable de comprendre correctement une question. Pour cela, une seule possibilit : lutilisation des oprateurs logiques de la thorie des ensembles (autre formulation lalgbre relationnelle). Le SGBD agira "par dduction" partir de lanalyse de la question. Telle question implique la consultation des fichiers W et X, telle autre implique la consultation des fichiers Y et Z. Bien entendu, il y aura des liens entre question et fichiers mais ils existeront non comme pointeurs mais comme lments dun tableau gr par le SGBD. Que trouverons-nous dans ce tableau ? Tout simplement les associations entre les divers "champs" ou donnes lmentaires, et les fichiers correspondants. Il sera possible tout moment dajouter ou de supprimer des fichiers dans la base de donnes. Les associations seront faites lors des interrogations de la base, en fonction des noms de donnes spcifis.
Afpa-St Brieuc 14/01/07 Page 10

Par exemple, la donne appele "MATRICULE" se trouve dans les fichiers "PAIE", "HISTORIQUE" et "PERSONNEL". Dans ce cas, toute question faisant intervenir le mot "MATRICULE" quel que soit le contexte, dclenchera le chanage logique des fichiers dsigns. Grce son tableau de relations le SGBD va associer tous les fichiers contenant un ou plusieurs champs spcifis dans la question de lutilisateur. Il est vident quune base de donnes relationnelle prsente des avantages tels que : - Lindpendance des utilisateurs vis vis de la structure logique, la structure physique, la stratgie daccs aux donnes; - La puissance de reprsentation grce conception rigoureuse du schma (approche mthodologique); - La rapidit dcriture du code - La manipulation par des non informaticiens pour des cas simples sinon la connaissance de la structure de la base de donnes et de la matrise de lalgbre relationnelle sont ncessaires. - Lapproche non procdurale permettant un traitement uniforme de la dfinition, de la manipulation et du contrle des donnes - Lvolutivit - La prise en compte des contraintes dintgrit
Afpa-St Brieuc
14/01/07
Page 11
upport de Formation :
Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com Les Systmes de Gestion de Bases de Donnes (SGBD)
SOMMAIRE
SOMMAIRE ......................................................................................................... 1 LES DIFFERENTS SGBD ................................................................................... 3
L'OUTIL BASE DE DONNEES : GENERALITES ................................ ............................ 3 1) Dfinition ................................ ................................ ................................ .................... 3 2) Facteurs l'origine du dveloppement ................................ ................................ ........ 3 3) Rappel sur les systmes de gestion de fichiers ................................ ........................... 3 4) Systme de gestion de base de donnes (SGBD) ................................ ....................... 4
OBJECTIFS DE L'APPROCHE BDD.................................................................. 5

1) INTEGRATION ET CORRELATION ................................ ................................ ........... 5 - redondance d'o danger d'incohrence des donnes ................................ .................... 5 - difficult de mise en place de nouveaux traitements ................................ ..................... 5 2) FLEXIBILITE ................................ ................................ ................................ ............... 5 3) DISPONIBILITE ................................ ................................ ................................ .......... 6 4) SECURITE ................................ ................................ ................................ ................. 6
ARCHITECTURE FONCTIO NNELLE D'UN SGBD : ANSI-SPARC .................... 7

1) NIVEAU CONCEPTUEL ................................ ................................ ............................. 7 2) NIVEAU EXTERNE ................................ ................................ ................................ ..... 9 3) NIVEAU INTERNE ................................ ................................ ................................ ...... 9
FONCTIONNEMENT D'UN SGBD .................................................................... 10

DIFFERENTS LANGAGES D'UN SGBD ................................ ................................ ....... 10 1) Prsentation ................................ ................................ ................................ .............. 10 2) Classification des LMD ................................ ................................ .............................. 11
ROLE DE L'ADMINISTRATEUR DE LA BASE (DBA) ................................ ...... 12 PRESENTATION DES PRINCIPAUX MODELES LOGIQUES.......................... 13
1) LE MODELE HIERARCHIQUE ................................ ................................ ................. 13 2) LE MODELE EN RESEAU ................................ ................................ ........................ 14 3) LE MODELE RELATI ONNEL ................................ ................................ .................... 15 Thorie et dfinitions ................................ ................................ ................................ ..... 16 Objectifs du modle ................................ ................................ ................................ ...... 16 Caractristiques du modle ................................ ................................ ........................... 16 Avantages et inconvnients ................................ ................................ .......................... 17
afpa
auteur
centre Dijon
formation
module
sq/item
type doc millsime sup. form. 14/01/2007
page 1
gen-BD

Support de Formation
afpa
auteur
centre Dijon
formation
module
sq/item
page 2
gen-BD

Les SGBD
LES DIFFERENTS SGBD

L'OUTIL BASE DE DONNEES : GENERALITES 1) Dfinition Le concept Base de Donnes (BDD) apparat vers 1960 suite au nombre croissant d'informations que les entreprises doivent grer et partager (volution dans les systmes informatiques). Historiquement, chaque nouvelle application engendrait ses propres fichiers et ses propres programmes. La cration d'une base de donnes va l'encontre de cette faon de procder ; elle rend possible la centralisation, la coordination, l'intgration et la diffusion de l'information archive. On peut en donner la dfinition suivante : une base de donnes est un ensemble structur de donnes enregistr sur des supports accessibles par l'ordinateur, pour satisfaire simultanment plusieurs utilisateurs de faon slective et en un temps opportun. En fait, une base de donnes enregistre des faits, des vnements qui surviennent dans la vie d'un organisme, pour les restituer la demande ; elle permet galement de tirer des conclusions en rapprochant plusieurs faits lmentaires les uns des autres. Les donnes peuvent tre manipules par plusieurs utilisateurs ayant des vues diffrentes de ces donnes. La structure de l'ensemble requiert une description rigoureuse appele SCHEMA. 2) Facteurs l'origine du dveloppement nombre croissant d'informations grer. volution technologique des mmoires : augmentation des capacits, diminution des temps d'accs. volution des logiciels avec l'apparition sur le march de produits fiables et diversifis. dveloppement des systmes en temps rel. modification dans l'approche des problmes de gestion par les entreprises. (approche globale par des donnes organises de faon rationnelle plutt qu'approche par des tapes bases sur les fonctions raliser). 3) Rappel sur les systmes de gestion de fichiers Les donnes tant stockes sur des supports physiques (fichiers), les diffrents systmes assurent des manipulations 3 niveaux : - support physique (exemple : une sauvegarde de fichiers constitue le passage des donnes d'un support un autre) - structures (oprations d'ouverture de fichier, fermeture, lecture, criture) - contenu (calculs, tests...). L'ensemble de ces fonctions est ralis par: * * des programmes d'application, des units de lecture et/ou d'criture,
afpa
auteur
centre Dijon
formation
module
sq/item
page 3
gen-BD

* des programmes de communication ou d'interface, l'ensemble de ces lments constituant un S.G.F. (systme de gestion de fichiers), que l'on peut reprsenter selon le schma suivant Systme d'expl. Matriel
Prog. d'appl.
Ouvrir, fermer, lire, crire SGF Code rponse (vent. enreg.)

Niveau physique
Demande d'un Units enreg. physique de lecture Enreg. physique et/ou ou code erreur criture
Niveau logique
4) Systme de gestion de base de donnes (SGBD) C'est l'ensemble des programmes et des langages de commande (livrs par le constructeur ou la socit qui commercialise le produit) qui permettent : - la dfinition des diffrents "ensembles de donnes" de la base, et les relations existant entre eux, - le traitement de ces donnes (interrogations, mises jour, calculs, extractions...). Le SGBD reoit des commandes aussi bien des programmes d'application que des utilisateurs; il commande les manipulations de donnes, gnralement par l'intermdiaire d'un SGF. Utilisateur Gestion de la base Programme d'applicat. Ouvrir, fermer, lire, crire SGBD Code rponse (vent. enreg.) SGF Demande d'un Units enreg. physique de lecture Enreg. physique et/ou ou code erreur criture
afpa
auteur
centre Dijon
formation
module
sq/item
page 4
gen-BD

Les SGBD
OBJECTIFS DE L'APPRO CHE BDD

Pour pallier les inconvnients des mthodes classiques (fichiers), les bases de donnes tentent d'atteindre 4 objectifs principaux : intgration et corrlation, flexibilit (indpendance), disponibilit, scurit. La solution ces problmes passe par une distinction nette entre les donnes (avec la structure qui leur est associe), et les procdures de manipulation de ces donnes. Aux donnes, on associera une fonction d'administration des donnes, aux procdures de manipulation une fonction de programmation. 1) INTEGRATION ET CORRELATION Dans les systmes dits "classiques", chaque application gre son propre ensemble de donnes utiles, ses propres "fichiers": il existe donc un risque d'avoir une floraison de fichiers et de programmes disparates, redondants et non compatibles. Il en rsulte plusieurs inconvnients : - redondance d'o danger d'incohrence des donnes la mme donne peut appartenir plusieurs applications, induisant une dperdition de stockage. Toute modification de cette donne est enregistrer plusieurs fois : si cette mise jour multiple n'est pas effectue correctement, les donnes deviennent incohrentes. De plus, les mises jour tant multiples, le cot de la mise jour augmente du fait de la multiplication des entres-sorties physiques. - difficult de mise en place de nouveaux traitements mettre en place de nouvelles applications, non prvues a priori, entrane dans un systme classique, des duplications supplmentaires de donnes. De plus, pour les intgrer avec le reste des applicatifs en exploitation, des modifications, parfois importantes, sont ncessaires. Dans l'approche BDD, un "rservoir" commun (intgration) est constitu, reprsentant une modlisation (corrlation) aussi fidle que possible de l'organisation relle de l'entreprise. Toutes les applications puisent dans ce rservoir les donnes les concernant, vitant les duplications. A l'inverse, le partage des donnes communes par des utilisateurs ayant des besoins diffrents va poser de nouveaux problmes de type contrle de la concurrence d'accs. 2) FLEXIBILITE La notion de flexibilit est essentielle dans la conception de tout systme de taille importante. Dans le cas des BDD, cette notion porte gnralement le nom d'indpendance. Dans les systmes classiques, tout changement intervenant dans le stockage des donnes (support, mthode d'accs physique...) entrane des modifications lourdes (voire une reprogrammation complte !) des applications correspondantes. L'approche BDD poursuit trois objectifs, correspondant au concept d'indpendance des donnes par rapport aux traitements : * indpendance physique: tout changement de support, de mthode d'accs reste transparent au niveau de l'utilisateur.
afpa
auteur
centre Dijon
formation
module
sq/item
page 5
gen-BD

* indpendance logique : les programmes d'application sont rendus transparents une modification dans l'organisation logique globale, par la dfinition de sousschmas couvrant les besoins spcifiques en donnes. * indpendance vis--vis des stratgies d'accs : de plus en plus, l'utilisateur n'a pas prendre en charge l'criture des procdures d'accs aux donnes. Il n'a donc pas intgrer les modifications tendant optimiser les chemins d'accs (ex: cration d'index). 3) DISPONIBILITE Le choix d'une approche BDD ne doit pas se traduire par des temps de traitement plus longs que ceux des systmes antrieurs. En fait, tout utilisateur doit (ou devrait!) pouvoir ignorer l'existence d'utilisateurs concurrents. L'aspect "performance" est donc crucial dans la mise en oeuvre d'une base de donnes. Un tel objectif ne peut tre atteint que si la conception d'une base de donnes est mene de faon rigoureuse avec un dcoupage fonctionnel adquat. Les rgles et contraintes inhrentes sont voques lors de l'apprentissage d'une mthodologie d'analyse (exemple MERISE). 4) SECURITE La scurit des donnes (qui sera dcrite en dtail ultrieurement) est un terme gnrique qui recouvre plusieurs aspects: l'intgrit, ou protection contre l'accs invalide (erreurs ou pannes), et contre l'incohrence des donnes vis--vis des contraintes de l'entreprise. la confidentialit, ou protection contre l'accs non autoris ou la modification illgale des donnes. Pour ne pas affecter les performances de faon sensible, la scurit doit galement tre prise en compte ds la phase de conception.
afpa
auteur
centre Dijon
formation
module
sq/item
page 6
gen-BD

Les SGBD
ARCHITECTURE FONCTIO NNELLE D'UN SGBD : ANSI-SPARC

Dans le cadre du groupe de normalisation nord amricain (ANSI), un groupe d'tudes a t cr en 69, Standard Planning and Requirement Committee (SPARC), avec pour mission, une standardisation des SGBD. Les travaux ont abouti en 75 (ANSI75) par la proposition d'une architecture multi-niveaux : chaque niveau fonctionnel, sont associs un modle et un schma de donnes, un langage de description de donnes (LDD) permettant de dcrire les donnes du schma, et un langage de manipulation de donnes (LMD) permettant de les utiliser (accs pour consultation, mise jour...).
Modle externe
Schma externe
Schma externe
Schma externe
Programmeur d'application
Modle conceptuel
Schma conceptuel
Analyste
Modle interne
Schma interne
Administrateur de la base
1) NIVEAU CONCEPTUEL Il reprsente l'abstraction, aussi fidle que possible, de l'univers de l'entreprise, aprs modlisation et indpendamment de toute rfrence l'utilisation et l'implantation en machine. Ainsi, le modle conceptuel de donnes permet le passage d'un concret inaccessible (l'univers rel) un abstrait manipulable : le schma conceptuel. Celui-ci peut donc tre considr comme la description du contenu de la base; c'est le rsultat d'un travail d'analyse et de conception d'un systme d'information automatis. La structure du systme d'information est dcrite de son point de vue gnral. Un schma conceptuel doit offrir les caractristiques suivantes: - puissance de reprsentation : aspects structurels, contraintes existant dans l'univers rel. - stabilit et flexibilit : l'ajout d'une nouvelle donne ou d'une nouvelle contrainte ne doit pas entraner de changement important dans le schma, ni d'"effet de bord".
afpa
auteur
centre Dijon
formation
module
sq/item
page 7
gen-BD

- simplicit de comprhension : nombre d'lments rduit, dissociation claire des diffrents concepts. - simplicit d'utilisation : nombre restreint d'outils ou de primitives de manipulation. - base formelle : la dfinition du schma doit s'appuyer sur une mthode rigoureuse, mathmatique, pour viter toute ambigut d'interprtation et pour garantir la fiabilit des donnes. Pour aboutir au schma conceptuel, l'analyste doit reprer dans le rel, et recenser de manire exhaustive, toutes les entits et toutes les associations. Une entit peut tre dfinie comme une personne, un objet, un lieu, un statut, un vnement... qui ont une existence dans le monde rel. C'est un objet concret ou abstrait, possdant un certain nombre de caractristiques spcifiques (exemple : le produit x cote y francs). Gnralement, les entits du monde rel se manifestent travers des faits lmentaires. Certains faits font intervenir plusieurs entits concernes, il apparat la notion d'association. Une association (ou lien) est un ensemble de deux ou plusieurs entits, chacune d'elles jouant un rle particulier. Exemple : le fait que la voiture x appartienne la personne y est une association entre les entits "voiture " et "personne y". Selon la notation CODASYL, trois types de liens peuvent tre envisags : - les liens fonctionnels nots N:1. On a un lien N:1 de A vers B si toute occurrence de A dtermine au plus une occurrence de B, et si, toute occurrence de B, correspondent 0,1 ou plusieurs occurrences de A. Exemple : dans une compagnie arienne, connaissant le n d'un vol, on en dduit d'une manire unique la destination, mais plusieurs vols peuvent avoir la mme destination. - les liens hirarchiques nots 1:N. On a un lien 1:N de A vers B si une occurrence de A permet de dterminer 0,1 ou plusieurs occurrences de B et si, une occurrence de B, correspond au plus une occurrence de A. Exemple : la polygamie est un lien 1:N de "homme" vers "femme". - les liens maills nots N:M. Nous avons un lien maill de A vers B s'il n'existe aucune restriction sur le nombre d'occurrences de A et B intervenant dans le lien. Exemple : dans un lyce donn, un enseignant peut tre amen dispenser des cours dans plusieurs matires diffrentes; de la mme faon, une matire donne peut tre dispense par plusieurs enseignants.
afpa
auteur
centre Dijon
formation
module
sq/item
page 8
gen-BD

Les SGBD
Remarque : les cardinalits dans les MCD du formalisme MERISE ne correspondent pas forcment cette reprsentation.
2) NIVEAU EXTERNE Ce niveau logique comprend les "vues" spcifiques dfinies pour la manipulation des donnes ; il prend en compte les contraintes d'accs imposes par la nature des applications considrer (indpendamment des caractristiques techniques) ; il exprime les besoins en donnes des diffrents utilisateurs. L'objectif satisfaire ce niveau est l'optimisation globale des accs par rapport aux applications ; d'autre part, la manipulation des donnes doit tre trs simple puisque l'utilisateur interagit au niveau externe. Le modle de donnes utilis ce niveau externe peut diffrer de celui utilis au niveau conceptuel. Ainsi, certaines vues peuvent ne pas tre construites dans la base, mais dduites par calcul partir de certaines donnes du schma conceptuel (exemple : anciennet obtenue par diffrence entre anne en cours et annne d'embauche dans la socit). Certaines associations entre donnes peuvent galement tre diffrentes, voire inverses. 3) NIVEAU INTERNE Il correspond la reprsentation en machine, aussi efficace que possible, du schma conceptuel ; le schma physique intgre les caractristiques techniques (SGBD, matriel). L'efficacit doit tenir compte d'une part des contraintes d'implantation, d'autre part des critres d'utilisation.
afpa
auteur
centre Dijon
formation
module
sq/item
page 9
gen-BD

FONCTIONNEMENT D'UN SGBD

La chronologie des oprations lmentaires effectues lors d'une demande de donne de la base par un programme est la suivante : - un programme d'application A met une demande de lecture d'une donne (ou d'un groupe de donnes) de la base : la demande est transmise au SGBD. - le SGBD traite la demande en consultant le sous-schma (schma externe) relatif au programme d'application A, obtenant ainsi la description des donnes. - le systme consulte le schma logique global (schma conceptuel) et dtermine le type logique de donnes extraire. - le systme examine la description physique de la base en rapport avec la requte logique et dtermine le (ou les) enregistrement(s) physique(s) lire. - le systme lance une commande au systme d'exploitation pour rechercher physiquement l'enregistrement dsir. - le systme d'exploitation, par le biais de ses mthodes d'accs, accde l'enregistrement physique. - les donnes demandes sont transfres dans les buffers, ou mmoires tampons. - le SGBD, partir d'une comparaison entre schma logique et sous-schma A, extrait, des donnes stockes dans le buffer, l'enregistrement logique rclam par le programme d'application. Il effectue galement les transformations ventuelles de format. - le SGBD transfre les donnes des buffers dans la zone de liaison du programme d'application A. - le SGBD fournit galement des informations "d'tat" au programme d'application, lui signalant en particulier les erreurs ventuellement constates au cours du processus d'extraction. - le programme d'application, qui dispose des donnes et d'informations de "service" en assure la bonne exploitation! Les ordres d'criture dans la base physique sont traits par un processus similaire, toute modification ou adjonction tant en gnral prcde d'une opration de lecture. A signaler que, dans la majorit des cas, le SGBD doit traiter simultanment plusieurs demandes de donnes en provenance de plusieurs programmes d'application, utilisant plusieurs schmas externes diffrents. DIFFERENTS LANGAGES D'UN SGBD 1) Prsentation La prsentation des SGBD ralise dans les pages prcdentes a fait apparatre la ncessit de bien diffrencier les deux tapes et objectifs diffrents que sont la dfinition des donnes a priori (rle du DBA ou administrateur de la base) et leur utilisation a posteriori (par les utilisateurs ou les programmeurs d'application). Le SGBD met donc disposition deux types de langage :
afpa
auteur
centre Dijon
formation
module
sq/item
page 10
gen-BD

Les SGBD
Langage de Description de Donnes (LDD) Il permet de dcrire prcisment la structure de la base et le mode de stockage des donnes. Tandis que l'utilisation de fichiers permet une description de donnes interne au programme, dans une approche Base de Donnes, on effectue la description de toutes les donnes une fois pour toutes : elle constitue l'ensemble des tables et dictionnaires de la base, son schma (terminologie CODASYL). En particulier, il prcise la structure logique des donnes (nom, type, contraintes spcifiques...), la structure physique (mode d'implantation sur les supports, mode d'accs), la dfinition des sous-schmas ou "vues". Langage de Manipulation de Donnes (LMD) Il convient de rappeler que l'utilisation d'une BDD suppose un grand nombre d'utilisateurs (souvent non informaticiens) ayant tous des tches et des besoins varis auxquels le LMD doit pouvoir rpondre. On peut rpertorier : le langage d'interrogation ou langage de requte il vite le recours, en particulier pour des besoins ponctuels, des langages gnraux de programmation, qui impliquent des cots prohibitifs et des dlais souvent fort longs. Il doit tre syntaxe souple, accessible aux non-spcialistes et permettre la formulation de demandes utilisant des critres varis et combins. le langage hte pour les traitements rguliers ou mettant en oeuvre d'importants volumes d'informations, le SGBD doit pouvoir fournir un interface permettant l'utilisation de la base l'aide des langages gnraux (COBOL, PL/1, FORTRAN, ASSEMBLEUR...). 2) Classification des LMD Les LMD se rpartissent en 2 catgories principales : - langages navigationnels (ex : SYMBAD) on les rencontre avec les SGBD hirarchiques ou rseaux. Les requtes du langage (ou questions) dcrivent les chemins d'accs aux diffrentes donnes, celles-ci tant gnralement chanes entre elles. - langages algbriques (ex : SQL) on les rencontre avec les SGBD relationnels. Ils utilisent, pour fournir des rsultats aux requtes, les oprateurs de l'algbre relationnelle.
afpa
auteur
centre Dijon
formation
module
sq/item
page 11
gen-BD

ROLE DE L'ADMINISTRATEUR DE LA BASE (DBA )

Rappelons succintement les diffrentes fonctions assumes par un SGBD: description de la structure de la base (schma) organisation du stockage physique manipulation des informations (slection, extraction, mise jour) protection pour personnaliser de faon fiable les accs la base, il convient d'identifier l'utilisateur (code et mot de passe) et de vrifier qu'il est autoris effectuer sur les donnes les traitements qu'il demande (contrle des droits d'accs). scurit, restauration (possibilit de reconstituer la base dans un tat satisfaisant aprs tout incident) optimisation des ressources le logiciel doit fournir des statistiques prcises sur l'tat de la base et permettre des rorganisations physiques priodiques qui viteront la dgradation des performances globales du systme intgrit des donnes (cohrence des informations les unes par rapport aux autres). L'essentiel de la mise en oeuvre de ces fonctions revient une personne (ou une quipe) appele administrateur de la BDD. Elle dispose d'un ensemble d'outils logiciels pour l'assister dans sa tche. Son rle consiste : intervenir en tant que conseil lors de l'tape conceptuelle de l'analyse (responsabilit de gestion des donnes) dcider des techniques d'accs et de l'implantation physique grer les diverses autorisations d'accs dfinir les stratgies de reprise en cas d'incident suivre rgulirement les performances du systme et raliser en consquence les modifications ou volutions qui s'imposent.
afpa
auteur
centre Dijon
formation
module
sq/item
page 12
gen-BD

Les SGBD
PRESENTATION DES PRI NCIPAUX MODELES LOGI QUES

Un trs grand nombre de modles existent sur le march, ralisant plus ou moins bien les diverses fonctions voques prcdemment. Les 3 principaux, par le nombre d'installations, sont, dans l'ordre chronologique de leur arrive sur le march, le modle hirarchique, le modle rseau (ou navigationnel), le modle relationnel. 1) LE MODELE HIERARCHIQUE Exemple : reprsentation (partielle!) du SI d'une compagnie arienne
Socit
Salaris
Vols
Matriel
Pilotes
Htesses
Entretien
Administratif
L'anctre, et le plus rpandu, en est le SGBD IMS (Information Management System), dvelopp et commercialis par IBM.dans les annes 70; on peut galement citer le systme S2000 (1978). Sa caractristique principale est la trs forte dpendance entre la description de la structure des donnes et la manire dont celle-ci se trouvent enregistres sur le support physique. Les lments de base du modle sont des enregistrements logiques relis entre eux pour constituer un arbre ordonn ou arborescence value. Les diffrentes entits (ou segments) constituent les noeuds, celui de plus haut niveau portant le nom de racine; les branches (pointeurs logiques entre entits) constituent les liens. Chaque segment est une collection d'objets appels champs (ou fields). Chaque noeud, sauf la racine, a un seul arc incident du type 1:N et un (ou plusieurs) arc(s) mergeant(s). Plus simplement, chaque segment a obligatoirement un pre, mais un seul, et peut avoir plusieurs fils. De faon visuelle, cette reprsentation schmatique fait apparatre: - les avantages du modle rigueur des structures et des chemins d'accs, simplicit relative de l'implmentation, adquation parfaite du modle une entreprise structure arborescente. - les contraintes un peu lourdes qui en sont la contrepartie * les accs se font normalement depuis la racine et uniquement depuis la racine
afpa
auteur
centre Dijon
formation
module
sq/item
page 13
gen-BD

* la structure lude la possibilit de liens N:M, ne permettant que le lien 1:N. La reprsentation d'autres relations impose de ce fait une redondance de l'information. Exemple: comment reprsenter un parc de vhicules et un ensemble de chauffeurs, chaque chauffeur pouvant conduire plusieurs vhicules, et un vhicule pouvant tre conduit par plusieurs chauffeurs ? * les "anomalies" que l'on est amen constater lors des oprations de mise jour (on parle de stockage : insertion, destruction, modification). Ainsi, l'limination d'un noeud entrane l'limination de tous les segments de niveau infrieur qui lui sont rattachs (risque de perdre des donnes uniques) * l'indpendance logique trs rduite : la structure du schma doit reflter les besoins des applications. * de plus, il n'existe pas d'interface utilisateur simple. 2) LE MODELE EN RESEAU Il peut tre considr comme une volution du modle hirarchique, en lui intgrant les rsultats du travail du groupe CODASYL (comit de langage de programmation), lequel avait dmarr l'tude d'une extension de COBOL pour manipuler les bases de donnes. En 1969, il donne ses premires recommandations concernant syntaxe et smantique du LDD et du LMD. Mme si cette vue est un peu simplificatrice, une base en rseau peut tre dcrite comme un certain nombre de fichiers comportant des rfrences des uns vers les autres. Les entits sont connectes entre elles l'aide de pointeurs logiques. Ce concept permet d'associer, un enregistrement d'un ensemble de donnes A, une srie d'enregistrements (ou records) d'un autre ensemble de donnes B. On constitue ainsi des SET, ou COSET, structure fondamentale du modle en rseau : - le lien entre les enregistrements de A et ceux de B est 1:N - le COSET comporte un type d'enregistrement "propritaire" (l'enregistrement de A est dit OWNER) et un type d'enregistrement "membre" (les enregistrements de B sont MEMBER). Supposons l'exemple suivant : un institut de recherche regroupe plusieurs laboratoires, diviss en dpartements, chacun de ceux-ci employant plusieurs chercheurs. Reprsentation : diagramme de Bachman.
LABO
LABODEPT
afpa
auteur
centre Dijon
formation
module
sq/item
page 14
gen-BD

Les SGBD
On ne rencontre aucune restriction la conception du modle : un type de "record" peut la fois tre propritaire et membre vis--vis de plusieurs sets ; de mme, il peut tre propritaire (ou membre) de plusieurs sets. Exemple : schma reprsentant le sous-systme d'information produits / magasins de stockage / fournisseurs / domiciliations bancaires
PROD
FOURN
MAGASIN
PRODFOUR
DOMICIL
Avantages et inconvnients du modle * reprsentation naturelle des liens maills N:M * absence d'anomalies pour les oprations de stockage * commercialisation importante des systmes correspondants (DMS, IDMS, TOTAL, IDS II, SOCRATE...), mais - pas d'indpendance par rapport aux stratgies d'accs - procduralit importante des langages de manipulation ; l'utilisateur doit "naviguer" dans le rseau logique constitu par les enregistrements et les chanes de pointeurs. 3) LE MODELE RELATIONNEL C'est un article publi en 1969 par un mathmaticien du centre de recherche IBM, Codd, qui dfinit les bases de ce modle relationnel. Codd s'est intress au concept d'information et a cherch le dfinir sans se proccuper de la technique informatique, de ses exigences et de ses contraintes. Il a tudi un modle de reprsentation des donnes qui repose sur la notion mathmatique de "relation". Dans la pratique, une relation sera reprsente par une table de valeurs.
afpa
auteur
centre Dijon
formation
module
sq/item
page 15
gen-BD

Exemple: reprsentation d'une table du personnel

Matricule
Thorie et dfinitions
Une relation est un ensemble de tuples ou uplets (lignes ou articles), dont l'ordre est sans importance; chaque tuple est unique. Les colonnes de la table sont appeles attributs ou champs; leur ordre est dfini lors de la cration de la table. Une cl est un ensemble ordonn d'attributs qui caractrise un tuple. Une cl primaire le caractrise de manire unique, l'inverse d'une cl secondaire. On dit qu'un attribut A est un dterminant si sa connaissance dtermine celle de l'attribut B.
Objectifs du modle
proposer des schmas de donnes faciles utiliser amliorer l'indpendance logique et physique mettre disposition des utilisateurs des langages de haut niveau pouvant ventuellement tre utiliss par des non -informaticiens. optimiser les accs la base de donnes amliorer l'intgrit et la confidentialit prendre en compte une varit d'applications fournir une approche mthodologique dans la construction des schmas.
Caractristiques du modle (DB2, INGRES, ORACLE, FOCUS, NOMAD, DATACOM) * les structures de donnes sont simples : ce sont des tables deux dimensions o les lments sont des donnes lmentaires. * un ensemble d'oprateurs (union, intersection, diffrence, produit cartsien, projection, slection, jointure, division) , l'algbre relationnelle, appliqus aux relations, permet la dfinition, la recherche et la mise jour des donnes. Cette algbre est la base des langages de manipulation non procduraux, type SQL. * un ensemble de contraintes d'intgrit (unicit de cl, contrainte rfrentielle) dfinit l'tat cohrent de la base. * toute information de la base de donnes est reprsente par des valeurs dans des tables. * il n'y a pas de pointeurs visibles par l'utilisateur entre tables.
afpa
auteur
centre Dijon
formation
module
sq/item
page 16
gen-BD

Les SGBD
Avantages et inconvnients indpendance de l'utilisateur vis--vis de la structure logique, de la structure physique et des stratgies d'accs, d'o simplicit et clart dans l'utilisation. puissance et uniformit de la reprsentation. trs grande souplesse d'expression dans la scurit des donnes. existence d'interfaces non procdurales. indpendance des programmes vis--vis de la base : une modification du schma ne ncessite pas de modification des applicatifs existants. problmes de performance pour certains modles
difficult de conception d'un schma conceptuel propre (mise en application des rgles de normalisation), tape indispensable un fonctionnement satisfaisant du modle.
afpa
auteur
centre Dijon
formation
module
sq/item
page 17
gen-BD

afpa
auteur
centre Dijon
formation
module
sq/item
page 18
gen-BD

Base de donnes modeleRelationnel
LE MODELE RELATIONNEL
afpa - St Brieuc -14/01/07
Page 1

1. INTRODUCTION : LES OBJECTIFS DU MODELE

Le modle relationnel a t introduit par E. F. Codd [Codd70] qui travaillait au fameux Centre de Recherche dIBM San-Jos. La premire volont du modle relationnel fut dtre un modle ensembliste simple, supportant des ensembles denregistrements aussi bien au niveau de la description que de la manipulation. Les premires ides dun modle ensembliste avaient t proposes un peu avant, notamment dans [Childs68]. Le modle relationnel est aujourdhui la base de nombreux systmes, et les architectures permettant daccder depuis une station de travail des serveurs de donnes sappuient en gnral sur le modle relationnel. Le relationnel a donc atteint ses objectifs au-del de toute esprance. Les premiers objectifs du modle ont t prciss par E. F. Codd [Codd7O] comme suit 1).Permettre un haut degr dindpendance des programmes dapplications et des activits interactives la reprsentation interne des donnes, en particulier aux choix des ordres dimplantation des donnes dans les fichiers, des index et plus gnralement des chemins daccs. 2) Fournir une base solide pour traiter les problmes de cohrence et redondance des donnes. Ces deux objectifs qui ntaient pas atteints par les modles rseau et hirarchique, ont t pleinement satisfaits par le modle relationnel, dune part grce la simplicit des vues relationnelles qui permettent de percevoir les donnes sous forme de tables deux dimensions et dautre part grce aux rgles dintgrit supportes par le modle et ses fondements logiques.
Page 2

En addition aux objectifs fixs par E. F. Codd, le modle relationnel a atteint un troisime objectif: 3) Permettre le dveloppement de langages de manipulation de donnes non procduraux bass sur des thories solides. Ce troisime objectif est atteint dune part laide de lalgbre relationnelle qui permet de manipuler des donnes de manire trs simple et formelle comme les oprateurs arithmtiques permettent de manipuler des entiers et dautre part laide des langages assertionnels bass sur la logique qui permettent de spcifier les donnes que lon souhaite obtenir sans dire comment les obtenir Finalement, le modle relationnel a atteint deux autres objectifs non prvu initialement: 4).Etre un modle extensible permettant de modliser et de manipuler simplement des donnes tabulaires, mais pouvant tre tendu pour modliser et manipuler des donnes complexes. 5) Devenir un standard pour la description et la manipulation des bases de donnes. Lobjectif 4 est trs important, car il a permis dintgrer de nouveaux concepts au modle relationnel, notamment la plupart des concepts de lorient objets. Les premiers travaux de recherche dans ce sens ont t effectus par Codd luimme [Codd79]. puis poursuivis Bell Laboratories [Zaniolo83], Berkeley [Stonebraker8l] et, en France, l'INRIA [Gardarin89]. Lobjectif 5 a t ralis grce en particulier IBM : le modle relationnel et son langage SQL ont t normalis au niveau international en 1986 [1S089].
Page 3

Dans ce chapitre, nous allons tout dabord prsenter les concepts structuraux de base du modle relationnel qui permettent de modliser les donnes sous forme de tables deux dimensions. Nous soulignerons ensuite les rgles de cohrence des relations qui sont considrs comme partie intgrante du modle. Puis nous introduirons lalgbre relationnelle, qui est loutil formel indispensable afin de manipuler des relations. Les nombreuses extensions de cette algbre seront galement prsentes. En conclusion, nous dmontrons les vastes possibilits denrichissement offertes par le modle relationnel, possibilits qui seront tudies plus en dtail au niveau des modles objets et logiques, sujets des chapitres VII et VIII de ce livre.
2. LES STRUCTURES DE DONNEES DE BASE

2.1. DOMAINE, ATTRIBUT ET RELATION Le modle relationnel est bas sur la thorie mathmatique bien connue des relations. Cette thorie se construit partir de la thorie des ensembles. Trois notions de base sont importantes pour introduire les bases de donnes relationnelles. La premire notion permet de dfinir les ensembles de dpart. Ces ensembles sont les domaines de valeurs. Notion V.1 : Domaine (Domain) Ensemble de valeurs caractris par un nom. Les domaines sont donc les ensembles dans lesquels les donnes prennent valeur. Comme un ensemble, un domaine peut tre dfini en extension, en donnant la liste des valeurs composantes, ou en intention, en dfinissant une proprit caractristique des valeurs du domaine. Au dpart, les domaines ENTIER, REEL, BOOLEEN, CARACTERES (une chane de caractres de longueur fixe ou variable) sont dfinis en intention. A partir de ces domaines, il est possible de dfinir en intention des domaines plus spcifiques tels que MONNAIE (rel avec 2 chiffres derrire la virgule), DATE (entier de 6 chiffres jour, mois et an), TEMPS (heure en seconde), etc. Un domaine peut toujours tre dfini en extension, par exemple le domaine des couleurs de vins COULEUR-VINS = {Ros, Blanc, Rouge}. Rappelons que le produit cartsien dun ensemble de domaines Dl, D2,.., Dn est lensemble des vecteurs < vi, v2, ..., vn > o, pour i variant de 1 n. vi est une valeur de Di. Par exemple, le produit cartsien des domaines COULEUR-VINS = {ROSE, BLANC, ROUGE} et CRUS = {VOLNAY, SANCERRE, CHABLES} est compos des neuf vecteurs reprsents figure V.1. COULEUR-VINS = {ROSE, BLANC, ROUGE} CRUS = {VOLNAY, SANCERRE, CHABLIS}
afpa - St Brieuc -14/01/07 Page 4

ROSE ROSE ROSE BLANC BLANC BLANC ROUGE ROUGE ROUGE
VOLNAY SANCERRE CHABLIS VOLNAY SANCERRE CHABLIS VOLNAY SANCERRE CHABLIS
Figure V.1 : Exemple de produit cartsien
Nous pouvons maintenant introduire la notion de relation, bien sr la base du modle. Nation V.2 : Relation (Relation) Sous-ensemble du produit cartsien dune liste de domaines caractris par un nom. Etant un sous-ensemble dun produit cartsien, une relation est compose de vecteurs. Une reprsentation commode dune relation sous forme de table deux dimensions a t retenue par Codd et est gnralement utilise. Chaque ligne correspond un vecteur alors que chaque colonne correspond un domaine du produit cartsien considr un mme domaine peut bien sr apparatre plusieurs fois. Par exemple, partir des domaines COULEURS_VINS et CRUS, il est possible de composer la relation COULEURS_CRUS reprsente sous forme tabulaire figure V.2.
COULEURS CRUS
Couleur ROSE ROSE BLANC ROUGE ROUGE ROUGE
Cru SANCERRE CHABLIS SANCERRE VOLNAY SANCERRE CHABLIS
Figure V.2 : Un premier exemple de relation
Page 5

Afin de pouvoir distinguer les colonnes dune relation sans utiliser un index, et ainsi de rendre leur ordre sans importance tout en permettant plusieurs colonnes de mme domaine, il est ncessaire dassocier un nom chaque colonne. Une colonne se distingue dun domaine en ce sens quelle prend valeur dans un domaine et peut un instant donn comporter seulement certaines valeurs du domaine. Par exemple, si le domaine est lensemble des entiers, seulement quelques valeurs seront prises un instant donn, par exemple {10, 20, 30}. Lensemble des valeurs dune colonne de relation est en gnral fini. Afin de bien distinguer domaine et colonne, on introduit la notion dattribut comme suit. Notion V.3 : Attribut (attribute) Colonne dune relation caractrise par un nom. Le nom associ un attribut est souvent porteur de sens. Il est donc en gnral diffrent de celui du domaine qui supporte lattribut. Ainsi, par exemple, la premire colonne de la relation COULEUR-CRUS pourra tre appele simplement COULEUR et la deuxime CRU. COULEUR et CRU seront donc deux attributs de la relation COULEUR-CRUS. Les lignes dune relation correspondent des n-uplets de valeurs. Une ligne est aussi appele tuple (du mot anglais tuple) : un tuple correspond en fait un enregistrement dans une relation (encore appele table). Notion V.4 : Tuple (tuple) Ligne d'une relation correspondant un enregistrement. La notion de relation est bien connue en mathmatiques : une relation n-aire est un ensemble de n-uplets. Un cas particulier souvent employ est la relation binaire qui est un ensemble de paires ordonnes. Une relation n-aire est souvent reprsente par un graphe entre les ensembles composants. Ainsi, la relation LOCALISATION, donnant la rgion de chaque cru et certains prix moyens des vins associs est reprsente par un graphe figure V.3. Une relation peut aussi tre reprsente sur un diagramme n dimensions dont les coordonnes correspondent aux domaines participants. Ainsi, la relation STATISTIQUE, dattributs AGE et SALAIRE, donnant la moyenne des salaires par ge est reprsente figure V.4.
CRUS
REGION
PRIX l 45 l 42
Page 6
Sancerre l
afpa - St Brieuc -14/01/07 l Chablis
Loire
Bourgogne
l 38

Figure V.3 : Graphe de la relation LOCALISATION
Salaire 100 80 60 40 20 10 0 0 10 20 30 40 50 60 70 Age Figure V.4 : Diagramme reprsentant une relation binaire
Une autre perception mathmatique dune relation consiste a voir chaque tuple t comme une fonction : t: Ai Di pour i = 1, 2 ... n qui applique donc les attributs sur les domaines. Ainsi, une relation peut tre vue comme un ensemble fini de fonctions. Bien sr, cet ensemble varie en fonction du temps. Tout ceci montre la diversit des outils mathmatiques qui peuvent tre appliqus aux relations. En consquence, le modle relationnel peut apparatre comme un modle mathmatique simple des donnes. De plus, grce la reprsentation tabulaire il est simple apprhender pour les non mathmaticiens.
Page 7

2.2. EXTENSIONS ET INTENTIONS Comme tous les modles de donnes, le modle relationnel permet de dcrire des donnes dont les valeurs varient en fonction du temps. En particulier, les relations varient en fonction du temps, en ce sens que des tuples sont ajouts, supprims et modifis dans une relation au cours de sa vie. Cependant, la structure dune relation caractrise par les trois concepts de domaine, relation et attribut est un invariant pour la relation qui ne change pas en fonction du temps. Cette structure est capture dans le schma de la relation. Notion 5 : Schma de Relation (Relation Schema) Nom de la relation suivi de la liste dos attributs et de la dfinition de leurs domaines. Un schma de relation est not sous la forme : R (A1: D1, A2: D2, ..., Ai: Di, ...,An: Dn) o R est le nom de la relation, Ai les attributs et Di les domaines associs. A titre dexemple, nous donnons figure V.5 deux schmas de relations celui de la relation LOCALISATION introduite ci-dessus et celui de la relation VINS qui reprsente des vins caractriss par un numro, un cru, un millsime et un degr. Les domaines utiliss sont ceux des entiers, des rels et des chanes de caractres de longueur variable (CHARVAR). La plupart du temps, lorsquon dfinit le schma dune relation, les domaines sont implicites et dcoulent du nom de lattribut aussi, on omet de les prciser. LOCALISATION (CRU: CHARVAR, REGION: CHARVAR, PRIX: REEL) VINS (NV:ENTIER, CRU: CHARVAR, MILL:ENTIER, DEGRE: REEL) Figure V.5 : Schmas des relations LOCALISATION et VINS Il est souligner que le schma dune relation reprsente son intention, cest-dire les proprits (ou au moins certaines) communes et invariantes des tuples quelle va contenir au cours du temps. Au contraire, une table reprsente une extension dune relation (voir figure V.2 par exemple), cest--dire une vue des tuples quelle contient un instant donn. Une extension dune relation R est aussi appele instance de R. Lintention est le rsultat de la description des donnes, alors quune extension (ou instance) fait suite des manipulations et reprsente un tat de la base.
3. LES REGLES DINTEGRITE STRUCTURELLE
Page 8

Les rgles dintgrit sont les assertions qui doivent tre vrifies par les donnes contenues dans une base. Il est possible de distinguer les rgles structurelles qui sont inhrentes au modle de donnes, cest--dire ncessaires sa mise en uvre, et les rgles de comportement propres au schma particulier dune application. Le modle relationnel impose a priori une rgle minimale qui est lunicit des cls comme nous allons le voir ci-dessous. Il est commode et courant [Date81] dajouter trois types de rgles dintgrit supplmentaires les contraintes de rfrences, les contraintes dentit et les contraintes de domaine cela afin dobtenir les rgles dintgrit structurelles supportes par le modle relationnel.
3.1 UNICITE DE CLE Par dfinition, une relation est un ensemble de tuples. Un ensemble nayant pas dlment en double, il ne peut exister deux fois le mme tuple dans une relation. Afin didentifier les tuples dune relation sans donner toutes les valeurs et dassurer simplement lunicit des tuples, la notion de cl est utilise. Notion V.6 : Cl (Key) Ensemble dattributs minimal dont la connaissance des voleurs permet d'identifier un Iup!e unique de la relation considre. De manire plus tonnelle, une cl dune relation R est un ensemble dattributs K tel que, quels que soient les tuples t1 et t2 dune instance de R, t1(K) t2(K), cest--dire que t1 et t2 ont des valeurs de K diffrentes. Un ensemble dattributs contenant une cl est appele super-cl [Ullman88]. Toute relation possde au moins une cl car la connaissance de tous les attributs permet didentifier un tuple unique. Dans le cas o il existe plusieurs cls, on en choisit en gnral une de manire arbitraire qui est appele cl primaire. Par exemple, NV peut constituer une cl primaire pour la relation VINS. Le couple <CRU, MIILLESIME> est une cl alternative. Il est souligner que la notion de cl caractrise lintention dune relation dans toute extension possible dune relation, il ne peut exister deux tuples ayant mme valeur pour les attributs cls. La dtermination dune cl pour une relation ncessite donc une rflexion sur la smantique de la relation, cest--dire sur toutes les extensions possibles et non pas sur une extension particulire. 3.2. CONTRAINTES DE REFERENCES Le modle relationnel est souvent utilis afin de reprsenter des entits du monde rel qui sont les objets ayant une existence propre, et des associations

entre ces objets [Chen76]. Une entit correspond alors un tuple dans une relation qui comporte la fois la cl de lentit et ses caractristiques sous forme dattributs. Une entit est identifie par la valeur de sa cl. Un type dassociation est modlis par une relation comportant les cls des entits participantes ainsi que les caractristiques propres lassociation. A titre dexemple, nous considrons les entits BUVEURS et VINS du monde rel : la cl de lentit BUVEURS est le numro de buveur NB et celles de lentit VINS le numro de vin NV. Ces entits peuvent tre associes par une consommation dun vin par un buveur : une consommation sera par exemple modlise par une association ABUS entre le buveur et le vin. Cette base typique et simple, qui servira souvent dexemple, est appele DEGUSTATION. Le diagramme entit association de cette base est reprsent figure V.6. En relationnel, chaque entit est reprsente par une table. Une association est aussi reprsente par une table, dont les attributs seront les cls des entits participantes, cest--dire NB et NV, ainsi que les attributs caractrisant lassociation, par exemple la date et la quantit bue. On aboutit ainsi au schma relationnel reprsent figure V.7.
BUVEURS
ABUS
VINS
NB
Type
NV
Degr
Nom Prnom
Adresse Quantit Date
Cru
Qualit Millsime
Figure V.6 : Diagramme entit-association de la base DEGUSTATION
BUVEURS (NB, NOM, PRENOM, ADRESSE, TYPE) VIN (NV, CRU, MILL QUALITE, DEGRE) ABUS (NB, NV, DATE, QUANTITE) Figure V.7 : Schma relationnel de la base DEGUSTATION Lutilisation du modle relationnel pour reprsenter des entits et des associations ne permet pas jusque l de reprsenter le fait que lassociation entre une consommation et un vin est obligatoire, cest--dire que tout abus doit correspondre un vin existant dans la base. De mme, le fait que le lien entre

une consommation et un buveur soit obligatoire est perdu. Le maintient de liens obligatoires a justifi lintroduction de la notion de contrainte dintgrit rfrentielle [Date8l].
Page 11

Notion V.7 : Contrainte rfrentielle (Referential constraint) Contrainte d'intgrit portant sur une relation R1, consistant imposer que la valeur dun groupe dattributs apparaisse comme valeur de cl dans une autre relation R2. Une telle contrainte dintgrit sapplique en gnral aux associations obligatoires : une telle association ne peut exister que si les entits participant lassociation existent dj. A noter que dans la dfinition, R1 et R2 ne sont pas forcment distinctes : lassociation peut en effet porter sur deux entits de mme type, par exemple entre une personne et ses parents. La reprsentation de contraintes de rfrence peut seffectuer par la dfinition de cls trangres dans une relation : une cl trangre est un groupe dattributs qui doit apparatre comme cl dans une (autre) relation. Par exemple, la relation ABUS (NB, NV, DATE, QUANTITE) a pour cl <NB, NV, DATE> et a deux cls trangres NB dans BUVEURS et NV dans VINS. Les contraintes rfrentielles dfinissent des liens obligatoires entre relations. Ce sont des contraintes trs fortes qui impactent les oprations de mises jour. Lors de linsertion dun tuple dans une relation rfrenant, il faut vrifier que les valeurs de cls trangres existent dans les relations rfrences. Par exemple, lors de linsertion dun abus, il faut que le vin et le buveur associs existent, sinon linsertion est refuse pour cause de violation dintgrit. Lors de la suppression dun tuple dans une relation rfrence, il faut vrifier quaucun tuple n'existe dans chaque relation rfrenante sil en existe, le systme peut soit refuser la suppression, soit cascader La suppression (cest--dire, supprimer les tuples rfrenants). Par exemple, la suppression dun vin entranera la vrification quaucun abus ne rfrence ce vin. Les contraintes dintgrit rfrentielles sont donc des liens forts qui rendent les relations dpendantes ; en quelque sorte, elles introduisent des liens hirarchiques depuis les relations rfrences vers les relations rfrenantes.
3.3. VALEURS NULLES ET CLES Lors de linsertion de tuples dans une relation, il arrive frquemment quun attribut soit inconnu ou non applicable par exemple, la quantit de vin bu par un buveur une certaine date peut tre inconnue ; si un vin ne possde pas de millsime, l attribut millsime est inapplicable ce vin. On est alors amen introduire dans la relation une valeur conventionnelle, appele valeur nulle. Notion V.8 : Valeur nulle (Null value) Valeur conventionnelle introduite dans une relation pour reprsenter une information inconnue ou inapplicable.
Page 12

La signification prcise dune valeur nulle est souvent ambigu ; le groupe ANSI/X3/SPARC a recens quatorze significations possibles, parmi lesquelles valeur inconnue et valeur inapplicable sont les plus caractristiques. Tout attribut dans une relation ne peut prendre une valeur nulle ; en effet, lexistence dune cl unique impose la connaissance de la cl afin de pouvoir vrifier que cette valeur de cl nexiste pas dj. Ainsi, une contrainte structurelle du modle relationnel est la contrainte dentit dfinie ci-dessous [Date81]. Notion V.9 : Contrainte d'entit (Entity constraint) Contrainte d'intgrit imposant que toute relation possde une cl primaire et que tout attribut participant cette cl primaire soit non nul. A moins quil nen soit spcifi autrement par une contrainte smantique, le modle relationnel nimpose pas que les cls trangres qui nappartiennent pas une cl primaire soient non nulles. Cela peut permettre une certaine souplesse, par exemple denregistrer des employs qui ne sont attachs aucun service. 3.4. CONTRAINTES DE DOMAINES En thorie, une relation est construite partir dun ensemble de domaines. En pratique, les domaines grs par les systmes sont souvent limits aux types de base entier, rel, chane de caractres, parfois monnaie et date. Afin de spcialiser un type de donnes pour composer un domaine plus fin (par exemple, le domaine des salaires mensuels qui sont des rels compris entre 5 000 et 1 000 000 de francs), la notion de contrainte dintgrit de domaine est souvent ajoute aux rgles dintgrit structurelle du relationnelle. Cette notion peut tre introduite comme suit. Notion V.1O : Contrainte de domaine (Domain constraint) Contrainte dintgrit imposant quune colonne dune relation doit comporter des voleurs vrifiant une assertion logique. Lassertion logique est soit lappartenance une plage de valeurs ou une liste de valeurs. Par exemple, SALAIRE 5 000 et 1 000 000, COULEUR {BLEU, BLANC, ROUGE}, etc. Les contraintes permettent de contrler la validit des valeurs introduites lors des insertions ou mises jour. La non-nullit dune colonne peut aussi tre considre comme une contrainte
Page 13

de domaine, par exemple DEGRE NULL.
Page 14

Proposition de solutionJO
PROPOSITION DE SOLUTION
DU
CAS
JEUX OLYMPIQUES DHIVERS
afpa-St Brieuc-Langueux Participation : Frdrique GOUYA -DI 07/02
Page : 1

CAHIER DES CHARGES
Les Organisateurs des jeux Olympique d'hiver souhaitent s'quiper d'un systme informatique capable de grer les preuves , les concurrents et les Responsables. Les personnes responsables des jeux se sont organises de faon hirarchique. Au sommet de la pyramide se trouve un "Responsable gnrale" dont dpendent des responsables de discipline ( Ski alpin , patinage , Bobsleigh ..). De ces derniers dpendent leur tour des responsables moins importants ,et ainsi de suite jusqu' la personne de base. Tout le monde a un rle dans l'organisation des jeux : "juge a l'arrive , chronomtreur , juge de parcours. " et pour des raisons pratiques sera identifi par un NMatricule. On grera aussi leur nom et leur coordonnes. Chaque preuve a lieu dans une des stations de la rgion. Une mme station dont on connat le nom et l'altitude peut accueillir plusieurs preuves mais des jours diffrents et du mme type. A l'organisation d'une preuve sont affects plusieurs responsables . Les responsables peuvent s'occuper de plusieurs preuves. Ces dernires ont un Code alphabtique . Chaque preuve fait partie d'une discipline et d'une seule. Elles se droulent quelquefois en plusieurs manches. Chaque concurrent reprsente un Pays et participe une ou plusieurs preuves. Il peut pratiquer plusieurs disciplines. Dans les manches d'une preuve il porte toujours le mme numro de dossard mais en change pour une autre preuve. A l'issue de chaque manche , le systme doit enregistrer , selon l'preuve , le temps ( Ski , . ) ou le nombre de points de chaque concurrent. A la fin de l'preuve , il mmorisera la place et ventuellement la mdaille ( OR , ARGENT , BRONZE ) de chacun des athltes. On distinguera les concurrents hommes des femmes car les preuves ne sont pas mixte. Ils sont identifis par un numro d'inscription aux jeux et ont un Nom , une date de naissance et des coordonnes. Tous les pays sont codifis ( FR , GB , USA . ).
Page : 2

1-MODELE CONCEPTUEL DE DONNEES
Responsable NoMatr <pi> <O> NomResp CoordResp
1,1 a pour role 1,n
Role CodeRole <pi> <O> intitul
Pays code Pays <pi> <O>
0,n 0,1 0,n a sous ses ordres 1,1 est responsable Discipline Id discipline <pi> <O> Nom discipline 1,n 1,n Athlte 0,n est responsable de pratique
0,n reprsente
est sous les ordres de
1,1
no inscription <pi> <O> nom concurrent date de naissance coordonnees concurrent sexe concurrent
1,n est responsable de
1,n comporte participe No dossard place medaille
0,n
1,1 1,n a pour type 1,1 Epreuve Code Epreuve <pi> <O> NomEpreuve 1,1
1,n resultat intermediaire Temps nb points 1,n
a lieu 1,n Type d'preuve Id type d'epreuve <pi> <O> nom type d'preuve 1,n a lieu dans Station correspond 1,1 CodStation <pi> <O> NomStation Altitude 1,n 0,1
se droule
1,1
1,n
Jour jour <pi> <O>
Manche Id Manche <pi> <O> No Manche
Page : 3

2-MODELE LOGIQUE DE DONNEES RESPONSABLE (NoMatr, NomResp, CoordResp, CodRole, NoMatrSup) ROLE (CodRole, intitul) DISCIPLINE (Id discipline, Nom discipline, NoMatrResp) PRATIQUE (no inscription, Id discipline) RESPONSABLE_EPREUVE (NoMatr, Code preuve) EPREUVE (Code preuve, NomEpreuve, Id discipline, Id type d'preuve, Nom station, jour) TYPE_EPREUVE (Id type d'preuve, NomTypeEpreuve) STATION (CodStation, Nom station, altitude, Id type d'preuve) MANCHE (Id manche, Nom manche, Code preuve) PARTICIPE (Code preuve, No inscription, no dossard, place, mdaille) ATHLETE (No inscription, nom concurrent, date de naissance, coordonnes concurrent, sexe concurrent, Cod pays) PAYS (Codpays, NomPays) RESULTAT_INTERMEDIAIRE (No inscription, Id manche, Temps, nb points)
Page : 4

3-MODELE LOGIQUE DE DONNEES -TABLEAU DES CONTRAINTES Table RESPONSABLE

Contraintes Attributs Type Structure DOMAINE Unique Obligatoire Evolutivit Valeur Proprit INTER N-Uplets Relation
NoMatr NomResp CoordResp NoMatrSup CodeRole
Numrique Caractre Caractre Numrique Caractre
3 20 60 3 20
oui
oui oui oui oui oui
RESPONSABLE ROLE
Table ROLE
CodeRole intitul Rle
Numerique Caractre
20
oui oui
oui oui
+1
Table DISCIPLINE
Id discipline Nom discipline NoMatrResp
Numrique Caractre Numrique
3 20 3
oui
oui oui oui
RESPONSABLE
Table PRATIQUE
No inscription Id discipline
Numrique Numrique
3 3
oui oui
oui oui
ATHLETE DISCIPLINE
Table RESPONSABLE_EPREUVE
NoMatr Numrique Code epreuve Numrique
3 3
oui oui
oui oui
RESPONSABLE EPREUVE
Page : 5

Table EPREUVE
Code preuve Nom Epreuve Id discipline Id type d'preuve Nom station Jour
Num rique Caractre Numrique Numrique Caractre Date
3 20 3 3 20 JJ/MM/AA
oui
oui oui oui oui oui oui
DISCIPLINE TYPE EPREUVE STATION
Table TYPE_EPREUVE
Id type d'preuve Nom type d'preuve
Numrique Caractre
3 20
oui
oui oui
Table STATION
NStation Nom station Altitude Id type d'preuve
Numrique Caractre Numrique Numrique
5 20 5 3
oui oui oui
oui oui non oui
+1
TYPE_EPREUVE
Table MANCHE
Id manche
Numrique
3 20 3
oui
oui oui oui EPREUVE
Nom manche Caractre Code preuve Numrique
Table PARTICIPE
Code preuve No inscription No dossard place Mdaille
Numrique Numrique Numrique Numrique Caractre
3 3 4 3 10
oui oui
oui oui oui non non
EPREUVE ATHLETE
Or, Argent, Bronze
Table ATHLETE
afpa-St Brieuc-Langueux Participation : Frdrique GOUYA -DI 07/02 Page : 6

Contraintes Attributs Type Structure
DOMAINE Unique Obligatoire Evolutivit Valeur Proprit
INTER N-Uplets Relation
No inscription Nom concurrent Date de naissance coordonnes concurrent sexe concurrent code pays
Numrique Caractre Date Caractre Caractre Caractre
3 20 JJ/MM/AA 60 1 3
oui
oui oui oui oui oui oui M,F
Table PAYS
Code pays Nom pays
Caractre Caractre
3 20
oui
oui oui
Table RESULTAT_INTERMEDIAIRE
No inscription Id manche Temps nb points
Numrique Numrique Numrique Numrique
3 3 HH:MM:SS 3
oui oui
oui oui non non
ATHLETE MANCHE
Page : 7

4-CREATION DE LA BASE D E DONNEES

DROP TABLE ResInter; DROP TABLE Participe; DROP TABLE Pratique; DROP TABLE RespEpreuve; DROP TABLE Manche; DROP TABLE Epreuve; DROP TABLE Discipline; DROP TABLE Responsable; DROP TABLE Athlete; DROP TABLE Role; DROP TABLE Pays; DROP TABLE Station; DROP TABLE TypeEpre uve; CREATE TABLE Role ( CodRole smallint IDENTITY(1,1) not null, IntitRole varchar(30) not null, Constraint pk_role primary key (CodRole) );
CREATE TABLE Pays ( CodPays varchar(3) not null, NomPays varchar(20) not null, Constraint pk_pays primary key (CodPays) ); CREATE TABLE TypeEpreuve ( IDTypeEpr int IDENTITY(1,1) not null, NomTypeEpr varchar(20) not null, Constraint pk_typeepr primary key (IDTypeEpr) ); CREATE TABLE Station ( CodStation smallint IDENTITY(1,1) not null, NomStation varchar(20) not null, Alti int not null, IDTypeEpr int not null, Constraint pk_station primary key (CodStation), Constraint fk_TypeEpreuve foreign key (IDTypeEpr) references TypeEpreuve(IDTypeEpr));
CREATE TABLE Responsable ( NoMatrResp int not null, NomResp varchar(20) not null, CoordResp varchar(60) not null, CodeRole smallint not null, NoMatrSup int, Constraint pk_resp primary key (NoMatrResp), afpa-St Brieuc-Langueux Participation : Frdrique GOUYA -DI 07/02 Page : 8

Constraint fk_respRole foreign key (CodeRole) references Role(CodRole), Constraint fk_supRespSup foreign key (NoMatrSup) references Responsable(NoMatrResp), Constraint ck_diff check (NoMatrResp<>NoMatrSup ));
CREATE TABLE Discipline ( IDDisc int IDENTITY(1,1) not null, NomDisc varchar(20) not null, NoMatrResp int not null, Constraint pk_discipline primary key (IDDisc), Constraint fk_respDisc foreign key (NoMatrResp) references Responsable(NoMatrResp)); CREATE TABLE Athlete ( NoInscrit int IDENTITY(1,1) not null, NomAthl varchar(30) not null, DateNaiss datetime not null, CoordAthl varchar(60) not null, SexeAthl char not null, CodPays varchar(3) not null, Constraint pk_athlete primary key (noInscrit), Constraint fk_athletePays foreign key (CodPays) references Pays(CodPays), Constraint ck_sexe check (SexeAthl='M' or SexeAthl='F'));
CREATE TABLE Epreuve ( CodEpr int IDENTITY(1,1) not null, NomEpr varchar(20) not null, IdDisc int not null, IdType int not null, CodStation smallint not null, Jour datetime not null, Constraint pk_epreuve primary key (CodEpr), Constraint fk_epreuveDisc foreign key (IdDisc) references Discipline(IDDisc), Constraint fk_epreuveType foreign key (IdType) references TypeEpreuve(IDTypeEpr), Constraint fk_epreuveStation foreign key (CodStation) references Station(Cod Station)); CREATE TABLE Manche ( IdManche int not null, NomManche varchar(20) not null, CodEpr int not null, Constraint pk_manche primary key (IdManche), Constraint fk_mancheEpr foreign key (CodEpr) references Epreuve(CodEpr),);
Page : 9

CREATE TABLE Re spEpreuve ( NoMatrResp int not null, CodEpr int not null, Constraint pk_respEpr primary key (NoMatrResp,CodEpr), Constraint fk_respEprResp foreign key (NoMatrResp) references Responsable(NoMatrResp), Constraint fk_respRespEpr foreign key (CodEp r) references Epreuve(CodEpr)); CREATE TABLE Pratique ( IdDisc int not null, NoInscrit int not null, Constraint pk_pratique primary key (IdDisc,NoInscrit), Constraint fk_pratAthlete foreign key (NoInscrit) references Athlete(NoInscrit), Constraint fk_pratDisc foreign key (IdDisc) references Discipline(IdDisc)); CREATE TABLE Participe ( NoInscrit int not null, CodEpr int not null, NoDossard int not null, Place int , Medaille varchar(10), Constraint pk_participe primary key (CodEpr,NoInsc rit), Constraint fk_partAthlete foreign key (NoInscrit) references Athlete(NoInscrit), Constraint fk_partEpreuve foreign key (CodEpr) references Epreuve(CodEpr), Constraint ck_medaille check (Medaille='Or' or Medaille='Argent' or Medaille='Bronze' )); CREATE TABLE ResInter ( NoInscrit int not null, IdManche int not null, Temps datetime , NbPts int, Constraint pk_resInter primary key (NoInscrit,IdManche), Constraint fk_resInterAthlete foreign key (NoInscrit) references Athlete(NoInscrit), Constraint fk_resInterManche foreign key (IdManche) references Manche(IdManche));
Page : 10

5-JEU D ESSAI
DELETE from ResInter; DELETE from Participe; DELETE from Pratique; DELETE from RespEpreuve; DELETE from Manche; DELETE from Epreuve; DELETE from Athlete; DELETE from Discipline; DELETE from Responsable; DELETE from Station; DELETE from Pays; DELETE from Role; DELETE from TypeEpreuve; INSERT INTO Role (IntitRole) values ('responsable general'); INSERT INTO Role (IntitRole) values ('responsable discipline '); INSERT INTO Role (IntitRole) values ('responsable epreuve'); INSERT INTO Role (IntitRole) values ('juge a l''arrivee'); INSERT INTO Role (IntitRole) values ('juge au dpart'); INSERT INTO Role (IntitRole) values ('chronometreur'); INSERT INTO Role (IntitRole) values ('juge 1'); INSERT INTO Role (IntitRole) values ('juge 2'); INSERT INTO Role (IntitRole) values ('juge 3'); INSERT INTO Role (IntitRole) values ('juge 4'); INSERT INTO Responsable (NoMatrResp, NomResp,CoordResp,CodeRole) values (1, 'Dupont', 'France',1); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (2,'Tardy', 'France', 2,1); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (3,'Tronet', 'France', 2,1); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (4,'Durand', 'France', 3,2); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (5,'Martin', 'Suisse', 3,3); INSERT INTO Responsable (NoMatrResp,NomResp,Co ordResp,CodeRole,NoMatrSup) values (6,'Dujardin', 'France', 4,4); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (7,'Clemart', 'France',5,4); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (8,'Smith', 'Grande -Bretagne', 6,4); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (9,'Wesson', 'Grande -Bretagne', 7,5); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (10,'Toinat', 'Luxembourg', 8,5); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) values (11,'Alvarez', 'Mexique', 9,5); INSERT INTO Responsable (NoMatrResp,NomResp,CoordResp,CodeRole,NoMatrSup) afpa-St Brieuc-Langueux Participation : Frdrique GOUYA -DI 07/02 Page : 11

values (12,'Riegel', 'Allemagne', 10,5);
INSERT INTO Pays values ('GB', 'Grande -Bretagne'); INSERT INTO Pays values ('FRA', 'France'); INSERT INTO Pays values ('SUI', 'Suisse'); INSERT INTO Pays values ('ALL', 'Allemagne'); INSERT INTO Pays values ('CAN', 'Canada'); INSERT INTO Pays values ('RUS', 'Russie'); INSERT INTO Pays values ('NOR', 'Norvege'); INSERT INTO TypeEpreuve (NomTypeEpr) values ('Ski'); INSERT INTO TypeEpreuve (NomTypeEpr) values ('Patinage'); INSERT INTO Station (NomStation, Alti,IDTypeEpr) values ('Chamonix',1500 , 1); INSERT INTO Station (NomStation, Alti,IDTypeEpr) values ('Tignes',1500, 2); INSERT INTO Discipline (NomDisc,NoMatrResp) values ('Ski alpin',2); INSERT INTO Discipline (NomDisc,NoMatrResp) values ('Patinage artistique',3); INSERT INTO Athlete (No mAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Dubois Pierre','05/02/1971','Dinan','M','FRA'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Carpenter John','14/05/1972','Londres','M','GB'); INSERT INTO Athlete (NomAth l,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Weiss Charles','31/03/1971','Geneve','M','SUI'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Fichtner Andrea','14/03/1975','Berlin','F','ALL'); INSERT INTO Athlete (NomAthl ,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Desbois Marie','01/05/1977','Grenoble','F','FRA'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Kowtun Regis','06/06/1972','Moscou','M','RUS'); INSERT INTO Athlete (NomAthl,Da teNaiss,CoordAthl,SexeAthl,CodPays) values ('Karamazov Tatiana','26/05/1985','St -Petersbourg','F','RUS'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Lambert Denis','21/03/1976','Montreal','M','CAN'); INSERT INTO Athlete ( NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Wilson Julia','03/12/1980','Ottawa','F','CAN'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Trevor Audrey','21/07/1981','Birmingham','F','GB'); INSERT INTO Athlete (No mAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Godisch Martin','30/04/1982','Hambourg','M','ALL'); INSERT INTO Athlete (NomAthl,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Olafsen Lars','16/09/1979','Oslo','M','NOR'); INSERT INTO Athlete (NomAth l,DateNaiss,CoordAthl,SexeAthl,CodPays) values ('Erikson Tania','14/08/1978','Oslo','F','NOR');
Page : 12

INSERT INTO Epreuve (NomEpr,IdDisc,IdType,CodStation,Jour) values ('Slalom Geant Homme',1,1,1,'09/02/2002'); INSERT INTO Epreuve (NomEpr,IdDisc,IdType,CodSta tion,Jour) values ('Slalom Geant Femme',1,1,1,'11/02/2002'); INSERT INTO Epreuve (NomEpr,IdDisc,IdType,CodStation,Jour) values ('Patinage Femme',2,2,2,'10/02/2002'); INSERT INTO Epreuve (NomEpr,IdDisc,IdType,CodStation,Jour) values ('Patinage Homme',2,2 ,2,'12/02/2002'); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (1,'Slalom Homme',1); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (2,'Slalom Femme',2); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (3,'Libre Femme',3); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (4,'Impos Femme',3); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (5,'Libre Homme',4); INSERT INTO Manche (IdManche,NomManche,CodEpr) values (6,'Impos Homme',4); INSERT INTO RespEpreuve values (4,1); INSERT INTO RespEpreuve values (4,2); INSERT INTO RespEpreuve values (5,3); INSERT INTO RespEpreuve values (5,4); -- athlete pratique discipline INSERT INTO Pratique values (2,1); INSERT INTO Pratique values (1,2); INSERT INTO Pratique values (1,3); INSERT INTO Pratique values (1,4); INSERT INTO Pratique values (2,5); INSERT INTO Pratique values (2,6); INSERT INTO Pratique values (2,7); INSERT INTO Pratique values (2,8); INSERT INTO Pratique values (2,9); INSERT INTO Pratique values (1,10); INSERT INTO Pratique values (1,11); INSERT INTO Pratique values (1,12); INSERT INTO Pratique values (1,13);
Page : 13

INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (1,4,1); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (6,4,2); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (8,4,3); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (2,1,1); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (3,1,2); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (11,1,3); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (12,1,4); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (5,3,1); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (7,3,2); INSERT INTO Participe (NoInscrit, CodEpr,NoDossard) values (9,3,3); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (4,2,1); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (10,2,2); INSERT INTO Participe (NoInscrit,CodEpr,NoDossard) values (13,2,3); INSERT INTO Re sInter (NoInscrit,IdManche) values (2,1); INSERT INTO ResInter (NoInscrit,IdManche) values (3,1); INSERT INTO ResInter (NoInscrit,IdManche) values (11,1); INSERT INTO ResInter (NoInscrit,IdManche) values (12,1); INSERT INTO ResInter (NoInscrit,IdManche ) values (4,2); INSERT INTO ResInter (NoInscrit,IdManche) values (10,2); INSERT INTO ResInter (NoInscrit,IdManche) values (13,2); INSERT INTO ResInter (NoInscrit,IdManche) values (5,3); INSERT INTO ResInter (NoInscrit,IdManche) values (7,3); INSERT INTO ResInter (NoInscrit,IdManche) values (9,3); INSERT INTO ResInter (NoInscrit,IdManche) values (5,4); INSERT INTO ResInter (NoInscrit,IdManche) values (7,4); INSERT INTO ResInter (NoInscrit,IdManche) values (9,4); INSERT INTO ResInter (NoInscrit,IdMan che) values (1,5); INSERT INTO ResInter (NoInscrit,IdManche) values (6,5); INSERT INTO ResInter (NoInscrit,IdManche) values (8,5); INSERT INTO ResInter (NoInscrit,IdManche)
Page : 14

values (1,6); INSERT INTO ResInter (NoInscrit,IdManche) values (6,6); INSERT INTO ResInter (NoInscrit,IdManche) values (8,6);
Page : 15

6-MISE A JOUR DES TABL ES DE JO AVEC LES RESULTATS

-- patinage femme UPDATE ResInter SET NbPts=5.88 WHERE (NoInscrit=5 and IdManche=3); UPDATE ResInter SET NbPts=5.21 WHERE (NoInscrit=7 and IdManche=3) ; UPDATE ResInter SET NbPts=4.78 WHERE (NoInscrit=9 and IdManche=3); UPDATE ResInter SET NbPts=5.61 WHERE (NoInscrit=5 and IdManche=4); UPDATE ResInter SET NbPts=5.95 WHERE (NoInscrit=7 and IdManche=4); UPDATE ResInter SET NbPts=5.30 WHERE (NoInscr it=9 and IdManche=4); UPDATE Participe SET Place=1, Medaille='Or' WHERE NoInscrit=5; UPDATE Participe SET Place=2, Medaille='Argent' WHERE NoInscrit=7; UPDATE Participe SET Place=3, Medaille='Bronze' WHERE NoInscrit=9; -- patinage homme UPDATE ResInter SET NbPts=5.75 WHERE (NoInscrit=1 and IdManche=5); UPDATE ResInter SET NbPts=5.84 WHERE (NoInscrit=6 and IdManche=5); UPDATE ResInter SET NbPts=5.03 WHERE (NoInscrit=8 and IdManche=5); UPDATE ResInter SET NbPts=4.56 WHERE (NoInscrit=1 and IdManche=6); UPDATE ResInter SET NbPts=5.32 WHERE (NoInscrit=6 and IdManche=6); UPDATE ResInter SET NbPts=5.21 WHERE (NoInscrit=8 and IdManche=6); UPDATE Participe SET Place=2, Medaille='Argent' WHERE NoInscrit=1; UPDATE Participe afpa-St Brieuc-Langueux Participation : Frdrique GOUYA -DI 07/02 Page : 16

Place=1, Medaille='Or' WHERE NoInscrit=6; UPDATE Participe SET Place=3, Medaille='Bronze' WHERE NoInscrit=8; -- slalom homme UPDATE ResInter SET Temps='00:04:23' WHERE (NoInscrit=2 and IdManche=1); UPDATE ResInter SET Temps='00:05:02' WHERE (NoIns crit=3 and IdManche=1); UPDATE ResInter SET Temps='00:04:51' WHERE (NoInscrit=11 and IdManche=1); UPDATE ResInter SET Temps='00:04:44' WHERE (NoInscrit=12 and IdManche=1);
SET
UPDATE Participe SET Place=2, Medaille='Argent' WHERE NoInscrit=12; UPDATE Participe SET Place=1, Medaille='Or' WHERE NoInscrit=2; UPDATE Participe SET Place=3, Medaille='Bronze' WHERE NoInscrit=11; UPDATE Participe SET Place=4 WHERE NoInscrit=3; --slalom femme UPDATE ResInter SET Temps='00:05:12' WHERE (NoInscr it=4 and IdManche=2); UPDATE ResInter SET Temps='00:04:59' WHERE (NoInscrit=10 and IdManche=2); UPDATE ResInter SET Temps='00:05:24' WHERE (NoInscrit=13 and IdManche=2); UPDATE Participe SET Place=2, Medaille='Argent' WHERE NoInscrit=4; UPDATE Participe SET Place=1, Medaille='Or' WHERE NoInscrit=10; UPDATE Participe SET Place=3,
Page : 17

Medaille='Bronze' WHERE NoInscrit=13;
Page : 18

7-REQUETES REQ 1 : RESULTATS DU SLALOM GEANT HOMME : ALGEBRE RELATIONNELLE : Analytique : R1=REST (EPREUVE ; CodEpr = 1 ) R2=JOIN (EPREUVE , PARTICIPE , ATHLETE ; (EPREUVE .CodEpr = PARTICIPE .CodEpr) ET (PARTICIPE .NoInscrit = ATHLETE .NoInscrit) R3=PROJ(R2, EPREUVE .NomEpr, ATHLETE .NomAthl, PARTICIPE .medaille) Graphique : Rsultat
epreuve.NomEpr, Athlete.NomAthl, participe.medaille
PARTICIPE .NoInscrit
ATHLETE .NoInscrit
ATHLETE
EPREUVE .CodEpr PARTICIPE .CodEpr
PARTICIPE
EPREUVE .CodEpr = 1
EPREUVE
REQUETE SQL : Select epreuve.NomEpr, Athlete.NomAthl, participe.medaille from epreuve inner join (participe inner join Athlete on participe.NoInscrit = Athlete.NoInscrit) on epreuve.CodEpr = participe.CodEpr where epreuve.CodEpr = 1 order by participe.place
Page : 19
Bases de donnes : Prsentation gnrale et Mthode de Conception
Bases de donnes :
Prsentation gnrale et Mthode de conception
Lcu Rgis : CFPA Champs/Marne, Formation APIAI (origine CFPA Dijon)
Chapitre 1 Gnralits sur les bases de donnes ___________________________ 3 Chapitre 2 Objectifs de l'approche SGBD_________________________________ 5
2.1 Intgration et corrlation ____________________________________________ 5 2.2 Flexibilit ou indpendance ___________________________________________ 6 2.3 Disponibilit________________________________________________________ 6 2.4 Scurit ____________________________________________________________ 6
Chapitre 3 Architecture fonctionnelle d'un SGBD : ANSI-SPARC ____________ 7

3.1 Niveau conceptuel __________________________________________________ 7 3.2 Niveau externe _____________________________________________________ 9 3.3 Niveau interne ou Physique ___________________________________________ 9
Chapitre 4 Fonctionnement d'un SGBD ________________________________ 10

4.1 Chronologie des oprations dans linterrogation dun SGDB ______________ 10 4.2 Les langages d'un SGBD____________________________________________ 10
Chapitre 5 Rle de l'administrateur de la base____________________________ 12 Chapitre 6 Principaux modles logiques_________________________________ 13

6.1 Le modle hirarchique_____________________________________________ 13 6.2 Le modle en rseau _______________________________________________ 14 6.3 Le modle relationnel ______________________________________________ 16
Chapitre 7 Conception de bases de donnes ______________________________ 17

7.1 Les Formes normales_______________________________________________ 17 7.2 Dmarche de conception ____________________________________________ 19 7.3 Les phases de la conception avec un symbolisme de type MERISE ______ 21
Chapitre 8 Exercices ________________________________________________ 26
APIAI Champs/Marne (origine Dijon)
page 2
CHAPITRE
GENERALITES SUR LES BASES DE DONNEES
Dfinition et Historique
Une base de donnes est un ensemble structur de donnes enregistres sur des supports informatiss, pouvant satisfaire simultanment plusieurs utilisateurs de faon sl ective, en un dlai raisonnable. Le concept de Base de Donnes (BDD) est apparu vers 1960, face au nombre croissant d'informations que les entreprises devaient grer et partager : chaque nouvelle application crait alors ses propres fichiers de donnes e t ses propres programmes ; le concept de base de donnes va l'encontre de cette faon de procder : il permet la centralisation, la coordination, l'intgration et la diffusion de l'information archive.
La base de donnes enregistre les faits ou vnements qui surviennent dans la vie d'un organisme, pour les restituer la demande : elle permet galement de tirer des conclusions en rapprochant plusieurs faits lmentaires. Les donnes peuvent tre manipules par plusieurs utilisateurs ayant des vues diffrentes sur ces donnes ("points de vue" diffrents). La structure densemble des donnes suit une dfinition rigoureuse appele SCHEMA.
Facteurs lis au dveloppement des SGBD :

augmentation des capacits mmoire, et diminution des temps d'accs apparition sur le march dapplications fiables et diversifies, qui doivent partager leurs donnes dveloppement des systmes de gestion en temps rel : "Gestion transactionnelle" approche globale "oriente donnes" des problmes de gestion : les donnes sont organises de faon rationnelle plutt que dfinies au coup par coup selon les applications raliser.
Rappel sur les systmes de gestion de fichiers

Toute manipulation de fichier exige trois niveaux dintervention, et trois couches logicielles : Gestion du support physique : disques durs, disquette, streamers Pilote dentres-sorties (Driver) Gestion des structures internes des fichiers, et des mthodes daccs : ouverture, fermeture, lecture, criture
Systme de gestion de fichiers (SGF) Gestion des contenus : calculs, tests, affichages ... Programmes applicatifs
APIAI Champs/Marne (origine Dijon) page 3
Applications Matriel
Ouvrir, fermer lire, crire Programme applicatif Code derreur ou
Systme d'exploitation
Demande d'un enregistrement physique
Units de lecture et/ou criture
SGF
Code derreur ou Enregistrement physique
Donnes logiques
Niveau logique
Niveau physique
Systme de Gestion de Base de donnes : SGBD

Ensemble des programmes et des langages de commande qui permettent de : dfinir des "bases de donnes", et des relations entre les lments de chaque base ; spcifier le traitement de ces donnes : interrogations, mises jour, calculs, extractions...
Le SGBD reoit des commandes aussi bien des programmes d'application que des utilisateurs : il commande les manipulations de donnes, gnralement par l'intermdiaire d'un SGF.
Utilisateur Ouvrir, fermer, Gestion de la Base lire, crire SGBD Code rponse, Programme applicatif Donnes logiques SGF Enreg. physique ou code erreur Demande d'un enreg. physique Units De Lecture/ Ecriture
page 4
CHAPITRE
OBJECTIFS DE L'APPROCHE SGBD
Pour pallier aux inconvnients des mthodes classiques de gestion de fichiers, les SGBD visent quatre objectifs : intgration et corrlation, flexibilit (indpendance), disponibilit, scurit. Ces objectifs exigent une distinction nette entre les donnes et les procdures de manipulation de ces donnes : aux donnes, on associera une fonction d'administration des donnes, aux procdures de manipulation une fonction de programmation.
at Intgration et corrlation
Dans les systmes classiques, chaque application gre ses donnes dans ses propres "fichiers", do :
-
Un risque de redondance, et un danger d'incohrence des donnes

La mme donne peut appartenir plusieurs applications, induisant une dperdition de stockage. Toute modification de cette donne est enregistrer plusieurs fois : si cette mise jour multiple n'est pas effectue correctement, les donnes deviennent incohrentes. Le cot de la mise jour augmente du fait de la multiplication des entres -sorties physiques.
Une difficult pour crer de nouveaux traitements

Les nouvelles applications entranent des duplications supplmentaires d e donnes. Leur intgration avec les applicatifs en exploitation entrane des modifications importantes.
Dans l'approche SGBD, un "rservoir" commun ( intgration) est constitu, reprsentant une modlisation (corrlation) aussi fidle que possible de l'organisation relle de l'entreprise :
Toutes les applications puisent dans ce rservoir, les donnes qui les concernent, vitant ainsi les duplications. Mais le partage des donnes entre les utilisateurs pose le problme de la synchronisation des accs concurrents .
page 5
ag Flexibilit ou indpendance
Dans les systmes classiques, tout changement intervenant dans le stockage des donnes (support, mthode d'accs physique) entrane des modifications lourdes des applications correspondantes. L'approche SGBD poursuit trois objectifs, pour assurer lindpendance des donnes par rapport aux traitements : indpendance physique: tout changement de support, de mthode d'accs reste transparent au niveau de l'utilisateur. indpendance logique : les programmes d'applic ation sont rendus transparents une modification dans l'organisation logique globale, par la dfinition de sous -schmas couvrant les besoins spcifiques en donnes. indpendance vis--vis des stratgies d'accs : l'utilisateur n'a plus prendre en charge l'criture des procdures d'accs aux donnes. Il n'a donc pas intgrer les modifications tendant optimiser les chemins d'accs (ex: cration d'index).
2.3 Disponibilit

Le choix d'une approche SGBD ne doit pas se traduire par des temps de traiteme nt plus longs que ceux des systmes antrieurs. Lutilisateur doit ignorer l'existence d'utilisateurs concurrents. L'aspect "performance" est donc crucial dans la mise en oeuvre d'une base de donnes. Un tel objectif ne peut tre atteint que si la concepti on d'une base de donnes est mene de faon rigoureuse avec un dcoupage fonctionnel adquat. Les rgles et contraintes inhrentes sont voques lors de l'apprentissage d'une mthodologie d'analyse (exemple MERISE).
2.4 Scurit
-
La scurit des donnes recouvre deux aspects : l'intgrit, ou protection contre l'accs invalide (erreurs ou pannes), et contre l'incohrence des donnes vis--vis des contraintes de l'entreprise. la confidentialit, ou protection contre l'accs non autoris ou la modification i llgale des donnes.
Pour ne pas trop affecter les performances, la scurit doit galement tre prise en compte ds la phase de conception.
page 6
CHAPITRE ARCHITECTURE SGBD : ANSI-SPARC
FONCTI ONNELLE
D'UN
Dans le cadre du groupe de normalisation nord amricain (ANSI ), un groupe d'tudes a t cr en 69, Standard Planning and Requirement Committee (SPARC) avec pour mission, une standardisation des SGBD.
Les travaux ont abouti en 75 (ANSI 75) par la proposition d'une architecture multi niveaux : chaque niveau fonc tionnel, sont associs un modle et un schma de donnes, un langage de description de donnes (LDD) permettant de dcrire les donnes du schma, et un langage de manipulation de donnes (LMD) permettant de les utiliser (accs pour consultation, mise jour...).
Modle externe
Schma Externe
Utilisateur 1
Schma externe
Utilisateur 2
Schma externe
Application 3
Programmeur d'application
Modle conceptuel
Schma conceptuel
Analyste
Schma Modle interne interne
Administrateur de la base
x Niveau conceptuel t
Cest une abstraction aussi fidle que possible, de l'univers de l'entreprise, aprs modlisation et indpendamment de toute rfrence l'utilisation et l'implantation en machine. Le modle conceptuel de donnes (MCD) permet le passage d'un concret inaccessible (l'univers rel) un abstrait manipulable : le schma conceptuel. Celui -ci peut donc tre considr comme la description du contenu de la base : c'est le rsultat d'un travail d'analyse et de conception d'un systme d'information automatis.
page 7

Un schma conceptuel doit offrir les caractristiques suivantes :
puissance de reprsentation : aspects structurels, contraintes existant dans l'univers rel. stabilit et flexibilit : l'ajout d'une nouvelle donne ou d'une nouvelle contrainte ne doit pas entraner de changement important dans le schma. simplicit de comprhension : nombre d'lments rduit, dissociation claire des diffrents concepts. simplicit d'utilisation : nombre restreint d' outils ou de primitives de manipulation. base formelle : la dfinition du schma doit s'appuyer sur une mthode rigoureuse, mathmatique, pour viter toute ambigut d'interprtation et pour garantir la fiabilit des donnes.
Pour aboutir au schma concep tuel, l'analyste doit reprer dans le rel, et recenser de manire exhaustive, toutes les entits et toutes les associations :
Une entit peut tre dfinie comme une personne, un objet, un lieu, un statut, un vnement qui ont une existence dans le monde rel. C'est un objet concret ou abstrait, possdant un certain nombre de caractristiques spcifiques (exemple : le produit x cote y francs). Gnralement, les entits du monde rel se manifestent travers des faits lmentaires. Certains faits faisant intervenir plusieurs entits, il apparat la notion d'association. Une association (ou lien) est un ensemble de deux ou plusieurs entits, chacune d'elles jouant un rle particulier.
Exemple : le fait que la "voiture x" appartienne la "personne y" est u ne association entre les entits "voiture " et "personne".
Selon la notation CODASYL, trois types de liens peuvent tre envisags :
les liens fonctionnels nots N : 1
On a un lien fonctionnel N:1 de A vers B si toute occurrence de A dtermine au plus une occurrence de B, et si toute occurrence de B, correspond un nombre quelconque doccurrences de A. Exemple : dans une compagnie arienne, connaissant le numro d'un vol, on en dduit d'une manire unique la destination, mais plusieurs vols peuvent avoir la mme destination.
Numros Vols
X Y Z W Y Z X
Destinations
page 8
les liens hirarchiques nots 1 : N.
On a un lien hirarchique 1:N de A vers B si une occurrence de A peut dterminer un nombre quelconque doccurrences de B et si, une occurrence de B, correspond au plus une occurrence de A. Exemple : la polygamie est un lien 1 : N de "homme" vers "femme".
- les liens maills nots N : M.

On a un lien maill de A vers B s'il n'existe aucune restriction sur le nombre d'occurrences de A et B intervenant dans le lien. Exemple : dans un lyce donn, un enseignant peut dispenser des cours dans plusieurs matires diffrentes ; de la mme faon, une matire peut tre dispense par plusieurs enseignants.
ag Niveau externe
Le niveau externe comprend les "vues" spcifiques dfinies pour la manipulation des donnes. Il prend en compte les contraintes d'accs imposes par la nature des applications considrer (indpendamment des caractristiques techniques) et exprime les besoins en donnes des diffrents utilisateurs, ou applications.
Le modle logique des donnes (MLD) utilis ce niveau externe peut diffrer de celui utilis au niveau conceptuel. Ainsi, certaines vues peuvent ne pas tre construites dans la base, mais dduites par calcul partir de certaines donnes du schma conceptuel (exemple : anciennet obtenue par diffrence entre anne en cours et annne d'embauche dans la socit).
g Niveau interne ou Physique
Il correspond la reprsentation en machine, a ussi efficace que possible, du schma conceptuel : le schma physique intgre les caractristiques techniques (choix du SGBD, du matriel, du systme dexploitation).
L'efficacit doit tenir compte d'une part des contraintes d'implantation (taille des d isques, optimisation du systme de fichiers), d'autre part des critres d'utilisation (traitement interactif ou en batch, selon la frquence dutilisation et la dure du traitement).
page 9
CHAPITRE
FONCTIONNEMENT D 'UN SGBD
0g Chronologie des oprations dans linterrogation dun SGDB

Un programme d'application A met une demande de lecture de donnes au SGBD sur une des bases :
Le SGBD traite la demande en consultant le sous -schma externe relatif au programme d'application A, obtenant ainsi la description des donn es. Le SGBD consulte le schma conceptuel et dtermine le type logique de donnes extraire. Le systme examine la description physique de la base en rapport avec la requte logique et dtermine le (ou les) enregistrement(s) physique(s) lire. Le systme lance une commande au systme d'exploitation pour rechercher physiquement l'enregistrement dsir. Le systme d'exploitation, par le biais de ses mthodes d'accs, accde l'enregistrement physique. Les donnes demandes sont transfres dans les buffer s, ou mmoires tampons. Le SGBD, partir d'une comparaison entre le schma logique global (conceptuel) et le sous-schma externe de lapplication A, extrait des donnes stockes dans le buffer, l'enregistrement logique rclam par le programme d'applicati on. Il effectue galement les transformations ventuelles de format. Le SGBD transfre les donnes des buffers dans la zone de liaison du programme d'application A. Le SGBD fournit galement des informations "d'tat" au programme d'application, lui signalant en particulier les erreurs ventuellement constates au cours du processus d'extraction. Le programme d'application, qui dispose des donnes et d'informations de "service" en assure la bonne exploitation !
Les ordres d'criture dans la base physique so nt traits par un processus similaire, toute modification ou adjonction tant en gnral prcde d'une opration de lecture. A signaler que, dans la majorit des cas, le SGBD doit traiter simultanment plusieurs demandes de donnes en provenance de plusieurs programmes d'application, utilisant plusieurs schmas externes diffrents.
ig Les langages d'un SGBD
Cette prsentation des SGBD fait apparatre la ncessit de bien diffrencier deux tapes :
page 10

la dfinition des donnes par ladministrateur de la bas e (DBA) leur utilisation par les utilisateurs ou les programmeurs d'application. Le SGBD met donc disposition deux types de langage : LDD et LMD
Langage de Description de Donnes : LDD

Il permet de dcrire prcisment la structure de la base et le mo de de stockage des donnes. Alors que l'utilisation de fichiers permet seulement une description de donnes interne au programme, dans une approche Base de Donnes, on effectue la description de toutes les donnes une fois pour toutes : elle constitue l'en semble des tables et dictionnaires de la base, son schma (terminologie CODASYL).
En particulier, il prcise la structure logique des donnes (nom, type, contraintes spcifiques...), la structure physique (mode d'implantation sur les supports, mode d'accs), la dfinition des sous-schmas ou "vues".
Langage de Manipulation de Donnes : LMD

L'utilisation d'une BDD suppose un grand nombre d'utilisateurs, souvent non informaticiens, ayant des tches et des besoins varis auxquels le LMD doit pouvoir rpond re. Le SGBD fournit deux niveaux daccs : le langage d'interrogation, ou langage de requte interactif
vite le recours des langages gnraux de programmation. Il doit avoir une syntaxe souple, si possible graphique, tre accessible aux non -spcialistes et permettre la formulation de demandes utilisant des critres varis et combins.
le langage hte
pour les traitements rguliers, le SGBD doit fournir une interface permettant l'utilisation de la base l'aide des langages procduraux (COBOL, Pascal, C/C++.), en incorporant les requtes dans des programmes classiques.
Classification des LMD

langages navigationnels (ex : SYMBAD)
dans les SGBD hirarchiques ou rseaux. Les requtes du langage dcrivent les chemins d'accs aux diffrentes donnes, cel les-ci tant gnralement chanes entre elles.
langages algbriques (ex : SQL)

dans les SGBD relationnels. Ils utilisent, pour fournir des rsultats aux requtes, les oprateurs de l'algbre relationnelle.
page 11
CHAPITRE
ROLE DE L'ADMI NISTRATEUR DE LA BAS E
Rsum des fonctions dun SGBD :
description de la structure de la base : schma externes.
interne, conceptuel, sous-schmas
organisation du stockage physique
manipulation des informations : slection, extraction, mise jour
protection des donnes : pour personnaliser les accs la base, il faut identifier l'utilisateur (code et mot de passe) et vrifier qu'il est autoris effectuer les traitements demands (contrle des droits d'accs). scurit, restauration : possibilit de reconstituer la base dans un tat satisfaisant aprs tout incident
optimisation des ressources, tenue dun journal de tous les vnements : le logiciel doit fournir des statistiques prcises sur l'tat de la base et permettre des rorganisations physiques priodiques qui viteront la dgradation des performances globales du systme. intgrit des donnes : cohrence des informations les unes par rapport aux autres
L'essentiel de la mise en oeuvre de ces fonctions revient une personne appele administrateur de la BDD qui doit :
intervenir en tant que conseil lors de l'tape conceptuelle de l'analyse : responsabilit de gestion des donnes dcider des techniques d'accs et de l'implantation physique grer les diverses autorisations d'accs dfinir les stratgies de reprise en cas d'incident suivre rgulirement les performances du systme et raliser en consquence les modifications ou volutions qui s'imposent.
page 12
CHAPITRE
PRINCIPAUX MODELES LOGIQUES
Les trois principaux modles sont, dans l'ordre chronologique de leur arrive sur le march, le modle hirarchique, le modle rseau (ou navigationnel), le modle relationnel.
3 Le modle hirarchique g
Exemple : le Systme dinformation d'une compagnie arienne
Socit
Salaris
Vols
Matriel
Pilotes
Htesses
Entretien
Administratif
L'anctre le plus rpandu est le SGBD IMS (Information Management System), dvelopp et commercialis par IBM dans les annes 70 Caractristiques gnrales du modle : Forte dpendance entre la description de la structure des donnes et la manire dont celles ci sont enregistres sur le support physique. Les lments de base du modle sont des enregistrements logiques relis entre eux pour constituer un arbre ordonn. Les entits (ou segments) constituent les noeuds, celui de plus haut niveau portant le nom de racine ; les branches (pointeurs logiques entre entits) constituent les liens. Chaque segment est une collection d'objets appels champs (ou fields). Chaque segment a obligatoirement un pre (sauf la racine), et peut avoir plusieurs fils.
Avantages : rigueur des structures et des chemins d'accs simplicit relative de l'implmentation adquation parfaite du modle une entreprise structure arborescente.
page 13
Inconvnients : les accs se font uniquement depuis la racine la structure interdit les liens N:M, ne permettant que le lien 1:N. La reprsentation d'autres relations impose de ce fait une redondance de l'information.
Exemple : comment reprsenter dans ce modle, un parc de vhicules et un ensemble de chauffeurs, chaque chauffeur pouvant conduire plusieurs vhicules, et un vhi cule pouvant tre conduit par plusieurs chauffeurs ?
les "anomalies" que l'on constate lors des oprations de mise jour (insertion, destruction, modification) : l'limination d'un noeud entrane l'limination de tous les segments de niveau infrieur qui lui sont rattachs (risque de perdre des donnes uniques) indpendance logique trs rduite : la structure du schma doit reflter les besoins des applications. pas d'interface utilisateur simple.
4 Le modle en rseau g
Evolution du modle hirarchique intgrant les rsultats du travail du groupe CODASYL (comit de langage de programmation), qui avait dmarr l'tude d'une extension de COBOL pour manipuler les bases de donnes. En 1969, il donne ses premires recommandations concernant syntaxe et smantiq ue du LDD et du LMD. Mme si cette vue est un peu simplificatrice, une base en rseau peut tre dcrite comme un certain nombre de fichiers comportant des rfrences les uns vers les autres. Les entits sont connectes entre elles l'aide de pointeurs lo giques : un enregistrement d'un ensemble de donnes A est associ une srie d'enregistrements (ou records) d'un autre ensemble de donnes B. On constitue ainsi des SET, ou COSET, structure fondamentale du modle en rseau le lien entre les enregistrements de A et ceux de B est 1:N le COSET comporte un type d'enregistrement "propritaire" (l'enregistrement de A est dit OWNER) et un type d'enregistrement "membre" (les enregistrements de B sont MEMBER).
page 14
Avantages et inconvnients du modle : aucune restriction dans la conception : un type de "record" peut la fois tre propritaire et membre de plusieurs sets reprsentation naturelle des liens maills N:M pas d'anomalies pour les oprations de stockage commercialisation importante des systmes correspo ndants (DMS, IDMS, TOTAL, IDS II, SOCRATE...),
MAIS pas d'indpendance par rapport aux stratgies d'accs procduralit importante des langages de manipulation ; l'utilisateur doit "naviguer" dans le rseau logique constitu par les enregistrements et les chanes de pointeurs.
Exemple : schma reprsentant le sous -systme d'information produits / magasins de stockages / fournisseurs / domiciliations bancaires
Produits
Fournisseurs
Magasin de stockage
Produit/Fournisseur
Domiciliation bancaire
page 15
6g Le modle relationnel
C'est un article publi en 1969 par un mathmaticien du centre de recherche IBM, Codd, qui dfinit les bases de ce modle relationnel. Codd s'est intress au concept d'information et a cherch le dfinir sans se proccuper de la technique informatique, de ses exigences et de ses contraintes. Il a tudi un modle de reprsentation des donnes qui repose sur la notion mathmatique de "relation". Dans la pratique, une relation sera reprsente par une table de valeurs.
Exemple: reprsentation d'une table du personnel Matricule 350 780 320 490 Nom Durand Dupond Veillon Martin poste Employ Cadre PDG Cadre Salaire 8000 15000 25000 15000 N dept 320 870 400 320
Dfinitions
Une relation est un ensemble de tuples (lignes), dont l'ordre est sans importance. Les colonnes de la table sont appeles attributs ou champs. Lordre des colonnes est dfini lors de la cration de la table. Une cl est un ensemble ordonn d'attributs qui caractrise un tuple. Une cl primaire le caractrise de manire unique, l'inverse d'une cl secondaire. On dit qu'un attribut A est un dterminant si sa connaissance dtermine celle de l'attribut B (B dpend fonctionnellement de A).
Caractristiques du modle
Schma de donnes facile utiliser : toutes les valeurs sont des champs de tables deux dimensions. Amliore l'indpendance entre les niveaux logique et physique : pas de pointeurs visibles par l'utilisateur.
Fournit aux utilisateurs des langages de haut niveau pouvant ventuellement tre utiliss
par des non-informaticiens (SQL, L4G) et un ensemble d'oprateurs bas sur l'algbre relationnelle : union, intersection, diffrence, produit cartsien, projection, slection, jointure, division. Optimise les accs aux bases de donnes Amliore l'intgrit et la confidentialit : unicit de cl, contrainte dintgrit rfrentielle Prend en compte une varit d'applications, en gestion et en industriel Fournir une approche mthodologique dans la construction des schmas.
page 16
CHAPITRE
CONCEPTION DE BASES DE DONNEES
7g Les Formes normales

Les formes normales permettent de construir e un schma conceptuel correct partir des relations brutes issues des donnes recueillies auprs des clients.
1re forme normale

Une relation est dite en premire forme normale si chaque attribut possde une seule valeur (ce qui exclut les groupes), et si elle admet une cl primaire. Exemple: L'exemple porte sur un ensemble de donnes concernant des tests de types diffrents, effectus sur les lments matriel d'un systme de production : R ( libell matriel, code marque, libell marque, type d e test, date du test, rsultat du test) n'est pas en 1re forme normale car aucun attribut ne peut tre cl primaire : le libell matriel peut tre identique pour plusieurs lments. R (code matriel, libell matriel, code marque, libell marque, code type de test, libell du test, date du test, rsultat du test) n'est pas en 1 re forme normale car on peut faire plusieurs tests sur un mme matriel, ce qui exige de rpter les informations "code type de test", "libell du test", "date du test", "rsul tat du test", dans un mme nuple. La relation doit tre clate en deux, pour tre exprime en 1 re forme normale : R-MATERIEL (code matriel, libell matriel, code marque, libell marque) R-TEST (code matriel, code type, libell test, date du test, rsultat du test) Les deux relations ne comportent que des attributs sans rptition. Dans R_TEST, la cl primaire est compose de "code matriel" et "code type" : un type de test peut concerner plusieurs matriels, un matriel peut tre test plusieurs f ois, mais chaque matriel ne subit quune fois un type de test donn.
page 17
2me forme normale

Une relation est dite en deuxime forme normale si elle est en premire forme normale, et si tout attribut n'appartenant pas la cl primaire ne dpend pas que d'une partie de cette cl. R-TEST(code matriel, code type, libell test, date du test, rsultat du test) n'est pas en 2 me forme normale car l'attribut "libell test" ne dpend que du "code type" et pas du "code matriel" ; La relation doit clate en deux, pour tre exprime en deuxime forme normale : R-TEST (code matriel, code type, date du test, rsultat du test) R-TYPETEST (code type, libell test)
3me forme normale

Une relation est dite en troisime forme normale si elle est en deuxime fo rme normale, et si toutes les dpendances fonctionnelles issues de la cl primaire sont directes
R-MATERIEL(code matriel, libell matriel, code marque, libell marque) La dpendance entre "code matriel" et "libell marque" n'est pas directe, "libell marque" est en dpendance fonctionnelle directe avec le "code marque". La relation doit tre clate en deux, pour tre exprime en troisime forme normale : R-MATERIEL(code matriel, libell matriel, code marque) R-MARQUE(code marque, libell marque)
Le schma conceptuel final de la base de donnes est donc : R-MATERIEL (code matriel, libell matriel, code marque) R-MARQUE (code marque, libell marque) R-TYPETEST (code type, libell test) R-TEST (code matriel, code type, date du test, rsultat du test)
page 18
Commentaires: Le schma conceptuel fait apparatre 3 relations entits : R-MATERIEL, R-MARQUE, R-TYPETEST et la relation association R-TEST qui ralise le lien Matriel <--> Type test de type N:M Le lien fonctionnel Matriel <--> Marque de type N:1 est ralis par la prsence du "code marque" dans la relation R-MATERIEL.
N MATERIEL 1
1 MARQUE TYPE TEST 1
TEST N N
-S Dmarche de conception
Concevoir une base de donnes relationnelle, c'est tablir pour le systme d'information tudi, les relations entits et les relations associations en troisime forme normale.
1re tape : Etablir les schmas externes, c'est --dire lister les donnes ncessaires chaque utilisateur de la future base.
2me tape : Etablir le dictionnaire de donnes en regroupant les schmas externes, en supprimant les redondances et en ne conservant que les informations lmentaires (non dduites). Ceci revient lister les attributs de la base.
Dictionnaire de donnes du systme d'informations relatif aux tests sur les matriels de production : code matriel, libell matriel code marque, libell marque code type de test, libell du test, date du test, rsultat du test
3me tape : Etablir les contraintes d'intgrit fonctionnelle (ou dpendances fonctionnelles) entre attributs. Attributs En dpendance fonctionnelle avec
page 19
code matriel
Entit = Cl + Attributs dpendants
libell matriel code marque libell marque code type de test libell du test
code matriel
code marque
code type de test code matriel + type de test code matriel + type de test
Association
date du test rsultat du test
4me tape : En dduire les relations "entits" et les relations "associations avec attributs" : Les entits sont contitues dune cl primaire et dun ou plusieurs attributs qui ne dpendent fonctionnellement que de cette cl Les associations sont constitues dune liste dau moins deux cls reprsentant des entits, et dattributs qui dpendent de ces cls
Entits : Matriel, Marque, Type de test Association avec attributs : Test
5me tape : Etablir les relations "associations sans d'attributs" en considrant deux cas : Il existe un lien fonctionnel N : 1 entre les entits : la cl primaire de l'entit mre devient cl trangre dans l'entit fille
Exemple: matriel-marque. Lentit "Matriel" dpend (est fille) de l entit "Marque" : la cl trangre "code marque" dans "Matriel" pointe sur la cl primaire "code marque" dans "Marque" . Le lien entre les deux entits est de type N:M : il faut crer une nouvelle relation association sans attributs, qui contient seulement les cls primaires des deux relations associes.
6me tape: Reprsenter le schma de la base
7me tape: S'assurer que les relations sont en troisime forme normale.
page 20

1g Les phases de la conception avec un symbolisme de type MERISE
Prsentation
Sans faire un expos sur la mthode Merise, ce chapitre voudrait prsenter succinctement les diffrents modles des donnes (MCD Conceptuel, MLD Logique, MPD Physique), titre de comparaison avec la mthode maison qui vient dtre expose. Aprs avoir recueilli les donnes auprs des clients (tape 1), supprim les redondances (tapes 2), class les donnes selon les dpendances fonctionnelles (tape 3), on construit le modle conceptuel entits/associations (tape 4), o les associations sont des relations values, comportant un ou plusieurs attributs :
Association R avec la proprit PropR.1
Objet1 Prop1.1 Prop1.2
0,1
R PropR .1
Objet2 0,n Prop2.1
Entit
Min, Max cardinalit
A partir du modle conceptuel, on peut dduire le modle logique et physique par des
oprations systmatiques (tape 5 et 6) : lapplication complte de la mthode Merise garantit lobtention des formes normales. Le passage du MCD au MLD, puis au MPD dpend de la cardinalit des relations.
Du MCD au MPD, pour un lien fonctionnel (N :1) ou hirarchique (1 :N) M.C.D

Objet1 Prop1.1 Prop1.2 0,1 R PropR. 1 Objet2 0,n Prop2.1
Exemple :
Livres Titre Auteur Emprunt 0,1 Date 0,n Adh. Nom
Lassociation est emprunt le contient la proprit Date

Cardinalit : Un livre peut tre emprunt 0 ou une fois (min = 0, max = 1 dans la notation
Merise). Un adhrent peut emprunter de 0 N livres lien fonctionnel N : 1 dans la notation ANSI -SPARC
(min= 0, max= N)
page 21
La relation inverse emprunte le est une relation hirarchique 1 :N
Adh Nom
0,n
Emprunte Date
Livre 0,1 Titre Auteur
M.L.D
OBJET1 Prop1.1 Prop1.2 PropR.1
OBJET2 Prop2.1
Rgle : les proprits de lassociation glissent du ct 0-1, la flche pointe vers le ct 0,n
Livres Titre Auteur Date
Adh Nom
Dans la table Livres, on ajoute la date de lemprunt, et une flche vers ladhrent emprunteur
MPD
Objet1 (Prop1.1, Prop1.2, PropR.1, Prop2.1) Objet2 (Prop2.1)
Rgle : une cl trangre Prop2.1 pointant sur objet2.Prop2.1 est ajoute objet1
Livres Adherents
(Titre, Auteur, Date, Nom) (Nom)
Dans la relation Livres, on ajoute la cl trangre Nom , pointant sur Adherents.Nom
Du MCD au MPD pour une Relation 0-N : 0-N

M.C.D
Objet1 Prop1.1 Prop1.2 0,n R PropR.1 0,n Objet2 Prop2.1
page 22

Exemple :
Auteurs Nom Prnom 1,n
crit
Date
Livres 1,m Ident Titre.
Lassociation "crit"contient la proprit "Date" (de parution)

Cardinalit de la relation : Un auteur peut crire de 1 n livres . Un livre peut avoir de 1 m
auteurs => lien maill N : M dans la notation ANSI -SPARC
M.L.D
OBJET1 Prop1.1 Prop1.2
R PropR.1
OBJET2 Prop2.1
Rgle : lassociation devient une nouvelle table et les flches pointent vers les tables lies
Auteurs Nom Prnom
Ecrit Date
Livres Ident Titre
On cre une nouvelle table crit , avec la proprit Date , et des liens vers les cls des entits Auteurs et Livres
MPD Objet1 (Prop1.1, Prop1.2) R1 (Prop1.1, Prop2.1, PropR.1)
Objet2 (Prop2.1)
Rgle : la relation devient une table dont la cl est la concatnation des cls des deux objets lis.
Exemple : Livres (Ident, Titre)
Ecrit (Nom, Ident , Date) Auteurs (Nom, Prnom)
page 23
Exemple rcapitulatif
MCD
Client NClient 0,n NomClient PrenomClient
Passe
Commande 1,1 NCommande DateCommande MontantCommande
1,n
SeComposeDe Qte TauxTva
Article NArticle 0,n DesignationArticle PUArticle
MLD
Client NClient NomClient PrenomClient
Commande NCommande DateCommande MontantCommande
SeComposeDe Qte TauxTva
Article NArticle DesignationArticle PUArticle
MPD
Client Commande
(NClient, NomClient, PrenomClient). (NCommande, DateCommande, MontantCommande, NClient).
SeComposeDe (NCommande, NArticle, Qte, TauxTva). Article (NArticle, DesignationArticle, PUArticle).
Du MCD au MPD, dans une Relati on ternaire

MCD
Profs Matiere
Matiere CoeffMatiere Enseigne Nom Prenom Age Salaire
1,n
1,n 1,n
1,n Cours
DateCours HeureCours
1,n Salle
NSalle DesignationSalle
page 24

MLD
Matiere Matiere CoeffMatiere Enseigne Profs NomProf PrenomProf AgeProf SalaireProf
Cours DateCours HeureCours
Salle NSalle DesignationSalle
MPD
Matiere (Matiere, CoeffMatiere). Enseigne (NomProf, Matiere). Profs Cours Salles (NomProf, PrenomProf, AgeProf, SalaireProf). (NomProf, Matiere, NSalle, DateCours, HeureCours). (NSalle, DesignationSalle)
Rgle : une relation ternaire devient une table dont la cl est la concatnation des cls des trois objets lis.
page 25
CHAPITRE
ENONCE 1
EXERCICES
Trouvez les formes normales des relations suivante s (exercices indpendants) :
R1 (N client, n produit, quantit commande, nom produit)
R2 (N commande, n produit, quantit commande) Dans chaque commande mise, on commande certaines quantits de plusieurs produits. Un mme produit peut tre command dans plusieurs bordereaux de commandes
R3 (N client, nom client, nom reprsentant) Un client peut tre suivi par plusieurs reprsentants de lentreprise. Pour simplifier, on supposera que les noms des reprsentant sont uniques, et quun reprsentant n e dmarche quun seul client.
R4 (N produit, nom produit, n atelier, nom chef d'atelier) Chaque produit est fabriqu dans un seul atelier. Il ny a bien sr quun chef par atelier !
R5 (N produit, n fournisseur, nom fournisseur)
Pour les noncs qui suivent, il est demand d'tablir le schma de la base en prsentant les relations entits et les relations associations pour chacun des domaines tudi, en suivant la dmarche du chapitre 7.2. On reprsentera le modle conceptuel avec un symbolisme Mer ise.
ENONCE 2
Une socit d'dition de livres et manuels universitaires dcide de s'informatiser. Elle souhaite en particulier automatiser le calcul des droits d'auteur. On a relev lors de l'tude les lments suivants : un auteur est class dans une seule spcialit un livre appartient ou non une collection. S'il appartient une collection, il ne peut appartenir qu' une seule collection. les droits d'auteur sont calculs sur le nombre d'exemplaires vendus dans l'anne.
page 26
Voici le document envoy a ux auteurs permettant leur paiement :
Relev des droits d'auteur Anne 1995 Auteur n 73 Monsieur Dupont Jean 3 rue des alouettes 25 BESANCON Spcialit: Mathmatiques Titre: Mathmatiques pour la gestion Collection: Mathmatiques appliques Taux droits d'auteur: 8% N SS 1520373265005 N ouvrage: 850 N Collection: 6 Nombre d'ouvrages vendus: 800
N ouvrage: 647 N Collection: 6 Nombre d'ouvrages vendus: 1000
Titre: Mathmatiques pour tous Collection: Mathmatiques appliques Taux droits d'auteur: 10%
Total gnral : 11400 F Taxe (5%) NET A PAYER : 570 F 11970 F
page 27
ENONCE 3
Une troupe thatrale se produit dans le monde entier. L'quipe tablit rgulirement le document dcrit plus loin. Elle vous demande de l'analyser en vue d'une informatisation.
Date du jour
RECAPITULATIF DES REPRESENTATIONS PAR AUTEURS
AFRIQUE
nom de l'auteur
AMERIQUE
ASIE
EUROPE
OCEANIE
titre de la pice
nbre reprs.
date
nbre reprs
date
nbre reprs
date
nbre reprs
date
nbre reprs.
date
nom de l'auteur
titre de la pice
nbre reprs.
date
nbre reprs.
date
nbre reprs.
date
nbre reprs.
date
nbre reprs.
date
page 28

ENONCE 4
Un grand garage se propose d'informatiser son systme de gestion en introduisant une base de donnes pour l'tablissement des factures.Voici l'image du document facture:
GARAGE CHARLES FACTURE N: 87234B DATE FACTURE: 30/08/95
Monsieur DUPONT Jacques Tel: 89.52.15.32 3 rue des roses Intervention N 37843 Date entre vhicule: 25/08/95 Date sortie vhicule: 26/28/95 Vhicule N 6837 VH 68 Marque: RENAULT Type R21
Anne de mise en service: 1990
CODE OPERATION
LIBELLE
CODE OUVRIER
COUT STANDARD
FOURNITURES ou PIECES
62
Rglage Allumage
G12
52.00
7.00
27
Vidange Graissage
G23
78.00
373.00
TOTAL H.T. MONTANT TVA
510.00 F 102.00 F
MONTANT TTC
612.00 F
Pour laborer ce document, on a relev les points suivants : Une entre d'un vhicule reoit un numro d'intervention ; Chaque intervention est forme d'une suite d'oprations ; Chaque opration correspond un travail codifi et affect d'un cot standard dfini par le garage. Pour une opration donne sur un vhicule donn, un seul ouvrier intervient.
page 29

Bases de Donnees

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bases de Donnees

Transféré par

Droits d'auteur :

Formats disponibles

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.

. Construction dune BDD

. Manipulation dune BDD

. Traitements dans les BDD

. Scurits des BDD

. Accs aux BDD dans les langages htes

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Modle Conceptuel de Donnes

NO6 A30 A30 N5 A30 A15

Facture Numro facture Date facture

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Cas Note

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Cas Niche

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Cas FAP

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Cas Rservation Htel

Liste des proprits :

Le type de chambre dpend de la capacit, du degr de confort et de lexposition de la

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

1 - Conception dune BDD Relationnelle Passage au Modle Logique

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Modle Logique de Donnes :

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

2 - Construction dune BDD Langage de dfinition SQL

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

3 - Manipulation dune BDD Langage de manipulation SQL INSERT

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

3 - Manipulation dune BDD Langage de manipulation SQL SELECT TRI

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Regroupement sur CODE_POSTAL

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

NUMERO_FACTURE DATE_FACTURE RAISON_SOCIALE BUREAU_DISTRIBUTEUR

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

3 - Manipulation dune BDD Langage de manipulation SQL UPDATE

afpa Roubaix Didier DENRY

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com