Modéliser une interface de POO en SQL ?

Bonjour à tous,

Je développe en PHP sous le framework Symfony et son ORM attitré Doctrine, mais pour un projet je tombe sur un os pour penser en tables de bdd ce que j'ai conçu en classes. Je viens donc quérir quelques conseils auprès de vous. J'explique le contexte en quelques mots :

Je fais une application de gestion d'évènements (Jeux Olympiques, séminaire de médecine, marathon, salon de l'auto, festival de musique, compétition de judo, soirée bière/pizza avec des amis, ...), et ces évènements ont lieu à une date et un emplacement; C'est sur le "où" que je travaille.

Un évènement peut avoir lieu :
_A une adresse postale précise (par exemple 5 rue de bidule à Triffouilli, France),
_Dans une salle remarquable (par exemple le parc des expositions de Versailles, qui lui même a une adresse postale bien sûr),
_Dans une zone moins précise (par exemple les jeux olympiques de Tokyo auront lieu dans tout Tokyo, tandis que la coupe du monde au Qatar aura lieu dans tout le pays),
_Online (une url généralement),
_A des coordonnées précises en latitude/longitude GPS (par exemple au milieu d'une forêt... Je vous déconseille d'aller à cet évènement !).

Pour réaliser ceci, ma classe Event possède un attribut de type LocationInterface, et chacun des 5 cas de figure ci-dessus est modélisé par une classe implémentant cette interface.

Mais coté SQL, comment modéliser une telle relation ? Doit on avoir une table event avec 5 Clés étrangères nullables, pour représenter potentiellement l'une de ces relations ?
Ou bien feriez vous ceci à l'aide d'une table d'association, comme une relation Many to many ?
Est-ce un cas de figure commun dont la solution est triviale ? Existe-t-il un pattern connu pour régler cela en base de données ?
Peut être qu'une base non relationnelle (mongoDB etc) serait plus adaptée pour un tel interfaçage ?

Qu'en pensez-vous ?

Merci d'avance,
Cordialement,
Julien

Après réflexion, je crois qu'on peut simplifier ma question avec un exemple plus trivial :

Un évènement peut être créé soit par un utilisateur, soit par une organisation (que les utilisateurs créent et rejoignent). On a donc une relation entre un évènement et un utilisateur OU entre un évènement et une organisation, mais pas les 2.

Comment refléter une telle relation de "choix" lors de la conception de sa base de données ?

1. Ajoute-t-on les champs "user_id" et "organisation_id" en tant que clées étrangères dans la table Event ?
2. Crée-t-on une table d'association comme pour un many to many, même si un évènement ne peut avoir qu'un seul créateur ?
3. Fait-on vivre la relation de l'autre coté, avec la FK chez user et organisation ?

Que serait le plus juste ?

Bonjour,

Selon le cas, on peut opter pour l'héritage ou un méta-modèle

cf. ce sujet : https://merise.developpez.com/faq/?p...eVariablePptes

Bonjour et merci beaucoup pour votre réponse,

Le lien que vous avez fourni est très intéressant; Le style d'écriture est très formel ce qui me prend du temps à lire et peut être que je passe à coté de choses importantes, mais il me semble que le chapitre "Comment indiquer qu'une entité participe conditionnellement à plusieurs relations ?" met un nom sur mon problème, en détaillant même avec :

Citation:

---

l'exclusivité, notée X: la participation aux relations impliquées est mutuellement exclusive
la totalité, notée T: la participation à au moins une des relations impliquées est obligatoire
la partition, notée XT; combinaison des 2 précédente

---

Qui me fait penser que mes cas de figure sont des XT.

On retrouve mention de ce problème dans "Comment exprimer que des caractéristiques ne puissent être pertinentes que pour certaines occurrences d'une entité ?", où il semble que mon problème se nomme "liste variable de propriétés" (je peux me tromper dans le détail mais en tout cas ça y ressemble).

Il semble que la méta-modélisation soit ce dont j'ai besoin; Il me semble pertinent que les informations concernant l'entité qui créée mon évènement n'empiète pas sur mon évènement.

Comment traduire une telle relation en MLD ? Je ne crois pas que l'article (ou les pages suivantes) ne réponde à cela, quelqu'un saurait il m'aiguiller ?

Merci d'avance,

Bonjour,

Citation:

---

Envoyé par Nayte

Comment traduire une telle relation en MLD ? Je ne crois pas que l'article (ou les pages suivantes) ne réponde à cela, quelqu'un saurait il m'aiguiller ?

---

Au début, ne vous préoccupez pas de la traduction en MLD : si vous concevez correctement votre MCD, le MLD correspondant, ainsi que les requêtes SQL de création des tables de la BD, seront générés automatiquement par votre outil de modélisation conceptuelle.
Donc, première étage : réalisez un beau MCD reflétant parfaitement la structure de votre système d'information, et tout le reste se déduira alors très simplement. :lun:

Je ne peux qu'approuver les propos de Paprick : commencez par le MCD :)

Si vous avez besoin d'aide pour construire votre MCD, vous pouvez poser vos questions ici :
https://www.developpez.net/forums/f6...sation/schema/

Citation:

---

Un évènement peut avoir lieu :
_A une adresse postale précise (par exemple 5 rue de bidule à Triffouilli, France),
_Dans une salle remarquable (par exemple le parc des expositions de Versailles, qui lui même a une adresse postale bien sûr),
_Dans une zone moins précise (par exemple les jeux olympiques de Tokyo auront lieu dans tout Tokyo, tandis que la coupe du monde au Qatar aura lieu dans tout le pays),
_Online (une url généralement),
_A des coordonnées précises en latitude/longitude GPS (par exemple au milieu d'une forêt... Je vous déconseille d'aller à cet évènement !).

Pour réaliser ceci, ma classe Event possède un attribut de type LocationInterface, et chacun des 5 cas de figure ci-dessus est modélisé par une classe implémentant cette interface.

---

Vous pouvez faire une chose similaire en modélisant un héritage dans la base de données.

Règles de gestion :
R1 : Une PostalAddress est une LocationInterface et une LocationInterface peut être une PostalAddress.
R2 : Un Hall est une LocationInterface et une LocationInterface peut être un Hall.
R3 : Une Zone est une LocationInterface et une LocationInterface peut être une zone.
R4 : Une URL est une LocationInterface et une LocationInterface peut être une URL.
R5 : Un GeographicPoint est une LocationInterface et une LocationInterface peut être un GeographicPoint.
R6 : Un Hall est situé à une PostalAddress et une PostalAddress peut situer un Hall (ou bien peut situer plusieurs Hall ; à vous de décider).

MCD pour les règles R1 à R5 :
PostalAddress -(1,1)----être----0,1- LocationInterface
Hall -(1,1)----être----0,1---------------------------|
Zone -(1,1)----être----0,1-------------------------|
URL -(1,1)----être----0,1--------------------------|
GeographicPoint -(1,1)----être----0,1----------|

Ajout au MCD pour la règle R6 :
Hall -1,1----situer----0,1- PostalAddress

On peut aussi ajouter l'éclatement de l'adresse pour éviter la répétition de la saisie des villes avec une orthographe différente :
R7 : Une PostalAddress fait partie d'une City et une City peut être patitionnée en plusieurs PostalAddress.
R8 : Une City appartient à un Country et un Country possède plusieurs City.

PostalAddress -1,1----faire_partie----0,n- City -1,1----appartenir----0,n- Country

Et si besoin, vous pouvez découper le Country en plusieurs Region. Je vous laisse chercher comment faire.

Bonjour, et merci à tous pour vos réponses,

Concernant la réponse étoffée de @CinePhil (je vous remercie chaleureusement pour l'effort), je pense que j'avais tout cela, mais pour parler correctement voici la version graphique de "ce que je crois avoir compris" :)

