23 - Les Bases de Données

⏪

⏬

⏩

1 - BDD

2 - Historique

3 - Relation

4 - étrangères

5 - Schéma Rel.

6 - FAQ

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 :

C'est un simple fichier-texte
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	Pokemon n°	Nom	Type	Points de vie
Collection / Table	Attributs ou Descripteurs
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 ?

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.

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.

MODE COURS (cacher les questions)

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

1.1 Définition d'une base de données

Voir

Définition

Une base de données est un ensemble structuré stockant de données intègres pouvant être traitées par un système informatique pour en sortir des informations et respectant des propriétés précises (voir ci-dessous).

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

Propriétés

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

Persistance des données : le stockage est permanent (une fois enregistré, c'est vraiment enregistré)
Sécurisation des accès : on doit pouvoir limiter les droits d'accès et de modification en fonction du profil de l'utilisateur.
Efficacité de traitement des requêtes : le système fait ce qu'on lui demande sans avoir besoin de vérifier si la modification a bien été effectuée.
Gestion des accès concurrents : c'est un système multi-utilisateurs, plusieurs personnes peuvent faire des modifications 'en même temps'.
Indépendance entre la représentation logique des données et l'implémentation physique des données : la manipulation de la base de données ne doit pas nécessiter de savoir comment les données sont réellement stockées.
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

SGBD

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 s'appelle un système de gestion de bases de données relationnelles (SGBD).

1.2 Différences CSV et BDD

Voir

CSV ne permet pas de garantir les points précédents :

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.
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.
Multi-utilisateurs ? Nos programmes ne permettent qu'à un utilisateur à la fois d'agir sur les données.
Indépendance ? L'utilisateur doit respecter scrupuleusement le format CSV s'il veut récupérer ses informations.
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 ».

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

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écisément 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
1	Flight Simulator	Simulation de pilotage d'avion avec des pixels gros comme des camions !	1980	subLOGIC	Apple 2	Simulateur
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
3	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1982	Activision	Atari 2600	Plate-formes
4	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1983	Activision	Commodore 64 (C64)	Plate-formes
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

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

Un champ
Une relation
Un p-uplet
Un attribut

Correction ?

...CORRECTION...

Une relation

Regardons maintenant cette ligne (en rouge) :

id	jeu	description	annee_sortie	editeur	support	genre
1	Flight Simulator	Simulation de pilotage d'avion avec des pixels gros comme des camions !	1980	subLOGIC	Apple 2	Simulateur
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
3	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1982	Activision	Atari 2600	Plate-formes
4	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1983	Activision	Commodore 64 (C64)	Plate-formes
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

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

Un champ
Une relation
Un p-uplet
Un attribut

Correction ?

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

Un champ
Une relation
Un p-uplet
Un attribut

Correction ?

...CORRECTION...

Un attribut

On pourrait aussi dire descripteur ou propriété.

Regardons maintenant cette case (en rouge) :

id	jeu	description	annee_sortie	editeur	support	genre
1	Flight Simulator	Simulation de pilotage d'avion avec des pixels gros comme des camions !	1980	subLOGIC	Apple 2	Simulateur
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
3	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1982	Activision	Atari 2600	Plate-formes
4	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1983	Activision	Commodore 64 (C64)	Plate-formes
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

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

Un champ
Une relation
Un p-uplet
Un attribut

Correction ?

...CORRECTION...

Un champ

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 ?

...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 les premières différences entre des données stockées dans un fichier CSV ou dans une base de données relationnelles.

3.1 - Contrainte d'intégrité de DOMAINE

Voir

Attribut : nom + domaine

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

Chaque attribut est défini par deux choses au moins :

Le nom de l'attribut :

On utilisera plutôt le snake_case) car certaines BDD ne sont pas sensibles à la casse.

Le domaine de l'attribut : l'ensemble des valeurs qui sont autorisées pour cet attribut. Ces domaines peuvent correspondre à :

des types de données classiques typiques des langages de programmation (integer, caractère, integer positif)... ou
des types plus contraignants : une date, une heure, un email, un n° de téléphone... ou même
des valeurs appartenant à un ensemble précis, par exemple {"EX", "TB", "B", "P", "I", "A"} pour des appréciations

On notera que la plupart des SGBD acceptent la gestion de valeurs par défaut.

Nécessité de NULL

