Hellósztok!
lécci segítsetek!
lenne egy adatbázis elméleti feladat(sor), amit nem bírok megoldani, vagyis nem éppen merek biztosra menni, mert nem értem az anyagrészt!

szóval normálformáról lenne szó!

első feladat:

Hozd megfelelő alakra!

2.)
Szakács (név; ételkód; ételnév; adag; születési év; cím; fajtakód; fajtaszám)
ezt 3-dik normál formára kell hozni!
itt nem muszáj rekordot megadni, hanem elég csak a fejlézet létrehozni... gondolom itt több táblázat is lesz!

A végső feladat :
Hogyan ábrázolnád, jelölnéd a kulcsokat, és a hivatkozás irányát?

több szakács dolgozik a száloda éttermében azt szeretnénk tárolni, hogy melyikük mit főz, segítség a kiinduláshoz:
a szakácsot a személyi szám és név, az ételt az ételkód és az ételnév jellemzi! Szükség lesz egy kapcsoló táblára is! /ki_mit_főz/

ezt végképp nem értem..

szóval ezekben várnám a segítségeteket, és ha lehetne akkor még ma!
nem mondom, hogy élethalál kérdése, meg azonnal.... de elég sürgős!

Ja és elég ha csak elindítana valalaki... mert abszolút nem megy...

első feladatra van egy ötletem, majde minnyá'!


Nagyon szépen köszönöm!

</end.?>

szóval egyes feladatnak ezt találtam megoldásnak:
név | hobbi
Petike | olvasásá
Petike | mosogatás
Esztike | rajzolás
Esztike | biciglizés
Gergő | Számcsizás
Gergő | Biciglizés

remélem ez jó?? érthető??
vagy most ezt még tovább lehet egyszerüsíteni???

UP!!

Nálatok is lassú a ph?? felraktam firefoxot, mert ie be sem hozta...

</end.?>

1. Felsorolást tárolni egy mezőben eleve rossz ötlet. Szóval az a minimum, hogy az egyes hobbikat külön sorba rakod, mellette a gyerek nevével.
Itt szvsz még nincs értelme táblákra szétbontani, de a normalizálás szabályai lehet, hogy megkövetelnék...

2. Egy szakács több ételt is csinál illetve több szakács is csinálhatja ugyanazt az ételt. Nyilván nincs értelme a szakács által elkészített minden egyes ételnél eltárolni a személyi adatait.
Tehát személyi adatok egy táblában.

Hasonlóképp a kajáknál, nincs értelme minden egyes elkészítésnél (más szakács, más mennyiség) eltárolni az étel teljes nevét. (Szöveges adat sok helyet foglal...)
Szóval egy táblában a kaja kódja, és neve.

És amivel összekapcsolod a kettőt:
szakácskód, ételkód, mennyiség (+én betennék egy egyedi azonosítót is a kapcsolótáblába)

A fajta nem tudom mit takar, valószinűleg az is külön táblába tartozik...

Kulcsok: Ami a rekordot az egyik táblában egyértelműen azonosítja -> Elsődleges kulcs az adott táblában. És ha a kapcsolótáblában ezt használjuk az összekötéshez, akkor ott meg idegen kulcs lesz.

Pl a személyi adatos táblában a cím vagy név nem egyértelmű azonosító (bár lehet, hogy épp nincs azonos nevű szakács a konyhán), de a személyi szám igen.-> Elsődleges kulcsnak használható, és a kapcsoló táblában viszont idegen kulcs lehet. (Bár én nem ezt használnám, hanem inkább egy generált egyedi kódot...)

Aki hülye, haljon meg!

Egy ilyen egyszerű adatbázisnál, ahol csak két adatot (név és hobbi) kell tárolni én nem látnám értelmét táblákra bontásnak...

Aki hülye, haljon meg!

nagyon köszi a segítséget...

a fajta az azt takarja, hogy mijen fajtájú az étel, tehát előétel, deszert, főétel, stb..
fajtakód meg azért van, hogy az ne legyen leírva... így most arra tudsz bővebbet mondani??

előre is köszi...

</end.?>

Ez egy nagyon jó leírás erről a témáról:

Bővebben: link

Vazz... még magyarul sem értem... egyébként nem vagyok perfekt angol...

még a feladat sem világos...

</end.?>