Pièce jointe 591922

Sans surprise, ici tout va se passer autour de la table location_interface (qui pourrait être appelée "location" aussi), qui va avoir une relation avec area OU postal_address OU virtual_address OU venue OU geographic_point. Comment prendre en compte cette relation exclusive dans cette table ? Y a-t-il un moyen avec MySQL de dire "entre ces 5 FK, il doit ET ne peut en avoir qu'une seule de non nulle" ? Un trigger ? J'entend beaucoup autour de moi que PGSQL permet plus de contrôles dans ce genre, est ce vrai ?

J'en ai également profiter pour esquisser ce qui me semble être "la bonne solution" du coté de mon langage de backend (PHP), en reprenant le même example mais en le simplifiant à 2 choix au lieu de 5 - la forme la plus simple de mon dilemme :

Pièce jointe 591925

Alors peut être me trompe-je en utilisant une interface LocationInterface pour modéliser ce "je veux l'un ou l'autre", mais ça me semble robuste.

Si je converti ça, je retombe sur peu ou proue la version précédente, avec 2 options au lieu de 5 :

Pièce jointe 591927

La table "event_location" joue le même rôle que l'interface PHP, mais dans cette version la relation entre event_location et event est possédée par event_location, ce qui me semble être un massacre niveau perf. Un tout petit changement donc :

Pièce jointe 591928

Et cette modélisation me semble être la plus élégante : la table "event" n'est pas noyée de FK nuisant à la lecture, et la table "location" fait son oeuvre de "table d'association pour relation one to many". La version encore plus simple aurait pu être celle ci mais me semble moins élégante donc :

Pièce jointe 591929

Je pense donc avoir trouvé une manière élégante de modéliser ça dans ma base, mais est-ce le cas ? Peut-être suis-je totalement dans les choux ?

Et malheureusement cela n'enlève pas mon problème d'implémentation en PHP, avec l'ORM Doctrine. A savoir que pour lui une telle relation doit être faite avec une classe "location" dont toutes les autres héritent.

Ce qui m'étonne dans le problème que je rencontre et qui fait que je vous écris, c'est que réduit à 3 classes (un évènement, une adresse postale ou une adresse virtuelle), le use case me semble très simple et pourtant complexe outre-mesure à mettre en place :
_coté SQL, il faut donc relier toutes les FK à une table, et dire "celle-ci ou celle-la" ne peut simplement pas se faire (peut être que si, voir ma question plus haut, peut être avec un trigger ou quelque chose que je ne connais pas),
_coté Doctrine, un ORM réputé, ce cas de figure n'existe pas. Il faut forcément hériter.

La probabilité que moi petit développeur en formation vienne de démontrer un énorme problème de conception informatique en 2021 est nulle; Il est fort plus probable que je sois simplement dans les choux sur un élément de compréhension, mais lequel ?

Vos cardinalités dans votre premier schéma ne sont pas dans le bon sens, ce qui fait que MySQL Workbench a créé des clés étrangères dans location_interface. :aie:

1) Supprimez les associations partant de location_interface
2) Supprimez les clés primaires des entités postal_address, venue, area, geographic_point et virtual_address.
3) Refaites les associations partant de location_interface en utilisant le type "Identifying relationship".
Si vous constatez la création d'une clé dans location_interface, recommencez en partant de l'autre entité.

Revenez nous voir avec ce nouveau schéma.

Ah c'est intéressant comme remarque, car je n'ai même pas laissé le loisir à Workbench de créer les clés étrangères par lui même, j'ai consciemment conçu ma table location_interface de cette manière ! Je me disait qu'avoir les FK qui partent en étoile depuis cette table était la bonne façon de faire, et j'avoue ne pas en avoir douté avant votre dernier message.

Ce qui nous donne donc, avec cette nouvelle logique :

Pièce jointe 591953

