Zhodnotenie úloh z minulého stretnutia

Opis stretnutia

Príloha A. k stretnutiu č.26:
E–mailová komunikácia ohľadom dátového modelu (19.04.2001-22.04.2001)

-------------------------------------------------------------------------

Zolo:

On Thu, 19 Apr 2001, Kubo Zdeno wrote:

> napisem tu postup ako vytvorit jednu poziadavku s viac segmentami. mozno to

> osvetli niektore casti modelu...

>

>

> no ide o to ze u nas je kazdy segment jedna poziadavka a tam to mozne urcit

> je...

>

To bolo zatial! (Alebo nie?) Vtedy v jednej poziadavke bol len jeden

segment (to je jedno, ze sme tam mali accesspointy), takze bolo mozne

jednoznacne urcit prarametre k segmentu (k 1 segmentu bola priradena

jedna mnozina parametrov).

Pises, ze kazdy segment bude nadalej (je) jedna poziadavka. Potom na

zaklade coho urcim, ze 2 rozne poziadavky mam dat do jednej tabulky pri

generovani formularov?

Maju rovnaku techniku a rovnaky nerv? To je OK, ale co s tym, ze tie

zhoduju a v ohranicenia su rozne (hlavne urcenie strany: lava-prava).

> no a tu je ten postup:

>

> ak chcete celu tabulku mat ako jednu poziadavku potom je treba pridat do

> struct_title dalsie Titles:

> priklad:

> Dist. Acc. 2

> Prox. Acc. 2

>

> Dist. Acc. 2

> Prox. Acc. 3

>

> (podla toho kolko chcete segmentov... tu pribudnu dva)

> potom k technike pridat vazbu na tieto nove Titles...

> ak by mali tieto Titles atribut nepovinne je mozne ich nezadat resp. ak budu

> povinne tak ich bude treba zadat...

A mne sa zda (podla toho co tu hore pises), ze v jednej poziadavke budeme

mat viacerych segmentov. Je to tak alebo nie? Miso mi to vysvetlil tak, ze

1 poziadavka bude obsahovat viac segmentov napr:

Title Name order group

nerve medianus 1 1

dist.acc wrist 2 2 _ 1. segment

prox. acc m. oponens 3 2 /

dist.acc wrist 4 3 - 2. segment

prox. acc axila 5 3 /

dist. acc axila 6 4 - 3. segment

prox. acc elbow 7 4 /

Ak je to tak, potom k vsetkym segmentom mozes priradit len jednu mnozinu

parametrov (su spolocne pre vsetky segmenty)

Ja to stale nechapem, a mozno preto moj navrh mozno je jednoduchsi a

netreba tolko veci menit. A mozno to nechapu ostatny, preto dam jeden

priklad:

V tab. request_group by sme evidovali mnozinu poziadaviek, ktore su na

jednom nerve s urcitou technikou (a nie len koncatiny). Do tab request by

sme pridali atribut Order, alebo nieco co by nam hovoril o poradi

vykonavania testov (priorita je nieco ine) na

tom nerve - aby sme zacali merat na mediane zdola nahor a nie opacne,

takisto aby sme mohli vykreslit celu tabulku (pre viacere segmenty) podla

poradia.

Potom obsah tabuliek by vyzeral nasledovne:

request_group

=============

id name

1 medianus - lava

2 medianus - prava

3 struktura na nohe - lava

4 struktura na nohe - prava

...

tie su v inych tabulkach

kvoli jednoduchosti to pisem sem

request / \

======= / \

id request_group_id ORDER technique struktura segment

1 1 1 MNS medianus opon.-wrist

2 1 2 MNS medianus wrist-axila

3 1 3 MNS medianus axila-elbow

4 2 1 MNS medianus opon.-wrist

5 2 2 MNS...

6 2 3 MNS...

7 3 1 MNS noha segment na nohe

8 3 2 MNS noha segment na nohe

...

Poziadavky s ID. 1-3 maju v ohraniceniach oznacenu lavu stranu a 4-6 pravu

stranu.

Atribut ORDER nemusi vyjadrovat len poradie v ramci groupu, ale mozeme

postupne cislovat (nezcinat vzdy od 1), potom doktorovi dame jednoznacne

poradie v ktorom ma merat. A ak to chce usporiadat inak (podla nejakeho

atributu), potom mu umoznime, s tym ze poradie poziadaviek v ramci groupu

sa musi zachovat (druhy kriterium sortovania)

Vyhody:

=======

- treba pridat len 1 atribut, netreba menit vazby, pridat novu tabulku, aj

ciselniky by ostali tak ako su teraz, nemusime nic ine menit v DB (to moze

byt vyhodne aj pre druhy tim)

- ku kazdej poziadavke mozno definovat ine parametre (je to pozadovane) a

ohranicenie (Misova verzia to nedovoli - pozri priklad hore)

- viem jednoznacne urcit poradie merani resp. poradie stlpcov v tabulke

napriklad ked budem merat na skupine medianus-lava, potom nameram

najprv na segmente opon-wrist, potom wrist-axila, atd., cize vykreslim

nasl. tabulku:

Parameter\segment opon-wrist wrist-axila axila-elbow

length 5 cm zadava povinne zadava povinne

Amplitude povinny povinny povinny

Duration povinny povinny povinny

Conduciton n/a povinny povinny

...

Nevyhody: Neviem - povedzte na vas nazor.

>

> a samozrejme nadefinovat parametre (prip. conditions pre jednotlive segmenty -

> tie co su spolocne netreba...)

> potom vytvorit vazby (technika - parametre) a samotnu poziadavku...

>

> ------------------------------------------------------

> tak ako to je teraz to je podla mna lepsie... ale toto je v modeli mozne

> tiez... ide o to co s tym spravi Asterix...

Hlavne ide o Asterixa - nemame vela casu na to.

> ------------------------------------------------------

>

> takze zatial sa majte...

>

Majte sa dobre!

Zolo

------------------------------------------------------------------------------------------

Zdeno:

Varga Zoltan wrote:

On Thu, 19 Apr 2001, Kubo Zdeno wrote:

> napisem tu postup ako vytvorit jednu poziadavku s viac segmentami. mozno to

> osvetli niektore casti modelu...

>

>

> no ide o to ze u nas je kazdy segment jedna poziadavka a tam to mozne urcit

> je...

>

To bolo zatial! (Alebo nie?) Vtedy v jednej poziadavke bol len jeden

segment (to je jedno, ze sme tam mali accesspointy), takze bolo mozne

jednoznacne urcit prarametre k segmentu (k 1 segmentu bola priradena

jedna mnozina parametrov).

Pises, ze kazdy segment bude nadalej (je) jedna poziadavka. Potom na

zaklade coho urcim, ze 2 rozne poziadavky mam dat do jednej tabulky pri

generovani formularov?

Maju rovnaku techniku a rovnaky nerv? To je OK, ale co s tym, ze tie

zhoduju a v ohranicenia su rozne (hlavne urcenie strany: lava-prava).

zrejme to bude ina poziadavka (ak ma ine podmienky...)

> no a tu je ten postup:

>

> ak chcete celu tabulku mat ako jednu poziadavku potom je treba pridat do

> struct_title dalsie Titles:

> priklad:

> Dist. Acc. 2

> Prox. Acc. 2

>

> Dist. Acc. 2

> Prox. Acc. 3

>

> (podla toho kolko chcete segmentov... tu pribudnu dva)

> potom k technike pridat vazbu na tieto nove Titles...

> ak by mali tieto Titles atribut nepovinne je mozne ich nezadat resp. ak budu

> povinne tak ich bude treba zadat...

A mne sa zda (podla toho co tu hore pises), ze v jednej poziadavke budeme

mat viacerych segmentov. Je to tak alebo nie? Miso mi to vysvetlil tak, ze

1 poziadavka bude obsahovat viac segmentov napr:

Title Name order group

nerve medianus 1 1

dist.acc wrist 2 2 _ 1. segment

prox. acc m. oponens 3 2 /

dist.acc wrist 4 3 - 2. segment

prox. acc axila 5 3 /

dist. acc axila 6 4 - 3. segment

prox. acc elbow 7 4 /

Ak je to tak, potom k vsetkym segmentom mozes priradit len jednu mnozinu

parametrov (su spolocne pre vsetky segmenty)

