Plan du cours:

La structuration des données:

• Généralités sur les SGBD: page 1
• TD sur le modele relationnel: page 2
• TD sur le modele relationnel, entité-relation: page 3
• TP sur la creation d’une BDD cinéma, utilisant un SGBD (Base de LibreOffice)
• TP sur la gestion d’une base de données de romans de sciences fiction, utilisant SQLite Browser : page 4

Le langage de requêtes:

• TD en ligne sur une base de données de prenoms: [Lien] (https://e-nsi.forge.aeif.fr/exercices_bdd/31_prenoms/prenoms/)"> vers le site e-nsi.forge.aeif.fr
• TP sur le langage SQL avec des requetes sur une base de données d'exoplanetes: bas de la page 5
• TP sur le langage SQL avec plusieurs tables et jointures: une enquete de police: page 5
• TP sur la creation d’un serveur avec gestion d’un formulaire en python/SQL: page 6

Structurer les données

Exemple:

Voici plusieurs informations: M Dupont, un policier, uniforme noir et chapeau rond, le capitaine Hadock fume une pipe, c’est un marin et il porte une casquette de marin; Tintin est journaliste, habillé avec une chemise.

Il existe une relation entre ces informations. Chacune se réfère à un individu et le décrit avec les mêmes descripteurs. On peut les rassembler en un tableau de données.

Ces personnages prennent vie dans certains des albums de la collection Tintin. Chaque album a une date de parution, un auteur, un editeur.

On peut rassembler ces autres informations dans un nouveau tableau. Il existe alors une association entre ces 2 tableaux: l’association est présent dans l’album.

Des relations de ce genre définissent des structures.

Schéma relationnel en une seul table

Avec un tableau simple, comme ceux manipulés par un tableur, on peut avoir la représentation suivante pour ce que l’on appelle une relation:

Une relation est donc une table. Cette table possède un en-tête, constitué des attributs Titre, Annee, NomMES, PrenomMES, AnneeNaiss. La table contient des n-uplets, comme par exemple: Hana-bi, 1997, Kitano, Takeshi, 1947.

Cette table respecte 2 règles importantes pour la création et la modification d’une base de données:

• chaque entrée (ligne ou n-uplet) du tableau renseigne bien tous les attributs, et respecte bien le domaine de cet attribut (voir plus loin).
• la table ne contient pas deux n-uplets identiques.

Q1. On voudrait insérer les lignes suivantes dans la table. Laquelle de ces lignes présenterait une anomalie d’insertion?

ligne 1
(Alive, 2003, Kitamura, Ryûhei, 1969)
ligne 2
(Alive, 2004, Berthe, Frederic, 1967)

Q2. Une erreur s’est glissée dans le tableau: Alfred Hitchcock est né en 1899 et non 1898. Vous le corrigez dans la ligne Vertigo. Est-ce que la table est complètement mise à jour?

Q3. Vous supprimez les lignes de Volver et Parle avec elle. Pouvez vous alors retrouver la date de naissance de Pedro Almodovar?

Anomalies dans une base de données

La première règle est l’UNICITE des (n-uplets) dans chaque table.

• Anomalie d’insertion: Rien n’empêche dans la gestion d’une table par un tableur de faire plusieurs entrées pour le même film. Il pourrait alors y avoir une répétition des données. Il peut aussi y avoir des valeurs non renseignées, ce qui présente aussi une anomalie d’insertion.

La base de données en une seule table présente plusieurs problèmes de redondance, ce qui va entrainer d’autres anomalies.

• Anomalie de modification: La tenue d’une table de ce type peut entrainer des problèmes lors de la modification: Par exemple, la modification de l’année de naissance d’Hitchcock pour Vertigo et pas pour Psychose entraîne des informations incohérentes. Ou alors il faudrait modifier la table à plusieurs endroits, ce qui n’est pas réaliste si celle-ci est très grande…

• Anomalie de suppression: On ne peut pas supprimer un film sans supprimer son metteur en scène, … et les informations sur celui-ci.

La redondance d’informations dans une table va entrainer des anomalies de modification, et de suppression. Cela va entrainer un coût d’espace et des preformances moindres de la base de données.

• Mais alors, comment faire pour corriger ces problèmes? … L’idée est de travailler avec 2 relations au lieu d’une seule et créer un lien entre ces 2 relations.

Deux tables ou plus: La bonne méthode

La base de données doit:

1. être capable de représenter individuellement les films et les réalisateurs, de manière à ce qu’une action sur l’un n’entraîne pas systématiquement une action sur l’autre,
2. définir une méthode d’identification d’un film ou d’un réalisateur, qui permette d’assurer que la même information est représentée une seule fois. On utilisera pour chaque table une clé primaire.
3. préserver le lien entre les films et les réalisateurs mais sans introduire de redondance.

Pour notre exemple, les deux tables s’appeleront Films et Réalisateurs.

Ensuite, il faudra décider si deux films différents, ou deux réalisateurs différents peuvent avoir ou non le même nom.

Il semblerait qu’il y ait des homonymes dans les titres de film, ainsi que dans les noms propres de réalisateurs. On va devoir créer un identifiant unique pour les entrées de chaque table.

Première proposition

On sépare les données en 2 tables. On placera un index numérique à la première colonne, qui fournira un identifiant unique.

Films

Réalisateur:

A faire: Compléter la première table avec les valeurs correspondantes pour id_rea.

Q4. L’association entre les informations des 2 tables est-elle toujours aussi explicite qu’avec une seule table?

Q5. Vérifier enfin que la base de données produite ne présente plus aucune des anomalies citées plus haut.

Deuxième proposition

Films

Réalisateur:

L’association entre ces 2 tables est assurée par une nouvelle table FilmsRéalisés:

FilmsRéalisés (à compléter)

Ces deux descriptions suivent le modèle entité-association. Mais la manière avec laquelle cette association est représentée est différente.

Q6. Expliquer quelle est cette différence.

Suite du cours

• retour sur la page SGBD
• page suivante : concevoir une base de données relationnelles