Projet Integration 08_arcitecture_shemas - dudleydehenau/Ephec GitHub Wiki

Architecture / Schémas

A. Schémas de fonctionnement

  • Schéma Bras Robot : IMG_0251

B. Structure de l'application

  • Comment l'application est structurée.

Maquette du Site Web

Page des composants

composants composant4 composant3 composant2

Page des composants avec les notifications composantsNotif

Page des composants modifier composantModif

Page historique historique

Page paramètres

parametres

Page démarer le tri

demarer demarer2

C. Conception de la DB

Détails sur la conception de la base de données.

Schéma de la DB

Explications de la conception et des différentes relations

Dans le schéma ci-dessus on peut remarquer aisément que la table Component est la table centrale de notre base de données car celle-ci est interconnectée à toutes les autres tables excepté la table Host.

  • Table Component :
    • Cette table est notre table qui contiendra tout les composants de notre stock.
    • Chaque composant étant représenté par un Nom, un Type, une Quantité, une Description et un compartiment attribué.
  • Table Compartment :
    • Cette table contient les informations sur les différents compartiments qui sont généralement attribué à plusieurs composants.
    • Chaque compartiment est représenté par un Nom et une Localisation/emplacement.
  • Table Feature :
    • Cette table contient les descriptions et les images associées à un type de composant.
    • Chaque spécificité est représenté par une Description et une Image du type de composant.
  • Table Type :
    • Cette table contient les catégories / types de composant existant dans la DB.
    • Chaque type étant représentée par un Nom et une valeur référence de Stock idéal.
  • Table Historic :
    • Cette table contient l'historique de toutes les actions effectuée sur un composant.
    • Chaque enregistrement dans l'historique est représenté par une Date, une Action, un ID de Composant et un Compteur.
  • Table Host :
    • Cette table contient les informations (Hostname, First Name et Last Name) de chaque Professeur responsable des Labos d'électronique auquel sera associé une session de tri.
    • Cette table n'est pas liée directement avec les autres tables car il n'est pas nécessaire dans ce cas de figure ci.

D. API

Présentation de l'API et lien vers la documentation.

Présentation de l'API

Nous avons utilisé ici l'API RESTful de base fournie par Supabase avec la Base de données.
Cette API nous fournissant tout ce dont on a besoin pour interagir correctement avec notre base de données.

En réalité les avantages et fonctionnalités sont :

  • Une API prête à l'emploi dés la création de la base de données.
  • Support des opérations CRUD complètes.
  • Filtrage avancés et requêtes SQL complexes.
  • Authentification et sécurité intégrées. L'API respecte les règles de sécurité RLS (Row-Level Security) définies dans Supabase.
  • Clés API fournies pour différencier les accès. Une clé anon pour un usage public sécurisé (accès basiques en lecture seule ou avec restrictions). Et une clé service_role pour des accès complets (idéal pour le backend sécurisé).
  • Gestion des sessions utilisateur, connexions et inscriptions.
  • Et encore pleins d'autres avantages...

Lien vers la Documentation

Ci-dessous vous retrouverez le lien vers la Doc de l'API. Malheureusement la documentation interactive ne vous est pas accessible car il faut se connecter avec un compte Supabase et que vous soyez ajouté au Projet par un Administrateur du Projet.

Lien Doc API : Documentation API

E. Configurations

Fichiers de configuration et précautions liées aux données sensible(RGPD).

Nous n'avons pas vraiment de fichiers de configurations en tant que tel excepté le fait que nous avons un fichier comportant des variables d'environnement permettant l'authentification des personnes se connectant et faisant des requêtes à l'API par le biais du Site Web.