Computermerk - Netwerkkaart - Videokaart - IPnummer - Type Geheugen - Processor
Van alle dingen kan bijna redundantie ontstaan..... hoe kan je dat nou normaliseren??
Ik heb dit ooit wel eens op school gehad, maar is helaas een beetje weggezakt.
_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*
ACWW NWFC id: 2921-2609-9160 nick: tbone Town: Finetown
Fiets
en dan de onderdelen middels een koppel tabel koppelen aan een pc...
edit::
je kan het zelf nog bonter maken trouwens en netter
Elk CI (configuratie item) gewoon in een tabel met standaard informatie, plus een refrentie naar een specefieke entry, namelijk die CI afhankelijk (bijvoorbeeld een netwerk kaart heeft een transmissie snelheid)
[Dit bericht is gewijzigd door markvleth op 15-05-2003 14:52]
quote:lijkt me wel handig om eerst te weten wat precies de omstandigheden zijn bij deze database..
Op donderdag 15 mei 2003 14:43 schreef EggsTC het volgende:
Ok, je hebt een database maar wil redundantie voorkomen. Hoe kan je dat doen??? Je hebt deze tabel :
Computermerk - Netwerkkaart - Videokaart - IPnummer - Type Geheugen - Processor
Van alle dingen kan bijna redundantie ontstaan..... hoe kan je dat nou normaliseren??
Zoek eerst maar uit wat de primary key is
quote:en welke normaalvorm heb je dan?
Op donderdag 15 mei 2003 14:46 schreef markvleth het volgende:
Elk onderdeel (behalve pc in een apparte tabel) met daarin standaard dingen als leverancier, en misschien nog specefieke omschrijving
en dan de onderdelen middels een koppel tabel koppelen aan een pc...
* ik vond normaliseren op school altijd best leuk
_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*
ACWW NWFC id: 2921-2609-9160 nick: tbone Town: Finetown
Fiets
quote:brr.. normaliseren... me ergste nachtmerrie .. scheen t nog wel te snappen.. had er een flinke voldoende voor.
Op donderdag 15 mei 2003 14:50 schreef kareltje_de_grote het volgende:[..]
en welke normaalvorm heb je dan?
* ik vond normaliseren op school altijd best leuk
Volleges mij...
quote:Dan ben je klaar
Op donderdag 15 mei 2003 14:50 schreef kareltje_de_grote het volgende:[..]
en welke normaalvorm heb je dan?
* ik vond normaliseren op school altijd best leuk
quote:
Op donderdag 15 mei 2003 14:53 schreef markvleth het volgende:[..]
Dan ben je klaar
de perfecte normaalvorm bestond nl niet volgens mijn docent.
_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*
ACWW NWFC id: 2921-2609-9160 nick: tbone Town: Finetown
Fiets
quote:configuratie item als in de ITIL methode
Op donderdag 15 mei 2003 14:46 schreef markvleth het volgende:
edit::je kan het zelf nog bonter maken trouwens en netter
Elk CI (configuratie item) gewoon in een tabel met standaard informatie, plus een refrentie naar een specefieke entry, namelijk die CI afhankelijk (bijvoorbeeld een netwerk kaart heeft een transmissie snelheid)
quote:Aangezien de meeste informatie die je kan invullen behoort tot een vrij kleine groep elementen (hoeveel computermerken zijn er, hoeveel videokaarten, ....) kan je die info bijvoorbeeld in een aparte tabel zetten. Tabel Computermerken bijvoorbeeld met velden MerkID (integer) en Merk (Varchar).
Op donderdag 15 mei 2003 14:43 schreef EggsTC het volgende:
Ok, je hebt een database maar wil redundantie voorkomen. Hoe kan je dat doen??? Je hebt deze tabel :
Computermerk - Netwerkkaart - Videokaart - IPnummer - Type Geheugen - Processor
Van alle dingen kan bijna redundantie ontstaan..... hoe kan je dat nou normaliseren??
Zodoende hoef je in je hoofdtabel alleen maar een nummer te zetten. Zodoende sla je geen redundante informatie op.
Trekt bij warm weer een poncho aan
quote:dat klopt.. en soms moet je ook gewoon denormaliseren
Op donderdag 15 mei 2003 14:54 schreef kareltje_de_grote het volgende:[..]
de perfecte normaalvorm bestond nl niet volgens mijn docent.
Dat is toch juist redundantie? Daarom vroeg ik het me af.
quote:Primarykey moet ik nog toewijzen...
Op donderdag 15 mei 2003 14:47 schreef NDAsilenced het volgende:[..]
lijkt me wel handig om eerst te weten wat precies de omstandigheden zijn bij deze database..
Zoek eerst maar uit wat de primary key is
sterker nog : de database bestaat (nog) niet eens.
quote:toch wel iig zo weinig mogelijk redundantie
Op donderdag 15 mei 2003 14:58 schreef markvleth het volgende:
Overigens moet het doel bij het ontwerpen van een DB nooit zijn om geen redundantie te hebben. Het doel moet zijn om een representatie te hebben van de werkelijkheid, en alle mogelijke (geldige) situaties te kunnen opvangen...
Computermerk - Netwerkkaart - Videokaart - IPnummer - Type Geheugen - Processor
Niet genormaliseerd heb je bijvoorbeeld als vulling:
ABC - DEF - GHI - JKL - MNO - PQR
ABC - DEF - GHI - JKL - MNO - STU
ABC - DEF - GHI - JKL - VWX - PQR
Wel genormaliseerd maak je een extra tabel:
Tabel Processor:
Pr_id - Processor
Vulling:
Tabel Processor:
1 - PQR
2 - STU
Tabel X:
ABC - DEF - GHI - JKL - MNO - 1
ABC - DEF - GHI - JKL - MNO - 2
ABC - DEF - GHI - JKL - VWX - 1
En dit kun je dus voor elke kolom doen.
Wat je ook kunt doen, maar dat is een stap verder, is bepaalde combinaties maken... bv.
Tabel Processor_Geheugen:
ID - Type Geheugen - Processor
11 - MNO - PQR
12 - VWX - PQR
13 - MNO - STU
(Of :
11 - MNO - 1
12 - VWX - 1
13 - MNO - 2
plus tabel Processor zoals hierboven
etc
)
Tabel X:
ABC - DEF - GHI - JKL - 11
ABC - DEF - GHI - JKL - 13
ABC - DEF - GHI - JKL - 12
En dit kan ook in eindeloze variaties...
Overigens heeft dit niet zozeer met redundantie te maken, is puur normaliseren, en niet altijd nuttig (bv in het geval van platte data zoals je nu hebt, maar als dit een onderdeel van een voorraadsysteem is kan het wel handig zijn).
quote:Dat spreekt voor zich natuurlijk, ook al ga je voor performance altijd zo min mogelijk redundantie
Op donderdag 15 mei 2003 15:00 schreef domolanglekker het volgende:[..]
toch wel iig zo weinig mogelijk redundantie
quote:indd laat de topicstarter eerst maar eens een fantsoenlijke database analyse maken. en ga dan de boel meer eens lekker over hoop halen door te normaliseren.
Op donderdag 15 mei 2003 15:09 schreef dexter12win het volgende:
wat heeft een ip adres te maken met de configuratie van een compu ?
_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*
ACWW NWFC id: 2921-2609-9160 nick: tbone Town: Finetown
Fiets
quote:Hoeft toch juist niet? Je zet 1 keer die Geforce2 in die tabel met een eigen id, en vervolgens koppel je die id in een andere tabel aan de computer.
Op donderdag 15 mei 2003 14:57 schreef EggsTC het volgende:
Maar als ik Videokaart in 1 tabel zet kan je in die tabel wel 15000 keer krijgen : GeForce 2 bla bla??
Dat is toch juist redundantie? Daarom vroeg ik het me af.
quote:Edit: zoals Ranja het dus doet...had geen zin om zo'n lange uitleg te maken
Op donderdag 15 mei 2003 15:14 schreef Darkysdust het volgende:[..]
Hoeft toch juist niet? Je zet 1 keer die Geforce2 in die tabel met een eigen id, en vervolgens koppel je die id in een andere tabel aan de computer.
quote:Dus voor iedere videokaart een aparte tabel
Op donderdag 15 mei 2003 15:14 schreef Darkysdust het volgende:[..]
Hoeft toch juist niet? Je zet 1 keer die Geforce2 in die tabel met een eigen id, en vervolgens koppel je die id in een andere tabel aan de computer.
krijg je aardig wat tabellen? (of per gebruikt merk videokaart een tabel met alle videokaarten van dat merk?)
quote:Dan krijg je in die andere tabel toch iedere keer het zelfde "ID-nummer" wat ook weer redundantie is........
Op donderdag 15 mei 2003 15:14 schreef Darkysdust het volgende:[..]
Hoeft toch juist niet? Je zet 1 keer die Geforce2 in die tabel met een eigen id, en vervolgens koppel je die id in een andere tabel aan de computer.
quote:Lijkt me beter om 1 tabel te hebben voor alle videokaarten. Hoeveel videokaarten zal je hebben? Hooguit enige 10tallen, desnoods 100 stuks. Daar ga je niet weer subtabellen voor maken.
Op donderdag 15 mei 2003 15:18 schreef domolanglekker het volgende:[..]
Dus voor iedere videokaart een aparte tabel
Trekt bij warm weer een poncho aan
quote:Ja, maar die redundantie (dezelfde ID nummers in de hoofdtabel) blijf je houden, omdat de gegevens zelf redundant zijn (er zijn machines met dezelfde videokaart). Maar je kan beter redundant zijn in een integer, dan in een lange uitleg met characters. Een typefoutje is snel gemaakt, bovendien neemt het veel extra opslag in.
Op donderdag 15 mei 2003 15:24 schreef EggsTC het volgende:[..]
Dan krijg je in die andere tabel toch iedere keer het zelfde "ID-nummer" wat ook weer redundantie is........
Trekt bij warm weer een poncho aan
(geen idee of het goed is, ga het nu ook lezen).
Overigens is het zelden wenselijk om verder dan de derde normaalvorm te normaliseren. Soms is het zelfs wenselijk om helemaal niet te normaliseren.
-edit- je kunt beter zeggen dat het soms wenselijk is om maar t/m de eerste normaalvorm te normaliseren.
[Dit bericht is gewijzigd door sop op 15-05-2003 15:39]
quote:Ja hoor.
Op donderdag 15 mei 2003 15:38 schreef EggsTC het volgende:
Kunnen er meerdere sleutels (die verwijzen naar vreemde sleutels) in een tabel?
quote:Met Primary Keys wel samengestelde keys (dus 1 Primary key die bestaat uit de combinatie van meerdere velden), met Foreign Keys (verwijzgingen naar andere tabellen) zoveel je maar wilt.
Op donderdag 15 mei 2003 15:38 schreef EggsTC het volgende:
Kunnen er meerdere sleutels (die verwijzen naar vreemde sleutels) in een tabel?
Trekt bij warm weer een poncho aan
quote:Je bedoeld:
Op donderdag 15 mei 2003 15:38 schreef EggsTC het volgende:
Kunnen er meerdere sleutels (die verwijzen naar vreemde sleutels) in een tabel?
code:Waarbij de velden met een =>FK verwijzen naar een andere tabel.[table: Computer]
ID
MonitorID => FK
ToetsenbordID =>FK
MuisID => FK
PrinterID =>FK
M.a.w.: ja dat kan.
-edit-
Wellicht handig om even bij stil te staan:
Primary Key : Unieke waarden in een tabel. De waarde van dat veld mag maar 1 keer voorkomen in de tabel.
Foreign Key: De waarde van dit veld in de tabel mag wel meerdere malen in deze tabel voorkomen. De waarde van dit veld wijst echter naar een primairy key in een andere tabel.
Een primairy key definieer je in de structuur van de tabel. De foreign key wordt gedefinieerd in de relatie tussen de tabellen.
[Dit bericht is gewijzigd door sop op 15-05-2003 15:47]
quote:Alleen wil je dit eigelijk zoveel mogelijk vermijden...
Op donderdag 15 mei 2003 15:40 schreef Lucille het volgende:[..]
Met Primary Keys wel samengestelde keys (dus 1 Primary key die bestaat uit de combinatie van meerdere velden), met Foreign Keys (verwijzgingen naar andere tabellen) zoveel je maar wilt.
quote:Normaliseren is superhandig, het is en blijft redelijk overzichtelijk, je hebt weinig tot geen redundantie, maar je krijgt er verrekte rottige query's van
Op donderdag 15 mei 2003 14:50 schreef kareltje_de_grote het volgende:[..]
en welke normaalvorm heb je dan?
* ik vond normaliseren op school altijd best leuk
Maargoed, wij hebben dus ook de 1e t/m 4e normaalvorm behandeld, en dan ging op zich redelijk. Een makkelijk programma hierbij is SDW, die je redelijk helpt met het normaliseren, want goed normaliseren is nog helemaal geen eitje ben ik achter gekomen.
Ik denk dat in 80% van de gevallen ook geeneens genormaliseerd wordt. De meeste mensen denken van: wat heb ik nodig, wat wil ik opslaan, en hoppa, beng, knallen ze 1 a 2 tabellen eruit waar alles ingepropt is
Misschien dat je hier nog wat aan hebt!
Succes!
quote:Je wilt Foreign Keys vermijden?
Op donderdag 15 mei 2003 15:44 schreef markvleth het volgende:[..]
Alleen wil je dit eigelijk zoveel mogelijk vermijden...
Trekt bij warm weer een poncho aan
quote:Samengestelde Primary Keys vermoedelijk.
Op donderdag 15 mei 2003 15:47 schreef Lucille het volgende:[..]
Je wilt Foreign Keys vermijden?
quote:Ik denk dat als je niet normaliseert het programmeren/onderhouden van de inhoud van je database nog veel rottiger wordt.
Op donderdag 15 mei 2003 15:46 schreef ReSiever het volgende:[..]
Normaliseren is superhandig, het is en blijft redelijk overzichtelijk, je hebt weinig tot geen redundantie, maar je krijgt er verrekte rottige query's van
En zo moeilijk zijn joins nou ook weer niet.
quote:Ja, dat snap ik ook niet helemaal... dan is het principe van normaliseren dus al gevlogen....
Op donderdag 15 mei 2003 15:47 schreef Lucille het volgende:[..]
Je wilt Foreign Keys vermijden?
quote:Nee, joins zijn niet moeilijk, dat besef ik wel, maar je moet ermee gewerkt hebben. En mensen kiezen nou eenmaal voor de makkelijke manier.. Hup alles in 1 keer met een SELECT *, en daaruit lezen... maar daar is bij normaliseren geen sprake van
Op donderdag 15 mei 2003 15:50 schreef sop het volgende:[..]
Ik denk dat als je niet normaliseert het programmeren/onderhouden van de inhoud van je database nog veel rottiger wordt.
En zo moeilijk zijn joins nou ook weer niet.
quote:Ach, soms ontkom je er niet aan. Gewoonweg omdat er geen andere manier bestaat om op 1 veld een primary key te zetten.
Op donderdag 15 mei 2003 15:49 schreef Litpho het volgende:[..]
Samengestelde Primary Keys vermoedelijk.
Trekt bij warm weer een poncho aan
quote:Als je zo graag een platte database wilt hebben, dan maak je toch gewoon een view aan. Kun je gewoon SELECT * doen.
Op donderdag 15 mei 2003 15:52 schreef ReSiever het volgende:[..]
Nee, joins zijn niet moeilijk, dat besef ik wel, maar je moet ermee gewerkt hebben. En mensen kiezen nou eenmaal voor de makkelijke manier.. Hup alles in 1 keer met een SELECT *, en daaruit lezen... maar daar is bij normaliseren geen sprake van
quote:ja sorry, ik doelde inderdaad op samengestelde sleutels. Ja de enige keer dat je er niet aan ontkomt is een veel op veel relatie en je dus gebruik maakt van een koppeltabel. Voor alle andere situaties gebruik je slechts een veld voor de pk...
Op donderdag 15 mei 2003 15:52 schreef Lucille het volgende:[..]
Ach, soms ontkom je er niet aan. Gewoonweg omdat er geen andere manier bestaat om op 1 veld een primary key te zetten.
quote:Ja, maar niet iedereen heeft daar zoveel verstand van he
Op donderdag 15 mei 2003 15:53 schreef sop het volgende:[..]
Als je zo graag een platte database wilt hebben, dan maak je toch gewoon een view aan. Kun je gewoon SELECT * doen.
Ik vind normaliseren ok, maar je moet dan ook wat verstand van SQL hebben, dat bedoelde ik ermee te zeggen.
quote:En hoe maak je zo'n view aan?
Op donderdag 15 mei 2003 15:53 schreef sop het volgende:[..]
Als je zo graag een platte database wilt hebben, dan maak je toch gewoon een view aan. Kun je gewoon SELECT * doen.
code:dus volgens mij schiet je daar nog niet veel mee op, ben je nog bezig met SQLlen.CREATE VIEW blah
SELECT hupeldepup, FROM huppeldepup WHERE blahblah = huppeldepup enz.
_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*_-*-_-*
ACWW NWFC id: 2921-2609-9160 nick: tbone Town: Finetown
Fiets
quote:Een database ontwerp maken zonder kennis van SQL lijkt me op zich al helemaal fout. Maar ja, zo heb ik genoeg foute database ontwerpen gezien in de afgelopen jaren.
Op donderdag 15 mei 2003 15:56 schreef ReSiever het volgende:[..]
Ja, maar niet iedereen heeft daar zoveel verstand van he
Trekt bij warm weer een poncho aan
quote:Ja, maar die kennis van SQL komt meestal niet verder dan een SELECT * FROM tabel .. en dan zo af en toe nog een WHERE erbij
Op donderdag 15 mei 2003 15:58 schreef Lucille het volgende:[..]
Een database ontwerp maken zonder kennis van SQL lijkt me op zich al helemaal fout. Maar ja, zo heb ik genoeg foute database ontwerpen gezien in de afgelopen jaren.
PCnummer(Primair)
Merk
Model
Serienummer
Serienummer
Videokaart
Geluidskaart
Processor
Geheugen
Harddisk
AantalUSB
Uitbreidingsmogelijkheden
Gebruiker
Software_ID
IPnummer
IPnummer
Type netwerkkaart
MAC Adres
Software_ID
Besturing
Extra Software
Uitbreidingsmogelijkheden
AGP
ISA
PCI
Gebruiker
Afdeling
Kan hij nog verder??
Trekt bij warm weer een poncho aan
quote:laat maar is zien dan.
Op donderdag 15 mei 2003 16:05 schreef Lucille het volgende:
Ik zou het echt helemaal anders opzetten, maar of je dat wilt is een tweede.
quote:helemaal mee eens, dit is op ze zachts gezegd... ach laat ook maar...
Op donderdag 15 mei 2003 16:05 schreef Lucille het volgende:
Ik zou het echt helemaal anders opzetten, maar of je dat wilt is een tweede.
En daar vervolgens de rand apparatuur weer aanhangen.
die randapparatuur kun je dan vervolgens weer normaliseren.
Tabel artikel:
veld 1 :id ->prim key
veld 2 :naam -> naam van onderdeel (Hercules Videokaart)
veld 3 :beschrijving -> beschrijving videokaart
veld 4 :specs -> specs videokaart
veld 5 :oid -> link naar tabel waar soorten onderdelen in staan (videokaart, geluidskaart)
tabel onderdeel:
veld 1: id-> primkey
veld 2 :onderdeelnaam (geluidskaart)
veld 3: misschien nog iets extra's
zoiets zou ik waarschijnlijk doen...
PC_ID (integer, Primairy Key)
Type (integer, Foreign Key -> PC_Types)
Serienummer
Gebruiker_ID (integer, FK -> Gebruiker_Info)
IP_Nummer
MAC_Adres
AantalUSB
AGP (integer wat aantal aangeeft, eventueel gesplitst in totaal en in gebruik)
ISA (idem)
PCI (idem)
Tabel PC_Types
Type_ID (integer, PK)
Merk
Type_Uitvoering
Tabel Hardware_Info
PC_ID (integer, FK -> PC_Info)
Hardware_ID (FK -> Hardware_Types)
Tabel Hardware_Types
Hardware_ID (integer, PK)
Hardware_Type (integer wat aangeeft; Moederbord, Videokaart, Geluidskaart, Processor, Geheugen, Harddisk)
Merk
Uitvoering
Opmerkingen
Tabel Software_Info
PC_ID (integer, FK -> PC_Info)
Software_ID (FK -> Software_Types)
Besturing
Extra Software
Tabel Software_Types
Software_ID (integer, PK)
Naam
Versie
Tabel Gebruiker_Info
Gebruiker_ID (integer, PK)
Naam
Afdeling
Zoiets dus. Kost misschien iets meer moeite om het de eerste keer op te zetten, maar het onderhoud gaat sneller en je queries worden heel erg simpel. Je zoekt de PC_ID en aan de hand daarvan heb je een hele simepele query wat betreft de hardware en software die in de PC zit.
Trekt bij warm weer een poncho aan
quote:Lijkt me niet, anders is het geen serienummer.
Op donderdag 15 mei 2003 16:06 schreef markvleth het volgende:
Kan een pc hetzelfde serie nummer hebben??????
Trekt bij warm weer een poncho aan
quote:Mij ook niet, maar volgens het model van EggsTC wel...
Op donderdag 15 mei 2003 16:45 schreef Lucille het volgende:[..]
Lijkt me niet, anders is het geen serienummer.
|
|
