[DavidZed]

Hello,

Pour faire les choses dans l’ordre, et vu que tu débutes, je me permet quelques rappels pour m’assurer que tu as bien commencé par certains prérequis :

• être dans un environnement de développement (ou environnement développeur)
• avoir créé une solution “non gérée” pour ton projet Ce qui te permettra de bien gérer l’ALM de ton projet

<h2>Pour ce qui est de ton sujet, les relations :</h2>

Il y a trois types de relations possibles dans dataverse, nous allons prendre une relation entre professeurs, Classes et élèves pour illustrer :

• 1:N (Un à plusieurs)
  • Une classe a plusieurs élèves
• N:1 (Plusieurs à Un)
  • Chaque classe a un seul professeur principal (Mais un prof peut être le prof principal de plusieurs classes)
• N:N : Plusieurs à plusieurs
  • Un professeurs a plusieurs classes, une classe a plusieurs professeurs

<h2>Quelques généralités : </h2>

Les relations 1:N et N:1 sont rigoureusement identiques, seule la cardinalité change. Dans notre exemple on peut voir que les tables élèves et professeurs ont deux relations (Dans Dataverse tu as le même exemple avec les tables contacts et comptes) :

• La relation qui indique qu’un professeur est le prof principal de plusieurs élèves / Un èleve ne peut avoir qu’un prof principal.
• La relation qui indique qu’un élève peut avoir cours avec plusieurs professeurs / que les professeurs peuvent faire cours à plusieurs élèves.

Une table peut également avoir une relation avec elle même.

On peut remplacer une relation N:N par une table intérmédiaire et deux relations 1:N, pour reprendre l’exemple de tout à l’heure (N professeurs : N classes), on peut remplacer cette relation en créant une table “Cours” qui contiendrait:

• une relation 1:N vers les professeurs
• une relation 1/N vers les classes
• éventuellement des informations supplémentaires ratachées au cours : la matière, les horaires, la salle etc… (ce qui serait impossible avec une relation N:N)
• Cette approche est à privilégier dans les applications Canevas car la gestion des relations N:N y est fastidieuse

<h2>Pour créer une relation</h2>

On peut passer par section relations d’une table, ce qui permet de créer n’importe quel type de relation et cardinalité :

Mais pour les relations N:1, il y a plus simple (Et surtout plus intuitif !) : il suffit d’ajouter une colonne de type recherche / lookup dans la table N

L’inverse est également vrai, si on crée une relation 1:N ou N:1 directement dans la section “Relations” d’une table, une colonne lookup / recherche sera créé dans la table N

Un nouvel outil permet de créer des tables et les liasons entre elles à l’aide d’un éditeur d’ERD, qui offre une interface visuelle également plus intuitive, mais attention, il est utilisé surtout pour créer de nouvelles tables et l’ajout de tables existentes n’est pas encore pris en charge (ça arrivera prochainement)

Quelques ressources pour aller plus loin :

Training path “débuter dans Dataverse”

[martial]

Merci pour ces rappels très intéréssants, mais je crois j’ai du mal à le contextualiser dans mon cas.

En effet, j’ai un batiment avec une enveloppe donc plusieurs murs , et chaque mur a des caracteristiques différentes en plus soit des portes ou des fenetres (qui ont chacune leur caractéristiques) ceux ci avec la liste déroulantes en cliquant sur etats des lieux. En effet cela me ferais plusieurs table à remplir? En effet voici les relations que j’ai monté et j’aimerais avoir un avis merci et si je peux avoir moins de table ou visionner dirreter directement tout ces champ sur le minimum de table possible pour faire un logiciel de collecte simple.

Merci pour votre temps et vos conseils.

[R3dKap]

Salut @martial,

Toujours hyper intéressant la phase de conception du modèle de données… Surtout que c’est critique pour une implémentation aisée dans l’application qui va suivre… 😉

Au premier abord comme ça, je pense que c’est pas mal.

Quelques remarques/questions :

1. Je vois que les 2 entités Plancher (haut et bas) sont très similaires : y’a p’têt moyen d’optimiser. Peut-être une seule entité Plancher avec un Type plancher qui peut prendre 2 valeurs (haut et bas). Mais je vois qu’il y a déjà dans chaque entité un Type plancher propre à chacun. P’têt trouver un autre nom… A creuser…
2. Est-ce que la notion d’enveloppe représente uniquement l’enveloppe externe du bâtiment ou celle de chaque pièce du bâtiment ? Parce-que si ce n’est que l’enveloppe externe, comme il n’y en aurait qu’une seule par bâtiment, tu pourrais éliminer l’entité Enveloppe et connecter les entités situées actuellement sous Enveloppe directement à celle du bâtiment.
3. Pour l’éclairage, je suis surpris qu’il ne soit pas associé à l’enveloppe si cette dernière représente chaque pièce du bâtiment : car chaque pièce a son éclairage. Ou peut-être s’agit-il uniquement de l’éclairage externe.

