Données BDD

Identification

Infoforall

23 - Les Bases de Données


En 1er, nous avons vu qu'il était possible de stocker les données dans un fichier CSV situé dans une mémoire de masse, fichier qui a deux énormes avantages :

  1. C'est un simple fichier-texte
  2. On peut l'ouvrir, le modifier et l'enregistrer avec un simple éditeur de texte mais également avec un tableur

A l'aide d'un langage de programmation, les données de ce fichier peuvent alors être placées en mémoire vive dans un tableau de n-uplets, de façon à obtenir une Collection ou Table contenant des enregistrements. Exemple pour le premier enregistrement : (1, 'Bulbasaur', 'Grass', 318)

De façon schématique,

  • Chaque ligne de la table est l'un des enregistrements ou objets.
  • Chaque colonne de la table comporte les valeurs associées à un même descripteur ou attribut.
  • Collection / Table Attributs ou Descripteurs
    Pokemon n° Nom Type Points de vie
    Enregistrement d'index 0 1 Bulbasaur Grass 318
    Enregistrement d'index 1 2 Ivysaur Grass 405
    Enregistrement d'index 2 3 Venusaur Grass 525
    Enregistrement d'index 3 3 VenusaurMega Venusaur Grass 625

Nous avons vu en 1er comment

  • Implémenter chaque enregistrement dans un tuple ou un dictionnaire
  • Implémenter la table dans un tableau de tuple ou un tableau de dictionnaires.

Nous allons voir aujourd'hui qu'on peut aussi les stocker dans une base de données.

Documents de cours : open document ou pdf

Vocabulaire

Vous avez vu qu'il existe plusieurs mots permettant de faire référence à (presque) la même idée.

  • Ensemble des données : Collection - Table - Relation
  • L'une des données enregistrées : Ligne - Enregistrement - P-uplet nommé - Objet - Tuple - Dictionnaire
  • L'un des types d'informations enregistrées : Colonne - Attribut - Descripteur

Pourquoi pas un mot pour un seul concept ?

  1. A cause de la différence entre idée abstraite et implémentation réelle. Exemple :
    • La ligne de la table est de façon abstraite un p-uplet nommé : on peut l'implémenter en Python sous forme d'un tuple ou d'un dictionnaire par exemple.
  2. A cause de la différence entre les mathématiques et l'informatique : chaque domaine à son propre vocabulaire, mais les deux domaines étant en interaction proche, ce n'est pas forcément clair. A-t-on affaire à un mathématicien qui parle d'informatique ou d'un informaticien qui parle de mathématiques ?

Dans cette partie, nous allons donc définir la version "officielle" pour la NSI permettant à tous les élèves de France de pouvoir lire un même énoncé de la même façon. Mais, sachez qu'il est possible que vos cours dans le supérieur utilisent d'autres variations des termes présentés ici.

1 - Principe de la Base de Données

Actualité de 2020

Il est vraiment malheureux en 2020 de stocker des données sensibles dans un simple fichier CSV alors que depuis 1970 on sait faire mieux !

En fait, cela vient de l'outil utilisé !

La vérité ? Toujours via un autre titre lu dans la presse :

Gros titre : 16000 cas de covid non analysés à cause d'une 'erreur'

Nous allons voir aujourd'hui qu'il existe pourtant des systèmes datant de 1970 qui ont pour but d'éviter ceci justement. Les bases de données.

Elles sont utilisées partout : sur les sites Web en passant par les données des entreprises, et même l'historique de votre navigateur Web ! Ce n'est donc pas une nouveauté...

Définition d'une base de données

Une base de données est un ensemble structuré stockant des données intègres pouvant être traitées par un système informatique pour en sortir des informations.

On peut lui demander d'insérer de nouvelles données, de les trier, de les filtrer ou de les assembler.

Le stockage doit avoir les propriétés suivantes :

  1. Persistance des données : le stockage est permanent (une fois enregistré, c'est vraiment enregistré)
  2. Sécurisation des accès : on doit pouvoir limiter les droits d'accès et de modification en fonction du profil de l'utilisateur.
  3. Efficacité de traitement des requêtes : le système est rapide mais fait ce qu'on lui demande sans avoir besoin de vérifier si la modification a bien été effectuée.
  4. Gestion des accès concurrents : plusieurs personnes peuvent accéder au service BDD en même temps et même faire des modifications 'en même temps'. C'est un système multi-utilisateurs.
  5. Indépendance entre la représentation logique des données et l'implémentation physique réelle des données : comme pour les types de données Liste, Pile, File et leurs fonctions d'interface, la manipulation de la base de données ne doit pas nécessiter de savoir comment les données sont réellement stockées.
  6. Interface directe ou service API : l'utilisateur doit pouvoir manipuler facilement les données via une interface graphique/textuelle ou via un langage de programmation (API Application Programming Interface)
Principe d'une BDD : Multiusers et interface

Une base de données est donc multi-utilisateurs et doit comporter un système d'interfaçage entre les données et l'extérieur.

Un système permettant de gérer tous ces aspects d'une base de données s'appelle un système de gestion de bases de données relationnelles (SGBD).

Différences CSV et BDD

Les différences sont-elles grandes avec un fichier CSV permettant de créer une Collection ? Oui, CSV ne permet pas de garantir les points précédents :

  1. Permanent ? en cas de mise à jour du fichier CSV, nos programmes précédents devraient être mis au courant et devraient trouver un moyen de mettre à jour ou recréer la Collection.
  2. Sécurisée ? Aucune sécurité dans la création du fichier CSV : n'importe qui peut le modifier, supprimer des enregistrements ou rajouter des choses qui ne respectent pas le schéma global : le bon fonctionnement est dépendant de l'utilisateur. Mauvaise idée.
  3. Multi-utilisateurs ? Nos programmes ne permettent qu'à un utilisateur à la fois d'agir sur les données.
  4. Indépendance ? L'utilisateur doit respecter le format CSV s'il veut récupérer ses informations.
  5. Interface de type API ? Non. Il faut créer à la main nos propres programmes.

2 - Historique

1955 : les premiers disques durs sont opérationnels et vont permettre de stocker des données en grand nombre et, surtout, de pouvoir y accéder en un temps acceptable.

1960 : les premières bases de données ont stocké les enregistrements dans des arborescences. Un peu comme le TP Arbre à Pokemons mais en version stockage permanent et pas juste en mémoire vive.
Les missions Apollo ont utilisé ce type de BDD. Apollo 11 est la mission du programme spatial américain Apollo au cours de laquelle, pour la première fois, des hommes se sont posés sur la Lune, le 21 juillet 1969

On peut maintenant trouvé le code source de la mission sur GithHub : https://github.com/chrislgarry/Apollo-11.

En voici une célèbre photo montrant la quantité de code, version papier. A gauche, Margaret Hamilton, responsable de l'équipe chargée du développement du logiciel embarqué.

https://fr.wikipedia.org/wiki/Fichier:Margaret_Hamilton_-_restoration.jpg
Margaret_Hamilton, Mission Apollo 11. Image dans le domaine public (source wikipedia)

Le terme database (base de données) est apparu en 1964 pour désigner une collection d'informations partagées par différents utilisateurs d'un système d'informations (militaire à l'époque !).

En 1965, Charles Bachman conçoit l'architecture Ansi/Sparc encore utilisée de nos jours pour les BDD. Il a reçu le prix Turing en 1973 pour ses « contributions exceptionnelles à la technologie des bases de données ».

https://fr.wikipedia.org/wiki/Fichier:Margaret_Hamilton_-_restoration.jpg
Charles Bachman - Image tirée du site amturing.acm.org -

En 1970, Edgar F. Codd note dans sa thèse de mathématiques sur l'algèbre relationnelle qu'un ensemble d'enregistrements est comparable à une famille définissant une relation en mathématiques : tous les enregitrements ont effectivement les mêmes attributs. De la même façon, les jointures("assemblages" de plusieurs tables) sont équivalents à des produits cartésiens. Cette thèse est à l'origine des bases de données relationnelles qui vous allez découvrir aujourd'hui. Edgar F. Codd a reçu le prix Turing en 1981.

https://fr.wikipedia.org/wiki/Fichier:Margaret_Hamilton_-_restoration.jpg
Edgar F Codd - Image tirée du site wikipedia, en Fair Use (voir la page du lien)

Dans une base de données relationnelles, l'information est organisée de façon très précise dans des tableaux à deux dimensions appelés

  • des relations lorsqu'on reste dans l'abstraction ou
  • des tables lorsqu'on les implémente en machine.

