Hardware/storingen database ontwerpen

[kromme]

Goedemorgen,

Voor mijn werk wil ik een database ontwerpen voor het registreren van de hardware en storingen in te zetten met de oplossing.
We hebben hier nu TOPDESK maar hier word geen gebruik van gemaakt omdat het te groot is en de gebruikers dit pakket niet fijn vinden, tevens uiteraard de kosten van het pakket
Ik wil samen met mijn collega van ict daarom een simpelle database maken.

Ik heb het volgende gemaakt:

1 tabel Hardware:
Device type (uitrolmenu met "pc,monitor,printer,notebook,pda")
Merk
Type
Serienummer
PC naam (dit is een combi van (Device,plaats,kamernummer,volgnummer)
INCH Scherm
UMTS kaart (Ja,Nee)(voor bij notebook)
User
Locatie
Kamer
Opmerking

1tabel storingen:
Datum aanmelding
Device type
Locatie
Kamer
PC naam
Serienummer
Storings omschrijving
Behandelaar
Status
Oplossing
Opgelost door(uitrol menu ICT)
Datum afgehandeld

Mijn vraag is nu omdat ik het idee heb dat ik fout bezig ben qua tabellen.
Zijn er suggesties,ideeen,op of aanmerkingen?
Wat kan ik het beste als primaire sleutel pakken?
De hardware moet worden genummerd, ideen hoe en wat het beste werkt(dymo labeler?)

[Silver7]

Kijk ook naar:
- toekomstvisie
- infrastructuur (computers/netwerken/printers/etc)
als het groot netwerk is, is een kleine databas dan zo handig?
- no-Access database-mogelijkheden
- overleggen over wat er moet komen in de database (oftewel scope)

[ Voor 17% gewijzigd door Silver7 op 19-02-2007 10:17 ]

[DiedX]

ik zou sowieso de user lostrekken van de hardware-tabel (wat als Piet weggaat, en zijn laptop gaat naar Henk?). Verder inderdaad de scope: wat wil je er in hebben ja of nee?

[kromme]

Silver7 schreef op maandag 19 februari 2007 @ 10:17:
Kijk ook naar:
- toekomstvisie
- infrastructuur (computers/netwerken/printers/etc)
als het groot netwerk is, is een kleine databas dan zo handig?
- no-Access database-mogelijkheden
- overleggen over wat er moet komen in de database (oftewel scope)

Toekomst is nog een beetje onduidelijk, Het beheer ligt nu volledig extern.
De kans is groot dat we de servers weer binnenshuis gaan nemen,het beheer is nog niet geheel duidelijk, de vraag of we dit laten doen door extern bedrijf of zelf een compleet netwerk opzetten.

offtopic:Suggesties trouwens ook welkom.

Maar ja opzicht wil ik wel een uitgebreidere database maken.

[Verwijderd]

Wij maken hier gebruik van GLPI. Erg fijn OpenSource pakketje met vele mogelijkheden. Heeft al een goede basis en het werkt fijn met templates voor diverse hardware. Het kan koppelen met devices en laat ook een goede historie van een apparaat zien. Men kan zien wie de vorige gebruiker is geweest etc, etc.

[kromme]

DiedX schreef op maandag 19 februari 2007 @ 10:19:
ik zou sowieso de user lostrekken van de hardware-tabel (wat als Piet weggaat, en zijn laptop gaat naar Henk?). Verder inderdaad de scope: wat wil je er in hebben ja of nee?

Dus een apparte tabel met de users?

[gorgi_19]

kromme schreef op maandag 19 februari 2007 @ 10:24:
[...]


Dus een apparte tabel met de users?

Hangt van de relatie af; als 1 user per definitie 1 hardwarecomponent heeft, dan niet. In praktijk heeft een user 0 of meer hardwarecomponenten onder zich, dus krijg je een aparte tabel met een 1:n relatie

[BtM909]

Is dit niet een kwestie van de normaliserings procedure doorlopen

[kromme]

gorgi_19 schreef op maandag 19 februari 2007 @ 10:28:
[...]

Hangt van de relatie af; als 1 user per definitie 1 hardwarecomponent heeft, dan niet. In praktijk heeft een user 0 of meer hardwarecomponenten onder zich, dus krijg je een aparte tabel met een 1:n relatie

Een user heeft altijd een pc,monitor onder zich, eventueel ook nog een laptop of pda.

Ik wilde ook voor ieder device type een apparte tabel maken, maar of dat zo slim is

[kromme]

BtM909 schreef op maandag 19 februari 2007 @ 10:31:
Is dit niet een kwestie van de normaliserings procedure doorlopen

Ja ik weet wat ik wil, ben alleen benieuwd of andere ideen hebben en tips.

[gorgi_19]

kromme schreef op maandag 19 februari 2007 @ 10:33:
[...]


Ja ik weet wat ik wil, ben alleen benieuwd of andere ideen hebben en tips.

Neemt niet weg dat je nog steeds die procedure moet doorlopen voor de opzet van je database.

[BtM909]

kromme schreef op maandag 19 februari 2007 @ 10:33:
[...]
Ja ik weet wat ik wil, ben alleen benieuwd of andere ideen hebben en tips.

Los van tips en andere ideeen is dat wel hetgeen waar je eerst mee moet beginnen.

Als ik dit nl. lees

Ik wilde ook voor ieder device type een apparte tabel maken, maar of dat zo slim is

dan weet ik niet of je wel echt aan 't normaliseren bent

[kromme]

Ik zal dadelijk eens helemaal opnieuw gaan normaliseren en de output daarvan zal ik hier plaatsen.

[kromme]

Of het nu aan carnaval ligt maar ik weet ff niet of ik goed bezig ben.

0de vorm
Device type,Merk,Type,Serienummer,PC naam,INCH Scherm,UMTS kaart,User,Locatie,Kamer,Opmerking

Moet hier nu die 2de tabel bij?
Wij hebben dat indertijd op school met een formulier geleerd.

1tabel storingen:
Datum aanmelding
Device type

[ Voor 31% gewijzigd door kromme op 19-02-2007 12:26 ]

[Verwijderd]

Kijk ook eens naar configuratiemanagement volgens ITIL. Hier zijn bijna alle aspecten van het beheren van configuraties al op genomen. (Er zijn pakketten al ingericht die dit kunnen)

[kromme]

Verwijderd schreef op maandag 19 februari 2007 @ 14:51:
Kijk ook eens naar configuratiemanagement volgens ITIL. Hier zijn bijna alle aspecten van het beheren van configuraties al op genomen. (Er zijn pakketten al ingericht die dit kunnen)

Dan ga ik denk ik toch weer meer naar het te uitgebreide toe en het "flinke prijskaartje"

[kromme]

Verwijderd schreef op maandag 19 februari 2007 @ 10:23:
Wij maken hier gebruik van GLPI. Erg fijn OpenSource pakketje met vele mogelijkheden. Heeft al een goede basis en het werkt fijn met templates voor diverse hardware. Het kan koppelen met devices en laat ook een goede historie van een apparaat zien. Men kan zien wie de vorige gebruiker is geweest etc, etc.

Dit ziet er erg mooi uit, heb je toevallig iets van een nederlandse handleiding?

[JochemK]

kromme schreef op maandag 19 februari 2007 @ 12:21:
Of het nu aan carnaval ligt maar ik weet ff niet of ik goed bezig ben.

0de vorm
Device type,Merk,Type,Serienummer,PC naam,INCH Scherm,UMTS kaart,User,Locatie,Kamer,Opmerking

Op deze manier ga je natuurlijk redundantie kweken. Stel het volgende staat in je database:
User1 heeft een pc, woont in kamer1 op locatie A
User1 heeft een pda, woont in kamer1 op locatie A

Dan gaat User1 verhuizen, en moet je de database gaan updaten, dus je zoekt naar User1, en schrijft wat weg, met als gevolg dat het volgende er staat:

User1 heeft een pc, woont in kamer5 op locatie B
User1 heeft een pda, woont in kamer1 op locatie A

Wie weet nu nog waar User1 woont?

Wat je volgens mij moet doen is het volgende:

• bepaal welke entiteiten je hebt (bv users, hardware, storing)
• bepaal welke attributen de verschillende entiteiten hebben (bij user bv. naam, kamer, locatie)
• bepaal de relaties tussen de verschillende entiteiten (bv 1 user heeft 0 of meer hardware components)

nu kun je de database op gaan bouwen.

Nog een paar extra tips:

• Geef alle entiteiten een volgnummer, wat je als primary key instelt
• Als je in een tabel wilt verwijzen naar een andere entiteit, gebruik je dit volgnummer, en niet de op dat moment relevante info, zie verhaal over redundantie hierboven
• Als je een veel op veel relatie tegenkomt, maak je voor die relatie een nieuwe tabel aan.

Dat was wat ik zosnel even kon bedenken. Kijk nu nog maar eens kritisch naar je ontwerp, en dan horen we het wel weer.

[kromme]

kingjotte schreef op dinsdag 20 februari 2007 @ 16:07:
[...]


Op deze manier ga je natuurlijk redundantie kweken. Stel het volgende staat in je database:
User1 heeft een pc, woont in kamer1 op locatie A
User1 heeft een pda, woont in kamer1 op locatie A

Dan gaat User1 verhuizen, en moet je de database gaan updaten, dus je zoekt naar User1, en schrijft wat weg, met als gevolg dat het volgende er staat:

User1 heeft een pc, woont in kamer5 op locatie B
User1 heeft een pda, woont in kamer1 op locatie A

Wie weet nu nog waar User1 woont?

Wat je volgens mij moet doen is het volgende:

[list]
• bepaal welke entiteiten je hebt (bv users, hardware, storing)
...

Dus toch meerdere tabellen, wat ik al dacht. Thanks hier heb ik wat aan.
Ik ga het met mijn collega er vandaag over proberen te hebben(na zijn 5 dagen carnaval) of we dat open source programme niet kunnen gebruiken en integreren en ons intranet.Zo niet dan gaan we weer aan de slag met access.

[Janoz]

Omdat dit (oa) mij meer op een ontwerp probleem lijkt verplaats ik hem naar SEA.