Office: (Office 2003) Fehlerdatenbank

Hallo Zusammen und ein frohes neues Jahr.

Da ich noch an den absoluten anfängen ,was VBA und Access generell betrifft, stehe habe ich eine kurze Frage: Ich möchte eine Fehlerdatenbank erstellen, in der ich und mein Kollege über verschiedene Hersteller verschiedene Probleme mit Lösungen eintragen kann,d.h ich stelle mir ein Formular vor, in dem ich über z.B. eine dropdown Liste die einzelnen Hersteller auswählen und dann in einem Feld das Problem schreiben kann. Desweiteren möchte ich natürlich auch das dann mir die schon vorgekommenen Probleme mit Lösungen angezeigt werden. Ich hoffe Ihr könnt so einigermassen verstehen, wie ich mir das vorstelle. *rolleyes.gif*

Kann ich sowas mit Access umsetzen?

:)

 

Ja, Sowas ist grundsätzlich mit Access möglich.

Wobei brauchst Du konkret Hilfe?
Datenmodell? Abfragendesign? Formulardesign?

 

Hi,

möglich ist das und auch nicht das schwierigste. Allerdings gibt es ja schon Bugtracker, zwar basieren die meisten auf MySQL, aber evtl ist es ja eine Alternative.

 

Also da ich überhaupt keine Ahnung habe wie ich dieses Vorhaben angehen soll,brauch ich eigentlich bei allem ersteinmal Hilfe *depressed ,was aber nicht bedeuten soll das ich mir hier alles vorkauen lassen möchte *tongue.gif*

 

Dann empfehle ich als erstes einen Bleistift, Spitzer, Radiergummi und Papier *wink.gif*

Das ist ernster gemeint als evtl. vermutet.
Als erstes solltest Du Dir Gedanken darüber machen, was wo und wie gespeichert werden soll -> Datenmodellierung

Wenn das theoretisch auf dem Papier festgehalten wurde und so passt, kann man es entsprechend in Tabellen und relationalen Beziehungen umsetzen.

Anschliessend werden notwendige Abfragen erstellt.

Erst danach kommen Formulare/Berichte; also die GUI.

Für den Einstieg in das Thema könnte Dir der Link 'relationale DBs' in meiner Signatur helfen.

 

Dann solltest du mit dem Datendesign anfangen, das ist das A und O einer DB. Welche Informationen hast du, wie lassen sich diese gruppieren und in welchen Verbindungen stehen diese?

Dafür sind Zettel und Stift meistens am besten geeignesten *wink.gif*

 

Also Bleistift und Papier ist eine gute Idee. Ihr habt sicherlich recht, das man ersteinmal ,ich nenne es mal 'Grundkonzept', hat.

Aber das ist doch ,zumindest für mich, leichter gesat als getan, da ich noch nichteinmal weiß, wie ich das von mir Vorgestellte aufs Papier bringen soll.

Mal sehen....

 

Lies dir mal das hier durch. Damit solltest du zumindest erkennen, in welche Struktur du deine Daten bringen musst. Da wir nicht wissen, um was es dabei eigentlich geht, ist es für uns halt schwer zu helfen.

Bisher wissen wir nur, dass du Fehler, Hersteller und Lösungen hast. Ich stelle mir das so vor, dass du eine Tabelle für Hersteller, Fehler und Lösungen hast. In den 3 Tabellen stehen dann Details zu den entsprechenden Einträgen (Fehlerbeschreibung, Fehlercode, FehlerID) und in einer 4 Tabelle verbindest du alle 3 ID's. Das macht aber nur Sinn, wenn zB ein Fehler bei mehreren Herstellern auftritt oder eine Lösung bei mehrere Fehler hilft. In der 4. Tabelle kann man dann auch noch die Datums mitspeichern (Wann aufgetreten, Wann bearbeitet etc) und zB wer es war und wie es beim Hilfesuchenden ankam. Hier kann man sich aber auch überlegen, ob man das nicht, der Übersichtlichkeit wegen, lieber in eine separate 1:1 Tabelle verbindet.

 

Also die Sach ist folgenermassen:
Automobilbranche-> z.B: VW möchte ich auswählen und dann möchte ich ein Problem mit Lösung beschreiben oder eine Lösung zu einem vorher schon eingetragenem Problem sehen. Ich bin mir noch nicht sicher,ob ich auch noch die einzelnen Motoren,also z.B: 1,6l oder 2,0l zur Auswahl haben möchte, aber so ungefähr stelle ich mir die Datenbank vor.

 

Die Entscheidung können wir Dir auch nicht abnehmen... das ist genau die Aufgabe, die Du jetzt erstmal bewerkstelligen musst.
"Welche Informationen brauche ich wofür und wie möchte/muss ich sie verteilen und wie detailiert müssen sie vorgehalten werden?"

Über die Darstellung und Bedienung

mach Dir später Gedanken.
Das geht schon Richtung GUI-Programmierung; die wird zwar vom Datenmodell beeinflusst aber gerade deshalb muss das erstmal stehen.

Das ist die Konzeption bzw. die Erstellung des Datenmodells (wie bereits mehrfach angesprochen).

 

Alles klar. Ich werde mich ersteinmal damit auseinander setzen und mich dann morgen mit absoluter Sicherheit wieder hier melden *grins

Aber bis hierhin schon mal vielen Dank für Eure Hilfe *five

 

So,jetzt bin ich wieder bei dem Thema.

Ich habe glaub ich im Moment ein grundsätzliches Verständnis Problem. Ich habe eine Tabelle, die z.B Hersteller heißt und in der soll ich jetzt die einzelnen Datensätze,also VW,BMW, usw. anlegen?
Wenn ich jetzt ein Problem zu VW schreiben möchte, dann wird das in eine Spalte ,die zur Zeile(Datensatz VW) gehört geschrieben?

