Letos se uskuteční již 11. ročník soutěže v programování Kasiopea. Tato soutěž, (primárně) pro středoškoláky, nabízí skvělou příležitost procvičit logické myšlení a dozvědět se něco nového ze světa algoritmů – a to nejen pro zkušené programátory, ale i pro úplné začátečníky. Domácí kolo proběhne online od 22. 11. do 7. 12. 2025 a skládá se z 9 zajímavých úloh různé obtížnosti. Na výběru programovacího jazyka přitom nezáleží – úlohy jsou
… více »Byla vydána nová verze 2.52.0 distribuovaného systému správy verzí Git. Přispělo 94 vývojářů, z toho 33 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
VKD3D-Proton byl vydán ve verzi 3.0. Jedná se fork knihovny vkd3d z projektu Wine pro Proton. Knihovna slouží pro překlad volání Direct3D 12 na Vulkan. V přehledu novinek je vypíchnuta podpora AMD FSR 4 (AMD FidelityFX Super Resolution 4).
Poštovní klient Thunderbird byl vydán v nové verzi 145.0. Podporuje DNS přes HTTPS nebo Microsoft Exchange skrze Exchange Web Services. Ukončena byla podpora 32bitového Thunderbirdu pro Linux.
U příležitosti státního svátku 17. listopadu probíhá na Steamu i GOG.com již šestý ročník Czech & Slovak Games Week aneb týdenní oslava a také slevová akce českých a slovenských počítačových her.
Byla vydána nová verze 9.19 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze například nový balíček BirdNET-Go, tj. AI řešení pro nepřetržité monitorování a identifikaci ptáků.
Byla vydána nová verze 3.38 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.10 souvisejícího programovacího jazyka Dart (Wikipedie).
Organizace Apache Software Foundation (ASF) vydala verzi 28 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Byl vydán Debian 13.2, tj. druhá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Google představil platformu Code Wiki pro rychlejší porozumění existujícímu kódu. Code Wiki pomocí AI Gemini udržuje průběžně aktualizovanou strukturovanou wiki pro softwarové repozitáře. Zatím jenom pro veřejné. V plánu je rozšíření Gemini CLI také pro soukromé a interní repozitáře.
Dobrý den,
mám dotaz ohledně správného rozkladu......
Mám tabulky zápas a tým.
Zápas (id_team_1 , id_team_2, ............)
Tým (id_team,nazev,............)
id_team_1,id_team_2 - cizi klice s tabulky Tym.
Potrebuji vyresit spravne vztah mezi temito tabulkami, podle me je tady vztah N:M, ale jelikoz jsou tymy vybirany ze stejne tabulky, tak nevim jak to spravne vyresit.
Dekuji..........
A čo na tom nevieš vyriešiť? Veď to máš správne... 
Vzťah M:N je medzi tabuľkami "Tým" a "Tým", s tým že väzobná tabuľka je "Zápas". Medzi tabuľkami "Tým" a "Zápas" je dvakrát vzťah 1:N.
nevim nejak sem se zamotal protoze ty tymy vybiram z jedne tabulky
vzdyt jeden tym muze hrat N zapasu ale jeden zapas muzou hrat vzdy 2 konkretni tymy
tym (1)------------------(N) zapas (N)-------------------tym(1)
mam mit dve tabulky tym ??? to je blbost ne ?
sem se nejako zamotal :( :)
pokud do budete malovat do nějakého schématu (nevidím jiný důvod, proč byste potřeboval vědět, jak tu vazbu označit),
Typ vazby musíte znát i bez omalovánek, jinak nedáte SELECT. Slovní popis vazeb nemusí nutně znamenat nutnost grafického modelu.
Ale tak samozřejmě. Vždycky se to musí nějak vysvětlit. A jestli to člověk udělá grafickým modelem nebo slohovou prací — výsledek by měl být stejný. To znamená — srozumitelný pro toho, kdo s databází pracuje. 
Můžu Tě uklidnit. Máš to dobře. Obecně se vztah M:N řeší přes převodní tabulku, ale v tomto případě dva cizí klíče stačí. Výběr provedeš takto:
SELECT
z.whatever,
t1.nazev AS "název prvního týmu",
t2.nazev AS "název druhého týmu"
FROM
zapas z INNER JOIN tym t1 ON (z.id_team_1 = t1.id_team)
INNER JOIN tym t2 ON (z.id_team_2 = t2.id_team)
WHERE
1 = 1
-- AND whatever…
/
Ještě bych zauvažoval nad CHECK CONSTRAINTem, který zajistí, aby tým nemohl hrát sám se sebou (předpokládám, že id_team_1 and id_team_2 jsou již pod NOT NULL constraintem):
ALTER TABLE "Zápas" ADD CONSTRAINT ck_teams CHECK (id_team_1 != id_team_2) /
Jen doplním mé myšlenkové pochody: předpokládám, že primární klíč v tabulce ZÁPAS je definován svým ID; předpokládám, že dva týmy můžou spolu hrát několik zápasů.
diky moc vsem sem, zacatecnik s databazemi tak me zmatlo ze jsou oba tymy se stejne tabulky......
jen pro upresneni :) mam tedy dve tabulky mezi kterymi mam dva vztahy 1:N ??? :)
neubicujte me za tu otazku 
podivam se na to co znamena ten CHECK CONSTRAINT a bude to ok snad
tak jeste jednou diky
Ano, jedná vpodstatě o vztah 1:N. Dá se říci, že ty tabulky mají dvojnásobný vztah. Jak jsem říkal, je to jedna z možných implementací vztahu M:N. S pomocnou tabulkou by to vypadalo takto: TYM — TYM_ZAPAS — ZAPAS:
CREATE TABLE tym (
id_team NUMBER(10) NOT NULL,
nazev VARCHAR2(256) NOT NULL)
/
ALTER TABLE tym ADD CONSTRAINT pk_tym PRIMARY KEY (id_team)
/
CREATE TABLE zapas (
zapas_id NUMBER(10) NOT NULL,
zapas_details VARCHAR2(256))
/
ALTER TABLE zapas ADD CONSTRAINT pk_zapas PRIMARY KEY (zapas_id)
/
CREATE TABLE tym_zapas (
zapas_id NUMBER(10) NOT NULL,
id_team_1 NUMBER(10) NOT NULL,
id_team_2 NUMBER(10) NOT NULL)
/
ALTER TABLE tym_zapas ADD CONSTRAINT fk_zapas FOREIGN KEY (zapas_id) REFERENCES zapas (zapas_id)
/
ALTER TALBE tym_zapas ADD CONSTRAINT fk_tym1_tym FOREIGN KEY (id_team_1) REFERENCES tym (id_team)
/
ALTER TALBE tym_zapas ADD CONSTRAINT fk_tym2_tym FOREIGN KEY (id_team_2) REFERENCES tym (id_team)
/
ALTER TABLE tym_zapas ADD CONSTRAINT pk_tym_zapas PRIMARY KEY (zapas_id, id_team1, id_team2)
/
Tento model má tu výhodu, že do tabulky TYM_ZAPAS můžu dát vlastnosti, které se týkají jen vztahu tým — zápas.
Jiný příklad. Mám vyřešit datový model v bance. Mám ukládat účty a jejich klienty. Každý účet má několik klientů. Jednoho majitele a pak případně další (například manželka a její disponabilní právo; nebo nějaký garantor úvěrového účtu). To znamená, že zavedu tabulku účtů, tabulku klientů a tabulku vazeb. Ten typ vztahu klient — účet — to je přesně to, co patří do té vazební tabulky KLIENT_ÚČET.
Ano, jedná vpodstatě o vztah 1:N. Dá se říci, že ty tabulky mají dvojnásobný vztah. Jak jsem říkal, je to jedna z možných implementací vztahu M:NTaky by se to dalo označit jako jeden vztah 2:M
System Eror :)
nj ale vztah ktery ja nechapu tedy vztah mezi tabulkou "tym" a "zapas" byl presunut mezi tabulky "tym_zapas" a tabulu "tym"
TYM — TYM_ZAPAS — ZAPAS:
stale vybiram 2 tymy s tabulky "tym" ...
porad me tam pretrvava vztah 2:N jenom se presunul mezi jine tabulky
CREATE TABLE zapas ( id int, time_play time, ... ); CREATE TABLE tym ( id int, name text, ... ); CREATE TABLE tym_zapas ( id int not null primary key, zapas int not null reference zapas (id) on delete restrict, tym int not null reference tym (id) on delete restict, score int null, home int not null ); CREATE UNIQUE INDEX i__tym_zapas on tym_zapas (tym, zapas);Hlavná výhoda: ak potrebujem nájsť zápasy týmu X, nemám podmienku OR (tym1 = ? or tym2 = ?). Práca so score, kombináciami týmov, ... Príklad: chcem vyhľadať zápasy Sparta - Slavia, ktoré skončili víťazstvom Sparty
SELECT
z.time_play,
case when zt.home = 1 then 'na sparte' else 'na slavii' end,
t1.name,
t2.name,
zt1.score,
zt2.score
FROM
zapas z,
tym t1,
tym t2,
tym_zapas zt1,
tym_zapas zt2,
WHERE
t1.name = 'Sparta' -- ktorý tým je Sparta
and t2.name = 'Slavia' -- ktorý tým je Slavia
and zt1.tym = t1.id -- ktoré zápasy hral tým 1
and zt2.tym = t2.id -- ktoré zápasy hral tým 2
and zt1.zapas = zt2.zapas -- oba hrali rovnaký zápas
and zt1.score > zt2.score -- a tým 1 dal viac gólov
;
Vysvetlenie pre autora otázky: v klauzule FROM je definíciou aliasu pre tabuľky (t1, t2, zt1, zt2) umožnené vyhľadať dva rôzne riadky z jednej tabuľky, každý podľa jeho vlastnej podmienky
Pre fanúšikov join: tento zápis považujem za zrozumiteľnejší
System Eror :)
Nic takového tady neznáme. 
nj ale vztah ktery ja nechapu tedy vztah mezi tabulkou "tym" a "zapas" byl presunut mezi tabulky "tym_zapas" a tabulu "tym"
TYM—TYM_ZAPAS—ZAPAS:stale vybiram 2 tymy s tabulky "tym" ...
porad me tam pretrvava vztah 2:N jenom se presunul mezi jine tabulky
Jistě. O to tady jde. Tvůj problém je, že v tvém případě zápas spolu hrají právě dva týmy. Proto ti stačí dva cizí klíče — jak psal Filip Jirsák — vzba 2:N. Kdybys měl případ, že nevíš, kolik těch týmů může hrát jeden zápas — například ten vztah účet a jeho klienti — pak bys měl dvě možnosti:
Takže jinými slovy — ta vazební tabulka se hodí v těchto případech:
Naproti tomu cizí klíče použiješ, když:
Tak snad jsem to trošku objasnil… doufám… Už mě totiž napadají jen samé nevhodné příklady, které by snad prošly v blogu než v poradně (například model "vztahů" návštěvníků gayklubu — každý s každým). 
takze formalne si vztah zakreslim jako dve cary se vztahem 1:N mezi tabulkami (viz obr)
Tak dekuji vsem kteri prispely a pomohli k rozjasneni v me hlave :)
Tiskni
Sdílej: