Datenbankdesign

Sn0rr3

Newbie
Registriert
Aug. 2005
Beiträge
7
Hallo Leute,

dieser Beitrag hat nicht wirklich etwas mit "Porgrammieren" an sich zu tun, dennoch gehört auch Datenbankdesign zur Softwareentwicklung etc.

Ich möchte mal so beginnen:

Ich würde gerne eine "Lagersoftware" mit einer MS Access Datenbank bauen.

Da ich hier in diesem Forum keine Unterkategorien mit Datenbank etc. gefunden habe, könntet ihr mir bitte ein paar Links (sofern ihr welche wisst) zu Datenbank Foren geben.

Falls jemand hier mir bei meinem Problem helfen möchte (es geht um Datenbankmodell ERM und Relationenmodell) möge er/sie es bitte als Antwort schreiben.

Also das Problem einfach ausgedrückt: Ich bräuchte nur Hilfe beim Design der Datenbank und jemand der sich mit Realtionenmodell und Normalisierungen auskennt, damit ich keine Fehler mache.

MfG
 
Hi,

um dir bei der Normalisierung und dem ERM Modell zuhelfen sollten aber mehr Info´s kommen.
Was genau für einträge enthalten sein müssen, Felder, Kardinalitäten etc.

Google doch mal und guck ob ein Modell von SAP dafür findest, ich glaub besser wird das von uns keiner hinbekommen *gg*

mfg

Mysterox
 
So also mal danke für die schnelle Antwort :>

Um mein Problem zu beschreiben:

Also ich bin Ferialpraktikant in einer Firma und bin in der EDV Abteilung. Diese Abteilung hat ein "Lager" und dieses ist sehr sehr unordentlich.... -.-. Also habe ich es mir zur Aufgabe gemacht, dieses aufzuräumen und mit einem Lagerverwaltungstool zu kontrollieren und die Lagerbewegungen aufzuzeichenen etc. (Was eben so eine Lagersoftware macht).

Ich habe hier 2 Regale (is noch größer aber die 2 Regale haben mehr als 1400 Artikel...) welche ich folgendermaßen Beschriftet habe: R1(oder R2 = Regal1 oder Regal2) / B1/2/3/4/5 für Brett 1.2... und P1-6 für Ablageplatz 1-6. Das sollen die Lagerstandorte sein. Auf diesen Lagerstandorten befinden sich blaue Boxen in welchen die Artikel (es sind nicht wirkliche Artikel, sondern Waren die sich die Mitarbeiter halt nehmen können - deswegen auch Lagerbewegung etc.) drinnen sind. Also Netzwerkkarten etc. Diese Boxen habe ich auch mit Nummern versehen.

Und jetzt brächt ich halt Hilfe beim ERM oder Relationenmodell wie das mit dem LAger so funktioniert. So Verkauf von Produkten is ja Wurscht, brauch ich da nicht und kann ich auch nicht, brächte halt nur jemanden der mir sagt wie das mit den Realtionen funktioniert.

Damit du/ihr euch ein Bild machen könnt wie das mit dem Lager so ausschaut hab ich ein paint bild gemalt :>.

MfG
 

Anhänge

  • oO.jpg
    oO.jpg
    19,8 KB · Aufrufe: 251
Also du hast auf jeden Fall das Entity Objekt:
Id: Integer
Name: String
Regal: Integer
Brett: Integer
Ablageplatz: Integer
Box: Integer

Dann die Constraints:
Primary Key: Id
Unique: (Regal+Brett+Ablageplatz+Box)

Dan könnte ein Datensatz wie folgt aussehen:
Id: 16877
Name: Holzbohrer
Regal: 1
Brett: 22
Ablageplatz: 31
Box: 1

Dann kannst du auch schöne Abfragen basteln wie:
Hol alle Artikel aus Regal 123, oder Alle Artikel auf Brett 3 usw.

Ergänzende Frage:
Gibt es irgendeine fortlaufende Nummer in eurem Lagerbestand?
 
Hi,

das ist ja eigentlich gar nicht so schwer. Ich bin zwar kein Access Mensch, aber geh halt ganz einfach gesagt mal so vor. Ich kann natürlich nur SQL Datentypen und weiß jetzt nicht, ob es die in Access auch gibt.

- Datendefinition
Lege fest, welche Basisdaten, Stammdaten und Bewegungsdaten in dem Projekt gebraucht werden. Demnach erstellst Du die Tabellen. Realisierbar sind also Tabellen, wie

a) Basisdaten mit etwaigen Einstellungen
- Artikellimit gesamt - integer
- Lager ins Minus - tinyint(1) Werte 0=nein 1=ja
- fachprefix (Buchstabe vor einem Fach/Ablageort in einem Regal)
- diverse andere globale Einstellungen/Voreinstellungen

b) Stammdaten
Hier wird's dann schon komplexer.

