Office: (Office 2007) Lagerdatenbank mit Zusatzinfos+ Normalisierung richtig machen

Hallo alle zusammen.
Ich möchte eine Lager-Datenbank erstellen.
Genau gesagt geht es um die Verwaltung von Drucksensoren für die Motorenentwicklung im Automobilbereich.
Es gibt verschiedene Typen von Drucksensoren, alle mit Seriennummer unterscheidbar.
Nun kommt Person X und braucht 8Sensoren. Aus den verschiedenen Typen soll er einen auswählen und sieht wieviel davon im Lager sind.
Dann trägt man ein, wo die Sensoren verbaut sind(Motornummer angeben)
Zur Übersicht soll man noch sehen können, wo welche Sensoren sind, wieviel sind im Lager und welche sind defekt.
Andere Sache ist, das es zu den Sensoren Informationen gibt, die auch angezeigt werden sollen.
Jeder Sensor hat seinen eigenen Messbereich und seine eigene Empfindlichkeit.
Das soll z.B. auch ein Suchkriterium sein.
Als Anfang habe ich eine Tabelle mit den für mich wichtigen Informationen erstellt.
Aber aus dem was ich gelesen und gesehen habe, braucht man mehrere kleine Tabellen.
Also hab ich die EINE Tabelle zerlegt.
Nun glaub ich aber wird das ganze etwas zu viel.
Wär schön wenn Ihr da mal drüber schauen könntet und mir ein paar Tips gibt.
Danke
Kay

:)

 

Hi,

Verwaltung kann alles möglich sein. Ich erkenne hier auf den ersten Blick

