datenbankplanung richtig?

[zerberos]

Hallo,

ich bin gerade eine datenbank am planen mit der die verschiedene software und hardware verwaltet wird bei uns. es soll u.a. möglich sein sich anzeigen zu lassen welche hard und software ein nutzer hat und welche in einen bestimmten raum steht


meine planung sieht bis jetzt so aus

mitarbeiter
-----------
userid
anrede
vorname
nachname
telefonnummer
raum


standort
--------
raum
ort

software
--------
id
name
hersteller
typ

hardware
--------
seriennummer
typ
hersteller
bezeichnung
kaufdatum

hardware_details (wenn die hardware ein rechner ist)
----------------
cpu
arbeitsspeicher
festplatte
grafikkarte
laufwerk
netzwerk


Was haltet ihr davon? was brauch ich noch für tabellen damit das funktioniert?

 

[LasMiranda]

ich würde einfach mal sagen, dass eine "Gemeinsamkeit" fehlt, oder wie willst du die Hardware den MAs zuordnen?

Die Standort-Tabelle finde ich persönlich sinnlos, da der Raum sicherlich nie den Ort ändern wird.

 

[zerberos]

minst du mit gemeinsamkeit eine verknüfungstabelle

so in der art

namekeineahnung
-----------------
mitariter-id
hardware-id
raum
software-id

 

[justme69]

spendiere jeder Tabelle auch eine eigene eindeutige ID (Nominalisierung). DatensatzNr oder DsId, DS-SerienNr o.ä.

Dann kannst du weiteres überdenken.

Verknüpfungstabekllen sind ebenfalls erforderlich

 

[paigo]

Dito, du benötigst ja einen Primary Key, welcher am besten mit jedem Eintrag automatisch inkrementiert wird. Ich denke doch, dass du immer mal Einträge hinzufügen musst.

 

[TriloByte]

Bei der Planung ist zusätzlich auf jeden Fall wichtig, welche Form von Zugriffen im späteren System erwartet werden und in welcher Häufigkeit. Diese Frage kann je nach Entity Typ unterschiedlich beantwortet werden.
Werden viele Lesezugriffe und wenig Einfügeoperationen erwartet, kannst du dein Datenmodell so gestalten, dass die Lesezugriffe performanter und das Einfügen möglicherweise etwas aufwendiger ist.

Sprich redundante Speicherung kann Joins sparen und lesende Anfragen beschleunigen, bringt jedoch erhöhten Aufwand bei Sicherstellung der Konsistenz mit sich. Auch kann es sein, dass einige Attribute von einer bestimmten Tabellen sehr selten abgefragt werden, andere hingegen sehr häufig. In diesem Fall könnte eine vertikale Fragmentierung Sinn machen. Anfragen, die alle Attribute betreffen sind dafür zwar langsamer, aber die häufig benötigten Attribute können schneller abgefragt werden.

Außerdem wäre noch wichtig, wie hoch du das Datenaufkommen einschätzt. Wenn du mit ein paar 100 Datensätzen rechnest sind manche Optimierungsüberlegungen vermutlich irrelevant.