Introduction aux Bases de Données

89 lecture(s)
Maîtrise, Supérieur, Maîtrise (bac+4)
  • cours - matière potentielle : f
  • cours - matière potentielle : i
  • cours - matière : bases de données
1Introduction aux Bases de Données Maîtrise de Sciences Cognitives Année 2003-2004 Jérôme Darmont Bases de données 1 Plan du cours I. Introduction II. Le modèle UML III. Le modèle relationnel Bases de données 2 Plan du cours F I. Introduction II. Le modèle UML III. Le modèle relationnel Bases de données 3 I.1. Historique des bases de données § Jusqu'aux années 60 : organisation classique en fichiers § Fin des années 60 : apparition des premiers SGBD (Systèmes de Gestion de Bases de Données), les systèmes réseaux et hiérarchiques § À partir de 1970 : deuxième génération de SGBD, les systèmes relationnels § Début des
  • multiplicité des associations
  • utilisateur utilisateur
  • bases de données
  • introduction aux bases de données maîtrise
  • fichier fichier
  • saisie
  • prénom
  • prénoms
  • clientes
  • clients
  • client

lire la suite replier

Télécharger la publication

  • Format PDF
Commenter Intégrer Stats et infos du document Retour en haut de page
mafic
publié par

suivre

Vous aimerez aussi

Þ
Þ
Þ
Plan du cours
I. IntroductionIntroduction aux
Bases de Données II. Le modèle UML
Maîtrise de Sciences Cognitives III. Le modèle relationnel
Année 2003-2004
Jérôme Darmont
http://eric.univ-lyon2.fr/~jdarmont/
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 1
Plan du cours I.1. Historique des bases de données
§ Jusqu’aux années 60 : organisation classique en
fichiers
F I. Introduction § Fin des années 60 : apparition des premiers SGBD
(Systèmes de Gestion de Bases de Données), les
II. Le modèle UML systèmes réseaux et hiérarchiques
§ À partir de 1970 : deuxième génération de SGBD, III. Le modèle relationnel les systèmes relationnels
§ Début des années 80 : troisième génération de
SGBD, les systèmes orientés objet
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 2 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 3
I.2. Limites des systèmes à fichiers I.2. Limites des systèmes à fichiers
§ Particularisation de la saisie et des traitements en
Saisie Traitement Fichier
fonction des fichiers un ou plusieurs
programmes par fichierUtilisateur
§ Contrôle en différé des données Fichier
augmentation des délais et du risque d’erreur
Utilisateur
§ Particularisation des fichiers en fonction des État de sortieSaisie Traitement
traitements grande redondance des données
Utilisateur
Organisation en fichiers
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 4 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 5

