[Core Data] Quel choix de modélisation pour être dynamique

Bonjour,

Voici ma problématique :
Mon application stocke des valeurs, chacune de ces valeurs est rattachée à un indicateur, par exemple :
- l'indicateur chiffre d'affaires peut être relié à 10k€, 20k€, 50k€...

Jusque là tout va bien, j'ai :
- une table Valeur avec un attribut valeur et une liaison to one indicateur
- une table Indicateur avec un attribut indicateur et une liaison to many valeurs

Là où cela se complique c'est quand je dois intégrer des axes (ou segment, on peut nommer cela de différentes manières), par exemple :
- l'indicateur chiffre d'affaires est en fait découpé en 2 :
--- chiffre d'affaires magasin nord : 8k€, 10k€, 40k€
--- chiffre d'affaire magasin sud : 2k€, 10k€, 10k€
--- le total est bien celui de l'exemple cité plus haut

Vous me direz, facile : il suffit de créer une table magasin :D
Mais le problème c'est que je ne connais pas à l'avance tous les axes : c'est variable d'un indicateur à l'autre et non défini au départ :marteau:

Par exemple, toujours pour le chiffre d'affaires, il peut y avoir le pays, le rayon du magasin, le produit... bref tout cela est défini par l'utilisateur et doit ensuite pouvoir faire l'objet de restitution de type :
- le chiffre d'affaire pour le magasin 1 de la produit A
- le chiffre d'affaire pour la produit B pour le magasin 1 et 2
-...

j'ai beau essayer de chercher je n'arrive pas à trouver une solution pertinante.
J'ai pensé à faire un table Axe avec un attribut libelle axe et une relation recursive mais du coup, je suis sur une relation to many - to many (et non pas to many - to one comme pour un organigramme par exemple)

Merci de votre aide :)

PS : j'ai placé cette demande dans Objective - C car la solution est liée spécifiquement aux caractéristiques et limitations de Core Data (on est dans le SQL sans y être)

Citation:

---

Envoyé par gregfreemind

c'est variable d'un indicateur à l'autre et non défini au départ :marteau:

---

Alors une table Segment avec seulement 2 clefs étrangères Valeur et Indicateur, peut-être en couple unique :whistle:

PS: c'est une réponse SQL et pas forcément CoreData :wow:

Sans doute me suis-je mal exprimé (ou alors je ne vois pas bien comment résoudre mon problème avec votre réponse)
Voici un exemple, format fichier plat de ce que je peux être amené à intégrer dans la base :

VILLE	MAGASIN	RAYON	INDICATEUR	VALEUR
Paris	Mag1	Fruits	Chiffre d'affaire	100€
Paris	Mag2	Fruits	chiffre d'affaire	200€
Lyon	Mag3	Legumes	chiffre d'affaire	400€
Lyon	Mag3	Fruits	chiffre d'affaire	150€

Les axes (ou segments) ici sont Ville, Magasin et Rayon

Et, dans ce même modèle devoir enregistrer :

ENTREPOT	RAYON	INDICATEUR	VALEUR
Sud	Fruits	Sotck	1 000
Nord	Fruits	Sotck	2 000
Nord	Legumes	Sotck	1 000

Ici les axes sont Entrepot et Rayon

En gros je vais avoir une infinité de possibilités d'axes.

Si je reprends votre proposition, je vais certe pouvoir associer un couple valeur-indicateur a plusieurs axes mais sans aucun lien entre les axes :
- si je veux toutes les valeurs pour l'indicateur chiffre d'affaire pour du MAGASIN = Mag1 : pas de soucis
- si je veux toutes les valeurs pour l'indicateur chiffre d'affaire pour les rayons Fruits de la ville Paris : ça ne marche pas car :
------ si je fais SEGMENT = FRUIT AND SEGMENT = PARIS : forcement ça marche pas (0 lignes)
------ si je fais SEGMENT = FRUIT OR SEGMENT = PARIS : ça ne marche pas non plus car il va me sortir les lignes voulues mais aussi la ligne avec le rayon fruits de la ville de Lyon (3 lignes)

Qu'en pensez-vous ?

Reflexion faite, je pense avoir trouvé à partir de votre proposition :
- je fais un select avec SEGMENT = FRUIT OR SEGMENT = PARIS, je ne remène pas le segment dans le résultat de la requête mais fais un COUNT sur SEGMENT et un GROUP BY sur les champs indicateur et valeur, si le COUNT me retourne 2 je garde la ligne, sinon je la rejète.

Du coup si j'ai un 3e critère je garde les lignes avec un COUNT à 3, etc...

Je vais tester cela en réel, mais à priori ça va marcher :)
Merci de votre aide.

Parce que ta valeur est composée :mrgreen:

Je ne suis pas spécialiste SQL tant que cela mais en gros il faudrait faire une truc comme cela, valide 1-2-3ième formes normales

table VILLE (id_ville, ville)
table MAGASIN (id_magasin, magasin)
table ENTREPOT (id_entrepot, entrepot)
table RAYON (id_rayon, rayon) // On mélange les rayons ou alors faire 2 tables
table INDICATEUR (id_indicateur, indicateur) // On mélange les indicateurs ou alors faire 2 tables
table VALEUR (id_valeur, valeur) // On mélange les valeurs ou alors faire 2 tables

table SEGMENT_1 (id_ville, id_magasin, id_rayon, id_indicateur, id_valeur)
table SEGMENT_2 (id_entrepot, id_rayon, id_indicateur, id_valeur)


D'après l'exemple l'indicateur du segment 1 est toujours "chiffre d'affaire" et celui du segment 2 "Stock': donc on peut supprimer la table INDICATEUR.

Ou éventuellement on peut faire une table INDICATEUR (id_indicateur, indicateur, id_valeur)
Avec
table SEGMENT_1 (id_ville, id_magasin, id_rayon, id_indicateur)
table SEGMENT_2 (id_entrepot, id_rayon, id_indicateur)


Par contre les jointures vont faire mal 8O