Je crois comprendre la logique mais plein de questions me traversent l'esprit :
_Les 5 FK location_interface_id dans les 5 tables sont elles des clefs primaires pour elles ?
_Est ce que ce design fait office de "ou exclusif" ?
_La table location_interface fini donc très vide, ça n'est pas choquant ?

Je n'avais pas vu les choses comme ça !

Bonsoir,


Si l’area de la city est celle de la city de l’area alors le lien entre country est une redondance et doit disparaître. A défaut, vous créez une boucle, et les boucles sont redoutables.

Citation:

---

Envoyé par Nayte

Est ce que ce design fait office de "ou exclusif" ?

---

En aucune façon. donc mise en oeuvre d’une contrainte en perspective.

Remplacez les bijections par des injections. Par exemple si une area est toujours une location_interface et si une location_interface n’est que pafois une area, alors la cardinalité "||" est à remplacer par "O|" (voyez le paragraphe 6 de l’article sur MWB).


Mais dans tout ça, le mieux est sans conteste de reprendre la modélisation mais avec Looping !

Citation:

---

_Les 5 FK location_interface_id dans les 5 tables sont elles des clefs primaires pour elles ?

---

Oui. Vous avez bien compris. Les tables filles (postal_address, area, geographic_point...) ont pour clé primaire la clé étrangère référençant la table mère. C'est comme ça qu'on modélise un héritage dans les BDD relationnelles.

Je vais manger et je reviens plus tard...

En même temps (bis repetita) ce serait tellement plus simple de commencer par le MCD, un grand nombre de ces pièges seraient évités de facto !

Suite...

1) Un détail : Si vous reprenez mon MCD textuel de mon message #7, vous constaterez que les cardinalités entre location_interface et ses entités-types filles sont (1,1 - 0,1). Dans votre schéma, elles sont (1,1 - 1,1). Il faut donc, en toute rigueur, de mémoire (je n'ai pas Workbench sous la main), cliquer droit sur l'association puis changer manuellement la cardinalité. Je vous laisse essayer. Au final, vous devriez avoir ceci :
area o|------|| location_interface

2) Pensez aussi à adapter les types de colonnes à vos données.
Par exemple, une longitude ou une latitude ne sont pas de type VARCHAR mais de type DECIMAL ou FLOAT. Ou, mieux, directement en type de données spatiales.
Une URL en VARCHAR(45), "c'est un peu court, jeune homme", comme aurait dit Cyrano. :)

3) Repensez les composants de votre postal_address.
Vous pouvez vous inspirer de la norme postale.

4) L'area étant associée à la fois à city et country, vous pouvez, comme le souligne fsmrel, vous retrouver avec une area située dans une ville française et un pays différent de la France. Embêtant, non ?

5) Il vous manque une association entre venue et postal_address.

Merci pour l'aide encore une fois,

1) Exact pour le 0,1, je ne savais pas comment éditer ceci. Votre aide de tête était la bonne. Je crois qu'elle est faite dans le bon sens, MWB représente la relation 0,1 avec un "O|".

2) Les autres données ont été mises à la va vite, juste histoire d'exposer le contexte de manière un peu immersive. Je corrige ce que je peux au fil :) par exemple un évènement aura 20 propriétés de plus à terme.

3) Ahhh une norme pour les adresses ! Tout ce que j'ai (mal ?) cherché sur le net depuis des jours était qu'il n'y a aucune norme car c'est un freestyle absolu. La norme que vous avez pointé a l'air d'être purement française ? Y a t il un équivalent mondial ? En l'état, j'ai préféré penser qu'une adresse c'est une rue (avec le numéro), un complément (au choix de l'utilisateur) puis une ville qui a un code postal, elle même dans un pays. Basique mais fonctionnel. D'un point de vue métier, je n'ai pas besoin d'envoyer de courriers postaux, juste de bien indiquer aux gens comment se rendre sur place.

4 et 5) en fait on se retrouve avec un problème que je ne sais régler, à savoir que (pour le plus simple des 2) un venue a un postal_address, mais vers quoi pointe-t-on si postal_address n'a pas de PK ? Vers sa FK location_interface_id ? Le problème du coté de l'area est le même, car une zone peut être soit une ville soit un pays.

