Database benamingen verslag

[demonic]

Mijn afstudeerverslag is in ontwikkeling. ik ben een Dashboard aan het maken om de prestaties van een fabriek inzichtelijk te maken.
Een onderdeel van mijn opdracht/project is een database ontwerp maken, bij het maken van het verslag gebruik ik de termen "Brede tabel en smalle tabel". en als feedback die ik vervolgens kreeg van mijn begeleider is dat dat niet echt goede termen zijn.

ik heb in mijn ontwerp een aantal tabellen zitten.
Tabel 1, bevat gegevens mbt hoeveel tijd je geproduceerd hebt, en hoeveel daarvan stilstand is geweest en door welke machine.

ID	StartDatum	EindDatum	Lijn	Productie	geen orders	vulmachine	verpakkingsmachine	palletizer.	en nog meer
autoincrement	startdatum	einddatum	lijn nummer	hoeveel seconden je productie hebt gedraaid	hoeveel seconden je hebt stilgestaan omdat er geen orders waren	hoeveel seconden je stil heb gestaan vanwege storing aan de vulmachine	hoeveel seconden je stil heb gestaan vanwege storing aan de Verpakkingsmachine	hoeveel seconden je stil heb gestaan vanwege storing aan de Palletizer	en deze gaat door tot ongeveer 20 kolummen (vanaf productie geteld)

Tabel 2: hierin worden indicators opgeslagen, welke verderop in stadium worden gebruikt in dashboarding software

Tabel 2:

ID	StartDatum	EindDatum	Lijn	Type	Val1	Val2
autoincrement	Startdatum	eind datum	lijn nummer	Het type indicator. bv. beschikbaarheids-,prestatie- of kwaliteitsgraad	val1 en val2 zijn de waardes voor en na de deelstreep, zodat hier een dashboard omgeving een percentage van kan worden berekend.

Hierbij is tabel 1 dus een hele brede tabel, waarbij tabel 2 een relatief smalle tabel is.
Ik heb zelf naar normalisatie zitten kijken, maar beide bevinden zich op de eerste normaalvorm.
(Ik maak bewust geen gebruik van hoger nomalisatie vormen. Maar dat is misschien een discussie voor een ander moment )

