Skip to content

Fredericdrnl/BDD-LFL-2022

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Base de donnĂ©e LFL 🗄

Auteurs : Anthony ELUECQUE, Benjamin FOURNIER, Frédéric DOURNEL

Sommaire 📃

  • 1 Introduction
    • 1.1 Le thĂšme choisi
      • 1.1.1 Pourquoi ce sujet
      • 1.1.2 L'origine des donnĂ©es
      • 1.1.3 Notre base de donnĂ©es en chiffres
      • 1.1.4 Documentation Ă  propos de ce sujet
    • 1.2 Travail en groupe
  • 2 La base de donnĂ©es
    • 2.1 Structure du projet
      • 2.1.1 Le MCD
      • 2.1.2 Le MLD
    • 2.2 La mise en pratique
      • 2.2.1 CrĂ©ation des tables
      • 2.2.2 Ajouts & Organisation des tuples
      • 2.2.3 La mĂ©thodologie
    • 2.3 La crĂ©ation des fonctions
      • 2.3.1 Les fonctions utilitaires pour L'utilisation de la BDD
      • 2.3.2 La gestion automatique du classement
  • 3 Le site web associĂ© Ă  la BDD
    • 3.1 Les outils
      • 3.1.1 Vue JS | Frontend
      • 3.1.2 Node JS | Backend
  • 4 Conclusion
    • 4.1 Les limites du projet
    • 4.2 Conclusion
  • 5 Mode d'emploi
    • 5.1 Comment consulter la BDD
    • 5.2 Comment consulter le site web associĂ© Ă  la BDD
    • 5.3 Les diffĂ©rentes routes de l’API

1 Introduction 📌

Lors de notre 3Ăšme Semestre de BUT, nous avions eu pour mission la rĂ©alisation d’une base de donnĂ©es sur un championnat par Ă©quipe ou individuel avec un classement automatique.
Pour cela, Monsieur CAPITAINE nous a demandĂ© l’utilisation de fonctions trigger sur le langage plpgsql.
Cette SAÉ nous a permis de valider plusieurs apprentissages critiques :

  • Concevoir , gĂ©rer , administrer et exploiter les donnĂ©es de l'entreprise et mettre Ă  disposition toutes les informations pour un bon pilotage de l’entreprise
  • DĂ©velopper (c’est-Ă -dire concevoir, coder, test et intĂ©grer) une solution informatique pour un client

1.1 Le thĂšme choisi

1.1.1 Pourquoi ce sujet

Nous avons choisi comme sujet le championnat de la ligue Française de League Of Legends (LFL).
Étant des joueurs de ce jeu, ils nous semblaient intĂ©ressant de crĂ©er une base de donnĂ©e sur celui-ci , afin de mettre en application nos connaissances en SQL sur un sujet qui parlait Ă  tout le groupe.

1.1.2 L'oreigine des données

Bien qu’il existe des bases de donnĂ©es dĂ©jĂ  complĂštes sur ce championnat, nous n’avions pas les droits sur celle-ci, nous avons donc dĂ» partir de 0 et rĂ©flĂ©chir Ă  une solution efficace pour rĂ©pondre Ă  la problĂ©matique posĂ©e.
A travers les diffĂ©rents sites faisant rĂ©fĂ©rence Ă  ce championnat, nous avons rĂ©cupĂ©rĂ© des informations, statistiques, 
, tout ce qui semblait ĂȘtre exploitable.
Cependant, se basant sur un jeu et voulant reflĂ©ter parfaitement les matchs qui se sont rĂ©ellement dĂ©roulĂ©s et toutes les mĂ©caniques du jeu, nous vĂ©rifions chaque donnĂ©e pour s’en assurer.
Nous avons notamment utilisé notre connaissance sur le jeu pour pouvoir apporter, compléter les informations trouvées sur les différents sites internet.

1.1.3 Notre base de données en chiffres

Joueurs
50
Equipes
10
Champions
163
Matchs 90

1.1.4 Documentation Ă  propos de ce sujet

Pour comprendre comment se déroule le championnat de la LFL nous avons rédigé une documentation "explicationLFL" pour avoir plus de connaissances concernant le championnat que nous avons choisi.
Ce document donne des informations sur le nom des équipes, des joueurs et des coachs mais aussi sur le déroulement du championnat pour élire l'équipe championne de France.
Par ailleurs, nous avons aussi rédigé une documentation "explicationLoL" qui explique le déroulement d'un match de League Of Legends. Ce document donne des explications sur les champions et leurs spécificités, les rÎles jouables, la génération d'or et d'expérience.
Ces 2 documents sont complémentaires mais permettent de comprendre plus en détail notre sujet.

1.2 Travail en groupe

Afin de mettre en application ce que nous venons de voir en gestion de projet et l’élĂ©ment moteur d’un groupe, c'est-Ă -dire la communication, nous avons organisĂ© les travaux pour que chaque membre du groupe ait un tĂąche Ă  effectuer.
Pour que chacun puisse accĂ©der en temps rĂ©el au script de la base de donnĂ©es et voir les modifications de chacun, plusieurs outils existent comme Le Live Share de Visual Studio Code, il s'agit d'une extension qui permet de travailler en mĂȘme temps sur un mĂȘme fichier Ă  la maniĂšre d'un Google Doc.
Afin d’amĂ©liorer la communication du groupe en utilisant les outils mis Ă  nos dispositions, Discord nous a semblĂ© opportun pour Ă©changer sur le projet.
Cependant, l’usage de Github nous a semblĂ© indispensable afin de garder un historique de nos versions.

2 La base de donnĂ©es 📩

2.1 Structure du projet

2.1.1 Le MCD

Afin de mieux visualiser la structure de la base de donnée. Nous avons modélisé un ModÚle Conceptuel de données.
A partir de nos recherches et de nos connaissances, nous avons construit ce MCD afin qu’il soit Ă©volutif , il serait possible de revenir dessus, et d’ajouter de nouvelles tables sans modifier celles-existantes. Ce principe fait rĂ©fĂ©rence aux principes SOLID , ou la modification de l’existant n’est pas nĂ©cessaire Ă  l’ajout.
Cette conceptualisation et la construction des liens a Ă©tĂ© rĂ©alisĂ©e en groupe avant l’insertion des tuples, afin de s’assurer que sa structure soit optimale.
Un avis à notre professeur référent, Monsieur CAPITAINE a notamment été demandé, et nous avons apporté des modifications par rapport aux remarques

Nous avons utilisé le logiciel Looping prévu pour cela : https://www.looping-mcd.fr/

đ™‡Ă©đ™œđ™šđ™Łđ™™đ™š :

𝙟𝙖đ™Ș𝙣𝙚 : Tables de la base de donnĂ©es
𝙗𝙡𝙚đ™Ș : associations entre les tables
𝙡𝙞𝙚𝙣 : dĂ©finit le type d'association entre les tables

Le MCD (ModÚle conceptuel de données)

2.1.2 Le MLD

Une fonctionnalitĂ© du logiciel Looping nous permet Ă  partir d’un MCD de crĂ©er automatiquement par rapport Ă  nous ajouts un MLD.
Par cet outil, nous pouvons voir le contenu de la table avec la mise en évidence des clés primaires (en gras et souligné) et étrangÚres (en gras avec une couleur bleu et soulignées).

MLD

2.2 La mise en pratique

2.2.1 Création des tables

Notre MLD nous a permis d’ajouter facilement les tables dans notre script SQL , puisque celui-ci permet de connaĂźtre chaque attributs de table, ainsi que les clĂ©s primaires et Ă©tranges.
En prĂ©vention d’un classement automatique, nous avons en parallĂšle de cette crĂ©ation commencer Ă  rĂ©flĂ©chir sur les fonctions et les triggers associĂ©s.
En effet, nos triggers permettant des vérifications avant et aprÚs ajout de tuple sur certaines tables, il était important de coordonnées ses 2 tùches.

2.2.2 Ajout & organisation des tuples

Comme dit auparavant , les BDD ne nous Ă©taient pas accessibles.
Nous avons insĂ©rĂ© tous les tuples de notre base de donnĂ©es Ă  la main (environ plus de 1200 insertions) . Cela nous a pris beaucoup de temps, si bien que les crĂ©neaux rĂ©servĂ©s Ă  cette SAE ont Ă©tĂ© dĂ©passĂ© (plus de 15 heures d’insertions de tuples au lieu des 7H30 pour toute la SAE)
Pour cela une mĂ©thodologie (sur laquelle nous nous attarderons juste aprĂšs) a dĂ» ĂȘtre mise en place.

2.2.3 La méthodologie

