Livre : Bases de données – de la modélisation au SQL

Bases de données - de la modélisation au SQL Enseignant à l’institut universitaire de technologie de l’Université de Paris 13, lorsque le cours de Bases de données m’a été confié, j’ai dû rechercher dans la volumineuse bibliographie sur les Bases de données un support de cours adéquat. Les ouvrages traitant correctement de la conception des bases de données, en utilisant le modèle entités-associations, ne sont pas si nombreux et datent souvent de l’époque Merise. En plus de la conception, je souhaitais aborder l’algèbre relationnelle, puis le langage SQL et enfin les déclencheurs. Chacune de ces parties devait être ponctuée de séances d’exercices sous forme de travaux dirigés ou de travaux pratiques. J’ai donc entrepris la rédaction d’un support de cours sur mesure, qui, de révision en révision, est devenu cet ouvrage édité dans la collection Info+ des éditions Ellipses sous le titre Bases de données – de la modélisation au SQL. Ce livre de 255 pages est composé de 5 chapitres décrits ci-dessous.
  1. Introduction aux bases de données – L’objectif de ce court chapitre est d’introduire la problématique des bases de données : définition de la notion de bases de données, principaux modèles de bases de données, systèmes de gestion de bases de données (SGBD).
  2. Conception des bases de données : le modèle entités-associations – Ce chapitre explique comment bien concevoir une base de données. Après une description des éléments constitutifs du modèle entités-associations, la notion de type-association est détaillée, puis un éventail méthodologique des règles qu’il est utile d’appliquer pour l’obtention d’un modèle bien formé est ensuite présenté. La problématique de la normalisation des type-entités et des type-associations est ensuite abordée avant de discuter de l’adéquation des type-associations n-aires.
  3. Modèle de données relationnel – Ce chapitre commence par une présentation du modèle relationnel, puis décrit le moyen de passer d’un modèle entités-associations à un modèle relationnel. La théorie de la normalisation, qui constitue un précieux outil pour débusquer la redondance dans les bases de données, est ensuite présentée en détail. Le chapitre aborde enfin l’algèbre relationnelle qui constitue le formalisme support du langage de requête de SQL.
  4. Langage SQL – Ce chapitre est entièrement consacré au langage SQL qui est considéré comme le langage d’accès normalisé aux bases de données relationnelles. La création et la manipulation de la structure de la base de données sont traitées en premier. Les commandes SQL d’insertion, de suppression et de modification des données sont ensuite abordées. Puis, deux sections sont entièrement consacrées à la commande d’interrogation d’une base de données. La dernière section s’intéresse à la description de quelques objets particuliers.
  5. Programmation SQL – L’objet de ce chapitre est de présenter comment combiner des commandes élémentaires SQL avec un langage de programmation. Le premier objectif est l’implémentation de fonctionnalités complexes au niveau du SGBD grâce aux fonctions utilisateur. Ces fonctions sont ensuite utilisées pour implémenter des comportements complexes et dynamiques en utilisant le mécanisme des déclencheurs, rendant ainsi la base de données active.
    Le second objectif est l’interaction entre un programme et un SGBD abordé en décrivant comment intégrer des commandes SQL à un programme écrit en langage C.
Ce livre, comportant de nombreux exercices corrigés, s’adresse à toute personne désirant se former à la problématique des bases de données.
Cette entrée a été publiée dans Livres, Cours. Placez un signet sur le permalien.