Pour info, ton modèle de données va potentiellement évoluer pour te faciliter la vie dans l’application selon les fonctionnalités que tu vas vouloir mettre en place. Il m’arrive souvent de répéter certaines informations d’une entité dans une autre afin de me faciliter le filtrage des données. Il m’arrive aussi de créer des champs de compteurs pour comptabiliser les enfants d’une entités (ça permet de gagner en perf dans l’app puisqu’il te suffit d’afficher le champ plutôt que de faire un CountIf() ou un CountRows(Filter(...))). Exemple : dans Parois, un champ Nombre de fenêtres et un autre Nombre de portes… 😉 A toi de gérer les compteurs lors de l’ajout/suppression des portes et fenêtres.

Faut pas hésiter à rajouter des champs si tu estimes que ça te facilite la vie côté app…

Voilou…

[martial]

1) effectivement , je peux optimiser sur le type le plancher, belle remarque merci.

2) je vais faire simple pour le moment me focaliser uniquement sur l’enveloppe externe du batiment ( pour faire mes audits pour le tertiaire (magasins….), je migrerais vers les maisons quand j’aurais mieux maitriser pour faciliter les releves de mes techniciens sur site.

Merci une fois de plus pour vos remarques et vos suggestions. Je me met au travail.

Faut que je reussisse a faire un bon background, c’est la base👍.

[martial]

bonjour,

Svp j’aimerais que les deux tables fenetres et portes possèdent une tables communes ouvertures.

en fonctions du type d’ ouvertures soit les informations de fenetres apparaissent si fenetres, portes si portes et les deux si présent. J’essaye de le faire depuis mais je galère.

ou suis je obligé d’avoir les deux tables fenetres et portes.

Merci pour votre expertise et vos solutions.

[R3dKap]

Tu peux nous détailler les éléments des ouvertures en précisant quels champs pour fenêtre et lesquels pour porte ?

[martial]

Sans soucis l’element ouverture peut etre portes ou fenetres.

l’élément porte a pour champ type, longueur, largeur, type de vitrage, gaz.

l’élément fenetre a pour champ type longueur, largeur, presence de vitrage(si oui les autres champs), pourcentage de vitrage, type de vitrage, gaz

[martial]

deux champs suplementaire photo fenetre et photo porte

[R3dKap]

Ok. Mais du coup je vois pas l’intérêt d’avoir une table supplémentaire Ouverture dans laquelle il y aurait qu’un seul champ Type (Fenêtre et/ou Porte).

Ton objectif c’est de regrouper les champs communs dans Ouverture et de n’avoir dans Fenêtre et Porte que les champs spécifiques aux fenêtres et aux portes ?

IMPORTANT : est-ce que tu fais une application model-driven ou une canevas ? Passke dans la canevas, tu peux très bien afficher les champs comme bon te semble en fonction de tes données. Dans la model-driven c’est plus compliqué.

Dans ce dernier cas (model-driven), il faudrait probablement que tu utilises un lookup polymorphique : https://learn.microsoft.com/fr-fr/power-apps/maker/canvas-apps/working-with-references

J’ai encore jamais utilisé perso, mais ça pourrait répondre à ton pb…

[martial]

bonjour merci pour la réponse c’est une application canevas. désolé si mes questions sont pas très précises. Je débute, merci pour votre temps et aide cela m’est d’une très grande aide. merci

[R3dKap]

Ok. Vu que c’est une canevas, tu peux faire quasiment tout ce que tu veux. Par contre, n’hésite pas à expliquer ici comment tu vas structurer ton application. Comme je pourrais t’aider à la concevoir proprement.

Si tu peux juste décrire pour l’instant les écrans que tu as prévu, avec les différentes actions possibles sur chaque écran ça serait déjà un bon début.

Je pourrais aussi t’expliquer comment gérer tes données intelligemment grâce aux propriétés améliorées des composants. Et te donner des bonnes pratiques générales…

Si tu as déjà commencé, tu peux aussi mettre ici des captures d’écrans pour que je puisse te donner des conseils sur le design…

Vu ton modèle de données qui n’est pas des plus basique, il faut que tu conçoives bien l’application pour qu’elle soit bien adoptée.

D’ailleurs, est-ce une application PC ou mobile ?