[Database] Hulp bij normalisatie

[eatualive]

Beste Tweakers,

Ik ben bezig met het normaliseren van mijn database. Dit gaat tot op zekere hoogte goed.
Toch vroeg ik me af of jullie kunnen controleren of dat dit correct is.
Zelden maak ik databases en voordat ik mijn programma ga schrijven wil ik zeker zijn dat ik geen grote fouten erin heb zitten.

Hieronder de database met relaties zoals deze nu in elkaar zit.



Beschrijving:

Het programma dat ik ga schrijven moet overzichten generen voor een productie lijn.
Data die ik log:

- Product tellers
- Tijd dat een machine in een bepaalde stop zit (RT als naamgeving in database)
- Teller hoevaak hij switched tussen verschillende stops of productie (Cnt als naamgeving in database)

- Een fabriek kan meerdere productie lijnen hebben.
- Een productie lijn kan niet 2x dezelfde machine bevatten
- Er zijn altijd 3 shifts per dag(Na elke shift worden timers en counter op 0 gezet)
- Elke shift is een *.csv bestand die geimporteerd word(Dus 3 files per dag)


Tabel T_Data: Bevat alle data waarmee gerekend word door heel het programma. Zoals dag, maand of jaar overzichten.

Tabel T_Machine: Bevat alle machine die bestaan(Machine is afkortings naam en Machine Name is volledige naam)

Tabel T_Shift: Om te voorkomen dat van elke shift telkens alle start datums en tijden in t_data komen heb ik hier een tabel van gemakt. Op deze manier kan ik deze ook weer koppel aan een Lijn of aan de opsalg locatie van de *CSV bestanden.

Tabel T_Files: Opslag locatie bestanden

Tabel T_Line: Lijn aanwezig in fabriek en welke machine wordt gebruikt voor rendement productie lijn.

T_Machine_Chart: Dit is nodig om een goede grafiek met een quary te generen maar kun je even negeren.

Nu denk ik dat het bovenstaande wel klopt. Alleen het probleem is dat als er 2 productie lijnen zijn dat deze uit verschillende machines kunnen bestaan.
En mocht je dezelfde machine hebben dan kunnen ze in andere units rekenen(Pallets of bottles).
Dit alles defineer ik 1x aan het begin van het project. Maar als dit in de toekomst aangepast wordt moet dit aanpasbaar zijn.

Ik heb dus een koppel table gemaakt:
Tabel T_Active: Hier geeft ik aan welke machiens lijn 1 heeft en welke tellers hebben en of zel bottles, trays of pallets tellen.

Heel verhaal, maar ik weet niet of dat deze T_Active als koppel tabel slim is. Zouden jullie dit zo doen of hebben jullie een manier om deze koppel tabel te vermijden.
Graag hoor ik feedback of dit zo verstandig is en anders wat beter is.

[BikkelZ]

Als ik zo'n tabel met van lekker afgekorte namen zou tegen komen als ik jouw applicatie over zou moeten nemen zou ik al gelijk sjachrijnig worden. Kan dat niet gewoon uitgeschreven worden?

Ik vind die t_Data tabel (prefix zou ik ook weglaten tenzij je een database moet delen met meerdere applicaties) er uit zien alsof hij nog verder genormaliseerd kan worden, want je herhaalt een stuk of acht keer zo'n drieletteracroniem met twee andere afkortingen.

Stel dat je een negende wil toevoegen?

Liever daar een extra steun- en koppeltabel bij zetten waarin je en de voluit geschreven naam en het drieletteracroniem kunt gebruiken wat ze misschien op een gegeven moment zijn gaan gebruiken binnen het bedrijf om een of andere reden.

Dus table DrieLetterAcroniemType

- id INT
- code CHAR(3)
- naam NVARCHAR(100)

DrieLetterAcroniemValue

- dataId INT -- composite key
- drieLetterAcroniemTypeId INT -- composite key
- count INT
- time INT (?)

Eigenlijk zou ik eerder nog alle stops en starts loggen per machine per shift, en het er dan met een query uit trekken. Dan werk je gewoon met DateTimes in plaats van een of andere generieke tijdtellervariabele. Een count heb je zo gedaan.