b.1) Mitarbeiter
id - int AutoIncrement
name1 - varChar(100) NOT NULL
name2 - varChar(100) NULL
name2 - varChar(100) NULL
...evtl. Felder für die Anschrift...

Hinweis zu b.1: Den Mitarbeiterstamm könnte man zudem um eine Abteilungstabelle erweitern und die Mitarbeiter einer Abteilung zuordnen, damit hinterher weitereichender Auswertungen möglich sind.
Der Mitarbeiterstamm wird dahingehend benötigt, dass man spätere Lagerbewegungen zuordnen kann und weiß, wer welches teil entnommen, bzw. eingelegt hat.

b.2) Lager
id - int AutoIncrement (gleichzeitig die Lagernummer)
bezeichnung - varChar(100) NOT NULL
beschreibung - text NULL
...evtl. Felder für die Anschrift...

Hinweis b.2: Die Aufteilung in eine Lagerstandortverwaltung ermöglicht später das Hinzufügen weiterer Anschriften, zum Beispiel, wenn ein weiterer Lagerstandort mit seinen eigenen Regalen an einer anderen Anschrift eröffnet wird.

b.2.1) Regal
id - int AutoIncrement (gleichzeitig die Lagernummer)
lager_id - int(11) NOT NULL (Zuordnung zum Lager)
bezeichnung - varChar(100) NOT NULL
beschreibung - text NULL
raumnummer - varChar(50) NULL (Raumnummer im Haus)

b.2.1.1) Regalfaecher
id - int AutoIncrement
regal_id - int(11) NOT NULL (Zuordnung zum Regal)
bezeichnung - varChar(100) NOT NULL
kurzzeichen - varChar(20) (Kurzbezeichnung des Fachs)
beschreibung - text NULL
...evtl. weitere Merkmale zum Fach (Höhe, Breite, Tiefe, Tragkraft)...

b.3) Artikel
id - int AutoIncrement
bezeichnung - varChar(250) NOT NULL
beschreibung - text NULL
...weitere Informationen...

Hinweis zu b.3: Zu der Artikelverwaltung empfehle ich weitere Stammdaten in eigenen Tabellen zu erfassen. Diese sind Mengeneinheiten (Kurz- und Langformat), Warengruppen und Zuordnung der Artikel zu diesen. Wenn es sich nur um eine hausinterne Anwendung handelt, erübrigen sich Zuordnung und Erfassung von Preisen/Preistabellen, Rabatttabellen, Datenblaetter etc..

c) Bewegungsdaten
In den Bewegungsdaten werden nun alle Vorgänge erfasst. Jeder Vorgang wird mittels Kopf erfasst und enthält gewisse Bewegungen/Positionen.

c.1) Lagerbewegungen
id - int AutoIncrement
datum - datetime NOT NULL
beschreibung - text NULL
erfasser_id - ID des Mitarbeiters, der den Vorgang erfasst hat
m_id - Mitarbeiter, an den das Material gegeben wurde, bzw. von dem das Mat. entgegengenommen wurde

Hinweis zu c.1: So wird jeder Vorgang einem Mitarbeiter zugeordnet und Du kannst im Nachhinein sehr leicht feststellen, wann wer was entnommen und eingelegt hat. Sogar ein Rückschluss auf die eintragene Person ist so möglich.

c.1.1) Bewegungspositionen
id - int AutoIncrement
lb_id - int NOT NULL (Zuordnung zur Lagerbewegung)
art_id - int(11) (Zuordnung Artikel)
einaus - tinytext (Werte "Eingang" und "Ausgang" - zur Definition ob die Position ein Wareneingang oder Ausgang war)
regalfach_id - int(11) (Zurodnung zum Regalfach, somit Rückverfolgung auf Regal und Lagerstandort möglich)
menge - decimal(13,3) NOT NULL (Menge von dem ein-/ausgehenden Artikel)


So, aus dem Stehgreif fällt mir jetzt nicht mehr ein. Natürlich kann man das Ganze locker und leicht um Seriennummern erweitern. So werden Seriennummern nachvollziehbar. Man kann einen Lieferantenstamm anlegen und im Artikelstamm Garantiehinweise hinterlegen, damit man anhand der Seriennummern auch gleich einen Garantienachweis erstellen kann. Dies allerdings dann nur, wenn man auch einen Wareneingang im Zusammenhang mit dem Einkauf anlegt.

Da gibt's sehr sehr viele Möglichkeiten, die ich allesamt schon mal realisiert habe. Aber so im einfachsten Sinne, dürften die Tabellen oben für Deine Zwecke reichen. Nagelt mich ans Kreuz, wenn ich was vergessen habe ^^.

Viele Grüße
Hurga
 
Vielen Dank für eure Hilfe,

setzt mich grad hin und versuchs :>
 
Zurück
Oben