Kasutajatugi

Andmebaasis on tabelid, millesse võib olla vaja teha muudatusi. Osadel kasutajatel on muudatuste tegemise õigus, neil kellel pole, peaks olema aga võimalus muudatusi soovitada, need soovitused jõustuksid peale muutmisõigusega kasutaja heakskiitu. See süsteem oleks inspireeritud sellest, kuidas toimivad pull request'id / merge request'ed GitHub ja GitLab keskkondades. Samasugune loogika on olemas ka näiteks Google Docsis (inimese saab lisada soovituse, mis vajab dokumeni omaniku heakskiitu). Kasutaja ei pruugi siinjuures tähistada andmebaasi kasutajat, tegemist võib olla rakenduse kasutajatega, ehk siis kirjetega tabelis `User`. Hea oleks, kui tegemist ei oleks mitte ühe tabeli spetsiifilise lahendusega, vaid üldise lahendusega, mida saaksid kasutada erinevad tabelid. Kuidas võiks sellist asja PostgreSQLiga teha?

Kuidas salvestada PostgreSQL andmebaasis tabelite muudatuste ajalugu? Lahendus peaks olema üldine, mitte ühe konkreetse tabeli spetsiifiline. Kas siin artiklis toodud lahendus on mõistlik? https://www.cybertec-postgresql.com/en/tracking-changes-in-postgresql/

Kas saaksite tuua mõne näite valesti valitud väljapikkustest ja selle põhjustatud probleemidest?

Kohustuslik lugeda

Kas ja millised probleemid võivad tekkida andmebaasirakenduse tegemisel kasutades mõnda ORM (Object-Relational Mappers, objekt-relatsioonvastenduse) vahendit?

Kuidas määrata kindlaks, millises andmekesksesse allsüsteemi e registrisse (andmebaasi loogilisse alamosasse) mingid andmed kuuluvad?

Kas see on tavapärane praktika koostada registrite vaheliste seoste puhul nn vahetabelid, ning kas on juhte, kus see pole vajalik?

Kui teha töövihiku järgi projekti, siis millistele veergudele oleks mõistlik lisada vaikimisi väärtus?

Mis vahe on identifitseerival ja mitteidentifitseerival seosel tabelite vahel?

Kas tühja stringi esinemise keelamine ja NOT NULL kitsendus on üks ja sama asi?

Kuidas jõustada PostgreSQL andmebaasis kitsendus, et tabeli veerus hoitakse rahasummat eurodes?

Kas SQL-andmebaasis saab jõustada deklaratiivsete kitsendustena assotisatsioonireegleid?

Kas sain aru õigesti, et iga klassifikaatori jaoks pole atribuutide definitsioonide tabelis vaja teha eraldi kirjeldust (et lihtsalt kui mõnel klassifikaatoril on olemas atribuut, mida teistel ei ole, siis lihtsalt täpsustan, millel klassifikaatoril on see olemas) ?

Mille alusel otsustada olemite vaheliste seoste alustel leitud olemitüüpide kuuluvuse üle konkreetsesse registrisse?

Mis andmeid võiks registreerida tanklate kohta? Millised võiksid olla tanklaga seotud klassifikaatorid? Kas tanklat pidav organisatsioon võiks olla üks tanklaga seotud klassifikaator?

Igal isikul on null või rohkem meiliaadressi. Võib juhtuda, et mitu isikut jagavad ühte ja sama meiliaadressi. Kas selliste andmete hoidmiseks peaks tegema kokku kolm tabelit: meiliaadresside tabeli, isikute tabeli ja meiliaadresside ja isikute vahelist M:N seost esitava vahetabeli?

Kui tabelis Riik on (nimetus) alternatiivvõti, siis miks ei piisa selle jõustamiseks UNIQUE kitsendusest? Miks on vaja veerule nimetus ka NOT NULL kitsendust?

Miks ei ole hea mõte kasutada kõikides tabelites surrogaatvõtit?

Miks on halb mõte kasutada erinevates tabelites ühesuguse nimega (id, kood või code) primaarvõtme veergu?

Kas olemasolevates "päriselu" SQL-andmebaasides jõustatakse välisvõtme kitsendusi?

Kas olemasolevate "päriselu" SQL-andmebaaside disaini kvaliteet on hea?

Milleks läheb vaja olemitüüpide ja atribuutide tähenduse e semantika kirjeldusi?

Milliseid probleeme tekitab andmete liiasus operatiivandmete andmebaasides?

Millal modelleerida kontseptuaalses andmemudelis mingit olemitüübi omadust atribuudina ja millal klassifikaatorina (eraldi olemitüübina)?

Mis erinevus on primaarvõtme ja kandidaatvõtme vahel?

Millal kasutada kontseptuaalses andmemudelis kompositsiooniseost (seose ühes otsas on täidetud romb e täidetud teemant)?

Mida kujundab endast elementaarvõtme normaalkuju (EVNK)?