[eatualive]

De afkortingen gebruik ik omdat we deze intern door alle programma's gebruiken. Een negende zou zo toegevoegd kunnen worden al zal dat waarschijnlijk nooit gebeuren.

Deze afkortingen(In tabel T_Data) zijn bijna complete zinnen. Bijv. BMS is 'Backup main stream'.
Dus BMS_Cnt en BMS_RT staan voor:

Backup main stream runtime
Backup main stream counter

De runtime is exact de tijd dat de machine in deze stop verkeerde. Ik ben het met je eens dat als ik alle start en stop tijden log dat ik dan de counter kan elimineren. Echter wij zijn afhankelijk van een systeem dat communiceerd met de machines. En dit systeem levert de tijd in een decimaal getal. Bijv. 6,5 = 6 uur en 30 minuten. Als ik alle starts en stops wil loggen moet het systeem compleet herschreven worden dat communiceerd met de machines.

Dit kan iets voor de toekomst zijn al denk ik eraan om in de toekomst data direct te loggen in de database
zonder CSV file.

Maar ik geef je gelijk, van de afkorting wordt je niet heel vrolijk van.

[ Voor 3% gewijzigd door eatualive op 18-06-2012 16:15 ]

[eatualive]

Als iemand nog meer punten heeft die anders zouden moeten dan hoor ik het graag.

[Boss]

Ik zie nog ergens een spatie in een veldnaam staan. Dat zou ik niet doen.
En waarom gebruik je bij machine een afkorting als PK en niet gewoon een (numeriek) ID zoals bij de andere velden? Ook al is dat nodig omdat er misschien uit een ander systeem een afkorting komt, dan zou ik nog een apart veld toevoegen daarvoor.

Zelfde voor Line en Unit. Gewoon consequent in zijn. Niets vervelender dan een database waar geen systematiek zit in de (naamgeving van) de tabellen en velden.

[eatualive]

Mja daar heb je een punt, is me helemaal niet opgevallen tot nu. Dat is zeker iets dat ik ga aanpassen.

Maar ik had het gedaan vanuit de gedachte, de naam/afkorting is uniek en kan hij als PK fungeren. Maar je zou dit dus nog steeds met een ID doen?

[ Voor 41% gewijzigd door eatualive op 22-06-2012 08:37 ]

[Boss]

Als je wat gaat rondzoeken over PKs dan kom je doorgaans twee meningen tegen:
De ene is dat je prima een unieke eigenschap van het object kan gebruiken, zolang deze maar gegarandeerd uniek is. Bijvoorbeeld het nummerbord van een auto of een productcode.

De andere mening is dat er altijd wel uitzonderingen zullen zijn op die regel en dat je daarom altijd een betekenisloze ID moet hebben, waarvoor een oplopende integer of GUID zeer geschikt zijn.

Ik ben meer aanhanger van de 2e :-) Gewoon een auto-inc integer veld. Ook voor de naamgeving is het altijd wel handig om daar 'ID' in voor te laten komen: Machine.ID of Machine.MachineID wordt het dan.

[eatualive]

Ok, bedankt, ga hetzelfde doen .

[Afvalzak]

Moet Production_machine in t_line dan ook niet gekoppeld worden met machine of zijn dat andere machines?
Nu heb je natuurlijk de kans dat er 10 keer dezelfde production machine toegevoegd wordt.

[eatualive]

Per lijn is er 1 machine die de output van de lijn bepaald. Dit is de laatste machine in de lijn die een counter heeft. De naam van deze machine sla ik daar in op.

De tabel kan er ongeveer zo uit zien:

Lijn | actief | production machine

1 | Ja | Inpakker
2 | Ja | Inpakker
3 | Ja | Vuller

Nu zit ik te twijfelen of hij wel op die plek thuishoord. Koppeltabel t_Machines geeft de relatie aan welke machine in welke lijn zit en of dat deze een counter heeft. Als alle voorwaarden matchen kan die machine gebruikt worden als 'Production_Machine'.

[ Voor 28% gewijzigd door eatualive op 22-06-2012 14:28 ]