(op de wikipedia pagina's worden ze vernoemd als brede en smalle tabellen... )
Wikipedia: Table (information)


TL;DR:
Ik heb een brede tabel, en een smalle/lange tabel. Wat zouden meer professioneler begrippen hiervoor zijn.

[Matthijs B]

Wij noemen het tweede type tabel hier wel eens key-value tabellen. Misschien dat je begeleider daar naar op zoek is?

[Dido]

Veelal geef je een tabel een naam die beschrijft wat erin zit. Die eerste tabel lijkt statistieken (of uitvalstatistieken) te bevatten, bijvoorbeeld.

Dat ding "brede tabel" noemen is hetzelfde als in de supermarkt zoeken naar een halfhoog, rond pak als je beschuiten zoekt. Best kans dat je ze vindt, maar niet de handigste manier.

[demonic]

Dido schreef op vrijdag 9 december 2016 @ 15:31:
Veelal geef je een tabel een naam die beschrijft wat erin zit. Die eerste tabel lijkt statistieken (of uitvalstatistieken) te bevatten, bijvoorbeeld.

Dat ding "brede tabel" noemen is hetzelfde als in de supermarkt zoeken naar een halfhoog, rond pak als je beschuiten zoekt. Best kans dat je ze vindt, maar niet de handigste manier.

Het gaat mij niet om de benamingen in de database zelf, deze zijn bv, tbl_OEE & tbl_OEE_Targets.
Ik probeer alleen te omschrijven in mijn verslag waarom de ene een brede tabel is, en de tweede een smalle tabel is.

en die 2 benamingen zijn niet correct genoeg volgens mij docent. hij suggereerde me naar normalisatie te kijken voor termen. Maar beide tabellen zijn de eerste normaal vorm, dus die termen vallen ook al af.

[DaHell66]

Wat Dido zegt.. en misschien is de eerste tabel 'Wide" te noemen, maar de tweede niet echt "Narrow", Beschrijf de tabellen zoals ze zijn.

Verder kan ik nog opmerkingen maken over de naamgeving en conventies (of camelcase of Pascalcase) , maar dat doe ik nu even niet en in godsnaam normaliseer die handel verder!

[DaHell66]

demonic schreef op vrijdag 9 december 2016 @ 15:33:
[...]


Het gaat mij niet om de benamingen in de database zelf, deze zijn bv, tbl_OEE & tbl_OEE_Targets.
Ik probeer alleen te omschrijven in mijn verslag waarom de ene een brede tabel is, en de tweede een smalle tabel is.

en die 2 benamingen zijn niet correct genoeg volgens mij docent. hij suggereerde me naar normalisatie te kijken voor termen. Maar beide tabellen zijn de eerste normaal vorm, dus die termen vallen ook al af.

Waarom vallen die dan af? Dan zou de benaming toch "Eerste normaalvorm" zijn?

[demonic]

In een hoofdstuk van het verslag noem ik ontwerpkeuzes die ik heb gemaakt, waaronder dus de keuze voor een 'wide' of 'narrow' ontwerp te kiezen:

Brede Tabel – Lange Tabel
Kiezen tussen een brede statische tabel heeft een aantal voordelen, maar ook nadelen ten opzichte van een lange tabel.
- Brede tabel:
Door de optimalisatie die Tableau op een database kan uitvoeren zijn brede statische tabellen erg efficiënt. Als men bv. Op een datum gaat filteren, i.p.v. dat je dan 10 rijen krijgt met verschillende waardes, krijg je in een brede tabel 1 rij met meerdere waardes. Dat helpt de prestaties van het dashboard enorm.

- Lange Tabel:
Bij het gebruik van een lange tabel krijg je een enorme vrijheid. Waarbij je bij een brede tabel maar een maximaal aantal kolommen hebt, kan je bij een lange tabel deze gewoon toevoegen waar je deze wenst. Dit heeft als voordeel dat je heel flexibel bent, en als er ooit behoefte is aan extra informatie is deze makkelijk toe te voegen zonder dat er van alles mis gaat. Als nadeel heb je alleen dat dit soort tabellen intensiever zijn om mee te werken voor Tableau en daardoor de prestaties kunnen verslechteren.

Mijn docent vind dat breed/wide en/of smal/narrow gewoon echt niet kan. als ik dus zou kiezen voor de benaming: "eerste normaalvorm",
dan zou het subkopje voor dit stuk zijn:

Eerste normaalvorm vs Eerste normaalvorm

dat levert dan ook niks op.

p.s. ik ben persoonlijk van mening dat we aan het mierenneuken zijn, maar ik wil inieder geval proberen om een andere benaming dan breed en smal te vinden. om mijn docent tevreden te stellen.

[DJMaze]

Lees dit eens: Wikipedia: Entity-relationshipmodel

[demonic]

Matthijs B schreef op vrijdag 9 december 2016 @ 15:25:
Wij noemen het tweede type tabel hier wel eens key-value tabellen. Misschien dat je begeleider daar naar op zoek is?

met Key-Value tabel als google zoekterm nu hier terecht gekomen, dit lijkt in de buurt te komen.
Wikipedia: Entity–attribute–value model

EDIT:

DJMaze schreef op vrijdag 9 december 2016 @ 15:56:
Lees dit eens: Wikipedia: Entity-relationshipmodel

Dat lijkt hem inderdaad te zijn!

[ Voor 22% gewijzigd door demonic op 09-12-2016 15:59 ]

[pacificocean]

Een tabelnaam moet gewoon beschrijven wat erin staat en is dus zeker geen mierenneuken, maar normaalvorm vind ik ook nergens op slaan. Waarom niet gewoon meetwaarden en indicatoren? Dat geeft gelijkaan waarom de 1 tabel breed is en de andere smal.

[Dido]

demonic schreef op vrijdag 9 december 2016 @ 15:51:
p.s. ik ben persoonlijk van mening dat we aan het mierenneuken zijn, maar ik wil inieder geval proberen om een andere benaming dan breed en smal te vinden. om mijn docent tevreden te stellen.

Protip: Naamgeving is nooit mierenneuken.

Slechte naamgeving is een van de meest voorkomende frustraties bij onderhoud van software. En je kunt het achteraf vaak niet aanpassen zonder de halve applicatie overhoop te gooien.

Als jij je tabellen een technisch logische naam had gegeven, had je nu geen probleem gehad om ze te beschrijven want dan was de naam al duidelijk geweest.

Nu heb jij ergens gelezen dat er rode en blauwe auto's bestaan en jij noemt je Fiat panda en je Ferrari allebei rode auto. En vervolgens vind je dat iemand aan het mierenneuken is als hij zich afvraagt of je geen betere namen kunt verzinnen voor die twee rode auto's, namen die iets duidelijker de auto's beschrijven.

Je ouders hebben jou toch (neem ik aan) bij je geboorte ook niet "jongetje" genoemd omdat ze gelezen hadden dat baby's meestal of een jongetje of een meisje zijn? Jij hebt nu gelzen dat je voor bepaalde zaken een tabel model A en een tabel model B kunt gebruiken, jongetje of meisje, en je noemt je eerste jongetje en meisje meteen jongetje en meisje. Dat wordt lastig als je er meer krijgt

Wat is er mis met "uitvalstatistiek" en "dashboardparameter" als namen voor je tabellen?

Dat je dan vervolgens beschrijft dat de tabel "uitvalstatistiek" een brede, lange, blauwe of knuffeltabel is staat los van de naam die je hem geeft.

[demonic]

pacificocean schreef op vrijdag 9 december 2016 @ 15:58:
Een tabelnaam moet gewoon beschrijven wat erin staat en is dus zeker geen mierenneuken, maar normaalvorm vind ik ook nergens op slaan. Waarom niet gewoon meetwaarden en indicatoren? Dat geeft gelijkaan waarom de 1 tabel breed is en de andere smal.

het gaat om een algemene omschrijving van het type tabel in een algemeen verslag, niet om de benaming in de database zelf.

Dido schreef op vrijdag 9 december 2016 @ 15:59:
[...]

Protip: Naamgeving is nooit mierenneuken.

Slechte naamgeving is een van de meest voorkomende frustraties bij onderhoud van software. En je kunt het achteraf vaak niet aanpassen zonder de halve applicatie overhoop te gooien.

Als jij je tabellen een technisch logische naam had gegeven, had je nu geen probleem gehad om ze te beschrijven want dan was de naam al duidelijk geweest.

Nu heb jij ergens gelezen dat er rode en blauwe auto's bestaan en jij noemt je Fiat panda en je Ferrari allebei rode auto. En vervolgens vind je dat iemand aan het mierenneuken is als hij zich afvraagt of je geen betere namen kunt verzinnen voor die twee rode auto's, namen die iets duidelijker de auto's beschrijven.

Je ouders hebben jou toch (neem ik aan) bij je geboorte ook niet "jongetje" genoemd omdat ze gelezen hadden dat baby's meestal of een jongetje of een meisje zijn? Jij hebt nu gelzen dat je voor bepaalde zaken een tabel model A en een tabel model B kunt gebruiken, jongetje of meisje, en je noemt je eerste jongetje en meisje meteen jongetje en meisje. Dat wordt lastig als je er meer krijgt

Wat is er mis met "uitvalstatistiek" en "dashboardparameter" als namen voor je tabellen?

Dat je dan vervolgens beschrijft dat de tabel "uitvalstatistiek" een brede, lange, blauwe of knuffeltabel is staat los van de naam die je hem geeft.

Ik ben niet opzoek naar een tabelnaam IN de database, maar juist eentje voor een algemeen verslag. ik heb die 2 tabellen genoemd om een idee te schetsen wat ik bedoelde.

Ik ben het helemaal eens met je protip! maar dat was niet het gene wat ik nu vroeg.

[ Voor 63% gewijzigd door demonic op 09-12-2016 16:03 ]

[Dido]

demonic schreef op vrijdag 9 december 2016 @ 16:00:
het gaat om een algemene omschrijving van het type tabel in een algemeen verslag, niet om de benaming in de database zelf.

Dan klopt je topictitel en vraagstelling niet. Een benaming en een omschrijving zijn twee verschillende dingen.

De omschrijving op basis van een onderscheid tussen breed en lang kan prima breed en lang zijn, maar dat is een arbitrair ondescheid dat alleen interessant is als je het over dat onderscheid wilt hebben. Op andere momenten is het logischer om met een logische naam naar de tabel te verwijzen (en als je je technische naam goed gekozen had, zouden die technische en logische namen erg op elkaar kunnen lijken).

In een algemeen verslag constant verwijzen naar een tabel op basis van een willekeurige eigenschap van dat ding is natuurlijk niet handig. Je gebruikt nu lang en breed, maar je kunt ook groot en klein, statisch en dynamisch, write-optimized en read-optimized gebruiken, maar ook dat is allemaal niet relevant als ik het niet over die specifieke eigenschappen heb, maar gewoon naar de tabel wil verwijzen.

[SinergyX]

Aardig wat jaren geleden voor mij, maar is dit wel een brede en smalle tabel? Afaik, lange geleden, was het verschil of je de data in de breedte of in de hoogte opsloeg.

Brede
ID StartDatum EindDatum Lijn Productie geen orders vulmachine verpakkingsmachine
12 01-01-2016 31-12-2016 7 etc etc

vs

Smalle
ID Type Value
met bijvoorbeeld:
12 Startdatum 01-01-2016
12 Einddatum 31-12-2016
12 lijn 7
etc

(waar meestal voor Type weer aparte tabel had die elke waarde had vastgelegd)

Wat jij hebt lijkt meer op uitgebreid en compact/samengevoegd.

[ Voor 7% gewijzigd door SinergyX op 09-12-2016 16:08 ]

[emnich]

Tabel 2 is nog steeds niet narrow.

Misschien kan je uitleggen waarom/hoe je naar deze tabellen verwijst in je verslag. Als het gaat om de daadwerkelijke tabellen, noem ze dan gewoon bij hun naampje.

[demonic]

SinergyX schreef op vrijdag 9 december 2016 @ 16:07:

Smalle
ID Type Value
met bijvoorbeeld:
12 Startdatum 01-01-2016
12 Einddatum 31-12-2016
12 lijn 7
etc

(waar meestal voor Type weer aparte tabel had die elke waarde had vastgelegd)

Wat jij hebt lijkt meer op uitgebreid en compact/samengevoegd.

Omdat startdatum en lijn nummer los van elkaar niks zeggen.
De minimale informatie die ik nodig heb op een regel is, startdatum, lijn nummer, type indicator, en de waardes daarvan. (bestaande uit 2 componenten)
Alles met relaties aan elkaar gaan koppelen verslechterd de responsiviteit van het dashboard enorm.

emnich schreef op vrijdag 9 december 2016 @ 16:08:
Tabel 2 is nog steeds niet narrow.

Misschien kan je uitleggen waarom/hoe je naar deze tabellen verwijst in je verslag. Als het gaat om de daadwerkelijke tabellen, noem ze dan gewoon bij hun naampje.

Ik verwijs niet zozeer naar die specifieke tabellen in mijn verslag. maar ik probeer te onderbouwen waarom je een keuze tussen een brede tabel en een 'narrow' tabel zou moeten maken, en dat beide zijn use-cases hebben.
(de tabellen heb ik hier alleen wel toegevoegd om een beeld te schetsen.)

[emnich]

demonic schreef op vrijdag 9 december 2016 @ 16:15:
[...]


Omdat startdatum en lijn nummer los van elkaar niks zeggen.
De minimale informatie die ik nodig heb op een regel is, startdatum, lijn nummer, type indicator, en de waardes daarvan. (bestaande uit 2 componenten)
Alles met relaties aan elkaar gaan koppelen verslechterd de responsiviteit van het dashboard enorm.


[...]

Ik verwijs niet zozeer naar die specifieke tabellen in mijn verslag. maar ik probeer te onderbouwen waarom je een keuze tussen een brede tabel en een 'narrow' tabel zou moeten maken, en dat beide zijn use-cases hebben.
(de tabellen heb ik hier alleen wel toegevoegd om een beeld te schetsen.)

OK, op zich is breed/smal of wide/narrow wel prima maar is de 2e tabel die je laat zien niet het voorbeeld van een narrow tabel, dan moet je naar het voorbeeld van SinergyX kijken.

[SinergyX]

demonic schreef op vrijdag 9 december 2016 @ 16:15:
[...]


Omdat startdatum en lijn nummer los van elkaar niks zeggen.
De minimale informatie die ik nodig heb op een regel is, startdatum, lijn nummer, type indicator, en de waardes daarvan. (bestaande uit 2 componenten)
Alles met relaties aan elkaar gaan koppelen verslechterd de responsiviteit van het dashboard enorm.

Als het goed is zouden beide dezelfde 'relatieve' informatie moeten bevatten, breed/smal heeft afaik niets te maken met welke informatie, maar uitsluitend op de manier van opslaan.

Bij eerste tabel haal je alle informatie in 1x op, bij de 2de haal je dus 'alles' van bepaalde ID op en voeg je dit samen.

Edit, de engelse wiki noemt dit dus Stacked/unstacked, en dat is toch echt het principe wat ik als voorbeeld geef.

Wikipedia: Wide and narrow data
Wide, or unstacked data is presented with each different data variable in a separate column

Narrow, or stacked data is presented with one column containing all the values and another column listing the context of the value

Wow.. sommige dingen blijven dus wel redelijk goed opgeslagen in m'n grijze massa

Zo ik het zie zijn de termen an sich wel goed, maar je begeleider bedoelt het volgens mij meer in de zin, dat de tabellen in kwestie niet als small/breed zijn, dat je dus geheel verkeerde termen hebt gebruikt voor die tabellen.

[ Voor 27% gewijzigd door SinergyX op 09-12-2016 16:28 ]

[Johnsel]

U zoekt row-based vs column-based dataopslag - geloof ik

U zoekt relationeel vs EAV

[ Voor 39% gewijzigd door Johnsel op 10-12-2016 20:20 ]