23 - Les Bases de Données

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

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)

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

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.

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)

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.

Une clé primaire ne peut pas valoir NULL car cela indiquerait qu'on ne connait pas la clé primaire de cet enregistrement !

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

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.

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.

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 :

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 :

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 :

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 :