Office: (Office 2003) KANBAN DB aufbauen

Hallo,

1. ich stimme in allen Punkten Rainer zu !

2. Anmerkungen zu Deime Entwurf:

Tabelle ARTIKEL

Spalte BESTAND_GES löschen ! Dies ist eine Redundanz und wird Dir nur Probleme machen.

Tabelle BESTANFORD

Da Du bei der Bestellanforderung nicht unbeding wissen kannst oder musst, wo der Artikel beim WE eingelagert werden wird, solltest Du noch die Spalte LAGERNR aufnehmen. In diesem Fall wird die Bestellung dann ins Lager geliefert und dort wird dann aufgrund der aktuellen Lagersituation entschieden wo die Ware hinkommt. Selbst wenn Ihr heute mit feste Plätzen für einen Artikel arbeitet, kann in der Zukunft evtl. auf eine "chaotische" Lagerplatzvergabe umgestellt werden.

Die Splate Mengeneinheit solle entfallen, da dies im Artikelstamm steht (Vermeiden von Redundanzen).

Tabellen LAGERBESTAND; LAGERPLATZ und LAGER

sind so i.O.
In Tabelle LAGERBESTAND steht, welcher Artikel auf einem Lagerplatz liegt und die Menge.

Tabelle MATBELEGE

so i.O.
Hier werden die einzelnen Materialbewegungen gespeichert, also alle Ab- und Zugänge. Beim Speichern des "Belegs" muss dann parallel die Tabelle Lagerbestand fortgeschrieben werden.

Barcode auf Karten

Kanns Du bitte die Anforderungen genauer beschreiben, wo / wann / wofür sollen sie eingesetzt werden, was soll auf der Karte stehen

Ich denke Du bist jetzt auf einem guten Weg - wenn Du noch die Anforderungen an die Funktionalität zusammenstellts.

 

Hallo,

Die Karten möchte ich dazu nutzen, aus dem Lager ein Ersatzteil zu entnehmen, die werden täglich eingesammelt zwecks Datenpflege
der Instandhalter soll so sich nur um die Aufgabe Maschine reparieren Instandsetzen etc kümmern, nicht mit der Datenpflege.

