Cours gratuits » Cours informatique » Cours bases de données » Cours Introduction aux BD relationnelles

Cours Introduction aux BD relationnelles

Problème à signaler:

Télécharger



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Cours Introduction aux BD relationnelles

...

III. Bases de données

BD : Collection de représentation de la réalité sous forme de données inter-reliées :

  • cohérente, structurée
  • avec une redondance calculée
  • centralisée
  1. Les précurseurs des BD : les systèmes de fichiers

Dans une entreprise, chaque service avait ses

propres fichiers, développés en fonction de ses besoins

 informations communes, sans que cela soit géré.

 redondance non gérée.

  1. Redondance

Problèmes :

  • volume de données important (moins grave actuellement : mémoires de masse importantes)
  • temps de saisie et de mise à jour : par exemple, si on dispose de 3 fichiers clients (factures, BL, étiquettes), la saisie d'un client doit être effectuée trois fois, avec des risques d'erreur (fautes de frappe entre deux saisies)
  • difficultés de tenir à jour les informations pour "coller" à la réalité

 manque de cohérence.

  1. Cohérence

Etre juste par rapport à une certaine réalité, c-à-d intégrité des données.

La réalité doit être fixée sous forme de règles ou contraintes d'intégrité.

La BD est cohérente si elle respecte les contraintes d'intégrité énoncées (dépendantes des applications).

Les règles définissant les liens entre les données de la base décrivent la réalité.

Exemples de contraintes d'intégrité : BD clients / fournisseurs / produits, avec commandes clients et fournisseurs :

  • couleur autorisée pour un produit {blanc, bleu, noir }
  • chaque client, chaque fournisseur, chaque produit doit être identifié de manière unique dans toute la base ( numérotation explicite)
  • pour la gestion des commandes, les clients et produits intervenant dans la transaction doivent exister
  • tout client sauvegardé dans la base a passé au moins une commande

Les contraintes sont posées au départ :

  • elles définissent la structure de la base
  • elles doivent être vérifiées en permanence
  1. Centralisation

La BD doit satisfaire une grande variété de demandes de renseignements exprimée par de nombreux utilisateurs.

Les utilisateurs ont des exigences de réponse qui doivent être compatibles avec leurs conditions de travail.

 BD : entité commune, centrale, à laquelle accèdent tous les utilisateurs.

L'utilisateur doit pouvoir travailler comme il l'a toujours fait, avec sa propre vision de la BD.

  1. Système de Gestion des Bases de Données (SGBD)

Un SGBD est une ensemble de logiciels permettant aux utilisateurs de manipuler efficacement des données dans une grande masse d'information partagée avec d'autres utilisateurs.

Différence avec les systèmes de fichiers : description des données séparée de leur utilisation (description : définition des types par des noms, des formats, des caractéristiques ; utilisation : interrogations, mises à jour).

Le système est en fait un composant de plus bas niveau, englobé dans le SGBD.

  1. Historique

4 générations. Le début se situe vers 1965 avec le programme Apollo d'IBM.

1) 1ère génération : fin des années 60

Exemple : TOTAL, IDMS.

Modèles réseau ou hiérarchique, organisés autour de types d'articles constituant les nœuds d'un graphe, les arcs étant des types de pointeurs.

  1. a) Modèles hiérarchiques

Les données sont représentées sous forme d’une structure arborescente d’enregistrements. Cette structure est conçue avec des pointeurs et détermine les chemins d’accès aux données.

Avantages :

  • structure de donnée facile à comprendre
  • chemins d'accès fixes : peu de commandes, simplicité des commandes

Inconvénients :

  • organisation non naturelle
  • contrôle de cohérence délicat
  • coût élevé de la recherche, dû à l'unicité du chemin d'accès
  1. b) Modèles réseau

La structure peut être visualisée sous forme d’un graphe quelconque. Comme pour le modèle hiérarchique, la structure est conçue avec des pointeurs et détermine le chemin d’accès aux données.

Avantages :

  • moins restrictif
  • représentation naturelle des liaisons
  • moins de redondances

Inconvénients :

  • pas d'indépendance vis-à-vis des stratégies d'accès

Dans ces deux modèles, les programmes ne sont pas indépendants de la structure logique de la base et du chemin d’accès aux données : ils doivent décrire comment retrouver les données (on parle de navigation dans la base) et si, par exemple, on enlève un index, tous les programmes qui l’utilisaient doivent être réécrits. De plus, le langage de travail est complexe.

2) 2ème génération : fin des années 70

Exemple : ORACLE, SYBASE, INFORMIX, DBASE, SQL SERVER.

Modèle relationnel.

Point de départ : théorie des ensembles en mathématiques.

Les données sont présentées aux utilisateurs sous forme de relations entre domaines de valeurs, simplement représentées par des tables, et plus les pointeurs qui figeaient la structure de la base.

Les recherches et mises à jour sont effectuées à l'aide d'un langage non procédural standardisé :

SQL (Structured Query Language), permettant de traduire les requêtes du langage courant.

Les SGBD de la 2ème génération représentent l'essentiel du marché actuel.

Avantages :

  • simplicité de la structure
  • indépendance totale entre niveaux logiques et physiques

Inconvénients :

  • langage pas adapté aux données complexes (les images par exemple)
  • sémantique pauvre
  • pas de point de vue opérationnel des données
  • déductions limitées

L’inventeur du modèle relationnel est Codd (IBM). Il a énoncé 12 règles que doivent vérifier les SGBD pour etre relationnels (actuellement aucun SGBD ne les respecte toutes, mais certains tentent de s’approcher de cette « perfection » relationnelle) :

  • règle 1 : toutes les informations sur les données sont représentées au niveau logique et non physique (pas besoin d’informations sur la façon dont sont enregistrées physiquement les données)
  • règle 2 : les données sont accessibles uniquement par la combinaison du nom de la table, de la clé primaire et du nom de la colonne (pas de chemin à donner)
  • règle 3 : une valeur spéciale doit représenter l’absence de valeur (NULL)
  • règle 4 : la description de la base de données doit être accessible comme les données ordinaires (un dictionnaire des données est enregistré dans la base)
  • règle 5 : un langage doit permettre de définir les données, définir des vues (visions particulières de la base, enregistrées comme des relations), manipuler les données, définir des contraintes d’intégrité, des autorisations de gérer des transactions
  • règle 6 : on peut faire des mises à jour par les vues lorsque c’est logiquement possible
  • règle 7 : le langage doit comporter des ordres effectuant l’insertion, la mise à jour et la suppression des données (un seul ordre pour effectuer chacune de ces fonctions)
  • règle 8 : indépendance des programmes vis-à-vis de l’implantation physique des données
  • règle 9 : indépendance des programmes vis-à-vis de l’implantation logique des données (si les informations manipulées par les programmes n’ont pas été modifiées ou supprimées
  • règle 10 : les contraintes d’intégrité doivent pouvoir être définies dans le langage relationnel et enregistrées dans le dictionnaire des données
  • règle 11 : indépendance vis-à-vis de la répartition des données sur divers sites
  • règle 12 : on ne peut jamais contourner les contraintes (d’intégrité ou de sécurité) imposées par le langage du SGBD en utilisant un langage de plus bas niveau (par exemple le C)

3) 3ème génération : fin des années 80

Les structures de données complexes sont éclatées par le modèle relationnel et la reconstruction de la structure nécessite des opérations (jointures) coûteuses en performances.

 Extensions objet des systèmes relationnels.

Exemple : ORACLE 8, DB2 Universal Database, Informix Universal Server.

Structuration conjointe des données et des programmes en types : les données sont enregistrées avec les procédures qui permettent de les manipuler.

Possibilités de définir des sous-types par héritage.

Règles actives  répercussions des MAJ d'un objet sur d'autres objets dépendants.

4) 4ème génération : années 90 et actuellement

Plus extension de la 3ème génération que vraiment une nouvelle génération.

Permet de mieux supporter Internet et le Web, les informations mal structurées, les objets multimédia, l'aide à la décision et l'extraction de connaissances.

Mais cela reste un système relationnel  domaine (actif) de recherche Intelligence Artificielle (IA).

Il n’existe pas encore de norme, et ces SGBD sont encore utilisés pour des usages bien spécifiques : le manque de support et d’uniformité dans les implantations des différents SGBD du marché conduisent à les utiliser avec prudence.

  1. Objectifs des SGBD

Un SGBD est un ensemble de logiciels qui fournit un environnement pour :

  • décrire des données
  • mémoriser des données
  • manipuler des données (ajouter, modifier, supprimer)
  • traiter des données en les restituant éventuellement sous une forme différente de leur saisie (selectionner, trier, calculer…)
  • définir des contraintes d’intégrité sur les données (contraintes de domaines, d’existence…)
  • définir des protections d’accès (mots de passe, autorisations…)
  • résoudre les problèmes d’accès multiples aux données (blocages, interblocages…)
  • prévoir des procédures de reprise en cas d’accident (sauvegardes, journaux…)

Un SGBD doit en outre permettre d’écrire des applications indépendantes de l’implantation physique des données (codage, ordre dans lequel les données sont enregistrées…).

Objectif : assurer

  • la sécurité
  • la confidentialité
  • l'intégrité
  • de bonnes performances

des données alors que plusieurs utilisateurs peuvent accéder simultanément à la BD.

1) Sécurité

Une perte d'informations peut s'avérer fatale  la sécurité est primordiale.

  1. a) Sécurité de fonctionnement

Suite à un incident matériel ou logiciel, il convient de :

  • redémarrer le système
  • remettre la BD en état cohérent

 archivage : copie de sauvegarde sur un autre support (CD, DAT, disquette...).

 journalisation : un journal mémorise toutes les transactions effectuées sur la BD. En cas de panne de courant, le système lit le journal.

Durant la transaction (ensemble de modifications de la base qui forme un tout indivisible), des opérations sont effectuées sur la BD  BD non cohérente temporairement.

 risque, si un autre utilisateur accède à la BD à ce moment.

La transaction doit être terminée ou non exécutée.

Exemple de transaction : transfert d’une somme d’argent entre deux comptes d’un client d’une banque. Elle comporte deux ordres : débiter le premier compte, puis créditer le second. Si un problème empêche le crédit, le débit doit être annulé.

Une transaction est terminée :

  • soit par une validation qui entérine les modifications
  • soit par une annulation qui remet la base dans son état initial

Deux transactions ne peuvent se chevaucher.

L’utilisateur peut à tout moment valider la transaction en cours (COMMIT en SQL)  les modifications deviennent alors définitives et visibles à l’ensemble des utilisateurs.

Tant que la transaction n’est pas validée, les modifications qu’elle contient n’apparaissent qu’à l’utilisateur qui l’execute. Tous les autres utilisateurs voient la base dans l’état où elle était avant le début de la transaction.

L’utilsateur peut annuler la transaction en cours (ROLLBACK en SQL)  les modifications effectuées depuis le début de la transaction sont annulées.

  1. b) Gestion de la concurrence d'accès

Lorsque plusieurs personnes travaillent simultanément sur la même donnée, il faut éviter que le travail de l'une écrase celui de l'autre.

Exemple : éditer un même fichier partagé.

Mises à jour perdues. Par exemple,:2 personnes veulent modifier une quantité q en stock :

Transaction :

  • lire (q)
  • modifier (q) (valeur stockée dans un buffer)
  • écrire (q) (dans la BD)

Ici, le travail de l'utilisateur 1 est écrasé.

 Mécanisme des verrous :

  • interdit l'accès à une donnée (table ou partie de table) tant que celle-ci est utilisée
  • verrou pendant un temps minimal  généralement transparent (tous les utilisateurs ont l'impression de travailler seuls sur la donnée)

Mais cela peut conduire à un interblocage de processus (deadlock) :

Exemple :

Ce type d’interblocage ne peut pas arriver si tous les utilisateurs bloquent les tables dans le même ordre.

Lecture inconsistante ou lecture impropre. Une transaction T2 lit une valeur donnée par une autre transaction T1. Ensuite la transaction T1 annule son affection de V  la valeur lue par T2 est fausse :

Ce cas ne peut pas arriver si les modifications effectuées par une transaction ne sont visibles par les autres qu’après validation (COMMIT) de la transaction.

Lecture non répétitive, ou non reproductible, ou incohérente. Une transaction lit deux fois une même valeur et ne trouve pas la même valeur les deux fois.

Pour éviter ce cas, T1 devra bloquer les données qu’il veut modifier suffisamment longtemps pour empêcher les autres transactions de les modifier.

Lignes fantômes. Une sélection de lignes récupère des lignes qui sont modifiées par une autre transaction et ne vérifient plus le critère de la sélection. La même sélection lancée une seconde fois ne retrouve donc plus ces lignes.

Là encore la solution est le blocage explicite des lignes en question.

Traitement des accès concurrents par le SGBD. Les SGBD gèrent automatiquement les accès concurrents de plusieurs utilisateurs sur les mêmes lignes des tables.

Dans Oracle, une donnée est en cours de modification  les autres utilisateur ::

  • peuvent lire la donnée telles qu’elles étaient avant cette modification (jamais de délai d’attente pour la lecture)
  • sont bloqués automatiquement s’ils veulent modifier la donnée

Oracle assure une « lecture consistante » des données pendant l’exécution d’un ordre SQL : par exemple, un ordre SELECT ou UPDATE va travailler sur les lignes telles qu’elles étaient au moment du début de l’exécution de la commande, même si entre-temps un autre utilisateur a confirmé (COMMIT) des modifications sur certaines de ces lignes.

2) Confidentialité

  1. a) Contrôle de l’accès à la base