Így üresbe ennek a fajtának semmi értelme nincs, de gondolom az alkalmazás ami használná az adatbázist adna neki értelmet.

Valószinűleg van egy külön referencia tábla, amiben csak a pár fajta szerepel, kód és a hózzá tartozó név. És ezt csak azért, hogy ne kelljen az étel táblában állandóan a fajta nevét tárolgatni, és ezzel némi helyet spóroljunk. (Ami szerintem adott példánál minimális, szóval nyugodtan tárolhatnánk azt is.)

Erre gondoltam a hobbi-s példánál is, hogy ha csak pár hobbi szerepel a táblában, azok viszont sokszor ismétlődnek, akkor elvileg ott is lehetne egy hasonló referencia táblát használni, és csak a hobbi kódját tárolni a gyerek neve mellett.

De hogy ezt megérje alkalmazni, ahhoz az kell, hogy viszonylag kevés számú elem, gyakran ismétlődjön, egy nagy rekordszámú táblában. Vagy az ismétlődő elemek olyan hosszúságúak legyenek, hogy már kevés ismétlődésnél is megérje csak kóddal hivatkozni rájuk...

Viszont lehet, hogy a normalizálási szabályok nem különböztetik, meg, hogy érdemes-e vagy sem, szóval nem tudom a te első példádban kell-e alkalmazni ezt a bontást, vagy sem...

Aki hülye, haljon meg!

nos... nem fogja semmijen alkalmazás használni... holnap kell beadnunk lapon... a tanár osztályozza... adatbázist tanulunk elméletből... senki sem érti
szóval a kettes feladat így jó?

vagy el vagyok tévedve???

az első megvan.. azt febontottam egy sorokba...
mod:

ezt értem....

[Szerkesztve]

</end.?>

up...
majd késöbb vissza nézek....

</end.?>

up...

</end.?>

kösz a tippet.... megnézem holnap hogy ebből a könyvből csesztet é minket a tanár...
de holnap is szopok holnapra kell a beadandó

</end.?>

A fajtaszám mire való?

( 2b || !2b ) az itt a kérdés...

a fajtaszám az aszem, hogy ne keljen a fajtanevet beirogatni.... de enm tom... má le is szarom..
lesz ami lesz holnap... oszt kész...
na mindenkinek köszönök mindent.....
üdv.. mára ennyi...

</end.?>

Már régen normalizáltam, de remélem nem csináltam semmi szarvashibát.
Mivel nemtom mire való a fajtaszám ezért két változatom van.

1.

SZAKÁCS(/név,ételkód/,adag)
SZAKÁCS ADATOK (/név/,születési év, cím)
ÉTEL(/ételkód/,fajtakód, fajtaszám)



2.

SZAKÁCS(/név,ételkód/,adag)
SZAKÁCS ADATOK (/név/,születési év, cím)
ÉTEL(/ételkód/,fajtakód)
FAJTA(/fajtakód/,fajtaszám)

(a / jelek között van az azonosító)

( 2b || !2b ) az itt a kérdés...

Ha a fajtakód arra van, hogy a fajta nevet ne kelljen állandóan beírogatni, akkor miért tárolod el mégis minden egyes ételhez a nevet is?

Külön táblába a Fajta: (fajtakod, fajtanev)
Az étel táblában pedig csak a fajta kód szerepeljen.

Aki hülye, haljon meg!

Az étel nevét nem tárolod sehol?

Aki hülye, haljon meg!

Sorry az kimaradt.
Értlemszerűen az ételnév az Étel táblába kerül.
A fajtaszám, fajtakód kavarást még mindíg nem értem.

( 2b || !2b ) az itt a kérdés...

A fajtaszám, fajtakód kavarást még mindíg nem értem.

Pedig a #17-ben ott a válasz:

fajta(/Fajtakód/,fajtanév) táblát készítesz, innentől az ételeknél már csak a fajtakódot kell tárolni, a fajta nevét nem -> spórolsz egy csómó helyet, varchar helyett elég egy numerikus mező. (Ugye normálformák, függőség -> a fajtanév nem függ mástól, csak a fajtakódtól, ergo semmi keresnivalója az étel táblában)

''Egy bármilyen Annál jobb hogy új és Fényképezős!'' by Rolabola