- Bezeichnung Artikel
- Artikelnummer
- Lieferant
- Lagerplatz
- Min
- Max
- Bestand (nach Datenpflege geht Karte zurück ins Lager (aktueller Bestand)
- Maschine / Empfänger
- lfdnr "Karte"
- Barcode Artikelnummer (zum schnelleren Finden mittels Scanner)
das Design habe ich ja in der Version LV_KANBAN_06 schon drin gehabt
siehe Report der Version

so hatte ich mir das gedacht

 

Hallo, beim Entkomprimieren von LV..06.. bleibt stuffit hängen! Kannst Du evtl. einen sreenshot schicken ?

Ich habe aber den Zweck der Karte noch nicht verstanden. Soll dies eine Materialanforderungen ans Lager sein ? Wenn ja wo steht die benötigte Menge ?

 

Hallo Bernd,

jeder Artikel im Lager soll solche Art von Karte erhalten, beim enthehmen 1 Ersatzteil wird diese in eine Kiste geworfen
die Kiste wird täglich gelerrt und DB auf den aktuellen Stand gebracht.
die Karte mit den aktuellen Stand geht dann zurück ins Lager

Bspw. aktueller Stand Artikel XX = 5 im Lager nach entnahme der Karte und Aktualisierung der DB
nur noch 4

oder habe ich einen Denkfehler, etwas übersehen und es kann so nicht funktionieren?

anbei Screenshot und geändertes Modell

hoffe habe nun alles richtig 0 Fehler

 

Ist folgende Annahme richtig ?

Je aus dem Lager entnommenem Teil wird eine Karte in die Kiste geworfen. Jede Karte entsprecht der Entnahme von 1 Stück des Artikels. Die Aktualisierung der Datenbank soll durch Scannen des Barcodes erfolgen.

Wie wird der Scanner angeschlossen, Einschleifung in die Tastatur ? oder ...

Im Barcode sollte dann Lagerplatz-ID, Art-Nr. und Menge (1) und Bewegungsart-ID stehen. Dies wird eingescannt und in ein Textfeld des "Buchungsformulars" gelesen und dort "auseinandergenommen". Wenn das Ersatzteil an eine Maschine geht muss noch die Maschinen-Nr. nachgetragen werden. Aber wo kommt die her, auf der Karte steht sie nicht?

 

Hallo bernd,

deine Annahme ist soweit richtig!
über USB Scanner mit OPOS Treiber klappt der Code aus dem Screenshot
schonmal

Richtig, noch nicht nur ein Feld Maschine: rechts unter dem Barcode.

aber ich meine wir müssen erstmal das Modell stehen haben, oder ist das bei mir bis dahin OK ?

 

Hallo,
ich denke, es ist so ok.

 

hallo bernd,

was meinst du mit Menge (1)

betrifft den Barcodeinhalt aus #65

@Rainer, was meinst du

es macht ja nun keinen Sinn wenn alle ja machen und es doch nicht passt
wie soll ich weitermachen, wie läßt sich das Modell prüfen ob es soweit OK ist?

ich habe da noch fragen zu den Schlüsselfelder, wenn ihr euch das angeschaut habt und bernd hier soweit OK gibt, dann sind alle Beziehungen Schlüsselfelder etc. OK?

 

Hallo,

mit Menge (1) meine ich, dass auf der Karte auch die Menge stehen sollte.
Wenn z.B. die Entnahme in "Päckchen" je 10 Stück erfolgt, so könnte bei
diesem Artiekl auf der Karte die Menge 10 stehen.
Bei Artikeln die einzeln ausgegeben werden steht dann die

 

Zu den Beziehungen:

Zwischen Tabelle ARTIKEL und MATBELEGE
hast Du die ref. Integrität mit Löschweitergabe angelegt.

Du musst Dir bewusst sein was dies bedeutet:
Artikel wird gelöscht und dann auch alle daran hängenden Materialbelege. Ob dies so gewünscht ist halte ich für fragwürtig. Denke daran, dass Auswertungen über den Materialverbrauch dann nicht mehr korrekte Werte liefern. Daher Empfehlung:

Wenn ein Artikel gelöscht werden soll, dann in eine weiter Spalte der Tabelle ARTIKEL mit Namen "LOESCHDATUM" das Datum an dem die Löschung vermerkt wurde reinschreiben. In einer extra Aktualisierungsabfrage dann alle Belege Löschen deren Löschdatum z.B. vor 1.1.2010 liegt. So blieben dann die Belege des lfd. Jahres erhalten. Wenn Du es so machst ist die Löschweitergabe i.O.

Bei der Beziehung zwischen Tabellen LAGERPLATZ und LAGER würde ich die ref. Integrität auch raus nehmen.

Sonst aus meiner Sicht o.k. was sagt Rainer ?

 

Eigentlich gar nicht. ^^ Du wirst auch mit Sicherheit während der Entwichlung noch das ein oder andere ändern müssen (wenn es gut gemacht ist beschränkt es sich i.d.R. auf anfügen von Argumenten oder neuen Entitäten).

Du kannst einzig und alleine ein ERM dadurch prüfen das Du über jede einzelne Entität und deren Beziehung ausführlich nachdenkst. Und erst wenn Du aus allen Blickwinkel (also allen möglichen Praxisgegebenheiten) glaubst das die Entität und die Beziehung alles abbdeckt was vorkommt könnte sie gut sein. *wink.gif*

Deswegen schlaf einmal drüber und schlaf auch ein zweites Mal drüber und betrachte jeden Tag auf's Neue Dein Datenmodell ob es auch wirklich alle Aktionen aus der Praxis abbildet.

Jein. ^^

Meiner Meinung nach sollte eine Tabelle die über eine eigene ID verfügt auch nur diese ID als gekennzeichnetes Schlüsselfeld haben. Alle anderen ID's sind Fremdschlüssel (logischerweise) und sollten nicht als Schlüsselfeld aktiviert werden.

Fremdschlüssel als Schlüsselfeld deklarieren nutze ich nur in Zwischentabellen die m:n Beziehungen abbilden (und da auch nur wenn ich nicht zwingend ein eigenes Schlüsselfeld brauche ... z.B. weil die Kombinationen der Fremdschlüssel mehrfach möglich sein dürfen). Da ich dort eben alle Fremdschlüssel gemeinsam als Identifier haben will/haben muss.

@ lalo

Dann hast Du laut Deiner Aussage nach in einer Tabelle den Primärschlüssel ID und dazu dann noch Fremdschlüssel die jeweils auch ID heissen und keinen Präfix o.ä. bekommen. Wie soll das gehen ... irgendwas muss die Felder doch in der Bezeichnung innerhalb einer Tabelle unterscheiden!?

Was meinst Du mit unerwünschte Doppeleinträge? Gleiche ID ... geht ja eh nicht wenn die ID Primärschlüsselfeld ist. Woran willst Du beim ERM erkennen das es ein unerwünschter Doppeleintrag ist? Oder sind wir da wieder bei dem praktisch-philosophischen Thema ist "Müller, Hans" der gleiche Kunde wie "Müller, Hans"?

Da mache ich es genau andersrum als Du ... Beziehungen sind für mich enorm wichtig und werden auch pingelig genau beachtet/erstellt, aber Vermeidung von unerwünschten Doppeleinträgen programmiere ich lieber selber. Beziehungen sind was planbares und etwas mit einer festen unverändernlichen Logik auf die man sich verlassen kann, dagegen sind unerwünschte Doppeleinträge sehr sehr stark individuelle von der Art der gespeicherten Daten abhängig und folgen damit keiner festen verlässlichen Regel. Zumindest meine Meinung zum Thema ... oder habe ich Dich nur falsch verstanden was Du willst?

Und mit dem Thema Indizes bin ich eh extrem vorsichtig. Jeder Index reduziert die Performance der DB beim Schreiben/Ändern von DS, dafür erhöht er natürlich die Performance von Abfragen/Suchzugriffen.

Fremdschlüsselfelder aus Beziehungen sind davon natürlich ausgenommen da für diese ja eh automatisch in Access ein Index angelegt wird.

Gruß

Rainer

P.S.: Aussagen zum ERM aus dem letzten Anhang von Erich kommen gleich. *wink.gif*

 

Danke Bernd,

Hoffe er sieht das auch so, würde mich zunächst mal etwas Sicherer machen.
dann noch einmal schauen, und dann kämmen ja die Sache die Daten schnell und einfach a) einzugeben b) finden C) auswerten.

morgen mache ich mich da nochmals ran

 

Also hier mal meine Anmerkungen zum ERM:

Tabelle LAGERBESTAND:

Fremdschlüsselfeld LAGERNR unnötig, leitet sich aus der Beziehung zum LAGERPLATZ ab also raus damit.

Aber mal was anderes ... woher kommen eigentlich Bestandsveränderungen? Ich sehe in der Tabelle Lagerbestand nichts was anzeigt woher die Veränderung kommt. Ist das nicht etwas ungeschickt ... siehe dazu auch unten Beziehung MATBELEG zu ARTIKEL.

Tabelle MEINH:

Nehme an das es sich dabei um eine Tabelle für Verpackungseinheit handelt. Z.B. 10 Stück pro Verpackungseinheit. Die Beziehung zu Artikel ist okay, aber ist geklärt in welcher Form der Lagerbestand abgebildet wird? Als Einzelstück oder als Anzahl Verpackungseinheiten?

Reicht wirklich ein Eintrag in der Tabelle MEINH? Oder sind da nicht noch weitere Angaben nötig? Z.B. Maßeinheit oder ähnliches oder wird bei euch im Lager alles nach Stück gemessen, bzw. gibt es keine Sachen die z.B. in Litern, Milligram o.ä. gemessen werden? Es könnte doch Sachen wie Schmiermittel o.ä. geben wo die Verpackungseinheit eine Box mit 6 Dosen und pro Dose 500 Milliliter ist ... oder nicht? Das würde das Modell, bzw. die Tabelle MEINH so nicht hergeben.

Stimmt die Beziehung MATBELEG zu ARTIKEL?

Ich würde sagen ... Nein, eindeutig nicht.

Denn der MATBELEG soll ja die Entnahme darstellen ... wo erfolgt die Entnahme? Direkt beim Artikel oder doch eher am Lagerplatz? Eine Beziehung zwischen MATBELEG und LAGERBESTAND würde doch vielleicht mehr Sinn machen, oder? Man könnte daraus den Artikel ableiten, sowie Lagerplatz und Lagerort und damit würde in der Tabelle LAGERBESTAND zu jeder Lagerbestandveränderung auch ein FK zum passenden MATBELEG existieren.

Passt die Beziehung BESTANFORD?

BESTANFORD bezieht sich korrekterweise auf einen Artikel ... aber der Artikel ist auf Lagerplätze aufgeteilt. Ist hier sinnvoll die Bestellanfoderung auf den Artikel gesamt durchzuführen oder wäre es nicht sinnvoller die Bestellanforderung auf den Lagerplatz zu beziehen? Könnte ja durchaus möglich sein, dass es in einem Lagerplatz 0 Stück gibt und in einem anderen Lagerplatz 40 Stück.

Was mich wiederum zu der Frage führt ... ist es richtig den Mindest-, Max- und Meldebestand im Artikel selber zu führen? Wäre es nicht sinniger diese Werte pro Lagerplatz zu führen?

Das sind nur ein paar Fragen ohne das gesamte Datenmodell im Detail zu prüfen.

