Office: (Office 2003) KANBAN DB aufbauen

Hallo Bernd,

etwas überarbeitet, aber es fehlt noch einiges....... das ist mir bewusst
nur mal angefragt so in etwa?

 

Hallo bernd,

und die 3 Version ? *wink.gif* auf dem richtigem Weg

ich hoffe da schaut jemand rein und hilft mir weiter *Smilie

 

Hallo,

zur letzten Version folgende Anmerkungen:

Generelles

Dier Tabellen sind nicht normalisiert ! Wenn Du so weiter machst wie bisher wirst Du laufend an den Tabellen Änderungen vornehmen müssen und keine "stabile" Anwendung erhalten. Dringende Empfehlung: Vor allen weiteren Schritten die Tabellen normalisieren.
Schau Dir mal dies an:
Normalisierung (Datenbank) – Wikipedia
Empfehlung: Normalisiere bis zur 3. Normalform.

Tabelle Artikel
Die Spalten LagerID_F und LagerortID_F sollgen aus dem Artikelstamm entfernt werden. Sobald ein Artikel auf mehr als einem Lagerort / Lagerplatz gelagert wird müsste ein neuer Artikelstamm angelegt werden.

Die Spalte Bestand sollte auch entfernt werden, da der Bestand nicht zu den Stammdaten zählt sondern das Ergebnis von Bewegungsdaten ist.

Tabelle ErgebnisLager

Die Spalte KategorieID_F sollte entfernt werden. Das ist eine Redundanz zum Artikelstamm (Wenn Du im Artikelstamm die Kategorie änderst, müsste zusätzlich auch in dieser Tabelle geändert werden. Also auch hier "normalidsieren"!

Tabelle Bestandsänderungen

Hier ist nicht erkennbar warum sich ein Bestand ändert.
Wenn mal eine Anwendung fertig ist sollte man erkennen warum hier eine Änderung erfolgte (Warenausgabe, Rückgabe, Wareneinganb Lieferant usw.)
Es sit nicht erkennbar für welche Maschine, Kostenstelle usw. ein Materialbewegung (Entnahme) stattfand.


usw usw.

 

sorry so hatte ich dich verstanden

dann ist die Nr.: 4 ja gleich falsch?

ich taste mich da ja pö mal pö ran, und bin froh über deine Anmerkungen.
wie würdest du den 4. Stand verbessern?
Lagereingang, Lagerausgang tu ich mich noch schwer

 

Ergänzend zu Lalos Anmerkungen:
In der Tabelle ErgebnisLager ist die Artikelnr als Autowert eingetragen, das müßte aber eine Beziehung zur Tabelle Artikel sein. Außerdem wird da eine Summe gebildet, Berechnungen gehören aber nicht in eine Tabelle. Die Artikelbezeichnung ist auch redundant. Vermutlich ist also die ganze Tabelle ErgebnisLager überflüssig.
Der Einzelpreis in der Tabelle Artikel kann Dir auch Schwierigkeiten machen, wenn sich der Preis mal ändert, und das wird er. Vielleicht kann der Preis in die Tabelle Bestandsänderung geführt werden.
Deine Beziehungen sehen auch ein bisserl mager aus. Zwischen Lagerort und Lagerplatz sowie zwischen Einheit und Artikel müssen Beziehungen bestehen. Wahrscheinlich fehlen auch noch andere Beziehungen.
Faustregel: werde mißtrauisch, wenn eine Tabelle nicht mindestens eine Beziehung hat.
Indianerregel von Häupling Saubere Arbeit: bau keine Formulare bevor nicht die Sonne wenigstens zwei mal über Deiner Tabellenkonstruktion untergegangen ist. Denn erst wenn das letzte Formular gebaut und der letzte Code geschrieben ist, werdet ihr merken, daß man Tabellen nicht durch VBA-Gefummel ersetzen kann!

 

habe gerade versucht anzupassen, im Moment ärgert mich eine permanente Parameterabfrage Artikel.LagerID_F die ich entfernt hatte und finde nicht heraus woran es liegt

 

Indianerregel von Häupling Saubere Arbeit: bau keine Formulare bevor nicht die Sonne wenigstens zwei mal über Deiner Tabellenkonstruktion untergegangen ist. Denn erst wenn das letzte Formular gebaut und der letzte Code geschrieben ist, werdet ihr merken, daß man Normalisierung nicht durch VBA-Gefummel ersetzen kann!
(Da hatte ich eben einen Fehler im Zitat.)

 

OK hast ja recht, aber ich muss gleich sehen was passiert.

also nun die Nr. 5, was meint der Häubling und Bernd dazu
zunächst nur die empfehlungen DF entfernen umgestzt. Es hackt z.Z.
wohin mit den EP, Bestand, MIN und MAX
und wie kann der Stamm mich weiterhelfen? ich habs leider nicht so mit der theorie

PS Fehler gefunden

 

Hallo Thomas, hallo Bernd

wenn ihr euch das bitte mal anschaut, es klemmt ziemlich bei mir.
habe mehr Daten eingegeben.
auch einige tabs die Beziehungen erstellt

wenn der Artikel erfasst ist
wohin nun mit dem Artikel (Einlagern ins Lager) wie sollte das aussehen?
in die Tab Bestandänderungen, die mit Wareneingang verknüpft ist
bei der Einlagerung dann die Attribute wie MIN, MAX, Bestand verwenden.

Bitte helft mir mal weiter.........
ich weiß nicht warum ich z.Z. viele Klemmer habe

 

Erich, sei mir nicht böse, aber ich klinke mich aus. Nach meiner Erfahrung ist es sinnlos irgendetwas zu tun, bevor nicht das Datenmodell einwandfrei ist. Und um ein Datenmodell zu entwerfen braucht man zunächst einen Bleistift und ein Stück Papier.
Und bevor man dafür Papier verschwendet braucht man ein ganz genaues Anforderungsprofil, ein Pflichtenheft. Das Pflichtenheft kann vielleicht, bei einer einfachen Sache, auf 'nem Bierdeckel Platz finden; aber ohne das läuft nix.

 

nein bin dir nicht böse, aber ein wenig enttäuscht das ihr so schnell die Flinte ins Korn schmeißt
so wie ihr wahrscheinlich von meiner Leistung hier enttäuscht seid.
Mein Problem ist halt, das ich Praktikabel denke und nicht wie ein Programmierer
ich bin aber der Meinung das wir das hinbekommen könnten.

 

Schonmal drüber nachgedacht, dass das vielleicht auch ein Stück weit an Deiner Resistenz gegenüber den Ratschlägen liegt?

Thomas hat Dir versucht klar zu machen, dass alles was Du tust bevor Dein Datenmodell wirklich 1000%ig (ja, ich weiss es gibt keine 1000% ... trotzdem ^^) steht völlig für den A***** ist.

Und das erste was Dir einfällt ist mit einem (vermutlich) noch nicht mal halbfertigen Datenmodell los zu brausen und Formular u.ä. zu machen. Das endet ähnlich wie Dein letztes Projekt ... irgendwann kommst Du an den Punkt wo die Fehler/Probleme im Datenmodell auch nicht mehr durch die komplexesten SQL-Statement oder VBA-Codes zu lösen sind, bzw. nur noch mit so enormen Aufwand das Du es nicht mehr packst und kein anderer ohne fürstliche Bezahlung diese Mühe auf sich nimmt.

Dann lerne es oder lass die Finger von der Programmierung. Aber wenn Du funktionierende DB's die auch im Praxiseinsatz taugen und anwendbar sind entwickeln willst, dann MUSST Du lernen wie ein DB-Entwickler (Programmierer passt hier nicht wirklich *wink.gif* ) zu denken und zu handeln.

Deswegen auch Eingangs in diesem Thread mein Hinweis darauf das Du dieses neue Projekt nutzen solltest um zu lernen um nicht die gleichen Fehler wie bei Deinem ersten Projekt zu machen ... und kaum gucke ich mal rein, machst Du den gleichen Unfug wieder auf's Neue.

Sorry, dass ich mich hier etwas direkter ausgedrückt habe, aber ich habe so die Befürchtung das Du die bisherigen Winks durch die Blume (und nicht nur von mir) noch nicht wirklich registriert hast. *wink.gif*

Also hock Dich hin und lerne erstmal ein sauberes und korrektes Datenmodell zu entwerfen, bevor Du irgendwas anderes tust. Ohne das ist nämlich alle Arbeit die Du investierst irgendwann umsonst gewesen.

Wenn Dir Bleistift und Papier zu simpel ist, dann besorg Dir ein Tool für die Erstellung eines ERM (Entity-Relationship-Model) wie z.B. DeZign for Database (das nutze ich, gehört aber mit knapp 600 € in der Expert-Version zu den eher teureren Programmen in der Richtung).

Gruß

Rainer

 

OK, aber ihr müsst mir recht geben auf meine Anmerkungen aus #38 #39
ist da nun kein Feedback gewesen.

die Nr. 6 hast du geladen ? und ganz so schlecht ist es doch wohl nicht, habe ja nicht behaubtet das es fertig ist

 

Die Frage ist für was?

Für eine geschäftliche Anwendung aus der eine Firma seine Einkaufsentscheidungen ableiten soll und die Lagerverwaltung optimieren soll ist es untauglich.

Zumindest entnehme ich das so aus dem Datenmodell (siehe im Anhang die DB mal rein auf das Datenmodell runtergebrochen).

Also Datenmodell ist wohl noch nicht mal halbfertig und Du baust schon Formulare und Eingabemasken?

Das ist doch der Unfug um den es geht. Erst Datenmodell bis es absolut sicher und sauber steht und dann kannst Du mal anfangen über Formulare nachzudenken, davor ist es einfach unsinnig.

Das wollte Dir Thomas klar machen, bzw. so verstehe ich seine Äußerungen und da schliesse ich mich schlicht zu 100% an. *wink.gif*

Gruß

Rainer

 

Hallo Rainer,

Bin nun auch dabei, mir Bleistift und Papier zur Hilfe zu nehmen.

- DB Modell -
Anforderungen

- geordnetes Lagersystem
"Bereich Ersatzteile, Ersatzteilkomponente für Produktionsmaschinen"
- Dokumentationsverwaltung
"Zeichnungen für Ersatzteil oder Komponente soweit Verfügbar"
- KanBan Anlehnung
Material, Ersatzteil Entnahme über KanBan
- Übersichtliches System das Instandhalter stets Zeitnah ausreichend Ersazteile nachordern kann
- Mehrbenutzerfähig, selbsterklärend
- Zugriff auf andere Läger "Standorte suchen und lesen"
- Entnahme über Anforderung ans Lager -> Standort
- frühzeitiger Meldebestand zwecks auslösen von Nachbestellungen
- optimalen Bestand im Ersatzteillager dh. ABC Analysen Auswertungen Übersichtliche Listen und Bedarfsmeldungen per eMail absetzen

da kommt einiges zusammen, und so beim schreiben habe ich glaube nun auch verstanden ohne Planung geht das nicht.

Ich hoffe aber auf eure weitere Unterstützung, melde mich sobald ich ein Modell zusammengestellt habe um mir weitere Tipps oder Kretik abzuholen *wink.gif*