Les données doivent être intègres : on ne doit jamais insérer de données fausses. Comment faire si on ne connaît pas un n° de téléphone par exemple ? Mettre 0.0.0.0.0 serait manifestement une fausse information.

Il existe une valeur spécifique aux BDD : la valeur NULL de SQL qui indique l'ABSCENCE D'INFORMATIONS pour ce champ.

Deux raisons possibles d'avoir NULL

On ne connaît pas de valeur précise pour le moment (date de remise en vente d'un produit en rupture fournisseur pour le moment)
La valeur n'a pas de sens (plaque d'immatriculation pour une personne qui ne possède pas de véhicule par exemple)

NULL peut être choisie comme valeur par défaut pour certains champs. Cela évite de tout remplir dès le départ.

Contraintes d'intégrité de DOMAINE

On impose des CONTRAINTES d'intégrité de DOMAINE qui empêchent d'enregistrer une donnée si elle n'a pas le type attendu : tout ce qui rentre dans le système est analysé AVANT insertion.

Si l'utilisateur veut insérer quelque chose qui n'a pas la forme d'un e-mail, on va refuser l'enregistrement plutôt que de risquer d'insérer une donnée non intègre.

3.2 Domaines disponibles

Voir

Les domaines disponibles changent sensiblement d'un système à un autre (SQLite, Maria DB, Oracle DB...).

SQLite permet d'utiliser facilement SQL sans installer un serveur : SQL Lite.

Dans SQLite, la base de données est en réalité implémentée dans un fichier-texte.

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. Le module Python sqlite3 nous permettra d'interagir en Python avec notre base de données .

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

TEXT pour tout ce qui est caractère.
NUMERIC pour un nombre.
INTEGER pour un nombre entier.
REAL pour un flottant. Attention, il s'agit bien de flottant malgré le nom du type !
BLOB pour le reste : par exemple les images. Cela veut dire qu'on place simplement des octets. C'est un blob, une masse informe d'informations.

La plupart des autres BDD SQL incluent

le type CHAR qui permet de stocker des caractères en nombre limité. Exemple : CHAR(40) pour dire qu'il faut EXACTEMENT 40 caractères.
le type VARCHAR. Exemple : VARCHAR(40) pour dire qu'il faut AU MAXIMUM 40 caractères.
le type DATE qui stocke des dates avec un formatage choisi à la création : AAAA-MM-JJ ou JJ-MM-AAAA ou MM-JJ-AAAA à l'américaine.
le type DATETIME qui stocke une date 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.3 Schéma relationnel : définition formelle d'une relation

Voir

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)

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
1	Flight Simulator	Simulation de pilotage d'avion avec des pixels gros comme des camions !	1980	subLOGIC	Apple 2	Simulateur
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
3	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1982	Activision	Atari 2600	Plate-formes
4	PITFALL!	Pitfall Harry, un explorateur, ramasse des objets éparpillés dans la jungle.	1983	Activision	Commodore 64 (C64)	Plate-formes
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

Correction ?

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

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 ?

...CORRECTION...

3.4 - Contrainte d'UNICITE (clé primaire)

Voir

RAPPEL : 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.

A - Relation vue comme un ensemble

Pour définir un n-uplet (objet), il faut fournir les n informations liées à cet objet dans la relation.

La relation peut être vue comme un ensemble de n-uplets : chaque n-uplet doit donc être différent des autres. Il ne doit pas y avoir deux n-uplets qui auraient exactement les mêmes valeurs.

B - Clé primaire / Primary Key (pk)

La clé primaire est un attribut permettant d’identifier et différencier un n-uplet parmi tous les n-uplets de la relation

Il s'agit le plus souvent d'un attribut de type INTEGER et nommé id qui ne doit apparaître qu'une unique fois dans la colonne et qui doit être défini.

En terme SQL, PRIMARY KEY veut dire donc dire UNIQUE et NOT NULL.

Elle ne peut pas être NULL car ne pas connaître sa valeur empêche de localiser le n-uplet.

La clé primaire peut-être

un attribut (comme un numero_etudiant) ou
l'association de plusieurs attributs (comme (numero_de_sécu, nom, prenom)).

Exemple

salarie(id:int, nom:text, prenom:text, nationalite:text) pour le schéma relationnel
(007, James, Bond, Anglais) pour l'agent secret nommé James Bond.
(008, James, Bond, Anglais) pour le plombier nommé James Bond.

On voit que les deux salariés ne sont pas les mêmes uniquement à l'aide de l'id.

Par contre, lorsqu'un même individu réel apparaît deux fois dans une même table avec deux id différents, on parle de doublon. Et ça, il faut tout faire pour l'éviter.

C - Contrainte d'UNICITE

La contrainte d'UNICITE impose qu'on puisse toujours distinguer deux n-uplets d'une relation.

Le SGBD n'acceptera pas d'insérer un nouvel n-uplet si sa clé primaire correspond à la clé primaire d'un autre n-uplet.

Dans le cadre d'un SGBD, on peut charger le SGBD de choisir automatiquement le nouvel id d'un n-uplet qu'on veut insérer.. Il choisira une valeur ou association de valeurs qui n'existe pas encore.

D - Conventions

On identifie les clés primaires

en les soulignant dans le schéma relationnel de la relation
en plaçant une clé dorée sur l'IHM d'un SGBD
parfois en plaçant le nom de la relation en suffixe (ex id_livre)
en préfixant parfois le nom de l'attribut par pk (ex pk_id_livre)

Exemple du livre

Que prendre comme clé primaire ?

L'attribut titre ne suffit pas : deux livres peuvent porter le même nom.

Le couple (titre, auteur) ne suffit nécessairement : certains livres sortent sous plusieurs éditions.

Si vous voulez faire un site Web donnant des critiques littéraires, sans tenir compte des éditions, cela suffit.

Le triplet (titre, auteur, édition) peut parfois être suffisant.

Si vous voulez faire un site Web donnant des critiques littéraires, cela suffit.

Un système d'identification unique existe déjà : l'ISBN (International Standard Book Number).

Dans un bibliothèque, l'ISBN ou le triplet ne sont pas suffisants : chaque livre réel peut être présent en plusieurs exemplaires dans le stock. En prenant l'ISBN, on ne pourra pas savoir quel livre exactement quelqu'un a loué. Dans ce cas, il faut rajouter un numéro de toutes manières.

Soit le quadruplet (titre, auteur, édition, exemplaire)
Soit un numéro unique à chaque livre réel présent dans le stock.

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 livre (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 :

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

Correction ?

...CORRECTION...

Localiser le p-uplet de la relation jeu_retro dont la clé primaire vaut 10.

Il s'agit de l'avant dernière ligne, le PITFALL ! sorti en 1983.

Quelle est la valeur du champ id_support de ce p-uplet ?

On lit 3 dans le champ de l'atttribut id_support.

Que peut-on en tirer comme informations sur la console de ce jeu ?

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.

Fournir le p-uplet virtuel obtenu en concaténant les attributs de la relation jeu_retro et les attributs de la relation console ?

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

...CORRECTION...

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

Gain en place mémoire puisque l'information sur le C64 n'est plus stocké qu'une unique fois en réalité.
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.

4.1 Contrainte de REFERENCE (clé étrangère, foreign key)

Voir

A - Liaison entre relations

Le système de liaison entre les relations est donc basé sur :

des attributs nommés clés primaires respectant la contrainte d'UNICITE : uniques, ils identifient un n-uplet.
des attributs nommés clés étrangères dont la valeur doit correspondre à la valeur d'une clé primaire d'une relation.

B - Contrainte de REFERENCE

La contrainte de REFERENCE impose que toutes valeurs de clé étrangère doit correspondre à une valeur de clé primaire existante.

Par contre, une clé secondaire peut contenir NULL, cela indiquant qu'on ne sait pas pour l'instant où se trouve l'information voulue.

C - Conventions

On identifie les clés étrangères :

en plaçant un caractère dièse # devant leur nom dans un schéma relationnel
souvent, en préfixant le nom de l'attribut par fk : 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.

Exemple

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.

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 par la première lettre de la relation.

On met même parfois le nom entier.

Nous aurions donc :

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 :

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 :

jeu_retro (
    id_jeu_retro:int,
    jeu:text,
    description:text;
    sortie:date,
    editeur:text,
    fichier_image:blob,
    genre:text,
    #id_console:int
)

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 :

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
)

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 :

le nom de chaque relation
la liste des attributs de chaque relation (nom et domaine)
Indiquer clairement la clé primaire des relations (soulignement ou pk)
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 :

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

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 :

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.

⏪

⏫

⏩