Diskussion:Stammdaten

Kein Singularetantum!

Es handelt sich bei diesem Wort um ein Pluraletantum!

ÜA

Artikel startet mit einer kryptischen Wortgruppe statt mit einer Kurzerklärung des Lemmas. Kategorisierung fehlt --Uwe G. ¿Θ? 13:52, 22. Jun 2005 (CEST)

Abgrenzung zu den Bewegungsdaten fehlerhaft

Ich denke, die Beschreibung ist vor allem bei der Abgrenzung zu den Bewegungsdaten fehlerhaft. Ich würde eher so herangehen (ohne es korrekt formulieren zu können), dass Stammdaten eben einzelne Elemente eines (z.B.) Wirtschaftsprozesses beschreiben, z.B. ein Material, einen Kunden, einen Mitarbeiter, eine Abteilung, einen Lieferanten, eine Ware, ... Bewegungsdaten hingegen beschreiben Prozesse, Geschäftsvorfälle also z.B. eine Bestellung, einen Einkauf, eine Auslieferung oder eben auch eine Entnahme aus dem Lager. Die Angabe, Bewegungsdaten würden die Stammdaten verändern, stimmt so auch nicht. Die Bewegungsdaten haben einen Bezug zu den Stammdaten (wären ohne sie nicht erklärbar) aber sie ändern nichts an den Stammdaten - allenfalls an den Bestandsdaten, die m.E. nicht mit den Stammdaten verwechselt werden dürfen. Aber was schreib ich ? Es muss doch irgendwo eine anerkannte Definition geben ! Thomas Binder, Berlin

Ich bislang habe ich in etwa einem Monat Recherche keine "gute" Definition gesehen. Zumindest nicht "wissenschaftlich". In der Regel nehmen die meisten Praxispaper (Analysten, Marketing) eine implizite Definition von Stammdaten durch aufzählen vor: Kunden, Mitarbeiter, Produkte,... Wenige definieren Stammdaten explizit. Meistens geschieht dies durch dir Abgrenzung von "transacton data" (Bewegungsdaten). Bewegungsdaten Daten repräsentieren Ereignisse/Prozesse (z.B. Verkauf) in einem Unternehmen, "reference data" sind dann die daran beteiligten Objekte (z.B. Kunde, Verkäufer, Produkt, Ort). Als "Master Data" wird weiterführend dann die über Systemgrenzen hinweg vereinheitlichte Version dieser beteigten Objekte bezeichnet. Was man nun im deutschen als Stammdaten bezeichnet... keine Ahnung. Ich denke da fehlt die deutschsprachige Literatur. Ich würde dem Gefühl nach eher zu den beteiligten Objekten tendieren. Das Vereinheitlichen sehe ich eher als Teil des Stammdatenmanagements. Ich habe aber auch schon eine Definition gelesen, welche die oben als reference data bezeichnten Objekte als master data bezeichnet. "Referece data" wird dann wieder anderweitig verwendet. SH, 30.Mai 2006

Hallo SH und Thomas, ich habe den Artikel überarbeitet, die m.E. korrekte Definition klargestellt und einige Missverständnisse bereinigt.

• Missverständnis I: Bestandesgrössen sind Stammdaten: siehe Richtigstellung im Artikel unter Abgrenzung zum Antonympaar Bestandeskennzahl und Bewegungskennzahl
• Weiter werden Änderungen an Stückliste- und Arbeitsplänen als Bewegungsdaten klassiert. Sind Aenderungen an Stammdaten wirklich Bewegungsdaten? Ich meine NEIN. Diese Aenderungen schliessen nähmlich in der Stammdatenhistorie eine vergangen Gültigkeitperiode ab und öffnen eine neue Gültigkeitperiode. Stammdatenmutationen sind damit wie Stammdaten selber Zeitraumbezogen und damit wiederum Stammdaten.

