Návrh relační databáze

[pk13]

Zdravím všechny, potřeboval bych poradit jak by měl vypadat "správný" (nebo alespoň co nejčistší) návrh databáze. Představte si, že mám data, která si lze představit jako auta, každé auto má své výrobní číslo, svého vlastníka (který se může měnit), firmu ve které vlasntník pracuje (ta se také může měnit) a počet najetých kilometrů.
- to je celkem jasné na to stačí 1 tabulka s příslušnými sloupci (vlastně to tak i dostávám)

Problém ale nastává, když tato data dostávám každý den a po mě se chce na dotaz generovat změny za posledních pár dnů (kolik které auto mělo daný den najeto kilometrů a o kolik to bylo více oproti dni minulému, jestli nějaké auto změnilo vlastníka, jestli nějaký vlastník auta změnil firmu ve které pracuje, jestli nějakému vlastníku přibylo nějaké auto, jestli nějakému vlastníku auto ubylo, auta které vastník vlastní a kolik na kterém ujel kilometrů, kolik ujeli kilometrů celkem zaměstnanci dané firmy, kdo daný den autem nejel apod.)

Z toho mála, co o databázích vím mi nedává dobrý smysl každý den dělat novou tabulku, kde je skoro vše stejné a změní se většinou jen pár čísel v jediném sloupci (počet najetých kilometrů).

[Reklama]

[neron]

Zdravím všechny, potřeboval bych poradit jak by měl vypadat "správný" (nebo alespoň co nejčistší) návrh databáze. Představte si, že mám data, která si lze představit jako auta, každé auto má své výrobní číslo, svého vlastníka (který se může měnit), firmu ve které vlasntník pracuje (ta se také může měnit) a počet najetých kilometrů.
- to je celkem jasné na to stačí 1 tabulka s příslušnými sloupci (vlastně to tak i dostávám)

To není tak úplně pravda, lepší by bylo oddělit firmy a vlastníky do jiných tabulek. Ale lze to i takhle, ale jakmile se tam vyskytne jeste nejaky další údaj (věk vlastníka, IČO firmy nebo cokoliv jiného) začne to být problém.

Problém ale nastává, když tato data dostávám každý den a po mě se chce na dotaz generovat změny za posledních pár dnů (kolik které auto mělo daný den najeto kilometrů a o kolik to bylo více oproti dni minulému, jestli nějaké auto změnilo vlastníka, jestli nějaký vlastník auta změnil firmu ve které pracuje, jestli nějakému vlastníku přibylo nějaké auto, jestli nějakému vlastníku auto ubylo, auta které vastník vlastní a kolik na kterém ujel kilometrů, kolik ujeli kilometrů celkem zaměstnanci dané firmy, kdo daný den autem nejel apod.)

Z toho mála, co o databázích vím mi nedává dobrý smysl každý den dělat novou tabulku, kde je skoro vše stejné a změní se většinou jen pár čísel v jediném sloupci (počet najetých kilometrů).

Ne, určitě nevytvářet dynamicky tabulky pro jednotlivé dny. Je potřeba rozšířit tu tabulku o datum a primární klíč pak bude ID auta + datum vytvoření záznamu. Nad tím pak půjde provádět příslušné selekty.

[pk13]

Takže když dostávám každý den tabulku dat ve formě:
výrobní číslo - vlastník - firma - najetých kilometrů

tak stačí přidat ještě jeden sloupec den a vše ládovat do jediné tabulky?

A jak se to změní, když tam budou atributy jasně svázané jen s vlastníkem, popřípadě firmou? (například bydliště vlastníka, síldo firmy ... obojí se může občas změnit)

[wamba]

Takže když dostávám každý den tabulku dat ve formě:
výrobní číslo - vlastník - firma - najetých kilometrů

tak stačí přidat ještě jeden sloupec den a vše ládovat do jediné tabulky?

A jak se to změní, když tam budou atributy jasně svázané jen s vlastníkem, popřípadě firmou? (například bydliště vlastníka, síldo firmy ... obojí se může občas změnit)

tak to je jedna možnost poměrně extrémní,
jiná možnost je mít "spoustu" tabulek, např. jedna tabulka kde bude "datum, výrobní číslo auta, kilometry", další pro vlastníky, další pro firmy, další pro auta, další která bude spojovat   auta s vlastníky (s firmami) atd. , to záleží na spoustě věcí např. kolik bude údajů,  co se vlastně bude často zjišťovat atp.

[Pavel]

Takže když dostávám každý den tabulku dat ve formě:
výrobní číslo - vlastník - firma - najetých kilometrů

tak stačí přidat ještě jeden sloupec den a vše ládovat do jediné tabulky?

A jak se to změní, když tam budou atributy jasně svázané jen s vlastníkem, popřípadě firmou? (například bydliště vlastníka, síldo firmy ... obojí se může občas změnit)

Mozne riesenie bez nejakeho velkeho uvazovania:

T1: data o firme s datumami "platne OD" + nejaky abstraktny udaj ktory nebudes menit cely zivot firmy (pripadne nieco stabilne ako napr. IC)
T2: detto vlastnik
T3: na zvazenie detto samotne auto, ale tu asi je zbytocne dumat, vyrobne cislo sa pocas zivota zariadenia menit nebude
T4: abstraktny udaj o firme, abstraktny udaj o vlastnikovi, vyrobne cislo, kilometre, datum

V1: T1 s vypocitanym "platne DO"
V2: T2 s vypocitanym "platne DO"
V3: T2 s vypocitanym "platne DO"
V4: v pripade, ze nepridu kazdy den data pre kazde auto, virtualizujeme nulove zaznamy do T4