höhö... kaptam rá egy kettest.... LOL.. de még mindig nem magyarázta el... aszonta 5 perces meló....
az egészről csináltunk egy példát, amit 3 órán kersztül normalizáltunk....
aztán mindig odaírtuk hogy pl.: ''3. normál formában van, mert: 2. normál formában van, és ... '' szoval értem? de hogy értem....
egy emberke tudta 5ösre megcsinálni.... majd holnap odadja a munkáját.... ö is aszem valami ilyesmit csinált mint amit ti kihoztatok belölle...

szoval köszi mindent... jövő héten kapunk megint ilyen hülye feladatot...
csak nem értem.... ezzel párhuzamossan nem kellene mondjuk az acces-t venni, minimum??? mert elég morbid, hogy adatbázist csinálunk... lapon... elképzelni sem tudjuk mi a szar ez...

na köszi....

üdv: ReJim

</end.?>

Pár mestert ért az a megtiszteltetés, hogy felkérjem egy kis segítségre (MA)...
(Postaláda/Friss)
Aki jelentkezne a karitatív célra, megteheti még...
(Levél frissülés 20h-kor)


[Szerkesztve]

Csak tisztán

SQL az Access-hez???

Ma már szinte minden adatbázis kezeléssel összefügg az SQL.

Adatbáziskezeléshez két dolgot kell megtanulni jól. A normál formára hozást és az SQL-t. A normál formára hozásnál inkább a lényegre kell koncentrálni és nem arra, hogy minél magasabb szinten legyen. Van amikor az alacsonyabb normál forma a nyerő. Az SQL az a ''nyelv'', amit kifejezetten adatbázisok birizgálására hoztak létre, és azon belül is a lekérdezések támogatására. Jó kis nyelv. A legtöbb programozási nyelv ma már nativan támogatja a használatát.

Még egy jó tanács: Az algoritmus a lényeg és nem az implementáció. Ha ezt betartod, könnyen fogsz programozni.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

Tudnál segíteni egy példában?
(Fontos és sürgős lenne!)

Engedelmeddel küldök e-mailt!

Csak tisztán

Senki nem szeretne segíteni egy picit?

Csak tisztán

Eben a könyvben:
Devecz F (...) Irány az ECDL!; Nemzeti Tankönyvkiadó, Budapest; 2004
szépen le van írva.

Fej! Tor! Potroh!

Jo konyvek:
alapokra SQL temaban: ComputerBooks SQL Kezikonyv
alapok es nemi tervezes: IDG Az adatbazistervezes alapjai es titkai (Halassy Bela)

ezek mar verprofik:
Panen kiado konyvei:
- Adatbazisrendszerek alapvetes Jeffrey d. Ullman es Jannifer Widom
- Adatbazisrendszerek megvalositasa Hector Garcia-Molina es Jeffrey d. Ullman es Jannifer Widom

A normal formara hozashoz egy kis adalek a lenyege, hogy egy adathalmazban lehetosegszerint ne legyen ismetlodes. Pld nem normalizalhatok tovabb olyan tablak amikben egy bizonyos tenyrol, targyrol, stb tarolunk adatokat amik azt jellemzik.
PL szemely eseteben (nev, anyjaneve, szul datum, helye, hajszin, szemszin)

A normalizalt tablakat osszekotik a kapcsolatok vannak olyan tablak amik lehetove teszik a tobbes kapcsolatot.
Pl szemely es vegzetseg ahol a szemelytabla egyedi azonositoja (szemelyiszam pld) sokszor szerepelhet melette meg a vegzetseg tabla azonositoja is.

A normalizalas legjobb megertese pl a kartotek rendszer es nyilvantarto lapok megtekitese ahol a fejlec egy normal tabla a felsorolas resze meg a kapcsolati tabla.

Szükségem volna nekem is egy kis segítségre. Valaki emberi nyelven el tudná magyarázni, hogy mi a különbség a 3NF és a BCNF között?

3NF:
Egy R séma 3NF-ben van, ha 2NF teljesül és a nem kulcs attribútumok nem függnek tranzitíven a kulcstól.

BCNF (általánosított 3NF):
Egy R séma akkor van BCNF-ben, ha 2NF teljesül és funkcionális függőség csak jelölt kulcsból (olyan mező, mely egyértelműen meghatározza a többi mező értékét, egyértelműen azonosítja a rekord-előfordulást) indul ki.

No most szépek, meg jók ezek a definíciók, de nincsen arra vonatkozóan valami ökölszabály, hogy pl mikor egyezik meg a 3NF meg a BCNF? Mert pl az 1NF akkor egyezik meg a 2NF-fel, ha az 1NF-ben a kulcs nem összetett. Már ha jól tudom.

1NF: Legyen kulcs mező (pl: A a kulcs és őt senki nem határozza meg)

2NF: Ne legyen részkulcsból kiindukó függőség (pl: AB meghatározza C-t, D-t, de ha pl: csak A határozna meg valamit, pl C-t, akkor az már részkulcsból indul holott AB a kulcs)

3NF: Nem kulcs mezőből, nem kulcs mezőbe nincs függőség (pl: A kulcs, A meghatározza B és B meghatározza C-t. Ez így nem jó, mert B nem kulcs, de mégis van belőle függőség)

BCNF: Minden függőség jelöl kulcsból indul ki

From Miskolc by emberi nyelv

[Szerkesztve]

No, megmondom őszintén vártam már egy bennfentest is a témában. Hogy én se menjek messzire voilá a példa: [link] /gondolom ismerős /

Itt az utolsó példa:
6. Normalizálja az alábbi sémát BCNF-ig: R(A,B,C,D,E) ahol A → B, A → C, B → A, B → C, C → D, D → E.

Miért van az, hogy a BCNF-nél az R1-es reláció megengedi, hogy A benne legyen? Ugyanis a 3NF-nél tök tiszta, hogy nem lehet benne, hiszen A → B, azaz tranzitív függőség lenne egy reláción belül.

Ha tisztán a BCNF definícióját vesszük, akkor a 4 relációból álló 3NF-es formulára is teljesül. Nem? Hisz' ott is Minden függőség jelöl kulcsból indul ki.

Szóval azt akarom én valahogy beleverni a kis fejembe, hogy mi a különbség a 3NF meg a BCNF között. Ugyanis nem nagyon érzem. Mentségemre legyen szólva, hogy a linken is, és a könyv példái között is (ami egyébként feltűnően hasonló) ez az egyetlen egy példa van, ahol a 3NF különbözik a BCNF-től.

Az egyébként véletlen, hogy ennél a példánál az 1NF=2NF-fel (mivel a kulcs nem összetett), és így a 3NF != BCNF-fel?
Mert a többi példában mind összetett kulcs van, és ott egyenlő a 3-as és a Boyce-Codd normál forma.

[Szerkesztve]

[Szerkesztve]

Hali!

Nos! Az van, hogy C -t A és B is egyértelműen meg tudja határozni, ezért BCNF-ben eltekintük az A -> C -től és csak B -> C -t vesszük figyelembe. Így nincs jelöletlen kulcson kívüli függőség, viszont B -> A és B - > C-t fantasztikusan teljesíti a BCNF feltételeit.

Köszi! Kezdem kapizsgálni.

Lenne még 1-2 kérdésem relációs algebra ügyben, ha nem gond. Mi a különbség a az inner join és a szelekciós join között?

Itt van egy kis példa: [link]. Mennyi hiba van benne?

Szerintetek mit jelent az adatbázisnál a kapcsolat foka?

Üdv, egy adatbázis fizikai eléréi idejét kell kiszámolnom.
A képletek megvannak, az kindulási adatokat ki tudtam számolni, csak azzal nem tudok mit kezdeni, hogy a rekordok 80 %-an vannak feltöltve!
Egyszerűen csak meg kell szorozni 0,8 -al a kapott értéket?
Vagy például szekvecionális művelet esetén a művelet a rekord üres rsézén is végbemegy?

Fej! Tor! Potroh!

Sziasztok!
Tudna valaki ebben segíteni?
Van a következő adatbázis séma:
hallgató <HALLGATÓ_NEVE, HALLGATÓ_CÍME, KEDVEZMÉNY, TANFOLYAM_NYELVE, TANFOLYAM_SZINTJE, TANFOLYAM_ÁRA, TANFOLYAM_ÓRASZÁMA, TANÁR_NÉV, TANÁR_SZÁMA, TELEPHELY_NEVE, TELEPHELY_CÍME, TELEPHELY_TEL>
Ezt kellene BCNF alakra hozni.

[ Szerkesztve ]

1-es golf, 2-es golf, ... (Bëlga)