1974 : son modèle théorique a inspiré , chez IBM, le développement du langage Structured English QUEry Language (SEQUEL) (« langage d'interrogation structuré en anglais »), renommé ultérieurement SQL pour cause de conflit de marque déposée avec une société d'aéronautique. SQL est encore actuellement le principal langage utilisé pour réaliser l'interfaçage avec les bases de données relationnelles.

En 1979, la société qui deviendra Oracle Corporation présenta la première version commercialement disponible de SQL, rapidement imitée par d'autres fournisseurs.

En 1986, SQL est adopté comme recommandation par l'Institut de normalisation américaine (ANSI).

En 1987, SQL est adopté comme comme norme internationale par l'Organisation internationale de normalisation (ISO).

no-SQL

Devant l'augmentation énorme ces dernières années de la quantité d'informations récoltées, certaines entreprises ont dû passer à d'autres formes de base de données : les bases de données non-relationnelles, également nommées no-SQL.

Ces bases de données permettent plus facilement le stockage d'informations en quantité très très importante. Les données stockées sont moins structurées et prennent donc moins de place. Attention, ces "nouvelles" bases de données ne remplacent pas les précédentes : il s'agit juste d'un usage très particulier.

Conclusion

Les données d'une BDD peuvent être stockées sous une forme très structurées (base de données relationnelles par exemple), ou bien sous la forme de données brutes peu structurées voire déstructurées (avec les bases de données NoSQL par exemple). Une base de données peut être localisée dans un même lieu et sur un même support informatisé, ou réparties sur plusieurs machines à plusieurs endroits.

Les BDD sont finalement assez flexibles pour s'adapter à différents besoins.

3 - Relation

Regardons maintenant plus précisement ce qui caractérise les relations et pourquoi on parle de base de données relationnelles.

Nous allons commencer par un cas très simple : la relation unique. Une seule table donc.

Voici un exemple de relation basée sur les vieux jeux vidéos.

id jeu description annee_sortie editeur support genre capture_ecran
1 Flight Simulator Simulation de piotage d'avion avec des pixels gros comme des camions ! 1980 subLOGIC Apple 2 Simulateur Flight Simulator
2 DONKEY KONG Un méchant singe géant a capturé la fiancé de JumpMan (qui portera plus tard le nom de Mario). Guide JumpMan pour qu'il délivre sa dulcinée. 1981 Nintendo Arcade Plate-formes Donkey Kong
3 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1982 Activision Atari 2600 Plate-formes Donkey Kong
4 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1983 Activision Commodore 64 (C64) Plate-formes Donkey Kong
5 Boulder Dash Rockford, mineur téméraire, ramasse des diamants et tente de ne pas se faire écraser par les énormes pierres instables. 1983 First Star Software Commodore 64 (C64) Plate-formes Boulder Dash

01° L'ensemble des données ci-dessus représente une table. Quel nom va-t-on lui donner dans cette activité :

  1. Un champ
  2. Une relation
  3. Un p-uplet
  4. Un attribut

...CORRECTION...

  • Une relation
  • Regardons maintenant cette ligne (en rouge) :

    id jeu description annee_sortie editeur support genre visuel
    1 Flight Simulator Simulation de piotage d'avion avec des pixels gros comme des camions ! 1980 subLOGIC Apple 2 Simulateur Flight Simulator
    2 DONKEY KONG Un méchant singe géant a capturé la fiancé de JumpMan (qui portera plus tard le nom de Mario). Guide JumpMan pour qu'il délivre sa dulcinée. 1981 Nintendo Arcade Plate-formes Donkey Kong
    3 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1982 Activision Atari 2600 Plate-formes Donkey Kong
    4 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1983 Activision Commodore 64 (C64) Plate-formes Donkey Kong
    5 Boulder Dash Rockford, mineur téméraire, ramasse des diamants et tente de ne pas se faire écraser par les énormes pierres instables. 1983 First Star Software Commodore 64 (C64) Plate-formes Boulder Dash

    02° Quel nom va-t-on donner à cette ligne dans cette activité :

    1. Un champ
    2. Une relation
    3. Un p-uplet
    4. Un attribut

    ...CORRECTION...

  • Un p-uplet
  • On pourrait dire aussi n-uplet ou enregistrement.

    03° Comment se nomme l'un des éléments situés dans l'en-tête de la relation ?

    1. Un champ
    2. Une relation
    3. Un p-uplet
    4. Un attribut

    ...CORRECTION...

    1. Un attribut
    2. On pourrait aussi dire descripteur ou propriété.

    Regardons maintenant cette case (en rouge) :

    id jeu description annee_sortie editeur support genre capture_ecran
    1 Flight Simulator Simulation de piotage d'avion avec des pixels gros comme des camions ! 1980 subLOGIC Apple 2 Simulateur Flight Simulator
    2 DONKEY KONG Un méchant singe géant a capturé la fiancé de JumpMan (qui portera plus tard le nom de Mario). Guide JumpMan pour qu'il délivre sa dulcinée. 1981 Nintendo Arcade Plate-formes Donkey Kong
    3 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1982 Activision Atari 2600 Plate-formes Donkey Kong
    4 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1983 Activision Commodore 64 (C64) Plate-formes Donkey Kong
    5 Boulder Dash Rockford, mineur téméraire, ramasse des diamants et tente de ne pas se faire écraser par les énormes pierres instables. 1983 First Star Software Commodore 64 (C64) Plate-formes Boulder Dash

    04° Comment se nomme l'une case correspondant à l'intersection d'un p-uplet (enregistrement) et d'un attribut (descripteur) ?

    1. Un champ
    2. Une relation
    3. Un p-uplet
    4. Un attribut

    ...CORRECTION...

    1. Un champ
    2. Chaque case correspond en effet à un champ de réponse possible. C'est l'équivalent d'une cellule dans un traitement de texte.

    05° Quelle est la valeur associée à ce champ ?

    ...CORRECTION...

    La valeur est "PITFALL !". Visiblement l'attribut jeu désigne des informations stockées sous forme d'une chaîne de caractères.

    Voyons maintenant l'une des premières différences entre des données stockées dans un fichier CSV et des données stockées dans une base de données relationnelles.

    1/4 - Domaine d'un attribut et contrainte d'intégrité

    Lors de la création de la relation, il faut impérativement fournir la liste des attributs qu'on désire.

    En réalité, chaque attribut est défini par deux choses au moins :

    • Le nom de l'attribut :
      • On utilisera souvent des minuscules et des underscores pour séparer les éventuels noms composés de plusieurs mots (snake_case). En effet, quelques implémentations de base de données ne sont pas sensibles à la casse.
      • Dans le même esprit, certains utilisent uniquement des majuscules (comme cela pas de problème non plus sur les systèmes non sensibles à la casse).
      • Finalement, certains utilisent néanmoins du camelCase, mais c'est moins portable : si cela fonctionne sur votre base de données sensible à la casse, pas certain qu'en changeant de type de base de données, cela ne pose pas de problèmes.
    • Le domaine de l'attribut : cela caractérise l'ensemble des valeurs qui sont attendues et autorisées pour cet attribut. Ces domaines peuvent correspondre à
      • des types de variables typiques des langages de programmation (integer, caractère, integer positif)... ou
      • des types plus contraignants : une date, une heure... ou même
      • des valeurs appartiennant à un ensemble précis, par exemple {"EX", "TB", "B", "P", "I", "A"} pour des appréciations

    Trois améliorations par rapport aux simples fichiers CSV :

    1. La valeur NULL de SQL permet d'indiquer qu'on ne donne pas de valeur dans ce champs. Deux raisons possibles d'avoir NULL
      1. On ne connaît pas de valeur intègre et précise pour le moment (date de mise en vente d'un produit en rupture de stock)
      2. La valeur n'a pas de sens (plaque d'immatriculation pour une personne qui ne possède pas de véhicule par exemple)
    2. On peut placer une valeur par défaut (on peut même décider que c'est NULL).
    3. On peut imposer des CONTRAINTES d'intégrité de DOMAINE qui empêchent d'enregistrer une donnée si elle n'a pas le type attendu.
    2/4 - Domaines disponibles

    Les différents domaines ainsi que la façon de les déclarer change sensiblement d'un système d'interfaçage à un autre.

    Voyons par exemple SQLITE qui permet d'utiliser facilement SQL sans installer un serveur réel. Dans SQLITE, la base de données est en réalité implémentée dans un fichier-texte.

    Logo SQLite

    Cette bibliothèque écrite en C est directement intégrée au programme. Ce système et son code source sont entièrement dans le domaine public ce qui permet à tout à chacun d’utiliser et de participer à l’évolution de ce projet. Il existe également un module Python qui nous permettra de faire interagir Python et notre base de données avec énormément de facilité.

    Voici ce qu'on trouve sur le site officiel de https://www.sqlite.org :

    Expression Affinity Column Declared Type
    TEXT "TEXT"
    NUMERIC "NUM"
    INTEGER "INT"
    REAL "REAL"
    BLOB (a.k.a "NONE") "" (empty string)

    Comme son nom l'indique, SQLite fait dans le light par rapport aux autres bases de données SQL (comme MySQL, MariaDB...)

    1. TEXT pour tout ce qui est caractère unique ou multiples.
    2. NUMERIC pour rentrer un nombre.
    3. INTEGER pour les entiers.
    4. REAL pour les flottants.
    5. BLOB pour le reste : par exemple les images. Cela veut dire qu'on peut placer n'importe quelle suite d'octets. C'est un blob, une masse informe.

    La plupart des autres BDD SQL incluent

    • un type CHAR qui permet de stocker des caractères en nombre limité. Exemple : CHAR(40) pour dire qu'on n'accepte qu'une entrée de type texte tenant sur au plus 40 caractères.
    • un type DATE qui permet de stocker uniquement des dates valides, avec un formatage choisi à la création : AAAA-MM-JJ ou JJ-MM-AAAA ou MM-JJ-AAAA à l'américaine.
    • un type DATETIME qui permet de dater un moment dans un format incluant date et heure : AAAA-MM-JJ HH:MM:SS.
    • La bonne nouvelle pour vous ? Aucun système de BDD précis n'est imposée dans le programme NSI. Aucune question ne peut donc être posée de façon précise sur les différents types. On restera donc dans les généralités, en imaginant par exemple un système SQL mimant les types Python.

      id jeu description annee_sortie editeur support genre capture_ecran
      INTEGER TEXT TEXT INTEGER TEXT TEXT TEXT BLOB
    3/4 - Schéma relationnel : une définition un peu plus formelle d'une relation

    Une relation est définie en fournissant son nom ainsi que la liste de ses attributs (nom et domaine).

    Exemple de création de table avec SQLITE pour créer la table des salariées d'une entreprise (juste pour info, aucune connaissance sur la création de tables pendant les épreuves de NSI) :

    IMPLEMENTATION : création de la table de la relation salarie en SQL (version SQLite)

    1 2 3 4 5 6 7
    CREATE TABLE salarie ( s_id INTEGER PRIMARY KEY, nom TEXT NOT NULL, age INTEGER NOT NULL, adresse TEXT, salaire REAL );

    Nous verrons un peu plus loin ce que signifie PRIMARY KEY.

    NOT NULL est clair : la valeur doit absolument être renseignée pour créer l'enregistrement. On n'acceptera pas d'entrée où cette information est manquante. Comme dans les formules Web où on demande absolument de renseigner telle ou telle chose.

    On pourrait décrire la relation de cette façon très simple en restant à un niveau abstrait et en se rapprochant finalement d'un mixe entre la déclaration d'une fonction Python et d'un tuple Python par exemple :

    ABSTRACTION : schéma relationnel de la relation salarie

    salarie(s_id:int, nom:text, age:int, adresse:text, salaire:int)

    Soulignement : on remarquera qu'on souligne la clé primaire dans cette façon de décrire les attributs d'une relation. D'ailleurs, puisqu'on est ici sur au niveau de la réflexion abstraite, on pourra utiliser le camelCase pour rendre la lecture plus facile :

    salarie(sId:int, nom:text, age:int, adresse:text, salaire:int)

    Majuscule pour la relation : on trouve parfois une convention consistant à mettre une majuscule sur le nom de la relation. On aurait donc pu noter Salarie. Un peu comme le nom des Classes dans la programmation objet.

    Salarie(sId:int, nom:text, age:int, adresse:text, salaire:int)

    Une bonne pratique consiste donc à tout mettre en minuscule et d'utiliser le snake_case mais les pratiques diffèrent d'un professionnel à l'autre.

    06° Déterminer les noms des attributs et leurs types dans la table des jeux qu'on nommera jeu.

    id jeu description annee_sortie editeur support genre capture_ecran
    1 Flight Simulator Simulation de piotage d'avion avec des pixels gros comme des camions ! 1980 subLOGIC Apple 2 Simulateur Flight Simulator
    2 DONKEY KONG Un méchant singe géant a capturé la fiancé de JumpMan (qui portera plus tard le nom de Mario). Guide JumpMan pour qu'il délivre sa dulcinée. 1981 Nintendo Arcade Plate-formes Donkey Kong
    3 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1982 Activision Atari 2600 Plate-formes Donkey Kong
    4 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1983 Activision Commodore 64 (C64) Plate-formes Donkey Kong
    5 Boulder Dash Rockford, mineur téméraire, ramasse des diamants et tente de ne pas se faire écraser par les énormes pierres instables. 1983 First Star Software Commodore 64 (C64) Plate-formes Boulder Dash

    ...CORRECTION...

    07° Fournir le schéma relationnel de la relation pokemon qui permettrait de mettre les données du fichier CSV dans une BDD.

    En voici un extrait :

    1 2 3 4
    Number, Name, Type 1, Type 2, Total, HP, Attack, Defense, Sp. Atk, Sp. Def, Speed, Generation, Legendary 1, Bulbasaur, Grass, Poison, 318, 45, 49, 49, 65, 65, 45, 1, False 2, Ivysaur, Grass, Poison, 405, 60, 62, 63, 80, 80, 60, 1, False 3, Venusaur, Grass, Poison, 525, 80, 82, 83, 100, 100, 80, 1, False

    Pensez à faire attention au nommage : en SQL, on tente de ne pas utiliser les majuscules et on utilise l'underscore pour séparer les mots.

    Comme d'habitude, il ne s'agit que de conventions.

    ...CORRECTION...

    4/4 - Clé primaire et Contrainte d'UNICITE des enregistrements

    On rappelle qu'enregistrement et p-uplet sont synomymes dans le cadre d'une relation.

    Pour définir un p-uplet, il faut fournir l'ensemble des informations liées aux attributs de la relation.

    La relation peut-être vue comme un ensemble de p-uplets, au sens des mathématiques.

    Or, dans un ensemble mathématique, chaque entité ne peut apparaître qu'une unique fois.

    • {1, 2, 3, 8} peut être vu comme un ensemble.
    • (1, 3, 3, 8) ne peut pas être vu comme un ensemble car 3 apparaît deux fois.

    La clé primaire est un attribut permettant d’identifier à coup sûr un unique p-uplet parmi tous les p-uplets de la relation : cette clé primaire pourra ainsi toujours permettre de différencier des p-uplets qui seraient sinon identiques :

    • (007, James, Bond, Anglais) pour l'agent secret nommé James Bond.
    • (008, James, Bond, Anglais) pour le plombier nommé James Bond.

    Puisque chaque p-uplet d'une relation doit être unique, aucun p-uplet de cette relation ne peut avoir exactement les mêmes valeurs que lui.

    La clé primaire est un moyen d'identifier clairement les p-uplets de façon à garantir la contrainte d'UNICITE des p-uplets.

    La clé primaire peut-être

    1. un attribut unique (comme votre numero_etudiant) ou
    2. être l'association de plusieurs attributs (comme (numero_de_sécu, nom, prenom)), mais dans ce cas, la recherche d'un p-uplet est plus longue car il faut utiliser 3 colonnes à la fois.

    Exemple : un livre.

    L'attribut titre lié au nom d'un livre ne permet pas de l'identifier à coup sûr. Il est possible qu'un livre portant le même nom existe.

    On peut peut-être envisager que la clé primaire soit un p-uplet elle même : pourquoi pas le couple (titre, auteur) ?

    Si votre but est de faire un site donnant des avis sur des livres, cela peut suffire : vous n'avez aucune raison d'avoir la même entrée deux fois.

    Par contre, si vous avez un site de vente de livre, il est possible qu'un même livre soit sorti sous plusieurs éditions successives et le couple précédent ne suffirait pas...

    Pour garantir à coup sûr l'UNICITE, on rajoute souvent automatiquement un attribut supplémentaire dans les relations : un identifiant qui joue le rôle d'information supplémentaire, purement informatique et qui permet donc de distinguer à coup sûr n'importe quel enregistrement !

    A chaque fois qu'on rajoute un nouveau p-uplet dans la relation, il suffit alors d'incrémenter l'identifiant automatiquement, voire de récupérer un ancien numéro d'identification laissé libre à cause d'une suppression dans la relation.

    Dans le cadre de l'utilisation d'un SGBD, c'est le système qui se charge de choisir une valeur adaptée à cet identifiant automatiquement..

    Conventions

    On identifie les clés primaires

    • en les soulignant lorsqu'on donne un schéma relationnel abstrait d'une relation
    • en plaçant une petite clé dorée à côté lorsqu'on utilise une table concrète via une interface graphique sur un SGBD
    • en préfixant parfois le nom de l'attribut par pk pour primary key (ex pk_id_livre)

    08° Quel est le nom du numéro d'identification qui permet de distinguer les publications françaises ?

    Ce numéro permet-il de distinguer deux exemplaires d'un même libre (même nom, même auteur, même édition et même version) ?

    09° Peut-on utiliser l'ISBN comme clé primaire pour un site WEB qui publie des critiques de livres ? Pour une bibliothèque qui vend des livres ?

    Choisir les attributs (noms et domaines) d'une relation livre unique qui permettraient de gèrer un système de location de livres.

    10° On veut créer une relation eleve qui permettrait d'identifier les élèves d'un établissement scolaire.

    Fournir un ensemble d'au moins 5 attributs qui permettrait de gérer ces élèves à minima.

    Les élèves disposent-ils d'un système d'identification leur permettant de garantir la contrainte d'UNICITE (autre que l'identificateur automatique de la relation elle-même) ?

    4 - Clés étrangères

    Nous allons maintenant voir une autre raison à l'existence de la clé primaire.

    Imaginons que je veuille augmenter la quantité d'informations contenues dans ma table sur les jeux retro :

    On rajoute les infos sur la console en plus des infos sur le jeu lui-même

    En plus du nom du support (la console sur laquelle le jeu tournait), on rajoute à chaque fois la date de sortie de la console, sa mémoire et la capacité de gestion de processeur (en bits).

    11° Qu'est-ce qui ne va pas être optimum en terme de mémoire si on finit par mettre vraiment beaucoup de jeux dans la relation ?

    Pour limiter ce problème, la solution envisagée par les bases de données relationnelles est de relier les informations des relations entre elles.

    Le principe de base est tout bête : plutôt que du dupliquer de nombreuses fois les mêmes informations, nous allons créer une deuxième relation console qui va contenir les p-uplets nommés caractérisant les différentes consoles.

    La relation console contient les informations sur les consoles

    12° Donner le schéma relationnel de la relation console en imaginant qu'on dispose d'un domaine nommé Date.

    13° Quelle est la clé primaire de cette relation ? Est-elle bien soulignée ?

    Regardons maintenant comment utiliser cela :

    La clé étrangère permet de faire le lien entre la table jeu et la table console

    Comme vous pouvez le voir, l'un des attributs de la relation jeu_retro doit donc tout simplement avoir comme domaine les valeurs de la clé primaire de la relation console.

    14° Quatre choses :

    1. Localiser le p-uplet de la relation jeu_retro dont la clé primaire vaut 10.
    2. Quelle est la valeur du champ id_support de ce p-uplet ?
    3. Que peut-on en tirer comme informations sur la console de ce jeu ?
    4. Fournir le p-uplet virtuel obtenu en concaténant les attributs de la relation jeu_retro et les attributs de la relation console ?

    ...CORRECTION...

    1. Localiser le p-uplet de la relation jeu_retro dont la clé primaire vaut 10.
    2. Il s'agit de l'avant dernière ligne, le PITFALL ! sorti en 1983.

    3. Quelle est la valeur du champ id_support de ce p-uplet ?
    4. On lit 3 dans le champ de l'atttribut id_support.

    5. Que peut-on en tirer comme informations sur la console de ce jeu ?
    6. En allant voir dans la relation console, on peut voir qu'il s'agit d'une version du jeu pour le C64, ordinateur personnel sorti en 1982 et disposant de 64 ko de mémoire.

    7. Fournir le p-uplet virtuel obtenu en concaténant les attributs de la relation jeu_retro et les attributs de la relation console ?
    8. id jeu description sortie editeur fichier_image genre jeu_retro.id_support = console.id nom RAM date_sortie
      10 PITFALL! Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle. 1983 Activision Donkey Kong Plate-formes 3 C64 64 ko 1982-08-01

    15° Quel est l'avantage en place mémoire ? Quel risque cela annule-t-il ?

    ...CORRECTION...

    Deux avantages à séparer ainsi l'information sur deux tables :

    <
    1. Gain en place mémoire puisque l'information sur le C64 n'est plus stocké qu'une unique fois en réalité.
    2. Il n'existe qu'une unique source d'information. Cela évite les erreurs bêtes comme le fait qu'on indique une fois que sa RAM est de 64 ko et ailleurs 67 ko à cause d'une erreur de frappe.
    Clé étrangère, clé primaire

    Le système est donc basé sur :

    1. des attributs nommés clés primaires respectant la contrainte d'UNICITE : elles permettent d'identifier à coup sûr l'un des n-uplets d'une relation A puisque seul ce n-uplet à cette valeur dans la relation.
    2. Une clé primaire ne peut pas valoir NULL car cela indiquerait qu'on ne connait pas la clé primaire de cet enregistrement !

    3. des attributs nommés clés étrangères respectant la contrainte de REFERENCE : elles ont une valeur qui doit correspondre à une valeur de clé primaire réelle dans une table et permettent ainsi de trouver à coup sûr un autre n-uplet.
    4. Une clé secondaire peut contenir NULL, cela indique qu'on ne sait pas pour l'instant où se trouve l'information voulue.

    Dans l'exemple des consoles et des jeux retro, la clé éétrangère id_support doit être affecté à 1, 2 ou 3. On accepte également NULL ici, mais on aurait pu refuser cette valeur.

    La clé étrangère permet de faire le lien entre la table jeu et la table console

    On identifie les cls étrangères :

    • en plaçant un caractère dièse # devant leur nom (dans un schéma relationnel)
    • ou en commençant le nom de l'attribut par fk pour foreign key (dans une vraie table implémentée) : fk_id_support, ou encore mieux fk_id_console pour indiquer qu'il s'agit d'une clé étrangère menant à l'un des n-uplets de la table console.

    16° Fournir les schémas relationnels des relations jeu_retro et console.

    Deux conventions courantes de nommage

    Lorsqu'on a un grand nombre de relations, on est parfois difficile de savoir de quel attribut on parle exactement.

    Préfixer les attributs pour la première lettre de la relation

    L'une des conventions est de faire précéder tous les noms d'attributs d'une relation par la première lettre de la relation.

    On met même parfois le nom entier.

    Nous aurions donc :

    1 2 3 4 5 6 7 8 9 10
    jeu_retro ( j_id_jeu_retro:int, j_jeu:text, j_description:text; j_sortie:date, j_editeur:text, j_fichier_image:blob, j_genre:text, #j_id_support:int )

    Attention, le nom de l'attribut en ligne 9 est juste j_id_support. Le # permet juste de signaler qu'il s'agit d'une clé étrangère.

    Et pour la deuxième table :

    1 2 3 4 5 6
    console ( c_id_console:int, c_nom:text, c_ram:text; c_sortie:date, )

    Néanmoins, cela a tendance à rapidement alourdir les notations.

    Nommer la clé étrangère comme la clé primaire qu'elle référence

    On donne souvent le même nom à la clé étrangère que celui de la clé primaire de la relation qu'on pointe. Exemple :

    1 2 3 4 5 6 7 8 9 10
    jeu_retro ( id_jeu_retro:int, jeu:text, description:text; sortie:date, editeur:text, fichier_image:blob, genre:text, #id_console:int )
    1 2 3 4 5 6
    console ( id_console:int, nom:text, ram:text; sortie:date, )

    Les deux à la fois ?

    On donne souvent le même nom à la clé étrangère que celui de la clé primaire de la relation qu'on pointe. Exemple :

    1 2 3 4 5 6 7 8 9 10
    jeu_retro ( j_id_jeu_retro:int, j_jeu:text, j_description:text; j_sortie:date, j_editeur:text, j_fichier_image:blob, j_genre:text, #j_c_id_console:int )
    1 2 3 4 5 6
    console ( c_id_console:int, c_nom:text, c_ram:text; c_sortie:date, )

    5 - Schéma relationnel

    Schéma relationnel d'une base de données

    Le schéma relationnel d'une base de données est l'ensemble des relations et des liaisons entre ces relations. Il s'agit donc de donner le schéma relationnel de toutes les relations contenues dans la base de données et de montrer les liaisons entre les raisons.

    On doit donc fournir :

    1. le nom de chaque relation
    2. la liste des attributs de chaque relation (nom et domaine)
    3. Indiquer clairement la clé primaire des relations (soulignement ou pk)
    4. Indiquer clairement les clés étrangères (# ou fk)

    Pour l'exemple précédent, il s'agit donc juste des deux choses déjà présentées :

    1 2 3 4 5 6 7 8 9 10
    jeu_retro ( j_id_jeu_retro:int, j_jeu:text, j_description:text; j_sortie:date, j_editeur:text, j_fichier_image:blob, j_genre:text, #j_id_support:int (clé étrangère vers la relation console) )
    1 2 3 4 5 6
    console ( c_id_console:int, c_nom:text, c_ram:text; c_sortie:date, )

    On peut également les représenter sous forme de schéma graphique :

    sr_graphique.png

    17° Créer le schéma relationnel d'une bibliothèque. On aura besoin des relations livre, client, location.

    6 - FAQ

    Rien pour l'instant

    Activité publiée le 10 01 2021
    Dernière modification : 10 01 2021
    Auteur : ows. h.