IntroductionLes modèles

Un modèle est un ensemble de concepts permettant de décrire les données, leurs liens, leurs sémantiques, et les contraintes d'intégrité. Il en existe de très nombreux. Certains permettent de bien comprendre le fonctionnement d'une application, et surtout de bien la développer, d'autres se concentrent sur les bases de données.
Parmi tous ces modèles, on en retiendra deux:

  1. Le modèle de type conceptuel: Il se présente sous la forme d'un graphique, utilisé pour l'analyse d'aplpications. Le modèle standard est le modèle entité-association. Les concepts qui y sont traités sont: les entités, les associations (quelle originalité), les spécialisation, les attributs, les identificateurs, ... Cela fera l'objet d'un autre cours, par moi, ou pas!
  2. Le modèle de type logique: Il correspond à une traduction bêtement informatique du modèle conceptuel, et est associé au SGBD que vous utilisez. Le modèle standard est le modèle relationnel. Les concepts qui y sont traités sont: les relations, les attributs, les domaines, les clés, les n-uplets, ...

Comment sont reliés ces modèles qui ont l'ai si palpitants?

Voici deux schémas qui vont vous permettre de comprendre le principe de fonctionnement.


"Regarder, observer, modéliser, avant de développer? Balek je suis une machine moi!"

Bravo, vous êtes de la graine de champion...Tu es fin prêt à travailler dans le monde merveilleux de Pôle Emploi Informatique

Toute application informatique, et donc toute base de données, démarre suivant le même principe. Il faut d'abord lire l'énoncé de ce qu'on a à faire, l'analyser, le concevoir sur papier, puis en dernier lieu, développer.

Partir directement en mode Rambo dans le développement ne vous amènera qu'à une chose, la faillite!

Autre question que l'on peut se poser, et pourquoi pas une seule table?

Ca déjà, c'est une meilleure question. On reviendrait plus ou moins sur le principe d'un tableur. Vous allez me dire "Alors oui il y a de la redondance, mais bon l'informatique maintenant, on peut gérer ce genre de truc, non?", et vous n'auriez pas non plus complètement tort. C'est un peu le concept d'entrepôt de données. Mais ce n'est pas le sujet qui nous intéresse ça, on ne fait pas des entrepôts ici, mais des bases de données.

Prenons un exemple: une table unique pour gérer l'emprunt de bouquins scientifiques. La table ressemblerait à ça.

Et là on se retrouve avec plusieurs problèmes:

  • Un livre peut avoir plusieurs auteurs …. Que faire ?
  • Duplication de données, ex : adresse d'une personne empruntant plusieurs livres.
  • Comment conserver un client qui rend son dernier livre ?

Bilan : Sémantique des données très mal représentée ! (emprunteurs et livres non distincts) ➔ il faut définir plusieurs tables/relations