27 Responses to Livre : Bases de données – de la modélisation au SQL

  1. Anonymous dit :

    le cours a l'air intéressant.mais comment avoir accès???
    Il peut bien nous aider.Si on peut l'avoir en format pdf, cela nous arrangerait.

  2. romarno1 dit :

    Bonjour,

    Quel logiciel utilisez-vous pour dessiner le modèle entités-associations ?

  3. Nerea dit :

    Bonjour,

    Existe-t-il un errata de ce livre SVP ?

    • Laurent dit :

      Non, mais je modifie au fur et à mesure ma version de travail.
      Si vous avez une question ou un doute, n’hésitez pas à m’en faire part.

      • Nerea dit :

        Quand on a un doute, c’est qu’on s’est aperçu de quelque chose. Le problème est plutôt quand on ne voit rien…
        L’édition que je possède est celle de septembre 2011, et il y a quelques coquilles (je ne les ai pas noté au fur et à mesure).
        Par contre j’ai une petite remarque sur la correction des exercices de la partie modèle entités-associations (TD 2.7) : Les modèles sont donnés sans aucune explication. Il m’aurait semblé utile d’en avoir au moins pour certains type-entités ou types-associations (les moins évidents).
        Pour le reste, je trouve ce livre très pédagogique.

        • Laurent dit :

          Je vous remercie pour ces commentaires constructifs.
          J’espère trouver le temps de me replonger dans la rédaction de cet ouvrage pour corriger certaines erreurs et apporter des explications aux solutions proposées.

  4. Arnaud dit :

    Bonjour,
    Le type-entité FOURNISSEUR de la figure 2.51 illustrant la troisième forme normale est-il vraiment en 3FN ?
    Si l’attribut adresseFournisseur dépend de l’attribut nomFournisseur, alors on a un attribut n’appartenant pas à la clé qui dépend d’un attribut non-clé. Non ??

    • Laurent dit :

      Bonjour,
      Si l’attribut adresseFournisseur dépend de l’attribut nomFournisseur, alors l’attribut nomFournisseur est une clé candidate et le type-entité FOURNISSER est bien en 3FN. Il possède deux clés candidates : nomFournisseur et idPersonne. idPersonne est la clé choisie comme clé primaire.
      Par contre, dans le type-entitié ARTICLE, l’attribut nomFournisseur n’est pas une clé candidate. Le type-entitié ARTICLE n’est donc pas en 3FN.

  5. patrick van male dit :

    Bravo pour votre ouvrage « Bases de données »: en quelques pages j’ai pu comprendre l’explication éthymologique et surtout le principe des bases de données relationnelle, alors que j’avais déjà lu plusieurs autres documents traitant du sujet.
    Je trouve votre ouvrage très pédagogique.
    Grand merci de l’avoir écrit.

    Si vous rééditez cet ouvrage, pourriez-vous corriger la numérotation de tous les titres, erronée (Le chapitre nommé dans le sommaire « 1.2.1 Historique » (par exemple) est en réalité le chapitre « 2.1. Historique » dans le livre)

    Patrick

  6. patrick van male dit :

    dans mon commentaire précédent, j’ai mal identifié et mal décrit l’erreur de numérotation des chapitres:
    le sommaire fait une erreur uniquement pour la section 1.2. »modèles de bases de données » page 11, ce titre devant être plus haut gradé. La conséquence est une erreur dans la fin du §1 page 12 quand vous renvoyez à la section « 1.2.4 ».
    N’hésitez pas à corriger mon commentaire précédent, erroné, avant de le publier.

    Patrick

    • Laurent dit :

      En fait il n’y a pas d’erreur mais une façon de numéroter maladroite (et à corriger).
      En dehors de la table des matières, les numéros de chapitre n’apparaissent pas dans la numérotation des sections, mais apparaissent dans les références. Ainsi, la référence à la section 1.2.4 est la section 2.4 du chapitre 1.

  7. Jean Luc Ravenne dit :

    Bonjour Laurent…

    Question (de paresseux..)

    Merci pour la qualité de l’ouvrage
    mais…..
    Avez vous les exos (pas forcement les solutions ) sous une forme numérique ?
    trés cordialement
    JL

  8. Laurent dit :

    L’adresse indiquée page 123 (fichiers des tables pour les TPs) n’est plus valide.
    La nouvelle adresse est : http://lipn.univ-paris13.fr/~audibert/bd/cinema_tables.zip

  9. Alexandre Courvoisier dit :

    Bonjour Monsieur Audibert,

    Après trois ans d’avoir appris l’informatique – au travers de laquelle je me suis passionné pour les neuf formes normales notamment – j’ai lu la version ouverte de votre cours en bases de données… du Pain Bénit !

    Je dois dire qu’en première lecture, j’ai dû m’accrocher. Après une deuxième lecture rapide des deux premiers chapitres, j’ai compris – ou au moins crû comprendre.

    Question 1.1:
    Le modèle Entités-Associations, c’est bien un modèle qui a pour cas particulier le Modèle Conceptuel de Données, ou je me trompe ? Je pose cette question, parce que d’après ce dont je me souviens, les règles y applicables le seraient aussi au MCD (Merise).

    Question 1.2:
    Et les règles applicables au modèle relationnel, on peut les garder pour le Modèle Logique de Donnée de Merise ?

    Question 2.1 (optionnelle) [edit: j’ai laissé la question mais vous y répondez en disant que la version en ligne est l’ébauche]:
    Il m’a semblé voir une ou deux fautes de frappes, bénignes, dans toute la somme que vous avez écrite (à moins que cela n’incombe à ma lecture), ce qui m’amène à la question suivante:
    Est-ce que votre cours en version livre (p. ex.: sur Amazon) serait une version agrémentée (éventuellement en termes de paragraphes ou exercices complémentaires), ou est-il identique à la version on-line (auquel premier cas cela m’intéresserait de l’acheter) ?

    -J’ai élaboré un modeste tutoriel, de 45 pages, sur les neuf formes normales. Mon mérite est modeste, vu qu’il condense entre autres certains exemples et contre-exemples de Wikipedia reformulés en des mots que j’ai estimés plus justes. Une forme a nécessité l’autorisation d’une mathématicienne qui l’a illustrée d’un contre-exemple, enfin la dernière est le fruit de ma lecture de C.J. Date.
    Question 3.1:
    Une fois une première correction orthographique appliquée, seriez-vous ouvert à en faire la relecture en avant-première avant toute distribution ? J’en serais ravi. Quelque chose me dit que vous êtes très occupé, mais ne sait-on jamais.

    En vous remerciant d’avance pour vos réponses à mes questions, je vous souhaite, Monsieur Audibert, une bonne année 2014.

    • Laurent dit :

      Q 1.1 & 1.2 Je ne suis pas un expert en Merise. Ma formation est poste Merise et je ne me suis pas trop intéressé à cette Méthode. Le modèle EA existait avant Merise et a été repris par Merise pour son niveau MCD. Donc réponse oui pour 1.1. Oui pour 1.2 également il me semble.

      Q 2.1 : Ce billet (http://gurau-audibert.hd.free.fr/josdblog/2009/09/nouvelles-du-cours-bases-de-donnees-et-langage-sql/) détaille les différences entre la version en ligne et le livre. Les deux versions sont donc très différentes. La version en ligne est bien une ébauche.

      Q 3.1 : Effectivement, je suis très occupé, surtout avec deux enfants en bas âge. Je ne suis donc pas certain de pouvoir en faire une relecture approfondi, mais je peux y jeter un œil. Le meilleur tutoriel que j’ai trouvé sur la normalisation est celui-ci : http://fsmrel.developpez.com/basesrelationnelles/normalisation/

      Meilleurs vœux également pour cette année 2014

      • Alexandre Courvoisier dit :

        Merci Monsieur Audibert pour vos précieuses réponses.

        Oserais-je donc vous demander un courriel mentionnant simplement « Coup d’oeil pour les formes normales », à l’adresse que j’ai renseignée sur votre site, si le fait de jeter un petit coup d’oeil est toujours possible pour vous ? Car je ne vois pas d’autre moyen de vous transmettre cela.

        -J’ai découvert très récemment le tutoriel de Monsieur de Sainte Marie (pour donner une idée, cela faisait trois ans que je me passionnais pour le sujet avant de découvrir ceci), qui m’a permis et même demandé de le citer nommément au cas où j’avais besoin de quelque passage de son document. Il se trouve que je n’ai trouvé la définition de 1NF que dans son document.

        Pour le reste, Monsieur de Sainte Marie avait aussi l’air assez occupé. J’ai essayé dans un (bref) échange de lui transmettre progressivement ma vision de la chose. Mais j’ai vu assez vite que fsmrel avait certaines limites – de temps – ne permettant pas une coopération approfondie. En d’autres termes, qu’il n’allait plus « corriger » (selon moi) son tutoriel.

        Notamment, j’ai eu un doute sur la probité de commencer par une forme normale avancée (je crois que cela débute par BCNF qui ne requiert pas les précédentes, alors qu’on pourrait exposer directement 6NF).

        En outre, dans mon document, je mets en question le terme même de normalisation. Car celui-ci ne dit rien sur le stade de forme normale obtenu ou recherché. D’après ce que j’ai retenu de ma lecture de Date et al., la seule forme qui normalise stricto sensu une base est 6NF. Sachant que 5NF et D/KNF nous exposent toujours à des pertes de données (ce pourquoi la 6NF a été énoncée), le terme normalisation utilisé pour mener à tout stade antérieur serait un abus de langage.

        De plus, ce terme ne dit qualitativement rien du procédé. Dans une approche quelque peu scolastique (i.e.: ne prenant pas en compte une base existante mais partant de la conception), j’explique comment cet abus de langage peut être simplement et bénéfiquement remplacé par le terme pourtant connu de projection. (La seule exception serait 5NF, qui peut comprendre des jointures (ce qui n’est toutefois pas obligatoire) à certaines conditions.)

        Il y a aussi sur Wikipedia la notion d' »attributs constants » pour 1NF qui ne dérivent pas la définition, qui – elle – invoque des attributs élémentaires. Même si on voit ce que Wikipedia veut dire, la notion d’attributs constants serait une lapalissade au sens qu’une donnée ne saurait par définition être autre chose que constante.

        Enfin, dérivant de ma remarque sur le terme de normalisation, il y a la normalisation par restriction-union (dont vous évoquiez dans votre document que vous ne l’exposeriez pas et je crois que vous avez eu par là une grande intuition). Non seulement je n’ai pas trouvé de fondement à cette notion, mais il apparaît n’exister aucune forme normale invoquant la restriction ou l’union.

        Voilà, je ne m’étalerai pas plus sur mon travail ici. C’était uniquement pour vous donner un aperçu.

        En vous remerciant d’avance de m’informer (par courriel ou autre moyen pour que je vous le transmette) si vous êtes toujours intéressé à y jeter un coup d’oeil, je vous remercie aussi pour votre précédente et sympathique réponse.

  10. Alexandre Courvoisier dit :

    N.B.: Monsieur Audibert, je souhaite apporter une précision.
    J’ai réfléchi à ma réponse et à celle que vous pouviez me faire. La normalisation ne dit pas exactement « rien » du procédé. À mon sens, s’il y a lieu d’évoquer le terme de normalisation, cela serait avant tout par la projection comme je l’ai déjà entendu; mais les autres opérations élémentaires (sur une base quelconque a priori) seraient aléatoires. J’en déduis que le terme de normalisation partant de là jusqu’à on-ne-sait où, est un terme mal défini, et donc… non-normalisé (et donc serait un terme indû).

    Ceci précisé, je crois que vous avez évoqué la « normalisation par restriction-union » avant même de mentionner que vous ne l’exposeriez pas en ces termes. À mon sens, il s’agit de la factorisation d’entités dérivées (d’une entité générique), en cette entité générique (dentiste & chirurgien –> médecin, pour reprendre votre exemple). Maintenant, je me dis que cette factorisation doit obligatoirement – être accompagnée de la séparation de la fonction (que vous appelez, si je ne m’abuse, type énuméré) – être impliquée par la définition d’un(e) (stade de) forme normale.*

    (En fait je crois à la capacité de l’intuition, par exemple en chimie, mais j’ai un doute sur sa capacité à faire acquérir un stade avancé de forme normale à un ensemble de données, même si vous évoquez dans votre cours qu’il y a des cas où l’intuition dépasse le formalisme. Je n’en suis pas sûr, parce je pense que la suite d’opérations menées en vue d’acquérir une forme normale, si la suite est faite au feeling, aura « la solidité de son opération la moins profonde » (par exemple: une partie non normalisée du tout, alors qu’un autre sous-ensemble d’entités semblent respecter une certaine forme normale). Ca a l’air d’être un simple point de vue sur un ensemble (de données) a priori quelconque, mais je pense qu’il serait plus sûr de s’imposer les définitions des formes normales pour cadre, et de ne garder le feeling qu’en vue d’agir pour se tenir à (la plus avancée de) celles-ci.)

    *Donc là où je voulais en venir, c’est que la factorisation – et la séparation des types énumérés – que j’ai ma foi parfois négligés avant de connaître votre précieux ouvrage et avant d’étudier les formes normales, qui m’apparaissent maintenant essentielles, devraient obligatoirement être impliquées par une forme normale. Mais de mémoire je suis en peine de dire laquelle. Je pense que la factorisation et la séparation des types énumérés sont impliqués par la 4NF, pour la raison que 4NF conditionne les multivaluations.

    Enfin, je me souviens que Wikipedia donne à BCNF la propriété d’attributs indépendants (les uns des autres), mais à cause de la condition sur les mutlivaluations, je pense que l’indépendance des attributs ne devient respectée qu’à partir de 4NF. De ce dernier point, je ne suis pas encore sûr, la notion de multivaluation a été nouvelle pour moi.

  11. Alexandre Courvoisier dit :

    Ah, j’oubliais

    Le meilleur tutoriel que j’ai trouvé sur la normalisation est celui-ci : http://fsmrel.developpez.com/basesrelationnelles/normalisation/

    Trouver ce tuto ainsi c’est bien, le lire aussi – car effectivement, le tutoriel de Fsmrel n’a aucun égal actuellement sur le net, à mon avis, au sens que la plupart s’arrêtent simplement à 3NF, en disant que « c’est suffisant » (sur quelle base, je ne sais pas). Et ce que j’ai rédigé n’offrira aucune considération en terme d’optimisation, car je n’ai pas encore d’expérience dans ce domaine. Même si j’ai sauté les chapitres d’optimisation, Monsieur de Sainte Marie a mon plus profond respect – son expérience est solide, mais je crois l’avoir quelque peu impatienté sur les principes. À tel point que je me suis demandé s’il était réellement ingénieur.

    Parmis ce que j’avais noté, je lui ai fait remarqué – selon ma mémoire – que sous BCNF figuraient plein de définitions, sauf celle de Boyce et Codd, ceci dit ce n’est pas le plus capital.

    Aussi, le terme de « sous-clé » est utilisé.
    Si une super-clé (Fsmrel parle de sur-clé, mais le terme « overkey » n’a jamais existé chez les anglo-saxons) est bien une clé au même titre qu’une clé candidate, la « sous-clé » ne saurait aucunement être une clé, et par suite, est un non-sens. (Je ne lui avais pas mentionné ce point – il y en avait assez d’autres offrant une discussion.)

    Monsieur de Sainte Marie m’a écrit, lors de notre bref échange, qu’il ne se permettrait pas d’altérer les propos de Date. Le contre-exemple le plus stupéfiant est la définition de 6NF, que je lui ai notifiée. Il a voulu – pour la simplification – annuler une « double négation ». Erreur conceptuelle d’autant plus importante, qu’elle est élémentaire; la première négation s’applique à un substantif – la dépendance de jointure – alors que la deuxième s’applique à son qualificatif d’être triviale.

    La définition de 6NF traduite en français, et élaguée de son rappel sur la dépendance de jointure triviale, est la suivante (j’ai corrigé « sixth », car c’est en fait la neuvième):
    [Est en 6NF une relvar R] si et seulement si elle ne satisfait aucune dépendance de jointure non-triviale du tout.

    Et c’est bien pour cela que le rappel sur la dépendance de jointure triviale n’est fait qu’ensuite.

    Lorsque j’ai attiré son attention sur cette définition, Fsmrel avait écrit que R devait satisfaire une dépendance de jointure triviale.

    Je ne sais pas comment un ingénieur peut faire une telle approximation.

    Si c’est le cas, cela me semble rentrer dans la définition de Date et al., par contre: la réciproque n’est pas vraie.
    Il suffit pour cela d’imaginer une relvar n’ayant aucune dépendance de jointure du tout, ni non-triviale, ni triviale… alors qu’elle est validée par Date comme étant en 6NF, Fsmrel lui refusera ce statut.

    Donc les deux énoncés ne sont pas équivalents. Je n’ai pas trop regardé s’il avait décidé de finalement corriger cela. Il m’avait seulement signifié préférer continuer dans la faute, afin de « simplifier ». Et pour reprendre un de vos articles, Monsieur Audibert, ça aussi, ça peut s’appeler couper les têtes qui dépassent. Comme quoi même ceux qu’on apprécie le plus participent – parfois seulement ! – à ce qu’on aime le moins (ma grand-mère disait: le mieux est l’ennemi du bien). Voilà, petite morale qui me vient comme ça, quoiqu’elle dépasse largement le cadre des NF.

  12. Laurent dit :

    M. Courvoisier, je vais répondre globalement. Je trouve le terme de normalisation très adéquat. Certes il ne dit pas comment on normalise ni quel stade de normalisation on atteint. Il dit simplement que l’on procède à une opération dont l’objectif est de rendre la base de données plus normale, c’est à dire comportant moins d’anomalies pouvant conduire à des incohérences. Le terme de normalisation est analogue à celui d’accélération. Accélérer ne dit pas comment on accélère ni quelle vitesse on atteint. Ce n’est pas l’objectif du terme.
    Quand à la normalisation elle même, dans la plupart des applications, la BCNF suffit. Parfois, il faut dénormaliser pour des questions de performances. La normalisation n’est pas une fin en soit et avoir une base de donnée en 9ème forme normale ne garanti absolument rien. En effet, tout le processus est basé sur l’intuition de celui qui normalise. Il suffit que l’intuition ne soit pas bonne pour que la base de donnée en 9ème forme ne le soit pas non plus.
    L’intuition est à la base du processus car la normalisation se fait sur l’intention et non pas sur l’extension. Comme aucun procédé automatique ne peut définir l’intention, c’est au concepteur de la définir en se fiant à son intuition. Le processus de normalisation permet de matérialiser dans la base de données des dépendances ou des contraintes observées dans le monde réel par le concepteur en utilisant sa compétence et son intuition. Une fois ces dépendances ou contraintes définies formellement par le concepteur, la normalisation est un mécanisme fiable et formel, mais il ne faut jamais perdre de vue qu’il repose sur des prémisses qui elles ne sont pas formelles, pas calculables, pas démontrables et que le résultat obtenu, quelque soit le degré de normalisation atteint, ne vaudra jamais plus que les prémisses qui reposent entièrement sur la compétence, l’expérience et l’intuition du concepteur.

  13. mralem dit :

    Bonjour Monsieur,
    J’étudie cette année la matière de base de donnée relationnelle. Votre livre m’aide à comprendre les notions du cours, et je vous en remercie. Toutefois, je ne comprends pas la correction 5- du TD 3.6 pg 218 question 4
    En effet il me semble que d après les lois de Morgan non (A ou B)= non À et non B
    Du coup la réponse ne devrait elle pas être tout les films dont l année <2000 et dont le genre est différent de Policier ?
    Merci d avance

    • mralem dit :

      De plus à la question 12 le film faux semblant n apparaît pas ds le produit cartésien pourtant son annee est 1988 ce qui est bien inférieur ou égale à 1988

    • Laurent dit :

      C’est exact, la correction comporte une erreur. Les lignes devant être retournées sont : 01, 02, 04, 06, 07, 08, 10.
      La condition est : ( année < = 2000 et genre != 'Policier') car ( non année > 2000 ) donne ( année <= 2000 )

  14. mralem dit :

    Merci pour vos réponses :)
    Bonne continuation

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *