Normalisation de mon SGBD

Bonjour à tous ! :D


Je suis en train développer une application qui se base notamment sur MySQL.

Cette dernière tourne depuis plusieurs mois mais la base de données à été faite à l'arrache et j'aimerais repartir sur une base propre.

Les tables que j'ai actuellement sont les suivantes:

Table DATA (id, nodename, trunknb, trunkname, date, valeurLibre, valeurOccupé, valeurTotal)
Table NOMTRUNK(nomtrunk, nodename, trunknb, fulltrunknb)

Ma table DATA est remplie toutes les 2 minutes grâce à une appli java et ma table NOMTRUNK me permet juste de récupérer un nom compréhensible pour trunknb / trunkname, (le trunkname étant incompréhensible lorsqu'il est récupéré sur les serveurs).



J'ai donc essayé de faire le modèle Entité-Association suivant:

Pièce jointe 180747

Mais très vite c'est devenu le bor*el dans ma tête xD


Du coup comment suis-je sensé faire?
Je ne pense pas que mes premières tables soient super, mais j'ai peur de me compliquer la vie avec le modèle Entité-Association que je suis en train de faire.

Par exemple si je n'ai plus la table DATA où vais-je mettre les information qui sont récupérées automatiquement ?
Dans la table Faisceau peut-être mais dans ce cas il faudrait un ID à chaque tuple pour éviter d'écraser les données précédentes non?

Par avance je vous remercie pour votre aide,
Cordialement,
FLIGHT'

Bon, pour faire simple :

J'ai rien compris
(et je doute être le seul)

Je pense que le "bordel" comme vous dites, vient pas trop de votre modélisation, mais de l'idée que vous avez du problème dans votre tête.

Y'a moyen de tout poser sur la table ? On vous aidera à faire le tri promis.

Déjà, pour notre culture :
- Votre application, elle est censée faire quoi ?
- C'est quoi les données que vous récupérez ?
- Y'en a d'autres ?
- Vous en faites quoi ?

Bref : le machin bizarre, de la façon que vous le présentez, ça donne juste pas envie d'y toucher :D

Merci pour ta réponse StringBuilder :)

Effectivement même dans ma tête je ne sais pas si c'est très clair...


Mon appli récupère des information d'utilisation de faisceaux téléphoniques.

Les données récupérées sont quand à elles celles de la table DATA, elles y sont mises de façon brute et sans traitement.

J'ai donc un numéro de site, l'identifiant de faisceau, le nom de celui-ci (mais qui est incompréhensible car c'est une référence) la date et l'heure aux quelles les mesures ont été prises et le taux d'occupation (nombre lignes non occupées, occupées et le nombre total de lignes).


Afin d'avoir un nom compréhensible pour pouvoir les afficher sur de jolis graphiques, j'ai créé la deuxième table (NOMTRUNK) qui me permet de ''traduire'' la référence du trunk en un nom Français.

Est-ce plus clair maintenant ? ^^

Ce que je voudrais c'est garder la même chose mais en plus propre :)

FLIGHT'

Ah, c'est beaucoup plus clair d'un coup :D

En revanche, en regardant les nouvelles tables que vous souhaitez créer, je ne vois pas de rapport avec les tables existantes (mise à part l'histoire du faisceau) ?

En fait ma principale question est du coup :
Mes tables actuelles sont telles optimisées ou peut-on faire mieux ?

Je me suis dit qu'elles n'étaient pas forcément top top donc j'ai essayé de repartir de zéro en les "normalisant".

Mais au final je suis perdu dans ce que je viens de modéliser, j'ai l'impression que ces tables ne conviennent plus à ce dont elles devaient être destinées...

Suis-je clair ? x)


FLIGHT'

Au niveau de faisceaux/sites, je suis pas callé, je vois pas ce que ça veut dire.

On va partir du principe que tu as N sites contenant chacun M faisceaux.

Pour moi, on a donc :

Une table "SITE" :
- idsite
- nomsite

Une table "FAISCEAU" :
- idfaisceau
- idsite (fk vers site.idsite)
- nomfaisceau

Une table "MESURE" :
- idmesure
- idfaisceau (fk vers faiseau.idfaisceau)
- date
- valeurLibre
- valeurOccupé

Ensuite, tu n'en dis pas assez à propos de la "licence" dont il est question dans ta tentative de nouvelle modélisation...

Soit ça parle d'emblée pour un expert des telecom, que je ne suis pas, soit il manque quelques éléments dans ton explication ;)

Bonjour :)

Les faisceaux ce sont justes les lignes téléphoniques et les sites ben... juste les endroits où sont nos sites, par exemple un à Paris, un un Milan et un à Oslo ^^

Et ces sites sont regroupés dans différents noeuds, dans un noeud il y a plusieurs sites et un site ne peut appartenir qu'à un noeud.
Seul problème c'est qu'un faisceau peut exister plusieurs fois mais sera unique pour un noeud, du coup j'ai besoin d'avoir idnoeud & idfaisceau comme clé primaire?

Pour les licences (qui seront intégrées plus tard au projet mais autant préparer la chose immédiatement ^^) se sont les nombres de téléphones que l'on peut avoir par noeud.

Vala, c'est peut être mieux expliqué comme cela?

FLIGHT'

Beaucoup plus clair :)

Mise à part les cardinalités, que je ne sais pas relire (d'autant que j'en ai jamais vu des comme ça, visiblement c'est pas du MERISE), pour moi c'est bon à un détail près : un faisceau n'évolue pas dans le temps. Ce sont le nombre de lignes occupés et libres pour le faisceau qui évoluent. Donc une table mesure en plus, avec un lien vers faisceau qui comprend la date, le nombre de lignes libres et occupés.

Citation:

---

Beaucoup plus clair

---

Haha super ! :D

Citation:

---

Mise à part les cardinalités, que je ne sais pas relire (d'autant que j'en ai jamais vu des comme ça, visiblement c'est pas du MERISE)

---

Ha... C'est embêtant c'est ce que j'ai essayé de faire pourtant x)

En fait j'ai jamais appris à modéliser une BDD, en gros en cours SQL on a juste fait des requêtes (ainsi que des vues, les droits, les LOCKs, COMMITs etc), et c'est le genre de "logique" où j'ai du mal (sauf niveau requête ou la plupart du temps ça va).

Par conséquent je me suis informé sur Internet mais apparemment je n'ai pas tout compris :oops:

Du coup comment devraient être les cardinalités ?

Citation:

---

Ce sont le nombre de lignes occupés et libres pour le faisceau qui évoluent. Donc une table mesure en plus, avec un lien vers faisceau qui comprend la date, le nombre de lignes libres et occupés.

---

D'accord, donc en fait pour après faire un éventuel historique de l'utilisation des liens je dois aller taper dans la table MESURE, et après il faut que je me débrouille pour aller faire en sorte de matcher idfaisceau dans la table FAISCEAU afin de récupérer par exemple le nom "lisible" de ce dernier.



Si j'ai bien compris pour les BDD, lorsque l'on a plusieurs données, typiquement des données qui bougent souvent (comme des mesures) et des données qui ne changent presque pas (comme mes faisceaux) cela est plus propre de les séparer?


Merci encore pour ton aide StringBuilder :)

FLIGHT'

Pour faire simple, parmi les règles de base de la modélisation d'une base de données, aucune table ne doit contenir la moindre donnée dupliquée.

Donc si dans une table tu as "date, nom", et que quelque soit la valeur de "date", celle de "nom" reste identique, alors il faut séparer les deux colonnes dans deux tables différentes.

Okay c'est beaucoup plus clair pour moi déjà ^^


Donc pour résumer, je peux faire ça avec 4 tables?

Une table "SITE" :

- nomSite
- idSite
- nomNoeud

Une table "FAISCEAU" :

- idFaisceau
- idSite
- nomFaisceau
- nomNoeud le faisceau ne pouvant être identifié qu'avec idFaisceau + nomNoeud

Une table "MESURE" :

- idFaisceau
- les diverses valeurs
- ...

Une table "LICENCE" :

-Le sais pas trop encore mais nomNoeud c'est sur

Et je n'ai pas besoin d'une table NOEUD ? C'est une peut inutile de faire une table avec une seule colonne non?


FLIGHT'

Je pense que si, tu peux créer une table NOEUD.

Et ta table mesure, elle doit faire référence à la table faisceau à l'aide de sa clé entière, donc il faut rajouter "idnoeud" dedans.

Okay je vois un peu mieux où j'en suis mais je reste avec des données dupliquées dans mes tables...

En dehors de la table mesure qui aura des données dupliquées (idFaisceau) ce qui est "normal" car il y aura plusieurs entrées un même lien.

Mais pour ma table FAISCEAU par exmple, si je met une colonne nomNoeud celui-ci sera présent plusieurs fois dans la table (car il y a plusieurs faisceaux par noeud).

Et il faut à un moment où à un autre que je fasse un match entre un faisceau et un noeud et je ne vois pas comment faire pour ne pas avoir de données dupliquées....

J'aime le SQL mais ça me retourne la têêêêêêêêête :mouarf: :koi:


FLIGHT'

EDIT : En fait, ce que je ne comprend pas trop, c'est que l'on dit qu'il ne faut pas de redondance mais par exemple dans une BDD lambda (sur un site de commerce) pour une table CLIENT, chaque client à son ID qui lui est propre mais il y aura forcément plusieurs clients qui auront le même nom ou qui seront du même sexe... C'est ça que je ne pige pas :)

Comme je disais, NOEUD doit être une table à part, avec un ID et un NOM, et faisceau doit faire référence à cette table, et non pas stocker directement le nom du noeud.

Euuuh okay donc ceci devrait fonctionner ?


(Oups petit problème d'image j'arrive pas à avoir un truc propre désolé)

Mais après ça va être la galère pour les requêtes....