[Database] Relaties

[Verwijderd]

Ik ben bezig met een driverdatabase maar ik loop vast op de relaties. Het lijkt mij namelijk dat het allemaal 'een op veel' relaties moeten zijn maar ik weet het niet zeker.

Hier is mijn tabel ontwerp:



Het normaliseren lijkt me wel goed gelukt aangezien er geen dubbele gegevens in voor gaan komen als ik het volgens dit model doe.

Zou iemand me kunnen helpen met de relaties?

[Verwijderd]

Wat bedoel je precies met Fabrikant_onderdeel? Wat wil je daar in opslaan? En Type_onderdeel?

[Verwijderd]

Ik zal even een kleine toelichting geven:

- Fabrikant_PC: Hier komt te staan door wie de PC is samen gesteld (Compaq, Dell etc)
- Type_PC: Hier komt te staan wat voor type het is (Compaq Pressario S3000 etc)
- Fabrikant_onderdeel: Hier komt te staan van welke fabrikant het onderdeel is (3com, Matrox, etc)
- Type_onderdeel: Hier komt te staan van wat voor onderdeel het is (netwerkkaart, modem, videokaart etc)

Er moet dan gezocht kunnen worden op combinaties van de bovenstaande gegevens.

Ik hoop dat dit helpt

[BasSpruit]

aan je huidige plaatje te zien, zou SQL server hem al automatisch kunnen pakken als de de _id velden als sleutel instelt. Ook acces pakt ze dan al automatisch.

lukt dat niet, dan is alles aan de linkerkant 1 en alles aan de rechterkant meer. ik zou echter de kolomnamen in de rechtertabel wat aanpassen, zodat deze overeenkomen met de sleutelnamen uit de linkertabellen. snap je wat ik bedoel.

[Rotjeknor]

offtopic:
Heb je die lijnen van relaties handmatig getekend, of is het jou gelukt om die cellen met elkaar te verbinden? Ik ben namelijk al tijden opzoek naar een makkelijke oplossing om die relaties fatsoenlijk te kunnen tekenen, dus gewoon lijntje trekken tussen 2 cellen als er een relatie is...

[Eelis]

.

[ Voor 98% gewijzigd door Eelis op 18-02-2015 19:46 ]

[BasSpruit]

in access kijk je onder relaties en onder sql-server onder diagrams. beide zijn microsoft programma`s. kaasie

[cue]

Ja ik zou eerder een keuze maken per OS. Zijn namelijk veel verschillende win98 en win2k/xp drivers. is denk ik handig als je daar ook op kan zoeken.

[Verwijderd]

Eelis schreef op 15 May 2003 @ 10:28:
Ik vind het vreemd dat je onderscheid maakt tussen een driver voor een stuk hardware in bv een Compaq en hetzelfde stuk hardware in bv een Dell.

Daar had ik nog niet aan gedacht.. Het kan natuurlijk zo zijn dat bv een 3com netwerkkaart in zowel Dell als Compaq gebruikt wordt. Wat weer zal leiden tot dubbel ingevoerde drivers..

[Verwijderd]

Als jij voor iedere computer alle bijbehorende drivers wil bijhouden, dan klopt dit ontwerp niet, mijns inziens. Er zijn zat drivers die compleet afhankelijk zijn van een bepaald onderdeel, en helemaal onafhankelijk van de PC.

Misschien moet je eens denken aan de volgende tabellen:
FABRIKANT
-------------
ID
Naam
etc

ONDERDEELTYPE
---------------------
ID
Naam
Omschrijving

ONDERDEEL
---------------
ID
OnderdeelTypeID
FabrikantID
Revisie

PART
------
ID
OnderdeelID
SerialNumber
ComputerID

COMPUTER
--------------
ID
Naam
FabrikantID

OPERATINGSYSTEM
------------------------
ID
Naam
FabrikantID

DRIVER
---------
ID
Naam
FabikantID
ComputerPartID

DRIVERVERSIE
------------------
ID
DriverID
Versie
Datum
ReleaseNotes

Even wat uitleg over de ONDERDEEL en PART tabellen. Als je bijvoorbeeld 2 dezelfde 3COM netwerkkaarten hebt (met dezelfde rivisie, mind you), zijn ze hetzelfde ONDERDEEL, maar een verschillend PART, omdat ze in bijv verschillende computers kunnen zitten, maar wel dezelde driver hebben.

Je kunt nog verder uitbreiden, door ook revisie uit de ONDERDEEL tabel te normaliseren, maar dit vond ik een beetje overdreven.

Al deze relaties zijn 1 op n relaties. Als voorbeeld de relatie Fabrikant <--- Onderdeel: een Fabrikant kan meerdere onderdelen maken, maar een onderdeel kan maar door 1 fabrikant gemaakt worden.

Enjoy

[Verwijderd]

Ik zou graag de fabrikanten van onderdelen en PC's gescheiden houden maar ik neem aan dat dit op te lossen is door gewoon de fabrikant tabel op te splitsen in een pc fabrikant tabel en een onderdeel fabrikant tabel.

[Verwijderd]

Verwijderd schreef op 15 May 2003 @ 10:44:
Ik zou graag de fabrikanten van onderdelen en PC's gescheiden houden maar ik neem aan dat dit op te lossen is door gewoon de fabrikant tabel op te splitsen in een pc fabrikant tabel en een onderdeel fabrikant tabel.

Waarom zou je dat willen scheiden?

[Verwijderd]

Omdat ik een zoekfunctie wil maken waarin je zowel op PC merk/type als Onderdeel merk/type kan zoeken en dan heeft het weinig nut om PC en onderdeel fabrikanten door elkaar heen te gooien.

[Verwijderd]

Dan maak je
FABRIKANTTYPE
--------------------
ID
Type (Hierin staat dan bijv 'ComputerFabrikant', 'OnderdelenFabrikant' of 'Alles')

Vervolgens neem je in FABRIKANT een FabrikantTypeID op, om aan te geven wat de fabrikant maakt. Dit is een meer gestruuctureerde oplossing. Alleen als je daadwerkelijk verschillende gegevens voor de verschillende fabrikanttypes gaat opslaan is het zinvol de gegevens te scheiden.

[Verwijderd]

Hm, volgens mij is de bedoeling niet over gekomen.

Het moet een 'simpele' database worden waarin drivers worden verzameld die gebruikt zijn/worden voor gerepareerde PC's. Het gaat dus niet om alle drivers van een werkstation maar meer om een centrale verzamelpunt van drivers die gebruikt zijn zodat ze makkelijk toegankelijk zijn voor de volgende keer.

Wat jij aangeeft is volgens mij bedoeld als database waarin per werkstation alle drivers worden opgeslagen gekoppeld aan het serienummer van het werkstation. Dit is dus te complex voor hetgene waarvoor het gebruikt zal worden.

Het enige wat ik eigenlijk wil doen is een file (de driver zelf) koppelen aan een beschrijving:

- Merk/Fabrikant PC (optioneel)
- Type PC (optioneel)'
- Merk/Fabrikant onderdeel (verplicht)
- Type onderdeel (verplicht)
- Naam onderdeel (verplicht)
- OS versie (verplicht)
- Driver versie (verplicht)

Het lijkt mij dus dat er geen overvloed aan tabellen gebruikt hoeft te worden om dit te realiseren?

[Mickman]

Bij dit soort ontwerpen hoef je nog geen foreign keys op te nemen. Die komen terug in het representatieve model.