[CMDB] Normalisatie, ERD

[Verwijderd]

Hallo tweakers,

In september ben ik bij mijn nieuwe stagebedrijf begonnen. het is de bedoeling dat ik mij bezig houd met het creëren van het alombekende CMDB. Mijn begeleider zei al dat hij zelfstandig werken van mij verwachtte en ik wist dat ik het moeilijk zou krijgen. Nu heb ik op school geleerd dat je dit doet met behulp van normalisatie gevolgd door een ERD. Ik heb nu zoveel theorie gelezen over dit principe. Maar ik krijg het op een of andere manier niet in de praktijk gebracht.

De scope is dat we uiteindelijk (output) een overzicht willen van:

- Config-ID
- Config-soort
- merk
- Type
- Aanschafdatum
- Aanschafkosten
- Installatiekosten
- Kostenplaats

Ik heb me nu al door 2 mensen laten helpen, maar ik kom er nog niet fatsoenlijk uit.
Ik word er bijna depresief door..

Ik weet dat jullie dit niet voor mij gaan maken, en dat vraag ik ook niet. Maar misschien kunnen jullie mij de goede richting op sturen.

Nu weet ik dat de primary key de Config-ID is.

Wordt het dan het volgende??

1NV
Config-ID, (Config-Soort, Merk, Type, Aanschafdatum, Aanschafkosten,
Installatiekosten, kostenplaats)

Want je moet eerst de repeterende gegevens selecteren he? Maar we hebben bijvoorbeeld afgesproken dat Type een tekstveld wordt omdat dit zosnel verandert elke keer. Moet ik dat er dan ook in opnemen?

2NV
Config-ID,
Config-ID, Config-Soort, (Merk, Type, Aanschafdatum, Aanschafkosten, Installatiekosten, kostenplaats)

Is dit dan 2NV?

En verder dan dit kom ik momenteel niet. Wel weet ik dat de basis van de hele database op de 5-jarige afschrijving loopt. Nu heb ik me laten vertellen, wat eigenlijk heel logisch klinkt, dat de hele database gebaseerd is op 2 tabellen. Namelijk de tabel waarin de objecten staan die nog afgeschreven worden. En de tabel waarin de objecten afgeschreven zijn. Daartussen loopt het hele geautomatiseerde proces, toch?

Ik hoop dat jullie me verder kunnen helpen. Alvast bedankt!

(Dit is trouwens allemaal vanuit mijn eigen interpretatie gemaakt, daarnaast zullen dit niet alle complete waarden zijn vermoed ik)

[Verwijderd]

Kan je nog wat meer informatie geven over de precieze entiteiten die je op gaat slaan...dus om wat voor gegevens gaat het precies? Zijn het producten die een bedrijf aanschaft?

Zoja, dan zijn (merk, type) repeterende gegevens...en deze zouden naar mijn inzicht in een aparte tabel moeten staan.

Verwijderd schreef op donderdag 13 november 2008 @ 13:14:
Nu heb ik me laten vertellen, wat eigenlijk heel logisch klinkt, dat de hele database gebaseerd is op 2 tabellen. Namelijk de tabel waarin de objecten staan die nog afgeschreven worden. En de tabel waarin de objecten afgeschreven zijn. Daartussen loopt het hele geautomatiseerde proces, toch?

Dat mag dan wel heel logisch klinken, maar 2 tabellen die afgezien van een status veldje (afgeschreven ja/nee) exact hetzelfde zijn is nu niet echt een schoolvoorbeeld van een nette normalisatie .

[pedorus]

Verwijderd schreef op donderdag 13 november 2008 @ 13:37:
Kan je nog wat meer informatie geven over de precieze entiteiten die je op gaat slaan...dus om wat voor gegevens gaat het precies? Zijn het producten die een bedrijf aanschaft?

Het gaat denk ik om de ITIL CMDB. En kijk, in dat wikipedia artikel staan zelfs tools

En verder is eerst een tabel in de 1e normal form zetten, en dan steeds verdere normaalvormen gebruiken niet echt de juiste manier van database design (de 4e hit is zelfs een online boek lijkt wel).

Ik krijg toch een beetje het idee dat de 'google-fase' over is geslagen.

[Lethalis]

Bij normalisatie moet je heel erg kijken naar de semantiek.

Heel simpel:
1. Omschrijf wat de bedrijfsprocessen doen die je gaat normaliseren.

Bijvoorbeeld:
Klant koopt een product van een filiaal

2. Let op de zelfstandige naamwoorden, dit worden vaak je entiteiten.

Klant
Product
Filiaal

3. Let op de werkwoorden, aangezien dit ook vaak entiteiten worden:

Koop

4. Vervolgens kijk je naar de eigenschappen van elke entiteit. Ik geef elke entiteit al snel gewoon een volgnummer, dus KlantID, ProductID, FiliaalID, KoopID, etc om het uniek te identificeren.

Daarna kijk ik vaak naar wat ik weet over elke entiteit:

Klant (naam, adres, plaats, btw nummer, bankrekening)
Product (artikelnummer, omschrijving, prijs)
Filiaal (naam, adres, plaats)
Koop (klantid, productid, datum)

5. Gegevens die vaak herhalen, worden aparte entiteit..

Producttype bijv.

..

Nou ja, beetje simpel uitgelegd.. maar zo ga ik altijd te werk.

[edit] Ik heb een beetje te snel erover heen gelezen denk ik.. anyway, het is goed bedoeld

[ Voor 16% gewijzigd door Lethalis op 13-11-2008 14:00 ]

[Verwijderd]

Verwijderd schreef op donderdag 13 november 2008 @ 13:37:
Kan je nog wat meer informatie geven over de precieze entiteiten die je op gaat slaan...dus om wat voor gegevens gaat het precies? Zijn het producten die een bedrijf aanschaft?

Zoja, dan zijn (merk, type) repeterende gegevens...en deze zouden naar mijn inzicht in een aparte tabel moeten staan.
[...]

Dat mag dan wel heel logisch klinken, maar 2 tabellen die afgezien van een status veldje (afgeschreven ja/nee) exact hetzelfde zijn is nu niet echt een schoolvoorbeeld van een nette normalisatie .

Oh ja, natuurlijk.. Het gaat om +/- 500 werkplekken op +/- 80 locaties en +/-1200 gebruikers.

De PDA's, laptops en mobiele telefoons worden aan een gebruiker gekoppeld. En de rest Fat- Thinclient etc. aan een locatie. Volgens mij is het uiteindelijke doel om een overzicht te krijgen van de kosten op de juiste kostenplaats. Nog iets?

En dat laatste klinkt idd ook logisch.. Maar ik vond het wel een handig voorbeeld voor de visualisatie in mijn hoofd.

[Lethalis]

Verwijderd schreef op donderdag 13 november 2008 @ 13:14:
Nu heb ik me laten vertellen, wat eigenlijk heel logisch klinkt, dat de hele database gebaseerd is op 2 tabellen. Namelijk de tabel waarin de objecten staan die nog afgeschreven worden. En de tabel waarin de objecten afgeschreven zijn. Daartussen loopt het hele geautomatiseerde proces, toch?

Ik vind dit trouwens helemaal niet zo logisch.. ik zie dat meer als een eigenschap. Dus alle objecten in 1 tabel, met daarin een eigenschap "afgeschreven". Maar ik gooi ook maar wat in jouw richting

[Verwijderd]

pedorus schreef op donderdag 13 november 2008 @ 13:47:
[...]

Het gaat denk ik om de ITIL CMDB. En kijk, in dat wikipedia artikel staan zelfs tools

En verder is eerst een tabel in de 1e normal form zetten, en dan steeds verdere normaalvormen gebruiken niet echt de juiste manier van database design (de 4e hit is zelfs een online boek lijkt wel).

Ik krijg toch een beetje het idee dat de 'google-fase' over is geslagen.

Ik heb dat ITIL gebeuren (al eerder)doorgelezen inderdaad. Maar mijn scope is een stuk kleiner. Dus volgens mij klopt die theorie gewoon niet met wat mijn opdracht is.

Daarnaast is hier al een servicedesk en gaat het puur en alleen om de database.

