Introduction
L’application de commandes dispose d’une connexion à la base, mais d’aucune table de commandes. Vous définirez un petit schéma, stockerez trois commandes clients et interrogerez les données que lit l’application.
Terminez d’abord le laboratoire précédent sur la connexion. Ce laboratoire démarre indépendamment avec une instance PostgreSQL, une application et l’AWS CLI configurée. Vous supprimerez la base d’exercice après avoir testé les résultats.
Lien avec les certifications
Ce laboratoire propose une pratique introductive des sujets d’examen suivants.
- Cloud Practitioner (CLF-C02) · Tâche 3.4 : Reconnaître un cas d’utilisation d’une base relationnelle pour les données structurées d’une application.
- Solutions Architect – Associate (SAA-C03) · Tâche 3.3 : Comprendre les moteurs relationnels et les modes d’accès aux données des applications.
Définir la table des commandes
Dans cette étape, vous créerez un schéma donnant à chaque commande un identifiant unique, un nom de client et un montant total.
Une table stocke des lignes avec des colonnes définies. SQL est le langage permettant de définir et d’interroger ces lignes. L’API RDS gère l’instance ; SQL agit sur les données à l’intérieur du moteur PostgreSQL.
Chargez les paramètres de connexion SQL préparés et inspectez l’instance fournie :
cd /home/labex/project
source database.env
aws rds \
describe-db-instances \
--db-instance-identifier orders-db \
--query 'DBInstances[0].{Database:DBName,Endpoint:Endpoint,Status:DBInstanceStatus}'
L’instance est disponible et contient la base orders. Sa connexion psql est préparée sous la forme service=orders-db.
Créez la table avec un heredoc. Le texte entre les deux lignes SQL est transmis à psql comme instructions SQL :
psql \
"service=orders-db" \
--set=ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE orders (
order_id integer PRIMARY KEY,
customer text NOT NULL,
total numeric(8,2) NOT NULL CHECK (total > 0)
);
SQL
La clé primaire empêche deux lignes de partager le même ID de commande. NOT NULL impose une valeur. numeric(8,2) stocke un nombre décimal avec deux chiffres après la virgule, et CHECK rejette un total nul ou négatif. Ces contraintes permettent à la base de refuser les données invalides.
Inspectez la table :
psql \
"service=orders-db" \
--command '\d orders'
Vous devez voir trois colonnes, une clé primaire et le contrôle du total positif. La table ne contient encore aucune ligne.
Stocker trois commandes clients
Dans cette étape, vous insérerez un petit jeu de données puis le relirez immédiatement.
INSERT écrit des lignes. Nommer les colonnes explicite la correspondance entre chaque valeur et sa colonne :
psql \
"service=orders-db" \
--set=ON_ERROR_STOP=1 <<'SQL'
INSERT INTO orders (order_id, customer, total)
VALUES
(101, 'Maya', 49.90),
(102, 'Owen', 18.50),
(103, 'Nina', 25.25);
SELECT order_id, customer, total
FROM orders
ORDER BY order_id;
SQL
Vous devez obtenir trois lignes avec les valeurs ci-dessus. SELECT lit les données stockées ; ORDER BY rend l’affichage prévisible. Sans clause de tri, une base ne garantit aucun ordre particulier des lignes.
AWS View doit maintenant afficher ces trois mêmes commandes. L’application lit PostgreSQL à chaque requête : ajouter la table et ses lignes transforme une liste indisponible en données utiles pour l’application.
Interroger les commandes et vérifier l’application
Dans cette étape, vous répondrez à une question métier et comparerez les données SQL à la réponse de l’application.
L’équipe veut les commandes d’au moins 25.00. WHERE filtre les lignes avant leur inclusion dans le résultat :
psql \
"service=orders-db" \
--command 'SELECT order_id, customer, total FROM orders WHERE total >= 25.00 ORDER BY order_id;'
Vous devez obtenir les commandes 101 et 103. Le filtre ne supprime pas la commande 102 ; il sélectionne seulement les lignes à renvoyer.
Une agrégation combine les valeurs de plusieurs lignes. Comptez toutes les commandes et calculez leur montant total :
psql \
"service=orders-db" \
--command 'SELECT count(*) AS order_count, sum(total) AS order_total FROM orders;'
Vous devez obtenir 3 commandes et un total de 93.65.
Demandez la liste des commandes à l’application :
curl \
--silent \
--show-error \
--fail \
http://127.0.0.1:8080/application/orders | jq
Vous devez obtenir les trois commandes, la base orders, l’utilisateur orders_admin et read_only: false. SQL et l’application lisent les mêmes données stockées. L’application renvoie la liste complète ; la requête SQL précédente appliquait votre filtre.
L’utilisateur maître de la base est utile pour créer ce schéma. Le prochain laboratoire donne à l’application une identité disposant de moins de droits, afin que les accès courants n’exigent pas de privilèges administratifs.
Supprimer la base d’exercice
Dans cette étape, vous supprimerez la base de ce laboratoire et ses données de commandes.
L’instance fournie appartient à cet exercice. Vous n’avez pas besoin de conserver les commandes d’exemple ni un instantané final :
aws rds \
delete-db-instance \
--db-instance-identifier orders-db \
--skip-final-snapshot \
--query 'DBInstance.DBInstanceIdentifier'
aws rds \
wait db-instance-deleted \
--db-instance-identifier orders-db
aws rds \
describe-db-instances \
--query 'DBInstances[].DBInstanceIdentifier'
Vous devez obtenir []. Supprimer l’instance enlève la base contenant la table ; cette opération est plus large que DELETE, qui supprime certaines lignes d’une table existante. Conservez l’application et les ressources réseau préparées.
Résumé
Vous avez défini un schéma de commandes avec des contraintes, inséré trois enregistrements et utilisé des filtres et agrégations SQL pour répondre à des questions sur les données. L’application a lu les mêmes lignes dans PostgreSQL. Vous avez ensuite supprimé la base d’exercice tout en conservant l’application et le réseau fournis.
Le prochain laboratoire limite à la fois l’accès réseau et les privilèges de l’application dans la base.
