cours v1

Bases de données : étude d'un moteur de Blog
Présentation de la démarche
Ce cours est pour des élèves de BTS IRIS. L'objectif final est de pouvoir lire une structure de base
de données pour pouvoir en extraire des informations par des requêtes.
On va étudier le moteur de blog Dotclear (v1.2.7) qui fonctionne avec PHP et MySQL
téléchargeable ici.
Pour cela, on va faire une analyse à priori de la base de données nécessaire pour une telle
application :
• définition du cahier des charges (point de vue utilisateur)
• schéma conceptuel
• schéma logique relationnel
Ensuite, nous étudierons à posteriori la base de données de Dotclear et analyserons les différences
avec notre schéma logique.
Cahier des charges
Ce cahier des charges est à définir collectivement au cours d'un TD.
Un blog est un type de site web composé d'articles (posts) accessibles chacun séparément par une
URL (Unique Ressource Location).
Chaque post a un titre, une date d'édition, une date de publication, un auteur, un corps. Les articles
sont référencés dans des catégories (il faudra étudier le besoin d'avoir une ou plusieurs catégories
par article, cela interviendra dans les différents schémas). Le clic sur une catégorie permet de lister
tous les articles de cette catégorie.
Plusieurs personnes peuvent publier sur le même blog avec des permissions différentes
(administrateur, rédacteur), L'identification d'un utilisateur se fera par login et mot de passe.
Tout lecteur peut réagir à un article en ajoutant un commentaire (composé de titre, date, auteur,
corps, adresse du site de l'auteur, mail de l'auteur).
Un lecteur intéressé par un article de votre blog peut le citer sur son blog et indiquer ce lien sur
votre blog (comme ça les autres lecteurs peuvent aller voir les sites qui parlent de ce post) : c'est un
trackback (composé de titre, date, auteur, corps, URL de l'article distant).
Enfin, on souhaite pouvoir avoir sur notre blog une liste de liens vers les sites que l'on aime et que
l'on veut faire partager à nos lecteurs (ça s'appelle un blogroll).
Quelques questions n'ont pas encore de réponses :
Faut-il gérer plusieurs blogs dans la même base de données ?
Plusieurs personnes (enregistrées) peuvent-elle contribuer au même article ? (= un article peut-il
avoir plusieurs auteurs ?)
Un article peut-il appartenir à plusieurs catégories ?
Il faudra étudier attentivement ces questions lors de la conception de nos schémas.
Schéma conceptuel
Vocabulaire
Ce schéma met en relation les différentes entités identifiées. Il est indépendant de tout système
informatique et prévu pour traduire le cahier des charges dans un formalisme graphique
compréhensible par le client et le développeur.
Une entité est définie comme un objet clairement identifiable qui peut être concret (livre, personne,
…) ou abstrait (compte en banque). Elle est décrite par des attributs (caractéristiques ou propriétés)
parmi lesquelles on définit un identifiant composé d'un ou plusieurs attributs (qui lèvera toute
ambiguïté sur les différents enregistrements) par exemple, un numéro INSEE identifie de manière
unique une personne française.
Une relation représente les liens présents entre les différentes entités. Les relations n'ont pas
d'existence propre. Une relation peut concerner une ou plusieurs entités (s'il n'y a qu'une entité, la
relation est dite réflexive par exemple la relation Mariage sur une table Personne est réflexive). Le
nombre d'entité entrant dans une relation s'appelle la dimension de cette relation. (une relation de
dimension deux est binaire, de dimension 3 est ternaire, …)
On appelle cardinalité le nombre de participation d'une entité à une relation.
Si l'on considère la relation entre une facture et un produit, les différentes cardinalités correspondent
au cas suivant :
1 – 1 : On ne peut indiquer qu'un produit par facture (pas très pratique), on ne peut plus facturer le
produit après la première facture (toujours pas pratique)
1 – N : On peut avoir plusieurs lignes par facture, mais on est toujours limiter à une facture par
produit ou inversement
M – N : On a plusieurs lignes par facture et un produit peut être facturé plusieurs fois.
Démarche pour construire un schéma conceptuel
Déterminer la liste des entités
Pour toutes les entités, définir la liste des attributs puis déterminer l'identifiant
Déterminer les relations entre les entités
Pour chaque relation, définir les attributs propres à la relation (date, prix, … par exemple),
vérifier la dimension et définir la cardinalité.
e) Valider le schéma auprès des utilisateurs
C'est cette démarche que nous allons suivre pour construire notre schéma. Nous auto-validerons
notre schéma puisque nous sommes les utilisateurs de blogs…
Sauf exception, un schéma conceptuel ne doit pas d'information redondante (par exemple, attributs
calculables à partir d'autres attributs dans la base, transitivité, …).
a)
b)
c)
d)
Un même cahier des charges peut conduire à plusieurs schémas conceptuels différents.
Application pour le blog
Dans un premier temps, on répond NON aux 3 questions qui n'ont pas de réponse.
Liste des entités
Post, categorie, lien, utilisateur, commentaire, trackback
Liste des attributs des entités
A partir du cahier des charges, voici un premier jet de liste des entités :
post (titre, date_edit, date_pub, corps, auteur, categorie)
categorie (nom, URL)
lien (nom, URL)
utilisateur (login, mdp, permission)
commentaire (titre, date, auteur, corps, URL_site, mail_auteur)
trackback (titre, date, auteur, corps, URL_distant)
Quels sont les identifiants possibles ? Pour chaque entité, il va falloir rajouter un attribut qui
contiendra un entier qu'il faudra incrémenter à chaque enregistrement et qui assurera l'unicité des
enregistrements.
On peut considérer que le nom du lien peut être utilisé comme identifiant, (on ne rajoute pas
d'attribut à cette entité)
La liste attributs des entités est donc comme suit :
post (id_post, titre, date_edit, date_pub, corps, auteur, categorie)
categorie (id_cat, nom, URL)
lien (nom, URL)
utilisateur (id_user, login, mdp, permission)
commentaire (id_comm, titre, date, auteur, corps, URL_site, mail_auteur)
trackback (id_tb, titre, date, auteur, corps, URL_dist)
Une question se pose : l'auteur et la catégorie d'un post sont-ils des attributs du post ou des relation
entre les entités ?
Les relations entre entités
lien
categorie
post
0-N
id_cat nom
URL
appartient à
1-1
1-1
utilisateur
id_user
login mdp
permission
nom URL
id_post
titre
date_edit
date_pub
corps
auteur
categorie
0-N
cite
0-N
écrit
1-1
trackback
réagit à
0-N
id_tb titre
date corps
auteur
URL_dist
1-1
commentaire
id_comm titre
date corps
auteur
URL_site
mail_auteur
On constate que la table lien n'est en relation avec aucune autre table (ce qui n'est pas étonnant
puisque c'est un module indépendant de notre blog)
Les noms des relations sont discutables, l'essentiel est dans le repérage de ces relations ainsi que des
attributs qui en font parti.
On, constate que l'attribut categorie de post correspond plus à la relation appartient à qu'à l'entité.
De même, l'attribut auteur correspond à la relation écrit. (l'auteur d'un post est l'utilisateur qui l'a
écrit). On peut aussi se poser des questions sur la date d'un post, commentaire ou trackback,
dépend-elle de l'entité ou de la relation ? On aurait même pu définir la date comme une entité
indépendante. Vous avez ci-après les représentations de la relation réagit à pour ces deux cas de
figure.
post
id_post
titre
date_edit
date_pub
corps
réagit à
date
commentaire
post
id_comm titre
corps auteur
URL_site
mail_auteur
id_post
titre
date_edit
date_pub
corps
réagit à
date
commentaire
id_comm
titre corps
auteur
URL_site
mail_auteur
Ces deux schémas sont envisageables, j'ai choisi de laisser la date comme un attribut des entités,
cela peut être discutable, mais ne change pas grand chose pour la suite des opérations.
Il nous faut donc revoir notre liste des attributs des entités comme suit :
post (id_post, titre, date_edit, date_pub, corps)
categorie (id_cat, nom, URL)
lien (nom, URL)
utilisateur (id_user, login, mdp, permission)
commentaire (id_comm, titre, date, auteur, corps, URL_site, mail_auteur)
trackback (id_tb, titre, date, auteur, corps, URL_dist)
relations : attributs, dimensions, cardinalités
Toutes les relations sont dépourvues d'attribut propre.
cite : relie trackback à post, elle est binaire et de cardinalité 1 – N, un post peut avoir plusieurs
trackbacks.
réagit à : relie commentaire à post, elle est binaire et de cardinalité 1 – N, un post peut avoir
plusieurs commentaires.
appartient à : relie post à categorie, elle est binaire et de cardinalité 1 – N, une categorie peut
contenir plusieurs posts. Elle devient de cardinalité M – N, si l'on souhaite qu'un post puisse
appartenir à plusieurs catégories.
écrit : relie post à utilisateur, elle est binaire et de cardinalité 1 – N, un utilisateur peut écrire
plusieurs posts. Elle devient de cardinalité M – N, si l'on souhaite qu'un post puisse avoir plusieurs
auteurs.
Schéma logique relationnel
Pour l'instant, on a fait un schéma joli, intéressant, qui permet de bien comprendre les interactions
entité–relation. Cela n'est pas encore un schéma logique de base de données. Le schéma logique va
nous définir les tables que nous allons trouver dans notre base.
Passage du schéma conceptuel au schéma relationnel
Les règles simples pour passer du schéma conceptuel au schéma logique sont les suivantes.
Entités
Une entité est traduite en une table dont :
• le nom est le nom de l'entité,
• les colonnes sont les attributs de l'entité,
• la clé est l'identifiant de l'entité.
On passe donc de (entité, attribut, identifiant) à (table, colonne, clé primaire).
Si une table n'a qu'une colonne, elle est supprimée (la colonne de vient un attribut d'une des entités
avec lesquelles elle est en relation).
Relations
Une relation de cardinalité M – N est traduite par une table dont :
• le nom est le nom de la relation,
• les clés primaires des entités qui participent à la relation sont reportées comme colonnes de
la table,
• les attributs spécifiques de la relation sont les autres colonnes de la table.
Une relation de cardinalité 1 – N est traduite par :
• Un report de clé de la table côté N dans la table côté 1. (on rajoute une (ou plusieurs)
colonne(s) dans la table côté 1 correspondant à la clé primaire de la table côté N).
• Une table spécifique lorsque la relation a des attributs propres. La clé de la tables est
l'identifiant de l'entité côté 1.
Une relation de cardinalité 1 – 1 est généralement traduite par une fusion des tables qu'elle relie
(quand c'est une bijection). Dans certains cas particuliers, on peut préférer avoir une table pour la
relation ou faire un report de colonne comme pour les autres cardinalités.