• Lagerverwaltung (kennst du schon von ChristianS)
• "Datenblattverwaltung" (technische SPzifikationen für jeden Sensor; Messbereich, Maße, Ansteuerung, ...)
• Kompatibilitätsverwaltung (welcher Sensonr passt in welchen Motor (wobei damit wohl nicht die konkreten Maschinen gemeint sind, sondern die "Modelle")
• Auftragsverwaltung ("Nun kommt Person X und braucht 8Sensoren" -> Auftrag!)

Geht es wirklich nur um Drucksensoren? Oder allgemein um Bauteile/Ersatzteile? Ein Drucksensor dürfte andere Eigenschften haben als eine Lichtmaschine....

 

Es geht nur um die Sensoren.
Man soll halt erkennen, dass es 50Stück von Sensor 5052C im Lager gibt,
und 8Sensoren am Motor 0815 verbaut sind. Mit den Fahrzeugen oder so hat das nüscht zu tun.Es ist nur wichtig, welche Sensoren wo sind(nur Motornummer anzeigen)
Auch brauch ich keine ausgefallenen Suchoptionen.
Es gibt ca. 15 verschiedene Sensortypen(Type). Von jedem haben wir eine bestimmte Anzahl.
Und am Ende soll man wissen, wo die einzelnen Sensoren sind. damit keiner wegkommt sozusagen.
Das jeder Sensor noch Informationen hat, wie Messbereich usw. soll einfach nur angezeigt werden. Oder wenn ich weiß: ich bracu 4 Stück mit nem Messbereich bis 100bar, dann zeigt er mir auch nur die Sorten an mit 100bar. n klassischer Filter also

 

Reden wir da von einem konkreten Motor (= "den ich anfassen und schmieren kann"), oder von einem "Plan", also einer Art Montageanweisung (die kann man nicht schmieren, nur ausführen)?

 

die Dinger kommen in einen richtigen Motor, aus Metall, mit viel Oel, Benzin und was da sonst noch so ist.
Das ist also real.Und wird auch schon alles benutzt. Nur weiß keine Sau, wo welcher Sensor ist.Es sei denn man schaut einfach am Motor nach.
Aber um das zu vereinfachen möchte ich die DB machen

 

Gut, ich komm heute da nicht mehr zu, aber ich hab ein paar Ideen.

 

Hier hab ich meine Ausgangsdatenbank. Da stehen alles Abhängkeiten drin.
Aus der hab ich die kleinen Tabellen gemacht.
Mit der Normalisierung ist es doch anders als im Buch.(so wie ich das sehe)

 

Wo ich mir noch nicht ganz klar bin, ich brauch doch den Primärschlüssel zum identifizieren. Da eignet sich doch die Seriennummer besser als eine ID, oder? Zumindest in den Tabellen, wo ich die Seriennumer stehen habe.

 

Hi,
wie man bei einer Tabelle in der DB bereits von einer DB sprechen kann, bleibt mir etwas unverständlich (oder hab ich die falsche zip runtergeladen?) *biggrin.gif*
Im Prinzip kannst auch die Seriennummer als Primärschlüssel verwenden, genausogut ist jedoch der Autowert. Seriennummer könnte zusätzlich als Feld geführt werden.
Empfindlichkeiten, Messbereich etc. als Text und andere Attribute als Text, bleibt für mich fraglich. Wenn du später danach filtern oder suchen willst würde ich das numerisch speichern und die Einheit weglassen, oder lediglich im Bezeichnungsfeld (nicht im Feldnamen !!) erwähnen (z.b. Empfindlichkeit in cp/bar).
Gibt es immer nur 2 Messbereiche bzw. Empfindlichkeiten ? Oder kann es auch mal 3 oder 4 geben ?
Wenn ja, dann sollte hier eine 1:n Beziehung resultieren, mit je einem Feld Empfindlichkeit bzw. Messbereich.
Die üblichen Sachen:
verzichte auf Leer- und Sonderzeichen oder deutsch-spezifische Sachen (Umlaute, ß) etc., ansonsten muß alles zwingend geklammert werden.
Attachment-Felder - naja da kann man geteilter Meinung sein, die könnten die DB aufblähen, wenn die sehr umfangreich wird.
Edit:

Hab jetzt noch diese V3Quarz runtergeladen. DAs ist natürlich eine falsch verstandene NOrmalisierung von Tabellen. Alles was ein Bauteil/Sensor beschreibt, gehört in eine Tabelle. Natürlich kann es Hilfstabellen geben, die dir Vorgaben für bestimmte Attribute anbieten können, die dann 1:n mit der "Haupttabelle" (welches den Sensor an sich beschreibt) in Beziehung stehen. In diesen Hilfstabellen taucht aber nicht die Seriennummer als Primärschlüssel auf.
Ansonsten ist das natürlich eine umfangreiche Datenbank mit "vielen" Tabellen, die man nicht in 2 Min. aufbauen kann, ausgehend von deinem Anforderungskatalog.

 

ja tabelle oder db. Es soll eine DB werden. nennen wir es mal so. bis vor 5 tagen wusst eich nicht mal, dass es Access überhaupt gibt. nun sitz ich hier mit nem dicken Buch und schaue was passiert.
Spaß beiseite:
Danke für den Tip.
also messbereiche gibt es immer nur 2.
Die sollen, wenn möglich als Information zusätzlich angezeigt werden. und danach suchen, also filtern sollte man auch.

 

Ich hab mir gedacht, wenn ich ne ID mit Autowert reinmache, das es dann zu viel wird. schließlich hab ich ja eine Seriennumer

 

Hi,
naja da müßte man erstmal "zu viel" definieren *Smilie
Bei Datenbanken geht es im allgemeinen um "viel" DAten - um das mal so platt zu formulieren - also sind DB dafür konzipiert auch mit vielen Daten umgehen zu können. Soll natürlich nicht heißen, dass man deshalb auf einen intelligenten, speichersparenden Aufbau verzichten sollte - eher im Gegenteil.
Ich denke, dass ist das kleinste (bzw. ist es keins ) Problem deines Vorhabens.
Es macht keinen Unterschied, ob du jetzt die Seriennummer (falls numerisch) oder einen Autowert nimmst, oder einen Autowert mit zusätzlichem Seriennummer-Feld.
Größtes Augenmerk sollte zu Beginn darauf gerichtet werden welche Tabellen du grundsätzlich brauchst und wie die zu "verdrahten" sind. Alles andere (Formulare, Abfragen, Funktionsweisen, Gestaltung etc.) ist absolut zweitrangig.
War da nicht am Anfang der Antworten ein Link auf eine Beispiel-Datenbank ?
(man muß ja das Rad nicht jedesmal neu erfinden - es sei denn es geht hier um Lernprozesse durch "Doing by yourself")

 

Auch Dir empfehle ich als Einstieg den Link 'relationale DBs' in meiner Signatur.
Ohne das dort beschriebene wirst Du sehr schnell in eine sehr falsche Richtung laufen.

Den selben Tip habe ich auch ChristianS gegeben; offenbar geht es bei euren Themen ja um ähnliches und möglicherweise ist ein gemeinsames "Projekt" dahinter.

Grundsätzlich ist für Access wesentliche mehr, theoretisches Vorwissen nötig als in den anderen Officeprodukten.

 

Richtig.
Hab mir das auch angeschaut. Aber jede DB ist ja einzigartig. und ich denk mal, wenn ich als Laie eine vorhandene DB änder, dauert das länger (oder geht nicht) als wenn ich selber eine neue mache. Im buch steht ja eher wie man was neu macht und nicht wie man was ändert.
Lernen will ich natürlich auch!
der speicher ist mir erstmal egal. mein 2.er anhang ist ja mein 'ausgang', und ich habe ca 300-400 Sensoren, also jede Menge Information.
Das dumme ist, das manchen Infos(wie die Empfindlichkeit) für jeden einzelnen Sensor einzigartig sind.

Mit den Einheiten haste natürlich recht. das änder ich.

 

den link habe ich schon.
nun geht es daran, das vorhandene auf das neue zu übertragen.
nicht so einfach
ChristianS hat was ähnliches. wir arbeiten schon zusammen.
ein gemeinsames projekt ist das nicht. da trennen uns 700km luftlinie.