je dois concevoir une base permettant de renvoyer une durée de trajet (et
d'autre informations. changement à tel endroit etc..) entre deux lieux. Le
même style que ratp ou sncf mais en moins volumineux.
Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et
de la structure générale.
j'ai deja conçu 3 tables :
lieux_depart (liste des lieux de départ)
lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table)
lignes (contenant la liste des lignes).
seulement aprés je séche lamentablement.
existe-il un site ou je puisse trouver des infos sur ce genre de conception.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ManuPavy
j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
Bonjour, Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les lieux de départ ne puissent pas être lieux d'arrivée). Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu auras deux liens vers lieux : IDDepart et IDArrivee Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu place une table de liaison (pour relation n-n) entre ville et ligne. Voilà, c'est un premier jet, mais faut pas oublier que la modélisation repose en grande partie sur l'utilisation/extension d'utilisation que tu en auras.
Manu
j'ai deja conçu 3 tables :
lieux_depart (liste des lieux de départ)
lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table)
lignes (contenant la liste des lignes).
seulement aprés je séche lamentablement.
Bonjour,
Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est
une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il
s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les
lieux de départ ne puissent pas être lieux d'arrivée).
Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu
auras deux liens vers lieux : IDDepart et IDArrivee
Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu
place une table de liaison (pour relation n-n) entre ville et ligne.
Voilà, c'est un premier jet, mais faut pas oublier que la modélisation
repose en grande partie sur l'utilisation/extension d'utilisation que tu
en auras.
j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
Bonjour, Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les lieux de départ ne puissent pas être lieux d'arrivée). Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu auras deux liens vers lieux : IDDepart et IDArrivee Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu place une table de liaison (pour relation n-n) entre ville et ligne. Voilà, c'est un premier jet, mais faut pas oublier que la modélisation repose en grande partie sur l'utilisation/extension d'utilisation que tu en auras.
Manu
ManuPavy
ManuPavy wrote:
j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
Bonjour, Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les lieux de départ ne puissent pas être lieux d'arrivée). Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu auras deux liens vers lieux : IDDepart et IDArrivee Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu place une table de liaison (pour relation n-n) entre ville et ligne. Voilà, c'est un premier jet, mais faut pas oublier que la modélisation repose en grande partie sur l'utilisation/extension d'utilisation que tu en auras.
Manu
En me relisant, j ai remarqué que j ai mis "entre ville et ligne", il fallait lire "entre lieu et ligne"
Manu
ManuPavy wrote:
j'ai deja conçu 3 tables :
lieux_depart (liste des lieux de départ)
lieux_arrivé (liste des lieux d'arrivé. même contenu que la première
table)
lignes (contenant la liste des lignes).
seulement aprés je séche lamentablement.
Bonjour,
Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est
une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il
s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les
lieux de départ ne puissent pas être lieux d'arrivée).
Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu
auras deux liens vers lieux : IDDepart et IDArrivee
Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu
place une table de liaison (pour relation n-n) entre ville et ligne.
Voilà, c'est un premier jet, mais faut pas oublier que la modélisation
repose en grande partie sur l'utilisation/extension d'utilisation que tu
en auras.
Manu
En me relisant, j ai remarqué que j ai mis "entre ville et ligne", il
fallait lire "entre lieu et ligne"
j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
Bonjour, Déjà, je trouve que lister lieux de départ et les lieux d'arrivée est une erreur : un lieu est un lieu ; c'est ensuite que tu définis s'il s'agit d'un départ ou d'une arrivé (sauf si il est envisagé que les lieux de départ ne puissent pas être lieux d'arrivée). Ensuite, une ligne a un départ et une arrivée. Donc dans cette table tu auras deux liens vers lieux : IDDepart et IDArrivee Puis, pour modéliser des stations qui ne sont pas depart ou arrivée, tu place une table de liaison (pour relation n-n) entre ville et ligne. Voilà, c'est un premier jet, mais faut pas oublier que la modélisation repose en grande partie sur l'utilisation/extension d'utilisation que tu en auras.
Manu
En me relisant, j ai remarqué que j ai mis "entre ville et ligne", il fallait lire "entre lieu et ligne"
Manu
Fred BROUARD - SQLpro
il s'agit de réaliser une matrice diagonale des trajets possible à partir d'une table des étapes :
CREATE TABLE T_ETAPE_ETP (ETP_ID INTEGER NOT NULL PRIMARY KEY, ETP_LIEU VARCHAR(32) NOT NULL UNIQUE)
CREATE TABLE T_LIGNE_LGN (LGN_ID INTEGER NOT NULL PRIMARY KEY, TRJ_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_TRAJET_TRJ (TRJ_ID), LGN_SENS CHAR(6) NOT NULL DEFAULT 'ALLER' CHECK (VALUE IN ('ALLER ', 'RETOUR')), LGN_REF CHAR(8) NOT NULL UNIQUE)
et enfin les étapes de la ligne
CREATE TJ_LIGNE_ETAPE_LTP (LGN_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_LIGNE_LGN (LGN_ID), ETP_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_ETAPE_ETP (ETP_ID), LTP_ARRIVE TIME NULL, LTP_PART TIME NULL, CONSTRAINT PK_LTP PRIMARY KEY (LGN_ID, ETP_ID), CONSTRAINT CK_TIME_CHAIN CHECK (LTP_PART > LTP_ARRIVE))
Pour s'assurer que la chose est toujours correcte il faudrait rajouter une assertion qui spécifie que pour un LGN_ID donné il y a toujours dans la table TJ_LIGNE_ETAPE_LTP : l'étape de départ relative au TRJ_ID pour laquelle LTP_ARRIVE est NULL l'étape d'arrivée relative au TRJ_ID pour laquelle LTP_PART est NULL toutes autres étapes non relative au TRJ_ID doit avoir LTP_ARRIVE et LTP_PART NOT NULL
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
LF36 a écrit:
bonjour,
je dois concevoir une base permettant de renvoyer une durée de trajet (et d'autre informations. changement à tel endroit etc..) entre deux lieux. Le même style que ratp ou sncf mais en moins volumineux. Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et de la structure générale. j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
existe-il un site ou je puisse trouver des infos sur ce genre de conception.
Meci d'avance Laurent
il s'agit de réaliser une matrice diagonale des trajets possible à partir d'une
table des étapes :
CREATE TABLE T_ETAPE_ETP
(ETP_ID INTEGER NOT NULL PRIMARY KEY,
ETP_LIEU VARCHAR(32) NOT NULL UNIQUE)
CREATE TABLE T_LIGNE_LGN
(LGN_ID INTEGER NOT NULL PRIMARY KEY,
TRJ_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_TRAJET_TRJ (TRJ_ID),
LGN_SENS CHAR(6) NOT NULL DEFAULT 'ALLER'
CHECK (VALUE IN ('ALLER ', 'RETOUR')),
LGN_REF CHAR(8) NOT NULL UNIQUE)
et enfin les étapes de la ligne
CREATE TJ_LIGNE_ETAPE_LTP
(LGN_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_LIGNE_LGN (LGN_ID),
ETP_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_ETAPE_ETP (ETP_ID),
LTP_ARRIVE TIME NULL,
LTP_PART TIME NULL,
CONSTRAINT PK_LTP PRIMARY KEY (LGN_ID, ETP_ID),
CONSTRAINT CK_TIME_CHAIN CHECK (LTP_PART > LTP_ARRIVE))
Pour s'assurer que la chose est toujours correcte il faudrait rajouter une
assertion qui spécifie que pour un LGN_ID donné il y a toujours dans la table
TJ_LIGNE_ETAPE_LTP :
l'étape de départ relative au TRJ_ID pour laquelle LTP_ARRIVE est NULL
l'étape d'arrivée relative au TRJ_ID pour laquelle LTP_PART est NULL
toutes autres étapes non relative au TRJ_ID doit avoir LTP_ARRIVE et LTP_PART
NOT NULL
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
LF36 a écrit:
bonjour,
je dois concevoir une base permettant de renvoyer une durée de trajet (et
d'autre informations. changement à tel endroit etc..) entre deux lieux. Le
même style que ratp ou sncf mais en moins volumineux.
Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et
de la structure générale.
j'ai deja conçu 3 tables :
lieux_depart (liste des lieux de départ)
lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table)
lignes (contenant la liste des lignes).
seulement aprés je séche lamentablement.
existe-il un site ou je puisse trouver des infos sur ce genre de conception.
CREATE TABLE T_LIGNE_LGN (LGN_ID INTEGER NOT NULL PRIMARY KEY, TRJ_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_TRAJET_TRJ (TRJ_ID), LGN_SENS CHAR(6) NOT NULL DEFAULT 'ALLER' CHECK (VALUE IN ('ALLER ', 'RETOUR')), LGN_REF CHAR(8) NOT NULL UNIQUE)
et enfin les étapes de la ligne
CREATE TJ_LIGNE_ETAPE_LTP (LGN_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_LIGNE_LGN (LGN_ID), ETP_ID INTEGER NOT NULL FOREIGN KEY REFERENCES T_ETAPE_ETP (ETP_ID), LTP_ARRIVE TIME NULL, LTP_PART TIME NULL, CONSTRAINT PK_LTP PRIMARY KEY (LGN_ID, ETP_ID), CONSTRAINT CK_TIME_CHAIN CHECK (LTP_PART > LTP_ARRIVE))
Pour s'assurer que la chose est toujours correcte il faudrait rajouter une assertion qui spécifie que pour un LGN_ID donné il y a toujours dans la table TJ_LIGNE_ETAPE_LTP : l'étape de départ relative au TRJ_ID pour laquelle LTP_ARRIVE est NULL l'étape d'arrivée relative au TRJ_ID pour laquelle LTP_PART est NULL toutes autres étapes non relative au TRJ_ID doit avoir LTP_ARRIVE et LTP_PART NOT NULL
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
LF36 a écrit:
bonjour,
je dois concevoir une base permettant de renvoyer une durée de trajet (et d'autre informations. changement à tel endroit etc..) entre deux lieux. Le même style que ratp ou sncf mais en moins volumineux. Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et de la structure générale. j'ai deja conçu 3 tables : lieux_depart (liste des lieux de départ) lieux_arrivé (liste des lieux d'arrivé. même contenu que la première table) lignes (contenant la liste des lignes). seulement aprés je séche lamentablement.
existe-il un site ou je puisse trouver des infos sur ce genre de conception.
Meci d'avance Laurent
Jacques Caron
Salut,
On Thu, 27 Jan 2005 10:16:19 +0100, LF36 wrote:
je dois concevoir une base permettant de renvoyer une durée de trajet (et d'autre informations. changement à tel endroit etc..) entre deux lieux. Le même style que ratp ou sncf mais en moins volumineux. Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et de la structure générale.
Euh, le but c'est de stocker dans la base tous les trajets possibles (déjà calculés par ailleurs), ou de les trouver à partir de la base (qui contiendrait des trajets "élémentaires")?
Dans le second cas, à moins de faire une recherche exhaustive, ce qui risque d'être long s'il y a un nombre un tant soit peu important de trajets. Il faut donc de porter sur des algos type SPF (shortest path first) qui vont permettre de réduire le nombre de trajets à examiner. Mais ce n'est pas la base de données qui fera ce travail, elle ne fera que fournir les données à l'algo...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Thu, 27 Jan 2005 10:16:19 +0100, LF36 <laurent@adirect.net-pasdepub>
wrote:
je dois concevoir une base permettant de renvoyer une durée de trajet (et
d'autre informations. changement à tel endroit etc..) entre deux lieux.
Le même style que ratp ou sncf mais en moins volumineux.
Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables
et de la structure générale.
Euh, le but c'est de stocker dans la base tous les trajets possibles (déjà
calculés par ailleurs), ou de les trouver à partir de la base (qui
contiendrait des trajets "élémentaires")?
Dans le second cas, à moins de faire une recherche exhaustive, ce qui
risque d'être long s'il y a un nombre un tant soit peu important de
trajets. Il faut donc de porter sur des algos type SPF (shortest path
first) qui vont permettre de réduire le nombre de trajets à examiner. Mais
ce n'est pas la base de données qui fera ce travail, elle ne fera que
fournir les données à l'algo...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
je dois concevoir une base permettant de renvoyer une durée de trajet (et d'autre informations. changement à tel endroit etc..) entre deux lieux. Le même style que ratp ou sncf mais en moins volumineux. Hors je ne trouve pas l'astuce pour bien élaborer l'ensemble des tables et de la structure générale.
Euh, le but c'est de stocker dans la base tous les trajets possibles (déjà calculés par ailleurs), ou de les trouver à partir de la base (qui contiendrait des trajets "élémentaires")?
Dans le second cas, à moins de faire une recherche exhaustive, ce qui risque d'être long s'il y a un nombre un tant soit peu important de trajets. Il faut donc de porter sur des algos type SPF (shortest path first) qui vont permettre de réduire le nombre de trajets à examiner. Mais ce n'est pas la base de données qui fera ce travail, elle ne fera que fournir les données à l'algo...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/