Gestion des droits d'accès des différents utilisateurs (mots de passe).

Gestion des « privilèges » : les utilisateurs n’ont pas tous les mêmes droits.

  1. b) Contrôle de l’accès aux données

Les données d’une table appartiennent au créateur de la table, qui peut donner aux autres utilisateurs des droits sur cette table (par exemple consulter, ajouter…)

Les « vues » fournissent également des restrictions d’accès aux données. Une vue est une table virtuelle constituée de colonnes qui appartiennent à des tables réelles. On peut donner le droit d’accès à une vue sans donner le droit d’accès aux tables sous-jacentes.

On peut aussi donner des droits sur une partie seulement des lignes ou des colonnes d’une table.

3) Intégrité

Les opérations doivent respecter les contraintes d'intégrité implicitement :

  • définition de la clé primaire d’une table
  • clés étrangères dont les valeurs doivent exister dans une autre table
  • unicité des valeurs d’une rubrique
  • fourchette pour les valeurs acceptables

Les commandes qui ne respectent pas ces contraintes sont automatiquement annulées (toute la commande est annulée si une seule des lignes ne respecte pas une contrainte d’intégrité).

Exemple : BD client / fournisseur / produit

  • interdire l'insertion d'un produit dont le numéro figure déjà dans la base
  • interdire l'insertion d'une nouvelle commande avec un client inconnu

 il faut d'abord insérer le client, puis la commande

  • la suppression d'une commande peut provoquer la suppression d'un client (s'il n'avait qu'une commande)

4) Performances

Les langages d’utilisation des SGBD relationnels ne font pas référence au cheminement à suivre pour accéder aux données  risque de performances dégradées (données non contiguës, isolées…).

Solutions :

  • index sur une rubrique  accélérer l’accès aux lignes qui ont une certaine valeur ou accélérer le tri des lignes dans l’ordre de rangement de l’index
  • clusters : rangement physique de plusieurs tables dans un même espace accélérer les jointures sur ces tables en partageant des colonnes entre plusieurs tables
  1. Architecture des SGBD

3 schémas (norme ANSI/SPARC) :

  • conceptuel
  • externe
  • interne

Ce cours concerne particulièrement le niveau conceptuel.

 3 types d’utilisateurs :

  • administrateur
  • programmeur
  • utilisateur final

2 langages :

  • LMD
  • LDD

1) Schémas

  1. a) Schéma conceptuel

Niveau central, vision globale de la base. Un seul schéma conceptuel. Description des données et des CI qui y sont liées.

Différentes approches :

  • liaison : schémas externes / schéma conceptuel
  • ou schéma externe = dérivation du schéma conceptuel
  • ou schéma conceptuel = synthèse des schémas externes

 deux utilisateurs peuvent appeler une même variable sous deux noms différents, ou bien appeler deux variables différentes sous un même nom.

Exemple :

BUVEUR(Nom, Prénom, Adresse)  (objet)

VIN(Cru, Millésime, Quantité)  (objet)

ABUS(Buveur, Vin, Date, Quantité)  (association)

  1. b) Schémas externes

