Discussion :

[Mister_Max]

Bonjour,

Je travaille sur un projet personnel qui consiste à modéliser sous Postres une base de données GTFS. Le GTFS est utilisé dans les transports pour construire l'offre de transports (horaires, lignes....).
Pour ce faire j'utilise Looping et quelque chose m'échappe dans la construction du modèle et notamment sur 2 tables qui sont TRIPS et SHAPES.
La table TRIPS permet de construire les courses/missions quant à la table SHAPES elle sert à tracer le parcours sur une carte.

En lisant la documentation, il est indiqué que la table TRIPS à une clé primaire : trips_id et une clé étrangère shape_id provenant de la table SHAPES. (https://gtfs.org/fr/documentation/sc...ence/#tripstxt)

Pour la table SHAPES, il s'avère qu'il y a une clé composite : shape_id et shape_pt_sequence (https://gtfs.org/fr/documentation/sc...nce/#shapestxt)

En modélisant cette relation sous Looping, mes clés composites deviennent des clés étrangères dans la table TRIPS. D'ailleurs une petite étoile apparait au dessus de l'attribut shape_pt_sequence.



Est-il possible avec Looping de modéliser cette relation (ou comportement) pour ne propager que la clé shape_id dans la table TRIPS ?

En vous remerciant.

[escartefigue]

Bonjour,

Non seulement je ne pense pas qu'il soit possible de le faire, mais surtout, ce n'est pas souhaitable.

Car si l'on propage une partie seulement de l'identifiant, et donc une partie de la PK au stade tabulaire, on ne peut plus garantir l'intégrité référentielle.
Or, une base de données dont l'intégrité n'est pas garantie n'a que peu d'intérêt.

Si la suppression d'un "SHAPE" doit supprimer en cascade tous les "TRIPS" qui en dépendent, alors la bonne modélisation est la suivante :




Par ailleurs, choisir un type text, char ou varchar comme identifiant est une mauvaise idée :

• le contenu d'un type text, char ou varchar est souvent sémantique et instable. En cas de mise à jour, l'impact peut être très conséquent à cause du phénomène de cascade ;
• à nombre de valeurs égal, c'est beaucoup plus encombrant qu'un entier, au détriment des performances ;
• les types text, char et varchar sont sensibles à la collation, contrairement aux entiers.

[Mister_Max]

Merci beaucoup pour vos retours.

Vous avez raison cette base de données ne sera pas maintenable et donc inutile. Pour réaliser quelques requêtes sur les données GTFS je vais couper la relation entre TRIPS et SHAPES, l'intégration de fichiers plats dans Postgres ne posera pas de problèmes. Je vais reprendre la modélisation pour avoir un modèle conceptuel propre pour ajouter des fonctionnalités que j'ai en tête.

Je pense que vous me verrez régulièrement sur le forum pour vos avis.

En vous remerciant et bonne fin de journée à vous.