NOTE : si je me réfère au super lien de @fsmrel, alors en effet on maille autour de la FK de la table parente : https://fsmrel.developpez.com/basesr...nch/?page=6#L6 ce qui nous donne :

Pièce jointe 591973

J'ai simplement de la peine à dropper la PK de city et country, car ces tables ont une relation classique postal_address -- est dans -- city -- est dans -- country. Si tout cela est honnête comme modélisation, reste à savoir comment je vais faire comprendre ça à mon ORM Doctrine... Mais ça n'est pas le sujet du forum :)

Citation:

---

La norme que vous avez pointé a l'air d'être purement française ? Y a t il un équivalent mondial ?

---

Oui, c'est une norme française mais elle a une partie qui émet ses recommandation pour l'envoi de courrier à l'étranger donc elle est extensible aux adresses étrangères.

Citation:

---

En l'état, j'ai préféré penser qu'une adresse c'est une rue (avec le numéro), un complément (au choix de l'utilisateur) puis une ville qui a un code postal, elle même dans un pays.

---

Je séparerais au moins le code postal qui semble assez répandu dans les adresses étrangères.

Citation:

---

D'un point de vue métier, je n'ai pas besoin d'envoyer de courriers postaux, juste de bien indiquer aux gens comment se rendre sur place.

---

Alors je pense que vous pouvez laisser votre modèle en l'état.

Citation:

---

mais vers quoi pointe-t-on si postal_address n'a pas de PK ?

---

Les PK sont les identifiants hérités de location_interface.

Je reviens plus tard pour la suite...

Citation:

---

Envoyé par CinePhil

Alors je pense que vous pouvez laisser votre modèle en l'état.

---

Ca pourra tout à fait se complexifier dans le temps si les cas de figure se présentent : par exemple en France, il y a une ville Grigny dans le 91, et une dans le 69; même orthographe :) Je dois donc rajouter un champ département (minimum) ou zipcode dans city pour parer à cela. Au niveau international... Ce sera la surprise.

A reflechir il me semble que mes PK pour city et country ne sont pas bonnes; leur PK ne serait elle pas une combinaison entre id et area_location_interface_id ?

Bonjour à tous,

Je me répond à moi même, car j'ai trouvé une réponse satisfaisante avec l'aide de tout le monde. Merci à tous d'ailleurs :) Si cela peut aider une recherche internet :

Ce "ou exclusif" que je cherchais, dans mon contexte avoir un évènement qui peut soit avoir une adresse postale soit virtuelle dans des tables séparées, s'appelle un class table inheritance (ou en tout cas s'en rapproche très fortement).

Son expression la plus simple est trouvable ici sur le blog de Martin Fowler.

Il peut y avoir entre 0 et une infinité de propriétés partagées par les héritiers, et plusieurs générations d'héritages.

Coté PHP/Symfony/Doctrine, Il est possible de modéliser une class table inheritance avec une classe abstraite en parent. Par exemple, un évènement a une adresse, celle-ci peut être soit postale, soit virtuelle. La class Location est donc abstraite, et annotée comme suit :

Code:

---

1 2 3 4 5 6 7 8

/**  * @ORM\Entity  * @ORM\InheritanceType("JOINED")  */ abstract class Location { ... }

---

Tandis que les classes filles extendent simplement de Location :

Code:

---

1 2 3 4 5

/** @ORM\Entity */ class PostalAddress extends Location { ... }

---

Et tout fonctionne comme attendu.

Il n'est visiblement par possible, par contre, de faire marcher ce Class Table Inheritance sur une interface avec Doctrine, à date en tout cas. Est-ce une fonctionnalité intéressante, ou une lubie de débutant qui me suit, l'avenir nous le dira.

Merci encore à tous,