Die ersten Fragen wären:

- von wievielen Nutzern redest Du?
- wo soll die Datenbank gelagert sein?
- hast Du schon das Datenmodell fertig?

Gruß

Rainer

HerrFrie schrieb:

- Die Anzahl der Nutzer ist nicht geregelt. Momentan arbeiten wir mit einer Excel Liste, dort hat immer nur einer Zugriff drauf. Entweder beschränken wir das auf z.B. maximal 3 Nutzer oder lassen es bei nur einem Benutzer.

Es geht hierbei nicht darum wieviele User wirklich zugreifen, sondern wieviel User maximal gleichzeitig zugreifen können sollen. Einfach weil Access so bei rund 10 Nutzern anfängt kniffelig zu werden.

- Die Datenbank und Programm liegen auf einem Server. Einen SQL Server laufen zu lassen ist nicht möglich.

Was wären die Gründe dafür?

- bei dem Datenmodell bin ich mir halt noch nicht so sicher. Die Tabelle 1 mit den Ersatzteilen ist die Haupttabelle. Bis jetzt steht nur die Tabelle der Lieferanten in Relation. Die Tabelle 3 mit den Maschinen habe ich zur Zeit nur für eine Auswahl beim Abbuchen der Ersatzteile gedacht. Jede Abbuchung muß dann quasi in eine Tabelle 4 geschrieben werden. Dort wird die Maschinen ID für spätere Auswertungen mit rein geschrieben.

Solange Dein Datenmodell nicht steht ist es allerdings völlig unsinnig sich über Ausführungsdetails zu unterhalten. Ein Datenmodell ist ja eh DBMS unabhängig.

Würde vorschlagen Du machst erstmal das ERM fertig und dann guckt man mal weiter. Vor allem habe ich im Opener-Thread ein paar Punkte gesehen die so wie Du es Dir denkst überhaupt nicht sinnvoll sind. Z.B. die Lagerbestände.

Ein Lagerbestand ergibt sich nicht aus einem Wert den Du eingibst/berechnest, sondern wird in der DB fortlaufend aus Stückzahl-Eingang und Stückzahl-Ausgang ermittelt. Du brauchst also eine Tabelle für die Zu- und Abgänge zu jedem Artikel.

Genauso passen vermutlich einige der anderen Angaben nicht die Du da in das Table Artikel quetschen willst, wie z.B. Preis ... erstens müsste es Netto-Preis sein (die aktuelle Mehrwertsteuer ergibt sich schlicht aus dem Table für die Mehrwertsteuer ^^), zweitens ist Preis eine extrem variable Größe ... ändert sich relativ häufig. Wäre prinzipiell sinnvoll Preise zu Artikeln daher auch in einer eigenen Table zu verwalten. So bekommt man zusätzlich auch einen Überblick über die Preishistorie. Da in so einem eigenen Table natürlich nicht einmal eingetragene Preise überschrieben werden, sondern bei Preisänderung ein neuer Preiseintrag für den Artikel hinzu kommt: Kostet X € ab Datum XX.XX.XXXX.

Lieferanten direkt ins Table einzufügen halte ich auch für überdenkenswert, denn habe schon oftmals erlebt das irgendwann Artikel auf einmal von einem anderen Lieferant geliefert wurde da der bessere Konditionen angeboten hat. Oder ist sowas bei Euch zu 100% und für immer und ewig ausgeschlossen?

Lagerort und -positionen sind auch so ein heikles Thema. Ändern die sich nie?

Mir würden jetzt noch jede Menge anderes einfallen. Aber das hebe ich mir mal auf.

Wie Du siehst ist das was Du vorhast sinnvoll und funktionsfähig umzusetzen doch viel komplexer als Du es Dir gerade offensichtlich vorstellst. Da ist dann die Wahl des DBMS und mit welcher Programmiersprache baut man das Frontend eher Kinderkram gegen.

Übrigens wieso nicht gleich das Frontend auch in Access erstellen anstatt in VB? Spricht da was dagegen?

Gruß

Rainer

Ich schliße mich den Letzten Posting an,

Eine Acces Datenbanck ist eigendlich Schwachsing, nicht nur dass sie ab 10 nutzern knifelig wird, sie ist auch in vb.net (ich gehe von einer Windows Forms Anwendung aus) auch etwas Kniffeliger umzusetzen. Es existieren Data Set und Linq als Nette Mögligkeit daten von einen SQL (SQL Expresss geht auch) abzurufen!