Oder soll ich jeweils für VW und BMW eine eigene Tabelle machen?

Ich glaube daran liegt bei mir im Moment noch der kasus knacktus.

 

Hi,

du wirst ja bisher schon eine solche Fehlerverwaltung gemacht haben, und sei es als Zettelwirtschaft oder "im Kopf".

Gehe dieses bisherige Verfahren mal durch, um herauszufinden, welche Informationen da vorkommen. Es geht dabei nicht darum, z.B. alle Hersteller (VW, Daimler etc) aufzuführen, sondern es geht darum zu erkennen, dass der Begriff Hersteller überhaupt eine Rolle spielt.

Wenn du also die bisherige Verwaltung durchgehst, frage dich nach "Oberbegriffen" für die Werte, die dir dort unterkommen.

• VW, Daimler, Opel sind Hersteller
• Astra, Colt und /8 sind Modelle;
• Motor, Getriebe, Karosserie und Elektronik sind Komponenten (oder wie man es nennen mag)
• "Motorkontrolleuchte blinkt", "Rauchentwicklung", "Klicken" sind Symptome (o.ä.)
  etc.

Am einfachsten ist das, wenn du dich bei jedem Wert, der dir entgegenspringt, fragst: "wovon ist das eine Beschreibung oder eine Eigenschaft?".
Diese Oberbegriffe sind Prototypen der Tabellen, die später in Access angelegt werden müssen. Prototypen deshalb, weil sie noch überarbeitet werden müssen. Aber immerhin hast du dann schonmal einige Datenhaufen, mit denen man spielen kann.

Endziel des ganzen ist ein Datenmodell, d.h. ein Gefüge von Tabellen, die (faktisch) nur aus 1:n-Beziehungen bestehen. Gleichartieg Daten stehen dabei in einer Tabelle zusammen; alle Hersteller in einer Tabelle, alle Modelle in einer Tabelle (mit Verweis auf den jeweiligen Hersteller), etc.

Eine "BMW-Tabelle" ist also keine gute Idee. BMW-Probleme gehören in die Tabelle "Probleme", wo dann nur ein Kennzeichen auf das betroffenene Modell verweist, das seinerseits auf den Hersteller BMW verweist. Opelprobleme sehen dann optisch genauso aus wie BMW-Probleme und stehen auch in der gleichen Tabelle (!), verweisen aber auf Modelle des Herstellers Opel.

So ein Datenmodell fällt nicht vom Himmel, sondern muss erarbeitet, manchmal bitter ertrotzt werden. Aber es ist die Basis aller Fundamente. :-)

Gruß

 

O.K. Das ist natürlich mehr als einleuchtend.
Aber so viele Unterbegriffe wie die einzelnen Modelle und darunter wie Getriebe,Motor usw. brauch ich eigentlich gar nicht. Auch wenn das natürlich jetzt der falsche Weg ist,weil er das Design anspricht, erklär ich das mal anhand des Formulars und die arbeitsmöglichkeit, die ich mir damit vorstelle:
Also: Ich möchte nach verschiedenen Herstellen auswählen können(in einem Formular) wie z.B: VW,BMW usw. Dann habe ich mir vorgestellt, das dann zu dem ausgewähltem Hersteller die Probleme eintragbar sind mit der dazugehörigen Lösung. Desweiteren habe ich mir vorgestellt, das man zu jedem Problem, innerhalb des jeweiligen Herstellers, quasi eine Überschrift macht, die man dann zur Auswahl hat. In der Überschrift sollte dann das Problem stehen,damit man sich später schneller die Lösung dazu ansehen kann. I
Also um jetzt man aus der Sicht des Formulars zu sprechen: Auswahl Hersteller -> VW, dann die einzelnen Probleme,die schon mal waren als kurze Überschrift (auswählbar z.B: über dropdown) und eine Eingabe möglichkeit für ein neues Problem mit Überschrift. Ich weiß dass das jetzt schon ins Design geht, aber nur mal um meinen vorgestellten Aufbau der Datenbank zu erläutern.

Ich hoffe ich habe das ganze jetzt nicht zu blöd erklärt *entsetzt

Ich weiß das ich den Eindruck mache, als ob ich total überfordert wäre und das trifft leider auch zu und das nervt mich, weil ich nicht die geringste Ahnung habe, wie ich an das Problem rangehen soll noch wie ich es überhaupt jemals so wie von mir vorgestellt umgesetzt bekomme.

 

Das was Du in Post #14 beschreibst ist genau mit den Ansätzen von Martin aus Post #13 umsetzbar.

tblHersteller
enthält alle Hersteller (BMW, VW, Mercedes, Opel, etc.)
tblModelle
enthält die HerstellerID aus tblHersteller sowie die Modellbezeichnung (Astra, Golf, etc.)

die 2 Tabellen werden 1:n verknüpft (zu 1 Hersteller kann es n Modelle geben)
Dann folgen weitere Tabellen, z.B. Motorvarianten abhängig von der ModellID aus tblModell (je nach dem wie weit Du es "atomisieren" möchtests nach obigem Schema)

Als unterste Ebene gibt es dann eine Tabelle tblFehler.
Die enthält neben der IDs aus den letzten Detailtabellen (die "letzten" der obigen Reihe, z.B. tblMotoren, tblGetriebe, tblZubehör, etc.) weitere Felder zur Fehlerbeschreibung.
Z.B. Fehlerkurzbeschreibung (Deine gewünschte Überschrift die dann als Auswahl zur Suche verwendet werden kann) und FehlerDetailbeschreibung, sowie mögliche weitere Felder