I.3. Organisation base de données I.3. Organisation base de données
§ Uniformisation de la saisie et standardisation des
traitements (ex. tous les résultats de consultation
Utilisateur
sous forme de listes et de tableaux)Saisie
Base de États de sortie
+ Traitements
Données
Contrôles § Contrôle immédiat de la validité des données
Utilisateur
§ Partage de données entre plusieurs traitements
limitation de la redondance des données
Utilisateur
Organisation base de données
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 6 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 7
I.4. Définitions I.5. Objectifs des SGBD
§ Indépendance physique : un remaniement
§ Base de données (BD) : Collection de de l’organisation physique des données
données cohérentes et structurées n’entraîne pas de modification dans les
programmes d’application (traitements)
§ Système de Gestion de Bases de Données
§ Indépendance logique : un remaniement
(SGBD) : Logiciel(s) assurant structuration,
de l’organisation logique des fichiers (ex.
stockage, maintenance, mise à jour et
nouvelle rubrique) n’entraîne pas de
consultation des données d’une BD modification dans les programmes
d’application non concernés
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 8 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 9
I.5. Objectifs des SGBD I.5. Objectifs des SGBD
§ Manipulation facile des données : un
§ Efficacité des accès aux données : garantie
utilisateur non-informaticien doit pouvoir
d’un bon débit (nombre de transactions
manipuler simplement les données
exécutées par seconde) et d’un bon temps de
(interrogation et mise à jour)
réponse (temps d’attente moyen pour une
§ Administration facile des données : un transaction)
SGBD doit fournir des outils pour décrire
§ Redondance contrôlée des données :
les données, permettre le suivi de ces
diminution du volume de stockage, pas de
structures et autoriser leur évolution (tâche
mise à jour multiple ni d’incohérence
de l’administrateur BD)
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 10 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 11
2I.5. Objectifs des SGBD I.6. Fonctions des SGBD
§ Cohérence des données : ex. L’âge d’une
§ Description des données : Langage de
personne doit être un nombre entier positif. Le
Définition de Données (LDD)SGBD doit veiller à ce que les applications
respectent cette règle (contrainte d’intégrité). § Recherche des données Langage de
§ Partage des données : utilisation simultanée des Manipulation de § Mise à jour des données }données par différentes applications Données (LMD)
§ Transformation des données
§ Sécurité des données : les données doivent être
§ Contrôle de l’intégrité des donnéesprotégées contre les accès non-autorisés ou en cas
de panne § Gestion de transactions et sécurité
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 12 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 13
I.7. Processus de conception d’une base de données Plan du cours
Monde réel
Indépendant d'unSpécifications SGBDde la BDAnalyse I. Introduction
SchémaSchéma
conceptuel Spécifique à un
Conception conceptuel F II. Le modèle UMLSGBD
Schéma
logique III. Le modèle relationnelTransformation en
modèle logique
Schéma
interneConception
physique
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 14 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 15
II.1. Généralités II.2. Classes et attributs
§ UML = Unified Modeling Language
§ Classe : Groupe d’entités du § Ensemble de formalismes graphiques
monde réel ayant les mêmes pour la modélisation orientée objet (analyse)
CLIENTcaractéristiques et le même § Auteurs : J. Rumbaugh, G. Booch, I. Jacobson
comportement (ex. CLIENT) Nom§ Standard de l’OMG (Object Management Group)
Prénomdepuis 1997, standard de fait soutenu par Rational
Software, Microsoft, Hewlett-Packard, Oracle,
§ Attribut : Propriété de la classe
IBM…
(ex. Nom et Prénom du client)
§ Mise en œuvre d’une BD : transformation d’un
diagramme de classes UML en schéma logique
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 16 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 17
3II.2. Classes et attributs II.2. Classes et attributs
§ Type d’attribut :
CLIENT CLIENT
• Entier
Nom : Chaîne Nom : Chaîne
• Réel
Prénom : Chaîne Prénom : Chaîne
• Chaîne de caractères
Date de naissance : Date
• Date
Rue : Chaîne
§ Valeur par défaut (=) Code postal : Entier
Ville : ChaîneCL IENT
Nom : Chaîne = "Nouveau client"
Prénom : Chaîne Exemple de classe avec ses attributs
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 18 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 19
II.3. Instances II.4. Identifiants
Liste des clients
§ Classe : ex. CLIENT
Nom Prénom Date de Naissance Etc.
§ Instances (objets) de la classe CLIENT :
Dupont Albert 01/06/70 ...
les clients West James 03/09/63 ...
Martin Marie 05/06/78 ...Albert Dupont
Durand Gaston 15/11/80 ...
James West
Titgoutte Justine 28/02/75 ...
Marie Martin Dupont Noémie 18/09/57 ...
Gaston Durand Albert 23/05/33 ...
...
Problème : Comment distinguer les Dupont ?
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 20 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 21
II.4. Identifiants II.4. Identifiants
§ Le numéro de client est un identifiant. Un
Solution : Ajouter un attribut Numéro de client identifiant caractérise de façon unique les
instances d’une classe.
Numéro Nom Prénom Date Naissance
§ NB : Dans le paradigme objet, un objet est déjà 1 Dupont Albert 01/06/70
identifié par son OID (Object IDentifier). La 2 West James 03/09/63
finalité de notre utilisation d’UML n’étant pas 3 Martin Marie 05/06/78
OO, nous ajouterons un attribut identifiant.4 Durand Gaston 05/11/80
5 Titgoutte Justine 28/02/75 § Convention graphique : CLIENT
6 Dupont Noémie 18/09/57 NB : Ne pas confondre avec
les attributs de classe UML Numéro : Entier7 Albert 23/05/33 dont c’est la notation usuelle
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 22 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 23
4II.5. Associations et multiplicité II.5. Associations et multiplicité
Association : liaison perçue entre des classes Associations récursives et rôles
ex. Les clients commandent des produits.
§ Association récursive : une même instance de
COMMANDE
CLIENT PRODUIT classe peut jouer plusieurs rôles dans la même
association (ex. employés et supérieurs
hiérarchiques).§ Les classes CLIENT et PRODUIT peuvent être qualifiées EMPLOYE
de participantes à l’association COMMANDE. +est subalterne de
§ Rôle : fonction de chaque § Degré ou arité d’une association = nombre de classes
participantes. En général : associations binaires (de degré classe participante (+). +est supérieur de
2).
H IERARCH IE
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 24 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 25
II.5. Associations et multiplicité II.5. Associations et multiplicité
Multiplicité (ou cardinalité) Association « 1-1 »
ex. Un client donné ne commande qu’un seul § Définition : Indicateur qui montre combien d’instances de
la classe considérée peuvent être liées à une instance de produit. Un produit donné n’est commandé que par
l’autre classe participant à l’association un seul client.
COMMANDE• 1 Un et un seul CLIENT PRODUIT
11 11• 0..1 Zéro ou un
• 0..* ou * Zéro ou plus
• 1..* Un ou plus
Lire : Un client commande multiplicité (1)
• M..N De M à N (M, N entiers) produit(s).
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 26 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 27
II.5. Associations et multiplicité II.5. Associations et multiplicité
Association « 0 ou 1-N »Association « 1-N »
ex. Un client donné commande plusieurs produits. ex. Un client donné commande plusieurs produits. Un
Un produit donné est commandé au maximum par un produit donné n’est commandé que par un seul client.
client, mais peut ne pas être commandé.
COMMANDE
COMMANDECLIENT PRODUIT
CLIENT PRODUIT
1 1..*
0..1 1..*
La multiplicité « un à plusieurs » (1..*) peut aussi
La multiplicité « un à plusieurs » (1..*) peut aussi être
être « zéro à plusieurs » (0..* ou *).
« zéro à plusieurs » (0..* ou *).
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 28 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 29
5II.5. Associations et multiplicité II.5. Associations et multiplicité
Association « M-N » Classe-association : Dans une association
ex. Un client donné commande plusieurs produits. M-N, il est possible de caractériser l’association
Un produit donné est commandé par plusieurs par des attributs (qui doivent appartenir à une classe).
clients.
ex. Une commande est passée à une Date donnée
COMMANDE
CLIENT PRODUIT et concerne une Quantité de produit fixée.
1..* 1..* CLIENT PRODUIT
1..* 1..*
COMMANDELes multiplicités « un à plusieurs » (1..*) peuvent
Dateaussi être « zéro à plusieurs » (0..* ou *). Quantité
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 30 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 31
II.6. Exemple VPC complet II.6. Exemple VPC complet
Spécifications (suite)
Spécifications
§ Les produits sont caractérisés par un numéro de
produit, leur désignation et leur prix unitaire.§ Les clients sont caractérisés par un numéro
§ Chaque produit est fourni par un fournisseur de client, leur nom, prénom, date de
unique (mais un fournisseur peut fournir plusieurs naissance, rue, code postal et ville.
produits).
§ Ils commandent des produits à une date
§ Les fournisseurs sont caractérisés par un numéro
donnée et dans une quantité donnée. de fournisseur et leur raison sociale.
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 32 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 33
II.6. Exemple VPC complet
II.6. Exemple VPC complet
CLIENT
NumCli
PRODUITNomMarche à suivre pour produire un Prénom NumProd
DateNaiss Désidiagramme de classes UML : * *Rue PrixUni
CP
*
Ville
1) Identifier les classes. COMMANDE
FOURNIT
Date
Quantité2) Identifier les associations entre les classes. 1
FOURNISSEUR3) Identifier les attributs de chaque classe et
NumFour
RaisonSocde chaque classe d’association.
4) Évaluer la multiplicité des associations. Diagramme de classes UML de l’exemple VPC
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 34 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 35

Plan du cours III.1. Généralités
§ Le modèle relationnel est un modèle logique
associé aux SGBD relationnels (ex. Oracle, DB2, I. Introduction SQLServer, Access, Paradox, dBase…).
§ Objectifs du modèle relationnel :II. Le modèle E/A
• indépendance physique
• traitement du problème de redondance des donnéesF III. Le modèle relationnel
• LMD non procéduraux (faciles à utiliser)
• devenir un standard
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 36 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 37
III.2. Relations, attributs, n-uplets III.2. Relations, attributs, n-uplets
§ Une relation R est un ensemble d’attributs § Un n-uplet t est un ensemble de valeurs
{A , A , …, A }. t = <V , V , …, V > où V ˛ dom(A ) ou V1 2 n 1 2 n i i i
ex. La relation PRODUIT est l’ensemble est la valeur nulle (NULL).
des attributs {NumProd, Dési, PrixUni} ex. <112, ‘Raquette de tennis’, 300> est un
n-uplet de la relation PRODUIT.
§ Chaque attribut A prend ses valeurs dans i
un domaine dom(A ). § Notation : R (A , A , …, A )i 1 2 n
ex. PrixUni ˛ ]0, 10.000] ex. PRODUIT (NumProd, Dési, PrixUni)
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 38 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 39
III.3. Contraintes d’intégrité III.3. Contraintes d’intégrité
§ Clé primaire : Ensemble d’attributs dont les Notations : clés primaires soulignées, clés
valeurs permettent de distinguer les n-uplets les étrangères en italiques
uns des autres (identifiant). ex. PRODUIT (NumProd, Dési, PrixUni,
ex. NumProd clé primaire de la relation PRODUIT NumFour)
§ Clé étrangère : Attribut qui est clé primaire d’une
§ Contraintes de domaine : les attributs
autre relation.
doivent respecter une condition logique
ex. Connaître le fournisseur de chaque produit
ajout de l’attribut NumFour à la relation PRODUIT ex. PrixUni > 0 ET PrixUni £ 10000
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 40 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 41
7III.4. Traduction UML-Relationnel III.4. Traduction UML-Relationnel
2) Chaque association 1-1 est prise en compte
1) Chaque classe devient une relation. Les
en incluant la clé primaire d’une des relations
attributs de la classe deviennent attributs de la
comme clé étrangère dans l’autre relation.
relation. L’identifiant de la classe devient clé
primaire de la relation.
ex. Si un client peut posséder un compte, on aura :
COMPTE (NumCom, Solde)
ex. CLIENT (NumCli, Nom, Prénom,
CLIENT (NumCli, Nom, Prénom, DateNaiss, Rue,
DateNaiss, Rue, CP, Ville) CP, Ville, NumCom)
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 42 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 43
III.4. Traduction UML-Relationnel III.4. Traduction UML-Relationnel
4) Chaque association M-N est prise en 3) Chaque association 1-N est prise en compte
compte en créant une nouvelle relation dont en incluant la clé primaire de la relation dont
la clé primaire et la concaténation des clés la multiplicité maximale est * comme clé
primaires des relations participantes. Les étrangère dans l’autre relation.
attributs de la classe d’association sont
insérés dans cette nouvelle relation si ex.
nécessaire.PRODUIT (NumProd, Dési, PrixUni, NumFour)
FOURNISSEUR (NumFour, RaisonSoc) ex. COMMANDE (NumCli, NumProd, Date,
Quantité)
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 44 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 45
III.4. Traduction UML-Relationnel III.5. Problème de la redondance
[En dehors des clés étrangères]
Schéma relationnel complet de l’exemple VPC ex. Soit la relation COMMANDE_PRODUIT.
CLIENT (NumCli, Nom, Prénom, DateNaiss, Rue, CP, Ville) NumProd Quantité NumFour Adresse
PRODUIT (NumProd, Dési, PrixUni, NumFour) 101 300 901 Quai des brumes
FOURNISSEUR (NumFour, RaisonSoc) 104 1000 902 Quai Cl. Bernard
112 78 904 Quai des Marans
COMMANDE (NumCli, NumProd, Date, Quantité) 103 250 901 Quai des brumes
Cette relation présente différentes anomalies.
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 46 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 47
8III.5. Problème de la redondance III.6. Normalisation
§ Anomalies de modification : Si l’on souhaite
mettre à jour l’adresse d’un fournisseur, il faut le Objectifs de la normalisation :
faire pour tous les n-uplets concernés.
§ Anomalies d’insertion : Pour ajouter un
§ Suppression des problèmes de mise à jour
fournisseur nouveau, il faut obligatoirement
fournir des valeurs pour NumProd et Quantité. § Minimisation de l’espace de stockage
§ Anomalies de suppression : ex. La suppression (élimination des redondances)
du produit 104 fait perdre toutes les informations
concernant le fournisseur 902.
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 48 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 49
III.6. Normalisation III.6. Normalisation
Les dépendances fonctionnelles (DF)
Propriétés des dépendances fonctionnelles
Soit R (X, Y, Z) une relation où X, Y, et Z sont des
ensembles d’attributs. Z peut être vide. § Réflexivité : Si Y ˝ X alors X fi Y.
§ Augmentation : Si W ˝ Z et X fi Y alorsDéfinition : Y dépend fonctionnellement de X
(X fi Y) si c’est toujours la même valeur de X, Z fi Y, W.
Y qui est associée à X dans la relation R. § Transitivité : Si X fi Y et Y fi Z alors X fi Z.
ex. PRODUIT (NumProd, Dési, PrixUni)
(Règles d’inférence d’Armstrong)
NumProd fi Dési, Dési fi PrixUni
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 50 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 51
III.6. Normalisation III.6. Normalisation
Propriétés des dépendances fonctionnelles Première forme normale (1FN)
Une relation est en 1FN si tout attribut n’est § Pseudo-transitivité : Si X fi Y et Y, Z fi T
pas décomposable.alors X, Z fi T.
ex. Les relations PERSONNE (Nom, § Union : Si X fi Y et X fi Z alors X fi Y, Z.
Prénoms, Age) et DEPARTEMENT (Nom, § Décomposition : Si Z ˝ Y et X fi Y alors
Adresse, Tel) ne sont pas en 1FN si les
X fi Z.
attributs Prénoms et Adresse peuvent être du
NB : La notation X, Y signifie X ¨ Y. type [Jean, Paul] ou [Rue de Marseille, Lyon].
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 52 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 53

