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

-

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)

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

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 :)

#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.
 

#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í?

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í?           

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.

#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í. 

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

Mám toto schéma dobře (viz. obrázek)?

Připojen obrázek.

Připojen obrázek.

Oprava předchozího obrázku

#11 Jano
Ne.

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

#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.

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

#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.

#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?

#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..

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

#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ří.

#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? 

#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.

"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

#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?

#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. 
 

#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.

#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.

#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)?

#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

#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.

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

#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? 

#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.

#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?

#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í.