Talk:Opasnet base structure: Difference between revisions

From Opasnet
Jump to navigation Jump to search
No edit summary
 
(17 intermediate revisions by 2 users not shown)
Line 3: Line 3:
The following four discussions will replace the previous discussion ''Opasnet base should be restructured'' (below). This is because that discussion has several topics in one, but they can and should be dealt with separately.
The following four discussions will replace the previous discussion ''Opasnet base should be restructured'' (below). This is because that discussion has several topics in one, but they can and should be dealt with separately.


{{todo|Kuka tiivistäisi aiemman argumentaation? Ei tosin erityistä kiirettä.|Juha Villman, Teemu Rintala, Einari Happonen|project=Opasnet}}
===Kysymys Opasnet-kannan rakenteesta tiivistetysti===
 
Olemme siirtymässä siihen, että teemme ympäristöterveyden vaikutusarviointeja online nettityökaluilla siten, että kuka tahansa voi ajaa arviointimalleja hankkimalla käyttäjätunnuksen (esim. [[Assessment of the health impacts of H1N1 vaccination]]) Arviointeihin tarvitsemme lähtötietoja varten tietokannan, jonka pitää pystyä tallentamaan suuren määrän kaksiulotteisia datatauluja, joiden koko ja sisältö voi olla mitä tahansa. Nykyiset datat ovat kooltaan 1 kB - 100 MB (sarakkeita 2 - 200), ja suurin osa on pienestä päästä. Miten tällainen tietokanta tehdään?
 
Nykyinen rakenne on erittäin joustava ja on toiminut hyvin, mutta kun tietokannan koko alkaa nyt olla satoja miljoonia rivejä, on erityisesti isojen datojen leikkaaminen kannasta muuttunut hitaaksi. Toinen ongelma on se, että tietokannan indeksit alkavat paisua suuremmaksi kuin itse data. Käytämme MySQL:ää. Kannan rakenne on kuvattu täällä: [[Opasnet base structure]].
 
Niinpä olemme yrittäneet keksiä parempaa rakennetta erityisesti päästäksemme eroon loccell-taulusta, joka linkkaa datan ja sen kuvaukset toisiinsa ja paisuu paljon nopeammin kuin pelkäsimme.
 
# Tämänhetkinen ehdotus (josta on keskustelua http://en.opasnet.org/w/Talk:Opasnet_base_structure ) on se, että kaikki datataulut laitetaan yhteen hervottoman isoon tauluun, jossa on riittävästi sarakkeita leveällekin datataululle. Siis datan sarakkeet tulevat taulun sarakkeiksi ja loput taulun sarakkeet jäisivät tyhjiksi, ja jokaista datan riviä kohti tulisi yksi rivi tauluun. Metatiedot eli mitä mikäkin sarake tietyssä datassa tarkoittaa tulisi sitten toiseen tauluun. Lukuisia taulun sarakkeita pitäisi indeksoida, jotta haut olisivat nopeita.
# Kilpaileva ehdotus on, että jokainen data laitettaisiin omaan tietokantatauluunsa, jonka koko määräytyy datan koosta. Tällöin ei jää tyhjiä ruutuja eivätkä taulu tai sen indeksit koskaan paisu kovin isoksi, jolloin sen leikkaaminen on aina tehokasta. Ongelmana taas on, että käyttäjä tarvitsee admin-oikeudet luodakseen uuden taulun, ja sitä emme peruskäyttäjälle halua antaa. Toisaalta sadantuhannen erillisen taulun järjestelmä ei kuulosta minusta enää tietokannalta.
# Näistä kahdesta perusversiosta on sitten erilaisia viritelmiä, kuten
:: a) Kuten 1 mutta sarakkeita on kohtuullisen pieni määrä, esim. 30, ja jos data on leveämpi, yksi datarivi sijoitetaan useammalle riville tietokantatauluun.
:: b) Yhdistelmä 1:stä ja 2:sta siten että pienet data sijoitetaan kuten 1 ja isoille datoille luodaan omat taulut kuten 2.
:: c) Kuten 1 mutta taulun kokoa rajoitetaan siten, että kun se alkaa olla kokonsa takia hidas leikattava, perustetaan seuraaville datoille uusi, samanrakenteinen taulu. Tämä vaihtoehto on sikäli houkutteleva, että tulevaisuudessa toivon muidenkin tutkimuslaitosten liittyvän tähän työskentelytapaan. Silloin tietokannan ylläpitoa voisi hajauttaa siten, että eri laitokset ylläpitäisivät omia osiaan tietokannasta, mutta käyttäjälle se näyttäytyisi yhtenä.
 
Teillä varmaan on hyvä käsitys tietokantojen eri toiminnallisuuksien kustannuksista tilan ja nopeuden suhteen. Voitteko kommentoida näitä ehdotuksiamme? Projekti on avoin, joten kysymyksiäni saa vapaasti levittää tuntemillenne osaajille.
 
===Suggested structure for index/observation description===
 
Each act should contain index description (e.g. field act.indesc) to describe how each column should be interpreted and shown. Let's start from a 2D table with m index columns and n observation columns. The index for observation column is Index4.
 
Index1 Index2 Indexm Obser1 Obsern
Data11 Data12 Data13 Data14 Data15
Data21 Data22 Data23 Data24 Data25
 
This can be unambiguously described with this kind of string:
 
index="Index1,(Index2),Indexm,Index4" obs="Obser1,(Obsern)"
 
where the parentheses mean that the content of that column is hidden by default in the displayed table, and it will be shown with the "Show all" button. The parentheses will not affect how the data is stored in the database.
 
In an Excel or CSV file, this information is optionally given on the first row, and the titles are then on the second row. The user interface will ask: {{comment|# |This format may be problematic in CSV files because it contains " characters.|--[[User:Jouni|Jouni]] 09:27, 24 August 2011 (EEST)}}
 
The table must have a heading row in the beginning.
[Check box] The first row contains the column settings, and the table starts from the second row.
 
If the check box is not checked, the following question will be asked:
 
Give the column settings: [text box] [link to What's this?]
The default is ''index="Observations" obs="Col1,Col2,Col3,Col4,Col5,(Col6),...,(Coln)"''
 
Note that this syntax also makes it possible to show the data in very different formats, such as
 
index="Index2,(Index1),(Index4),Indexm" obs="Data23,Data13"
 
Therefore, it should be possible for the user to give a column setting string when downloading the data.


===Description of the problem with data slicing===
===Description of the problem with data slicing===
Line 10: Line 55:


===Discussion about solutions===
===Discussion about solutions===
{{discussion
|Statements= A new table (dat), which will include all the information in cell, res and loccell, is created.
|Resolution= Accepted.
|Resolved =
|Argumentation =
Tauluun tulee sarakkeet  id, ind1, ind2 ... ind256, mean, sd, result, result.text.
<nowiki>#SIP</nowiki> kuvaa jakaumia ja se tallennetaan result.text kenttään.
SIP:n lisäksi voidaan kehitellä muita funktioita, esim. #QUANTILE(), #PARAM() jne. joita tulkitaan pääasiassa vasta mallintaessa; Datan näyttämistä käyttäjää varten mean ja sd ovat riittävän hyviä jos result on jakauma (SIP tai muu).
Oletusarvona uploadattaessa havaintodataa, kaikki sarakkeet ovat "Havainto" -indeksin alla, jonka lisäksi laitetaan myös "Row" sarake, joka kertoo rivinumeron.
{{comment|# |Jos halutaan continuous indices -toiminnallisuus mukaan kertaheitolla, niin tarvitaan jotain vielä vähän extremempää. Continuous indices tarkoittaa että indekseillä voi olla reaalilukuarvo, jonka perusteella dataa leikataan (esim. pituus- ja leveyspiirit). Jotta se toimisi nopeasti tarvittaisiin lisää reaaliluku sarakkeita Result:n lisäksi. Josta seuraa kysymys, että miksi vain näillä indekseillä olisi omat sarakkeet, ehkäpä halutaankin leikata tehokkaasti myös eri havaintojen perusteella. Näin jatkamalla seuraa että tarvitaan taulu jossa on iso määrä vapaasti määriteltäviä kokonaisluku(loc_id)-, reaaliluku(Result)- ja teksti(Result.Text)sarakkeita. Sarakkeiden merkitykset määriteltäisiin act kohtaisesti act.ind:ssä tai vastaavassa.|--[[User:Teemu R|Teemu R]] 16:00, 19 August 2011 (EEST)}}
{{attack|# |Rupesin epäilemään että tällä rakenteella tulee tietokannan indeksoinnin kanssa ongelmia. Jos hurjan monen sarakkeen arvot indeksoidaan, niin eikö siitä tule aivan törkeän iso tietokanta-indeksi? Tässä saattaa olla uusi argumentti useiden taulujen puolesta; ne voi optimoida erikseen. |--[[User:Teemu R|Teemu R]] 16:15, 19 August 2011 (EEST)}}
}}


{{discussion
{{discussion
Line 49: Line 109:
|Argumentation =
|Argumentation =
{{defend|# |Some of the same as above (slicing, intelligent arrays, less joins for most tables).|--[[User:Teemu R|Teemu R]] 16:05, 28 March 2011 (EEST)}}
{{defend|# |Some of the same as above (slicing, intelligent arrays, less joins for most tables).|--[[User:Teemu R|Teemu R]] 16:05, 28 March 2011 (EEST)}}
{{defend|# |If n is large enough to hold all of the indices that are going to be sliced, the rest of the indices can be put into loccell where slicing is costly, but never done.|--[[User:Teemu R|Teemu R]] 16:12, 28 March 2011 (EEST)}}
:{{attack|# |But sometime at some point there just might be a situation where more than ''n'' sliceable indices would be required...|--[[User:Teemu R|Teemu R]] 16:12, 28 March 2011 (EEST)}}


{{comment|# |This could also be achieved by a locations_string column in the cell table, where its value would be of the form 'Age:1;Sex:Male' or ind_id1:loc_id1;ind_id2:loc_id2 or similar. Then use [http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html MySQL pattern match functionalities] for filtering: i.e. "... AND(/OR) locstring LIKE '%;ind_id:loc_id;%' AND(/OR) ...". Intelligent array operations would become impossible however. |--[[User:Teemu R|Teemu R]] 16:05, 28 March 2011 (EEST)}}
{{comment|# |This could also be achieved by a locations_string column in the cell table, where its value would be of the form 'Age:1;Sex:Male' or ind_id1:loc_id1;ind_id2:loc_id2 or similar. Then use [http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html MySQL pattern match functionalities] for filtering: i.e. "... AND(/OR) locstring LIKE '%;ind_id:loc_id;%' AND(/OR) ...". Intelligent array operations would become impossible however. |--[[User:Teemu R|Teemu R]] 16:05, 28 March 2011 (EEST)}}
}}
}}


== Continuous indices ==
Currently, having indices with real values is problematic as each value would have its own location. Slicing data so as to select a range of values from a continous index would be very useful.


==Opasnet base should be restructured==
{{attack|# |All of the current propositions suffer from the original large data slicing problems due to the need to find cell_id:s which fulfil the criteria (instead of directly filtering rows from the whole object).|--[[User:Teemu R|Teemu R]] 14:16, 22 August 2011 (EEST)}}


{{discussion
{{discussion
|Statements= Opasnet Base should be restructured.
|Statements= Put the continuous indices as results under the index Observation and location Continuous Index X. Then build tools for slicing data by result value.  
|Resolution=  
|Resolution=  
|Resolved =
|Argumentation =
|Argumentation =
{{defend_invalid|1 |Nykyisen rakenteen suorituskyvyn rajat alkaa tosissaan tuntua. Isoilla datoilla latailu on hidasta vaikka kuinka sitä leikkaisi. Vajaa puoli tuntia meni ladata 11 000 riviä 44 000 000 rivin datasta (Op_en2778) R downloadilla, opasnetin käyttöliittymä crashaa ennen kuin mitään pääsee näkemäänkään, joka johtunee rivien laskemisesta, mikä kesti 95s MySQL Query Browserissa.
{{defend|# |Would not require much change to the database structure.|--[[User:Teemu R|Teemu R]] 09:38, 12 May 2011 (EEST)}}


Ladattavan datan leikkaaminen lokaatioiden perusteella on nykyrakenteen kriittisin heikko kohta. Se on pakko hoitaa erillisellä queryllä, joka tunnistaa haluttuun dataan kuuluvat ja/tai kuulumattomat solut.
{{attack|# |Might require a tedious query.|--[[User:Teemu R|Teemu R]] 09:38, 12 May 2011 (EEST)}}


Toinen hieman pienempi ongelma on joinien suurehko määrä. En teknisistä yksityiskohdista mitään tiedä, mutta jos oletetaan että yhdessä joinissa tulee ekasta taulukosta poimittujen kriteerien määrä + tokan taulukon osumien määrä ylimääräisiä operaatioita verrattuna ideaalitapaukseen jossa data on valmiina sopivassa muodossa eikä näitä operaatioita tarvita. Joineja nykyrakenteella tulee ainakin 7 yhtä latausta kohden (obj -> actobj -> act l-> cell -> res l-> loccell -> loc -> obj); alkupään joinit ovat kuitenkin hyvin nopeita eli ei niillä väliä, mutta laskeskelin että ylimääräisiä operaatioita tulisi yhteensä noin 5 + ncell * (2 + nres + 5nloc/nind). Tämän kuvittelisin olevan mahdollinen pullonkaula datanlatauksen nopeudessa: Windowsin tehtävienhallinnasta network activity graphia katsomalla olen pannut merkille eri maksimilatausnopeudet isoilla ja hyvin isoilla datoilla.
{{attack|# |Some faulty thinking... Implementation would require a running ID achieved by using a new index or similar. It'd be probably better to adjust the database structure. |--[[User:Teemu R|Teemu R]] 10:21, 12 May 2011 (EEST)}}


Vaihtoehtoisesti kannan voisi järjestellä niin että kutakin objektia kohti tulisi oma taulukko kantaan; Muutettaisiin nykyiset virtuaaliset taulukot oikeiksi taulukoiksi. Taulut olisivat jo valmiiksi samassa muodossa kuin nykyinen lopputulos:
{{defend|# |If the Observation index location links were placed in the res table instead of loccell, a cell could have multiple results, which would be interpreted as different measurements (not obs as in iteration number) in the same index locations and a unique iteration number.|--[[User:Teemu R|Teemu R]] 14:00, 27 May 2011 (EEST)}}
}}


cell_id  (series_id)        (obs)    ind1      ind2      ind3      res/SIP
{{discussion
|Statements= Add an "Observation" column to the res table. The "Observation" -index should be a different structure from regular indices. Observations are properties unique to the individual, while regular indices are properties of a set/group. '''Continuous indices are actually observations'''.
1          (1)                    (0)       1          1          1          0
|Resolution=
|Resolved =
|Argumentation =
{{defend|# |Little change to the structure of the database.|--[[User:Teemu R|Teemu R]] 14:57, 12 July 2011 (EEST)}}


Objektien metadata, actit ja vaikka lokaatioiden tiedot voitaisiin keskittää omiin tauluihinsa, mutta nykyrakenteen raskain osa (rakenne) olisi valmiina.
{{attack|# |Requires more sophistication on the interface-side.|--[[User:Teemu R|Teemu R]] 14:57, 12 July 2011 (EEST)}}
}}


Samalla kannan käyttämisen koodi trivialisoituisi huomattavasti, niin että asiaan vihkiytymättömänkin olisi se helpompi ymmärtää ja kehittää omia sovellutuksia (itselleni tuli heti mieleen kahden taulun yhdistäminen ja tulostaminen vain tiettyjen lokaatioiden osalta databasen tasolla).
{{discussion
|Statements= Add a column with a numeric value to the loccell table.
|Resolution=
|Resolved =
|Argumentation =


Leikkaaminen olisi huomattavasti nopeampaa, kun pärjää yksinkertaisilla where lausekkeilla (WHERE obj1.ind1 (NOT) IN (...)).
}}


Joinien määrä putoaisi ja ylimääräisiä operaatioita olisi vain 5 + ncell * (1 + nloc/nind).
== SIP:s and SLURP:s ==


Tilaakin säästyisi hieman kun loccell putoaisi pois kuvioista. Sippeihin vaihtaminen pitäisi samalla toteuttaa, niin ei tulisi toistettua samoja lokaatioita joka obsille.
{{discussion
 
|Statements= The database structure need not be changed. [[SIP]]s are saved in the result.text column of the res table. These can then be interpreted separately. Some meta data might have to be added, so that the Base UI can automatically recognize the SIP.
Kääntöpuolella käyttöoikeuksien hallinta vaikeutuisi, kun uuden objektin luomiseen tarvittaisiin oikeuksia tablejen tekoon ja dramaattisemmat muutokset nykyisissä taulukoissa vaatisivat oikeuksia muuttaa taulun rakennetta.
|Resolution= Accepted.
 
|Resolved =  
Pieniä vaikeuksia tulee myös silloin kun jo olemassa olevaan objektiin ladataan aikaisempaan verrattuna eri muotoista dataa (eri indeksit): uusien indeksien lisääminen olisi triviaali toimenpide, ja poistaminen myös, jossa tapauksessa tosin vanha data tuhoutuisi. Jossakin erillisessä taulussa voisi kertoa sarjan käyttämien indeksien nimet, mutta silloin dataan jäisi turhia indeksejä lojumaan. En tosin nää mitään rajoitteita, jotka estäisivät taulukkojen massaamisen lataamalla objektit series_id kohtaisesti: nimeksi vaan concat(obj.id, series_id).
|Argumentation =
 
{{defend|# |In discussion within YMAL, everyone supports the using of SIPs.|--[[User:Jouni|Jouni]] 15:47, 20 August 2011 (EEST)}}
Dataa hallittaisiin aika samoilla periaatteilla, queryt vaan menis uusiksi ja homma yksinkertaistuis.
 
Näin tuumasin. Oliko järkeä?
|--[[User:Teemu R|Teemu R]] 12:42, 19 November 2010 (UTC)}}
 
: {{attack|2 |En innostu yhtään ajatuksesta, että kantaan pitäisi tehdä rakenteellisia muutoksia (eli lisää tauluja) muuttujien lisääntyessä. Kannan hienous on juuri siinä, että siinä on yksinkertainen mutta älyttömän joustava taulurakenne. Se että onko tämä vain fiilistelyä vai onko tässä jotain kovempaa tietoteoreettista pointtia onkin toinen juttu.|--[[User:Jouni|Jouni]] 12:42, 19 November 2010 (UTC)}}
: {{attack|3 |Vaihtoehtoisena ajatuksena esitän, että tosi isoille datoille perustetaan jokin eri kanta. Tämä ajatus on ollut ennenkin esillä, kun Kopra-datojen kohtaloa on mietitty (15 GB tavaraa). Järjestelmänhän pitäisi olla sillä tavalla joustava, että wikejä voi olla useita ja kantoja voi olla useita, ja kun nämä on esitelty toisilleen, mihin tahansa wikiin voi rakentaa muuttujan, jonka data voidaan ladata mihin tahansa näistä kannoista (suojausten puitteissa tietysti). |--[[User:Jouni|Jouni]] 12:42, 19 November 2010 (UTC)}}
: {{attack|4 |Minäkään en innostu ajatuksesta, jossa jokaisella objektilla olisi oma taulu. Parempi olla simppeli ja eheä rakenne, jota on siten helpompi hallita ja ylläpitää. Yritetään löytää ongelmiin muita ratkaisuja? Tuon UI:n osalta auttaisi paljon se, että pistettäisiin esim. ACT-tauluun uusia kenttiä, joihin on etukäteen laskettu esim. seuraavat tiedot koko datalle (actille): mean, result-rivien määrä, cell-rivien määrä. Noiden perusjuttujen selvittäminen isosta datasta on hidasta ja jos nuo lasketaan uploadin yhteydessä, niin saavutetaan jo erittäin merkittäviä hyötyjä nopeudessa. En nää uploadaamisen hitautta suurena ongelmana, jos nyt ei sentään päiviä kestä se lataaminen. Olennaista lie valmistella data kunnolla ja testata ensin pienemmällä otoksella, jotta vältytään lopulta turhalta työltä ja ajan haaskaukselta? |--[[User:ehac|Einari]] 9:36, 22 November 2010 (UTC)}}
::{{attack|# |Mielestäni ehdottamani rakenne olisi yksinkertaisempi juurikin hallinnan ja ylläpidon kannalta, kun vanhoja huonoja uploadeja ei tarvitse poistaa monipolvisilla queryillä keskeltä erinäisiä tauluja, riittäisi että dropataan yksi taulu ja korjataan uploadin tiedot toisesta; Kuvittelisin että näin jää vähemmän jälkiä kantaan ja olisi vähemmän päänsärkyä tarpeettomien rivien löytämisessä. Metadataa uploadeille olisi kyllä hyvä laittaa enemmän valmiiksi; Tosin count ainakin optimoitu niin että kokonaisista taulukoista se löytyy heti. Uploadi on kyllä ihan tarpeeksi nopeaa jo nyt, vähän aikaa sitten tuuppasin 45M solua dataa parin tunnin sisään (josta tulikin taas mieleeni että loccell on hitain taulu uploadissa, ehdottamassani rakenteessa sitä ei tarvittaisi), mutta pienen osan lataaminen samasta datasta kestikin sitten myös melkein 30 minuuttia. Jossain vaiheessa kun meillä on monta isoa aineistoa, joista kustakin tarvitaan jotain mallia varten vain pieni siivu, 30 minuuttia per osa alkaa tuntua aika paljolta jos ne joudutaan monta kertaa ajamaan läpi. Tosin on mahdollista että silloin luodaan pienempi muuttuja jossa on vain ne tiedot joita jotakin mallia varten tarvitaan, mutta eikös databasejen koko pointti ole että isosta datasta saataisiin helposti se haluttu siivu.|--[[User:Teemu R|Teemu R]] 11:29, 22 November 2010 (UTC)}}
: {{defend|5 |Hienoa ajattelua ja perehtymistä tärkeään asiaan. Ensi lukemalla en ymmärtänyt kaikkia pointteja. Olen samaa mieltä, että pitkä joinien ketju on ongelma.|--[[User:Jouni|Jouni]] 12:42, 19 November 2010 (UTC)}}
: {{defend|6 |Kannatan siirtymistä [[SIPs and SLURPs]]eihin.|--[[User:Jouni|Jouni]] 12:42, 19 November 2010 (UTC)}}
: {{defend|7 |Suurin ongelma mielestäni oli siis tuo datan leikkaamisen monimutkaisuus: Lopullinen query jolla data haetaan kannasta tuottaa taulukon jossa sarakkeet id, obs, loc, ind, res; lokaatiot ovat kaikki samassa sarakkeessa. Jos queryyn lisätään suorilta käsin ''where loc.id (not) in()'', niin rivejä poistetaan sokeasti huomoimatta sitä että oikeasti pitää jättää matchaavien solujen lokaatiot '''kaikkiin''' objektin indekseihin ehjäksi/poistaa loputkin indeksit. Tätä pitää kiertää tunnistamalla erikseen solut, joilla on jossakin indeksissä jokin lokaatio joka halutaan mukaan/pois. Ja tämä kiertotie aiheuttaa isoilla datoilla usean minuutin queryn ennen varsinaista datan lataamista.|--[[User:Teemu R|Teemu R]] 13:36, 19 November 2010 (UTC)}}
:: {{attack_invalid|# |Totta on, että leikkaaminen on nyt työlästä. Mutta en silti luovu periaatteesta, että tauluja on vähän ja taulurakenteeseen ei tarvitse koskea dataa lisätessä. Kaksi ehdotusta helpottamaan tuota leikkaamisen työläyttä:
::# Haettavassa taulussa pitää olla myös cell_id, ja jos loc_id:n perusteella jokin rivi tulee poistettavaksi/mukaan otettavaksi, tämä pätee kaikkiin riveihin, joilla on sama cell_id. Kysehän on loppujen lopuksi siitä, että haussa on tarkoitus löytää lista cell_id:tä, joihin liittyvät resultit ja locationit haetaan.
::# Olisiko teknisesti tolkullista rakentaa favorites-taulu, joka sisältäisi sellaiset actobj_id-loc_id-parit, joita on haettu aiemmin. Taulun tuottama lisäarvo olisi siinä, että siihen olisi listattu kaikki hakuehdot täyttävät cell_id:t, jolloin niitä ei tarvitse hakea loccell-taulusta lainkaan. Vain siinä tapauksessa, että kyseistä hakua ei löydy favoritesista, pitää katsoa loccell:stä.|--[[User:Jouni|Jouni]] 06:28, 25 March 2011 (EET)}}
:::{{attack|# |Olisi ehkä pitänyt tarkentaa että kyseessä oli subquery varsinaisen queryn sisällä, eli ehdotus 1 on periaatteessa käytössä. Tämä toimenpide tarvitsee ylimääräisen operaation (subqueryn), joka on riippuvainen koko datan koosta. Ehdotus 2 nopeuttaa kyllä kannan toimintaa, jos se toteutetaan niin että on fiksatut ennalta määritellyt näkymät, jotka ovat nopeita; muuten ei ole mitään lisäarvoa verrattuna nykyiseen loccell tauluun, jos niitä yritetään matchata hakuehtoihin (lokaatioihin). Ja millä perusteella nuo favoritet sitten luotaisiin? Jotenkin epämääräinen kiertotie, joka ei mielestäni ole tyydyttävä ratkaisu. |--[[User:Teemu R|Teemu R]] 14:37, 16 March 2011 (EET)}}
:{{defend|8 |<nowiki>Loccell on itse asiassa reippaasti suurikokoisin taulukko kannassa (Data length = 3.4GB; Index length = 9.2GB). Eli tällä uudella rakenteella säästyisi aika paljon tilaa...</nowiki>|--[[User:Teemu R|Teemu R]] 07:50, 22 November 2010 (UTC)}}
:{{attack|# |Uusi vaihtoehtoinen ratkaisu, joka ei vaadi röykkiöittäin tauluja ja pääasiassa ratkaisee loccellin paisumisen (mutta säilyttää joustavuuden lisätä indeksejä myös jälkikäteen jos tämä on tärkeää): cell-tauluun lisätään sarakkeet ind1, ind2,...indn (esim. <nowiki>n=8</nowiki>). Näiden sisältö on lod_id:t muuttujan indekseille 1..n ja jos indeksejä on vähemmän kuin n niin tietysti loput kentät jäävät tyhjiksi. Näin loccell-taulua ei tarvita lainkaan, paitsi kahdessa tilanteessa: 1) Jos indeksejä on yli n tai 2) jos jälkikäteen muuttujaan lisätään täsmentäviä indeksejä, koska käyttäjän ei ehkä haluta pääsevän muuttelemaan olemassaolevien rivien sisältöä cell-taulussa. Jotta kohta 2 toimisi, actobj-tauluun (tai jonnekin) pitäisi lisätä tieto, että onko tästä actobj.id:stä loccell-taulussa jotain vai ei. Haitat: SQL:stä tulee vähän monimutkaisempaa, koska pitää varautua lukemaan sekä ind1..indn-sarakkeet että loccell-taulu ja yhdistämään tulokset. Toisaalta ajettavat queryt yleensä ovat selvästi nopeampia, koska n voidaan asettaa semmoiseksi että 95 % muuttujista pärjää n indeksillä.|--[[User:Jouni|Jouni]] 06:17, 24 March 2011 (EET)}}
::{{attack|# |Ongelma painottuu nimenomaan noihin isoihin monen indeksin tauluihin, eli mikään indeksien ylärajan sisältävä ratkaisu ei oikeasti ratkaise ongelmiamme. Tulin tässä ajatelleeksi taas vaihtoehtoista systeemiä:
::*Kaikki lokaatiot ja indeksit muutetaan yhdeksi stringiksi muotoa esim. 'Age:1;Sex:Male' tai ind_id1:loc_id1;ind_id2:loc_id2. Näin loccell jää pois ja kaikki lokaatiot saadaan cell tauluun ilman indeksien määrän rajoituksia.
::*Näistä stringeistä voi sitten matchailla [http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html MySQL:n pattern match funktioilla] sopivat rivit.
::*Downsidena paljon leikkaavista queryistä tulee pitkiä kun jokainen kriteeri pitää erikseen määritellä. Kukin lokaatio joka samasta indeksistä halutaan ulos/mukaan vaatii oman "... AND(/OR) locstring LIKE '%;ind_id:loc_id;%' AND(/OR) ..." |--[[User:Teemu R|Teemu R]] 14:52, 24 March 2011 (EET)}}
{{defend|9 |Yksi olennainen johtopäätös, olkoonkin vajaasta analyysistä, on että datan latausaika ~ a*ncell<sup>b</sup>, jossa b on vähän yli 1 (koska nind on jollain tasolla riippuvainen solujen määrästä + muita tekijöitä esim. joinien ylimääräiset operaatiot); Dataa leikatessa a:ta kasvattaa ylimääräinen query (aika ~ 1*y*ncell<sup>x</sup>, eri query eri operaatiot: oletetaan x <nowiki>=</nowiki> b, y on queryjen verrannollinen tehokkuus (nopeus)) samalla kun pienempi ladattavien solujen määrä pienentää sitä (aika ~ k*ncell<sup>b</sup>, jossa k on ladattavien solujen määrä verrattuna solujen yhteismäärään). Nykyrakenne lisää siis yhden kokonaisen termin a:han, joka ei ole myöskään ihan pieni ja se riippuu suoraan datan koosta, eikä sitä voi pienentää tai välttää leikatessa. Eli iso data on hidasta, ei pelkästään ladattavasta datasta riippuen vaan myös suoraan koosta rippuen. Useamman taulun rakenne poistaisi koko termin ja samalla pienentäisi b:tä.|--[[User:Teemu R|Teemu R]] 09:12, 22 November 2010 (UTC)}}
 
{{defend|10 |Entäpä ajatus uudesta näkökulmasta: Loccell-taulu paisuu erityisesti siksi, että joka ikisessä uploadissa luodaan uudet solut ja näille uudet loccellit. Kuitenkin jos muuttuja alkaa olla vakiintunut muodoltaan, on epätodennäköistä että indeksit ja lokaatiot muuttuisivat uploadista toiseen; ainoastaan solujen sisältö vakiona pysyvässä rakenteessa päivittyy. Jos näin on, silloin kannattaisi pikemminkin rakentaa systeemi niin, että act-taulu kytkettäisiinkin res-tauluun eikä actobj:iin, ja yhdellä cell.id:llä voisi olla useita uploadattuja tuloksia (mutta act.id+res.id+res.obs olisi aina uniikki). Tästä olisi muutamia seurannaisvaikutuksia:
* Sip-kenttä pitäisi siirtää cell-taulusta res:iin.
* Cell.mean, cell.sd ja cell.n eivät enää olisi pysyviä tietoja, vaan ne laskettaisiin ja päivitettäisiin aina uusiksi kun tehdään uusi upload. Vanhoista uploadeista nämä pitäisi siis laskea raakadatasta lähtien siinä vaiheessa, kun joku niitä kysyy.
* Parasta olisi, jos vanha toiminnallisuus säilyisi (eli muuttujan rakennetta voisi muuttaa uudessa uploadissa) mutta myös olisi mahdollista käyttää uutta toiminnallisuutta eli käyttää vanhoja cell.id:tä mutta uuteen act.id:hen kytkettyjä res:ejä.
* Tätä ajatusta voi pohtia myös pitemmälle siten, että tietty indeksien ja lokaatioiden yhdistelmä voisi olla sama jopa eri muuttujilla. Tämän toteuttamiseen en kyllä käyttäisi samaa cell.id:tä vaan miettisin asiaa niinpäin, että olisi mahdollista luoda yhdistelmäindeksejä: yhdellä lokaatiolla tässä yhdistelmäindeksissä kuvattaisiin sitä, että kyseinen solu sijaitsee indeksien Ind<sub>i</sub> lokaatioissa Loc<sub>i</sub> (i {{=}} 1, 2, ...n). |--[[User:Jouni|Jouni]] 18:21, 1 December 2010 (UTC)}}
:{{attack|11 |Mahdollinen ratkaisu loccellin kokoon, mutta kannan tehokkuuden kannalta toissijainen. Datan leikkaamisen ongelma säilyy niin kauan kuin cell ja loccell taulujen tiedot pidetään eri taluissa (yhtä objektia kohti); ja joustavuudessa mahdollisesti kärsitään. |--[[User:Teemu R|Teemu R]] 13:04, 7 December 2010 (UTC)}}
}}
}}


== Should all variables go to result distribution database? ==
== Should all variables go to result distribution database? ==

Latest revision as of 06:27, 24 August 2011

New structure for Opasnet Base

The following four discussions will replace the previous discussion Opasnet base should be restructured (below). This is because that discussion has several topics in one, but they can and should be dealt with separately.

Kysymys Opasnet-kannan rakenteesta tiivistetysti

Olemme siirtymässä siihen, että teemme ympäristöterveyden vaikutusarviointeja online nettityökaluilla siten, että kuka tahansa voi ajaa arviointimalleja hankkimalla käyttäjätunnuksen (esim. Assessment of the health impacts of H1N1 vaccination) Arviointeihin tarvitsemme lähtötietoja varten tietokannan, jonka pitää pystyä tallentamaan suuren määrän kaksiulotteisia datatauluja, joiden koko ja sisältö voi olla mitä tahansa. Nykyiset datat ovat kooltaan 1 kB - 100 MB (sarakkeita 2 - 200), ja suurin osa on pienestä päästä. Miten tällainen tietokanta tehdään?

Nykyinen rakenne on erittäin joustava ja on toiminut hyvin, mutta kun tietokannan koko alkaa nyt olla satoja miljoonia rivejä, on erityisesti isojen datojen leikkaaminen kannasta muuttunut hitaaksi. Toinen ongelma on se, että tietokannan indeksit alkavat paisua suuremmaksi kuin itse data. Käytämme MySQL:ää. Kannan rakenne on kuvattu täällä: Opasnet base structure.

Niinpä olemme yrittäneet keksiä parempaa rakennetta erityisesti päästäksemme eroon loccell-taulusta, joka linkkaa datan ja sen kuvaukset toisiinsa ja paisuu paljon nopeammin kuin pelkäsimme.

  1. Tämänhetkinen ehdotus (josta on keskustelua http://en.opasnet.org/w/Talk:Opasnet_base_structure ) on se, että kaikki datataulut laitetaan yhteen hervottoman isoon tauluun, jossa on riittävästi sarakkeita leveällekin datataululle. Siis datan sarakkeet tulevat taulun sarakkeiksi ja loput taulun sarakkeet jäisivät tyhjiksi, ja jokaista datan riviä kohti tulisi yksi rivi tauluun. Metatiedot eli mitä mikäkin sarake tietyssä datassa tarkoittaa tulisi sitten toiseen tauluun. Lukuisia taulun sarakkeita pitäisi indeksoida, jotta haut olisivat nopeita.
  2. Kilpaileva ehdotus on, että jokainen data laitettaisiin omaan tietokantatauluunsa, jonka koko määräytyy datan koosta. Tällöin ei jää tyhjiä ruutuja eivätkä taulu tai sen indeksit koskaan paisu kovin isoksi, jolloin sen leikkaaminen on aina tehokasta. Ongelmana taas on, että käyttäjä tarvitsee admin-oikeudet luodakseen uuden taulun, ja sitä emme peruskäyttäjälle halua antaa. Toisaalta sadantuhannen erillisen taulun järjestelmä ei kuulosta minusta enää tietokannalta.
  3. Näistä kahdesta perusversiosta on sitten erilaisia viritelmiä, kuten
a) Kuten 1 mutta sarakkeita on kohtuullisen pieni määrä, esim. 30, ja jos data on leveämpi, yksi datarivi sijoitetaan useammalle riville tietokantatauluun.
b) Yhdistelmä 1:stä ja 2:sta siten että pienet data sijoitetaan kuten 1 ja isoille datoille luodaan omat taulut kuten 2.
c) Kuten 1 mutta taulun kokoa rajoitetaan siten, että kun se alkaa olla kokonsa takia hidas leikattava, perustetaan seuraaville datoille uusi, samanrakenteinen taulu. Tämä vaihtoehto on sikäli houkutteleva, että tulevaisuudessa toivon muidenkin tutkimuslaitosten liittyvän tähän työskentelytapaan. Silloin tietokannan ylläpitoa voisi hajauttaa siten, että eri laitokset ylläpitäisivät omia osiaan tietokannasta, mutta käyttäjälle se näyttäytyisi yhtenä.

Teillä varmaan on hyvä käsitys tietokantojen eri toiminnallisuuksien kustannuksista tilan ja nopeuden suhteen. Voitteko kommentoida näitä ehdotuksiamme? Projekti on avoin, joten kysymyksiäni saa vapaasti levittää tuntemillenne osaajille.

Suggested structure for index/observation description

Each act should contain index description (e.g. field act.indesc) to describe how each column should be interpreted and shown. Let's start from a 2D table with m index columns and n observation columns. The index for observation column is Index4. 

Index1 Index2 Indexm Obser1 Obsern
Data11 Data12 Data13 Data14 Data15
Data21 Data22 Data23 Data24 Data25

This can be unambiguously described with this kind of string: 

index="Index1,(Index2),Indexm,Index4" obs="Obser1,(Obsern)"

where the parentheses mean that the content of that column is hidden by default in the displayed table, and it will be shown with the "Show all" button. The parentheses will not affect how the data is stored in the database.

In an Excel or CSV file, this information is optionally given on the first row, and the titles are then on the second row. The user interface will ask: ----#: . This format may be problematic in CSV files because it contains " characters. --Jouni 09:27, 24 August 2011 (EEST) (type: truth; paradigms: science: comment) 

The table must have a heading row in the beginning.
[Check box] The first row contains the column settings, and the table starts from the second row.

If the check box is not checked, the following question will be asked: 

Give the column settings: [text box] [link to What's this?]
The default is index="Observations" obs="Col1,Col2,Col3,Col4,Col5,(Col6),...,(Coln)"

Note that this syntax also makes it possible to show the data in very different formats, such as 

index="Index2,(Index1),(Index4),Indexm" obs="Data23,Data13"

Therefore, it should be possible for the user to give a column setting string when downloading the data.

Description of the problem with data slicing

Add description.

Discussion about solutions

How to read discussions

Fact discussion: .
Opening statement: A new table (dat), which will include all the information in cell, res and loccell, is created.

Closing statement: Accepted.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

Tauluun tulee sarakkeet id, ind1, ind2 ... ind256, mean, sd, result, result.text. #SIP kuvaa jakaumia ja se tallennetaan result.text kenttään. SIP:n lisäksi voidaan kehitellä muita funktioita, esim. #QUANTILE(), #PARAM() jne. joita tulkitaan pääasiassa vasta mallintaessa; Datan näyttämistä käyttäjää varten mean ja sd ovat riittävän hyviä jos result on jakauma (SIP tai muu). Oletusarvona uploadattaessa havaintodataa, kaikki sarakkeet ovat "Havainto" -indeksin alla, jonka lisäksi laitetaan myös "Row" sarake, joka kertoo rivinumeron.

----#: . Jos halutaan continuous indices -toiminnallisuus mukaan kertaheitolla, niin tarvitaan jotain vielä vähän extremempää. Continuous indices tarkoittaa että indekseillä voi olla reaalilukuarvo, jonka perusteella dataa leikataan (esim. pituus- ja leveyspiirit). Jotta se toimisi nopeasti tarvittaisiin lisää reaaliluku sarakkeita Result:n lisäksi. Josta seuraa kysymys, että miksi vain näillä indekseillä olisi omat sarakkeet, ehkäpä halutaankin leikata tehokkaasti myös eri havaintojen perusteella. Näin jatkamalla seuraa että tarvitaan taulu jossa on iso määrä vapaasti määriteltäviä kokonaisluku(loc_id)-, reaaliluku(Result)- ja teksti(Result.Text)sarakkeita. Sarakkeiden merkitykset määriteltäisiin act kohtaisesti act.ind:ssä tai vastaavassa. --Teemu R 16:00, 19 August 2011 (EEST) (type: truth; paradigms: science: comment)

⇤--#: . Rupesin epäilemään että tällä rakenteella tulee tietokannan indeksoinnin kanssa ongelmia. Jos hurjan monen sarakkeen arvot indeksoidaan, niin eikö siitä tule aivan törkeän iso tietokanta-indeksi? Tässä saattaa olla uusi argumentti useiden taulujen puolesta; ne voi optimoida erikseen. --Teemu R 16:15, 19 August 2011 (EEST) (type: truth; paradigms: science: attack)

How to read discussions

Fact discussion: .
Opening statement: Opasnet Base needs more efficient solutions for slicing data, especially for the loccell table.

Closing statement: Accepted.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:
←--#: . Everyone agrees on this. --Jouni 06:28, 25 March 2011 (EET) (type: truth; paradigms: science: defence)

How to read discussions

Fact discussion: .
Opening statement: The loccell table should be kept in Opasnet Base.

Closing statement: Accepted

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--#: . Loccell makes the database flexible enough for any kind of data. --Jouni 06:28, 25 March 2011 (EET) (type: truth; paradigms: science: defence)

⇤--#: . Large objects' performance will suffer if indices, whose locations are often filtered, are implemented in loccell. --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: attack)

How to read discussions

Fact discussion: .
Opening statement: X % of the largest variables should be indexed with separate tables instead of with loccell, because the slicing of data is so slow. A good value for X is a part of this discussion.

Closing statement: Under discussion (to be changed when a conclusion is found)

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--#: . Slicing wouldn't require a tedious subquery. --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: defence)

←--#: . Enables fast and easy intelligent array operation on the database level. (It is possible with the current structure also, but it requires extremely heavy subquerying and is very memory intensive for the server.) --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: defence)

←--#: . Reduces number of joins used in data fetching queries -> faster. --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: defence)

----#: . I still support 100 as the value of X. I would trade simplicity for functionality and efficiency any day... though in my opinion the current structure is actually more complex than what I'm proposing (think about the difficulty of explaining it to an outsider; if all objects had their own table it would be a lot more intuitive). --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: comment)

----#: . If separate tables are created, they should be specific to actobj. They should be named as actobj_id or alternatively (if humans need to operate manually with tables) as obj_identifier+act.id. If found useful, tables could be located in folders named as obj_identifier. --Jouni 06:28, 25 March 2011 (EET) (type: truth; paradigms: science: comment)

How to read discussions

Fact discussion: .
Opening statement: Cell table should be reorganised and fields called ind1, ind2,...indn should be added. These are used for loc_id for the first n indices.

Closing statement: Under discussion (to be changed when a conclusion is found)

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--#: . Some of the same as above (slicing, intelligent arrays, less joins for most tables). --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: defence)

←--#: . If n is large enough to hold all of the indices that are going to be sliced, the rest of the indices can be put into loccell where slicing is costly, but never done. --Teemu R 16:12, 28 March 2011 (EEST) (type: truth; paradigms: science: defence)

⇤--#: . But sometime at some point there just might be a situation where more than n sliceable indices would be required... --Teemu R 16:12, 28 March 2011 (EEST) (type: truth; paradigms: science: attack)
----#: . This could also be achieved by a locations_string column in the cell table, where its value would be of the form 'Age:1;Sex:Male' or ind_id1:loc_id1;ind_id2:loc_id2 or similar. Then use MySQL pattern match functionalities for filtering: i.e. "... AND(/OR) locstring LIKE '%;ind_id:loc_id;%' AND(/OR) ...". Intelligent array operations would become impossible however. --Teemu R 16:05, 28 March 2011 (EEST) (type: truth; paradigms: science: comment)

Continuous indices

Currently, having indices with real values is problematic as each value would have its own location. Slicing data so as to select a range of values from a continous index would be very useful.

⇤--#: . All of the current propositions suffer from the original large data slicing problems due to the need to find cell_id:s which fulfil the criteria (instead of directly filtering rows from the whole object). --Teemu R 14:16, 22 August 2011 (EEST) (type: truth; paradigms: science: attack)

How to read discussions

Fact discussion: .
Opening statement: Put the continuous indices as results under the index Observation and location Continuous Index X. Then build tools for slicing data by result value.

Closing statement: Resolution not yet found.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--#: . Would not require much change to the database structure. --Teemu R 09:38, 12 May 2011 (EEST) (type: truth; paradigms: science: defence)

⇤--#: . Might require a tedious query. --Teemu R 09:38, 12 May 2011 (EEST) (type: truth; paradigms: science: attack)

⇤--#: . Some faulty thinking... Implementation would require a running ID achieved by using a new index or similar. It'd be probably better to adjust the database structure. --Teemu R 10:21, 12 May 2011 (EEST) (type: truth; paradigms: science: attack)

←--#: . If the Observation index location links were placed in the res table instead of loccell, a cell could have multiple results, which would be interpreted as different measurements (not obs as in iteration number) in the same index locations and a unique iteration number. --Teemu R 14:00, 27 May 2011 (EEST) (type: truth; paradigms: science: defence)

How to read discussions

Fact discussion: .
Opening statement: Add an "Observation" column to the res table. The "Observation" -index should be a different structure from regular indices. Observations are properties unique to the individual, while regular indices are properties of a set/group. Continuous indices are actually observations.

Closing statement: Resolution not yet found.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--#: . Little change to the structure of the database. --Teemu R 14:57, 12 July 2011 (EEST) (type: truth; paradigms: science: defence)

⇤--#: . Requires more sophistication on the interface-side. --Teemu R 14:57, 12 July 2011 (EEST) (type: truth; paradigms: science: attack)

How to read discussions

Fact discussion: .
Opening statement: Add a column with a numeric value to the loccell table.

Closing statement: Resolution not yet found.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

SIP:s and SLURP:s

How to read discussions

Fact discussion: .
Opening statement: The database structure need not be changed. SIPs are saved in the result.text column of the res table. These can then be interpreted separately. Some meta data might have to be added, so that the Base UI can automatically recognize the SIP.

Closing statement: Accepted.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:
←--#: . In discussion within YMAL, everyone supports the using of SIPs. --Jouni 15:47, 20 August 2011 (EEST) (type: truth; paradigms: science: defence)

Should all variables go to result distribution database?

How to read discussions

Fact discussion: .
Opening statement: Not all variables should go to the result distribution database

Closing statement: Not accepted.

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--1P: . There should be two levels of variables: 1) The results of important variables are uploaded in the result database, and they should be coherent with each other. 2) Other variables that are less important are used in case-specific assessments. They don't need to be coherent with all variables in the result database, only with those within the same assessment. --Jouni 23:52, 20 August 2007 (EEST) (type: truth; paradigms: science: defence)

----2P: . How do you define an important variable? I see variable importance as a varying aspect, not absolute and often case-specific. --Anna Karjalainen 14:17, 7 May 2008 (EEST) (type: truth; paradigms: science: comment)
⇤--3: . There is no separation to important and less important variables. There are only variables, and they are described in Opasnet. All these also go to the Opasnet Base. Some variables are in an early developmental stage and there is nothing to put to the Base yet, but this does not change the principle. However, there are also intermediate nodes in models that are not described as variables. They do not go into the Base. --Jouni 08:22, 21 February 2009 (EET) (type: truth; paradigms: science: attack)

Indeksien standardointi

Nykyään kantaan voi ladata mitä indeksejä tahansa. Jos samanniminen indeksi jo on, lokaatiot lisätään siihen. Jos samanniminen lokaatio jo on, käytetään sitä. Mutta jos on jo sisällöllisesti sama mutta nimeltään eri indeksi tai lokaatio, tätä ei tunnisteta millään tavalla. Tämä on iso ongelma, koska se estää tehokkaan muuttujien linkkaamisen toisiinsa samojen lokaatioiden osalta.

Ratkaisu: luodaan standardi-indeksien ja -lokaatioiden järjestelmä. Näitä käytetään aina kun mahdollista. Tarvitaan ylläpitäjä, joka seuraa uusia indeksejä ja tunnistaa, jos ne ovat sisällöltään samoja kuin jokin entinen. Kun tämmöinen löytyy, jokin indekseistä nimetään standardiksi (tai tarvittaessa luodaan uusi). Muut indeksit linkataan tähän, ja tulosteessa käytetään standardi-indeksin arvoja, ei alkuperäisiä.

Teknisesti tämä toteutetaan siten, että tarvitaan uusi taulu. Siinä on lista lokaatioita, ja kullekin lokaatiolle kerrotaan standardilokaatio. Tämä määrittelee samalla käytettävän indeksi yksiselitteisesti. Lista on uniikki lokaation suhteen mutta ei standardilokaation suhteen. Itse asiassa tästähän seuraa, ettei tarvita uutta taulua, vaan Loc-tauluun tarvitaan vain uusi kenttä standardilokaatiolle, mikä on paljon miellyttävämpi ratkaisu. Sen sijaan että käytettäisiin alkuperäistä Loc.id:tä, käytetäänkin Loc.Std_id ehdolla

<anacode> SELECT Rawloc.id, Loc.Obj_id_i, Loc.Location, Loc.Roww, Loc.Description FROM Loc AS Rawloc, Loc WHERE Rawloc.Std_id = Loc.id </anacode>

----1: . Tämä muutos on jo Opasnet-kantaan tehty. --Jouni 16:01, 22 May 2009 (EEST) (type: truth; paradigms: science: comment)

Tämä toimii joss kaikilla lokaatioilla on standardilokaatio. Tämä onnistuu, jos kaikkien lokaatioiden oletusarvo standardilokaatiolle on kyseinen lokaatio itse. Standardilokaation muutokset tekee ylläpitäjä käsin jälkikäteen.

SD

Salaisen datan käytössä on se ongelma, että se on salaista. Kuitenkin olisi tärkeää selvittää, kuinka tärkeää data on, ilman että paljastetaan, mikä se data on. Tähän tuli mieleeni ratkaisu:

Lähdetään siitä, että vaikka data sinänsä on salaista, sen keskihajonta on julkinen tieto. Niinpä voidaan Cell-tauluun lisätä kenttä SD, johon tämä hajonta sijoitetaan. Sen sijaan salatun tiedon tapauksessa Cell.Mean-kenttä jätetään tyhjäksi.

----1: . Tämä muutos on jo Opasnet-kantaan tehty. --Jouni 16:01, 22 May 2009 (EEST) (type: truth; paradigms: science: comment)

Nyt kuvitellaan tilanne, että meillä on muuttujasta julkinen estimaatti, joka on epävarma, ja salainen lisätutkimus, joka on informatiivinen. Jos tiedämme lisätutkimuksen hajonnan, voimme laskea EVPIIn (tiedon arvo osittaiselle epätäydelliselle tiedolle). Se tapahtuu siten, että oletamme saavamme tuon salaisen tutkimuksemme käyttöön, jolloin tiedon informatiivisuus lisääntyy eli keskihajonta kapenee. EVPIIssä verrataan alkuperäistä julkista jakaumaa tilanteeseen, jossa uusi tieto on jakauma, jonka keskiarvo otetaan alkuperäisestä jakaumasta arpomalla mutta keskihajonta salaisesta tutkimuksesta. Täydellisen tiedon EVPPIhän lasketaan muuten samalla tavalla mutta oletetaan, että uuden tiedon SD=0.

EVPII:n käyttö on erittäin tehokas työkalu osoittamaan sitä, kuinka kalliiksi yhteiskunnalle tulee jonkin tietyn informaation pimittäminen. Jos saamme pimitetystä tiedosta hajonnan selville, voimme demonstroida tämän kvantitatiivisesti. Tällä lähestymistavalla vielä tehdään jokin juttu Scienceen...

Res and Resinfo -tables should be merged

How to read discussions

Fact discussion: .
Opening statement: Res and Resinfo -tables should be merged

Closing statement: Tables will be merged

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:

←--1: . Merging these tables makes some queries faster because we can get rid of at least one join-query --Juha Villman 12:51, 7 September 2009 (EEST) (type: truth; paradigms: science: defence)

----2: . Merging makes Res-table slightly larger (approx. 2 %) because Restext, Who and When -fields require some amount of space even if they are empty (10 bits). --Juha Villman 12:51, 7 September 2009 (EEST) (type: truth; paradigms: science: comment)
Retrieved from "https://en.opasnet.org/index.php?title=Talk:Opasnet_base_structure&oldid=22381"