Die Definitionen habe ich frei aus dem Kopf formuliert. Um eine zitierfähige Belegstelle zu finden, würde ich die Schriften von Prof. W. Scheer empfehlen. z.B August-Wilhelm Scheer: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. 1997, Springer, Berlin ISBN: ISBN: 3-540-62967-X.

Freundliche Grüsse, --ollio 00:26, 7. Jun 2006 (CEST)

Hallo ollio, ich hab mir die Definition/Abgrenzung von Bewegungs- und Stammdaten von Scheer (S. 40) nun mal angeschaut. Diese findet allerdings auch eher über Ereignise und Zustände (ähnlich dem, was ich oben geschrieben hab) statt, der Zeitbezug ist eher eine Eigenschaft. Gruß SH

@meine Vorredner: Ich habe mit der hier vorgefundenen Abgrenzung der Antonyme Stammdaten und Bewegungsdaten auch meine Probleme. In einem Skript der Fernuniversität Hagen bin ich nach gezielter, nicht durch diesen Artikel motivierter Suche auf eine Trennung in vier Kategorien gestoßen, die ich gut nachvollziehen konnte. Dort wird in das Paar Stammdaten und Änderungsdaten und in das Paar Bestandsdaten und Bewegungsdaten getrennt, wobei mir der erst- und letztgenannte Begriff aus dem SAP-Projekt, wo ich arbeite, geläufig ist, die mittleren, im Grunde Komplementäre, noch nicht. Die Definition von Bestandsdaten als Stammdaten wie von ollio aufgeführt (im Artikel die Beispiele Warenzugang als Stammdatum, mE eher nicht, Debitor aber schon) habe ich in diesem Kontext ehrlich gesagt nicht verstanden und mag sie eigentlich auch nicht teilen.

In der von mir verwendeten Definition werden unter Stammdaten "[...] zustandsorientierte Daten, die der Identifizierung und Charakterisierung von Sachverhalten in Unternehmen dienen und die unverändert über einen langen Zeitraum zur Verfügung stehen" verstanden. Stammdaten sind den Definitionen folgend "[...] abwicklungsorientierte Daten, die Änderungen an Stammdaten auslösen."

Diesem Paar gegenüber stehen Bestandsdaten als "[...] zustandsorientierte Daten, die zur Beschreibung der betrieblichen Mengen- und Wertstruktur verwendet werden." Bewegungsdaten bilden demnach die Änderungen an betrieblichen Beständen durch "abwicklungsorientierte Daten, die immer wieder neu durch betriebliche Leistungsprozesse entstehen", konkreter z.B. durch Waren- oder monetäre Bewegungen.

Diese Definitionenpaare haben den Charm, daß die statischen und dynamischen Daten der betrieblichen Leistungs"struktur" (ein besserer Begriff fällt mir gerade nicht ein) und der Leistungsprozesse durch saubere Definitionen abgebildet sind.

Im Wesentlichen finden sich diese Überlegungen in Definition 3 (prozessuale Aspekte) wieder, könnten aber von der Struktur mE noch aufbereitet werden. Außerdem sollte mE eine Referenz auf Definition 1 (Datenmodell) gesetzt werden. Denn das Datenmodell modelliert den Realitätssachverhalt, dessen graduell unterschiedliche existenziellen Abhängigkeiten durch den kontinuierlichen Übergang von links nach rechts im Beispiel repräsentiert werden.

Konkret: Ein Wareneingang steht zu einem Vertrag oder mindestens einer Leistungsvereinbarung (inter- oder intrabetrieblich) in Beziehung, benötigt also (internen?) Kreditor und Debitor, Warenbestellung, Bestellanforderung (abhängig von den unternehmerischen Prozessen), finanzbuchhalterische Buchung, darüber dann Daten des Controlling, usw. Über Krditor und Debitor gelange ich zur Versandstelle, Werken und Lagerorten. Kunde, Lagerort, Werk u.a. sind dabei eher Stammdaten als der Wareneingang selbst. Mit dem Vertrag ist dann nicht mehr so einfach, denn dieser ist abhängig von Daten und von diesem sind Daten abhängig.

Aus solchen Überlegungen heraus tritt für mich die Bedeutung von Definition 2 (temporaler Apsekt) zurück und wäre eine Vereinung von Defintion 1 und 3 als Ableitung einer Datenstruktur aus den betrieblichen Prozessen mit gradueller Abstufung hilfreicher. Es wäre unter diesen Aspekten u.U. zu prüfen, ob nicht Definition 1 und 3 auf den selben Sachverhalt abstellen und Definition 2, weil sehr schwammig, vielleicht entbehrlich wird.

Ich bitte zu entschuldigen, daß mein Diskussionsbeitrag nun doch länger geworden ist. Gruß, --Polygraf 22:38, 16. Apr. 2010 (CEST)

infos zum übernehmen!?

bitte mal das hier anschauen - vielleicht kann man etwas davon hier einbauen? ansonsten ist Teilestammdaten entsprechend der LK nun ein redirect hierher. --JD {æ} 02:24, 22. Jan 2006 (CET)

Literatur und Quellen?

Ich schreibe gerade meine Diplomarbeit in dem Bereicht Stammdaten. Leider habe ich bislang keine zufriedenstellende Definition des Begriffs "Stammdaten" oder "master data" gefunden. Auch hier fehlen mir Quellen zu Büchern, Artikeln o.ä. SH, 17.Mai 2006

Hallo SH, Du kannst mit --~~~~unterschreiben, das fügt dann die aktuelle Zeit und eine Link auf Deine Benutzerseite Benutzer:SH ein. --ollio 00:29, 7. Jun 2006 (CEST)

Danke für den Hinweis, aber das da oben stammt nicht von mir... --SH 02:02, 7. Jun 2006 (CEST)

Überarbeiten: Zwei Lemmas in einem?

In diesem Artikel werden offenbar zwei Lemmas mit gegensätzlicher Bedeutung zusammen erklärt: Stammdaten und Bewegungsdaten. Der Artikel sollte deshalb meiner Meinung nach in zwei Artikel aufgeteilt werden. Darüberhinaus ist zu viel in Fettschrift geschrieben und schlecht gegliedert. --Sammler05 08:32, 18. Jun. 2007 (CEST)

Welchen Grund gibt es denn, lieber Sammler05, zwei Begriffe, die (graduell) antonym sind, nicht in einem Artikel zu beschreiben und sie somit gegenüberstellen zu können? Über Redirect von Bewegungsdatum/en kommt man auf den Artikel über Stammdaten.

Ich grüße Dich freundlichtzeh 09:37, 10. Jul. 2007 (CEST)

Änderungsdaten

Ä. sind definiert als diejenigen Daten, welche Stammdaten ändern. Insgesamt entstammt meinem Studium die Klassifikation bezüglich Variabilität geht in Stammdaten und Bestandsdaten. Stammdaten werden durch Änderungsdaten und Bestandsdaten durch Bewegungsdaten geändert. Nacht der unzureichden Zitationsform des Artikels kann ich das belegen mit (Lit: Hansen) und meine damit die Wirtschaftsinformatik I aus dem Jahr 1986. Das war vor der Definitionsbildung über ERM. Der Begriff Änderungsdaten taucht in dem Artikel nicht auf, der historische Teil ist in sofern unscharf. Fände das auch gut, wenn das Lemma Änderungsdaten angelegt würde und ein Redirect auf ein überarbeitetes Kapitel hier fände. grap 13:08, 14. Aug. 2008 (CEST)

Hm... man muss sehr vorsichtig sein, wenn man Studienliteratur als Terminologiequelle heranzieht.
Gerade im IT-Bereich ist die Terminologiebildung nicht abgeschlossen, und das gibt den Professoren Spielraum, ihre eigene Terminologie zu verwenden und zu propagieren (und mit den dahinterstehenden Konzepten auch die Ideenwelt des Professors).
Meiner Erfahrung aus zwei Jahrzehnten (kleinerer) IT-Projekte nach differenziert man nicht nach Daten, die geändert werden und Daten, die ändern; in der Praxis stehen die einen permanent in einer Datenbank und die anderen nicht, und ein Bedürfnis nach terminologischer Differenzierung besteht gar nicht, weil man über die ändernden Daten gar nicht groß nachdenkt (die sind Vehikel für das eigentlich Interessante, Mittel zum Zweck, und werden ad hoc definiert und auch wieder verworfen).
Den Begriff "Bestandsdaten" habe ich uneinheitlich verwendet gesehen. Projektleiter aus der Materialwirtschaft meinen damit die Daten zum Lagerbestand (also reine Bewegungsdaten). Projektleiter aus der IT meinen damit gelegentlich Metadaten (Daten über ihren Datenbestand), meistens aber den Bestand an Daten, den sie dauerhaft pflegen müssen (also Stammdaten, manchmal auch die Gesamtheit aus Bestands- und Bewegungsdaten). Ich halte es für voreilig, für diesen Begriff eine etablierte Bedeutung zuordnen zu wollen.
Der Begriff "Änderungsdaten" bezeichnet meist Daten über Änderungen, die an anderen Daten durchgeführt werden. Dabei wird nicht großartig zwischen Änderungen an Stammdaten oder Änderungen an Bewegungsdaten differenziert, hauptsächlich wohl deshalb, weil an Bewegungsdaten meist nur ergänzt, nicht modifiziert werden.
In Großprojekten wird die Terminologie stark vom Hersteller der eingesetzten Software geprägt. Wenn SAP eingesetzt wird, ist die Terminologie eben die von SAP... aber bisher reicht die Prägekraft dieser Großsysteme nicht aus, um die Terminologie auch in kleinen und mittleren Unternehmen zu bestimmen.
Joachim Durchholz 12:36, 1. Okt. 2008 (CEST)

Hallo Joachim,

wir aus der Informatikzunft könnten die Terminologiebildung zu den den Begriffen "Stammdaten" und "Bewegungsdaten" abschließen, wenn wir sie schlicht über Bord würfen. Diese beiden Begriffe aus der Steinzeit der Datenverarbeitung haben m.E. (nach 4 Jahrzehnten Umgang mit Daten als Programmierer, Datenmodellierer und Datenmanager) heute keinerlei (allenfalls noch aus historischer Sicht) Relevanz mehr. Was heute wichtig und hinreichend ist, ist die Unterscheidung nach der existentiellen Abhängigkeit von Daten (existentiell unabhängige Daten wie Kunde, Produkt, Region und existentiell abhängige Daten wie Auftrag(sposition), Rechnung, Lieferung, Buchung). Um so schlimmer, dass gerade SAP mit seiner großen Verbreitung und damit Wirkung in der Öffentlichkeit noch eine derartige antiquierte Begriffswelt hat. Über den (heutigen) Wert bzw. die Notwendigkeit der Begriffe Bestandsdaten und Änderungsdaten lasse ich mich gerne aufklären. Ich erachte sie als ebenso unwichtig wie die Begriffe Stamm- und Bewegungsdaten.

Mein Vorschlag: lasst uns die o.a. antiquierten Termini konsequent vermeiden und wenn sie von einem Kommunikationspartner verwendet werden, hinterfragen, was er darunter versteht. Wir verlieren hierdurch nichts; im Gegenteil: wir steigern die Verständlichkeit und vermeiden durch die ausschließliche Verwendung der Klassen nach Existenzabhängigkeit Kommunikationsprobleme bzw. Missinterpretationen. Dies ist ganz im Sinne von Ockhams Rasiermesser als Sparsamkeitsprinzip in der Wissenschaft.