Kui tekstilist väärtust hoidev väli või olla ka tühi, kas parem on lubada NULL väärtust või tühja stringi? Kas võib olla põhjust lubada ka mõlemat?

Meil on küsimus aadressi kohta. Kuidas on parem viis pakiautomaadi (kaupluse/kino/treeningsaali/...) aadressi andmebaasis salvestada? Me nägime, et Omniva lehel näidatakse seda niimoodi: "Ida-Viru maakond, Kohtla-Järve linn, Ahtme linnaosa, Maleva tn, 23". Tundub, et iga koma vahel on eraldi veerg, kuhu kirjutatakse andmed ja veerude nimed oleksid "asukoht_maakond, asukoht_linn, asukoht_linnaosa, asukoht_tänav, asukoht_tänava_nr". Kas me kasutame selle viisi, või saame parema loetavuse jaoks lihtsalt salvestada kogu stringi ühe veergu nimega "asukoht"?

Töövihiku järgi on juba olemas klassifikaator Riik, mis on siis seotud kliendiga seoses isikukoodiga. Kui me soovime lisada klassifikaatori Riik ka Pakettreisile, kas sobib kasutada sama klassifikaatorit või peaksime tegema lisaks Pakettreisi_Riik. Pakettreisi_Riigis ilmselt on vähem võimalikke väärtusi.

Küsimus kontseptuaalse andmemudeli kohta. Ma saan aru, et peame atribuute lisama X'le ja näiteks kliendile (on_nõus_tülitamisega), aga kuidas on erinevate standartsemate atribuutidega teiste olemitüüpide puhul. Nagu näiteks Töötaja_seisundi_liik, X_seisundi_liik või Riik: kas neile peaks ka lisama atribuudid nagu näiteks seisundi_liik_id, nimetus, kirjeldus. Vaadates vastuvõtuaegade näidisprojekti, siis seal näiteks pole neid atribuute kontseptuaalses andmemudelis välja toodud, kuid füüsilises disainis on. Samas X'i jaoks toome me ka kontseptuaalses andmemudelis selle koodi ja nimetuse välja. Seetõttu olen veidi segaduses ja lootsin, et ehk oleks võimalik natukene selgitust või suunamist saada sellele, missugused parameetrid lähevad kontseptuaalsesse andmemudelisse ning mis ainult füüsilisse disaini.

Millised on erinevad tabelite võtmete tüübid ja kuidas need on omavahel seotud?

Otsin omale põnevat lugemist andmebaaside (pigem relatsiooniliste, aga miks mitte ka teiste) antimustrite kohta. Mäletan Teiega andmebaaside kursust läbides, et erinevate materjalide nimed käisid läbi, aga mõtlesin küsida soovitust otse allikast. Mida võiks lugeda? Soovitatavalt võiks materjal olla inglise keeles (saaks jagada ka mitte-eestlastega), aga endale huvi pärast lugemiseks oleks eestikeelne materjal ka väga kasulik. Soovitused on teretulnud nii veebilinkide, dokumentide kui raamatusoovituste kujul.

Mis on (lihtsalt selgitades) normaliseerimine ja normaalkujud?

Märkasin et te kirjutate SQL muutujaid eesti keeles, näiteks "nimi VARCHAR(10)". Arvestades et kõik ettevõtted ning arendajad kirjutavad tänapäeval muutujaid ja koodi inglisekeelselt, kas ma võin ka praktikaülesannetes ning iseseisvas töös kasutada inglise keelt?

Teeme projekti töövihiku järgi. Meil on andmebaasis järgmise kontseptuaalse andmemudeli järgi loodud tabelid: [Treening]-1----------0..*-[Treeningu_kategooria_omamine]-0..*---------1-[Treeningu_kategooria] [Treening]-1----------0..*-[Treeningu_põhimõttelise_toimumise_asukoht ]-0..*---------1-[Ruum] Milliste välisvõtmete puhul tuleks kasutada ON DELETE CASCADE ja milliste puhul mitte?

Mis on olemitüüp, atribuut ja olem?

Kas leidub kergesti kättesaadavat eestikeelset kirjandust SQL-andmebaaside kavandamisel ettetulevatest probleemidest ja nende lahendustest?

Kas kuskil on nähtav andmebaasitehnoloogiate suur pilt?

Kas saaksite tuua näite mõnest andmebaasis puuduvast kitsendusest, mis on tekitanud probleeme?

Miks mitte luua klassifikaatoritele ühist tabelit Klassifikaator, kus on kõikide klassifikaatorite koodid ja nimetused?

Mida ma võiksin teada NoSQL süsteemidest?

Mis on intelligentne võti ja millal seda kasutada?

Milleks läheb vaja kontseptuaalses andmemudelis olevaid olemitüüpide ja atribuutide definitsioonide tabeleid?

Mis asi on register?

Kas puhta koodi põhimõtted on olulised ka andmebaaside korral?

Andmebaasid I (ITI0206) (kevad 2025)

Küsimused teemal: Andmebaasi kavandamise sisulised küsimused