Und ich würde ales Step by Step machen.

1: Auf Papier beginnen die Datenbanck zu Endwerfen (So habe ich es gemacht, mit erfolg )
2: Die Datenbanck auf den Server einzurichten, es giebt einen guten Freehoster für MSSQL free-sql.bizhostnet.com/
3: Wen man dass 3 Schichten Modell nutzt (Stichwort Verteilte Anwendung) Dann mit den Server Anfangen (somee.com), als Free Webhoster endpfolen
4: Die Windows Anwendung Erstellen (vileicht über SOAP die Daten Hin und her schieben)

Dann kanst du Optional noch:

5: Ein Webinterface erstellen (Ist nicht so Kompliziert wie es aussuht)
6: Ein Loggo Endwerden, und deinen Program Style geben

Aber halt erstmal alles wircklig Schrittweise, den wen du keine Datenback hast, dann ist dass Project für Ar***, westrehst!
Die Community Hilft dir gerne weiter, aber dass heißt nicht dass die Community alles für dich macht den du must auch Selber Handanlegen!

Viel Spaß beim Programmieren!

@ zn-gong

Eine Acces Datenbanck ist eigendlich Schwachsing, nicht nur dass sie ab 10 nutzern knifelig wird, sie ist auch in vb.net (ich gehe von einer Windows Forms Anwendung aus) auch etwas Kniffeliger umzusetzen. Es existieren Data Set und Linq als Nette Mögligkeit daten von einen SQL (SQL Expresss geht auch) abzurufen!

DataSet und LINQ sind keine speziellen Objekt-Modelle für SQL-Server. Du kannst diese Objekt-Modelle mit jeder Datenbank gleich gut verwenden, also auch mit MS-Access.

Und jetzt noch auf LINQ zu setzen wäre unsinnig nachdem MS selber erklärt hat das sie das erst neu eingeführte LINQ jetzt wieder sterben lassen und alle Entwickler hin zu Entity Framework abgezogen haben.

@ HerrFrie

Also gut ... der Reihe nach ^^:

HerrFrie schrieb:

Als erstes einmal der Server. Da es sich hier um eine große Firma handelt ist es mir nicht möglich/erlaubt irgendwelche Server zu erstellen und zu verwalten. Deshalb ja der Gedanke mit einer Datenbankdatei. Die nächste Frage die wahrscheinlich kommt ist, warum wir in einer großen Firma keine ordentlichen Programme dafür haben. Die Antwort ist schlicht, weil es kein Programm gibt, was einfach in der Handhabung ist, ohne viel Schnick Schnack und auf unsere Bedürfnisse angepasst ist. Hinzu kommt, dass hier zu viele Manager rum laufen...
Für unsere Abteilung haben wir bis jetzt mit 2 verschiedenen Programmen gearbeitet. Zum einen mit einer Excel Liste und zum Anderen mit einem Wartungsprogramm, welches auch Ersatzteile verwalten kann, aber völliger Mist ist.
Es bleibt mir also nur eine Datendatei. Es muss aber nicht wirklich eine Access-Datenbankdatei sein, ich habe nur bis jetzt mit nichts anderem gearbeitet.

Ihr habt also 4000 Artikel/Ersatzteile zu verwalten und eine eigene Einkaufsabteilung die deutlich besser (im Sinne von kosteneffizienter) agieren kann je genauer und detaillierter die Auswertungen über die Artikel sind und womöglich noch eine Controlling-Abteilung die wesentlich effizienter Kosteneinsparungspotential ermitteln könnten wenn sie auf Knopfdruck und sofort verfügbar Auswertunge jeglicher Art über Artikel, deren Historie und Verwendung haben würden ... und Du darfst dafür keinen SQL-Server installieren ... noch nicht mal einen "kostenlosen" MySQL-Server?

Davon mal abgesehen das der Einsatz eines ordentlichen Datenbanksystemes im Laufe der Zeit x-tausende von Euros an unnötigen Personalkosten - durch pure Zeitersparnis im Sinne von Verfügbarkeit aller Daten auf Knopfdruck anstatt händischer Zusammenstellung/Überprüfung - sparen würde.

Ehrlich ... wie bescheuert muss man sein? o_O