III.6. Normalisation III.6. Normalisation
Deuxième forme normale (2FN)Deuxième forme normale (2FN)
Une relation est en 2FN si : ex. La relation COMMANDE_PRODUIT
(NumProd, Quantité, NumFour, Ville) n’est pas en - elle est en 1FN ;
2FN car on a NumProd, NumFour fi Quantité et - tout attribut non clé primaire est dépendant
NumFour fi Ville.de la clé primaire entière.
La décomposition suivante donne deux relations en
ex. La relation CLIENT (NumCli, Nom, 2FN : COMMANDE (NumProd, NumFour,
Prénom, DateNaiss, Rue, CP, Ville) est en Quantité) ; FOURNISSEUR (NumFour, Ville).
2FN.
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 54 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 55
III.6. Normalisation III.6. Normalisation
Troisième forme normale (3FN) Troisième forme normale (3FN)
Anomalies de mise à jour sur la relationUne relation est en 3FN si :
CINEMA : il n’est pas possible d’introduire un - elle est en 2FN ;
nouveau réalisateur sans préciser le film
- il n’existe aucune DF entre deux attributs
correspondant.
non clé primaire.
La décomposition suivante donne deux relations en
ex. La relation CINEMA (NoFilm, NoRéal, Nom) 3FN qui permettent de retrouver (par transitivité)
avec les DF NoFilm fi NoRéal, NoRéal fi Nom et toutes les DF : R1 (NoFilm, NoRéal)
NoFilm fi Nom est en 2FN, mais pas en 3FN. R2 (NoRéal, Nom).
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 56 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 57
III.7. Algèbre relationnelle III.7. Algèbre relationnelle
Opérateurs ensemblistes§ Ensemble d’opérateurs qui s’appliquent aux
relations § Union : T = R ¨ S ou T = UNION (R, S)
§ Résultat : nouvelle relation qui peut à son R et S doivent avoir même schéma.
tour être manipulée ex. R et S sont les relations PRODUIT de
deux sociétés qui fusionnent et veulent
unifier leur catalogue.L’algèbre relationnelle permet d’effectuer
T
des recherches dans les relations. ¨Notation graphique :
R S
Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 58 Bases de données http://eric.univ-lyon2.fr/~jdarmont/ 59
10

Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.

 
Lisez à volonté, où que vous soyez
1 mois offert, Plus d'infos