Créée le, 19/06/2015

 Mise à jour le, 19/05/2019

Visiteurs N°  




Accueil
Nouveau Blog Nouveautés Moteur de Recherche Votre Caddie Pour Vos Achats Votre Espace Membre Vos Signets et Vos Jeux Préférés Page de Bienvenue Statique Site en Français Site en Anglais
Sommaires
Électronique Fondamentale Technologie Fondamentale Testez vos Connaissances Électronique Théorique Digitale Électronique Pratique Digitale Lexique Électronique Numérique Data book TTL Data book CMOS Dépannage TVC Mathématique
Micro-ordinateurs
Théorique des Micro-ordinateurs Testez vos Connaissances Pratique des Micro-ordinateurs Glossaires sur les Ordinateurs
Physique
La lumière Champ d'action Rayonnement Électromagnétique
Technologies
Classification des Résistances Identification des Résistances Classification des Condensateurs Identification des Condensateurs
Formulaires Mathématiques
Géométrie Physique 1. - Électronique 1. 2. - Électronique 1. 3. - Électrotechnique 1. 4. - Électromagnétisme
Accès à tous nos Produits
E. T. F. - Tome I - 257 Pages E. T. F. - Tome II - 451 Pages E. T. F. - Tome III - 611 Pages E. T. D. - Tome I - 610 Pages N. B. M. - Tome I - 201 Pages E. T. M. - Tome I - 554 Pages Business à Domicile Ouvrages 34 pages gratuits Nos E-books Logiciel Géométrie Logiciel Composants Électroniques
Aperçu de tous nos Produits
E. T. F. - Tome I - 257 Pages E. T. F. - Tome II - 451 Pages E. T. F. - Tome III - 611 Pages E. T. D. - Tome I - 610 Pages E. T. M. - Tome I - 554 Pages Logiciel Géométrie Logiciel Composants Électroniques
Nos Leçons aux Formats PDF
Électronique Fondamentale Technologie Fondamentale Électronique Théorique Digitale Électronique Pratique Digitale Théorique des Micro-ordinateurs Mathématiques
Informatique
Dépannage Win98 et WinXP et autres Dépannage PC Glossaire HTML et Programmes PHP et Programmes JavaScript (en cours de travaux) Création de plusieurs Sites
Forums
Forum Électronique et Infos Forum Électronique et Poésie
Divers et autres
Formulaire des pages perso News XML Statistiques CountUs Éditeur JavaScript Nos Partenaires et nos Liens Utiles Gestionnaire de Partenariat Nos Partenaires MyCircle Sondages 1er Livre d'Or 2ème livre d'Or

Signets :
  Leçons suivantes        Leçons précédentes     Bas de page
  Cliquez ici pour la leçon suivante ou dans le sommaire prévu à cet effet


Conception de votre base de données Web (1ère partie) :



Concepts des bases de données relationnelles :


Puisque vous connaissez maintenant les éléments essentiels du langage PHP, nous allons nous intéresser à l'intégration d'une base de données dans vos scripts. Dans la deuxième leçon, nous avons présenté les avantages de l'utilisation d'une base de données relationnelle à la place d'un fichier brut. On verra tous ces points concernant des atouts des RDBMS (Relational DataBase Management System) :

Petite_Main.gif Ils permettent d'accéder aux données plus rapidement qu'avec des fichiers bruts.

Petite_Main.gif On peut les interroger très facilement pour récupérer des ensembles de données satisfaisant certains critères.

Petite_Main.gif Ils possèdent des mécanismes intégrés permettant de gérer les accès simultanés, pour que le programmeur, c'est-à-dire vous-même, n'ait pas besoin de s'en occuper.

Petite_Main.gif Ils permettent d'accéder aléatoirement à vos données.

Petite_Main.gif Ils possèdent des systèmes de privilèges intégrés.

Concrètement, l'utilisation d'une base de données relationnelle vous permet rapidement et simplement à des questions comme l'origine de vos clients, vos produits qui se vendent le mieux, ou le type de clients qui dépensent le plus d'argent. Ces informations pourront vous aider à améliorer votre site pour attirer un plus grand nombre d'utilisateurs, et pour les fidéliser. La base de données que nous traiterons dans cette leçon est MySQL.

