Results 1 to 13 of 13

Thread: Normaliseren van gegevens

  1. #1

    Post Normaliseren van gegevens

    Ik ben enkele dagen geleden begonnen aan een applicatie die gebruikt gaat worden om alle schoolcomputers en monitors te inventariseren. Ik ben echter nogal slecht in het normaliseren van data en daardoor begin ik nu tegen problemen aan te lopen. Ik heb al meerdere tutorials m.b.t. normaliseren doorgenomen, maar met die informatie lukt het me ook niet goed. Nu wil ik graag helemaal opnieuw beginnen. Ik moet werken met de volgende gegevens:

    COMPUTERS
    rocnr (een sticker op de pc die uniek is)
    merk
    type
    serienr
    datum aanschaf
    lokaal
    patchnr

    MONITORS
    rocnr (een sticker op de monitor die uniek is, komt NIET overeen met rocnr van de computer)
    merk
    type
    serienummer
    datum aanschaf
    lokaal

    Nu is het de bedoeling dat deze gegevens in een Access database gaan komen, die m.b.v. ADO componenten aangesproken gaat worden. Het moet mogelijk zijn om een monitor te "koppelen" aan een computer. Zodat je weet wat waar bij hoort. Ook moet het mogelijk zijn om 2 monitoren aan een computer te hangen. Verder moet het mogelijk zijn om computers en monitoren te boeken die NIET aan elkaar gekoppeld zijn (staan in opslag of iets dergelijks). En is het maken van relaties nodig?

    Ik hoop dat hier mensen zijn die mij wat suggesties kunnen geven m.b.t. de opzet van de database!
    Last edited by kerberos; 29-Feb-08 at 10:31.

  2. #2
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    COMPUTERS
    rocnr (een sticker op de pc die uniek is)
    merk
    type
    serienr
    datum aanschaf
    lokaal
    patchnr
    monitor_id

    MONITORS
    monitor_id
    merk
    type
    serienummer
    datum aanschaf
    lokaal <-- deze hoeft niet, staat al in COMPUTERS

    zorg ervoor dat er altijd een relatie is tussen de pc en de monitor. Daardoor moet je de id van de monitor opnemen in de tabel COMPUTERS.
    Je eerste stap van normaiseren is eigenlijk dan al gedaan door het feit dat je de gevens van de monitor scheidt van de tabel COMPUTERS.
    Je zou het merk apart in een tabel kunnen plaatsen. Dat zorgt in iedergeval dat je dan redundantie kan verwachten.

    Veel valt er niet aan te normaliseren. Je hebt maar twee tabellen. Heb je eigenlijk wel een idee wat normaliseren inhoudt. Het is een vak apart en er zijn altijd nog andere personen die het beter kunnen dan jij en ik.

    Nu is het de bedoeling dat deze gegevens in een Access database gaan komen, die m.b.v. ADO componenten aangesproken gaat worden. Het moet mogelijk zijn om een monitor te "koppelen" aan een computer. Zodat je weet wat waar bij hoort. Ook moet het mogelijk zijn om 2 monitoren aan een computer te hangen. Verder moet het mogelijk zijn om computers en monitoren te boeken die NIET aan elkaar gekoppeld zijn (staan in opslag of iets dergelijks). En is het maken van relaties nodig?

    Ik hoop dat hier mensen zijn die mij wat suggesties kunnen geven m.b.t. de opzet van de database!
    Moet het in een access database? Je gegevens zijn niet groot en de database bestaat maar uit twee tabellen. Misschien zal je ook kunnen kijken naar een paradox of dbase database. Zelf heb ik daar tabellen van gemiddeld 20.000 records in staan, die zonder problemen werken.
    Last edited by jkuiper; 29-Feb-08 at 10:50. Reason: text vergeten
    Delphi is great. Lazarus is more powerfull

  3. #3
    Ik maak uit je omschrijving op dat het ROCNr uniek is over de computers en monitoren samen; als dat echt zo is, kan je dat als primary key voor zowel de computer- als de monitortabel gebruiken.

    Omdat de velden voor de tabellen nogal overeenkomen, zou je het ook zo kunnen doen:
    APPARATUUR
    Type -- 'computer' of 'monitor'
    RocNr -- primary key
    Merk
    Type
    SerieNr
    DatumAanschaf
    PatchNr -- vul je alleen voor computers

    SYSTEEM
    Computer -- bevat het RocNr van een computer
    Monitor -- bevat het RocNr van een monitor
    Lokaal

    Je kan echter nog verder normaliseren. Zo kan je de APPARATUUR splitsen in APPARATUUR en APPARATUURINGEBRUIK
    APPARATUUR
    ApparaatID -- primary key
    ApparaatType -- 'computer' of 'monitor'
    Merk
    Type

    APPARATUURINGEBRUIK
    RocNr -- primary key
    ApparaatID -- verwijst naar APPARATUUR
    SerieNr -- Neem ik aan dat uniek is per apparaat, hoort anders in APPARATUUR thuis
    DatumAanschaf
    PatchNr

    Waarbij de SYSTEEM tabel blijft zoals die al was. Hierbij ga ik er wel vanuit dat je alleen in het lokaal geïnteresseerd bent als het een systeem betreft; anders staat de apparatuur in het magazijn.
    Ignorance killed the cat. Curiosity was framed.

  4. #4
    Ik zou tot deze opzet komen:

    HARDWARE
    ID
    merk
    type

    LOCATIE
    ID
    lokaal

    INVENTARIS
    ID
    HardwareID
    rocnr
    serienr
    datum aanschaf
    patchnr

    INVENTARISLOCATIE
    ID
    InventarisID
    LocatieID

    INVENTARISKOPPELING
    InventarisID1
    InventarisID2
    Marcel

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Het is wel leuk en aardig dat er steeds meer tabellen komen, maar ik denk niet dat kerkebos hier op staat te wachten. Tenzij dat die (uberhaupt) anders reageert met welke oplossing nu voor hem van toepassing is.
    Je kan normaliseren tot je een ons weegt, maar kerkebos zal toch door de bomen het bos moeten zien en het moeten programmeren.
    Last edited by jkuiper; 03-Mar-08 at 21:27. Reason: spelling
    Delphi is great. Lazarus is more powerfull

  6. #6
    Je kan normaliseren tot je een ons weegt, maar kerkebos zal toch door de bomen het bos moeten zien en het moeten programmeren.
    Maar als kerberos met een verkeerd datamodel aan de slag gaat, dan wordt het straks alleen maar moeilijker voor kerberos om het te programmeren. Een datamodel is een van de eerste stappen van een database applicatie dus laten we hem daar vooral na mee helpen. Een goed datamodel betekent ook gemakkelijker gegevens ophalen en vooral logischer gegevens ophalen. Herbruikbaarheid van je datamodel, etc..

  7. #7
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    ...dus laten we hem daar vooral nu mee helpen.
    Helemaal mee eens Dees!
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  8. #8
    Dankje NGLN, het is gewoon belangrijk om een goede opzet te hebben

  9. #9
    Natuurlijk zijn er grenzen aan het normaliseren, maar ik heb niet het idee dat we hier over die grens gaan.

    En inderdaad, als je datamodel niet klopt gaat dat in het hele project tegen je werken. Aan de andere kant: als je een goed datamodel hebt voelt dat lekker aan en zul je in de toekomst merken dat het makkelijk is om je datamodel uit te breiden.

    Let ook op dat ik er bewust voor kies om technische primary keys te gebruiken. Gegevens die aan de gebruiker getoond of gevraagd worden gebruik ik persoonlijk nooit als primary key. Ooit gaat een keer blijken dat het gegeven bijna uniek is en dan heb je een probleem.
    Marcel

  10. #10
    Senior Member BVerhaar's Avatar
    Join Date
    Sep 2004
    Location
    Zuid Holland
    Posts
    455
    Quote Originally Posted by Marcel View Post
    Ooit gaat een keer blijken dat het gegeven bijna uniek is en dan heb je een probleem.
    True true... Zijn we ooit eens tegenaan gelopen. 6 karakters breed ID van een materieel. Is uniek zei de klant. Dus PK erop. Heeft 5,5 jaar goed gewerkt en toen kwamen ineens materielen in zicht met ID's die hetzelfde waren als bestaande en die toch een ander materieel waren.

  11. #11
    TNldPuinhoop pelleke's Avatar
    Join Date
    Apr 2002
    Location
    Den Haag! ! ! ! ! ! IDE: BDS 2007
    Posts
    409
    Dan nog verdient het de voorkeur om een tweede id-nummering te maken. Het voelt in mijn filosofie gewoon niet goed aan om zelf je id-nummers op te geven aan de hand van bestaande informatie. Maak gewoon een PK die zichzelf automatisch increment, en gebruik die waarde alleen in selecties, dan kom je nooit in de problemen. En voor databases met minder dan 1 miljoen records, hoef je je over 't algemeen geen zorgen te maken over 1 veldje extra. (Uitzonderingen daar gelaten.)
    Aut viam inveniam aut faciam!

    Google might answer your questions faster than me...

  12. #12
    Senior Member Henk Schreij's Avatar
    Join Date
    Sep 2002
    Location
    Heino (Raalte)
    Posts
    1,465
    Quote Originally Posted by Marcel
    Ooit gaat een keer blijken dat het gegeven bijna uniek is en dan heb je een probleem.
    Quote Originally Posted by BVerhaar
    True true... Is uniek zei de klant...en toen kwamen ineens materialen in zicht met ID's die hetzelfde waren als bestaande
    Hier mijn blunder:
    Alle binnenvaart schepen hebben een uniek EuropaNr (soort kenteken). Absoluut zeker uniek. Stom genoeg heb ik toen daar een PK van gemaakt.
    En toen ..
    Waren er coasters die ook in het systeem moeten omdat ze de rivier op varen, zonder EuropaNr dus.
    Had ik daar wat voor verzonnen, kwam de volgende ellende:
    Een nieuw schip krijgt soms zijn kenteken pas na keuring. Maar mag al wel varen. Zodat ik weer geen uniek gegeven had.

    Wijze les: Iets wat uniek is, moet je toch niet de PK maken want het kan toch ontbreken/veranderen/dubbel voorkomen/etc.

  13. #13
    TNldPuinhoop pelleke's Avatar
    Join Date
    Apr 2002
    Location
    Den Haag! ! ! ! ! ! IDE: BDS 2007
    Posts
    409
    Quote Originally Posted by Marcel View Post
    Natuurlijk zijn er grenzen aan het normaliseren, maar ik heb niet het idee dat we hier over die grens gaan.

    En inderdaad, als je datamodel niet klopt gaat dat in het hele project tegen je werken. Aan de andere kant: als je een goed datamodel hebt voelt dat lekker aan en zul je in de toekomst merken dat het makkelijk is om je datamodel uit te breiden.
    Juist. Een data-model bedenken hoef je (als je het goed doet) maar 1 keer te doen, dus kan je daar beter iets meer tijd voor nemen. Elke 10 minuten extra tijd in je modellering kan je 10 dagen schelen in je ontwikkeling...

    De 'grenzen' zijn voor mij ontzettend wijd, liever een databasetabel extra dan onlogische programmacode en vreemde constructies (zoals bijvoorbeeld kommagescheiden ID-nummers in een STRING veld ofzo voor many to many relaties)

    @Henk Schreij:
    Jouw wijze les zou ik liever zo willen formuleren:
    "Gebruik nooit een PK op een veld dat (behalve als uniek identificatienummer) iets te maken heeft met de informatie. De PK moet een totaal nietszeggend veldje zijn."
    In mijn databases wordt de id altijd automatisch ingevuld door de database server. Dan kan je je dus helemaal nooit vergissen.
    Last edited by pelleke; 07-Mar-08 at 13:14. Reason: typo
    Aut viam inveniam aut faciam!

    Google might answer your questions faster than me...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •