Omadus-väärtus (ehk rdf) andmebaasidest: erinevus redaktsioonide vahel

Allikas: Lambda
Mine navigeerimisribale Mine otsikasti
Resümee puudub
Resümee puudub
28. rida: 28. rida:
Kui tahad siduda eri tabeleid (näiteks, panna kirja, mis amet on mis inimesel) siis tehakse seda antud näites nii, et ametite tabelis on isikukoodi tulbas kirjas
Kui tahad siduda eri tabeleid (näiteks, panna kirja, mis amet on mis inimesel) siis tehakse seda antud näites nii, et ametite tabelis on isikukoodi tulbas kirjas
inimese kood isikute tabelis (ehk, "isikukood" tulp ametite tabelis vastab "ikood" tulbale isikute tabelis).
inimese kood isikute tabelis (ehk, "isikukood" tulp ametite tabelis vastab "ikood" tulbale isikute tabelis).
== Omadus-väärtus (ehk rdf) andmebaaside idee ==
Traditsiooniline viis andmeid hoida on väga hea, kui on täpselt teada, mis sorti asjade kohta ja mis sorti infot me hoidma hakkame. Teisisõnu, saame tabelite
loetelu ja tulbad ette ära määrata, ning siis teha oma programmid täpselt nende tabelite ja nende tulpade jaoks.
Paraku ei ole see igas rakenduses võimalik. Eriti ebamugavaks läheb olukord, kui andmeid tuleb lugeda võrgus olevatest andmebaasidest,
mida teised arendajad vahel muudavad (lisavad sinna tulpasid jne): me ei saa täpselt ette ennustada, et mis tabelid mis tulpadega meile
kättesaadavad on.
Appi tuleb järgmine lihtne idee: hoiame kõiki oma objekte (inimesed, ametid, autod jne) ühesainsas nelja tulbaga tabelis:
  objekti kood  ,  objekti omaduse nimi ,  objekti omaduse väärtus,  objekti omaduse tüüp
Ehk, selle asemel, et iga omadust hoida eraldi tulbas, hoiame ühe objekti ühte omadust täpselt ühel real. Arusaadavalt on selliselt tehtud andmebaasis palju rohkem ridu,
kui nö traditsioonilises andmebaasis.

Redaktsioon: 27. september 2006, kell 11:30

Enne rdf baaside selgitamist kirjutan andmete hoidmisest nö traditsioonilistes andmebaasides.

Harilikud tabelid mitte-rdf baasides

Harilikes andmebaasides hoitakse andmeid enamasti mitmes tabelis: iga tabel sisaldab infot mingit sorti asjade kohta (inimesed, firmad, autod jne jne). Iga tabel sisaldab hulga tulpasid: üks tulp sisaldab vastavat sorti asja mingit kindlat infot (nimi, registrikood, mark, hind vms).

Toome lihtsa näite kahe tabeliga, kusjuures kumbatki võib hoida lihtsalt ketta peal failina:

isikud.csv:

 ikood,eesnimi,pereknimi,vanus,pikkus
 10,Jaan,Mets,32,170.5  
 50,Mihkel,Karu,21,180.4
 30,Anna Marie,Rebane,22,165

ametid.csv:

  amet,isikukood,palk
  koristaja,10,5000
  lektor,10,5000
  direktor,30,9000
 

Esimene fail (isikud.csv) sisaldab infot inimeste kohta. Üks rida vastab ühele inimesele, iga tulp sisaldab konkreetset infot (eesnimi,pereknimi,vanus,pikkus). Samamoodi sisaldab teine tabel infot palkade kohta.

Kui tahad siduda eri tabeleid (näiteks, panna kirja, mis amet on mis inimesel) siis tehakse seda antud näites nii, et ametite tabelis on isikukoodi tulbas kirjas inimese kood isikute tabelis (ehk, "isikukood" tulp ametite tabelis vastab "ikood" tulbale isikute tabelis).

Omadus-väärtus (ehk rdf) andmebaaside idee

Traditsiooniline viis andmeid hoida on väga hea, kui on täpselt teada, mis sorti asjade kohta ja mis sorti infot me hoidma hakkame. Teisisõnu, saame tabelite loetelu ja tulbad ette ära määrata, ning siis teha oma programmid täpselt nende tabelite ja nende tulpade jaoks.

Paraku ei ole see igas rakenduses võimalik. Eriti ebamugavaks läheb olukord, kui andmeid tuleb lugeda võrgus olevatest andmebaasidest, mida teised arendajad vahel muudavad (lisavad sinna tulpasid jne): me ei saa täpselt ette ennustada, et mis tabelid mis tulpadega meile kättesaadavad on.

Appi tuleb järgmine lihtne idee: hoiame kõiki oma objekte (inimesed, ametid, autod jne) ühesainsas nelja tulbaga tabelis:

 objekti kood  ,  objekti omaduse nimi ,  objekti omaduse väärtus,  objekti omaduse tüüp

Ehk, selle asemel, et iga omadust hoida eraldi tulbas, hoiame ühe objekti ühte omadust täpselt ühel real. Arusaadavalt on selliselt tehtud andmebaasis palju rohkem ridu, kui nö traditsioonilises andmebaasis.