Cours “Bases de données” 3° année (MISI) Antoine Cornuéjols |
• 9 (10) séances de 3h (Cours + TD/TP) • Polycopié • Transparents Disponibles sur : Attention : remises à jour fréquentes 2 | ||||||||||||||||||
• Sources bibliographiques Andreas MEIER : “Introduction pratique aux bases de données relationnelles”, Springer-Verlag, 2006 Ramez ELMASRI & Shamkant NAVATHE : “Conception et architecture des bases de données”, Pearson Education, 2004 3 |
4 |
Caractéristiques Des données permanentes (livres) Un problème d’indexage Précis Fiable Supportant des mises à jour 5 |
• • vs. Ensemble de fichiers -détail de l’implantation ph Lourdeur d’accès : connaîtrysiquee le • Lourdeur d’accès aux données - Manque de sécurité : N’importe qui peut modifier le fichier. Pas de • Manque de sécurité contrôle de cohérence. - Pas de contrôle de concurrence • Pas de contrôle de concurrence entre utilisateurs. 6 | |||||||||||||||||||||||||||||||||||||||||||||||
7 |
8 |
9 |
Complexité (diversité des techniques mises en oeuvre) : Modèles de données Langages de requêtes Techniques de stockage Organisation des fichiers Architecture Optimisation des requêtes Concurrence d’accès et reprise sur panne 10 |
Indépendance physique des programmes et des données : Pouvoir modifier les schémas internes sans modifier les schémas conceptuels et externes Indépendance logique des programmes et des données : Pouvoir modifier les schémas externes sans modifier les schémas conceptuels Indépendance entre les différents utilisateurs Manipulation des données par des langages non procéduraux Données facilement manipulables par les utilisateurs (interactifs ou programmeurs) Administration facile des données Outils pour définir et modifier les définition de données 13 |
Efficacité d’accès aux données : Optimisation : temps de réponse, débit, ... Optimisation des opérations d’E/S Redondance contrôlée des données : Dans les BD réparties : redondance nécessaire, mais contrôlée Cohérence des données Satisfaction de contraintes d’intégrité Partage des données Permettre les accès concurrents Sécurité des données Outils pour définir et modifier les définition de données Protection en cas de panne (du SGBD, de la machine, ...) Assurer l’atomicité des transactions et l’intégrité des données 14 | |||||||||||||||||||||||||||||||||||||||||||||
15 |
1. Persistance 2. Gestion du disque 3. Partage des données 4. Fiabilité des données 5. Sécurité des données 7. Langage de description, d’interrogation et de traitement des données 16 |
1. Persistance Données stockées sur disque 2. Gestion du disque Techniques spécifiques pour de bonnes performances Index, hash-coding Regroupement des données sur disque Optimisation des requêtes Cache-mémoire 17 |
3. Partage des données Chaque utilisateur doit avoir l’illusion d’être seul Notion de transaction (begin, abort, commit) Cohérence des mises à jour effectuées par un utilisateur Cohérence collective : sérialisabilité 4. Fiabilité des données Vérification de contraintes d’intégrité Atomiticité des transactions : transaction complètement effectuée ou pas du tout Résistance aux pannes Si panne mémoire : restauration automatique de la base intégrant les dernières transactions validées avant la panne Si panne disque : restauration d’une sauvegarde et déroulement du journal archivé Mise en place d’un mécanisme de réplication synchrone de la base dans une base miroir : mirroring 18 | |||||||||||||||||||
5. Sécurité des données Tous les utilisateurs ne peuvent pas tout faire sur toutes les données Notion de groupes d’utilisateurs Granularité des autorisations : base de données, table, colonne, n-uplet, ... Possibilité d’accorder ou de supprimer des droits 6. Indépendance logique / physique Organisation physique de la BD transparente pour le développeur d’application On doit pouvoir changer la répartition des données sur le disque (ex : un regroupement ou la pose d’un index) sans changer le code de l’application manipulant les données 19 |
7. Langage de requête Les requêtes doivent être : Simples Déclaratives Optimisées avant leur exécution État de l’art : SQL (Structured Query Language) : mélange d’algèbre relationnelle et de calcul relationnel QBE (Query By Example) : s’appuie sur le calcul relationnel, mais permet de formuler des requêtes et d’effectuer des manipulations de données à l’aide de représentations graphiques OQL (Object Query Language) : conçu pour s’intégrer avec des programmes écrits en langage objet (C++, Smalltalk, Java) XQUERY (XML Query language) 20 |
Trois types d’intervenants : Utilisateur naïf Concepteur et programmeur d’applications Utilisateur expert (administrateur de la base) 23 |
Le modèle conceptuel: La description du système d’information Le modèle logique: Interface avec le SGBD Le modèle physique: Les fichiers 24 |
25 |
26 | |||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Quatre opérations classiques (LMD)
Faciles à exprimer Efficacité Fiabilité 29 |
Optimisation d’une requête s’appuie sur l’organisation physique des données Fichiers séquentiels Index (denses, secondaires, arbres B) Regroupement des données par hachage Optimiseur dans le SGBD Choisit le meilleur séquencement des opérations 30 | |||||||||||||
| ||||||||||||||
Un SGBD est unsystème complexe! Spécificités d’un SGBD Trois niveaux d’abstraction Fiabilité Concurrence Stockage massif sur disque Prix à payer Interfaces entre niveaux Journalisation Verrouillage Techniques spécialisées d’accès aux données sur disque 35 |
Un SGBD est unsystème difficile à bien utiliser! Méthodes dedéveloppement et maintenance Analyse des besoins de l’application Conception du schéma conceptuel Conception du schéma interne Réglage (tuning) des applications 36 |
|