Ik kan momenteel helaas niet naar de tools kijken omdat ik op een Thin-Cliënt zit. Maar ik zal er straks thuis even naar kijken. Iig bedankt voor de link.

Over de Google fase: Ik zei toch al dat ik een hoop theorie doorgelezen heb? Maar dat ik moeite heb met het uitvoeren van? Er komen 2 vragen en bij de 2e vraag hang ik al:

- Wat is de scope?
- Normaliseer en maak een ERD.

(Edit op spelfout)

[Verwijderd]

Lethalis schreef op donderdag 13 november 2008 @ 13:47:


[edit] Ik heb een beetje te snel erover heen gelezen denk ik.. anyway, het is goed bedoeld

Het gaat dus PUUR om de CMDB en niet echt om de bedrijfsprocessen. En ik kom er niet helemaal uit. Zie de bovenstaande (mislukte) normalisatie van mij.

(Edit: quotefix)

[ Voor 32% gewijzigd door Verwijderd op 13-11-2008 14:15 ]

[Verwijderd]

Ok, de vraag is nu dus...moet jij een heel nieuw systeem (nieuwe tabellen) opzetten om deze gegevens bij te houden, of bestaat dit al en moet jij het gevraagde overzicht uit je openings post zien te produceren?

In het eerste geval raad in je aan om de eerste post van Lethalis in dit topic nog eens door te lezen, ga op die manier na welke gegevens (entiteiten) je op wilt/moet slaan in je database...en wat de onderlinge relaties tussen deze entiteiten zijn.

Wanneer er reeds tabellen bestaan, en jij moet hiervan gegevens uitlezen en de tabellen uiteindelijk normaliseren, dan was je met je eerste opzet al goed op weg...maar pak er gewoon eens wat voorbeeld records bij, en ga dan nog eens goed na welke gegevens uniek zijn en welke vaker terug (kunnen!) komen.

pedorus schreef op donderdag 13 november 2008 @ 13:47:
[...]

Het gaat denk ik om de ITIL CMDB. En kijk, in dat wikipedia artikel staan zelfs tools

En verder is eerst een tabel in de 1e normal form zetten, en dan steeds verdere normaalvormen gebruiken niet echt de juiste manier van database design (de 4e hit is zelfs een online boek lijkt wel).

Ik krijg toch een beetje het idee dat de 'google-fase' over is geslagen.

Welke tool er gebruikt wordt maakt voor het ontwerp van het ERD/de tabellen niks uit, als het goed is...

[Lethalis]

Verwijderd schreef op donderdag 13 november 2008 @ 14:13:
[...]
Het gaat dus PUUR om de CMDB en niet echt om de bedrijfsprocessen. En ik kom er niet helemaal uit. Zie de bovenstaande (mislukte) normalisatie van mij.

Ik ben bang dat jij het veel te theoretisch bekijkt..

Want ik werk dagelijks met databases en heb er ook aardig wat ontworpen, maar ik weet nu al niet meer wat 1NV en 2NV is.. alleen nog dat ik het ooit moest weten

Je moet kijken naar wat je precies vastlegt en wat je ermee wil doen. Wat is het doel van de CMDB? Waar wil je later op kunnen zoeken bijvoorbeeld? Hoever ga je in het opslaan van gegevens? Etc.

[Verwijderd]

Verwijderd schreef op donderdag 13 november 2008 @ 14:15:
Ok, de vraag is nu dus...moet jij een heel nieuw systeem (nieuwe tabellen) opzetten om deze gegevens bij te houden, of bestaat dit al en moet jij het gevraagde overzicht uit je openings post zien te produceren?

In het eerste geval raad in je aan om de eerste post van Lethalis in dit topic nog eens door te lezen, ga op die manier na welke gegevens (entiteiten) je op wilt/moet slaan in je database...en wat de onderlinge relaties tussen deze entiteiten zijn.

Wanneer er reeds tabellen bestaan, en jij moet hiervan gegevens uitlezen en de tabellen uiteindelijk normaliseren, dan was je met je eerste opzet al goed op weg...maar pak er gewoon eens wat voorbeeld records bij, en ga dan nog eens goed na welke gegevens uniek zijn en welke vaker terug (kunnen!) komen.


[...]

Welke tool er gebruikt wordt maakt voor het ontwerp van het ERD/de tabellen niks uit, als het goed is...

Even opnieuw en voor de duidelijkheid. Ik vergeet concrete gegevens hier neer te zetten denk ik.

Feiten:
- Het complete beheer van alle configuraties wordt momenteel gedaan door een extern bedrijf.
- Er is al een ticket-systeem. (in eigen beheer) Voor wijzingen, incidenten etc.
- Men wil de controle houden en dit in eigen beheer registreren, maar het externe bedrijf blijft dit voorlopig doen.
- Deze database moet uiteindelijk worden opgenomen in de lokale 'website' van het incidentenbeheer.
- Ik heb samen met mijn begeleider geschetst (vanuit mijn voorstellen) wat de situatie moet zijn. (Zie de lijst in mijn OP.
- Er is al een database beheert door extern bedrijf, helaas maar voor +/- 75% acuraat. (huidige situatie)

[Verwijderd]

Ik ben nu zelf al een tijdje bezig m.b.t. normalisatie en maken van asp.net sites, dus heb hier al benodigde ervaring op gedaan. Wat ik doe als ik begin met het normaliseren van een (simpele) database, dan zet ik een rapport op voor mezelf van hoe een uiteindelijke uitdraai van informatie zou komen uit te zien.

Probeer van dit rapport alle entiteiten en repeterende groep(en) te bepalen (op simpel beginners niveua) ik denk namelijk door alle theorie die je al hebt (naar wat ik heb gelezen) je een stuk moeilijker aan het denken bent dan je zou moeten doen.

Als je ergens een "voorbeeld" zou kunnen krijgen van een simpele database, misschien dat je dan NET die "koppeling" ziet tussen bepaalde entiteiten. Zoals Lethalis al zei:

Ik ben bang dat jij het veel te theoretisch bekijkt..

Want ik werk dagelijks met databases en heb er ook aardig wat ontworpen, maar ik weet nu al niet meer wat 1NV en 2NV is.. alleen nog dat ik het ooit moest weten

(niet echt veel nuttige info, mja)

veel succes ermee!

[Lethalis]

Verwijderd schreef op donderdag 13 november 2008 @ 14:28:
[...]
Even opnieuw en voor de duidelijkheid. Ik vergeet concrete gegevens hier neer te zetten denk ik.

Feiten:
- Het complete beheer van alle configuraties wordt momenteel gedaan door een extern bedrijf.
- Er is al een ticket-systeem. (in eigen beheer) Voor wijzingen, incidenten etc.
- Men wil de controle houden en dit in eigen beheer registreren, maar het externe bedrijf blijft dit voorlopig doen.
- Deze database moet uiteindelijk worden opgenomen in de lokale 'website' van het incidentenbeheer.
- Ik heb samen met mijn begeleider geschetst (vanuit mijn voorstellen) wat de situatie moet zijn. (Zie de lijst in mijn OP.
- Er is al een database beheert door extern bedrijf, helaas maar voor +/- 75% acuraat. (huidige situatie)

Des te meer reden om de bedrijfsprocessen in kaart te brengen.

Proces: gebruiker van incidentenbeheer legt configuratie item vast

Je schrijft dat de huidige externe CMDB helaas maar voor ongeveer 75% correct is. Hoe denk je dit te verbeteren? Daarvoor heb je de werknemers nodig die al werken met de huidige website voor het incidentenbeheer en een controle daarop (of zij alles wel netjes invullen).

Conclusie: ik zou in mijn ERD gegevens opnemen hierover, namelijk per configuratie item:
- UserID / LogonID (hetzelfde als in het huidige pakket)
- DatumGewijzigd (om bij te houden wanneer iemand het heeft ingevuld / gewijzigd)

Op deze manier kun je uiteindelijk zien:
- Als er iets niet klopt, wie dat dan heeft ingevuld en wanneer
- Welke werknemers opvallend weinig items hebben aangepast / aangemaakt

Want anders lukt het je nooit om die 75% te verbeteren.

Succes