Access návrh DB

Doporučuju nastudovat:

http://cs.wikipedia.org/wiki/Normalizace_datab%C3% A1ze

Stačí 3 tabulky:

1. tabulka "uživatelé", primární klíč id_usera
2. tabulka "předměty" (tj. těch 14 typů zkoušek), primární klíč id_predmetu
3. tabulka "testy" (tj. samotné zkoušky), primární klíč id_zkoušky

je to klasický model m:n, pivot table je tabulka testy, tedy:

uživatelé propojeni na testy v relaci 1:n přes id_usera,
předměty propojeny na testy v relaci 1:n přes id_predmetu

Mi to nějak neštymuje...

Co když stejnou zkoušku dělali dva uživatelé?

EDIT: Daleko lepší model IMHO je:
Mít 4 tabulky Zkouška, Uživatel, vazební tabulku Uživatel_Zkouška a tabulku Typ_Zkouška propojené následovně:

Typ_Zkouška
ID_Typ_Zkouška (PK)

Zkouška
ID_Zkouška (PK)
ID_Typ_Zkouška(FK)

Uživatel
ID_Uživatel (PK)

Uživatel_Zkouška
ID_Uživatel_Zkouška (PK)
ID_Uživatel (FK)
ID_Zkouška (FK)

Ale to máš úplně to samý, jen sis navíc udělal číselník na typ zkoušky.

Jsem sice po kalbě, ale tohle není to samé. Pokud v touchwoodově modelu půjdou dva studenti na stejnou zkoušku, tak musí vznikout nová zkouška.

Ještě jinač. Zkus napsat select který v touchwoodově modelu spočítá počty studentů na jednotlivých zkouškách.

Já asi právě potřebuju bejt po kalbě, protože pokud beru, že tvoje tabulka Zkouska by se přejmenovala na Predmet a tabulka Uzivatel_Zkouska na Test, tak je to úplně to samý, akorát je tam číselní pro typ zkoušek.

Pokud to jde vůbec nějak vztáhnout, tak: moje Zkouška = Test, Typ_Zkoušky = Předmět, Uživatel = Uživatel, Uživatel_Zkouška je jen vazební...

chápu co myslíš, ale to by platilo v okamžiku, kdy stejný test dělá více lidí, což IMHO není ten případ a není to předmětem celého "projektu".

Pokud je to jak říkám, tak bys měl v selectu na danou zkoušku vždy jen jeden řádek s jedním člověkem.

Stejny test muze delat vic lidi. Vetsinou treba na jeden termin 20 lidi. Nekdo vsak jde na prvni pokus nekdo na treti. Nekdo jde na prvni opakovaci predchazejici ostre zkousce nekdo jde na druhy predchazejici trem neuspesnym pokusum.

Nekdo dalsi bude prave zadavat do DB kdy kdo jde, aby pak bylo mozne dohledat napriklad kdo jde 25.8.2010 na ostry test na zkousku F1. A vyhleda mi query lidi kteri jsou na toto datum prihlaseni a at uz jdou na prvni ci desaty pokus. Respektive kdo uz F1 udelal a jaky je prumer bodu, tak ze mi query vezme posledni pokusy nad 50 bodu (ti co prosli) a udela prumer. Ale opet nekdo to mohl dat napoprve a nekdo na paty pokus.

Pripadne jde nejak systemove nastavit, aby druhy opakovaci pokus sel dat, tedy spise byl vzdy presne po 3 neuspesich? Nebo si to musi hlidat ten kdo to tam vklada.

ALe abych se vratil k veci, na jednu zkousku treba ne jeden termin bude 15 lidi na druhou zkousku ve stejny termin 10 lidi. Takze spis to vypada na model MaSo pokud to dobre chapu.

v tom případě, pokud se jedná o klasickou "písemnou zkoušku", je lepší použít model od MaSa.

Technické věci okolo (před)vyplňování a ověřování hodnot se přece řeší až ve formuláři, to jsou z hlediska návrhu databáze nepodstatné věci. Je-li databáze normalizovaná, tohle není a nemůže být problém.

Jen jeste k tomuto uplne prilis nechapu Typ Zkouska a Zkouska. U Typ zkouska bych mel mit zadefinovane napr ze se jedna o zkousku 1-9 a u Zkoušky datum, zda se jedna o pripravny kurz, opakovaci ci ostry test a body ze zkousky?

Ci dokonce by spravne datum melo byt Uzivatel Zkouska?

Typ zkouška je tabulka, kde budeš mít taxativně vyjmenovány všechny "typy" neboli varianty zkoušek (myslím, žes psal, že jich je 14?), v tabulce Zkouška pak budou už jednotlivé termíny zkoušek s vazbou na tabulku Typ zkouška (tj. abys nemusel pokaždé vypisovat detaily zkoušky).

Pokud to dobre chapu tak zhruba takto:

Pokud to dobre chapu tak

Typ_Zkouška
ID_Typ_Zkouška (PK) // zde to bude vyjmenovane F1-F14 bez nejakych dalsich poli