Vision des données d'un utilisateur ou d'un groupe d'utilisateurs  description d'une partie Seulement des données  vision parcellaire, incomplète.

 Sécurité et confidentialité des données.

Il existe autant de visions externes que d'utilisateurs.

Mais les visions des différents utilisateurs vont se recouper (informations communes).

Exemple :

Schéma externe 1 :

buveur-de-vin :

Schéma externe 2 :

identité-buveur :    vins-consommés :

  1. c) Schéma interne

Description de la manière dont les données sont stockées sur les organes physiques.

Dans un SGBD, l'organisation physique des données est effectuée par le système d'exploitation  ignoré par l'utilisateur.

Il peut y avoir plusieurs modèles physiques pour un même modèle logique.

Exemple :

  1. d) Indépendances

Indépendance logique si le schéma conceptuel peut être modifié ou enrichi sans que cela affecte les schémas externes des utilisateurs et leurs programmes d'application.

Indépendance physique si on peut modifier le schéma interne sans affecter le schéma conceptuel. Cela permet de ne pas être lié au matériel ou au système d’exploitation (seul le niveau interne en dépend).

2) Utilisateurs

  1. a) Administrateur

Personne(s) responsable(s) de tout ce qui touche à la BD :

  • bon fonctionnement
  • création de la BD
  • déclaration d'un utilisateur
  • droits d'accès
  • modification des schémas externes
  • modification des chemins d'accès aux données
  • maintien des performances d’accès aux données
  • sauvegardes et reprises après pannes
  • ...
  1. b) Programmeur

Développeur d’applications utilisant la BD. Il a le droit de créer de nouvelles tables et les structures associées (vues, index, clusters…). Il définit les droits qui seront accordés aux utilisateurs des applications qu’il développe.

  1. c) Utilisateur final

N’a accès qu’aux données qui lui sont utiles. Il a certains droits accordés par l’administrateur : consultation, ajout, modification ; suppression. Généralement il n’a pas le droit de création, de modification ou de suppression de tables.

3) Langages

  1. a) Langage de Définition des Données (LDD)

Utilisé par l'administrateur de la base, le LDD permet de définir :

  • le schéma conceptuel et les schémas externes
  • les données, liens, contraintes d'intégrité

Utilisé lors de la conception de la base et la modification des schémas.

  1. b) Langage de Manipulation des Données (LMD)

Interrogation et MAJ de la BD.

Les instructions peuvent être :

  • interactives (outils en ligne, interfaces avec des outils de bureautique ou avec le web)
  • insérées dans un langage de programmation = langage hôte de 3ème génération (C  Pro*C) ou de 4ème génération (langages conçus spécifiquement pour développer des applications qui utilisent des BD)
  • sous forme de menus (forms...), de formulaires, d’états imprimés…
  1. Exemple de fonctionnement d'un SGBD

Le programme d'application, accédant à la BD via le schéma externe B, demande la lecture d'une donnée de la base.

  1. Demande transmise au SGBD.
  2. le SGBD analyse la demande :
  • consultation du schéma externe pour vérifier les droits d'accès à la donnée ; lecture des caractéristiques de la donnée à partir du schéma externe B ;
  • consultation du schéma conceptuel  type logique de la donnée à extraire ;
  • consultation du schéma physique  enregistrement physique à lire.
  1. Le SGBD transfère l'ordre de lecture au Système d'Exploitation (SE).
  2. Le SE reçoit l'ordre, l'analyse, puis lance un ordre de lecture au contrôleur des unités périphériques.
  3. Les données sont placées dans un tampon.
  4. Le SGBD sélectionne, dans le tampon, les données effectivement demandées et les transmet au tampon du programme d'application.
  5. Le SGBD peut prévenir le programme d'application en cas de déroulement anormal.
  6. Le programme d'application dispose de la donnée demandée.
  7. Résistance aux pannes

1) Sauvegardes

 Réparer les dommages créés par des pannes :

  • le SGBD enregistre automatiquement toutes les instructions exécutées sur la base dans des fichiers de « log »  fichiers utilisés lors du redémarrage après la panne
  • l’administrateur sauvegarde régulièrement les BD et les fichiers utilisés par le SGBD et enregistre les fichiers de log sur des médias stables (bandes, CD)  ralentissement du système mais plus grande fiabilité en cas de panne

191