Relace Access 2010
Zdravím,
potřebovala bych pomoc s jednou databází, respektive s její relací. Moc nechápu, co s čím se tam spojuje, podle čeho to je. Vždy jsem spojovala primární a cizí klíče a nějak mi to vždy vyšlo, ale ted nevím co s tím, jedno ID mi tam přebývá :( Mohli byste se na to prosím kouknou a zkontrolovat, popřípadě říct jak to má být? Moc by mi to pomohlo.
Děkuji
vložen obrázek z té idiotské služby jménem imageshack. Proč jsi jej nevložila přímo sem? (touchwood) (mif)
Tvé přání je mi rozkazem 
(mif)
Co konkretne se ti na tom nezda?
jestliže mají tabulky pobočka-zákazník, zákazník-služba a zaměstnanec-služba reprezentovat pivot tables pro relace M:N, pak v tom případě máš špatně primární klíče - NESMÍ být na relačních polích, ale musí být vytvořen separátní primární klíč.
Jinak je to správně, je to celkem hodně triviální datový model, nic složitého.
Děkuji moc. Jen moc nerozumím, tomu co jste napsal :) V Accessu se pohybuji krátce, takže nevím, co znamená relační pole ani separátní PK. Nemohl by jste mi prosím jen říct, co na tom mám opravit? Děkuji
Primární klíč (a dá se to najít i v nápovědě Accessu) je pole, které obsahuje UNIKÁTNÍ záznamy (tedy záznamy bez duplicit). Je-li tedy např. pole ID_zákazníka v tabulce pobočka-zákazník nastaveno jako primární, znamenalo by to, že pro jednu pobočku bude existovat právě jeden zákazník (a relace 1:N, která je naznačena ze strany tabulky Zákazník je pak zcela nesmyslná).
Primární klíče se tedy nastavují v tabulkách pouze u těch polí, které reprezentují levou stranu vztahu 1:N, např. v tabulce Zákazník bude správně nastaven PK pro ID_zákazníka, a to právě proto, že tabulka Zákazník reprezentuje unikátní záznamy o zákaznících.
Celý problém vyřešíš tak, že primární klíče u těchto pivotových tabulek (všechny označené jako něco-něco)odstraníš (tedy záznamy budou moci býti duplicitní) a v tabulce vytvoříš ještě jedno zvláštní pole jako PK, např. ID_pobocka-zakaznik.
Zdravím,
rozdělil jsem databázi MS Access na front-end a back-end a teď nevím jestli je lepší definovat relace mezi tabulkami na front, nebo back-endu. (nebo na obojím?) Jaký je rozdíl? Případné důsledky pro export tabulek? Ví někdo?
Dík.
Radek
To je dost obecně položená otázka na to, aby se dalo odpovědět.
Tak lépe... Rozdělením databáze vznikly dva soubory databáze typu MS Access. Jeden obsahuje tabulky a druhý obsahuje odkazy na tabulky z prvního a také dotazy, formuláře, sestavy atd. V obou databázích se dají myslím úspěšně formulovat relace mezi tabulkami (odkazy na tabulky). Druhý soubor (typu Front-end) však přebírá relace ze souboru prvního - obsahujícího tabulky, přičemž stávající relace z prvního souboru nejdou ve druhém změnit. Proto by bylo možná lepší relace vytvářet až na straně klienta (Front-end). Na druhou stranu pokud budu chtít exportovat tabulky třeba na server nebudu mít v souboru Back-end informace o relacích. Právě relace mě ovšem paradoxně způsobili problém při exportu na SQL server. Proto se ptám na zkušenosti ostatních a hlavně... Je lepší udělat relace na Front-endu, nebo Back-endu? (I s ohledem na budoucí export na SQL server)
pokud exportuješ "automaticky" pomocí nějakého černokněžníka, tak je to stejně jedno, optimální to nebude nikdy. Z hlediska accessu je to fuk, je to souborově orientovaná databáze (každý klient otevírá a modifikuje rovnou soubor databáze). Z hlediska SQL bych osobně stejně jen přesunul jen data (tabulky) a případné queries už dělal rovnou v MSSQL.