Zkouška
ID_Zkouška (PK) //treba autonumber
ID_Typ_Zkouška(FK)
//typ zkousky (na urovni formulare upravim aby bylo pevne dano na vyber ze tri moznosti :priprava,opakovani, ostry test)
//datum zkousky (date)
//pocet dosazenych bodu (na urovni formulare se osetri, aby vkladat slo jen v pripade ostre zkousky, jinak bude pole prazdne)

Uživatel
ID_Uživatel (PK)
/jmeno, prijmeni, oddeleni

Uživatel_Zkouška // vazebni tabulka zajistujici relaci kdy jakej uzivatel jde na jakou zkousku a v ramci zkousky na jakej typ kurzu a pripadne kolik v minulosti dosahl bodu
ID_Uživatel_Zkouška (PK)
ID_Uživatel (FK)
ID_Zkouška (FK)

Typ_zkouška bych asi trochu rozvinul, komentáře, možná výsledky, apod. - prostě vše, co se daného tématu týká.

Jinak tam vidím jeden potenciální problém - pole "typ zkoušky" by mělo IMHO být až v tabulce "uživatel-zkouška", protože předpokládám, že se mohou sejít "repetenti" s lidmi, kteří ji dělají poprvé nebo jen jako "přípravu"). Aby sis to ulehčil, můžeš si ve formuláři toto pole "předpočítat" - u prvního výskytu daného uživatele (předpokládám, že příprava je jen u jedné, ostatní jsou "naostro) předvyplníš "příprava", u druhého (pokud již existuje záznam "příprava") vyplníš "ostrý" a v ostatních už to bude "opakování" (tedy existuje-li už jeden ostrý na daný test) - toto lze samozřejmě přizpůsobit potřebám a požadavkům.

To pole "typ zkoušky" by nejlépe měla být další tabulka navázaná na Uživatel_Zkouška.

A nemely by ty vysledky byt prave ne u "typ zkouska"(definice F1-F14) ale u "Zkouska"? Protoze prece vysledky by bylo historicky dobre evidovat u jednotlivych pokusu. Tzn typ zkouska napr F3, Zkouska (ostry 12.2.2010 40 bodu, ostry 13.2.2010 60 bodu).

"Typ Zkouska" jak ho zde pisete spis chapu jen definice F1-F14. Samotna Zkouska pak dodatecne informace ("typ zkousky" - pripravna lekce, opakovaci lekce, ostry 1. pokus, ostry 2. pokus,...;; Datum;; body).

Reperenti se mohou sejit na ostrem terminu s temi kdo jdou poprve, tzn. "typ zkousky" ktery uvadis (priprava, opakovaci lekce ostry test) by mel byt v "uzivatel zkouska"? Na priprave se sejit znovu nemohou, protoze ti co to opakuji uz pripravu nemaji. Jedine kde se jeste mohou sejit je opakovaci lekci pred ostrym testem (ta je jen pokud 3x neuspeli u ostre zkousky).

To s tim prepoctenim good idea. Vcera jsem prave to nahodil +- tak jak jsem upravoval a doplnil ten prispevek vyse a nefungovalo to uplne presne

ty výsledky byly myšleny jako správné odpovědi (tedy nápověda/data pro hodnotitele zkoušky) , nikoli výsledky "studentů"

edit: jinak výsledkům testu se též říká klíč. (už jsem si vzpomněl na ten správný výraz)

Ok diky to tam asi nebudu davat, nebot vysledky ani nezname. Zkousky dela externi organizace. jde spise pouze o evidenci kdo dal, zda se na to uplne odflakl a nebo to nedal napr. o bod a hlavne o ty data, kdy je napr. prihlasen na jake zkousky a terminy.

Zkusim to prehodit pole "typ zkousky" k "uzivatel-zkouska" jako rozeznani pripravz, opakovaci lekce a ostreho testu a snad to bude ok.

Kazdopadne diky moc za rady.

Tak to mam : acca.jpg

myslite ze je teda navrh ok?

v obrázku máš špatně relaci (one-to-one)

jinak pokud "Typ zkouška" má jen jedno pole, tak jsi mohl jen nevázat tu databázi jako zdroj hodnot pro pole ID typ zkouška, nemusíš dělat relaci.

Zda je to správně, musíš posoudit ty, ty jediný máš přesnou znalost toho, jak celý proces zkoušek funguje a zda ten model doopravdy odpovídá realitě..

Bylo by hodne neprakticke vzhledem k tvorbe dotazu mit proste teda jen tri tabulky.

Uzivatel - info o uzivateli.
Zkouska - pevnych 14*4 zaznamu. Tj 4 zaznamy pro jednu zkousku ve forme:

Typ kurzu Kurz ID zkouska
F1 Exam F1E
F1 Intro F1I
F1 Mock F1M
F1 Revision F1R
F2 Exam F2E
F2 Intro F2I
F2 Mock F2M
F2 Revision F2R
...

a Uzivatel-zkouska kde by bylo datum, ID zkouska, ID uzivatele a ID uzivatel zkouska??