Zum Thema ordentliches Programm ... es gibt genug DB-Entwickler - wie auch meiner Einer - der sowas speziell auf die Bedürfnisse Eurer Firma erstellt. Klar kostet das Geld, aber im Vergleich zu den Einsparungen die ihr dadurch erzielt wäre das ein Witz bzw. hätte sich in kürzester Zeit amortisiert. Also das es keine passende Standard-Lösung auf dem Markt gibt ist daher nun wirklich eine faule Ausrede.

Aber gut ... nicht mein Problem.

Bei 4000 Artikeln würde ich es langsam eng mit Access sehen. Nicht wegen der 4000 Artikel das ist Pillepalle. Aber die Lagerbestandsverwaltung dürfte da das Problem sein ... selbst nur vier bis fünf Lagerbewegung pro Artikel pro Woche im Schnitt würden pro Jahr mal rund 1 Mio DS ergeben. Das würde einen SQL-Server noch nicht wirklich anstrengen aber für ein passives DBMS wird es da schon enger ... vor allem bei Mutli-User Zugriffe.

Da wirst Du mit Access einiges an Zeit in performante Abfragengestaltung und -bearbeitung investieren müssen und vor allem in ein Archvivierungssystem das die Anzahl DS auf nur die aktuellen beschränkt (z.B. nur die Lagerveränderungen in diesem Jahr, letztes Jahr ist archiviert und dieses Jahr beginnt dann halt mit dem Endstand des letzten Jahres).

Mögliche Alternativen wären SQLite oder MS SQL Compact. Beides auch passive Single-File DBMS. SQL Compact hat den Nachteil der Größenbeschränkung auf 2 GB (wie Access auch), SQLite kann dagegen problemlos bei zu 2 TB verwalten. Ist auch um einiges schneller als die beiden MS-Systeme. Allerdings klappt die Anbindung an MS Visual Studio natürlich mit den MS-Produkten besser ... eh klar.

So habe ich da nicht drüber nachgedacht. Hier hätte ich es mir einfach gemacht und den Ist-Bestand nach Abbuchung/Zubuchung einfach verändert.

Forget it. Nach der ersten Fehlbuchung weisst Du was daran so völlig krank und pervers ist ... nämlich das der komplette Lagerbestand für den Allerwertesten ist. Du kannst ja nicht mehr nachvollziehen was und wann Du falsch gebucht hast ... sondern Du hast jetzt X Stück und keine Ahnung wie Du dahin gekommen bist. Selbst bei der kleinstens Vermutung einer Fehlbuchung musst Du dann gleich mal in Lager rennen und alles händische nach zählen.

Das machste im besten Falle einmal und danach trittst Du so ein System in die Tonne wegen Untauglichkeit.

Um mir hier den aktuellen Ist-Bestand anzeigen zu lassen müsste ich demnach erst alle Abbuchungen/Zubuchungen berücksichtigen ? Das hört sich jetzt bei etwa 4000 verschiedenen Ersatzteilen nicht so einfach an. Die Historie für die Buchungen dient der Gesamtkostenrechnung der einzelnen Maschinen und eventueller sonstiger gewünschten Auswertung unserer Bestellanforderer. Z.B. monatliche Kosten von Ersatzteilen oder so.

So eine Zugangs-/Abgangsbuchung ist total einfach ... Table mit Verbindung zum Artikel-Table und dort werden alle Zu- und Abgänge stückzahlmäßig erfasst und mit dem FK des Artikels versehen und auf der anderen Seite mit einem FK zu einem Buchungsvorgang (Eingang durch Lieferung, Eingang durch Rückgabe, Ausgang durch Auslieferung etc., etc.).

Wenn ich jetzt für jedes Ersatzteil eine eigene Table für die Preishistorie mache, würden das ziemlich viele Tables werden bei ca. 4000 Ersatzteilen. Bläht das die Datenbank nicht ziemlich auf ?

Das funzt genauso wie das Table für den Artikelbestand. Die Preishistorie ist genau EIN Table und nicht mehr. Welcher Preis zu welchem Artikel gehört wird wiederum über einen Eintrag des Primary Key des Artikels als Foreign Key in der Table Preishistorie vorgenommen, dazu noch ein Datum ab wann der Preis gültig ist (oder eben war) und fertig ist der Lack.

Ja, da hast du recht. Aber das Programm sollte auch gar nicht so komplex werden .

Für unsere Abteilung würde es völlig ausreichen, wenn wir die Ersatzteile z.B. in einem DGV sehen, und dann bei Bedarf abbuchen können. Eine Historie wäre bei uns eigentlich unnötig.

Dann lass es besser bleiben. Wieso ein Datenbank-System einrichten/erstellen wenn es nur das gleiche wie die bereits vorhandenen Excel-Listen können soll? Daten in einem DGV anzeigen kannst du auch direkt aus einer Excel-Liste machen.

Da aber unsere Bestell-Leute Korrekturen und Auswertungen machen müssen wird es komplexer.

So wie ich das von denen verstanden habe, benötigen sie eine Liste aller Abbuchungen um die einzelnen Maschinenkosten zu bekommen. Dies denke ich wäre jetzt für mich auch kein Problem. Da würde ich dann eine Tabelle machen, in dem alle Abbuchungen mit dem aktuell gespeicherten Artikel-Preis gespeichert würden. Zusätzliche könnte ich dort auch Zubuchungen für Korrekturen oder gelieferten Artikel mit rein schreiben.[/quote]

Ah oki ... das klingt noch nach Arbeiten wie zu Großvaters Zeiten ... weisst schon, zu der Zeit wo Bismarck noch Reichskanzler war.

Mit einem ordentlichen Datenbanksystem könnten die auf Knopfdruck ihre Auswertungen selber erstellen anstatt Dich mit der händischen Aufzeichnung zu beauftragen. Da schüttelt es mich richtig gehend wenn ich daran denke wieviel Kohle wegen völlig uneffizientem Workflow bei Euch Monat für Monat rausgebuttert wird.

Gruß

Rainer

Also dass mit den Wasserköpfen und zuvielen Managern kennich in der Art ungefähr auch, und die Frage, "wie bescheuert?" zu lösen ist IMO Einsteins wirkliche Leistung:

Einstein schrieb:

Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.

Also ich sehe dein Projekt aus 2 Gründen als zum Scheitern verurteilt
1) Es will niemand haben
2) IMO kann ein Anfänger das nicht, das mussn Profi machen

HerrFrie schrieb:

Dann muß ich es doch irgendwie ohne Hilfe versuchen.

Eine lobenswerte Einstellung.

Lassen wir einfach mal das Thema was und wieso und kümmern uns mal um Dein Problem.

Hierbei sind wohl die verbreitetsten *.mdf und *.mdb. Deshalb kam ich auf die Access Datenbank *.mdb, da ich dieses auch per Access kontrollieren kann. Eine reine Anwendung in Access wäre da wohl auch per VBA möglich, es ist aber nicht auf jedem Rechner Access installiert. Meine Anwendung würde ich gerne in Visual Basic schreiben, da ich damit schon mal öfters gearbeitet habe.

Im deutschsprachigen Raum sind vermutlich die Access-DB-Files die weit verbreitetsten. Allerdings auch nur vermutlich, da gerade auf mobilen Geräten meistens lieber SQLite eingesetzt wird und wer ein bisserl besser DB haben will geht eh auf SQLite, bzw. seit neuestem auf SQL Compact.

Access läuft auch auf Rechnern auf denen keine Access-Vollversion installiert ist, Stichwort Runtime. Ab Access 2007 kann jeder Besitzer einer Volllizenz zu eigenen Access-Entwicklungen die Runtime unlimitiert weiter geben.

Mit was hast Du gearbeitet ... Visual Basic oder VB.NET? Bis auf die Grundzüge der Sprachsyntax haben die beiden Visual Basic Versionen nichts mehr miteinander gemeinsam. Da hat Visual Basic deutlich mehr Gemeinsamkeiten mit Visual Basic for Applications.

Bei dem wie genau die Datenbank aufgebaut werden soll, brauche ich dann auch Hilfe.

Gerne, dafür sind wir hier ja im forum.

Hier kann ich nur vorgeben, welche Daten/Spalten vorhanden sein sollen.

NEIN und nochmals NEIN.

Völlig falsche und vorallem völlig untaugliche Herangehensweise an die Erstellung einer DB.

Eine DB bildet den Datenfluß der Realität ab. Daher wird ein Datenmodell auch IMMER UND AUSNAHMSLOS auf die Abbildung der Realität aufgebaut.

Ist das richtig umgesetzt worden bekommst Du eh alle Informationen die Du brauchst, selbst die an die Du heute noch gar nicht denkst.

Daher ist eben nicht die Frage was für Daten willst Du haben, sondern ab welcher Stelle des WorkFlows bei Euch soll die DB ansetzen und bis zu welcher Stelle im WorkFlow den Datenfluss abbilden.

Nur so bekommst Du eine DB die erstens funktioniert, zweitens alles (aber auch wirklich alles) bereit stellt was Du jetzt und in Zukunft brauchst und vor allem eine DB die auf zukünftige Änderungen im WorkFlow oder im Datenfluss flexibel angepasst werden kann.

Alles andere ist Humbug und schon gestorben bevor Du das erste Mal echte Daten eingegeben hast.

In dem Sinne hast du zwar beschrieben was Du für Daten DERZEIT brauchen würdest, aber diese Information ist eben - siehe oben - völlig uninteressant.

Und bevor Du anfängst liest Du zu aller Erst das hier durch:

v.hdm-stuttgart.de/~riekert/lehre/db-kelz/

Oder eine andere sinnvolle und umfassende Einführung in das Thema Datenbanken.

Arbeite Dich darein, bei Fragen antworte ich Dir gerne und wenn Du alles begriffen hast dann kannst Du mit der Erstellung Deines Datenmodelles beginnen. Und wirklich erst dann und keine Minute früher.

Das was Du vorhast und wofür Du es brauchst muss funktionieren und sitzen. Wenn bei einer DB die die private CD-Sammlung verwaltet mal Daten verloren gehen, falsch verarbeitet werden und sonst ein Datenchaos passiert ist es nicht tragisch ... bei Dir wäre das katastrophal, denn wer bekommt den Anschiß wenn es Fehleinkäufe auf Grund falscher Daten von Dir gibt?

In meinem Buch wird meißtens die komplette Datenbank in ein Dataset/DataTabel eingelesen.
Ist das so die gängige Vorgehensweise z.B. bei einer solchen verwaltung ? Oder fährt man besser eine Select Anweisung nach Eingabe des Suchbegriffes gegen die DB ?

Wie schonmal gesagt ... über sowas jetzt nachzudenken ist das gleiche wie ein Dach zu bauen bevor das Haus steht. Solche Themen haben Dich derzeit nicht zu interessieren. Das einzige was im jetzigen Stadium zählt ist das Datenmodell ... alles andere ist komplett nachrangig.

Glaub es mir ... eine DB-Anwendung lebt nur von einem: Dem Datenmodell. Alles andere ist völlig schnurzpiepegal ... selbst die Wahl des DBMS ist nachrangig. Bzw. ergibt sich auch irgendwann zwangsweise aus dem Datenmodell.

Gruß

Rainer

raist10 schrieb:

Oder eine andere sinnvolle und umfassende Einführung in das Thema Datenbanken.

Probierma "Main.doc" auf Movie-Tuts
Das ist sicher nicht umfassend, aber ich hab mir Mühe mitte Verständlichkeit gegeben. Und die relationale GrundIdee

Jo, und tät mich dann auch interessieren, obs dir ühaupt was bringt.

kannst auch die anneren Tuts probieren, aber nur so zur Beruhigung gewissermaßen. Weil ich stell mir vor, das beunruhigt einen, wenn man sich iwie Tabellen vorstellt, und dann kriegt man gesagt: "kümmer dich erstmal um was ganz anneres".

Also die Beruhigung könnte darin liegen, dass du siehst, es ist wirklich möglich, sich beliebige Views aufzubauen, wie man sie braucht, wenn nur das Datenmodell hinhaut.

na, man muß sich das vergegenwärtigen, einfach, wies ist:

Ich denke mal: an einem LagerOrt können viele Ersatzteile lagern.
Ein Ersatzteil kann mehrmals gebucht werden (dadurch verändert sich der Bestand, aber das ist ein berechneter Wert, nämlich die Summe aller Buchungen überhaupt, oder?)

Daraus folgt:

LagerOrt -> Ersatzteil: 1:n
Ersatzteil -> Buchung: 1:n

Dann würdichnoch empfehlen, die Primärschlüssel namensgleich mit ihren Tabellen zumachen, also ErsatzteilID und LagerortID.
Und die ForeignKeys namensgleich mit den PrimKeys.

Dann sieht man sofort, was wie verknüppert ist.


Oder kann dasselbe Ersatzteil auch an verschiedenen Orten gelagert sein?

@ HerrFrie

Lass uns mal gucken welche realen Entitäten an Deinem kleinen Modell beteiligt sind:

Mitarbeiter
Lieferant
Hersteller
Artikel
Lager

Und dazu kommen noch eine nicht-reale Entität:

Buchung

