Kasutajatugi

Kohustuslik lugeda

Ma olen informaatika üliõpilane. Ma arvan, et kursuse töö töövihik on suur dokument mida keegi ei kasuta päris elus. Aine projekti tegemine on täielik ajaraisk, sest kogu info mida õppejõud näha tahab tuleb temalt ning kui ise sellest väga õppida ei saa. Milliseid kasulikke teadmisi, lisaks andmebaasidele, see projekt annab?

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/

Kui Enterprise Architect (EA) ei luba töötada DDLenhace-ga ja mudeli disain tuleb teha DDL-ga, siis kuidas kontrollida millised parameetrid peavad olema kohustuslikud ja millised PK või FK ning millistel parameetritel peab olema vaikimisi väärtus?

"Andmebaasid I" õppeaines kasutame infosüsteemi ja selle osaks oleva andmebaasi kirjeldamiseks UML modelleerimiskeelt. Milliseid allikaid soovitate UMLiga tutvumiseks või selle kohta teadmiste värskendamiseks lugeda?

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

Andmebaaside aine pöörab palju tähelepanu süsteemianalüüsile. Miks see on oluline?

Miks on kasulik tükeldada infosüsteemi allsüsteemideks?

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"?

Milliseid täiendusi tuleb arenduse tulemites (mudelid, andmebaas+rakendus) teha, kui tekivad uued nõuded, mida rakendus peab realiseerima?

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.

Teeme töövihiku järgi ning põhiolemiks on hoiuruum. Küsimus: Kas olekudiagrammile oleks loogiline lisada ka "renditud" olek? Mõtlesime selle üle ning tundus, et see viib vastuoluni, et hoiuruum peab olema korraga nii aktiivne kui ka renditud/vaba. (See oleks justkui nagu aktiivse oleku alam-olek). Samas informatsioon selle oleku kohta, kas hoiuruum on välja renditud või vaba on väga vajalik. Kas seda olekut peaks kajastama hoiuruumi seisundi diagrammil või kuskil mujal?

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?

Kas töövihiku järgi projekti tehes (X=teenus) peaks lisama kasutusjuhtude mudelisse kasutusjuhud teenuste broneerimise kohta?

Miks suurte IT-süsteemide arendamine pahatihti ebaõnnestub?

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?

Meie töövihiku projekti teemaks on treeningute funktsionaalne allsüsteem. Dokumendi punktis 1.2.3 (Allsüsteemi poolt vajatavad registrid) me kirjutame, et kasutame saalide registrit. Kas see tähendab, et meie projekti kontseptuaalse andmemudeli osaks peab olema saalide registri olemi-suhte diagramm?

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?

Kuidas eristada sisulisi ja administratiivseid allsüsteeme?

Miks on vaja klassifikaatorite funktsionaalset allsüsteemi?

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?

Töövihiku projekti muutes tekkis küsimus, kui suurt rõhku tuleks panna ainsuse/mitmuse kasutamisele X-i asendamisel? Nt. allsüsteemide juures on isikute, töötajate jne allsüsteemid, loogiliselt võttes tuleks seal asendada X mitmuse vormiga, aga kas see oleks korrektne? Läbivalt on kasutusel muidugi (meie projekti puhul) kaup kui ainsuse vorm, kuid mõned kohad tekitavad segadust, kas panna mitmusesse või ainsusesse. Kuidas sellises olukorras tegutseda?

Mis asi on register?

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

Kas välisteks tegutsejateks võivad olla teised infosüsteemid?

Andmebaasid I (ITI0206) (kevad 2024)

Küsimused teemal: Andmebaasi kavandamise sisulised küsimused