Applications Web : Les Bases de Données
WebObjects utilise une technologie appelée Enterprise Objects pour accéder aux données stockées (dans des bases de données, des serveurs d’annuaires, et ainsi de suite). Bien que Enterprise Objects vous permette de traiter vos données sous forme d’instances de classes Java plutôt que de vous demander de vous soucier des mécamismes bas niveau de la base, il est utile d’avoir quelques connaissances basiques des structures de bases de données relationnelles.
Ce chapitre apporte une courte introduction à la structure et à l’utilisation d’une base de données. Cela suffira pour que vous puissiez commencer à utiliser Enterprise Objects, mais vous devrez consulter la documentation qui accompagne votre base de données ou votre administrateur de bases de données local pour plus de détails. Vous pouvez aussi découvrir comment Enterprise Objects sert d’interface entre votre logique métier et votre base de données en consultant Inside WebObjects: Enterprise Objects.
Dans ce chapitre, vous allez apprendre :
- comment une base de données relationnelle est structurée,
- comment les relations sont implémentées dans une base de données.
Structure d’une Base de Données
Une base de données relationnelles suit approximativement le paradigme orienté objet. L’unité de base de cette organisation est la table, qui définit les attributs d’une entité de données. Une table peut avoir zéro ligne ou plus.
Tables
La table est l’équivallent de la définition de classe. Elle définit les attributs ou propriétés détenus par chaque ligne qu’elle contient. Chaque attribut est appelé une colonne.
Comme dans Java, la plupart des bases de données utilisent des types de données primitifs et chaque colonne de la table est définie pour être de l’un de ces types. Enterprise Objects gère la conversion entre les types internes d’une base de données et les types Java. Ensuite, pour chaque colonne, vous pouvez déclarer que sa ligne doit contenir des valeurs ou qu’elle peut être null.
Vous pouvez imaginer qu’une table est une classe, que les colonnes sont des variables d’instance et que les lignes sont des instances d’objets individuels. Comme un fichier de définition de classe en Java, une table n’a pas de variables. Vous devez ajouter une ligne pour pouvoir utiliser ses colonnes.
Lignes
Une ligne est l’équivallent d’une instance de classe. Là où la table s’apparente à une classe, une ligne s’apparente à une instance de classe.
Unicité
Chaque ligne d’une table donnée doit être différente des autres de quelques manières que ce soit. C’est ainsi que la base sait quels lignes mettre à jour ou supprimer lorsque vous effectuez des changements dans les données.
La base de données utilise une clé primaire qui définit une propriété (ou un ensemble de propriétés) dont la valeur identifie de manière unique chaque ligne. Pour chaque table que vous définissez, vous fournissez une clé (ou liste de clés) qui définit comment le moteur de la base peut être sûr que deux lignes sont bien différentes. Par exemple, si voous définissez une table pour stocker des données sur des personnes, vous déciderez peut-être d’utiliser le nom de la personne pour différencier chaque ligne entre elles.
Le système de la base s’assure que chaque ligne a bien une valeur unique dans la colonne (ou la combinaison de valeurs de l’ensemble de colonnes) que vous avez spécifiée comme étant la clé primaire. Enterprise Objects masque la plupart des complexités qui existent dans les interactions avec la base de données, y compris la conversion des types internes de la base en types Java. Cependant, si vous essayer d’affecter une valeur à une ligne qui entre en conflit avec une valeur d’une autre ligne, la base de données refuse le changement et remonte une erreur que votre application devra gérer.
Il est important de choisir soigneusement les clés primaires de vos tables. Si vous définissez que votre clé primaire est la colonne qui contient le nom d’une personne, vous rencontrerez des difficultés dès que vous aurez deux personnes ayant le même nom. En général, il est mieux de faire en sorte que votre clé primaire ne serve à rien d’autre et de laisser Enterprise Objects la gérer pour vous.
Dans l’exemple de la base de données “Auteurs” (voir “Création de la Base de Données Auteurs”), chaque table comporte une colonne qui sert de clé primaire et qui s’appelle ENTITYNAME_ID de type entier.
Non Null
Vous souhaiterez peut-être déclarer qu’une ligne n’est pas valide lorsque certaines données manquent ou sont indéfinies. En déclarant qu’une colonne donnée est not-null, vous indiquez à la base de données d’interdire l’ajout de toute ligne qui ne contient pas la donnée requise.
Si vous rassemblez des informations à partir d’une liste de diffusion par email, par exemple, une ligne ne comportant pas de valeur dans la colonne EMAIL_ADDRESS n’est pas utile.
La colonne clé primaire d’une table doit toujours être déclarée comme étant non-nulle.
Relations
Une partie du schéma des bases de données consiste en des relations entre les tables. Chaque relation est composée des clés source et destination qui la définissent.
Les lignes et les tables peuvent être en relation de multiples manières. Comme avec la programmation orientée objet, la façon dont vous concevez les tables de la base de données dépend de la manière dont vous avez l’intention de vous en servir. Les relations peuvent modéliser une propriété (dans le sens “possession”), dans laquelle une ligne est une sous-partie d’une autre ligne, mais placée dans une table séparée par soucis d’organisation—par exemple, chaque ligne d’une table PERSONNE peut posséder une ligne d’une table ADRESSE parce que toute personne doit avoir une adresse postale. Les relations peuvent être optionnelles ou obligatoires. Dans la base de données Authors, tous les livres doivent avoior un auteur, mais il est concevable que quelques auteurs ne soient pas encore publiés (et en conséquence n’aient aucune ligne dans la table BOOK).
Puisque les relations mène d’une table source vers une table destination, nous disons que nous suivons une relation. Bien que Enterprise Objects supprime la plupart des considérations propres à la base dans l’utilisation des relations entre objets, il est utile de comprendre comment une relation est gérée au niveau de la base de données.
Les relations ne sont pas suivies à partir d’une table vers une autre mais à partir d’une ligne spécifique vers une autre ligne. Il est insensé de demander quel est l’auteur de la table BOOK ; cependant, chaque ligne de la table BOOK a une ligne correspondante dans la table AUTHOR.
Pour mettre en relation des lignes, des clés secondaires sont utilisées. Les clés secondaires sont des colonnes de la table source dont les lignes pointent vers la clé primaire de la table cible. Par exemple, la table des livres comporte une clé secondaire (AUTHOR_ID) qui est utilisée pour trouver les lignes correspondantes de la table AUTHOR (l’auteur du livre). Dans la table BOOK, AUTHOR_ID n’apporte aucune information sur le livre. Son seul but est de lier les lignes de la table BOOK avec les lignes de la table AUTHOR.
Un attribut important de la relation est l’ordinalité. L’ordinalité est une mesure indiquant qu’une relation met en rapport une ligne avec une seule autre ligne ou avec plusieurs autres lignes de la table de destination. Cela sépare les relations en deux types : un-pour-un (1/1) et un-pour-n (1/n).
Relations un-pour-un
Une relation 1/1, comme le suggère son nom, est une relation où la ligne source est connectée à une seule ligne. Dans cet exemple, chaque ligne de la table LIVRE ne peut avoir qu’une seule ligne de la table AUTHOR (NdT : Bien qu’un livre puisse être écrit par plusieurs auteurs !).
La colonne de destination d’une relation 1/1 doit être la même que la colonne clé primaire de la table de destination. Cela garantit qu’il n’y a qu’une seule ligne de destination pour une ligne source donnée.
Pour trouver la ligne correspondante à l’auteur spécifique d’un livre, vous effectueriez les taches suivantes :
- Obtenir les colonnes source et destination.Selon la définition de la relation, la colonne source est AUTHOR_ID dans la table BOOK et la colonne destination est AUTHOR_ID dans la table AUTHOR.
- Obtenir la valeur de la colonne AUTHOR_ID de la ligne source.
- Trouver la ligne cible dans la table AUTHOR (la ligne dont la colonne AUTHOR_ID a une valeur égale à celle de le colonne AUTHOR_ID de la ligne source).Puisque AUTHOR_ID est la clé primaire de la table AUTHOR, il n’y a qu’une seule ligne correspondante. Cette ligne contient les données de l’auteur du livre.
Relations un-pour-n
Autrement, une relation peut connecter la ligne source à plusieurs lignes destination. Par exemple, dans la base Authors, chaque auteur peut avoir plusieurs livres. Souvenez-vous que la colonne AUTHOR_ID de la table BOOK est une clé secondaire, pas une clé primaire. Par conséquent, cette colonne n’a pas à contenir une valeur unique dans toutes les lignes de la table BOOK.
Pour trouver les lignes de BOOK correspondant à une ligne de AUTHOR, vous effectueriez les taches suivantes :
- Obtenir les colonnes source et destination.Selon la définition de la relation, la colonne source est AUTHOR_ID dans la table AUTHOR et la colonne destination est AUTHOR_ID dans la table BOOK.
- Obtenir la valeur de la colonne AUTHOR_ID de la ligne source.
- Trouver les lignes dans la table BOOK dont la colonne AUTHOR_ID a une valeur égale à celle de le colonne AUTHOR_ID de la ligne source.Notez que AUTHOR_ID n’est pas la clé primaire de la table BOOK. Cela signifie que la relation peut mener à plusieurs lignes de la table BOOK. Chacune de ces lignes auront la même valeur dans la colonne AUTHOR_ID, signifiant que les livres qu’elles représentent ont été écrits par le même auteur.
De plus, il n’y a aucune garantie qu’il y ait des lignes de la table BOOK dont la valeur de la colonne AUTHOR_ID corresponde à celle de la colonne AUTHOR_ID de la table source. La relation pourrait donc mener vers aucune ligne de la table BOOK.
Textes originaux en anglais sur developer.apple.com : WebObjects Web Application - Database Basics
Chargement
Commentaires récents