Von daher mein Fazit zum Datenmodell/ERM ... deutlich besser als zuvor aber noch nicht wirklich fertig/brauchbar. *wink.gif*

Gruß

Rainer

 

Ach ja ... noch was:

Gebe ich lalo Recht.

Ich würde in dieser DB sogar soweit gehen, keine einzige Löschweitergabe zu setzen. Auf gut Deutsch: Existiert auch nur ein Untereintrag zu einem DS ist löschen schlicht ausgeschlossen.

Wieso? Ganz einfach ... das sind wichtige Daten die lange und vollumfänglich behalten werden müssen. Gerade bezüglich langfristigen Auswertungen oder Nachvollziehbarkeit noch nach Jahren oder Prüfung von Inventur-Ergebnissen oder Prüfung bezüglich Material-Retouren (ach übringens ... wo sind denn diese Sonderfälle bei Dir erfasst?).

Da darf an sich gar nichts was jemals eingegeben wurde gelöscht werden. Ausser es existiert kein Untereintrag als ein Artikel ohne Lagerbestand z.B..

Nur mal so meine Meinung. Wobei ich auf Grund Datenpflege von aussen zwar trotzdem Löschweitergaben setzen würde aber nirgendwo einen Löschbutton anbieten täte. *wink.gif*

Zum Thema Benamsung von Tabellen und Argumenten:

Ich bin ein Freund von Präfixen wie "tbl" vor jedem Tabellennamen ... dafür hasse ich die ansonsten so beliebten Unterstriche in der Benamsung wie die Pest und auch die Großschreibung von Tabellennamen und deren Argumenten. Wenn ich dann irgendwo lange SQL-Statements sehe wo alle Namen in Großschreibung vorkommen und am besten noch mit 2-3 Unterstrichen im Namen und dann noch vor jedem Argumentnamen den Tabellennamen davor, dann stellen sich mir alle Nackenhaare auf weil es einfach nur noch unlesbar ist was schlicht bedeutet extrem problematisch in der Fehlersuche ^^. Ist aber nur meine Meinung mit der ich ja auch anscheinend recht alleine da stehen. *wink.gif*

Desgleichen mag ich aber auch Präfixe vor Argumenten ... ich wähle da sofern eindeutig genug immer die ersten 3 Buchstaben des Tabellennamens (natürlich die ersten 3 nachdem Präfix tbl ^^). Z.B. heisst meine Kundentabelle tblKunden und meine ID aus diesem Table dann KunID.

Vorteil ist in der ganzen DB gibt es nur ein einziges Feld mit dem Namen KunID. Somit habe ich kein Problem mit dem Eintrag als Fremdschlüssel in einer anderen Tabellen und kann auch sofort in der anderen Tabelle erkennen um welchen Fremdschlüssel es sich handelt, bzw. weiss ich sofort zu welcher Tabelle der Fremdschlüssel gehört.

So kann ich auch auf einen Blick erkennen worauf im Code der FROM-Teil eines Statements zugreift (natürlich haben bei mir Abfragen auch Ihren Präfix ... dreimal darf man raten welchen ^^) und auch gleich sofort erkennen auf welche Felder aus welcher Tabelle sich die Abfrage bezieht.

Was mir dann letztendlich auch die Thematik erspart die lalo angerissen hat: In SQL-Statements zwecks eindeutiger Identifizierung den Tabellennamen vor ein Tabellenfeld zu schreiben. Und bei Join-Statements reicht mir dann einfach die Tabellen als t1, t2, t3 ... zu kennzeichen und das da einzusetzen wo PK von t1 und FK von t2 den gleichen Namen haben ... alles andere ist eindeutig und einzigartig in der kompletten DB.

Gruß

Rainer

P.S.: Ich habe mal aus der DB von Eirch das rein Datenmodell per Reverse-Engineering extrahiert ... finde es so übersichtlicher, falls es jemand interessiert im Anhang dabei.

 

Danke Rainer für deine Mühe,

das sieht schon ganz anders aus wie bei mir, aber mir fällt auch auf

Lagerbestand PF Lagernr (dein Präfix Abfrage?)

und mir fällt auf
das der PK Wert in LAGER und LAGERPLATZ verwendet wird und ist einmal TEXT und dann INTEGER (Zahl)

das fällt mir auch bei LIEFARTINFO zum LIEFERANT auf. Sind das jetzt noch die Feinheiten die überlegt werden sollten.

Echt super, von euch beiden Rainer und Bernd

PS du hast recht wo hin mit der Inventur, das sollte auf jeden Fall rein?