Ist Buchung aber wirklich nicht-reale? Eigentlich auch nicht, da vermutlich (fast) jede Buchung auf einem realen Vorgang basiert und es vermutlich für jeden Vorgang auch einen Beleg gibt. Eigentlich müsste man das daher Belege nennen ... aber trifft es auch nicht das es ja auch "Luftbuchungen" gibt, z.B. Korrekturbuchungen um Inventur-Fehlbestände zu erfassen. Daher bleib ich mal eben nei nicht-realer Entität ... also eine Entität die man nicht anfassen kann und gebraucht wird um Datenfluss-Prozesse abzubilden

Somit hättest Du schonmal 6 Basis-Tables die Dein Modell abbilden muss ... wirklich 6? Nö, eigentlich 5 denn die Entitäten Lieferant und Hersteller sind beides Firmen und gehören in einem Table verarbeitet.

Lies Dir auch noch mal den Bereich Normalisierung von Datenbanken durch. Dann wirst Du ganz schnell sehen das Dein Datenmodell dagegen aber sowas von verstösst.

In dem Sinne ... guter erster Ansatz, aber untauglich.

Kleiner Tipp: Erstelle zuerst NUR die realen Entitäten (also die Tables mit ihrem Namen) .... KEINE Attribute dazu (ausser natürlich das Attribut für den Primary Key des Tables ... das MUSS rein) und auch KEINE Beziehungen. Spiele dann im Kopf alles Vorgänge die Du abbilden willst/musst durch und prüfe dann durch ob Du nun alle realen Entitäten die an dem Datenfluß beteiligt sind abgebildet hast.

Wenn das geschehen ist dann gehst Du an die nicht-realen Entitäten (eben die Datenfluss-/WorkFlow-Prozesse die abzubilden sind) ... auch wiederum OHNE Attribute und Beziehungen. In Deinem Falle sämtliche "Bewegungen" von Artikeln. Also das Table Buchungen (wirklich richtige Namenswahl?).

Tipps zur Benamsung:

- Table sind immer als Mehrzahl zu benennen
- Tables sollten immer einen Präfix vor dem Namen haben, als Standard eingebürgert hat sich "tbl" oder "tbl_"
- keine Abkürzungen verwenden sondern sprechende Namen (was Du ja tust )
- Attribut-Namen sollten auch einen Präfix haben, als eine Kennung zu welchem Table sie gehören (erleichtert später ungemein die Arbeit mit SQL), z.B. 3 Buchstaben aus dem Table-Namen

Also würde Dein Table LagerOrt korrekt benamst so heissen: tblLagerOrte oder tbl_LagerOrte. Und das Attribut für den Primary Key im tblLagerOrte würden dann LgOID heissen.

Wenn Du nun alle Entitäten hast geht es an die Beziehungen. Dabei hilft als Trick die Beziehung in ganzen Sätzen nach einer bestimmten Syntax auszuformulieren:

Z.B. Beziehung zwischen tblBuchungen und tblMitarbeiter:

ZU EINER Buchung GEHÖRT exakt ein Mitarbeiter, ZU EINEM Mitarbeitern GEHÖREN keine oder mehrere Buchungen.

Mehr gibt es dazu nicht zu sagen und damit ist die Beziehung sauber definiert und Du kannst diese nun auch umsetzen: tblBuchungen - n:1 - tblMitarbeiter, der Foreign Key von tblMitarbeiter sollte dann als MANDANTORY (verpflichtend, also nicht Null und auch nicht Leer) deklariert sein.

Aber nun kommt die spannende Frage, wie lautet die Beziehung zwischen tblBuchungen und tblArtikel?

ZU EINER Buchung GEHÖREN ein oder mehrere Artikel, ZU EINEM Artikel GEHÖREN eine oder mehrere Buchungen

Wieso gehören zu einer Buchung mehrere Artikel ... einfach weil ein Wareneingang oftmals aus der Lieferungen mehrerer Artikel auf einem Lieferschein bestehen kann. Ein Lieferschein wiederum ist eine echte Entität und sollte auch so abgebildet sein ... jeder würde Dich erschlagen wenn er für 50 Artikel auf einem einzigen Lieferschein 50 einzelne Buchungen vornehmen müsste.

Somit haben wir eine klassische m:n Beziehung und die kann nur über ein Zwischentable aufgelöst werden. Und daraus ergibt sich einfach automatisch die Führung der Stückzahl-Bewegungen als fortlaufende Erfassung von Stück-Eingang und Stück-Ausgang.

Durch die Erfassung mehrerer Artikel aus einer Buchung heraus ergibt sich auch zwangsläufig das bei der Eingabe erfasst Attribute zu einem Artikel nicht im tblBuchungen geführt werden können, sondern als Attribute des Zwischentables das die m:n Beziehung auflöst geführt werden müsssen. Was könnten das für Attribute sein? Ganz klar ... z.B. Stückzahl MIT einer Vorzeichen-Erfassung (eben ob Eingang oder Ausgang) oder auch eine Buchungs-Art (Wareneingang, Warenausgang, Rtoure als Eingang, Retoure als Ausgang, Korrektur-Buchung).

Wieso Buchungs-Art direkt zum Artikel und nicht zu einer Buchung komplett? Nun ja ... wird der Realität gerechter da selten aber denkbar Buchungen die auf einem realen vorgang basieren durchaus auch mehrere unterschiedliche Arten von Gründen für Artikelbewegungen beinhalten können. Z.B. Lieferant liefert Ware an und nimmt andere (z.B. reklamierte) Ware wieder mit.

Viel Spaß beim Umsetzen.

Gruß

Rainer

raist10 schrieb:

Mitarbeiter
Lieferant
Hersteller
Artikel
Lager

Und dazu kommen noch eine nicht-reale Entität:

Buchung

Interessant - um nicht zu sagen: fabelhaft!

Die fehlende Entität Lieferschein sprichst du im weiteren ja an.
Ich zB. komme mit dem Begriff Buchung nicht klar - was ist das? - ist das vlt. dasselbe, was ich als "LieferscheinPosten" bezeichen würde? Also eine Zeile auf einem Lieferschein, wo drin steht: "DerUndDer Artikel, so viele davon"?

Wie löst du das Problem mit sich ändernden Preisen? Die Preisangabe eines Artikels hat ja nur für einen bestimmten Zeitraum Gültigkeit. Und es darf ja nicht eine Lieferung sich nachträglich verteuern, wenn der Hersteller den Preis anhebt.

Oder sollemer das erstnoch hintanstellen?

Lieferant würdichnoch diskutieren, ob HerrFrie den braucht oder nicht. Ich könnte mir auch ein Modell ohne Lieferant-Entität vorstellen, angenommen, man bestellt beim Hersteller, und der bestimmt und kümmert sich um den Lieferanten.
Also muß HerrFrie wissen natürlich

ErfinderDesRades schrieb:

Die fehlende Entität Lieferschein sprichst du im weiteren ja an.
Ich zB. komme mit dem Begriff Buchung nicht klar - was ist das? - ist das vlt. dasselbe, was ich als "LieferscheinPosten" bezeichen würde? Also eine Zeile auf einem Lieferschein, wo drin steht: "DerUndDer Artikel, so viele davon"?

Nein, eine Buchung in meinem Sinne, wäre nicht der LieferscheinPosten sondern der komplette Lieferschein. Der LieferscheinPosten selber wird über das Zwischentable der m:n Beziehung tblBuchungen zu tblArtikel erfasst. Das hält flexibler jede Art von Bestandsveränderung realitätsnah abzubilden ... also die Realität genauso wie sie gegeben ist umzusetzen.

Buchung ... wäre in meinen Augen alles was eine Artikelbestandsveränderung verursacht. Das kann durch reale (im Sinne von anfassbar) Dinge geschehen, wie z.B. Lieferscheine. Aber auch durch nicht-reale Dinge (im Sinne von nicht anfassbar), wie Bestandsveränderung auf Grund Inventurdifferenz oder andere nicht fassbare Warenabflüsse (Warenzuflüsse habe ich hier noch nie erlebt ^^).

Klar kann man alles auf eine Entität Lieferschein zurück führen, wenn man wollte. Aber das hiesse den echten Workflow-Prozess im Unternehmen beeinflussen zu müssen und jede mögliche und denkbare Stelle wo Warenveränderungen verursacht oder erfasst werden zum Ausfüllen eines Lieferscheines zu zwingen. So wird es leider auch oftmals gemacht.

Ich wehre mich aber dagegen weil die Datenbank dann nicht die Realität abbildet, sondern die Realität gezwungen wird Datenbank gerecht zu werden. Das ist selten eine gute Idee, angefangen von mangelnder Akzeptanz bei betroffenen Mitarbeiter (Stichwort "Wieso soll ich einen Lieferschein erstellen, ist nur zusätzliche Arbeit und haben wir noch nie so gemacht") und zweitens, meistens sehr unflexibel da Änderungen im Workflow-Prozess nicht abgebildet werden können, da ja die Datenbank danach designed wurde das die Realität auf die Datenbank angepasst wird.

Daher arbeite ich gerne mit solchen - für mich selbst so genannten - nicht-realen Entitäten. Die letztendlich nichts anderes sind, als die Zusammenfassung mehrerer realer Entitäten eines gleichartigen Vorganges ... in dem Fall wäre der Vorgang eine Änderung am Artikelbestand. Der Vorteil liegt auf der Hand: Ich kann darüber jegliche Veränderung am Workflow/Datenfluss der die Bestandsveränderung betrifft problemlos auch zukünftig ohne DB-Änderung nachbilden weil ich nicht auf eine einzige Entität festgenagelt bin.

Gut ... aber das ist schon arg theoretisch und ich hoffe ich konnte einigermaßen rüber bringen wieso ich das so "vorgeschlagen" habe?

Wie löst du das Problem mit sich ändernden Preisen? Die Preisangabe eines Artikels hat ja nur für einen bestimmten Zeitraum Gültigkeit. Und es darf ja nicht eine Lieferung sich nachträglich verteuern, wenn der Hersteller den Preis anhebt.

Oder sollemer das erstnoch hintanstellen?

Das Thema Preis so wie alle anderen Attributs-Entitäten (auch wieder meine eigene Begrifflichkeit ) stelle ich immer ganz hinten an.

Attributs-Entitäten aus dem Grund weil Preis eines Artikels eigentlich nur ein Attribut der Entität Artikel ist. Aber es Sinn machen kann eine eigene Entität daraus zu machen um Preis-Historien abbilden zu können.

Das es aber vom Ausgangspunkt her nur ein Attribut ist, berücksichtige ich das erst später, eben wenn ich mich um die Attribut-Details eines Tables kümmere ... es betrifft ja eh nur dieses Table und hat keinerlei Einfluss auf das Zusammenspiel der Haupt-Entitäten untereinander, bzw. würde davon nur ablenken.

Wie hätten in dem Modell sofern gewollt nämlich jetzt schon erkennbar eine größere Anzahl an Attributs-Entitäten (darunter fallen für mich auch die klassischen LookUp-Tables) einzuarbeiten ... z.B. Lieferanten-Adressen und Kontakt-Daten (davon kann es ja mehrere pro Lieferant/Firma geben und Adresse1, Adresse2, Adresse3 oder Telefon1, Telefon2, Telefon3 ist ja mal gar keine Lösung dafür ^^), Buchungs-Arten (eben Lieferschein z.B.), etc., etc. ... .

Der wird HerrFrie eh noch richtig Blut und Galle spucken bis er da durch ist.

Lieferant würdichnoch diskutieren, ob HerrFrie den braucht oder nicht. Ich könnte mir auch ein Modell ohne Lieferant-Entität vorstellen, angenommen, man bestellt beim Hersteller, und der bestimmt und kümmert sich um den Lieferanten.
Also muß HerrFrie wissen natürlich

Daher eben auch mein Ansatz Lieferant und Hersteller in einem Table zu verwalten.

Dadurch ist es eh nur noch Pillepalle ob man nun nur eine Beziehung für Hersteller zum Table Artikel erstellt oder noch eine zweite dazu packt für Lieferant. Wobei hier wohl als Erstes genau zu klären wäre was ist nun Hersteller und Lieferant genau ... also auf gut Deutsch wie ist die Realität dazu. Es könnte sich durchaus daraus nämlich eine weitere nicht-reale Entität ergeben ... z.B. Bezugsquelle. Was dann richtig spanend wird, weil man dann nicht mehr zum tblArtikel verbinden muss zum zum m:n Table zwischen Buchung und Artikel oder direkt zum Table Buchungen. Muss man gucken was HerrFrie dazu zu sagen hat.

Aber das sind dann die Fragen die automatisch auftreten wenn man den ersten Schritt im ERM gemacht hat ... reale Entitäten und nicht-reale Entitäten erfasst hat und nun die Beziehungen zwischen diesen abbilden will. Ich vermute ja das dann eh noch die ein oder andere nicht-reale Entität hinzu kommt bis es letztendlich wirklich auf die Realität passt.

Gruß

Rainer