Ja to stale nechapem, a mozno preto moj navrh mozno je jednoduchsi a

netreba tolko veci menit. A mozno to nechapu ostatny, preto dam jeden

priklad:

V tab. request_group by sme evidovali mnozinu poziadaviek, ktore su na

jednom nerve s urcitou technikou (a nie len koncatiny). Do tab request by

sme pridali atribut Order, alebo nieco co by nam hovoril o poradi

vykonavania testov (priorita je nieco ine) na

tom nerve - aby sme zacali merat na mediane zdola nahor a nie opacne,

takisto aby sme mohli vykreslit celu tabulku (pre viacere segmenty) podla

poradia.

Potom obsah tabuliek by vyzeral nasledovne:

request_group

=============

id name

1 medianus - lava

2 medianus - prava

3 struktura na nohe - lava

4 struktura na nohe - prava

...

tie su v inych tabulkach

kvoli jednoduchosti to pisem sem

request / \

======= / \

id request_group_id ORDER technique struktura segment

1 1 1 MNS medianus opon.-wrist

2 1 2 MNS medianus wrist-axila

3 1 3 MNS medianus axila-elbow

4 2 1 MNS medianus opon.-wrist

5 2 2 MNS...

6 2 3 MNS...

7 3 1 MNS noha segment na nohe

8 3 2 MNS noha segment na nohe

...

Poziadavky s ID. 1-3 maju v ohraniceniach oznacenu lavu stranu a 4-6 pravu

stranu.

Atribut ORDER nemusi vyjadrovat len poradie v ramci groupu, ale mozeme

postupne cislovat (nezcinat vzdy od 1), potom doktorovi dame jednoznacne

poradie v ktorom ma merat. A ak to chce usporiadat inak (podla nejakeho

atributu), potom mu umoznime, s tym ze poradie poziadaviek v ramci groupu

sa musi zachovat (druhy kriterium sortovania)

Vyhody:

=======

- treba pridat len 1 atribut, netreba menit vazby, pridat novu tabulku, aj

ciselniky by ostali tak ako su teraz, nemusime nic ine menit v DB (to moze

byt vyhodne aj pre druhy tim)

- ku kazdej poziadavke mozno definovat ine parametre (je to pozadovane) a

ohranicenie (Misova verzia to nedovoli - pozri priklad hore)

- viem jednoznacne urcit poradie merani resp. poradie stlpcov v tabulke

napriklad ked budem merat na skupine medianus-lava, potom nameram

najprv na segmente opon-wrist, potom wrist-axila, atd., cize vykreslim

nasl. tabulku:

Parameter\segment opon-wrist wrist-axila axila-elbow

length 5 cm zadava povinne zadava povinne

Amplitude povinny povinny povinny

Duration povinny povinny povinny

Conduciton n/a povinny povinny

to co treba pridat je GROUP? asi ano - otazka: kam?

request_structure

tech_struct_title

structure_title

pozri predchadzajuci majl...

...

Nevyhody: Neviem - povedzte na vas nazor.

som hovoril niekedy davno ze zgrupovanie by mohlo (malo) byt podla struktury...

tim 2 chcel zgrupovanie podla hocicoho => grupy robi lekar a musel by ich teda robit podla Tvojich (nasich) predstav (tj. medianus lava, medianus prava...) co zrejme problem nie je - ide o to aky vyznam bude mat request_group a bolo by vhodne si to vyjasnit co najrychlejsie (aj s timom 2)

>

> a samozrejme nadefinovat parametre (prip. conditions pre jednotlive segmenty -

> tie co su spolocne netreba...)

> potom vytvorit vazby (technika - parametre) a samotnu poziadavku...

>

> ------------------------------------------------------

> tak ako to je teraz to je podla mna lepsie... ale toto je v modeli mozne

> tiez... ide o to co s tym spravi Asterix...

Hlavne ide o Asterixa - nemame vela casu na to.

z db hladiska je jedno co znamenaju skupiny - treba dohodnut s timom 2 ze skupiny nebudu lubovolne ale budu zgrupovat nejake poziadavky podla techniky a struktury... (inac ved to sa da podla techniky a struktury s tym ze ak su ine podmienky tak to bude ina poziadavka...)