Une mĂ©thode trĂšs stricte qui nous a permis de ne pas se perdre dans toutes ces donnĂ©es mais surtout pour ne pas faire d'erreur dans l'entrĂ©e de ces informations est l’utilisation de postman.
Cette méthodologie a été appliquée plus particuliÚrement sur la table Historiques_matchs , ou un seul match possÚde 10 tuples (5 par équipes et donc 1 par joueur) sur les statistiques exploitable de celui-ci.
Les autres membres du groupe ont notamment vĂ©rifiĂ© tuple aprĂšs tuple pour s’assurer de la concordance entre les ajouts et l’existant.
Cette stratégie nous a permis de rentrer les tuples sans perdre de temps, et pouvoir passer à la partie du classement automatique.

2.3 La création des fonctions

Nous avons pour optimiser cette base de données et la rendre automatique, créer plusieurs fonctions.
Pour répondre à la problématique posée, la création de triggers permettant la gestion automatique du classement a été une grande partie de notre projet.
Cette gestion automatique nĂ©cessite des fonctions intermĂ©diaires permettant d’exploiter plus facilement la base de donnĂ©es (GETTER, Calcul automatique, 
)
Pour notre championnat, nous avons décidé de créer plusieurs classements puisque celui-ci se déroule sur plusieurs semaines. Nous avons donc décidé de créer un classement par semaine, mais aussi sur la totalité du championnat (SPLIT)
Un trigger nous a semblé opportun sur les statistiques de chaque équipe du championnat aprÚs chaque ajout de match.

2.3.1 Les fonctions utilitaires pour l'utilisation de la BDD

- getNomChampion(id_champion integer) ▶ varchar
Permet de trouver le nom d'un champion Ă  partie de son id

- AfficherChampionsBanMatch(id_match integer) ▶ void
Permet d'afficher les 10 champions banni d'un match avec l'id du match

- AfficherChampionsChoisiMatch(id_match integer) ▶ void
Permet d'afficher les 10 champions choisi d'un match avec l'id du match

- nbFoisChampBan(nom_champion varchar) ▶ integer
Permet de trouver le nombre de fois qu'un champion a été banni à partir du nom de ce champion

- rateBanChamp(id_champion integer) ▶ real Permet d'obtenir le pourcentage que le champion a Ă©tĂ© banni sur tous les matchs dĂ©jĂ  jouĂ©s Ă  partir de l'id de ce champion

- nbFoisChampPick(nom_champion varchar) ▶ integer
Permet de trouver le nombre de fois qu'un champion a été choisi à partir du nom de ce champion

- calcul_winrate_champion(nom_champion varchar) ▶ decimal
Permet d'obtenir le taux de match gagné par champion à partir du nom de ce champion

- calcul_winrate_equipe(id_equipe integer) ▶ decimal
Permet d'obtenir le taux de match gagné par équipe à partir de l'id de cette équipe

- calcul_kda_equipe(id_equipe integer) ▶ decimal
Permet d'obtenir le kda par Ă©quipe Ă  partir de l'id de cette Ă©quipe

- calcul_kda_joueur(id_joueur integer) ▶ decimal
Permet d'obtenir le kda par joueur Ă  partir de l'id de ce joueur

2.3.2 La gestion automatique du classement

3 Le site web associĂ© Ă  la BDD 🌐

Bien que cette partie n’était pas obligatoire, il nous semblait essentiel que cette base de donnĂ©es soit utilisĂ©e pour un site web pour plusieurs raisons. La premiĂšre Ă©tait d’apprendre Ă  utiliser nos connaissances dans divers domaines et de les combiner en un seul projet : une application Web reprenant notre SAE Actuel : une base de donnĂ©es. La seconde pour le seul membre du groupe en parcours dĂ©veloppement et Application, ELUECQUE Anthony de rĂ©aliser un projet de fond lors des entretiens de Stage.

Ce site web pour communiquer avec une base de données se compose en 2 parties : le backend et frontend.

Le Frontend est la partie que l’utilisateur du site voit , c’est le design, les boutons, 
 Le backend est la communication entre la base de donnĂ©es et le site web.

Il permet de lier cette base de donnĂ©es Ă  une API et de pouvoir, Ă  partir du site web, envoyer des requĂȘtes HTTP vers l’API. Cette interface de programmation d’application est constamment mise Ă  jour par rapport Ă  notre base de donnĂ©es sur postgresql.

L’intĂ©rĂȘt de cette application web dans ce projet Ă©tait Ă  partir de notre base de donnĂ©e de pouvoir interagir avec celle-ci en Ă©tant un simple utilisateur et non un dĂ©veloppeur postgresql sur ubuntu. Pour cela, il est Ă©vident qu’une application web soit plus explicite qu’un terminal noir et blanc

3.1 Les outils

3.1.1 Vue JS | Frontend

Doc : https://vuejs.org/guide/introduction.html

3.1.2 Node JS | Backend

Doc : https://nodejs.org/docs/latest-v17.x/api/
Framework express : https://expressjs.com/

4 Conclusion 📌

4.1 Les limites du projet

Il y a eu quelques problĂšmes Ă  la rĂ©alisation de ce projet comme, une restriction au niveau du temps qui Ă©tait infime comparĂ© au projet qui Ă©tait Ă  rĂ©aliser, ce projet devait ĂȘtre rĂ©alisĂ© en mĂȘme temps que certain autre projet, il allait donc jongler entre plusieurs projets.
Puis pour notre base de données nous avons rempli à la main plus de 2000 tuples ce qui nous a pris un temps considérable et ce qui nous a ralenti à la finalisation de ce projet.

4.2 Conclusion

A la fin de ce projet, nous avons rĂ©ussi Ă  rĂ©aliser un classement automatique fonctionnel de la LFL lors du Summer Split 2022. Ce classement, oĂč une page web est associĂ©e Ă  notre base de donnĂ©es, permet d'ajouter des Ă©quipes, des joueurs, des matchs et permet aussi de les supprimer. Nous avons aussi Ă©crit des documents explicatifs concernant le jeu League Of Legends en lui mĂȘme puis, un autre sur le fonctionnement du championnat de la LFL, ces documents permettent de comprendre facilement mĂȘme pour un dĂ©butant.
Ce projet qui s'est effectué en groupe, à permis une amélioration de la communication au sein d'un groupe informatique, ce qui est une compétence indispensable pour les années suivantes.
Pour conclure que ce projet a été réalisé, malgré les problÚmes rencontrés, en utilisant une bonne communication au sein du groupe et une bonne répartition des travaux en fonction des compétences de chacun.

5 Mode d'emploi 📜

5.1 Comment Consulter la BDD

Vous pouvez consulter la base de données en utilisant le site web, ou bien passer par un terminal ubuntu (version 20+) avec postgres. Nous recommandons de passer par notre vidéo, qui explique en détail comment la consulter.

5.2 Comment consulter le site web associé à la BDD

Nous vous recommandons de suivre la vidéo, nous ne détaillerons pas les étapes ici mais les grandes lignes.

  • Lancer sur deux fenĂȘtres visuals studio codes les fichiers backend et frontend du site web.
  • Dans le fichier backend, taper dans un terminal npm run dev
  • Puis sur un navigateur, taper http://localhost:3000/ + la route de votre choix
  • Dans le fichier frontend , taper dans un terminal npm run serve
  • A nouveau dans un navigateur, taper http://localhost:8080 ou http://localhost:8081 (dĂ©pend des opĂ©rateurs)

5.3 Les diffĂ©rentes routes de l’API

Routes (Ajouter aprĂšs http://localhost:3000/)
Commandes SQL derriĂšre cette route Explication de la commande SQL
/matchs/
SELECT * FROM Matchs; Liste de tous les matchs
/matchs/:id_match
SELECT * FROM Matchs WHERE id_match = :id_match; Information d’un match
/champions SELECT * FROM Champions; Champions du jeu
/equipes SELECT * FROM Equipes; Liste de toutes les Ă©quipes de la LFL
/equipes/:id_equipe SELECT * FROM Equipes WHERE id_equipe = :id_equipe; Informations d’une seule Ă©quipe Ă  partir de son identifiant
/equipes/:id_equipe/kda SELECT * FROM calcul_kda_equipe(:id_equipe); KDA de l’équipe
/equipes/:id_equipe/coach SELECT * FROM Coachs WHERE id_coach = (SELECT id_coach FROM Equipes WHERE id_equipe = :id_equipe); Coach de l’équipe
/equipes/:id_equipe/stats SELECT * FROM Statistique_lfl WHERE id_equipe = :id_equipe; Statistiques des matchs d’une Ă©quipe Ă  partir de son identifiant