Aperçu des sections

  • Généralités

    Tout replier Tout déplier
    Cours sur la conception de modèles de données relationnels.

    Outils :
    https://app.diagrams.net/ (propose les symboles base de données)
    https://www.holistics.io/blog/top-5-free-database-diagram-design-tools/
    Mocodo : https://www.mocodo.net/

    Note : ce cours peut aussi être fait via les diagramme de classe en UML (https://webboy.fr/formation/course/view.php?id=164#section-1)

  • Modèle relationnel de données

    => cours à revoir

    La raison pour laquelle on utilise un logiciel dédié au stockage de nos données, au lieu de simples fichiers, c'est que l'on va pouvoir "configurer" l’organisation de l'information, et contraindre celle-ci à respecter un modèle qui répond au besoin de notre application. Pour faire simple, on va déterminer en amont différentes règles dans notre base de données, et si ces règles ne sont pas respectées, alors le SGBDR renverra une erreur, et refusera de faire une action interdite. 

    Ceci est très important, car cela va contraindre le développeur à suivre une logique imposée et - à priori - infaillible (car vérifiée par une machine). Je dis bien a priori, car si vous ne définissez pas les bonnes contraintes, alors le SGBDR acceptera de stocker de l'information de manière désorganisée, et vous devrez alors écrire ces règles directement en ligne de code, ce qui est bien plus fastidieux, dangereux, et propice à l'erreur humaine.


    Imaginez que vous travaillez sur une application qui doit localiser des utilisateurs géographiquement, selon les critères suivant :

    • un utilisateur à un nom
    • chaque ville, région et pays ont un nom
    • un utilisateur est rattaché obligatoirement à une ville, une région et un pays
    • une ville est rattachée à une région
    • une région est rattaché à un pays


    Voici un exemple de modélisation de ces règles de conception :


    Ceci est ce que l'on appelle un modèle conceptuel de données (MCD). C'est une façon schématique de représenter l'organisation des informations au sein de notre base de données. Ce type de diagramme doit théoriquement répondre à une certaines nomenclatures (symboles, représentations, etc...), mais l'idée générale est de poser sur papier les contraintes qui régissent notre BDD.

    Ici chaque rectangle représente une table. Et chaque table est reliée par ce que l'on appelle des "cardinalités" (ou contraintes).

    Exemple :

    • Un utilisateur doit être rattaché à une ville
    • Une ville doit être rattaché à une région
    • etc...


    Si par exemple, je créé un nouvel utilisateur, et que je lui donne une ville qui n'existe pas dans ma table "cities", alors le SGBDR refusera d'inscrire le nouvel utilisateur, car il ne trouvera pas la ville en question. Logique. En revanche, je peux tout a fait créer une ville qui ne recense aucun utilisateur. Logique aussi. 

    Et on peux aller très loin dans ce raisonnement. Plus notre application hébergera d'informations, plus le nombre de table sera élevé, et les liens entre chaque entités seront nombreux.

    Voici un exemple un peu plus étoffé. Dites moi en un coup d’œil quel type de service le développeur est entrain de mettre en place, et quelles sont, en gros, les différentes entités et leur liens :



    Note : la façon dont les données sont représentées ici correspond à une méthode un peu vieillissante : la méthode Merise. Aujourd'hui on utilisera d'autres méthodes qui donnent des diagrammes légèrement différents, et qui englobent la logique en même temps que les données (tel que UML). Mais l'exemple tiens toujours pour découvrir les choses pas à pas.


    Les exemples que nous venons de voir sont simples. Mais au fur et à mesure du développement d'une application, on peux très vite se retrouver avec de très nombreuse tables et contraintes :





    Ne vous inquiétez pas, cela se fait souvent progressivement, et quand on travaille sur une grosse base de données, il faut un temps minimum d'adaptation pour s'imprégner de l’organisation des données.

    Certains GUI, tels que les versions récentes de phpMyAdmin, ou bien MySQL Workbench, permettent de vous générer automatiquement ce genre de diagrammes, selon le contenu de votre DB. Ceci est très pratique, car cela permet d'avoir un rendu visuel, bien pratique lorsque l'on se demande ou aller chercher les informations.

  • Modèle conceptuel de données (MCD)

    Déterminer les entités de base

    Établir les relations entre elles, en respectant les cardinalités

    Créer les entités de liaisons avec leurs données respectives



    Section en cours d'élaboration, voir document ci-dessous pour plus de détails.

  • Modèle logique de données (MLD)

    Sur la base des entités du MCD, déduire les clés primaires et les clés étrangères en prenant bien en compte les cardinalités, et en fusionnant certaines entités si nécessaire.

    Déduire les tables et colonnes de la DB selon l'étape précédente




  • Modèle physique de données (MPD)

    Déterminer tous les types de champs avec exactitude pour chaque table

    Implémenter le MLD dans une base de données, sans oublier les contraintes de clé étrangère

    Prendre en compte les contraintes du SGBDR ou du code pour mettre en place des optimisations ou des ajustements si nécessaire.

  • TP