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
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.
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.
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 !
La vérité ? Toujours via un autre titre lu dans la presse :
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
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)
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
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.
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
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é.
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.
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
capture_ecran
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...
Une relation
Regardons maintenant cette ligne (en rouge) :
id
jeu
description
annee_sortie
editeur
support
genre
visuel
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...
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...
Un attribut
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 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...
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...
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
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
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 Pythonsqlite3 nous permettra d'interagir en Python avec notre base de données .
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
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)
Nous verrons un peu plus loin ce que signifie PRIMARYKEY.
NOTNULL 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
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 :
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.
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...
3.4 - Contrainte d'UNICITE (clé primaire)
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) ?
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 :
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.
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 :
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...
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...
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)
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.
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 :
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)
)