takze sa rozhodnite - mozno by pomohlo stretnutie - cim skor - napr. dnes o 15:00 - 17:00 niekde...

> ------------------------------------------------------

>

> takze zatial sa majte...

>

Majte sa dobre!

Zolo

--

so long

Z.

--------------------------------------------------------------------------------------

Zdeno:

vsetkych zdravim!!

mam na vas par otazok:

-------------------------------------------------------

1. Treba zadavat parametre pri merani do tabulky alebo to nechame tak ako to je?

odpoved:

-------------------------------------------------------

2. Pridat typ struktury SEGMENT do tabulky structure a aj do prislusnych dalsich?

odpoved:

-------------------------------------------------------

3. Naviazat tabulky request_parameter, test a condition_value na request_structure (pridat stlpec Structure_ID)?

odpoved:

-------------------------------------------------------

4. Pouzivat request_group na grupovanie poziadaviek podla techniky a struktury alebo nechat Horne a dolne koncatiny?

odpoved:

-------------------------------------------------------

prosim o vyjadrenie od vsetkych - miso potrebuje db co najskor (a asi aj ostatni...)

prajem pekny weekend.

--

so long

Z.

-------------------------------------------------------------------------------------------

Miso:

Povazujem za potrebne to trochu doplnit (rozviest).

vsetkych zdravim!!

mam na vas par otazok:

-------------------------------------------------------

1. Treba zadavat parametre pri merani do tabulky alebo to nechame tak ako

to je?

dovod: Ak chceme na zadavanie tabulku, treba robit zmeny do spracovania v

Asterix-e.

odpoved:

-------------------------------------------------------

2. Pridat typ struktury SEGMENT (napr. typ 'S') do tabulky structure

(skutocne do tabulky structure_title) a aj do prislusnych dalsich?

dovod: aby sme odlisili segmenty (elbow - axilla, axilla - erb's point

atd) od ostatnych (recodring, stimulation strucure). Treba to pri

vytvarani tabulky podla bodu 1, ale je to lepsie odlisit aj preto, lebo je

to skutocne nieco ine (teraz to ma vsetko typ 'A' - Access point).

odpoved:

-------------------------------------------------------

3. Naviazat tabulky request_parameter, test a condition_value na

request_structure (pridat stlpec Structure_ID)?

dovod: Chceme mat elementarnu poziadavku rovnu celej tabulke z

excelovskeho suboru Dr. Kuceru, t.j. el. poziadavka = technika, struktura

+ vsetky segmenty (access pointy) + recoding, stimulation site.

Na to, aby sa merane testy a podmienky stale vztahovaly na elementarnu

poziadavku chapanu povodnym sposobom t.j. iba jeden segment v poziadavky,

musime viazat merane hodnoty, podmienky a ostatne data (tabulky test,

request_parameter, condition_values) okrem kluca request_id aj na kluc

structure_id.

Vysledok: Poziadavka (v tabulke request) oznacuje techniku, strukturu +

VSETKY segmenty atd,

Elementarna poziadavka (IBA JEDEN segment) je dana dvojicou

klucov request_id, structure_id, t.j. technika, struktura + konkretny

segment (wrist - axilla).

odpoved:

-------------------------------------------------------

4. Pouzivat request_group na grupovanie poziadaviek podla techniky a

struktury alebo nechat Horne a dolne koncatiny?

Dovod: Keby nepresiel bod 3 (zasah do db - treba pridat structure_id do

spominanych tabuliek), tak je tu moznost zgrupovat rovnake elementarne

poziadavky, t.j. dosiahlo by sa to ze by som mohol Zolovi pri zobrazovani

tabulky k poziadavke poslat group_id a on by mohol k tomu zobrazit

zadavacie editboxy pre celu poziadavku teda techniku, strukturu a VSETKY

segmenty (rozhadzane po jednotlivych el. poziadavkach).

odpoved:

-------------------------------------------------------

prosim o vyjadrenie od vsetkych - miso potrebuje db co najskor (a asi aj

ostatni...)

prajem pekny weekend.

____________________________________

P. S. V. P. U.

http://www.pobox.sk/

--------------------------------------------------------------------------------------

M.Bielikova:

Dobry den,

tesim s vasej bohatej komunikacii. Ja som sa bohuzial dnes

az teraz dostala k mailu a tiez sa necitim uplne kompetentna

sa vyjadrovat k modelu udajov, kedze ho nemam pred sebou

a navyse nemam v hlave vsetky podrobnosti ako vy

(stiahla som si najnovsiu verziu v Accesse z vasej stranky,

ale tam toho vela nevidim...).

Napriek tomu sa pokusim k niektorym vyjadrit.

Zdravi

M.B.

PS: inak tato vasa podnetna diskusia (mozno aj nejake predchadzajuce)

by sa mala objavit v dokumentacii (napr. k zapisu z nasledujuceho stretnutia).

Ide totiz o to, ze tu je najlepsie zdokumentovany proces rozhodovania,

alternativy a jednotlive pohlady, ktore neskuor muozu byt velmi cenne

(pre vas, ci pre niekoho dalsieho). To ale neznamena, ze teraz treba

"vypisovat formalne maily".

>

> 1. Treba zadavat parametre pri merani do tabulky alebo to nechame tak ako

> to je?

>

> dovod: Ak chceme na zadavanie tabulku, treba robit zmeny do spracovania v

> Asterix-e.

>

> odpoved:

Ako vyplynulo zo stretnutia s MUDr. Kucerom, myslim, ze by sme ho vedeli

naucit pracovat aj po jednotlivych stlpcoch a ze by sa s tym zmieril. V kazdom

pripade vsak treba zabezpecit, aby subor nasich elementarnych poziadaviek

bol nejako pevne logicky zviazany a nemohol sa "rozsypat" - t.j. pri usporiadavni

budu vzdy v rovnakom poradi a spolu.

To, ze sa poziadavky budu zadavat zvlast nevidim ako problem, lebo vlastne

ide iba o teplotu (vzdialenost je pre kazdy segment ruozna a ostatne veci

sa sice v databaze zduplikuju, ale zadavaju sa iba raz - pri vytvarani

poziadavky v centre, lebo sa nemenia, pohlavie a vek je dany prislusnym

clovekom).

>

> -------------------------------------------------------

>

> 2. Pridat typ struktury SEGMENT (napr. typ 'S') do tabulky structure

> (skutocne do tabulky structure_title) a aj do prislusnych dalsich?

>

> dovod: aby sme odlisili segmenty (elbow - axilla, axilla - erb's point

> atd) od ostatnych (recodring, stimulation strucure). Treba to pri

> vytvarani tabulky podla bodu 1, ale je to lepsie odlisit aj preto, lebo je

> to skutocne nieco ine (teraz to ma vsetko typ 'A' - Access point).

>

> odpoved:

vyzera to rozumne, vsetky zmeny vsak odporucam dobre zvazit, lebo

tim 2 uz ma v dost pokrocilom stave implementovanu cast zadavania

poziadaviek, najme co najskuor im to povedat a zduovodnit

> -------------------------------------------------------

>

> 3. Naviazat tabulky request_parameter, test a condition_value na

> request_structure (pridat stlpec Structure_ID)?

>

> dovod: Chceme mat elementarnu poziadavku rovnu celej tabulke z

> excelovskeho suboru Dr. Kuceru, t.j. el. poziadavka = technika, struktura

> + vsetky segmenty (access pointy) + recoding, stimulation site.

>

> Na to, aby sa merane testy a podmienky stale vztahovaly na elementarnu

> poziadavku chapanu povodnym sposobom t.j. iba jeden segment v poziadavky,

> musime viazat merane hodnoty, podmienky a ostatne data (tabulky test,

> request_parameter, condition_values) okrem kluca request_id aj na kluc

> structure_id.

> Vysledok: Poziadavka (v tabulke request) oznacuje techniku, strukturu +

> VSETKY segmenty atd,

> Elementarna poziadavka (IBA JEDEN segment) je dana dvojicou

> klucov request_id, structure_id, t.j. technika, struktura + konkretny

> segment (wrist - axilla).

>

> odpoved:

konzultovat s timom 2!!! (Andrej a Ondrej)

> -------------------------------------------------------

>

> 4. Pouzivat request_group na grupovanie poziadaviek podla techniky a

> struktury alebo nechat Horne a dolne koncatiny?

>

> Dovod: Keby nepresiel bod 3 (zasah do db - treba pridat structure_id do

> spominanych tabuliek), tak je tu moznost zgrupovat rovnake elementarne

> poziadavky, t.j. dosiahlo by sa to ze by som mohol Zolovi pri zobrazovani

> tabulky k poziadavke poslat group_id a on by mohol k tomu zobrazit

> zadavacie editboxy pre celu poziadavku teda techniku, strukturu a VSETKY

> segmenty (rozhadzane po jednotlivych el. poziadavkach).

>

> odpoved:

zavisi od predchadzajucej

> -------------------------------------------------------

> prosim o vyjadrenie od vsetkych - miso potrebuje db co najskor (a asi aj

> ostatni...)

>

> prajem pekny weekend.

>

--------------------------------------------------------------------------

Miso:

Poslal som ten dotaznik aj Ondrejovi Kollarikovi a (hodne) intenzivne som ho s nim konzultoval, takze sa mozeme tesit, ze dojdeme k spolocnemu rieseniu (alebo sa nikdi nedohodneme - dufam, ze nie).

Ja som to uz citaj a aj som volal s Ondrejom, aby som si ujasnil niektore veci. V podstate s nim suhlasim, obidvaja chceme pridat do tabulky request_parameter atribut structure_id, avsak on presadzuje alternativu:

----- srtucture_id nebude sucast kluca, bude moct nadobudat hodnotu null a to v pripade, ked nebudu v poziadavke ziadne segmenty t.j. vsetky parametre budu viazane len na poziadavku. Na to vsak potrebuje pridat do tabulky aj jedinecny primarny kluc (aby mu to zniesli dve rovnake requesty a parametre - doterajsie kluce).

----- Ja som viacej za alternativu, ze structure_id v tabulke request_parameter bude sucastou kluca - vznikne trojkluc request_id, structure_id, parameter_id. To vsak sposobi, ze structure_id nebude moct byt null, a preto ho navrhujem viazat v pripade poziadaviek bez segmentov na hlavnu strukturu t.j. nerve.

Vsetko asi aj tak rozhodne Andrej, ktory sa k tomu vsak stavia trochu nezainteresovane, hoci Ondrej to s nim musi bezpodmienecne zkonzultovat.

Miso

PS: Na tento mail mi neodpovedajte, adresu Durdina@seznam.sk pouzivam len docasne (cez vikend nejde pobox.sk)

OK. Tu je Ondrejov povodny mail:

----- Original Message -----

From: Kiri

To: Szabolcs Molnar ; Maria Smolarova ; Andrej Netri ; Peter Fasung ; Michal Durdina

Sent: Friday, April 20, 2001 9:45 PM

Subject: Predbezne poziadavky/navrhy

Ja navrhujem (vychadzajuc z povodnej myslienky kolegu Misa):

{Predbezna verzia, zatial neodsuhlasena Andrejom, zato vsak, podla mojho skromneho nazoru, celkom zujimava.}

0. Na zadavanie pouzit 2D grid, tak ako to Kucera chcel.

1. Zrusit asociaciu medzi condition_value a request a nahradit ju 1:n medzi request_parameter a condition_value.

Teraz moze existovat napr. niekolko condition_values bez zodpovedajuceho request_parametra. Tak, ako to navrhujem, by to malo byt spravnejsie.

2. Do request_parameter pridat structure_id.

Pridat ho nie ako sucast PK, ale ako not required + sucasny dvojdielny PK nahradit autoinkrementom. Toto umozni zadavat constrainty tak pre jednotlive stlpce, ako aj pre cely request (keby structure_id nebol nastaveny). Tiez ostane zachovana existujuca moznost

Podobne, ako constrainty, aj parametre by tymto sposobom mohli fungovat tak pre jednotlive stlpce, ako aj pre cely request. Toto momentalne asi nevyuzijeme, ale povazujem za dost realne, ze sa Kucera zas raz lepsie vyspi a napadne ho aj takato poziadavka.

3. Do test pridat structure_id.

Az by sme chceli vyuzit tie per-request parametre, tak by toto malo byt tiez nepovinne.

