Datenbankmodellierung

Hallo

Ich hab mal eine Frage zur Datenbankmodiélierung.
Wir haben ein Projekt, wo wir in einer Firma eine Datenbank erstellen sollen über eine Inventur zu Büromaterialien.

Wir haben einige Felder wie Artikel, Raum, Möbel, Verbrauchsgüter,… erstellt.

Nun sollen wir aber noch die Kostenstellen und Abschreibung mit ein beziehen. Aber was hat das mit einer Inventur zu tun?

Wer kann helfen — Danke im voraus

Moin, Seppe,

Nun sollen wir aber noch die Kostenstellen und Abschreibung
mit ein beziehen. Aber was hat das mit einer Inventur zu tun?

das sollte der erklären können, der die Anforderung stellt. Wahrscheinlich müssen die Fehlbestände irgendwo verbucht werden, und das wird bei der Kostenstelle passieren müssen, der die verschwundenen Sachen gehört haben.

Gruß Ralf

Das sagt unser Auftraggeber uns leider nicht. Das sollen wir selber raus finden.

Moin, Seppe,

Das sagt unser Auftraggeber uns leider nicht. Das sollen wir
selber raus finden.

dann mach ihm klar, dass das Datenmodell den Informationsbedarf des Kunden darstellt. Nichts sonst, nicht mehr und nicht weniger.

Wer mir mit dem Spruch kommt „Hasch mich, ich bin der Frühling!“, dem halte ich entgegen „Leck mich, ich bin der Honig!“. Damit bin ich während 20 Jahren QS in der Datenmodellierung bestens gefahren.

Gruß Ralf

OK dann werden wir Ihn nochmal fragen.
Bis jetzt haben wir für unsere DB für Büromaterial folgende Entitäts-Tabellen: Artikel, Raum, Leasing und Verbindlichkeiten.
Wäre das ausreichend, wenn wir diese sinnvoll in Beziehung bringen oder ergibt das keinen Sinn?

Danke

Moin, Seppe,

Das sagt unser Auftraggeber uns leider nicht. Das sollen wir
selber raus finden.

dann mach ihm klar, dass das Datenmodell den
Informationsbedarf des Kunden darstellt.
Nichts sonst, nicht mehr und nicht weniger.

Wer mir mit dem Spruch kommt „Hasch mich, ich bin der
Frühling!“, dem halte ich entgegen „Leck mich, ich bin der
Honig!“. Damit bin ich während 20 Jahren QS in der
Datenmodellierung bestens gefahren.

Gruß Ralf

Moin, Seppe,

Artikel, Raum, Leasing und Verbindlichkeiten.
Wäre das ausreichend, wenn wir diese sinnvoll in Beziehung
bringen oder ergibt das keinen Sinn?

keine Ahnung, das kann wirklich nur der Kunde beantworten. Kann er natürlich nicht, aber er muss doch sagen können, welche Infos er aus dem System ziehen will.

Mir ist zB völlig rätselhaft, wozu bei der Inventur ein Raum gebraucht wird. Muss der Kunde wissen, wo die Sachen lagern? Dann schon. Was hat Leasing mit Inventur zu tun? Inwiefern beeinflusst der Lagerbestand die Verbindlichkeiten?

Der Urfurz des Weltalls der Modellierung ist immer die Frage, was haben wir und wer hat mit wem zu tun. Aus dem ersten ergeben sich Entitäten, aus dem zweiten die Beziehungen. Und wenn dann Entitäten ohne Beziehungen übrigbleiben, dann sind das meist Phantome.

Gruß Ralf

Hi!

Ich helfe nach :wink:

Mir ist zB völlig rätselhaft, wozu bei der Inventur ein Raum
gebraucht wird. Muss der Kunde wissen, wo die Sachen lagern?

Das ist sehr, sehr oft ziemlich hilfreich, z.B. bei eigenen Lagern mit vielen, vielen Räumen - wir sind bei einer Applikation sogar bis ins Regal und zur Reihe gegangen, damit die Dinger auch wieder auffindbar waren (so fielen auch an diversen Orten ziemlich heftige Diskrepanzen bei der Inventur auf).

Was hat Leasing mit Inventur zu tun?

Z.B., ob das Inventarstück geleast ist oder geleast werden kann; da kommen nochmals jede Menge Daten zusammen (wer, was, wieviel, wie lange, zu welchem Preis, …).

Inwiefern
beeinflusst der Lagerbestand die Verbindlichkeiten?

Lieferantenverbindlichkeiten durch den Artikel? Kundenverbindlichkeiten durch den Artikel? Und da kommt auch schon wieder Leasing zusätzlich zum Vorschein.

Der Urfurz des Weltalls der Modellierung
ist immer die Frage, was haben wir und wer hat mit wem zu tun.
Aus dem ersten ergeben sich Entitäten, aus dem zweiten die
Beziehungen.

Wirklich: Sehr schön gesagt!

Und wenn dann Entitäten ohne Beziehungen
übrigbleiben, dann sind das meist Phantome.

Naja, das können auch Parameter-Entitäten oder Referenztabellen sein - und die habe ich eigentlich noch nie in einem Datenmodell verknüpft … es soll ja noch halbwegs „lesbar“ bleiben …

Grüße,
Tomh

Moin, Tomh,

Ich helfe nach :wink:

das muss ich alles nicht wissen - es geht darum, Seppes Auftraggeber klarzumachen, dass seine Mitarbeit gefordert ist. Kein Datenmodell gibt es für lau, und wenn doch, dann nützt es dem Kunden nicht viel.

Und wenn dann Entitäten ohne Beziehungen
übrigbleiben, dann sind das meist Phantome.

Naja, das können auch Parameter-Entitäten oder
Referenztabellen sein - und die habe ich eigentlich noch nie
in einem Datenmodell verknüpft … es soll ja noch halbwegs
„lesbar“ bleiben …

Wie streng das gesehen wird, bleibt dem Modellierer überlassen, Referenzen sind schließlich die halbe Miete auf dem Weg zu konsistenten Datenbeständen. Ich neige da eher zur Prügelstrafe :smile:))

Gruß Ralf

Hi!

es geht darum, Seppes
Auftraggeber klarzumachen, dass seine Mitarbeit gefordert ist.

Das ist sowieso eine andere Geschichte - ein Satz wie Das sagt unser Auftraggeber uns leider nicht. Das sollen wir selber raus finden. würde mal zuallerst die Folge haben, dass 20 Leute 2 Jahre lang das mal „rausfinden“ … natürlich gg. Bares vom Auftraggeber - erstaunlich wie schnell und eindeutig diese dann mit Informationen rausrücken, wenn es um Geld geht :smile:

Ich neige da eher zur
Prügelstrafe :smile:))

Ich sperre nur die DB-Accounts - als letzte Aktion, bevor ich nach Hause gehe :smile:

Grüße,
Tomh