Die von Dir erwähnte Interperation der Bestandsdaten als Metadaten überrascht mich; sie wird die Begriffsverwirrung nur noch steigern. Gerade von Projektleitern (ob aus IT oder Fachbereich kommend) sollte man erwarten, dass sie Wert auf in der IT einheitlich verwendete und im Team gemeinsam genutzte Terminologie legen.

Ich grüße Dich freundlich tzeh 17:18, 2. Okt. 2008 (CEST)

Ich stimme deiner 'Eingabe' hier in keiner Weise zu, auch nicht nach weiteren viereinhalb Jahren. Die Unterscheidung zwischen Stammdaten und Bewegungsdaten halte ich für das Verständnis von Datenverarbeitung und Daten sehr wohl von großer Bedeutung. Denn wo so etwas (z.B. im Datendesign) nicht unterschieden wird, findest du zum Beispiel in Daten über 'Aufträge' die (Standard-) Bankverbindung, in Daten über Mahnungen das Datum der Zahlungsfälligkeit - anstatt dass diese Datenelemente (zu den Beispielen) in den Kundenstamm- bzw. in den Rechnungsdaten gespeichert werden, unabhängig davon, dass diese Infos in den Auswertungen/InfoMedien natürlich enthalten sein können. Auch dient die Unterscheidung der Erkenntnis, dass Bewegungsdaten (Vorgangsdaten, Änderungsdaten) naturgemäß immer etwas mit einem 'Zeitpunkt' zu tun haben, insofern auch ein Aspekt von Historie sind.

Kurz; deine Meinung trifft man im Unternehmensumfeld (wie auch zu ähnlichen anderen Strukturaspekten) häufig an, aber 'wesentliche' (das Wesen betreffend) Unterscheidungen nicht im Kopf, besser noch nicht im Gefühl zu haben, ist nach meinen Erfahrungen Quelle vieler Missverständnisse, und nicht nur zwischen IT und Fachbereich. Im Gegensatz zu einem DBMS, dem es völlig egal ist, wie die Tabellen heißen und welcher Kategorie sie angehören, brauchen Menschen 'Strukturen', um damit das Verständnis über Zusammenhänge zu stützen.

Die Metadaten-Aussage könnte man nur im allerweitesten Sinn akzeptieren, was aber wegen anderer Belegung dieses Begriffs ebenfalls für das Verständnis 'gefährlich' ist. Und das Bilden von Begriffen ist nun mal dazu da, um das Verständnis zu stützen, auch bei Stamm- und Bewegungsdaten. Servus von --VÖRBY (Diskussion) 10:54, 20. Mär. 2013 (CET)

Bildbeschreibung fehlt bei [[Bild:SERM_Beispiel2.svg|SERM-Beispiel|600px]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:SERM_Beispiel2.svg|SERM-Beispiel|600px]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 10:25, 2. Mär. 2009 (CET)

Stammdatenhistorie und slow moving change: Schlagwort erfunden und Slowly changing dimensions gemeint?

In Google findet sich auf Anhieb nichts passendes unter "slow moving change". Ein Artikel, der auf die Beschreibung passt, aber im Data Warehouse Themenbereich zugeordnet ist, ist "Slowly changing dimensions". (nicht signierter Beitrag von 217.76.106.30 (Diskussion) 16:28, 27. Jul 2012 (CEST))

Dieses nicht erklärte englische Satzfragment ist m.E. überflüssig wenn nicht falsch. Falls bis zum 18.8.2012 keine stichhaltige Begründung für das Anhängsel der Stammdatenhistorie geliefert wird, werde ich es ersatzlos streichen. tzeh (Diskussion) 14:19, 11. Aug. 2012 (CEST)

Änderungsvolumen (Statik vs. Dynamik)

