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
Reklama

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
85 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
3485 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
85 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
85 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
3485 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
85 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
85 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
85 příspěvků
12. 4. 2019   #10
-
0
-
Nahlásit jako SPAM
IP: 89.203.150.–
Jano
~ Anonymní uživatel
85 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
85 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
85 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
85 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
85 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
85 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
85 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
3485 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
85 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
85 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
85 příspěvků
18. 4. 2019   #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
19. 4. 2019   #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
19. 4. 2019   #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
19. 4. 2019   #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
85 příspěvků
19. 4. 2019   #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.–
MilanL+1
Věrný člen
20. 4. 2019   #33
-
0
-

#32 Jano
ty datumy jsou planost toho modelu u toho člověka. Když je tam budeš mít není problém změnit člověku režm ze dne na den.

Ty definice po dnech bych úplně nezavrhoval, ale hodí se spíš pro nepravidelný režim, nebo směny pokud tu docházku chceš použít zároveň jako plánovač směn.

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

#33 MilanL
Když je tam budeš mít není problém změnit člověku režm ze dne na den.

To jde i bez toho datumu změnit režim, ne?

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

#34 Jano
ano, ale pokud ho změníš v průběhu sledovaného období, tak bez datumu tam budeš mít jen nový model ikdyž na začátku docházel podle starého a můžou ti pak vzniknout nesrovnalosti.

Například po nemoci se změní režim na zkrácenou pracovní dobu a když se budeš chtít kouknout na docházku před nemocí, tak ti to bude počítat přesčasy vzhledem k tomu novému režimu. Když uděláš křížovou tabulku Osoba-Model s datumem tak to pak jednoduše zpracuješ podle režimů v každém tom samostatném období.

Nahlásit jako SPAM
IP: 185.112.167.–
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: 0 registrovaných, 7 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ý