IT3 BD 2022 2023 Chap 1
IT3 BD 2022 2023 Chap 1
IT3 BD 2022 2023 Chap 1
COUR DE BASES DE
DONNEES (vol3.4)
PAR : A HMED S EREME
D I PLÔMÉ D ’ ET UDES S U PÉR IEURES S PÉC I A LISÉ EN
CO N C EPT ION D E SY S T ÈM ES D ’ I NFORMATION
E M A IL s e re m e ah@ ya hoo.fr TEL 60 53 93 62
COPYRIGHT : SEREMEAH@YAHOO.FR 0
PLAN
PRE-REQUIS
CONCEPTS D’ADMINISTRATION DES BD
(Architecture interne d’Oracle)
MISE EN ŒUVRE DE L’ADMINISTRATION DES BD
SÉCURITÉ DES DONNÉES
COPYRIGHT : SEREMEAH@YAHOO.FR 1
CHAPITRE N° 1
COPYRIGHT : SEREMEAH@YAHOO.FR 2
RP : I. Définitions
S. I.
COPYRIGHT : SEREMEAH@YAHOO.FR
Ensemble des ressources matérielles, logiciels, et
humaines d’une organisation, mises en commun
pour collecter, stocker, traiter et diffuser les
informations.
3
S. I.
RP : I. Définitions
COPYRIGHT : SEREMEAH@YAHOO.FR
RP : I. Définitions
• Base de données
Une base de données (son abréviation est BD, en anglais DB, database) est une
COPYRIGHT : SEREMEAH@YAHOO.FR
entité dans laquelle il est possible de stocker des données de façon structurée
et avec le moins de redondance possible.
copyright : seremeah@yahoo.fr
5
RP : I. Définitions
COPYRIGHT : SEREMEAH@YAHOO.FR
• D’éviter les redondances et les incohérences qu’entrainerait
fatalement une approche où les données seraient réparties dans
différents fichiers sans connexions entre eux;
• Offrir des langages compréhensibles de haut niveau pour la définition
et la manipulation des données,
• Permettre le partage des données entre plusieurs utilisateurs,
• De contrôler l’intégrité, la disponibilité, la non répudiation, et la
confidentialité des données
copyright : seremeah@yahoo.fr
6
RP : I. Définitions
Model ANSI-SPARK
COPYRIGHT : SEREMEAH@YAHOO.FR
7
RP : I. Définitions
Architecture de BD : Monoposte / Client-serveur / Repartie
COPYRIGHT : SEREMEAH@YAHOO.FR
8
RP : I. Définitions
Architecture de BD : MVC
COPYRIGHT : SEREMEAH@YAHOO.FR
9
RP : I. Définitions
• Transaction
COPYRIGHT : SEREMEAH@YAHOO.FR
• Contrôle de DB
Intégrité
Partage et Concurrence
10
RP : I. Définitions
• Contrôle de DB
Intégrité
Partage et Concurrence
Disponibilité
COPYRIGHT : SEREMEAH@YAHOO.FR
Confidentialité
11
MODEL RELATIONNEL
David Maier
COPYRIGHT : SEREMEAH@YAHOO.FR 13
RP :Schémas relationnel
Définition
Un des grands avantages du modèle relationnel est sa très grande simplicité.
Il n’existe en effet qu’une seule structure, la relation. Une relation peut
simplement être représentée sous foRPe de table, comme sur la figure ci
dessous.
COPYRIGHT : SEREMEAH@YAHOO.FR
Titre Année Genre
Alien 1979 Science-Fiction
Volte – face 1997 Thriller
Yaba 1985 Aventure
Les enquêteurs 2010 Policier
COPYRIGHT : SEREMEAH@YAHOO.FR
d’enregistrements, etc.
En d’autres teRPes le système de types est figé et fourni par le système.
• Attribut
Les attributs nomment les colonnes d’une relation. Il servent à la fois à
indiquer le contenu de cette colonne, et à la référencer quand on effectue des
opérations. Un attribut est toujours associé à un domaine.
Le nom d’un attribut peut apparaître dans plusieurs schémas de relations.
15
RP :Schémas relationnel
Shéma de relation
Un schéma de relation est simplement un nom suivi de la liste des attributs, chaque
attribut étant associé à son domaine. La syntaxe est donc :
COPYRIGHT : SEREMEAH@YAHOO.FR
L’arité d’une relation est le nombre de ses attributs.
On peut trouver dans un schéma de relation plusieurs fois le même domaine, mais
une seule fois un nom d’attribut. Le domaine peut être omis en phase de définition.
• Une instance
16
RP :Schémas relationnel
N-uplets
Un n-uplet d’une relation 𝑅(𝐷1, . . . ,𝐷𝑛) est une liste de n valeurs (𝑣1, . . . , 𝑣𝑛) où
chaque 𝑣𝑖 est la valeur d’un attribut 𝐴𝑖 de type 𝐷𝑖.
Exemple : (’Yaba’, 1985, ’dramaturge’)
COPYRIGHT : SEREMEAH@YAHOO.FR
Un n-uplet est représenté par une ligne dans une relation sous forme de table. En
principe, on connaît les valeurs de tous les attributs du n-uplet.
Notion de Dépendance fonctionnelle :
Considérons deux propriétés P1 et P2. La création d’une relation E regroupant ces deux
seules propriétés n’est envisageable que si l’une des deux conditions suivantes est
satisfaite :
à toute valeur de la propriété P1 doit correspondre au plus une valeur
de la propriété P2. Ce fait traduit l’existence d’une dépendance
fonctionnelle mono-valuée entre P1 et P2 notée :
P1 P2. On dit encore que P1 détermine P2.
P1 est alors rubrique identifiante de l’entité E. La représentation
graphique de la relation E a la forme suivante :
ou à toute valeur de la rubrique P2 doit correspondre au plus une
valeur de la rubrique P1. P2 est alors en dépendance fonctionnelle
17
avec P1 et la relation E doit être représentée ainsi :
RP :Schémas relationnel
Les Contraintes d’intégrité
COPYRIGHT : SEREMEAH@YAHOO.FR 18
RP :SQL
De 1974 à 1986,
COPYRIGHT : SEREMEAH@YAHOO.FR 19
RP :SQL
Les Catégories du langage SQL
LDD Langage de Définition des Données
• Opérations sur les tables = structures
• create, alter, rename, drop
LMD Langage de Manipulation des Données
• Opérations sur les lignes = données/valeurs
• insert, update, delete
LID Langage d’Interrogation des Données
• Requêtage à partir de tables et de requêtes select
LCD Langage de Contrôle sur les Données
• Gestion des accès multiutilisateur aux données
• grant, revoke
LCT Langage de Contrôle des Transactions
• Validation et annulation des transactions
• commit, rollback
COPYRIGHT : SEREMEAH@YAHOO.FR 20
RP :SQL
Vous avez monté votre boutique de vente de recharges (unités) téléphonique et vous désirez
suivre les ventes qui sont effectuées par les agents de votre boutique.
L’agent, après s’être identifiée sur l’application à l’aide de son nom et de son mot de passe, peut
procéder aux opérations de recharge de tous types (Carte, SapSap, Cash, Money, SapSap...).
Chaque recharge s’effectuant à un moment précis.
Le client se présente à l’accueil, un numéro automatique lui ait donnée par le système, son
propre numéro de téléphone ne sera enregistré qui s’il le désire pour une gestion ultérieure de
sa fidélité. Il fournit le nom de l’opérateur de téléphonie dont il veut acheter les unités, le
montant de la recharge qu’il souhaite et le numéro de téléphone qui doit être rechargé.
L’agent vendeur(se), encaisse d’abord le montant à percevoir avant d’effectuer l’opération de
recharge, chacune des opérations s’effectuent distinctement à une date et une heure précise.
Le montant à recharger doit correspondre au montant encaissé des mains du client par l’agent
encaisseur. Pour ce faire l’enregistrement de chaque recharge devra être justifié par la
référence de l’encaissement idoine.
1) Elaborez le model conceptuel des données y afférent,
Déduisez le schéma relationnel de données correspondant.
COPYRIGHT : SEREMEAH@YAHOO.FR 21
FIN DU
CHAPITRE