Données BDD

Identification

Infoforall

25 - Les Bases de Données


En 1er, nous avons vu qu'il était possible de stocker les données dans un fichier CSV, 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

Les données de ce fichier peuvent alors être placées en mémoire vive de façons à obtenir une Collection ou Table contenant des enregistrements.

De façon schématique,

  • Chaque ligne de la table est l'un des enregistrements ou objets (un n-uplet, un tableau ou un dictionnaire)
  • 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 placer les enregistrements dans un simple tableau (nommé également liste contiguë). Dans ce cas, chaque case contient un enregistrement.

Nous avons vu en Terminale comment placer les enregistrements dans un arbre de recherche pour rendre la recherche et l'insertion plus efficace. Dans ce cas, chaque noeud contient l'un des enregistrements (fonction d'interface data pour notre arbre à Pokemons).

Nous allons voir aujourd'hui une autre façon (pour cette année) de stocker ces informations : 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.

Collection - Table - Relation

Ligne - Enregistrement - P-uplet nommé - Objet - Tuple - Dictionnaire

Colonne - Attribut - Descripteur

Pourquoi ?

  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.

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é ?

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. Ils sont utilisés partout : sur les sites Web en passant par les données des entreprises, et même l'historique des navigateurs ! 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 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 être fait :

  1. De façon permanente (persistance des données) : une fois enregistré, c'est vraiment enregistré.
  2. De façon sécurisée (sécurisation des accès) : on peut limiter les droits d'accès et de modification
  3. De façon efficace (efficacité de traitement des requêtes dont la non redondance et la cohérence des données) : le système est solide et fait ce qu'on lui demande sans avoir besoin de vérifier si une modification a bien été prise en compte et a bien fonctionné
  4. De façon à permettre des accès multi-utilisateurs (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'.
  5. De façon à permettre une indépendance entre la représentation physique des données et la représentation logique des données
  6. De façon à fournir une interface efficace et donc un service de type API
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.

Quelles grosses différences avec un fichier CSV permettant de créer une Collection ? 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 ? Une 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. API ? Non, il faut créer à la main nos propres programmes.

Contrairement à la plupart des autres activités, nous n'allons pas ici regarder sous le capot : nous n'allons faire qu'utiliser les bases de données et non pas regarder comment elles sont réellement implémentées.

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 notre 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

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 mathématiques sur l'algèbre relationnelle qu'un ensemble d'entités est comparable à une famille définissant une relation en mathématiques et que les jointures("assemblages" de plusieurs tables) sont 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)

Ses contributions ont permis de mettre en place les bases de données relationnelles.

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 ou encore tables.

Les lignes de ces relations sont appelées des n-uplets ou enregistrements.

Les colonnes sont appelées des attributs.

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é 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).

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.

Leurs données 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.

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.

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

id Jeu Description Année de sortie Editeur Support Genre Capture d'écran
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 Année de sortie Editeur Support Genre Capture d'écran
    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 Année de sortie Editeur Support Genre Capture d'écran
    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 valeure est "PITFALL !".

    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.

    Champs, valeurs et domaine d'un attribut

    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 :

    • Son nom ou intitulé : on utilise des minuscules et des underscores pour séparer les éventuels noms composés de plusieurs mots.
    • Son domaine : cela caractérise l'ensemble des valeurs qui sont autorisées pour les valeurs associées à cet attribut. Ces domaines peuvent correspondre à des types de variables reconnues dans la version de SQL (integer, caractère, integer positif)... mais on peut également rajouter des contraintes : une date, une heure, ou même imposer que les valeurs appartiennent à un ensemble précis : uniquement "EX" (pour excellent), "TB" (pour très bien), "B" (pour bien), "P" (pour passable), "I" (pour insuffisant), "TI" (pour très insuffisant)...
    • Nous verrons plus tard qu'on peut même imposer que chaque valeur n'apparaisse qu'une fois, qu'un champ peut être laissé vide ou pas... On peut donc imposer des contraintes supplémentaires.

      Enfin, il y a bien entendu la possibilité de placer une valeur par défaut.

    C'est donc la première nouveauté : dans nos fichiers-texte CSV, toutes les données étaient stockées sous forme de ... texte.

    Dans une base de données, on peut donc choisir le type d'un attribut et encore mieux : la base de données n'acceptera pas d'enregistrer un p-uplet si l'une de ses valeurs n'appartient pas au bon domaine.

    De cette façon, nous sommes certains que toutes les données stockées sont bien conformes aux attendus.

    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é 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.

    Schéma relationnel : une définition un peu plus formelle d'une relation

    Une relation peut être 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 :

    Code SQL (version SQLite) -> Implémentation

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

    Nous verrons un peu plus loin ce que signifie PRIMARY KEY. Et NOT NULL est clair : la valeur ne peut pas être vide.

    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 :

    Schéma relationnel de la relation salarie -> Abstraction

    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.

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

    id Jeu Description Année de sortie Editeur Support Genre Capture d'écran
    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° Donner la table pokemon des Pokemons que nous avions utilisé lors de l'activité sur les arbres.

    En voici un extrait :

    1 2 3 4
    #,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'habitudes, il ne s'agit que de conventions.

    ...CORRECTION...

    Clé primaire et Unicité des enregistrements

    La clé primaire est un attribut ou l’association de plusieurs attributs permettant d’identifier à coup sûr un unique p-uplet de la relation.

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

    Or, une relation peut-être vu comme un ensemble de p-uplets, au sens des mathématiques. Or, dans un ensemble, chaque entité ne peut apparaître qu'une fois.

    Ainsi,

    • {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.

    Chaque p-uplet doit donc être unique.

    Aucun p-uplet de la relation ne peut donc avoir exactement les mêmes valeurs qu'un autre p-uplet.

    Il faut donc trouver un moyen d'identifier clairement les p-uplets de façon à garantir l'unicité des p-uplets.

    Pour cela, on cherche à déterminer ce qui peut servir de clés primaires aux p-uplets

    Exemple : un livre.

    L'attribut livre_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 par contre peut-être envisager que la clé primaire soit un p-uplet elle même : pourquoi pas le p-uplet (livre_titre, livre_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. Si ?

    La plupart du temps, on rajoute un attribut supplémentaire dans les relations : un identifiant !

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

    Puisque c'est le système qui se charge de choisir une valeur adaptée à cet identifiant automatique, nous sommes certains que chaque p-uplet est nécessairement différent des autres.

    08° Dans le cadre du site de notation de livres, dans quel cas le tuple (livre_titre, livre_auteur) risque-t-il de ne pas être suffisant ?

    09° Pourquoi est-il difficile de se passer d'un système d'identifiant automatique dans une bibliothèque ?

    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 l'unicité (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 que ne va pas être optimum pour cette relation si on finit par y mettre vraiment beaucoup de jeux ?

    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 ? L'avez vous bien souligné ?

    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 doit donc tout simplement avoir comme domaine les valeurs de la clé primaire de la relation console.

    14° Quelle est la valeur du champ "id_support" du p-uplet de la relation jeu dont la clé primaire vaut 10 ? Que peut-on en tirer comme informations sur la console de ce jeu ?

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

    Clé Primaire et Clé étrangère

    Le système de clés permet donc de relier différentes relations (ou tables) entre elles.

    La clé primaire est un attribut ou l’association de plusieurs attributs permettant d’identifier à coup sûr un unique p-uplet de la relation.

    La clé primaire d'une relation doit impérativement permettre d'identifier un unique p-uplet (enregistrement) dans cette relation.

    On les identifie en la soulignant (dans un schéma relationnel) ou en plaçant une petite clé (dans les interfaces graphiques) à côté de son nom.

    Convention de nommage : on fait parfois commencer le nom de l'attribut par pk pour primary key : pk_id_jeu.

    Une clé étrangère est donc un attribut d'une relation qui correspond à la clé primaire d'une autre relation.

    On les identifie en plaçant un caractère dièse # devant leur nom (dans un schéma relationnel).

    Convention de nommage : on fait parfois commencer le nom de l'attribut par fk pour foreign key : fk_id_console.

    16° Fournir les descriptions des deux tables.

    Convention de nommage

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

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

    On met parfois le nom entier pour l'identificateur automatique.

    Nous aurions donc :

    1 2 3 4 5 6 7 8 9 10
    jeu ( j_id_jeu:int, j_nom: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 bien 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.

    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 raisons 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 :

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

    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, )

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

    sr_graphique.png

    On peut également écrire ceci :

    Pour l'exemple précédent :

    1 2 3 4 5 6 7 8 9 10 11 12
    jeu ( j_id_jeu:int, j_nom:text, j_description:text; j_sortie:date, j_editeur:text, j_fichier_image:blob, j_genre:text, j_id_support:int ) Clé primaire : j_id_jeu Clé étrangère : j_id_support (vers la relation console)

    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.