Alleine die Frequenz von Änderungen kann kein geeignetes Kriterium sein. Denn aus einem täglich 5 mal geänderten Stammsatz wird noch kein Bewegungssatz. Außerdem ist die Beschreibung 'unscharf': Zum Beispiel fallen zu einem typischen Bewegungsbestand 'Zahlungsdaten' in der Regel überhaupt keine Änderungen an, sie treten auf, werden gespeichert (insert) und idR nie mehr verändert, und irgendwann mal (historisiert und) gelöscht. Das macht sie aber nicht zu Stammdaten. Insofern sollte der Text etwas präzisiert werden.--VÖRBY (Diskussion) 19:35, 19. Mär. 2013 (CET)

Ich passe den Text entsprechend an.

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 11:17, 8. Apr. 2013 (CEST)

Falscher Link zum englischen Artikel?

Sollte nach meinem Verständnis nicht auf http://en.wikipedia.org/wiki/Reference_data verweisen, sondern auf http://en.wikipedia.org/wiki/Master_Data. (nicht signierter Beitrag von 91.16.148.61 (Diskussion) 10:52, 26. Mai 2013 (CEST))

Zur existentiellen Abhängigkeit

Die „existentielle Abhängigkeit“ kann in der sog. Realwelt sowohl bei den Realobjekten wie auch den zugehörigen Abstrakta (siehe dazu ifgi.uni-muenster.de/~h_bred01/misc/DB/VL/Kapitel2.pdf und Andre Zdunek: Ontologie, Wahrheit und Kausalität) und in den Datenmodellen sowohl auf Entitäts- wie auch auf Entitätstyp-Ebene (s. ER-Diagramm) bestehen. Sie schlägt sich nieder in den den Realitätsauschnitt beschreibenden Daten (sei es in Datenbanken - sei es andernorts), indem sichergestellt wird, dass es kein abhängiges Datum ohne das zugehörige unabhängige Datum gibt. Die unabhängigen Daten werden dann als Stammdaten bezeichnet.

Keineswegs ist der Terminus „Datensatz“ synonym zu dem Terminus „Entität“. Dies hieße ja, man könnte die beiden Worte in jeder Situation austauschen.

Daher wähle ich folgender Formulierung:

1. über die existentielle Abhängigkeit, die zwischen einzelnen Entitäten wie auch zwischen den zugehörigen Entitätstypen) (synonym Objekttypen) bestehen kann (so setzt z. B. ein Auftrag die Existenz eines Kunden voraus; demnach gilt: kein Auftrag ohne Kunde). tzeh (Diskussion) 20:20, 19. Dez. 2014 (CET)

Die Abhängigkeit besteht zunächst immer zwischen den Entitäten. Da aber in der IT letztlich 'Entitätstypen' gebildet und beschrieben werden, wird dort, v.a. bei Dateenbanken, auch die Abhängigkeit formuliert. Das "wie auch" ist insofern evtl. irreführend, weil das lediglich eine andere Modellierungs-/Formulierungsebene ist. Da hier bei 'Stammdaten' aber nicht zwangsläufig das Thema 'Modellierung' angesprochen werden kann (so wie man auch nicht zwangsläufig von Datenbanken ausgehen kann), verwendete ich den allgemeineren Begriff 'Datensatz'. Auch weil 'Entität' nur jemand versteht, der sich mit Modellierung beschäftigt. Falsch ist aber Deine Formulierung nicht. Gruß --VÖRBY (Diskussion) 23:22, 19. Dez. 2014 (CET)

Qualität der verwendeten Quellen

Ich denke, es würde der Qualität des Artikels gut tun, für die Definition des Begriffs "Stammdaten" statt einer kleinen IT-Beratungsfirma ein einschlägig anerkanntes Informatikbuch oder hochgerankte Journalartikel heranzuziehen - in der aktuellen Form, finde ich, wirkt es eher so, als hätte sich diese Firma ganz kuschelig in diesem für mehrere Disziplinen sehr wichtigen Artikel eingenistet, um ihren Namen zu verbreiten. Inhaltlich kann ich leider keine angemessenen Empfehlungen machen, da ich nicht vom Fach bin und nur am Rande mit dem Thema zu tun habe. --132.199.121.95 12:18, 17. Jul. 2018 (CEST)