4. Doplnit typ struktury 'S' (Segment) = 2-jica accptov + zvacsit structure::name - 40 znakov by nemuselo stacit.

Vyberat dvojice accptov a vytvarat z nich segmenty sa mi zda byt zbytocne. Je zrejme, ze dvojic accptov bude zhruba tolko, co accptov samych (komu to nie je jasne, nech si hodi slofika). Preto by sme mali tieto dvojice priamo zapisat ako struktury - typ S - do databazy. Takto nebudeme pouzivatela nutit robit vyber 2x z n prvkov, pricom nebude prichadzat do uvahy n^2 moznosti, ale len vyber z n (zmysluplnych) moznosti.

Taktiez odpada potreba viest odkazy pre dvojicu accptov, zgrupovat ich v ramci tejto dvojice, alebo riesit situacie, ked pouzivatel zada jeden a druhy nie.

6. Do structure_title pridat jediny zaznam typu S(egment) s bezvyznamnym obsahom atributu title.

Nasledne pre kazdu techniku, pre kt. ma vyznam uvazovat o segmentoch pridat zodpovedajuci pocet (resp. radsej viac, ako menej) tech_struct_titles. Druhemu az poslednemu nastavit required = Fasle.

Nazov title je irelevantny, lebo v editore requestov, tak ako aj v "starikovi s vokridlenou cepici" sa bude zobrazovat ako zahlavie stlpca nazov asociovanej struktury a nie nazov title.

5. Na vyjadrenie poradia stlpcov so segmentami pouzit tech_struct_title::order_code.

Ked su stlpce so segmentami kodovane pomocou titles a pouzivatel si moze zvolit ktore segmety priradi ktorym titles (do ktorych stlpcov), prostrednictvom coho ma plnu kontrolu nad poradim stlpcov, nevidim najmensi dovod spekulovat nad akymkolvek inym mechanizmom zabezpecenia poradia stlpcov.

7. Zachovat povodnu semantiku request_group.

Tymto sme vsetko vyriesili na urovni requestu; niet dovodu cokolvek menit na requestoch.

structure_id v bode 2 a 3 bude zrejme obsahovat id segmentu. Nepovinne by malo byt aj preto, lebo nie kazda technika umoznuje zadat nejaky segment...

Sumarizacia:

Co vsetko treba zmenit v DB:

a) Zrusit asociaciu medzi condition_value a request a nahradit ju 1:n medzi request_parameter a condition_value. (Toto nie je "uprava", to je "oprava".)

b) Do request_parameter pridat structure_id ako not required, sucasny dvojdielny PK nahradit autoinkrementom.

c) Do test pridat structure_id ako not required.

Co treba zeditovat:

a) Doplnit typ struktury 'S' (Segment) = 2-jica accptov + zvacsit structure::name - 40 znakov by nemuselo stacit. + Opisat pat segmentov do structure (podla kucerovie xls).

b) Do structure_title pridat jeden zaznam typu S.

c) Podla potreby pridat niekolko odkazov na structure_title typu S do tech_struct_title.

Co ziskame:

a) Request s viacerymi, plne editovatelnymi stlpcami (segmentmi). Alternativne to moze fungovat aj tak ako to bolo doteraz - nie pre kazdu techniku existuju segmenty.

b) Pre kazdy stlpec-segment mozeme nezavisle zadavat parametre, conditions a ktore su required.

c) Mozeme mat aj (popri b)) conditions a parametre pre cely request (ako to bolo dosial). Cize sex = Female nebudeme zrejme zadavat pre kazdy stlpec zvlast, ale to, ze pri niektorom segmente sa ma pouzit zeleny gel, ano.

d) Ostali nam nedotknute univerzalne pouzitelne request-grupy.

Co by este mohlo fungovat a nefunguje:

a) Mnozina metodik je iba jedna pre cely request, nemozno specifikovat dodatocne metodiky pre jednotlive stlpce. Toto, myslim, nepredstavuje vaznejsi problem.

Zaver:

Takto navrhnuty system zachovava vsetky moznosti existujuceho riesenia a rozsiruje ich o plne konfigurovatelnu podporu viacerych stlpcov-segmentov na request.

Ondrej