Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

13 Rappels sur les SGBDR Une base de données est un ensemble d’informations sto

13 Rappels sur les SGBDR Une base de données est un ensemble d’informations stockées sur un support et doté d’une certaine organisation. Votre carnet d’adresses en est un exemple élémentaire, l’annuaire du téléphone également, mais à une autre échelle. L’accès rapide à l’information via des réseaux comme ceux des entreprises puis par Internet a nécessité la création de systèmes d’organisation des données permettant un accès rapide à l’information. Imaginez que vous deviez trouver toutes les personnes portant le même nom dans un département donné. La consultation de l’annuaire vous prendrait des heures. Face à de tels problèmes, l’informatisation du stockage des données est devenue une nécessité. C’est dans ce but qu’ont été créés les SGBDR (Système de gestion de base de données relationnelle). L’objectif de ce chapitre n’est pas de vous fournir un cours complet sur les bases de données, loin de là. Il s’agit simplement de rappeler les notions essentielles qui vous permettront, à partir d’un besoin particulier de stockage d’information, de structurer les différentes données dans une base. Pour approfondir le sujet de la conception des bases de données et en particulier la méthode de conception UML (Unified Modeling Language, Langage de modélisation unifié en français), mieux adaptée à la conception orientée objet, vous pouvez vous reporter utilement à l’ouvrage de Christian Soutou, De UML à SQL : Conception de bases de données, paru aux éditions Eyrolles. L’organisation des données doit permettre de répondre à des contraintes précises, notam- ment les suivantes : • Les données doivent occuper le moins d’espace possible. • Les redondances d’information doivent être évitées. PHP 5 370 • Les mises à jour ou la suppression de données doivent laisser la base intègre et ne pas créer d’incohérences. • La recherche d’informations doit être rapide et sûre. Vous allez donc aborder successivement les phases suivantes : 1. Élaboration du modèle d’organisation des données à l’aide de la méthode entité/asso- ciation. Cela entraîne la création d’un modèle conceptuel de données (MCD), qui est une représentation abstraite des données à stocker et des liens entre elles. 2. Passage du modèle ainsi créé au modèle relationnel, qui est actuellement le plus courant. Cela entraîne la création d’un modèle logique de données (MLD), qui est la représentation d’un modèle implantable dans un système particulier. 3. Implémentation dans un SGBDR (Système de gestion de base de données relation- nelle) particulier, comme MySQL ou SQLite, qui font l’objet des chapitres suivants. L’exemple qui servira de socle à tout ce chapitre est la modélisation de la base de données nécessaire à la gestion d’un site de commerce en ligne. Le modèle entité/association Le nom anglais du modèle entité/association (Entity/Relationship) est à l’origine de la confusion que l’on retrouve souvent dans la définition d’une base de données relation- nelle (BDR). Certains auteurs définissent un BDR comme une base ayant des relations entre tables. Or une base est dite relationnelle si elle repose sur la notion de table, qui est la traduction du concept mathématique de relation entre ensembles. Une base de données peut en effet être qualifiée de relationnelle et ne comporter qu’une seule table. Le modèle entité/association permet la modélisation abstraite d’une base de données. Il utilise un ensemble de conventions de représentation graphique pour modéliser les différents concepts contenus dans une information et les liens qui existent entre eux. Les schémas réalisés sont similaires à ceux de la méthode Merise et donc différents de la notation UML. Les entités On appelle entité une représentation d’un ensemble d’objets réels ou abstraits qui ont des caractéristiques communes. Une information du monde réel peut correspondre à plusieurs entités. Cette décomposition de l’information en plusieurs entités, dont chacune a une nature différente, constitue la première étape du travail de conception. Si vous voulez modéliser une commande faite par un client, il apparaît en première lecture au moins deux entités, une personne d’un côté et les articles qu’elles commande de l’autre. Vous avez bien fait apparaître deux entités de nature différente. Chaque personne réelle est une occurrence de l’entité générale personne. Rappels sur les SGBDR CHAPITRE 13 371 On distingue deux sortes d’entités : • Les entités fortes, qui ne dépendent pas de l’existence d’une autre entité. C’est le cas, par exemple, d’une entité représentant un personne ou un produit. • Les entités faibles, dont l’existence dépend d’une autre entité. C’est le cas d’une entité représentant une commande qui dépend de l’entité personne (pas de commande s’il n’y a pas de client). Les entités sont représentées graphiquement par des rectangles (voir figure 13-1). Les attributs Chaque entité a des caractéristiques particulières, que l’on retrouve dans toutes ses occurrences. Un client a, par exemple, nécessairement un nom, un prénom, une adresse, etc. Ces caractéristiques sont nommées attributs de l’entité. Chaque entité doit avoir au moins un attribut, qui permet de distinguer une occurrence d’une autre. Cet attribut particulier est la clé primaire de l’entité. Cette clé doit être unique dans l’entité. Pour une personne, il est évidemment possible de trouver deux personnes de même nom. Le nom est donc un mauvais candidat pour effectuer cette distinction. Pour distinguer deux clients, on utilise habituellement un numéro de client pour chaque personne. La clé primaire peut être constituée de la réunion de plusieurs attributs, par exemple, le nom et l’adresse, si nous admettons qu’il n’est pas possible que deux personnes homonymes habitent au même endroit. L’utilisation d’une clé primaire abstraite, comme un identifiant numérique (par exemple le numéro INSEE propre à chaque personne), représente une solution plus sûre que le choix d’un autre attribut, et il est conseillé de l’utiliser systématiquement. Un attribut peut être défini comme obligatoire ou facultatif dans l’entité. Il peut être élémentaire ou décomposable en plusieurs autres attributs. L’adresse complète d’une personne peut constituer un seul attribut ou être décomposée en rue, ville, département et code postal. Il n’y a pas d’obligation en ce domaine. Cela relève d’un choix du pro- grammeur en fonction des besoins du client. S’il n’envisage pas de réaliser un jour des recherches de personnes par ville ou par département, il est inutile de décomposer l’attri- but adresse. Chaque attribut possède un domaine de valeurs possibles. Un nom est représenté par une chaîne de caractères de longueur variable et le code postal par un nombre de cinq chiffres. À chaque attribut correspond un type de donnée particulier. C’est à prendre en compte lors de l’implantation de la base de données sur un SGBDR particulier. Figure 13-1 Représentation des entités PHP 5 372 Une entité munie de ses attributs est représentée par un rectangle contenant le nom de l’entité suivi de celui de ses attributs. Dans la représentation graphique de l’entité, le nom de l’attribut qui constitue la clé primaire est placé en premier et souligné (voir figure 13-2). Les associations Le concept d’association permet de représenter le lien existant entre deux ou plusieurs entités. Une association reliant deux entités est dite binaire. Celle qui en relie plusieurs est dite n-aire. Dans la décomposition de l’information en entités vous avez toujours inté- rêt à créer des associations binaires et à redécomposer celles qui seraient ternaires. Une association est généralement nommée à l’aide d’un verbe d’action (à la forme active d’une entité vers l’autre et passive dans l’autre sens). Par exemple, la phrase « Un client commande un article » résume l’association commande entre l’entité client et vers l’entité article. Une association est représentée graphiquement par une ellipse contenant son nom. La figure 13-3 donne la représentation graphique de cette association. Une associa- tion peut, comme les entités, posséder des attributs. La clé de l’association est la conca- ténation des clés des entités qu’elle relie. Une association peut être réflexive, c’est-à-dire relier une entité à elle-même. Par exemple, l’association conjoint relie une personne avec une autre personne. Les cardinalités La cardinalité d’une association mesure le nombre d’occurrences d’une entité qu’il est possible d’associer à une occurrence de l’autre entité associée. Elles sont indiquées de chaque coté de l’association pour chaque entité. Figure 13-2 Représentation graphique d’une entité Figure 13-3 Représentation d’une association binaire Rappels sur les SGBDR CHAPITRE 13 373 On distingue des cardinalités minimales et maximales : • La cardinalité minimale mesure le nombre minimal de participation d’une entité dans l’association. Pour être enregistrée dans la base, une personne doit passer au moins une commande. La cardinalité minimale du coté de l’entité personne est donc 1. Un produit peut n’être commandé par aucune personne. La cardinalité minimale du coté de l’entité article est donc 0. En résumé, on indique ces deux cardinalités par la nota- tion 0.N. • La cardinalité maximale mesure le nombre maximal de participations d’une entité dans l’association. Une personne peut passer un nombre quelconque de commandes. La cardinalité maximale du coté de l’entité personne est donc notée N. Un produit peut être commandée par N personnes différentes. La cardinalité maximale du coté de l’entité article est donc N. En résumé, on indique ces deux cardinalités par la notation N.N. En pratique, on la note N.M pour montrer que les cardinalités ne sont pas néces- sairement égales. Par uploads/Industriel/ rappels-sgbdr.pdf