Les bases de données relationnelles sont, de loin, les bases de données les plus utilisées. Elles font appel à de solides bases théoriques, en algèbre relationnelle. Vous n'avez pas besoin de comprendre cette théorie relationnelle pour pouvoir utiliser une base de données relationnelle (ce qui est fort heureux), mais vous devez, en revanche connaître quelques concepts essentiels des bases de données.

Tableaux :

Les bases de données relationnelles sont composées de "relations", que l'on appelle plus couramment des "tableaux". Un tableau est en fait un ensemble de données organisées d'une certaine manière. Si vous avez déjà utilisé une feuille de calcul dans un tableur, vous avez déjà utilisé un tableau relationnel.

Intéressons-nous à un petit exemple.

Dans la figure 1, vous trouverez un exemple de tableau, qui contient les noms et les adresses des clients d'une librairie, de chez Jean-Pierre.

Tableaux_Clients.png

Ce tableau possède un Nom (Les Clients), un certain nombre de colonnes (correspondant chacune à un type d'information) et plisieurs lignes correspondant aux différents Clients.

Colonnes :

Chaque colonne possède un Nom unique et contient différentes données. De plus, dans le Tableau Les Clients de la figure 1, vous pouvez voir que la colonne Client_ID contient des nombres entiers, alors que les trois autres colonnes contiennent des chaînes de caractères. Les colonnes sont parfois appelées des champs ou des attributs.

Lignes :

Chaque ligne de ce tableau représente un client particulier. Grâce au format de ce tableau, toutes ces lignes possèdent les mêmes attributs. Les lignes peuvent également être appelées des enregistrements ou des tuples.

Valeurs :

Chaque ligne est composée d'un ensemble de valeurs particulières correspondant à chaque colonne. Le type de chaque valeur doit correspondre au type de la colonne dans laquelle elle se trouve.

Clés :

Il nous faut ensuite un moyen d'identifier chaque client. Généralement, les noms des clients ne sont pas très pratiques pour cela. Si vous possédez un nom assez répandu, vous avez probablement déjà compris pourquoi. Prenons par exemple le Nom de Pierre DUPOND dans le tableau Les Clients. En ouvrant un annuaire téléphonique, on se rend aussitôt compte qu'il existe un grand nombre de personnes possédant ce nom.

Nous pouvons identifier l'utilisateur Pierre DUPOND de plusieurs manières. En effet, on peut supposer qu'il s'agit uniquement le seul Pierre DUPOND habitant à son adresse. Cependant, le fait de désigner ce client par "Pierre DUPOND, 75 Rue de Lattre, Paris" est assez pénible et plutôt formel. Cela implique aussi d'utiliser plusieurs colonnes dans le tableau.

Dans cet exemple, nous avons choisi une approche que vous reprendrez probablement dans vos applications : l'affectation d'un identificateur de client unique, Client_ID, à chaque client. Ce principe est assez courant : vous possédez déjà un numéro de compte bancaire unique. Cela permet d'enregistrer les détails vous concernant dans une base de données d'une manière plus efficace et plus simple. de plus, on peut s'assurer que ce numéro d'identification est unique. Dans la pratique, il existe peu d'informations qui possèdent cette propriété, même si on en utilise plusieurs conjointement.

La colonne d'identification d'un tableau est appelé la clé, ou la clé primaire. Une clé peut également être répartie sur plusieurs colonnes. Par exemple, si nous avions choisi d'identifier Pierre avec "Pierre DUPOND, 75 Rue de Lattre, Paris", la clé contiendrait les colonnes Nom, Adresse et Ville, et dans ce cas, il est possible de garantir son unicité.

Les bases de données contiennent en général plusieurs tableaux, et se servent des clés comme d'une référence d'un tableau à un autre. Dans la figure 2, nous avons ajouté un second tableau dans la base de données. Celui-ci contient les commandes effectuées par les clients. Chaque ligne du tableau de Commandes représente une seule commande, effectuée par un seul client. Le client est identifié par le Numéro de Commande_ID valant 2, nous pouvons voir qu'elle a été effectuée par le client dont le Client_ID vaut 1. Si nous nous reportons ensuite au tableau Les Clients, nous pouvons voir que le Client_ID vaut 1 et fait référence à Pierre DUPOND.

Tableaux_Clients_2.png

Dans la terminologie des bases de données relationnelles, cette relation est appelée une clé externe. Dans le tableau Client_ID est la clé primaire dans le tableau "Les Clients", mais lorsqu'elle apparaît dans un autre tableau, comme le tableau de Commandes, elle devient une clé externe.

Vous vous demandez peut-être pourquoi nous avons choisi d'implémenter deux tableaux différents : pourquoi ne pas se contenter d'enregistrer l'adresse de Pierre DUPOND dans le tableau de Commandes ? C'est ce que nous allons voir dans la prochaine section de cette leçon.

Schémas :

La structure globale des tableaux d'une base de données est appelée le schéma de cette base de données. Il s'agit d'une sorte de plan de la base de données. Un schéma doit représenter les tableaux ainsi que leurs colonnes, le type de données de chaque colonne, et préciser la clé primaire de chaque tableau et toutes les clés externes. Un schéma ne contient aucune donnée, mais vous pouvez choisir de présenter quelques données typiques avec votre schéma pour expliquer son fonctionnement. Un schéma peut être présenté tel qu'il apparaît dans les diagrammes que nous utilisons, dans des diagrammes de relations d'entités (que nous n'aborderons pas dans cette leçon), ou plus simplement dans un format texte, comme ceci :

Les Clients(Client_ID, Nom, Adresse, Ville)

Commandes(Commande_ID, Client_ID, Prix, Date)

Les termes soulignés dans ce schéma sont les clés primaires pour la relation dans laquelle elles sont soulignées. Les termes soulignés en pointillé sont les clés externes pour la relation dans laquelle elles apparaissent soulignées en pointillé.

Relations :

Les clés externes représentent une relation entre les données et les tableaux. Par exemple, le lien du tableau Commandes vers le tableau Les Clients représente une relation entre une ligne du tableau Commandes et une ligne du tableau Les Clients.

Il existe trois principaux types de relations dans une base de données relationnelle. Ces relations peuvent être classées en fonction du nombre d'éléments intervenant dans chaque membre de la relation : un-vers-un, un-vers-plusieurs, ou plusieurs-vers-plusieurs.

Une relation un-vers-un signifie que la relation fait intervenir un seul élément de chaque côté. Par exemple, si nous avions placé les adresses dans un autre tableau que Les Clients, il existerait une relation un-vers-un entre elles. Vous pouvez disposer d'une clé externe de "Adresse" vers Les Clients, ou dans l'autre sens (aucune des deux n'est nécessaire).

Dans une ralation un-vers-plusieurs, une ligne d'un tableau est associée à plusieurs lignes d'un autre tableau. Dans notre exemple, un client référencé dans le tableau "Les Clients" peut effectuer plusieurs commandes, apparaissant dans le tableau "Commandes". Dans ce type de relation, le tableau dont plusieurs lignes participent à la relation possède une clé externe vers l'autre tableau. Dans notre cas, nous avons placé Client_ID dans le tableau de Commandes pour illustrer cette relation.

Dans une relation plusieurs-vers-plusieurs, plusieurs lignes d'un tableau sont associées à plusieurs lignes d'un autre tableau. Par exemple, si nous prenons l'exemple de deux tableaux, "Books" et "Authors", il se peut qu'un livre ait été écrit par deux auteurs, chacun d'entre eux ayant écrit d'autres livres, soit indépendamment, soit avec d'autres auteurs. Ce type de relation est généralement assez complexe, c'est pourquoi, il peut être intéressant de posséder les tableaux "Books", "Authors" et "Books_Authors". Ce dernier tableau ne contient que les clés des autres tableaux sous la forme de clés externes, pour connaître les auteurs associés à chaque livre.

Comment concevoir votre base de données Web :

Lorsque vous créez une base de données, vous modélisez généralement des objets du monde réel et les relations qui existent entre eux, et vous enregistrez des informations sur ces objets et sur ces relations.

Généralement, chaque type d'objet réel que vous modélisez a besoin de son propre tableau. En effet, dans notre exemple, il faut enregistrer les mêmes infomations pour tous les clients. Si un ensemble de données possède les mêmes propriétés, vous pouvez commencer par créer un tableau correspondant à ces données.

Dans l'exemple que nous évoquons de la librairie de chez Jean-Pierre, nous devons enregistrer des informations sur les clients, les livres à vendre, et sur les détails de chaque commande. Tous les clients possèdent un nom et une adresse. Les commandes sont caractérisées par une date, un montant total, et un ensemble de livres achetés. Chaque livre possède un code ISBN, un auteur, un titre, et un prix.

D'après ces caractéristiques, nous pouvons créer au moins trois tableaux dans cette base de données. Les Clients, Commandes et Books. Ce schéma initial est présenté à la figure 3.

Pour l'instant, il est impossible de deviner, à partir du modèle, les livres qui correspondent à chaque commande. Nous allons nous en occuper maintenant.

Tableaux_Clients_3.png

Evitez d'enregistrer des informations redondantes :

Nous avons déjà posé la question suivante : "Pourquoi ne pas enregistrer l'adresse de Pierre DUPOND dans le tableau de Commandes ?"

Si Pierre achète plusieurs livres chez Jean-Pierre, le responsable, cela reviendrait à enregistrer plusieurs fois les informations le concernant. Au cours du temps, le tableau de Commandes pourrait ressenbler à celui de la figure 4.

Tableaux_Clients_4.png

Cela pose essentiellement deux problèmes.

Tout d'abord, cette approche gaspille les ressources du système. Pourquoi enregistrer trois fois les données concernant Pierre, alors qu'il suffit de les enregistrer une seule fois ?

Le second problème est que cette approche peut entraîner des anomalies dans les mises à jour des informations, c'est-à-dire des situations dans lesquelles certaines informations de la base de données sont modifiées. Cette dernière se retrouve alors dans un état non cohérent. L'intégrité des données est corrompue, et il est impossible de savoir quelles sont les données correctes, et quelles sont les données incorrectes. Cela entraîne souvent des pertes d'informations.

Il convient d'éviter trois types d'anomalies : les anomalies de modification, d'insertions, et de suppressions.

Si Pierre déménage pendant qu'il a une commande en cours, il faut mettre à jour son adresse à trois endroits au lieu d'un seul, ce qui représente trois fois plus de travail. Il est assez facile d'oublier cette tâche et de ne changer son adresse qu'une seule fois, ce qui entraîne des incohérences dans la base de données (à éviter à tout prix). Ce type de problème est appelé une "anomalie de modification", puisqu'il a lieu pendant une modification de la base de données

Avec cette architecture, nous devons saisir les détails concernant Pierre chaque fois qu'il effectue une commande, et vérifier que ces détails sont cohérents avec les données existant déjà dans le tableau. Si nous oublions cette vérification, il se peut que nous nous retrouvions avec deux lignes contenant des informations différentes sur Pierre. Par exemple, l'une de ces lignes peut indiquer que Pierre Habite à PARIS, et une autre qu'il habite à NANTES. Ce type d'erreur est appelé une "anomalie d'insertion", puisqu'elle a lieu lorsque de nouvelles données sont insérées dans les tableaux.

Le troisième type d'anomalie est appelé "anomalie de suppression", puisque ces anomalies ont lieu lorsque des données sont supprimées dans la base de données. Par exemple, imaginons que lorsqu'une commande est terminée, nous la supprimons de la base de données. Lorsque toutes les commandes de Pierre ont été traitées, elles sont toutes supprimées du tableau de Commandes. Cela signifie que l'adresse de Pierre n'existe plus dans notre base de données. Il est alors impossible de lui envoyer des publicités, et la prochaine fois qu'il souhaitera passer une commande, il faudra rassembler à nouveau tous les détails le concernant.

Les bases de données sont normalement conçues pour qu'aucune de ces anomalies ne puisse avoir lieu.

Choisir des clés cohérentes :

Assurez-vous que les clés que vous choisissez sont uniques. Dans notre cas, nous avons créé des clés particulières pour les clients (Client_ID) et pour les commandes (Commande_ID), puisque ces objets du monde réel ne possèdent pas forcément un identificateur unique. Nous n'avons pas besoin de créer un identificateur unique pour les livres, puisqu'il en existe un : le numéro ISBN. Pour le tableau de Commandes_Articles, vous pouvez éventuellement ajouter une clé supplémentaire, mais la combinaison des deux attributs Commandes_ID et ISBN est unique, tant que plusieurs exemplaires d'un même livre dans une même commande sont traités sur une seule ligne. C'est pour cela que le tableau Commandes_Articles possède une colonne Quantity. Ce qui signifie "quantité".

Tableaux_Clients_5.png

Pensez aux questions que vous poserez à votre base de données :

Il est primordial de connaître les questions auxquelles la base de données doit pouvoir répondre. Vous pouvez par exemple reprendre les questions que nous avons mentionnées au début de cette leçon. Par exemple, quelles sont les meilleures ventes ? Assurez-vous que votre base de données contient toutes les donnés nécessaires, et que les liens appropriés existent entre les différents tableaux pour répondre correctement à vos questions.

Evitez les architectures multipliant les attributs vides :

Si nous souhaitons ajouter des résumés ou commentaires aux livres de la base de données, nous pouvons choisir entre deux approches différentes. Ces deux approches sont présentées à la figure 6.

Tableaux_Clients_6.png

La première méthode consiste à ajouter une colonne Résumé dans le tableau Books. De cette manière, il existe un champ Résumé pour chaque livre. Si la base de données contient beaucoup de livres, et si la personne qui rédige les résumés n'a pas l'intention de résumer chaque livre, il se peut que plusieurs lignes ne possèdent aucune valeur associée à cet attribut. On parle dans ce cas de valeurs nulles.

Il faut toujours éviter d'insérer des valeurs nulles dans une base de données. En effet, il s'agit d'un gaspillage de l'espace de stockage et cela peut entraîner divers problèmes lorsque vous calculez des totaux ou d'autres fonctions sur de colonnes numériques. De plus, lorsqu'un utilisateur voit une valeur nulle dans un tableau, il ne peut pas savoir si la valeur de cet attribut n'a aucune signification, s'il s'agit d'une erreur dans la base de données, ou s'il s'agit d'une donnée qui n'a pas encore été saisie.

Une architecture différente permet souvent de ne pas avoir recours à des valeurs nulles. Dans notre cas, nous pouvons avoir recours à la seconde architecture présentée à la figure 6. Dans cette organisation, seuls les livres qui possèdent un résumé sont spécifiés dans le tableau Book_Reviews, avec leur résumé.

Vous remarquerez que cette architecture nécessite un rédacteur de résumés en interne. Il est également possible de permettre aux utilisateurs d'écrire ces résumés. Pour cela, il suffit d'ajouter l'attribut Client_ID dans le tableau Book_Reviews.

Résumé des types de tableaux :

Les bases de données sont généralement composées de deux types de tableaux :

  • Des tableaux simples qui décrivent des objets du monde réel. Ces tableaux peuvent également contenir des clés vers d'autres objets simples, pour lesquels, il existe une relation un-vers-un ou un-vers-plusieurs. Par exemple, un client peut passer plusieurs commandes, mais chaque commande est effectuée par un seul client. Par Conséquent, nous pouvons placer dans chaque commande une référence au client qui a effectué cette commande.

  • Des tableaux de liaison qui décrivent des relations plusieurs-vers-plusieurs entre deux objets réels, comme la relation qui existe entre Commandes, figure 4 et Commandes Articles, figure 5. Ces tableaux sont souvent associés à des transactions réelles.

Architecture d'une base de données Web :

Maintenant que nous avons présenté l'architecture interne de votre base de données, nous pouvons nous intéresser à l'architecture externe des systèmes de bases de données Web, et présenter la méthodologie permettant de développer ces systèmes.

Architecture :

Le fonctionnement fondamental d'un serveur Web est présenté à la figure 7. Ce système est composé de deux objets : un navigateur Web et un serveur Web. Un lien de communication doit exister entre ces deux objets. Le navigateur Web effectue des requêtes auprès du serveur, et le serveur renvoie des réponses. Cette architecture est parfaitement adaptée à un serveur qui fournit des pages statiques. L'architecture qui permet de servir des sites Web faisant intervenir des bases de données est un peu plus complexe.

Client_Serveur.png

Les applications de base de données Web que nous allons mettre en œuvre dans cette leçon respectent une structure de base de données Web générale, qui est présentée à la figure 8. L'essentiel de cette structure devrait déjà vous sembler familier.

Client_Serveur_2.png

Une transaction de base de données Web typique est composée des étapes suivantes, qui sont numérotées sur la figure 8. Noua allons examiner ces étapes dans le contexte de la librairie de chez Jean-Pierre.

  1.   Le navigateur Web d'un utilisateur envoie une requête HTTP pour une page Web particulière. Par exemple, cette requête peut concerner tous les livres de chez Jean-Pierre écrit par Laura Thomson, et se présente sous la forme d'un formulaire HTML. La page de recherche des résultats est appelée Results.php
  2.   Le serveur Web reçoit la requête pour Results.php, récupère le fichier et le passe au moteur PHP afin qu'il soit traité.
  3.   Le moteur PHP commence à analyser le script. A l'intérieur de ce script se trouve une commande permettant de se connecter à la base de données et d'exécuter une requête (pour rechercher les livres). PHP ouvre une connexion vers le serveur MySQL, et transmet la requête appropriée.
  4.   Le serveur MySQL reçoit la requête de la base de données et la traite, puis renvoie les résultats (c'est-à-dire une liste de livres) au moteur PHP.
  5.   Le moteur PHP termine l'exécution du script, ce qui consiste généralement, en un formatage des résultats de la requête en HTML. Il envoie ensuite, le fichier HTML obtenu au serveur Web.
  6.   Le serveur Web transmet la page HTML au navigateur, pour que l'utilisateur puisse voir la liste des livres qu'il a recherchés.

Ce processus reste relativement identique, quels que soient le moteur de scripts et le serveur de base de données que vous utilisez. Le plus souvent, le serveur Web, le moteur PHP et le serveur de bases de données sont tous exécutés sur le même ordinateur. Cependant, il arrive que le serveur de base de données soit exécuté sur un autre ordinateur. Cette dernière approche répond à des problèmes de sécurité, d'augmentation des capacités, et de répartition de la charge. Au niveau de développement, cela ne change pas grand chose, bien que cette approche fournisse des avantages significatifs en termes de performances.

Dans cette leçon, nous avons présenté quelques conseils généraux pour l'architecture des bases de données relationnelles. Toutefois, si vous souhaitez vous attaquer plus profondément à la théorie des bases de données relationnelles, vous pouvez consulter plusieurs ouvrages écrits par des auteurs faisant référence à nos leçons, comme C.J Date. Cependant, vous devez savoir que ces ouvrages sont très théoriques, et n'ont pas nécessairement d'intérêt immédiat pour un développeur Web commercial. Généralement, les bases de données Web classiques ne sont pas très compliquées.

Nous terminons ainsi cette septième leçon et nous verrons dans la prochaine, l'usage que nous nous intéresserons à la Construction de votre Base de données MySQL ainsi que la création des bases de données et des utilisateurs.



  Cliquez ici pour la leçon suivante ou dans le sommaire prévu à cet effet.   Haut de page
  Page précédente   Page suivante







Nombre de pages vues, à partir de cette date : le 23 MAI 2019

compteur de visite

    




Envoyez un courrier électronique à Administrateur Web Société pour toute question ou remarque concernant ce site Web. 

Version du site : 10. 5. 14 - Site optimisation 1280 x 1024 pixels - Faculté de Nanterre - Dernière modification : 19 MAI 2019.   

Ce site Web a été Créé le, 14 Mars 1999 et ayant Rénové, en MAI 2019.