Records die al bestaan niet nogmaal toevoegen in tabel.

[Kadir28]

Beste Helpmij leden,

Ik ben voor stage een CMDB aan het bouwen. (Configuration Management Database)
Hij ziet er steeds weer beter uit.

Alleen, zit ik met het volgende;

Stel dat ik het volgende informatie toevoeg:

- AssetName: Server xxxx
- Asset Type: Dell xxxx
- Asset Descr:SERV0001
- Status: In Use
- RAM: 1024 MB bijvoorbeeld.
- User: Pietje Puk.

Nu zeg ik bijv. Stel dat Pietje Puk hem in gebruik heeft, dan wil ik wanneer ik voor de grap een nieuwe record toevoeg,
dat deze niet aangemaakt wordt, want deze bestaat reeds.


Hoe kan ik hiervoor zorgen?


Alvast bedankt,

Met vriendelijke groeten,
Kadir Perçin

 

[OctaFish]

Er ontbreekt vitale informatie want je geeft niet aan wat het sleutelveld is. De velden die je noemt lijken mij geen sleutelvelden, al zou bij mij het veld [Asset Descr] (wat in mijn ogen een memoveld zou moeten zijn gezien de naam) dus AssetID zijn, en als sleutelveld fungeren. In dat geval zou SERV001 dus de unieke naam zijn, die maar één keer voor mag komen. Op het moment dat je dan SERV001 nóg een keer probeert toe te voegen, zal dat niet lukken omdat die waarde al bestaat.

 

[tecsman]

In dit geval zou ik in mijn advies de nadruk leggen op het toepassen van Normalisatie.

De naam van iemand bij wie een server in gebruikk is, hoort in deze tabel niet thuis.

 

[OctaFish]

De naam van iemand bij wie een server in gebruikk is, hoort in deze tabel niet thuis.

Dat vind ik een beetje kort door de bocht; als je alleen wilt weten wie de laatste gebruiker is van het systeem, is dat zo prima. Doe ik ook regelmatig. En mijn databases zijn echt wel genormaliseerd... We weten niks van de db tenslotte dus niet te snel oordelen .

 

[tecsman]

@OctaFish: :thumb: je hebt gelijk, maar in de context van "configuratie management" vond ik dat ik deze gok wel kon maken.

 

[Kadir28]

Er ontbreekt vitale informatie want je geeft niet aan wat het sleutelveld is. De velden die je noemt lijken mij geen sleutelvelden, al zou bij mij het veld [Asset Descr] (wat in mijn ogen een memoveld zou moeten zijn gezien de naam) dus AssetID zijn, en als sleutelveld fungeren. In dat geval zou SERV001 dus de unieke naam zijn, die maar één keer voor mag komen. Op het moment dat je dan SERV001 nóg een keer probeert toe te voegen, zal dat niet lukken omdat die waarde al bestaat.

Ik ben het eens met u! Het sleutelveld is de HardwareID. Asset type, name etc. liggen hieronder.
Dit heeft dan denk ik te maken met ''Many to many'' relationships toch?
Dus bv. Hans puk kan ook gebruik maken van de server0001 die Pietje Puk in gebruik heeft.

Ik was alleen in de twijfel, want ja was het uniek, dan weet ik dat Access doorgaans een response geeft van "niet mogelijk".
of bv it is bound to .....

Normalisatie ziet er wel goed uit. Ik ben al een eindje gekomen met het extenden van deze database.
Bij tblHardware heb ik bv UserID er in staan zodat ik zo kan inzien bij tblUsers welke HardwareID door welke UserID (FirstName,LastName,Department) Etc...gebruikt wordt.

 

[Kadir28]

@OctaFish: :thumb: je hebt gelijk, maar in de context van "configuratie management" vond ik dat ik deze gok wel kon maken.

@tecsman Je hebt ook gelijk! Geen info, is ook geen response! I know that :thumb:

 

[Kadir28]

