Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
conception base avec relation deux à plusieurs
2 views
Skip to first unread message
Benoit Izac
Nov 1, 2011, 4:59:37 AM11/1/11
to
Bonjour,
Je bute sur la modélisation de ma base de donnée et j'ai beau tourner le
problème dans tous les sens, je ne vois pas quelle solution adopter.
J'ai une table SITE :
- site_id -> clé primaire
- nom
- longitude
- latitude
- adresse
- etc.
Je souhaite créer des liaisons point à point entre ces sites. J'ai donc
une relation deux à plusieurs : si je crée une table LIEN, un lien
contient exactement 2 sites et un site peut apparaître dans 0 ou
plusieurs liens.
J'ai des informations
- qui sont propres au lien : bande de fréquence utilisée, débit,
etc.
- qui sont dépendantes du lien et du site : hauteur de
l'installation sur le site, type d'antenne, etc.
Jusqu'ici, pas de problème, je crée une table LIEN :
- site_id -> clé primaire
- bande de fréquence
- débit
puis une table intermédiaire SITE_LIEN :
- site_id -+
- lien_id -+-> clé primaire
- hauteur
- antenne
Rajoutons une contrainte : je dois conserver le sens du lien : site de
départ (A), site de départ (B). Je modifie donc ma table SITE_LIEN :
- lien_id -+
- coté (A ou B) -+-> clé primaire
- site_id
- hauteur
- antenne
À ce stade, j'ai déjà quelques questions :
1) comment afficher une ligne avec les informations suivantes ?
- lien_id
- site_id où le coté est A
- site_id où le coté est B
2) comment afficher tous les sites qui appartiennent à un lien comme il
suit ?
- site_id
- site_id du distant
Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
calculer si je connais une extrémité ; par exemple, l'azimut (angle par
rapport au nord) est égal à celui du site distant + ou - 180°. La
fréquence est dite « haute » si celle d'en face est dite « basse ».
Avec toutes ces contraintes, j'en arrive à me dire qu'il est plus simple
de supprimer la table intermédiaire et d'avoir une table LIEN comme il
suit :
- lien_id
- bande de fréquence
- débit
- id_site_A
- antenne_A
- hauteur_A
- azimut_A
- fréquence_A
- id_site_B
- antenne_B
- hauteur_B
Mais ça me crée d'autre problème. Pour répondre à la question 2), je
dois faire deux requêtes puis une union (non testé) :
CREATE VIEW site_A AS
SELECT id_site_A AS local, id_site_B AS distant FROM LIEN;
CREATE VIEW site_B AS
SELECT id_site_B AS local, id_site_A AS distant FROM LIEN;
SELECT * FROM site_A
UNION
SELECT * FROM site_B;
Bref, mon manque d'expérience m'empêche de savoir quelle solution
adopter. Pouvez-vous m'indiquer d'une part si ces deux solutions sont
viables et d'autres part quels sont leurs avantages/inconvénients ?
Merci.
--
Benoit Izac
Je bute sur la modélisation de ma base de donnée et j'ai beau tourner le
problème dans tous les sens, je ne vois pas quelle solution adopter.
J'ai une table SITE :
- site_id -> clé primaire
- nom
- longitude
- latitude
- adresse
- etc.
Je souhaite créer des liaisons point à point entre ces sites. J'ai donc
une relation deux à plusieurs : si je crée une table LIEN, un lien
contient exactement 2 sites et un site peut apparaître dans 0 ou
plusieurs liens.
J'ai des informations
- qui sont propres au lien : bande de fréquence utilisée, débit,
etc.
- qui sont dépendantes du lien et du site : hauteur de
l'installation sur le site, type d'antenne, etc.
Jusqu'ici, pas de problème, je crée une table LIEN :
- site_id -> clé primaire
- bande de fréquence
- débit
puis une table intermédiaire SITE_LIEN :
- site_id -+
- lien_id -+-> clé primaire
- hauteur
- antenne
Rajoutons une contrainte : je dois conserver le sens du lien : site de
départ (A), site de départ (B). Je modifie donc ma table SITE_LIEN :
- lien_id -+
- coté (A ou B) -+-> clé primaire
- site_id
- hauteur
- antenne
À ce stade, j'ai déjà quelques questions :
1) comment afficher une ligne avec les informations suivantes ?
- lien_id
- site_id où le coté est A
- site_id où le coté est B
2) comment afficher tous les sites qui appartiennent à un lien comme il
suit ?
- site_id
- site_id du distant
Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
calculer si je connais une extrémité ; par exemple, l'azimut (angle par
rapport au nord) est égal à celui du site distant + ou - 180°. La
fréquence est dite « haute » si celle d'en face est dite « basse ».
Avec toutes ces contraintes, j'en arrive à me dire qu'il est plus simple
de supprimer la table intermédiaire et d'avoir une table LIEN comme il
suit :
- lien_id
- bande de fréquence
- débit
- id_site_A
- antenne_A
- hauteur_A
- azimut_A
- fréquence_A
- id_site_B
- antenne_B
- hauteur_B
Mais ça me crée d'autre problème. Pour répondre à la question 2), je
dois faire deux requêtes puis une union (non testé) :
CREATE VIEW site_A AS
SELECT id_site_A AS local, id_site_B AS distant FROM LIEN;
CREATE VIEW site_B AS
SELECT id_site_B AS local, id_site_A AS distant FROM LIEN;
SELECT * FROM site_A
UNION
SELECT * FROM site_B;
Bref, mon manque d'expérience m'empêche de savoir quelle solution
adopter. Pouvez-vous m'indiquer d'une part si ces deux solutions sont
viables et d'autres part quels sont leurs avantages/inconvénients ?
Merci.
--
Benoit Izac
pif34
Nov 1, 2011, 6:24:49 AM11/1/11
to
Bonjour, pas �vident, les explications sont pas super claires, mais
c'est aussi un peu logique, car sinon, pas de probl�me pour mod�liser...
Le 01/11/2011 09:59, Benoit Izac a �crit :
> Bonjour,
>
> Je bute sur la mod�lisation de ma base de donn�e et j'ai beau tourner le
> probl�me dans tous les sens, je ne vois pas quelle solution adopter.
> une relation deux � plusieurs : si je cr�e une table LIEN, un lien
> contient exactement 2 sites et un site peut appara�tre dans 0 ou
> etc.
> - qui sont d�pendantes du lien et du site : hauteur de
> - site_id -> cl� primaire
> - bande de fr�quence
> - d�bit
>
> puis une table interm�diaire SITE_LIEN :
> - site_id -+
> - lien_id -+-> cl� primaire
> - lien_id -+
> - cot� (A ou B) -+-> cl� primaire
structure de donn�es des plus �l�mentaires: des sites (les sommets) et
des liens (les aretes):
donc t'as grossomodo 2 entit�s:
Site (id, nom, gps_x, gps_y, ... )
Lien (id_src, id_dst, bande_frequence, debit, ...).
L'id du site est la PK, les deux ids de liens sont des FK et constituent
toutes les deux une PK de ta table lien (tu peux cr�er un identifiant si
tu peux avoir plusieurs connexions entre deux meme site ou pour diverses
raison techniques).
si t'as une info d�pendante du site (ex: affaiblissement, tu as
grossomodo deux solutions:
- si les attributs ne sont pas tres nombreux, tu modifie la table lien:
Lien (id_src, id_trg, bande_frequence, debit, affaiblissement_src,
affaiblissement_trg, ...).
, tu cr�� en effet une entit� lien avec une laison many to many genre:
Site (id, nom, gps_x, gps_y, ... )
Lien (id, bande_frequence, debit, ...)
et une table d'association:
Lien_Sites (id_site, id_lien, orientation (src ou cible),
affaiblissemet, etc.).
dans ce cas, tu peux mettre une contrainte d'unicit� sur (id_lien,
orientation) pour �viter d'avoir plusieurs sources ou destinations
tu peut avoir une PK (ou unicit�) sur (id_site,id_lien)...
> � ce stade, j'ai d�j� quelques questions :
> - site_id o� le cot� est B
dans le premier cas le plus simple:
select src.id, l.debit, trg.id
from lien l
join site src on lien.id_src = site.id
join site trg on lien.id_trg = site.id
dans le second cas:
select ....
from lien l
join lien_site ls_src on l.id = ls_src.id_lien
and ls_src.orientation = 1
join site src on ls_src.id_site = src.id
join lien_site ls_trg on l.id = ls_trg.id_lien
and ls_trg.orientation = 0
join site trg on ls_trg.id_site = trg.id
> 2) comment afficher tous les sites qui appartiennent � un lien comme il
where id lien = ?)
union select * from site where id in (select id_trg from lien....)
deuxieme cas:
select * from site where id in (select * id_site from lien_site where
id_lien = ? )
> Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
> l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
> calculer si je connais une extr�mit� ; par exemple, l'azimut (angle par
> rapport au nord) est �gal � celui du site distant + ou - 180�. La
> fr�quence est dite � haute � si celle d'en face est dite � basse �.
en g�n�ral, on parle d'attribut calcul�:
par exemple t'as la TVA, le HT et le TTC... stocker les 3 n'a pas de
sens car � partir de 2 tu peux en recalculer un 3�...
par contre, en effet, si tu prend l'�tat civil d'une personne, t'as sexe
M/F sur un seul champ: tu vas pas dire qu'il faut pas stocker F parce
que tu peux le d�duire si t'as pas M....
donc si t'as deux type de fr�quence H/B... ben tu cr�� un champ et tu
met la valeur qui va bien...
si par contre t'as une r�gle qui dit si bande_de_frequence = ??? alors
c'est bas... et que tu stocke la bande de fr�quence, en effet, tu stocke
pas la fr�quence basse...
au pire, si t'as des r�gles lourdes � coder et que tu veux �viter la
redondances, tu peux utiliser des m�canismes de vues par exemple,
> Avec toutes ces contraintes, j'en arrive � me dire qu'il est plus simple
> de supprimer la table interm�diaire et d'avoir une table LIEN comme il
> suit :
> - lien_id
> - bande de fr�quence
> - d�bit
et plein de jointure pour 1 attributs... si a terme t'en a 10 la
question se pose... si a terme t'as des connexion multiples aussi...
> Bref, mon manque d'exp�rience m'emp�che de savoir quelle solution
en l'�tat avec aussi peu de champs, les deux solutions sont correctes...
la solution compliqu�es sera cependant plus �volutive dans le temps...
dans tous les cas, tu peux utiliser des vues (j'ai le terme "requete
nomm�es") pour simplifier un certain nombre de requetes...
d'ailleurs, si tu base tout sur ces vues (sauf insert/delete/update), tu
pourras plus facilement faire �voluer ton sch�ma sans trop impacter le
reste de l'application ult�rieurement....
c'est aussi un peu logique, car sinon, pas de probl�me pour mod�liser...
Le 01/11/2011 09:59, Benoit Izac a �crit :
> Bonjour,
>
> Je bute sur la mod�lisation de ma base de donn�e et j'ai beau tourner le
> probl�me dans tous les sens, je ne vois pas quelle solution adopter.
>
> J'ai une table SITE :
> - site_id -> cl� primaire
> J'ai une table SITE :
> - nom
> - longitude
> - latitude
> - adresse
> - etc.
>
> Je souhaite cr�er des liaisons point � point entre ces sites. J'ai donc
> - longitude
> - latitude
> - adresse
> - etc.
>
> une relation deux � plusieurs : si je cr�e une table LIEN, un lien
> contient exactement 2 sites et un site peut appara�tre dans 0 ou
> plusieurs liens.
>
> J'ai des informations
> - qui sont propres au lien : bande de fr�quence utilis�e, d�bit,
>
> J'ai des informations
> etc.
> - qui sont d�pendantes du lien et du site : hauteur de
> l'installation sur le site, type d'antenne, etc.
>
> Jusqu'ici, pas de probl�me, je cr�e une table LIEN :
>
> - site_id -> cl� primaire
> - bande de fr�quence
> - d�bit
>
> puis une table interm�diaire SITE_LIEN :
> - site_id -+
> - lien_id -+-> cl� primaire
> - hauteur
> - antenne
>
> Rajoutons une contrainte : je dois conserver le sens du lien : site de
> d�part (A), site de d�part (B). Je modifie donc ma table SITE_LIEN :
> - antenne
>
> Rajoutons une contrainte : je dois conserver le sens du lien : site de
> - lien_id -+
> - cot� (A ou B) -+-> cl� primaire
> - site_id
> - hauteur
> - antenne
>
bon, alors je r�sume, en gros t'as un graphe orient�, ce qui reste une
> - hauteur
> - antenne
>
structure de donn�es des plus �l�mentaires: des sites (les sommets) et
des liens (les aretes):
donc t'as grossomodo 2 entit�s:
Site (id, nom, gps_x, gps_y, ... )
Lien (id_src, id_dst, bande_frequence, debit, ...).
L'id du site est la PK, les deux ids de liens sont des FK et constituent
toutes les deux une PK de ta table lien (tu peux cr�er un identifiant si
tu peux avoir plusieurs connexions entre deux meme site ou pour diverses
raison techniques).
si t'as une info d�pendante du site (ex: affaiblissement, tu as
grossomodo deux solutions:
- si les attributs ne sont pas tres nombreux, tu modifie la table lien:
Lien (id_src, id_trg, bande_frequence, debit, affaiblissement_src,
affaiblissement_trg, ...).
, tu cr�� en effet une entit� lien avec une laison many to many genre:
Site (id, nom, gps_x, gps_y, ... )
Lien (id, bande_frequence, debit, ...)
et une table d'association:
Lien_Sites (id_site, id_lien, orientation (src ou cible),
affaiblissemet, etc.).
dans ce cas, tu peux mettre une contrainte d'unicit� sur (id_lien,
orientation) pour �viter d'avoir plusieurs sources ou destinations
tu peut avoir une PK (ou unicit�) sur (id_site,id_lien)...
> � ce stade, j'ai d�j� quelques questions :
> 1) comment afficher une ligne avec les informations suivantes ?
> - lien_id
> - site_id o� le cot� est A
> - lien_id
> - site_id o� le cot� est B
dans le premier cas le plus simple:
select src.id, l.debit, trg.id
from lien l
join site src on lien.id_src = site.id
join site trg on lien.id_trg = site.id
dans le second cas:
select ....
from lien l
join lien_site ls_src on l.id = ls_src.id_lien
and ls_src.orientation = 1
join site src on ls_src.id_site = src.id
join lien_site ls_trg on l.id = ls_trg.id_lien
and ls_trg.orientation = 0
join site trg on ls_trg.id_site = trg.id
> 2) comment afficher tous les sites qui appartiennent � un lien comme il
> suit ?
> - site_id
> - site_id du distant
premier cas: select * from site where id in (select id_src from lien
> - site_id
> - site_id du distant
where id lien = ?)
union select * from site where id in (select id_trg from lien....)
deuxieme cas:
select * from site where id in (select * id_site from lien_site where
id_lien = ? )
> Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
> l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
> rapport au nord) est �gal � celui du site distant + ou - 180�. La
> fr�quence est dite � haute � si celle d'en face est dite � basse �.
en g�n�ral, on parle d'attribut calcul�:
par exemple t'as la TVA, le HT et le TTC... stocker les 3 n'a pas de
sens car � partir de 2 tu peux en recalculer un 3�...
par contre, en effet, si tu prend l'�tat civil d'une personne, t'as sexe
M/F sur un seul champ: tu vas pas dire qu'il faut pas stocker F parce
que tu peux le d�duire si t'as pas M....
donc si t'as deux type de fr�quence H/B... ben tu cr�� un champ et tu
met la valeur qui va bien...
si par contre t'as une r�gle qui dit si bande_de_frequence = ??? alors
c'est bas... et que tu stocke la bande de fr�quence, en effet, tu stocke
pas la fr�quence basse...
au pire, si t'as des r�gles lourdes � coder et que tu veux �viter la
redondances, tu peux utiliser des m�canismes de vues par exemple,
> Avec toutes ces contraintes, j'en arrive � me dire qu'il est plus simple
> de supprimer la table interm�diaire et d'avoir une table LIEN comme il
> suit :
> - lien_id
> - bande de fr�quence
> - d�bit
> - id_site_A
> - antenne_A
> - hauteur_A
> - azimut_A
> - fr�quence_A
> - antenne_A
> - hauteur_A
> - azimut_A
> - id_site_B
> - antenne_B
> - hauteur_B
oui, d�pend de l'�volution de ton logiciel... tu va pas cr�er une table
> - antenne_B
> - hauteur_B
et plein de jointure pour 1 attributs... si a terme t'en a 10 la
question se pose... si a terme t'as des connexion multiples aussi...
> Bref, mon manque d'exp�rience m'emp�che de savoir quelle solution
> adopter. Pouvez-vous m'indiquer d'une part si ces deux solutions sont
> viables et d'autres part quels sont leurs avantages/inconv�nients ?
en l'�tat avec aussi peu de champs, les deux solutions sont correctes...
la solution compliqu�es sera cependant plus �volutive dans le temps...
dans tous les cas, tu peux utiliser des vues (j'ai le terme "requete
nomm�es") pour simplifier un certain nombre de requetes...
d'ailleurs, si tu base tout sur ces vues (sauf insert/delete/update), tu
pourras plus facilement faire �voluer ton sch�ma sans trop impacter le
reste de l'application ult�rieurement....
Benoit Izac
Nov 1, 2011, 8:56:32 AM11/1/11
to
Bonjour,
le 01/11/2011 à 11:24, pif a écrit dans le message
<4eafc8ee$0$24233$426a...@news.free.fr> :
> Bonjour, pas évident, les explications sont pas super claires, mais
> c'est aussi un peu logique, car sinon, pas de problème pour
> modéliser...
Effectivement. Je pensais avoir tout de même bien décrit le problème.
> bon, alors je résume, en gros t'as un graphe orienté, ce qui reste une
> structure de données des plus élémentaires: des sites (les sommets) et
> des liens (les aretes):
Peut-être, je ne connais absolument rien en théorie des graphes. Si tu
me dis que c'est indispensable pour résoudre mon problème, je veux bien
y jeter un œil.
> donc t'as grossomodo 2 entités:
> orientation) pour éviter d'avoir plusieurs sources ou destinations
> tu peut avoir une PK (ou unicité) sur (id_site,id_lien)...
Ok, c'est ce que j'ai décrit.
>> À ce stade, j'ai déjà quelques questions :
change rien) :
SELECT id_src, id_dst FROM lien;
> dans le second cas:
[
> select ....
> from lien l
> join lien_site ls_src on l.id = ls_src.id_lien
> and ls_src.orientation = 1
> join site src on ls_src.id_site = src.id
> join lien_site ls_trg on l.id = ls_trg.id_lien
> and ls_trg.orientation = 0
> join site trg on ls_trg.id_site = trg.id
Il faut que je teste car j'ai du mal a suivre la requête (sans doute
parce que je n'ai pas l'habitude de lire cette syntaxe).
>> 2) comment afficher tous les sites qui appartiennent à un lien comme il
correspond à ce que je faisais à la fin de mon post initial avec des
CREATE VIEW et UNION.
> deuxieme cas:
> select * from site where id in (select * id_site from lien_site where
> id_lien = ? )
Même remarque que précédemment et c'est justement ça mon problème,
lister tous les sites de la table de liaison, c'est facile mais faire la
liaison entre src et dst, je ne sais pas faire.
>> Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
>> l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
>> calculer si je connais une extrémité ; par exemple, l'azimut (angle par
>> rapport au nord) est égal à celui du site distant + ou - 180°. La
>> fréquence est dite « haute » si celle d'en face est dite « basse ».
>
> en général, on parle d'attribut calculé:
>
> par contre, en effet, si tu prend l'état civil d'une personne, t'as
Non, c'est différent, dans le cas de l'état civil, tu peux avoir soit
M ou F et tu n'as pas de contrainte. Si par contre tu prends un couple
(non homosexuel), c'est différent tu ne peux pas avoir deux M ou deux
F dans le même couple. Je veux éviter d'une part, d'avoir des
incohérences (deux bandes hautes dans le même lien, la somme des azimut
qui n'est pas égal à 360°), d'autre part de consommer de l'espace
lorsque ce n'est pas nécessaire. Je pense que seule la table à plat
(sans la table de liaison) me le permet.
> donc si t'as deux type de fréquence H/B... ben tu créé un champ et tu
> c'est bas... et que tu stocke la bande de fréquence, en effet, tu
> stocke pas la fréquence basse...
Il y a une fréquence basse et une fréquence haute dans la bande de
fréquence.
> au pire, si t'as des règles lourdes à coder et que tu veux éviter la
> redondances, tu peux utiliser des mécanismes de vues par exemple,
>> Avec toutes ces contraintes, j'en arrive à me dire qu'il est plus simple
>> de supprimer la table intermédiaire et d'avoir une table LIEN comme il
>> suit :
>> - lien_id
>> - bande de fréquence
>> - débit
>
> en l'état avec aussi peu de champs, les deux solutions sont correctes...
Il y en a bien plus, c'était juste pour l'exemple.
> la solution compliquées sera cependant plus évolutive dans le temps...
C'est ce qui me semble aussi.
> dans tous les cas, tu peux utiliser des vues (j'ai le terme "requete
> nommées") pour simplifier un certain nombre de requetes...
> le reste de l'application ultérieurement....
Ok, merci pour la réponse.
--
Benoit Izac
le 01/11/2011 à 11:24, pif a écrit dans le message
<4eafc8ee$0$24233$426a...@news.free.fr> :
> Bonjour, pas évident, les explications sont pas super claires, mais
> c'est aussi un peu logique, car sinon, pas de problème pour
> modéliser...
Effectivement. Je pensais avoir tout de même bien décrit le problème.
> bon, alors je résume, en gros t'as un graphe orienté, ce qui reste une
> structure de données des plus élémentaires: des sites (les sommets) et
> des liens (les aretes):
Peut-être, je ne connais absolument rien en théorie des graphes. Si tu
me dis que c'est indispensable pour résoudre mon problème, je veux bien
y jeter un œil.
> donc t'as grossomodo 2 entités:
>
> Site (id, nom, gps_x, gps_y, ... )
> Lien (id_src, id_dst, bande_frequence, debit, ...).
>
> L'id du site est la PK, les deux ids de liens sont des FK et
> constituent toutes les deux une PK de ta table lien (tu peux créer un
> Site (id, nom, gps_x, gps_y, ... )
> Lien (id_src, id_dst, bande_frequence, debit, ...).
>
> L'id du site est la PK, les deux ids de liens sont des FK et
> identifiant si tu peux avoir plusieurs connexions entre deux meme site
> ou pour diverses raison techniques).
>
> si t'as une info dépendante du site (ex: affaiblissement, tu as
> ou pour diverses raison techniques).
>
> grossomodo deux solutions:
>
> - si les attributs ne sont pas tres nombreux, tu modifie la table lien:
> Lien (id_src, id_trg, bande_frequence, debit, affaiblissement_src,
> affaiblissement_trg, ...).
>
> , tu créé en effet une entité lien avec une laison many to many genre:
>
> - si les attributs ne sont pas tres nombreux, tu modifie la table lien:
> Lien (id_src, id_trg, bande_frequence, debit, affaiblissement_src,
> affaiblissement_trg, ...).
>
>
> Site (id, nom, gps_x, gps_y, ... )
> Lien (id, bande_frequence, debit, ...)
> et une table d'association:
> Lien_Sites (id_site, id_lien, orientation (src ou cible),
> affaiblissemet, etc.).
>
> dans ce cas, tu peux mettre une contrainte d'unicité sur (id_lien,
> Site (id, nom, gps_x, gps_y, ... )
> Lien (id, bande_frequence, debit, ...)
> et une table d'association:
> Lien_Sites (id_site, id_lien, orientation (src ou cible),
> affaiblissemet, etc.).
>
> orientation) pour éviter d'avoir plusieurs sources ou destinations
> tu peut avoir une PK (ou unicité) sur (id_site,id_lien)...
Ok, c'est ce que j'ai décrit.
>> À ce stade, j'ai déjà quelques questions :
>> 1) comment afficher une ligne avec les informations suivantes ?
>> - lien_id
>> - lien_id
>> - site_id où le coté est A
>> - site_id où le coté est B
>
> dans le premier cas le plus simple:
[je le rappelle pour plus de clarté
> dans le premier cas le plus simple:
Site (id, nom, gps_x, gps_y, ... )
Lien (id_src, id_dst, bande_frequence, debit, ...).
]
Lien (id_src, id_dst, bande_frequence, debit, ...).
> select src.id, l.debit, trg.id
> from lien l
> join site src on lien.id_src = site.id
> join site trg on lien.id_trg = site.id
Pour moi c'est un peu plus simple (tu as supprimé lien_id mais ça ne
> from lien l
> join site src on lien.id_src = site.id
> join site trg on lien.id_trg = site.id
change rien) :
SELECT id_src, id_dst FROM lien;
> dans le second cas:
[
Site (id, nom, gps_x, gps_y, ... )
Lien (id, bande_frequence, debit, ...)
Lien (id, bande_frequence, debit, ...)
Lien_Sites (id_site, id_lien, orientation (src ou cible),
affaiblissemet, etc.)
]
affaiblissemet, etc.)
> select ....
> from lien l
> join lien_site ls_src on l.id = ls_src.id_lien
> and ls_src.orientation = 1
> join site src on ls_src.id_site = src.id
> join lien_site ls_trg on l.id = ls_trg.id_lien
> and ls_trg.orientation = 0
> join site trg on ls_trg.id_site = trg.id
parce que je n'ai pas l'habitude de lire cette syntaxe).
>> 2) comment afficher tous les sites qui appartiennent à un lien comme il
>> suit ?
>> - site_id
>> - site_id du distant
>
> premier cas: select * from site where id in (select id_src from lien
> where id lien = ?)
> union select * from site where id in (select id_trg from lien....)
Non, pour moi, ça liste tous les sites, mais pas le distant. Ça
>> - site_id
>> - site_id du distant
>
> premier cas: select * from site where id in (select id_src from lien
> where id lien = ?)
> union select * from site where id in (select id_trg from lien....)
correspond à ce que je faisais à la fin de mon post initial avec des
CREATE VIEW et UNION.
> deuxieme cas:
> select * from site where id in (select * id_site from lien_site where
> id_lien = ? )
lister tous les sites de la table de liaison, c'est facile mais faire la
liaison entre src et dst, je ne sais pas faire.
>> Autre chose : j'ai lu qu'il ne fallait pas stocker des informations que
>> l'on pouvait calculer. Il se trouve qu'il y des informations que je peux
>> rapport au nord) est égal à celui du site distant + ou - 180°. La
>> fréquence est dite « haute » si celle d'en face est dite « basse ».
>
> en général, on parle d'attribut calculé:
>
> par exemple t'as la TVA, le HT et le TTC... stocker les 3 n'a pas de
> sens car à partir de 2 tu peux en recalculer un 3°...
> par exemple t'as la TVA, le HT et le TTC... stocker les 3 n'a pas de
>
> par contre, en effet, si tu prend l'état civil d'une personne, t'as
> sexe M/F sur un seul champ: tu vas pas dire qu'il faut pas stocker
> F parce que tu peux le déduire si t'as pas M....
Non, c'est différent, dans le cas de l'état civil, tu peux avoir soit
M ou F et tu n'as pas de contrainte. Si par contre tu prends un couple
(non homosexuel), c'est différent tu ne peux pas avoir deux M ou deux
F dans le même couple. Je veux éviter d'une part, d'avoir des
incohérences (deux bandes hautes dans le même lien, la somme des azimut
qui n'est pas égal à 360°), d'autre part de consommer de l'espace
lorsque ce n'est pas nécessaire. Je pense que seule la table à plat
(sans la table de liaison) me le permet.
> donc si t'as deux type de fréquence H/B... ben tu créé un champ et tu
> met la valeur qui va bien...
>
> si par contre t'as une règle qui dit si bande_de_frequence = ??? alors
>
> c'est bas... et que tu stocke la bande de fréquence, en effet, tu
> stocke pas la fréquence basse...
Il y a une fréquence basse et une fréquence haute dans la bande de
fréquence.
> au pire, si t'as des règles lourdes à coder et que tu veux éviter la
> redondances, tu peux utiliser des mécanismes de vues par exemple,
>> Avec toutes ces contraintes, j'en arrive à me dire qu'il est plus simple
>> de supprimer la table intermédiaire et d'avoir une table LIEN comme il
>> suit :
>> - lien_id
>> - bande de fréquence
>> - débit
>> - id_site_A
>> - antenne_A
>> - hauteur_A
>> - azimut_A
>> - fréquence_A
>> - antenne_A
>> - hauteur_A
>> - azimut_A
>> - id_site_B
>> - antenne_B
>> - hauteur_B
>
> oui, dépend de l'évolution de ton logiciel... tu va pas créer une
>> - antenne_B
>> - hauteur_B
>
> table et plein de jointure pour 1 attributs... si a terme t'en a 10 la
> question se pose... si a terme t'as des connexion multiples aussi...
>
>> Bref, mon manque d'expérience m'empêche de savoir quelle solution
> question se pose... si a terme t'as des connexion multiples aussi...
>
>> adopter. Pouvez-vous m'indiquer d'une part si ces deux solutions sont
>> viables et d'autres part quels sont leurs avantages/inconvénients ?
>
> en l'état avec aussi peu de champs, les deux solutions sont correctes...
Il y en a bien plus, c'était juste pour l'exemple.
> la solution compliquées sera cependant plus évolutive dans le temps...
C'est ce qui me semble aussi.
> dans tous les cas, tu peux utiliser des vues (j'ai le terme "requete
>
> d'ailleurs, si tu base tout sur ces vues (sauf insert/delete/update),
> tu pourras plus facilement faire évoluer ton schéma sans trop impacter
> d'ailleurs, si tu base tout sur ces vues (sauf insert/delete/update),
> le reste de l'application ultérieurement....
Ok, merci pour la réponse.
--
Benoit Izac
pif34
Nov 1, 2011, 9:22:57 AM11/1/11
to
Le 01/11/2011 13:56, Benoit Izac a ï¿œcrit :
> Peut-ï¿œtre, je ne connais absolument rien en thï¿œorie des graphes. Si tu
> me dis que c'est indispensable pour rï¿œsoudre mon problï¿œme, je veux bien
> y jeter un ï¿œil.
non, en informatique, on retrouve grossomodo deux structures des donnï¿œes
essentiellement: les espaces multidimensionner et les graphes (rï¿œseau de
transport de communication, sociaux, etc ...). T'as pas besoin de
connaitre la thï¿œorie des graphes, mais je t'en recommande la lecture,
c'est au programme de la premiï¿œre annï¿œe d'IUT...
je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
mï¿œtier...
> Pour moi c'est un peu plus simple (tu as supprimￜ lien_id mais ￜa ne
site ou autre....
> Il faut que je teste car j'ai du mal a suivre la requï¿œte (sans doute
> Non, pour moi, ï¿œa liste tous les sites, mais pas le distant. ï¿œa
> correspond ￜ ce que je faisais ￜ la fin de mon post initial avec des
> CREATE VIEW et UNION.
ben les sites sont toujours distants les un des autres... dans tous les
cas, t'as toutes les billes... ce que tu as a faire c'est de requetes
SQL de base avec des jointures, si t'en a jamais fait, je te recommande
une formation ou te d'intￜresser un peu plus ￜ ca avant de te lancer...
de toute faï¿œon tu y couperas pas...
> Mï¿œme remarque que prï¿œcï¿œdemment et c'est justement ï¿œa mon problï¿œme,
> Non, c'est diffï¿œrent, dans le cas de l'ï¿œtat civil, tu peux avoir soit
> F dans le mï¿œme couple. Je veux ï¿œviter d'une part, d'avoir des
> incohï¿œrences (deux bandes hautes dans le mï¿œme lien, la somme des azimut
> qui n'est pas ￜgal ￜ 360ￜ), d'autre part de consommer de l'espace
> lorsque ce n'est pas nￜcessaire. Je pense que seule la table ￜ plat
largement tenir ce que tu lui demande... je connais pas la volumï¿œtrie,
mais j'ai pas peur pour quelques champs vides...
la; je maitrise pas les questions mï¿œtiers, donc c'est pas la peine
d'aller plus loin.. t'as les ￜlￜments de base, je t'ai expliquￜ ce qu'on
appelle champ calculￜ... c'est un attribut qui peut etre calculￜ ￜ
partir des autres. A toi de voir si tu peux le faire ou pas...
> Peut-ï¿œtre, je ne connais absolument rien en thï¿œorie des graphes. Si tu
> me dis que c'est indispensable pour rï¿œsoudre mon problï¿œme, je veux bien
> y jeter un ï¿œil.
non, en informatique, on retrouve grossomodo deux structures des donnï¿œes
essentiellement: les espaces multidimensionner et les graphes (rï¿œseau de
transport de communication, sociaux, etc ...). T'as pas besoin de
connaitre la thï¿œorie des graphes, mais je t'en recommande la lecture,
c'est au programme de la premiï¿œre annï¿œe d'IUT...
je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
mï¿œtier...
> Pour moi c'est un peu plus simple (tu as supprimￜ lien_id mais ￜa ne
> change rien) :
> SELECT id_src, id_dst FROM lien;
ben la jointure que j'avais indiquￜ, c'ￜtait pour retrouver le nom du
> SELECT id_src, id_dst FROM lien;
site ou autre....
> Il faut que je teste car j'ai du mal a suivre la requï¿œte (sans doute
> parce que je n'ai pas l'habitude de lire cette syntaxe).
c'est du SQL standard
> Non, pour moi, ï¿œa liste tous les sites, mais pas le distant. ï¿œa
> correspond ￜ ce que je faisais ￜ la fin de mon post initial avec des
> CREATE VIEW et UNION.
ben les sites sont toujours distants les un des autres... dans tous les
cas, t'as toutes les billes... ce que tu as a faire c'est de requetes
SQL de base avec des jointures, si t'en a jamais fait, je te recommande
une formation ou te d'intￜresser un peu plus ￜ ca avant de te lancer...
de toute faï¿œon tu y couperas pas...
> Mï¿œme remarque que prï¿œcï¿œdemment et c'est justement ï¿œa mon problï¿œme,
> lister tous les sites de la table de liaison, c'est facile mais faire la
> liaison entre src et dst, je ne sais pas faire.
tu fais 2 jointures, c'est tout...
> liaison entre src et dst, je ne sais pas faire.
> Non, c'est diffï¿œrent, dans le cas de l'ï¿œtat civil, tu peux avoir soit
> M ou F et tu n'as pas de contrainte. Si par contre tu prends un couple
> (non homosexuel), c'est diffï¿œrent tu ne peux pas avoir deux M ou deux
> F dans le mï¿œme couple. Je veux ï¿œviter d'une part, d'avoir des
> incohï¿œrences (deux bandes hautes dans le mï¿œme lien, la somme des azimut
> qui n'est pas ￜgal ￜ 360ￜ), d'autre part de consommer de l'espace
> lorsque ce n'est pas nￜcessaire. Je pense que seule la table ￜ plat
> (sans la table de liaison) me le permet.
l'espace te pose pas trop de question... une base correcte devrait
largement tenir ce que tu lui demande... je connais pas la volumï¿œtrie,
mais j'ai pas peur pour quelques champs vides...
la; je maitrise pas les questions mï¿œtiers, donc c'est pas la peine
d'aller plus loin.. t'as les ￜlￜments de base, je t'ai expliquￜ ce qu'on
appelle champ calculￜ... c'est un attribut qui peut etre calculￜ ￜ
partir des autres. A toi de voir si tu peux le faire ou pas...
Benoit Izac
Nov 1, 2011, 10:24:15 AM11/1/11
to
Bonjour,
le 01/11/2011 à 14:22, pif a écrit dans le message
<4eaff2af$0$8436$426a...@news.free.fr> :
>> Peut-être, je ne connais absolument rien en théorie des graphes. Si tu
>> me dis que c'est indispensable pour résoudre mon problème, je veux bien
>> y jeter un œil.
> (réseau de transport de communication, sociaux, etc ...). T'as pas
> besoin de connaitre la théorie des graphes, mais je t'en recommande la
> lecture, c'est au programme de la première année d'IUT...
Je n'ai pas précisé : j'ai terminé mes études il y a plus de 15 ans et
je ne travaille pas dans l'informatique. J'admets donc bien volontiers
mes lacunes dans ce domaine et c'est pourquoi je demandais si ça avait
un quelquonque intérêt pour mon besoin.
[...]
CREATE VIEW site_A SELECT * FROM link_site WHERE side = "A";
CREATE VIEW site_B SELECT * FROM link_site WHERE side = "B";
SELECT site_A.site_id AS site_A, site_B.site_id AS site_B
FROM site_A, site_B
WHERE site_A.link_id = site_B.link_id;
Je pense que c'est correct mais je ne sais pas le faire en une seule
requête.
>> Non, c'est différent, dans le cas de l'état civil, tu peux avoir soit
>> incohérences (deux bandes hautes dans le même lien, la somme des azimut
>> qui n'est pas égal à 360°), d'autre part de consommer de l'espace
>> lorsque ce n'est pas nécessaire. Je pense que seule la table à plat
> d'aller plus loin.. t'as les éléments de base, je t'ai expliqué ce
> qu'on appelle champ calculé... c'est un attribut qui peut etre calculé
> à partir des autres. A toi de voir si tu peux le faire ou pas...
Est-ce qu'une contrainte CHECK serait la solution pour éviter les
incohérences ?
--
Benoit Izac
le 01/11/2011 à 14:22, pif a écrit dans le message
<4eaff2af$0$8436$426a...@news.free.fr> :
>> Peut-être, je ne connais absolument rien en théorie des graphes. Si tu
>> me dis que c'est indispensable pour résoudre mon problème, je veux bien
>> y jeter un œil.
>
> non, en informatique, on retrouve grossomodo deux structures des
> données essentiellement: les espaces multidimensionner et les graphes
> non, en informatique, on retrouve grossomodo deux structures des
> (réseau de transport de communication, sociaux, etc ...). T'as pas
> besoin de connaitre la théorie des graphes, mais je t'en recommande la
> lecture, c'est au programme de la première année d'IUT...
>
> je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
> métier...
> je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
Je n'ai pas précisé : j'ai terminé mes études il y a plus de 15 ans et
je ne travaille pas dans l'informatique. J'admets donc bien volontiers
mes lacunes dans ce domaine et c'est pourquoi je demandais si ça avait
un quelquonque intérêt pour mon besoin.
[...]
>> Même remarque que précédemment et c'est justement ça mon problème,
>> lister tous les sites de la table de liaison, c'est facile mais faire la
>> liaison entre src et dst, je ne sais pas faire.
>
> tu fais 2 jointures, c'est tout...
Par exemple avec la table link_site (site_id, link_id, side) ?
>> liaison entre src et dst, je ne sais pas faire.
>
> tu fais 2 jointures, c'est tout...
CREATE VIEW site_A SELECT * FROM link_site WHERE side = "A";
CREATE VIEW site_B SELECT * FROM link_site WHERE side = "B";
SELECT site_A.site_id AS site_A, site_B.site_id AS site_B
FROM site_A, site_B
WHERE site_A.link_id = site_B.link_id;
Je pense que c'est correct mais je ne sais pas le faire en une seule
requête.
>> Non, c'est différent, dans le cas de l'état civil, tu peux avoir soit
>> M ou F et tu n'as pas de contrainte. Si par contre tu prends un couple
>> (non homosexuel), c'est différent tu ne peux pas avoir deux M ou deux
>> F dans le même couple. Je veux éviter d'une part, d'avoir des
>> incohérences (deux bandes hautes dans le même lien, la somme des azimut
>> qui n'est pas égal à 360°), d'autre part de consommer de l'espace
>> lorsque ce n'est pas nécessaire. Je pense que seule la table à plat
>> (sans la table de liaison) me le permet.
>
> l'espace te pose pas trop de question... une base correcte devrait
> largement tenir ce que tu lui demande... je connais pas la volumétrie,
>
> l'espace te pose pas trop de question... une base correcte devrait
> mais j'ai pas peur pour quelques champs vides...
>
> la; je maitrise pas les questions métiers, donc c'est pas la peine
>
> d'aller plus loin.. t'as les éléments de base, je t'ai expliqué ce
> qu'on appelle champ calculé... c'est un attribut qui peut etre calculé
> à partir des autres. A toi de voir si tu peux le faire ou pas...
Est-ce qu'une contrainte CHECK serait la solution pour éviter les
incohérences ?
--
Benoit Izac
pif34
Nov 1, 2011, 12:51:12 PM11/1/11
to
Le 01/11/2011 15:24, Benoit Izac a ï¿œcrit :
>> je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
>> mï¿œtier...
>
> Je n'ai pas prￜcisￜ : j'ai terminￜ mes ￜtudes il y a plus de 15 ans et
> un quelquonque intï¿œrï¿œt pour mon besoin.
c'est bien ce que je pensais aprï¿œs ta rï¿œponse ;)
> Par exemple avec la table link_site (site_id, link_id, side) ?
>
> CREATE VIEW site_A SELECT * FROM link_site WHERE side = "A";
> CREATE VIEW site_B SELECT * FROM link_site WHERE side = "B";
> SELECT site_A.site_id AS site_A, site_B.site_id AS site_B
> FROM site_A, site_B
> WHERE site_A.link_id = site_B.link_id;
quand tu fais une jointure, c'est plus propre (lisible) de l'exprimer
avec un join plutot qu'avec un where et des "="... conformￜment ￜ la
norme SQL ANSI
un create view, c'est pareil qu'un select :
si t'as une table lien avec src et dest:
create view v1 as select sa.*, sb.* from
lien ls
join site sa on ls.idsrc = sa.id
join site sb on ls.idtrg = sb.id
si t'as une table avec une orientation (donc deux lignes pour les deux
sites associￜs ￜ un seul lien)
create view v2 as
select sa.*, sb.*
from lien_site lsa
join site sa on ls.id_site = sa.id
join lien_site lsb on lsa.id_lien = lsb.id_lien
and lsa.orientation = 1 and lsb.orientation = 0
join site sb on lsb.id_site = sb.id
>
> Je pense que c'est correct mais je ne sais pas le faire en une seule
> requï¿œte.
> Est-ce qu'une contrainte CHECK serait la solution pour ï¿œviter les
> incohï¿œrences ?
quelques incohï¿œrences ?
t'as des contraintes d'intￜgritￜ (unicitￜ, etc. ) qui sont dￜjￜ
intï¿œressantes... tu peux ajouter des contraintes checks, et meme faire
bien plus complexe en associant une fonction stockￜe ￜ tes contraintes
check...
tu peux meme aller plus loin avec des triggers et du PL sql...
mais ￜtant donnￜ que t'es dￜbutant en matiￜre de SQL, je te recommande
d'y aller progressivement... commence pas bï¿œtonner ton schï¿œma avec les
contraintes existantes, tu verras ensuite pour les check et triggers....
>> je mentionnais ca c'est c'est un terme on ne peut plus courant dans le
>
> Je n'ai pas prￜcisￜ : j'ai terminￜ mes ￜtudes il y a plus de 15 ans et
> je ne travaille pas dans l'informatique. J'admets donc bien volontiers
> mes lacunes dans ce domaine et c'est pourquoi je demandais si ï¿œa avait
> un quelquonque intï¿œrï¿œt pour mon besoin.
c'est bien ce que je pensais aprï¿œs ta rï¿œponse ;)
> Par exemple avec la table link_site (site_id, link_id, side) ?
>
> CREATE VIEW site_A SELECT * FROM link_site WHERE side = "A";
> CREATE VIEW site_B SELECT * FROM link_site WHERE side = "B";
> SELECT site_A.site_id AS site_A, site_B.site_id AS site_B
> FROM site_A, site_B
> WHERE site_A.link_id = site_B.link_id;
avec un join plutot qu'avec un where et des "="... conformￜment ￜ la
norme SQL ANSI
un create view, c'est pareil qu'un select :
si t'as une table lien avec src et dest:
create view v1 as select sa.*, sb.* from
lien ls
join site sa on ls.idsrc = sa.id
join site sb on ls.idtrg = sb.id
si t'as une table avec une orientation (donc deux lignes pour les deux
sites associￜs ￜ un seul lien)
create view v2 as
select sa.*, sb.*
from lien_site lsa
join site sa on ls.id_site = sa.id
join lien_site lsb on lsa.id_lien = lsb.id_lien
and lsa.orientation = 1 and lsb.orientation = 0
join site sb on lsb.id_site = sb.id
>
> Je pense que c'est correct mais je ne sais pas le faire en une seule
> Est-ce qu'une contrainte CHECK serait la solution pour ï¿œviter les
> incohï¿œrences ?
quelques incohï¿œrences ?
t'as des contraintes d'intￜgritￜ (unicitￜ, etc. ) qui sont dￜjￜ
intï¿œressantes... tu peux ajouter des contraintes checks, et meme faire
bien plus complexe en associant une fonction stockￜe ￜ tes contraintes
check...
tu peux meme aller plus loin avec des triggers et du PL sql...
mais ￜtant donnￜ que t'es dￜbutant en matiￜre de SQL, je te recommande
d'y aller progressivement... commence pas bï¿œtonner ton schï¿œma avec les
contraintes existantes, tu verras ensuite pour les check et triggers....
Benoit Izac
Nov 1, 2011, 3:47:25 PM11/1/11
to
Bonjour,
le 01/11/2011 à 17:51, pif a écrit dans le message
<4eb02393$0$14468$426a...@news.free.fr> :
>> Est-ce qu'une contrainte CHECK serait la solution pour éviter les
>> incohérences ?
>
> quelques incohérences ?
C'est expliqué dans ce que tu as coupé : deux bandes hautes dans le même
lien, la somme des azimut qui n'est pas égal à 360°.
> t'as des contraintes d'intégrité (unicité, etc. ) qui sont déjà
> intéressantes... tu peux ajouter des contraintes checks, et meme faire
> bien plus complexe en associant une fonction stockée à tes contraintes
> d'y aller progressivement... commence pas bétonner ton schéma avec les
mette tout cela en place. Je vais essayer le schéma avec la table
intermédiaire, c'est ce qui me semble le plus facile à maintenir (mais
pas à mettre en place). Je reviendrais si j'ai des soucis (et après un
peu de lecture).
--
Benoit Izac
le 01/11/2011 à 17:51, pif a écrit dans le message
<4eb02393$0$14468$426a...@news.free.fr> :
>> Est-ce qu'une contrainte CHECK serait la solution pour éviter les
>> incohérences ?
>
> quelques incohérences ?
C'est expliqué dans ce que tu as coupé : deux bandes hautes dans le même
lien, la somme des azimut qui n'est pas égal à 360°.
> t'as des contraintes d'intégrité (unicité, etc. ) qui sont déjà
> intéressantes... tu peux ajouter des contraintes checks, et meme faire
> bien plus complexe en associant une fonction stockée à tes contraintes
> check...
>
> tu peux meme aller plus loin avec des triggers et du PL sql...
> mais étant donné que t'es débutant en matière de SQL, je te recommande
>
> tu peux meme aller plus loin avec des triggers et du PL sql...
> d'y aller progressivement... commence pas bétonner ton schéma avec les
> contraintes existantes, tu verras ensuite pour les check et
> triggers....
Tu as sans doute raison, avant de m'occuper de détail, il faut que je
> triggers....
mette tout cela en place. Je vais essayer le schéma avec la table
intermédiaire, c'est ce qui me semble le plus facile à maintenir (mais
pas à mettre en place). Je reviendrais si j'ai des soucis (et après un
peu de lecture).
--
Benoit Izac
pif34
Nov 1, 2011, 4:40:09 PM11/1/11
to
Le 01/11/2011 20:47, Benoit Izac a écrit :
> Bonjour,
>
> le 01/11/2011 à 17:51, pif a écrit dans le message
> <4eb02393$0$14468$426a...@news.free.fr> :
>
>>> Est-ce qu'une contrainte CHECK serait la solution pour éviter les
>>> incohérences ?
>>
>> quelques incohérences ?
>
> C'est expliqué dans ce que tu as coupé : deux bandes hautes dans le même
> lien, la somme des azimut qui n'est pas égal à 360°.
un contrainte check ne peut porter que sur un tuple (ligne) à la fois...
> Bonjour,
>
> le 01/11/2011 à 17:51, pif a écrit dans le message
> <4eb02393$0$14468$426a...@news.free.fr> :
>
>>> Est-ce qu'une contrainte CHECK serait la solution pour éviter les
>>> incohérences ?
>>
>> quelques incohérences ?
>
> C'est expliqué dans ce que tu as coupé : deux bandes hautes dans le même
> lien, la somme des azimut qui n'est pas égal à 360°.
par conséquent, si tu reste sur un lien, c'est facile:
ALTER TABLE lien ADD CHECK (azimuth_src + azimuth_trg = 360);
pour les bandes:
ALTER TABLE lien ADD CHECK ((b1 = "H" and b2 = 'B') or (b1 = 'B' and b2
= 'B') );
si t'as plusieurs ligne à gérer, tu vas avoir un problème: quand tu
inseres la première ligne, la contrainte n'est pas respectée...
par conséquent il faut que tu procede par transaction et désactive la
contrainte au début puis la réactive à la fin pour pour faire propre....
souvent, meme si c'est pas l'idéal, on code sans dans la partie
applicative (en faisant en sorte que ce soit relativement propre et
centralisé).
> Tu as sans doute raison, avant de m'occuper de détail, il faut que je
> mette tout cela en place. Je vais essayer le schéma avec la table
> intermédiaire, c'est ce qui me semble le plus facile à maintenir (mais
> pas à mettre en place). Je reviendrais si j'ai des soucis (et après un
> peu de lecture).
suite, t'auras un usage assez simple....
de toute facon, cette seconde solution reste relativement rudimentaire
en matière d'informatique... dans une application, tu seras rapidement
amené à consulter des cas plus complexes...
bon courrage
Benoit Izac
Nov 1, 2011, 5:09:46 PM11/1/11
to
Bonjour,
le 01/11/2011 � 21:40, pif a �crit dans le message
<4eb05927$0$2836$426a...@news.free.fr> :
>>>> Est-ce qu'une contrainte CHECK serait la solution pour �viter les
>>>> incoh�rences ?
>>>
>>> quelques incoh�rences ?
>>
>> C'est expliqu� dans ce que tu as coup� : deux bandes hautes dans le m�me
>> lien, la somme des azimut qui n'est pas �gal � 360�.
>
> un contrainte check ne peut porter que sur un tuple (ligne) � la
> fois... par cons�quent, si tu reste sur un lien, c'est facile:
besoin de contrainte car je ne vais pas rentrer les informations pour le
deuxi�me site vu que je les ai d�j� (indirectement).
> si t'as plusieurs ligne � g�rer, tu vas avoir un probl�me: quand tu
> inseres la premi�re ligne, la contrainte n'est pas respect�e...
>
> par cons�quent il faut que tu procede par transaction et d�sactive la
> contrainte au d�but puis la r�active � la fin pour pour faire
> propre....
>
> souvent, meme si c'est pas l'id�al, on code sans dans la partie
Je comprends. En revanche, je peux faire une requ�te qui fait le calcul
et la v�rification et qui me pr�vient des entr�es qui sont en d�saccord.
Je verrai l'erreur plus tard mais au moins j'aurai l'information.
> bon courrage
Merci.
--
Benoit Izac
le 01/11/2011 � 21:40, pif a �crit dans le message
<4eb05927$0$2836$426a...@news.free.fr> :
>>>> Est-ce qu'une contrainte CHECK serait la solution pour �viter les
>>>> incoh�rences ?
>>>
>>> quelques incoh�rences ?
>>
>> C'est expliqu� dans ce que tu as coup� : deux bandes hautes dans le m�me
>> lien, la somme des azimut qui n'est pas �gal � 360�.
>
> un contrainte check ne peut porter que sur un tuple (ligne) � la
> fois... par cons�quent, si tu reste sur un lien, c'est facile:
>
> ALTER TABLE lien ADD CHECK (azimuth_src + azimuth_trg = 360);
> pour les bandes:
>
> ALTER TABLE lien ADD CHECK ((b1 = "H" and b2 = 'B') or (b1 = 'B' and
> b2 = 'B') );
Dommage car si je mets tout dans une seule table, du coup, je n'ai plus
> ALTER TABLE lien ADD CHECK (azimuth_src + azimuth_trg = 360);
> pour les bandes:
>
> ALTER TABLE lien ADD CHECK ((b1 = "H" and b2 = 'B') or (b1 = 'B' and
> b2 = 'B') );
besoin de contrainte car je ne vais pas rentrer les informations pour le
deuxi�me site vu que je les ai d�j� (indirectement).
> si t'as plusieurs ligne � g�rer, tu vas avoir un probl�me: quand tu
> inseres la premi�re ligne, la contrainte n'est pas respect�e...
>
> par cons�quent il faut que tu procede par transaction et d�sactive la
> contrainte au d�but puis la r�active � la fin pour pour faire
> propre....
>
> souvent, meme si c'est pas l'id�al, on code sans dans la partie
> applicative (en faisant en sorte que ce soit relativement propre et
> centralis�).
Je comprends. En revanche, je peux faire une requ�te qui fait le calcul
et la v�rification et qui me pr�vient des entr�es qui sont en d�saccord.
Je verrai l'erreur plus tard mais au moins j'aurai l'information.
> bon courrage
Merci.
--
Benoit Izac
SQLpro
Nov 29, 2011, 9:33:00 AM11/29/11
to
Bonjour,
la modélisation d'une base se fait au niveau conceptuel. Au niveau
physique vous n'y comprendrez rien.
Voici une solution générique :
MCD avec deux entités :
http://blog.developpez.com/media/MCD_deux_entites_et_deux_liens.gif
MPD correspondant
http://blog.developpez.com/media/MPD_deux_entites_et_deux_liens.gif
et en auto référence, MCD :
http://blog.developpez.com/media/MCD_une_entites_et_deux_liens.gif
MPD correspondant :
http://blog.developpez.com/media/MPD_une_entites_et_deux_liens.gif
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Avec un MCD merise, la solution est assez simple :
la modélisation d'une base se fait au niveau conceptuel. Au niveau
physique vous n'y comprendrez rien.
Voici une solution générique :
MCD avec deux entités :
http://blog.developpez.com/media/MCD_deux_entites_et_deux_liens.gif
MPD correspondant
http://blog.developpez.com/media/MPD_deux_entites_et_deux_liens.gif
et en auto référence, MCD :
http://blog.developpez.com/media/MCD_une_entites_et_deux_liens.gif
MPD correspondant :
http://blog.developpez.com/media/MPD_une_entites_et_deux_liens.gif
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Avec un MCD merise, la solution est assez simple :
Benoit Izac
Nov 29, 2011, 3:09:29 PM11/29/11
to
Bonjour,
le 29/11/2011 à 15:33, SQLpro a écrit dans le message
<4ed4ed1c$0$2269$426a...@news.free.fr> :
> la modélisation d'une base se fait au niveau conceptuel. Au niveau
> physique vous n'y comprendrez rien.
>
> Voici une solution générique :
> MCD avec deux entités :
> http://blog.developpez.com/media/MCD_deux_entites_et_deux_liens.gif
>
> MPD correspondant
> http://blog.developpez.com/media/MPD_deux_entites_et_deux_liens.gif
>
> et en auto référence, MCD :
> http://blog.developpez.com/media/MCD_une_entites_et_deux_liens.gif
>
> MPD correspondant :
> http://blog.developpez.com/media/MPD_une_entites_et_deux_liens.gif
Je ne comprends pas ce dernier exemple. Si « Entité A » dans mon cas est
un site, je comprends le MCD comme :
1) zéro ou un site peut avoir zéro ou plusieurs sites distants
2) un ou plusieurs sites peuvent être le(s) distant(s) de zéro ou
plusieurs sites.
Le MDP si je comprends bien est une table site dans laquelle on liste
les distants. Ça me parait un peu bancal car il faut ajouter un champ
à chaque nouveau site distant.
Mais il se peut que je n'ai rien compris...
--
Benoit Izac
le 29/11/2011 à 15:33, SQLpro a écrit dans le message
<4ed4ed1c$0$2269$426a...@news.free.fr> :
> la modélisation d'une base se fait au niveau conceptuel. Au niveau
> physique vous n'y comprendrez rien.
>
> Voici une solution générique :
> MCD avec deux entités :
> http://blog.developpez.com/media/MCD_deux_entites_et_deux_liens.gif
>
> MPD correspondant
> http://blog.developpez.com/media/MPD_deux_entites_et_deux_liens.gif
>
> et en auto référence, MCD :
> http://blog.developpez.com/media/MCD_une_entites_et_deux_liens.gif
>
> MPD correspondant :
> http://blog.developpez.com/media/MPD_une_entites_et_deux_liens.gif
un site, je comprends le MCD comme :
1) zéro ou un site peut avoir zéro ou plusieurs sites distants
2) un ou plusieurs sites peuvent être le(s) distant(s) de zéro ou
plusieurs sites.
Le MDP si je comprends bien est une table site dans laquelle on liste
les distants. Ça me parait un peu bancal car il faut ajouter un champ
à chaque nouveau site distant.
Mais il se peut que je n'ai rien compris...
--
Benoit Izac
0 new messages