z toho sa trivialne vysklada hociaky rozumny report + lahko sa to bude naplnat.

[Reklama]

[PanKapitanRUM]

Základem správného návrhu databáze je neduplikovat data a nevytvářet zbytečné tabulky.
Pro tento účel slouží návrhové vzory a postupy, který jsou na netu tisíce a pro CZ jazyk stovky viz: http://www.google.cz/search?q=jak+navrhnout+datab%E1zi

Určitě doporučuji si to nastudovat z příslušné literatury, je jí k dispozici opravdu hodně.
Začněte třeba zde: http://office.microsoft.com/cs-cz/access-help/navrhovani-databaze-HP005189136.aspx
http://www.google.cz/search?q=navrhov%E1n%ED+datab%E1z%ED

Je to tak, že 10 hodin strávených správným návrhem Vám ušetří třeba 100 hodin pozdějších oprav a řešení obtíží.
Problém "moderní zkurvené doby a moderních zkurvených lidí" je v tom, že nemají chuť se přehrabovat v informacích.
Musím se přiznat a stydím se za to, že taky často chvátám, protože jsem k tomu nucený "moderní zkurvenou dobou".

Ale v tomhle případě to chce ten návrh udělat VELMI DOBŘE A KVALIFIKOVANĚ.
Mnoho vazeb může zkomplikovat programování takové aplikace.
Netuším, v čem chcete danou aplikaci programovat, ale jsou i možnosti ukládání objektů: Ochutnávka třeba zde http://cs.wikipedia.org/wiki/Hibernate

Mít pro každé auto vlastní objekt by mohlo mít řadu výhod, taková aplikace by asi nedokázala dostatečně rychle ošetřit statisíce dotazů, ale pro omezený počet dotazů (běžné použití) by to mohlo být velmi vhodné.

A jen se chci zeptat, neprogramujete náhodou ten slavný CENTRÁLNÍ REGISTR VOZIDEL  ??

[Mirek Prýmek]

A jen se chci zeptat, neprogramujete náhodou ten slavný CENTRÁLNÍ REGISTR VOZIDEL  ??

Ten byl dobrej!

[pk13]

CENTRÁLNÍ REGISTR VOZIDEL  ??

Odhalen! ... ba ne, snažím se pro sebe si udělat malou legální pomůcku na jednu webovou hru, chtěl jsem do toho investovat maximálně 5-10 hodin. Z toho mála co o databázích vím (mé znalosti končí, tím, že existují 3 normální formy) jsem nebyl schopný to dát dokupy a nastudovat si návrhy databáze pro mě nebyla příliš schůdná cesta (volných 100+ hodin bohužel ve svém rozvrhu momentálně nenajdu, snad jednou...).

Osobně jsem si od tohoto vlákna sliboval, že se sejde několik možností od lidí pro které je toto denním chlebem a z hlavy něco rozumného vysypou za pár desítek sekund (max. minut) a já vyberu tu nejschůdnější (pravděpodobně "good enough"), možná se tím i něco málo naučím... a to se i splnilo

Děkuji všem zůčastněným

[Logik]

No udělej jednu tabulku firma, jednu tabulku vlastník, jednu auta s identifikací aut a jednu vlastnosti auta, kde
budou věci, jejichž změnu chceš sledovat.
Do vlastnosti_auta pak dělej pouze INSERTY, co změna, to nový řádek. Co se u auta změnilo a kdy pak zjistíš jednoduše

SELECT * FROM vlastnosti_auta WHERE  auto_id = XY ORDER BY datum_zapisu DESC LIMIT 2

Samozřejmě to chce správný indexy.
Podobnej princip pak můžeš použít např. pro sledování změny firmy pro vlastníka auta atd....

[j]

A jen se chci zeptat, neprogramujete náhodou ten slavný CENTRÁLNÍ REGISTR VOZIDEL  ??

Ten byl dobrej!

Neblbnete, tam nevedi co je to tabulka ... a existenci indexu jim musi sdelit nejaky zacek ZS.

Jinak k veci
1) zaklad je mit v kazdy tabulce nejaky pole unikatniho identifikatoru - i kdyz se zda, ze neni na nic treba. Usetri to spoustu trablu v budoucnu.
2) je treba brat v potaz to, ze mensi databaze = rychlejsi databaze => jak bylo receno, minimalizovat duplikovani polozek

=> pro dany ucel bych pouzil 4 tabulky - firmy, vlastnici , tabulka s autama a kilometry

3) dalsi zasada je, NIKDY ale opravdu NIKDY nepouzivat libovolna data nesousi informaci jako identifikator zaznamu - prvni pozadavek ze kteryho se posere vyvojar i cela databaze ... "ale ja to cislo chci zmenit"

Tzn trebas:

tb.auta
id_auta,vin,obsah, ...

tb.firmy
id_firmy,ico,adresa, ...

tb.vlastnik
id_vlastnika, jmeno, prijmeni, ...

tb.kilometry
id, id_auta, id_firmy, id_vlastnika, datum, stav_km, ...

Predpokladam zadavani stavu tachometru pri ukonceni(asi logictejsi) nebo zahajeni jizdy, to je jedno, ale porad stejne. Kdyz se zmeni neco (adresa ..) netreba prepisovat haldu zaznamu, staci jeden.

Jinak hned na tom taky videt, proc mit v tabulce ID - klidne by se mohlo stat, ze vzniknou dva totozne zaznamy o jizde v jednom dnu (stejny pocet kilometru) a problem je na svete - nelze je samostatne aktualizovat, smazat ...