Normalizace tabulek databáze konrola schématu – MySQL – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

Normalizace tabulek databáze konrola schématu – MySQL – Fórum – Programujte.comNormalizace tabulek databáze konrola schématu – MySQL – Fórum – Programujte.com

 
Hledat
Moderní platforma pro vytvoření vašeho nového webu – Wix.com.
Nyní už můžete mít web zdarma.
Vybavení pro Laser Game
Spuštěn Filmový magazín
Laser Game Brno
Laser Game Ostrava

Jano
~ Anonymní uživatel
80 příspěvků
8. 4. 2019   #1
-
0
-

-

Dobrý pozdní večer. Prosím o zkouknutí těchto tabulek databáze v textové podobě, zda odpovídají správné normalizaci do 3. Normální datové formy a nemám tam nějaké chyby, nejsem si jist, že je to zcela správně.

# = Primary KEY     ,        FK = Cizí klíč

Tabulky níže s atributy v závorkách

person (#id_person, first name, last name, date of birth, telephone, FK id_work)

person_reason (id, #id_person, #id_reason, date & time)


reason (#id_reason, name)


expected work time (#id_work, date_and_time from, date_and_time_to, id_person, day of week)

Nahlásit jako SPAM
IP: 89.203.150.–
Kit+14
Guru
9. 4. 2019   #2
-
0
-

#1 Jano
Osoba smí mít přiřazenu pouze jednu práci?

Nahlásit jako SPAM
IP: 81.19.3.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
peter
~ Anonymní uživatel
3474 příspěvků
9. 4. 2019   #3
-
0
-

Na Kita bacha, je pekne zaludny! :)

Propojovaci tabulku mas definovanou jako
person_reason (id, #id_person, #id_reason, date & time)
# = Primary KEY

Primary key znamena, ze je to hlavni klic tabulky, unikatni (unique).
Jako primary key si oznacil id_person a id_reason.
Coz je samo o sobe nesmysl, protoze primary key je jediny. Nemuzou byt dva.
A potom je tu Kitova poznamka. Pokud by teda oba klice nebyly primary, ale alespon unique, aby to mohlo fungovat, ze jo. Tak by z toho zapisu plynulo, ze v tabulce smi byt pouze 1 zaznam pro
 id_person=123, id_reason=cislo
 id_person=123, id_reason=jine_cislo - tohle by ti hlasilo chybu DUPLICATE KEY  id_person
a nebo kombinace s tim druhym klicem
 id_person=cislo, id_reason=123
 id_person=jine_cislo, id_reason=123 - tohle by ti hlasilo chybu DUPLICATE KEY  id_reason

Jinymi slovy, ze definice te tabulky je spatne. Ale myslel jsi to dobre :)

Nahlásit jako SPAM
IP: 2001:718:2601:258:4dbc:3838:5a25:f2e0...–
Kit+14
Guru
9. 4. 2019   #4
-
0
-

#3 peter
Primární klíč může být složený, pokud se jedná například o vazební tabulku, kde se používají jen cizí klíče, tedy

person_reason (#id_person, #id_reason, date & time)

Ovšem to asi nebude tento případ, soudě podle časového razítka.
 

Nahlásit jako SPAM
IP: 81.19.3.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Jano
~ Anonymní uživatel
80 příspěvků
9. 4. 2019   #5
-
0
-

#4 Kit
Ano, myslel jsem složený klíč. Mám to dobře.

A tím id_work jsem myslel id_work_time.

Je to potom také dobře, nebo mi tam ještě něco chybí?

Nahlásit jako SPAM
IP: 195.113.101.–
Jano
~ Anonymní uživatel
80 příspěvků
9. 4. 2019   #6
-
0
-

OPRAVA K MINULÉMU PŘÍSPĚVKU:

Ano, myslel jsem složený klíč. Mám to dobře?

A tím id_work jsem myslel id_work_time.

Je to potom také dobře, nebo mi tam ještě něco chybí?           

Nahlásit jako SPAM
IP: 89.203.150.–
peter
~ Anonymní uživatel
3474 příspěvků
10. 4. 2019   #7
-
0
-

Ne, mas to spatne.A nebo nechapes rozdil mezi pojmy tabulka, klic, primarni klic, slozeny klic. To je pak tezke ti vysvetlit, ze to mas spatne.

Nahlásit jako SPAM
IP: 2001:718:2601:258:4dbc:3838:5a25:f2e0...–
Jano
~ Anonymní uživatel
80 příspěvků
10. 4. 2019   #8
-
0
-

#7 peter

Myslel jsem složený primární klíč. Jinak když řeknu jenom, že je to klíč tak je tím míněno cizí klíč či ještě něco jiného. 

Rád se poučím v čem dělám chyby a rád bych prosím poprosil o rady, vysvětlení. 

Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
12. 4. 2019   #9
-
0
-

#8 peter
Doplním, 1 expected work time může mít více person.

Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
12. 4. 2019   #10
-
0
-
Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
12. 4. 2019   #11
-
0
-
Nahlásit jako SPAM
IP: 89.203.150.–
Kit+14
Guru
12. 4. 2019   #12
-
0
-
Nahlásit jako SPAM
IP: 37.188.187.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Jano
~ Anonymní uživatel
80 příspěvků
12. 4. 2019   #13
-
0
-

#12 Kit
Prosím o vysvětlení, kde dělám chybu. V tabulce Entry nebo v Expected_Work_Time?

Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
16. 4. 2019   #14
-
0
-

#13 Jano

Jde u vazební tabulky Entry trojitý primární klíč - ale jaký? {id, id_person, id_reason} nebo {id_person, id_reason, date_time}? Abych mohl mít u osoby 1 s důvodem 1 mít více dnů (date and time) průchodů a ne pouze jenom jediný den.

Nahlásit jako SPAM
IP: 89.203.150.–
Kit+14
Guru
16. 4. 2019   #15
-
0
-

#14 Jano
Konečně jsi napsal, k čemu to potřebuješ. Entry není vazební tabulkou, primárním klíčem bude pouze ID.

Nahlásit jako SPAM
IP: 46.174.34.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Jano
~ Anonymní uživatel
80 příspěvků
16. 4. 2019   #16
-
0
-

#15 Kit
Radši to ještě doplním (promiň asi jsem to napsal špatně, mělo to být například).

- osoba 1 důvod 1, potřebuji i důvod 2, 4, 5, atd. (každý reason v určitý date and time)

- osoba 1 důvod 1 v určitý dat. a čas den 2

- osoba 2 důvod 1 v dat. a čas den 1

- osoba 2 důvod 2 v dat. a čas  den 1

- osoba 2 důvod 1 v dat. a a čas den 2 

A pak si podle mě myslím budu možná potřebovat trojitý PK nebo jaký v Entry (vazební tabulka). Nevím. Prosím o radu. Jinak díky za předchozí odpovědi.

Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
17. 4. 2019   #17
-
0
-

#16 Jano
Když bych měl trojitý prim. klíč v tomhle případě a ne jenom ID, šlo by to taky nebo by vznikaly nějaké kraviny či něco jiného?

Nahlásit jako SPAM
IP: 89.203.150.–
MilanL+1
Věrný člen
17. 4. 2019   #18
-
0
-

#17 Jano
no od začátku a stále nějak nechápu k čemu to má vlastně sloužit, ale je několik variant jak to můžeš nadefinovat.

Pokud to má být kontrola vstupů pro návštěvníky tak nemůžeš použít primární klíč na ID_person+ID_Reason, primární klíč by pak mělo být id a na dvojici ID_Person + ID_Reason udělán index, případně jiná kombinace podle toho, jak to budeš potřebovat zpracovávat, indexovat se pak dá extra. Další věc Work time by měl být možná taky v entry jinak by stejnej člověk nemohl přijít víckrát za různým účelem, opravdu záleží k čemu ta DB má sloužit zatím jsem to nezjistil..

Nahlásit jako SPAM
IP: 185.112.167.–
Jano
~ Anonymní uživatel
80 příspěvků
17. 4. 2019   #19
-
0
-

#18 MilanL
K evidence docházky osob - příchodů a odchodů.

Nahlásit jako SPAM
IP: 89.203.150.–
Kit+14
Guru
17. 4. 2019   #20
-
0
-

#16 Jano
Použití jednoduchého primárního klíče ID zcela splňuje to, co od toho očekáváš. Další sloupce do něj nepatří.

Nahlásit jako SPAM
IP: 95.82.190.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Jano
~ Anonymní uživatel
80 příspěvků
17. 4. 2019   #21
-
0
-

#20 Kit
Zajímavé, díky.

Jenom, můžu prosit ještě o vysvětlení, jak to, že i když je mezi těmi dvěma tabulkami ta prostřední tabulka (propojovací, vazební), tak existuje na to nějaké pravidlo / standard, že se z vazební tabulky přestává být vazební tabulka se složeným primární klíčem a může se použít jenom id propojovací tabulky?  Tohle jde vždycky i v jiném případě udělat, že se složený prim. klíč vazební tabulky nahradí id prim. klíč vazební (propojovací) tabulky? 

Nahlásit jako SPAM
IP: 89.203.150.–
Kit+14
Guru
17. 4. 2019   #22
-
0
-

#21 Jano
Jednoduše se nejedná o vazební tabulku. Nesměla by mít ID, date_time ani jiný sloupec, než ty cizí klíče.

Nahlásit jako SPAM
IP: 95.82.190.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
peter
~ Anonymní uživatel
3474 příspěvků
18. 4. 2019   #23
-
0
-

"K evidence docházky osob - příchodů a odchodů."
Ja bych to resil takto:

person: id_person, data (= nejake dalsi sloupce)
worktime: id_work_time, data
person_worktime: id_pw, id_person, id_work_time
reason: id_reason, data
person_entry: id_pe, id_entry, id_person, data

Nazev tab. bych volil person_ proto, abys vedel, ze to ma nejakou vazbu na persona a je pro tebe nejdulezitejsi ze vsech tech vazeb. A prijde mi to prehlednejsi.

Worktime bych dal zvlast, oddelil od osobnich dat.

U vazebnich tabulech bych urcite nechal nejake id pro mazani radku (DELETE FROM entry WHERE id=123). Dokonce bych ho mozna pojmenoval jenom id, protoze nema jinak vyznam.
person_worktime: id, id_person, id_work_time
person_entry: id, id_entry, id_person, data

Nahlásit jako SPAM
IP: 2001:718:2601:258:4dbc:3838:5a25:f2e0...–
Jano
~ Anonymní uživatel
80 příspěvků
18. 4. 2019   #24
-
0
-

#23 peter
U tvé příspěvku peter, tak u person_entry, nemělo by být spíše id_reason místo id_entry? Když id_entry je defakto to id jenom?

Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
80 příspěvků
18. 4. 2019   #25
-
0
-

#22 Kit
Kite můžu ještě poprosit o radu. 
Na relaci 1 : N     tabulka Expected k tabulka Person. Na tomto mi nesedí, když budu mít např. datum_a_cas    1.1.2019 8:00 a to bude přiřazeno N osobám, tak už 2.1.2019 8:00 nemůžu přiřadit té samé osobě a z toho vyplívá, že by mohla pracovat jenom jeden den daná osoba.         Je to tak, nebo to chápu špatně?

Prosím o návrh jak to vyřešit. 
 

Nahlásit jako SPAM
IP: 89.203.150.–
MilanL+1
Věrný člen
18. 4. 2019   #26
-
0
-

#25 Jano
expected tabulka je jen definice pracovní doby? v tom případě bys na to měl mít křížovou tabulku jako na Entry, pracovní doba se může měnit např v případě změny pracovní  pozice případně různé zjiné změny

takže by měla být tabulka, kde bude pracovník provázán s definicí pracovní doby Person_WTime: ID, ID_Person, ID_expected_time, Begin_date, End_date.

Nahlásit jako SPAM
IP: 185.112.167.–
MilanL+1
Věrný člen
18. 4. 2019   #27
-
0
-

#26 MilanL

ta tabulka s pracovní dobou po dnech je ale trošku nesmysl, hodí se možná tak pro návštěvníky nebo externí prácovníky.

Pro kmenové zaměstnance se to řeší přes pracovní modely, např admini-strativní pracovník = pracovní dny - svátky 8:00-16.30, někdy se to ještě řeší přes volnou část, kdy je určeno 6,5h jádro pracovní doby např. 8:00-14:30 a zbylé 2h volně tzn. pracovník může přijít už v 6:00 nebo odejít až v 16:30 při dodržení druhého času dle jádra. U definice směn je několik možností, bud se nadefinuje model směny Ranní, Noční a program to  pak indikuje na základě časů příchodu a odchodu, Nebo se nadefinujou přímo plány směn a pracovníkovi se přidělý daný plán.

Tohle vše je třeba promyslet na začátku v rámci té normalizace, co vše od toho chceš, jak to rozdělit a dát do tabulek.

Nahlásit jako SPAM
IP: 185.112.167.–
Jano
~ Anonymní uživatel
80 příspěvků
Včera   #28
-
0
-

#26 MilanL

Ppprosím tě, o zodpovězení dotazů, jsem to všecko nepochopil.

Person_WTime: ID, ID_Person, ID_expected_time, Begin_date, End_date.

Není tady zbytečné ty sloupečky to begin_date a end_date, když už je to v tom Expected Work Time?


U definice směn je několik možností, bud se nadefinuje model směny Ranní, Noční a program to  pak indikuje na základě časů příchodu a odchodu.                                                                                                    Nebo se nadefinujou přímo plány směn a pracovníkovi se přidělý daný plán 1 plán vždy pro více pracovníků.

Model, Modely a plány tím se myslí 1 tabulka?

A tím indikuje, jako že do tabulky Ranní se vloží záznam o příchodu daného zaměstnance ráno automaticky dle času příchodu?                   

A plány směn přímo - 1 tabulka s časy (datum by tam nešel, protože by ta časová doba pak platila pro jeden den a druhý den ranní by pak taky nešla přiřadit té samé osobě, že jo/ne)?

Nahlásit jako SPAM
IP: 89.203.150.–
MilanL+1
Věrný člen
Včera   #29
-
0
-

#28 Jano
Person_WTime, může být i bez datumů, pokud tedy v expected budeš mít datum čas od čas do , pak uděláš křížovou tabulku jako je Entry tzn ID, ID_Person, ID_ExcTime

vpodstatě je to to co ti psal Peter v #23

Nahlásit jako SPAM
IP: 185.112.167.–
MilanL+1
Věrný člen
Včera   #30
-
0
-

#29 MilanL
já ti radím podle toho jak jsme to měli ve firmě my.

1. tabulka byly pracovní časy, pro denní zaměstnance Jádro  + limity (6-[8-14]-17), dále pak 12h Den a noc pevně 6-18 a 18-6

2. tabulka pracovní model denní zaměstnanec měl tu 1 definici, Vrátní měli navázané obě ty 12h definice 

počítání docházky pak měl na atarosti program, který vzal data průchodů a promítl je na ten pracovní model zaměstnance.

Nahlásit jako SPAM
IP: 185.112.167.–
MilanL+1
Věrný člen
Včera   #31
-
0
-

#30 MilanL
ten způsob co chceš použít se hodí spíš pro plánování nepravidelných směn.

Nahlásit jako SPAM
IP: 185.112.167.–
Jano
~ Anonymní uživatel
80 příspěvků
Včera   #32
-
0
-

#26 MilanL
Takže, kdybych měl tabulku definici pracovních časů a 1 konkrétní čas od do, by byl přiřazen N zaměstnancům tak nepotřebuji tu křížovou tabulku? Akorát nevím jestli tam mám uvést to Begin_date, End_date? 

Nahlásit jako SPAM
IP: 89.203.150.–
Zjistit počet nových příspěvků

Přidej příspěvek

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 1 registrovaný, 23 hostů

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032019 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý