Cours1 AdmBD 3L

Université Hassiba Benbouali Chlef
Faculté des Sciences Exactes et Informatique

Département d’Informatique 2019-2020
Objectif : - Présenter les règles essentielles permettant de concevoir et entretenir une base de
données cohérente.
- Présenter les langages d’interrogations permettant de tirer profit de ces données.
Contenu de la matière (Sommaire)
Chapitre 1 : Rappels sur les Bases de Données

(Rappels sur la modélisation des données, les bases de données (BD), Historique des SGBD,
Modèle Entités Association, Passage au modèle relationnel, etc.)
Chapitre 2 : Modèle relationnel

(Modèle relationnel, SGBD relationnel, Interrogation des BD, Langages de BD (Algèbre
relationnelle, calcul, SQL), Intégrité des données. Informations incomplètes aux BD,
Normalisation)
Chapitre 3 : Optimisation des requêtes (Opérateur algébrique, Optimisation du SGDB, etc.)
Chapitre 4 : Contrôle des accès concurrents & Sécurité (Contrôle des accès concurrents,
Résistance des pannes et la sécurité des données)
Chapitre 4: Bases de données semi-structurées & multimédias (BD semi-structurées et

XML, Interrogation (Xquery, Xpath, etc.), Indexation, Optimisation, BD multimédias.
Chapitre1 : Rappels sur les Bases de Données

1. Introduction
Les bases de données ont pris aujourd’hui une place essentielle dans l’informatique, plus en
gestion. Au cours des dernières années, des concepts, méthodes et algorithmes ont été
développés pour gérer des données sur mémoire secondaires ; ils constituent aujourd’hui
l’essentiel de la discipline « Bases de Données » (BD). Cette discipline est utilisée dans de
nombreuses applications. Aussi, il existe un grand nombre de Systèmes de Gestion de Bases
de Données (SGBD) qui permettent de gérer efficacement de grandes bases de données. De
plus, une théorie fondamentale sur les techniques de modélisation des données et les
algorithmes de traitement a vu le jour. Les bases de données constituent donc une discipline
s’appuyant sur une théorie solide et offrant de nombreux débouchés pratiques.
2. Définitions & Bases de données
2.1 Base de données (BD): Une collection de données en relation logique (cohérent, intégré,
partagé) et une description des données, conçues pour satisfaire les besoins d’information
nécessaires au fonctionnement d'une entreprise (ou organisme). La gestion de cet ensemble de
données est assurée par un logiciel appelé système de gestion de bases de données (SGBD).
2.2 Banque de données: Une base de données est développée au sein d'une entreprise, pour
son propre fonctionnement. Inversement, une banque de données est un ensemble de données,
Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 2

propres à un domaine d'application, que des "producteurs" réunissent pour ensuite les
commercialiser vers le public extérieur.
2.3 Fichier : Ensemble d’enregistrements identifié par un nom, qui constitue une unité
logique de stockage de données pour un ordinateur. Les années 60 ont connu un premier
développement des bases de données sous forme de fichiers reliés par des pointeurs. Les
fichiers sont composés d’articles stockés les uns à la suite des autres et accessibles par des
valeurs de données (appelées clés). Les systèmes IDS.I et IMS.I, développés respectivement à
Honeywell et à IBM vers 1965, permettent de constituer des chaînes d’articles entre fichiers et
de parcourir ces chaînes.
Exemple: Dans une entreprise, il convient de faire appel à l'approche base de données lorsque
les données à gérer sont de natures diverses (exemple : étudiants, cours, enseignants, salles,
etc.) et possèdent de nombreux liens entre elles (exemple : un étudiant suit un cours, un cours
est assuré par un enseignant, etc.).
Cependant, il existe des cas où les données à gérer, bien que importantes en volume, sont
homogènes : les abonnés d'une revue, le personnel d'une entreprise, les produits vendus par un
magasin, etc. Dans ces cas, on parlera de fichier (le fichier des abonnés, ...) et l'on utilisera un
système de gestion de fichiers (SGF), moins complexe qu'un SGBD.
Figure 1 : Utilité d’une Base de Données.
3. Système de gestion de base de données (SGBD): un logiciel de haut niveau qui permet à
des utilisateurs de définir, créer, mettre à jour une base de données et d’en contrôler l’accès.
Aussi, il permet de gérer et manipuler les informations stockées dans une base de données
partagée par plusieurs utilisateurs simultanément.

Figure 2 : Schéma de fonctionnement d’un SGBD (accès des utilisateurs).
3.1 Historique des SGBD

L'évolution historique des bases de données (voir figure 3), suit les avancées réalisées dans
des domaines divers comme : Systèmes d'exploitation, Langages de programmation, Logique.
Les premiers SGBD sont réellement apparus à la fin des années 60. La première génération
de SGBD est marquée par la séparation de la description des données et de la manipulation
par les programmes d’application. Elle coïncide aussi avec l’avènement des langages d’accès
navigationnels, c’est-à-dire permettant de se déplacer dans des structures de type graphe et
d’obtenir, un par un, des articles de fichiers. Cette première génération, dont l’aboutissement
est marqué par les recommandations du CODASYL, est basée sur les modèles réseau ou
hiérarchique, c’est-à-dire des modèles de données organisés autour de types d’articles
constituant les noeuds d’un graphe, reliés par des types de pointeurs composant les arcs du
graphe. Cette génération a été dominée par les SGBD TOTAL, IDMS, IDS 2 et IMS 2.
La deuxième génération de SGBD a grandi dans les laboratoires depuis 1970, à partir du
modèle relationnel. Elle vise à enrichir mais aussi à simplifier le SGBD externe afin de
faciliter l’accès aux données pour les utilisateurs. En effet, les données sont présentées aux
utilisateurs sous forme de tables. Les recherches et mises à jour sont effectuées à l’aide d’un
langage non procédural standardisé appelé SQL (Structured Query Language). Celui-ci
permet d’exprimer des requêtes traduisant directement des phrases simples du langage naturel
et de spécifier les données que l’on souhaite obtenir. Les systèmes de deuxième génération
sont commercialisés depuis 1980. Ils représentent aujourd’hui l’essentiel du marché des bases
de données. Les principaux systèmes sont ORACLE, INGRES, SYBASE, INFORMIX, DB2
et SQL SERVER. Ils supportent en général une architecture répartie, au moins avec des
stations clients transmettant leurs requêtes à de puissants serveurs gérant les bases.
Figure 3 : Evolution de la gestion des données (Meynard, 2020), tels que : IDS Integrated Data Store, IMS
Information Management System, CODASYL Conference on Data System Language.

Avant les années 60, le développement des SGF (Systèmes de Gestion Fichier) partagés comportant : (1) des
fonctions de base (création, destruction, allocation de mémoire, localisation) ; et (2) des fonctions de contrôle
(partage, résistance aux pannes, sécurité et confidentialité des données. Durant les années 60, naissance de la
première génération de SGBD, connue par (1) la Séparation de la description des données et des programmes
d'application écrits dans un langage ; et (2) l’Avènement des langages navigationnels et modèles navigationnels
(Modèle Hiérarchique, Modèle Réseau). Durant les années 70, naissance de la deuxième génération de SGBD
connue par : (1) le Modèle Entité-Relation ; et (2) le Modèle Relationnel. Vers les Années 80-2000 : Modèle
Orienté Objet ; et Bases de Données Déductives, etc.
La troisième génération a été développée dans les laboratoires depuis le début des années 80.
Elle commence à apparaître fortement dans l’industrie avec les extensions objet des systèmes
relationnels. Elle supporte des modèles de données extensibles intégrant le relationnel et
l’objet. Les architectures mieux réparties, permettent une meilleure collaboration entre des
utilisateurs concurrents. Ces SGBD, influencés par l’objet, tentent de répondre aux besoins
des nouvelles applications (multimédia, Web, CAO, bureautique, environnement,
télécommunications, etc.).
Quant à la quatrième génération, elle est orientée pour mieux supporter Internet et le Web,
les informations mal structurées, les objets multimédias, l’aide à la prise de décisions et
l’extraction de connaissances à partir des données. La plupart des SGBD à objets sont basés
sur C++, Smalltalk et Java. Ils permettent de gérer des classes d’objets persistants. Java est le
langage objet d’avenir, supporté par la plupart des SGBDO.
3.2 Le Cycle de vie d'une base de données est constituée de : la phase de conception, la
phase d’implantation et la phase d’utilisation. Ce cycle est géré par un SGBD.
3.2.1 La phase de conception: une analyse aboutit à déterminer le futur contenu de la base.
Le but est de déterminer les informations qu’il conviendra de mettre dans la BDD, il faut ainsi
que les utilisateurs de cette BD se mettent d’accord sur la nature des caractéristiques des
informations à garder pour assurer la gestion de l’entreprise. Ensuite ce contenu est transmit
au logiciel SGBD choisi par l’entreprise et cela par le moyen d’un langage symbolique,
spécifique que l’on appelle langage de description des données (LDD)
3.2.2 La phase d’implantation : l’utilisateur peut entrer les données, c'est-à-dire de

constituer la première version initiale de la base de données. Cette phase consiste à décrire la
base de données dans le langage du SGBD et construire cette première version.
3.2.3 La phase d’utilisation: une fois l'implantation terminée, l'utilisation de la base de

données peut commencer. Celle-ci se fait au moyen d'un langage, dit langage de manipulation
de données (LMD), qui permet d'exprimer aussi bien les requêtes d'interrogation (pour obtenir
des informations contenues dans la base) que des requêtes de mise à jour (pour ajouter de
nouvelles informations, supprimer des informations périmées, modifier le contenu des
informations).

4. Les modèles de SGBD : Il existe plusieurs modèles de SGBD, différenciés selon la

représentation des données qu‘ils contiennent.
4.1 Le modèle hiérarchique: les données sont classées hiérarchiquement, selon une
arborescence descendante. Ce modèle utilise des pointeurs entre les différents
enregistrements. Il s'agit du premier modèle du SGBD
Figure 4 : Schéma d’un modèle de BD hiérarchique.
4.2 Le modèle réseau: comme le modèle hiérarchique, ce modèle utilise des pointeurs vers
des enregistrements. Toutefois la structure n'est plus forcément arborescente dans le sens
descendant.
Figure 5 : Schéma d’un modèle de BD en réseau.
4.3 Le modèle relationnel (SGBDR): les données sont enregistrées dans des tableaux à deux
dimensions (lignes et colonnes). La manipulation de ces données se fait selon la théorie
mathématique des relations.
Figure 6 : Schéma d’un modèle de BD relationnel.
4.4 Le modèle objet (SGBDO): les données sont stockées sous forme d'objets, c'est-à-dire de
structures appelées classes présentant des données membres. Les champs sont des instances
de ces classes.

Figure 7 : Schéma d’un modèle de BD orienté objet.
5. Les niveaux d’abstraction des données. Un objectif majeur des SGBD est
d’assurer une abstraction des données stockées sur disques pour simplifier la vision des
utilisateurs. Pour cela, trois niveaux de description de données ont été distingués.
5.1 Le niveau conceptuel: il représente la vue intégrée de tous les utilisateurs, appelé aussi le
MCD ou MLD, il définit l’arrangement les données au sein de la base. Exemple :
Etudiant : nom, prénom, date de naissance, n°étudiant.

Enseignant : nom, prénom, statut, n°compte_bancaire.
Cours : nomC, cycle, nom_enseignant.
Inscription : n°étudiant, nom_cours, note1, note2.
5.2 Le niveau interne: correspond à la structure de stockage supportant les données. Il définit
la façon selon laquelle sont stockées les données et les méthodes pour y accéder.
5.3 Le niveau externe définit les vues des utilisateurs, chaque groupe de travail utilisant des
données possède une description des données perçues, appelée schéma externe. Un groupe de
travail ne peut en effet accéder qu’aux données décrites dans son schéma externe. Les autres
données sont ainsi protégées contre les accès non autorisés ou mal intentionnés de la part de
ce groupe de travail.
Exemple : Schéma externe BD (pour le professeur) :
Etudiant _BD : nom, prénom, note1, note2, note_finale
tel que Etudiant _BD résulte de la combinaison de Etudiant et Inscription du SL,
tel qu'il existe une Inscription de cet étudiant pour le cours BD (n°étudiant dans Etudiant =
n°étudiant dans Inscription et nom_cours dans Inscription = ‘BD’),
tel que note_finale = (note1 + note2)/2

- Schéma externe (pour le service de gestion du personnel enseignant):
Professeur : nom, prénom, n°compte_bancaire, nombre_de_cours, liste(nom_cours)
tel que Professeur résulte de la combinaison de Enseignant et Cours du SL, et liste

(nom_cours) est la liste de nomC qui se trouvent dans Cours tel que nom_enseignant dans
Cours = nom dans Enseignant, et tel que nombre_de_cours = Cardinalité (liste (nom_cours))
Un SGBD gère donc trois types de schémas pour une base de données, qui sont organisés de
la façon suivante:
Figure 8 : SGBD et ses trois schémas.
6. Le modèle Entité-association (ER - Entity Relationship)

Le modèle Entité-association supporte la généralisation et l’agrégation. La généralisation
(generalization) des ensembles d'entités est un processus d'abstraction qui consiste à
généraliser les entités, et donc les ensembles d'entités en un seul ensemble ascendant.
Réciproquement, la spécialisation consiste à définir des ensembles d'entités descendants ou
sous-ensembles d'entités dans une hiérarchie de généralisation. En général, la généralisation
définit une structure EST-UN. Exemple : «Tout employé est soit un cadre supérieur, soit un
spécialiste, soit un apprenti et vice versa». Tandis que l'agrégation permet un regroupement
des entités dans une structure dite MEMBRE-DE. La généralisation et l’agrégation sont deux
importants concepts de structuration.
Ce modèle se compose de trois concepts élémentaires : l'entité, l'association et les

contraintes portant sur ces associations.
6.1 Entité : C’est un objet, un événement, un lieu, une personne identifiable sans ambiguïté.

Exemples :
- Informaticien AEK,
- Compétence Oracle,
- Compétence Hot-Line,
- Client AeroMicroMecanique.
- Contrat C12.
L’informaticien AEK possède la compétence Oracle.
L’informaticien Ibrahim a signé le contrat C12.
* Classe d’Entités (type): Regroupement d’entités de même nature.
Exemple: INFORMATICIENS (AEK, Ibrahim,.....)
6.2 Association : C’est un lien entre deux ou plusieurs Entités.
Exemples :
- « l’Informaticien AEK» a « la compétence Oracle »,
- « l’Informaticien AEK » est affecté au « Contrat C12 » avec la « compétence Expert BD».
* Classe d’Associations: C’est un lien entre deux ou plusieurs classes d’entités.
Exemples :
- Signer (entre Contrats et Clients),
- Affecter (entre Contrats, Compétences et Informaticiens).
Figure 9 : Classe d’associations, elle est présentée par un Ovale ou un losange.
Parmi les types d'association on peut citer :
1. Statique : Ne change pas dans le temps. Ex : Signer, Avoir

2. Dynamique : Variable dans le temps, Gestion d’historiques. Ex: Affecter, Partir
3. Binaire, ternaire, ... selon le nombre de classes d’entités associées à la classe
d’association.
4. Réflexive : Relie deux Entités de la même classe. Ex : suite d’un contrat, compétence
englobant une autre compétence.

Figure 10 : Types d’associations dans un modèle Entité-Association (Merier, 2006).
Le type d'association de EE_1 à EE_2 indique le nombre d'entités provenant de l'ensemble associé EE_2 qui sont
reliées à une entité dans EE_1. On distingue essentiellement les types d'associations suivants: Statique (simple),
Dynamique (conditionnelle), Binaire, ternaire, réflexive (multiple et multiple conditionnelle), etc.
- Propriété (attribut): une donnée que l’on perçoit sur une entité ou une association.
Ex : - Ncli, RaisonSociale, Contact, Tel pour l’entité CLIENTS.
- Nc, Livrable, DateLivraison, Penalites pour CONTRATS
- Matricule, NomI, SalaireBase pour INFORMATICIEN
* Identifiant: propriété ou groupe de propriétés dont la valeur identifie sans ambiguïté une
entité ou une liaison d’une classe (identifiant=clé primaire).
Figure 11: Formalisme graphique d’une entité d’une table : (007, 'AEK, 54000).
* Cardinalités et rôle:- Le rôle détermine la façon dont les entités sont reliées.
• De 0,1 : une entité de A peut être reliée à aucune ou à une seule entité de B
• De 1,1 : une entité de A est reliée à une seule entité de B
• De 0 à plusieurs (0,N) : une entité de A peut être reliée à aucune ou à plusieurs entités de B

• De 1 à plusieurs (1,N) : une entité de A peut être reliée à une ou plusieurs entités de B
Les cardinalités décrivent comment les entités d’une classe peuvent être associées à d’autres
entités. Le rôle d’une association est défini par deux nombres (min,max).
Min Max
0=lien facultatif 1= lien unique
1=lien obligatoire N=plusieurs liens
Exemple :
Figure 12 : Exemple de cardinalités d’une association (signer).
- Combien de fois un contrat est signé par un client ?

Un contrat est obligatoirement signé et il est signé par un seul client (1,1)
- Combien de fois un client signe un contrat ?

Un client ne signe pas forcément de contrat et il peut signer plusieurs contrats (0,n)
9. Passage d’un schéma E/A à un Schéma Relationnel

Le Modèle relationnel représente l'information dans une collection de relations. Il sera
présenté dans le chapitre suivant (2).
– Une relation comme une table à double entrée, voir même comme un fichier.
– Chaque ligne de la table (appelée nuplet ou tuple) peut être vue comme un fait décrivant
une entité du monde. Une colonne de la table est appelée un attribut.
A chaque n-uplet est associé une clé qui l’identifie de manière unique (Unicité des valeurs de
clé). Une clé primaire ne peut contenir de valeur nulle.
• Les n-uplets d'une relation sont distincts deux à deux.
– L'information utilisée dans un n-uplet pour désigner un autre n-uplet est valide, notamment
si le n-uplet désigné existe bien.
Il existe cinq (5) règles de passage au modèle Relationnel pour le cas des associations
simples, une (1) règle pour le cas de la généralisation et une (1) règle pour le cas de
l’agrégation au niveau du modèle Entité- Association. Ces règles permettent de traduire

correctement un modèle entité-association en un schéma de base de données relationnelle

pour les différentes situations. Des exemples illustratifs peuvent être consultés dans (Meier,
2006).
- Règle 1 (ensemble d’entités)

Toute entité est transformée en table. L’identifiant devient la clé primaire de la table. Les
autres attributs de l'ensemble d'entités complètent les attributs de la table.
- Règle 2 (ensembles de liens)

Toute association binaire ((*,1) ou (*, n) tel que * peut être 0 ou 1) va disparaitre et on
duplique l’identifiant de l’entité du côté (*,n) dans celle du côté (*,1).
Donc, chaque ensemble de liens peut être traduit en une table distincte. Les clés
d'identification des ensembles d'entités participantes doivent y figurer comme clés étrangères.
La clé primaire de cette table peut être soit une clé d'identification formée par la
concaténation des clés étrangères, soit une autre clé candidate en créant par exemple une clé
artificielle. Les autres attributs de l'ensemble de liens complètent les attributs de la table.
- Règle 3 (Liaisons de type complexe-complexe)

Toute association binaire de type [(*, n), (*, n)] devient une table ayant comme clé le couple
composé par les deux clés des deux tables issues des entités. Les éventuelles propriétés dans
l’association deviennent des simples attributs dans cette nouvelle table.
Donc, chaque ensemble de liens complexe-complexe doit être transformé en une table
distincte. Elle contient au moins, comme clés étrangères, les clés d'identification des
ensembles d'entités qui participent à la liaison. La clé primaire de la table est soit la clé
d'identification formée par la concaténation des clés étrangères, soit une autre clé candidate.
D'autres attributs de l'ensemble de liens deviennent les attributs de la table.
- Règle 4 (liaisons de type simple-complexe)

Dans une association à trois participants ou plus, l’association devient une table ayant comme
clé composé des clés de toutes les tables issues des entités participantes à cette association.
Les éventuelles propriétés dans l’association deviennent des simples attributs dans cette table.
Donc, un ensemble de liens simple-complexe peut s'exprimer dans les deux tables des
ensembles d'entités participantes sans avoir besoin de créer une table distincte. Pour cela, dans
la table qui participe à l'association simple (association de type 1 ou c), on définit une clé
étrangère qui la relie à la table référencée et l’on ajoute éventuellement d'autres attributs de
l'ensemble de liens considéré.
- Règle 5 (liaisons de type simple-simple)

Un ensemble de liens simple-simple peut s'exprimer dans les deux tables issues des ensembles
d'entités participantes sans avoir besoin de créer une table distincte. L’une des deux tables est
la table référencée dont la clé d’identification apparaît comme clé étrangère dans l’autre table.

- Règle 6 (généralisation)- Règle de passage d’une structure EST-UN

Chaque ensemble d'entités dans une hiérarchie de généralisation donne lieu à une table
distincte. La clé primaire de la table ascendante est aussi celle des tables au niveau inférieur.
- Règle 7 (agrégation) - Règle de passage d’une structure MEMBRE-DE

Dans une structure d'agrégation, si le type de liens est complexe-complexe, une table distincte
doit être créée pour l'ensemble d'entités et une deuxième pour l'ensemble de liens. Cependant,
si la liaison est de type simple-complexe (structure hiérarchique), nous pouvons combiner en
une seule table l'ensemble d'entités et l'ensemble de liens.
Exemple du passage du modèle E-A au Modèle relationnel (Meier, 2006) :

(1) L’Analyse des données : pour le « contrôle des projets », chaque département doit
enregistrer périodiquement des données sur ses employés, les coûts et les durées des projets ;
1. Chaque employé est affecté à un seul département.
2. Un numéro de projet unique est attribué à chaque projet de manière centralisée.
3. Un employé peut travailler sur plusieurs projets simultanément. Le degré de sa participation
à un projet s'exprime en pour-cent.
La figure 16, présente un exemple pour le passage du modèle Entité-Association au modèle

relationnel : une table est créée pour chacun des trois ensembles d'entités, à savoir
DÉPARTEMENT, EMPLOYÉ et PROJET. Pour représenter sous forme tabulaire les liens
entre les ensembles d’entités, on définit pour chaque ensemble de liens une table distincte qui
contient obligatoirement les clés des ensembles d'entités participant à la liaison considérée,
appelées clés étrangères, et éventuellement d'autres attributs qui caractérisent cette liaison.
Dans cet exemple, la table AFFECTATION contient deux clés étrangères, le numéro de
l'employé et celui du département ; la table APPARTENANCE contient deux clés étrangères,
le numéro de l'employé et celui du projet, et un attribut supplémentaire, le degré de
participation au projet, exprimé en pour-cent.

Figure 13 : Les principales phases (2) et (3) de la modélisation des données en modèle E-A, puis le passage au
modèle relationnel (EA R).
Autres Exemples (Krokral, 2018):
Règle 1 : entité non faible
Une entité non faible est présentée par une relation T dont les attributs simples sont les
attributs de l’entité E et la clé de T est l’identifiant de E (Krokral, 2018).
Règle 2 : relation 1 :n
Les attributs d’une association qui a une cardinalité 0,1 ou 1,1 sont ajoutés à l’entité à laquelle
elle est reliée avec cette cardinalité. La clé primaire de l’autre entité qui participe devient clé
étrangère dans la première entité.
Règle 3 : relation n:m

L’association A est représentée par une relation T dont les attributs sont les attributs de A et la
clé est la concaténation des clés des entités participant à l’association A.
Règle 4 : entité faible

Le passage est identique à celui d’une association 1-n. la seule différence est que la clé du fils
migre vers le père est entre dans la constitution de la clé primaire de ce dernier.
Règle 5 : généralisation/spécialisation
1er cas :
2ème cas :
3ème cas :

Règle 6: association 1:1

La migration de la clé peut se faire dans un seul sens comme on peut le faire dans les deux
sens. Il est à noter que quand un cas pareil se présente il est presque impossible que les
cardinalités min des deux côtés soit égales à 1. L’une d’elles est toujours un 0. Ce qui fait que
le sens le plus recommandé pour la migration de la clé est celui allant du côté de la cardinalité
0 vers celui de la cardinalité minimale 1.
Règle 7: entité avec un seul attribut

Quand on est en présence d’une entité ne possédant qu’un seul attribut qui est son identifiant
et que les valeurs de ce dernier sont connus à l’avance ou ne sont pas assez importantes pour
être sauvegardées. Cette entité n’est pas représentée comme le cas de l’entité date.
10. Conclusion
Dans ce chapitre, nous avons présenté les notions essentielles sur les bases de données, le
modèle Entité –Association, les attributs, le cycle de vie d'une base de données, les Systèmes

de Gestion de Bases de données, les règles de passage depuis un modèle Entité-Association

vers un modèle relationnel et d’autres concepts importants.

Cours1 AdmBD 3L

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

Cours1 AdmBD 3L

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassiba Benbouali Chlef

Faculté des Sciences Exactes et Informatique

Chapitre 1 : Rappels sur les Bases de Données

Chapitre 2 : Modèle relationnel

Chapitre 3 : Optimisation des requêtes (Opérateur algébrique, Optimisation du SGDB, etc.)

Chapitre 4: Bases de données semi-structurées & multimédias (BD semi-structurées et

Chapitre1 : Rappels sur les Bases de Données

2. Définitions & Bases de données

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 2

Figure 1 : Utilité d’une Base de Données.

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 3

Figure 2 : Schéma de fonctionnement d’un SGBD (accès des utilisateurs).

3.1 Historique des SGBD

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 4

3.2.2 La phase d’implantation : l’utilisateur peut entrer les données, c'est-à-dire de

3.2.3 La phase d’utilisation: une fois l'implantation terminée, l'utilisation de la base de

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 5

4. Les modèles de SGBD : Il existe plusieurs modèles de SGBD, différenciés selon la

Figure 4 : Schéma d’un modèle de BD hiérarchique.

Figure 5 : Schéma d’un modèle de BD en réseau.

Figure 6 : Schéma d’un modèle de BD relationnel.

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 6

Figure 7 : Schéma d’un modèle de BD orienté objet.

Etudiant : nom, prénom, date de naissance, n°étudiant.

Exemple : Schéma externe BD (pour le professeur) :

Etudiant _BD : nom, prénom, note1, note2, note_finale

tel que Etudiant _BD résulte de la combinaison de Etudiant et Inscription du SL,

tel que note_finale = (note1 + note2)/2

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 7

- Schéma externe (pour le service de gestion du personnel enseignant):

Professeur : nom, prénom, n°compte_bancaire, nombre_de_cours, liste(nom_cours)

tel que Professeur résulte de la combinaison de Enseignant et Cours du SL, et liste

Figure 8 : SGBD et ses trois schémas.

6. Le modèle Entité-association (ER - Entity Relationship)

Ce modèle se compose de trois concepts élémentaires : l'entité, l'association et les

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 8

* Classe d’Entités (type): Regroupement d’entités de même nature.

Exemple: INFORMATICIENS (AEK, Ibrahim,.....)

6.2 Association : C’est un lien entre deux ou plusieurs Entités.

* Classe d’Associations: C’est un lien entre deux ou plusieurs classes d’entités.

Figure 9 : Classe d’associations, elle est présentée par un Ovale ou un losange.

Parmi les types d'association on peut citer :

1. Statique : Ne change pas dans le temps. Ex : Signer, Avoir

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 9

Figure 10 : Types d’associations dans un modèle Entité-Association (Merier, 2006).

• De 1,1 : une entité de A est reliée à une seule entité de B

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 10

Figure 12 : Exemple de cardinalités d’une association (signer).

- Combien de fois un contrat est signé par un client ?

- Combien de fois un client signe un contrat ?

9. Passage d’un schéma E/A à un Schéma Relationnel

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 11

correctement un modèle entité-association en un schéma de base de données relationnelle

- Règle 1 (ensemble d’entités)

- Règle 2 (ensembles de liens)

- Règle 3 (Liaisons de type complexe-complexe)

- Règle 4 (liaisons de type simple-complexe)

- Règle 5 (liaisons de type simple-simple)

Cours : Administration des Bases de Données (3L) Dr. Mezzoudj Fréha 12

- Règle 6 (généralisation)- Règle de passage d’une structure EST-UN

- Règle 7 (agrégation) - Règle de passage d’une structure MEMBRE-DE

Exemple du passage du modèle E-A au Modèle relationnel (Meier, 2006) :

La figure 16, présente un exemple pour le passage du modèle Entité-Association au modèle