Of anders zou ik dus zoals je het aan hebt gegeven een nieuwe table moeten aanmaken, waarvoor geldt: AssetID!
En daaronder name type etc etc.

AssetID als uniek zetten. Dan integrity aanvinken b.v.

Dan zou het in principe maar 1x moeten voorkomen toch?!

@tecsman

 

[tecsman]

@Kadir: bespreken van de werking van Access databases kun je beter aan OctaFish overlaten; die heeft daar verstand van.

Op een functioneel niveau zou ik zeggen:

Je wilt een overzicht van de hardware ( = aparte tabel)
Je wilt een overzicht van gebruikers ( = aparte tabel)
Je wilt vastleggen welke hardware bij welke gebruiker in gebruik is geweest (of: welke gebruiker is geautoriseerd voor welke hardware)

Persoonlijk zou ik dat laatste in een aparte tabel vastleggen, mèt een begin- en eind-datum.
En ik zou àlle tabellen voorzien van deze drie velden: begindatum, einddatum en een wijzigingsdatum.

Maar dat is meer vanuit het oogpunt van de DBA dan vanuit de behoefte van de eindgebruiker.

 

[Kadir28]

Bedankt voor je reactie! @tecsman

Mijn tabellen zien er als volgt uit:

tblHardware bevat:"HardwareID,UserID,AssetName,AssetType,Asset Description (is een memo)! Hiernaast nog als Attachments (jpg.): SerialNumber,PurchaseOrder, en een TagNumber (alle 3 zijn jpg. foto's)

tblUsers bevat:''UserID,HardwareID,NetworkID, FirstName,LastName, & Department.

tblNetwork bevat:"NetworkID,HardwareID,UserID , Outlet,IP-Address, Location.

en tblSoftware bevat:"SoftwareID,HardwareID,UserID, SoftwareName,Version,License(Attchm), License AcquisitionDate LicenseExpireDate, Quantity,Reference, PurchaseOrder(Attchm)

 

[Kadir28]

Bedankt voor je reactie! @tecsman

Mijn tabellen zien er als volgt uit:

tblHardware bevat:"HardwareID,UserID,AssetName,AssetType,Asset Description (is een memo)! Hiernaast nog als Attachments (jpg.): SerialNumber,PurchaseOrder, en een TagNumber (alle 3 zijn jpg. foto's)

tblUsers bevat:''UserID,HardwareID,NetworkID, FirstName,LastName, & Department.

tblNetwork bevat:"NetworkID,HardwareID,UserID , Outlet,IP-Address, Location.

en tblSoftware bevat:"SoftwareID,HardwareID,UserID, SoftwareName,Version,License(Attchm), License AcquisitionDate LicenseExpireDate, Quantity,Reference, PurchaseOrder(Attchm)

Ik heb nu al ongeveer 200 records in hardware desktops,laptops etc. Verder alle users zitten in de tblUsers. Network & Software ben ik nog niet aan toe... @OctaFish

 

[OctaFish]

@Kadir: je bent een nieuwe gebruiker (welkom nog ) dus je hebt de huisregels waarschijnlijk nog niet gelezen. Maar continue quooten is nergens voor nodig, maakt draadjes nodeloos lang en hebben we dus liever niet. Als je al een quoot gebruikt, pak dan alleen de zin(nen) waar het om gaat. Maar complete berichten quooten? Niet doen!

Je tabel Hardware bevat een veld UserID dat er niet thuishoort, en de tabel User bevat een veld HardwareID dat er niet thuishoort. Dat riekt niet naar een goed genormaliseerde database. Sowieso zou ik, als het om computers gaat, ook een tabel Configuraties maken. Een pc komt vaak met een monitor, toetsenbord etc. En je schuift een gebruiker dus vaak een complete configuratie in zijn mik. Dan is het dus beter om die configuraties ook vast te leggen. En maak dus vooral die koppeltabel, die je nu niet hebt.