Auszug
Die in diesem Teil IV vorgestellte Methode zur Data-Warehouse-Entwicklung zielt darauf ab, die wesentlichen in den vorangegangenen Abschnitten aufgezeigten Probleme und Herausforderungen zu lösen. Die Methode kann als Instanziierung des in Abschnitt 3.2.3 entwickelten Methoden-Metamodells betrachtet werden, d. h. sie beschreibt für den Anwendungsfall Data Warehousing Prinzipien, Aktivitäten, Techniken und Notationen sowie zu entwickelnde Ergebnisse.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Lehner et al.: Wirtschaftsinformatik, 1995, S. 292 ff.
Vgl. auch Goeken, Burmester: Data-Warehouse-Entwicklung, 2004, S. 55 ff.; Goeken, Burmester: Business Intelligence, 2004, S. 142.
Vgl. Goeken, Burmester: Data-Warehouse-Entwicklung, 2004, S. 55.
Vgl. Hackney: Architectures, 1998.
Vgl. Kimball, Ross: Toolkit, 2002, S. 26 u. 104 ff.
Vgl. Wixom, Watson: Data Warehousing Success, 2001, S. 18; Watson et al.: Data warehouse governance, 2004, S. 435 f.; Eicker: Data-Warehouse-Konzept, 2001, S. 68; Gardner: Data Warehouse, 1998, S. 54; Firestone: Architectural Evolution, 1998; Hackney: Architectures, 1998.
Vgl. Burmester, Goeken: Data-Warehouse-Systeme, 2005, S. 1424.
Vgl. Strauch: Informationsbedarfsanalyse, 2002, S. 53 u. S. 83 f.; Holten: Führungsinformationssysteme, 1999, S. 63.
Vgl. Watson et al.: Data warehouse governance, 2004, S. 436; Nach einer empirischen Analyse von Tschandl/Hergolitsch kommen der Management-und der Mitarbeiterorientierung bei der Entwicklung von Data-Warehouse-Systemen eine herausragende Rolle zu. Diesen mittels einer Faktoranalyse ermittelten globalen Faktoren liegen „feingranularere“ Erfolgsfaktoren wie Kommunikation, Einbeziehung der Mitarbeiter, Fachbereichsorientierung und Managementunterstützung zugrunde (Tschandl, Hergolitsch: Erfolgsfaktoren, 2002).
Vgl. Holten: Führungsinformationssysteme, 1999; Strauch: Informationsbedarfsanalyse, 2002.
Mertens: Integration, 1999, S. 414.
Gabriel, Gluchowski: Notationen, 1998, S. 494.
Becker, Holten: Führungsinformationssysteme, 1999, S. 484.
Pohl bezeichnet diese Dimension als „agreement dimension“ (Pohl: Requirements Engineering, 1993). Er betrachtet jedoch im Wesentlichen das Anforderungsmanagement für operative und interaktive Systeme, in denen bspw. Einigkeit hinsichtlich der Abläufe und Prozesse hergestellt werden muss. In Data-Warehouse-Systemen dagegen muss nicht vollständiger Konsens über die Anforderungen (z. B. Auswertungsmöglichkeiten und Navigationsstrukturen) hergestellt werden, d. h. Unterschiede zwischen Anforderungen können durchaus bestehen bleiben, soweit sie gleichzeitig technisch realisierbar sind; bspw. können für eine Kennzahl unterschiedliche Dimensionen und Hierarchien zur Auswertung angeboten werden. In diesem Fall kann die Vereinigungsmenge der Anforderungen implementiert werden — trotz möglicher Inkonsistenzen. Hierbei ist allerdings abzuwägen zwischen der Empfängerorientierung auf der einen Seite und der Vision eines Data-Warehouse-Systems als „Single-point-of-truth“ auf der anderen Seite.
Vgl. Goeken: Anforderungsmanagement, 2005, S. 169; Goeken: Führungsinformationssysteme, 2004, S. 357.
Die Qualität von Informationen bzw. Daten in Data-Warehouse-Systemen wird seit einiger Zeit breit diskutiert: Zu einer umfassenden Diskussion des Datenqualitätsmanagement im Data Warehousing (Helfert: Datenqualität, 2002); zu einer Herleitung von Datenqualitätsdimensionen vgl. Wand, Wang: Data Quality Dimensions, 1996 und Wang, Strong: Data Quality, 1996; zu ihrer Bedeutung für Data Warehouses (Shanks, Darke: Data Quality, 1998); zu einer empirischen Studie der Wahrnehmung der Datenqualität im Data Warehousing (Giannoccaro et al.: Data Quality, 1999).
Vgl. hierzu bspw. die Gegenüberstellung bei Helfert (Helfert: Datenqualität, 2002).
Kahn et al.: Information Quality Benchmarks, 2002.
Vgl. Goeken: Anforderungsmanagement, 2005, S. 175.
McDavid: Business Language Analysis, 1996, S. 145 u. S. 128; Ebenfalls zur Bedeutung des Terminologiemanagements: Back-Hock et al.: Datenmodellierung, 1994, S. 415 f.; Strehlow et al.: Terminological Aspects, 1993; Cysneiros et al.: Conceptual Models, 2001, S. 99 f.; Leite, Franco: Conceptual Model, 1993, S. 243.
McDavid: Business Language Analysis, 1996, S. 146.
Kritisch hierzu ebenfalls: Ortner, Schienmann: Normsprachlicher Entwurf, 1996, S. 116; Leite, Franco: Conceptual Model, 1993, S. 243; Cysneiros et al.: Conceptual Models, 2001.
Vgl. Sankar: Data Elements, 1985, S. 889; McDavid: Business Language Analysis, 1996, S. 134; Hellmuth: Terminologiemanagement, 1997, S. 86.
Tschandl/Hergolitsch identifizieren in einer empirische Studie das fehlende einheitliche Begriffsverständnis als einen entscheidenden Problembereich; vgl. Tschandl, Hergolitsch: Erfolgsfaktoren, 2002, S. 88 f.; ebenso: Garzotto: MASY — Ein Praxisbericht, 1999, S. 18; Lehmann, Jaszewski: Metadaten, 1999; Schelp: Modellierung, 1998, S. 268 f.; Wegner, Auth: Terminologiemanagement, 2002, S. 193 ff.
Zu Ausnahmen: Lehmann, Ortner: Data Warehouse-Repository, 2000; Lehmann: Meta-Datenmanagement, 2001.
Hellmuth: Terminologiemanagement, 1997, S. 43.
Vgl. Strehlow et al: Terminological Aspects, 1993, S. 130; Hellmuth: Terminologiemanagement, 1997, S. 44 u. 86; McDavid: Business Language Analysis, 1996, S. 146; Back-Hock et al.: Datenmodellierung, 1994.
Hier wird der Begriff Glossar verwendet, da er im Vergleich zum Begriff Lexikon umfassender ist. Zur Unterscheidung zwischen terminologischen und lexikalischen Wörterbüchern: Meyer: Knowledge Management, 1991; Wright: Dictionaries, 1999, S. 8 u. 17; McDavid: Business Language Analysis, 1996, S. 134 ff. Bei Meyer findet sich die eingängige Unterscheidung: „dictionaries are about words, encyclopedias are about things.“
Vgl. Gotel, Finkelstein: Traceability, 1994; Wiegers: Software Requirements, 1999, S. 19 u. 302 ff.; Macaulay: Requirements Engineering, 1996, S. 42; Schienmann: Anforderungsmanagement, 2002, S. 10 ff.
Vgl. Schienmann: Anforderungsmanagement, 2002, S. 105 ff.
Vgl. Wiegers: Software Requirements, 1999, S. 305 f.
Vgl. Habra: Separation of Concerns, 2001; Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809; Sousa, Castro: Separation of Concerns, 2004.
Vgl. Sousa, Castro: Separation of Concerns, 2004.
Ossher, Tarr: Separation of Concerns, 2001, S. 43.
Vgl. Ossher, Tarr: Separation of Concerns, 2001, S. 44.
Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809; ebenso: Sousa, Castro: Separation of Concerns, 2004.
Ossher, Tarr: Separation of Concerns, 2001, S. 44.; Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809.
Ossher, Tarr: Separation of Concerns, 2001, S. 44.
Vgl. Czarnecki: Generative Programming, 1998.
Vgl. Rashid et al: Early Aspects, 2002; Rashid et al.: Aspectual Requirements, 2003; „Early“ bezieht sich an dieser Stelle darauf, dass sie in den frühen Phasen der Systementwicklung, d. h. im Anforderungsmanagement, auftreten bzw. identifiziert werden.
Czarnecki: Generative Programming, 1998, S. 113.
Jackson: System Development, 1990.
Vgl. Nagl: Softwaretechnik, 1990, S. 24, 28 u. 232; Lehner et al: Wirtschaftsinformatik, 1995, S. 292.
Lehner et al.: Wirtschaftsinformatik, 1995, S. 292.
Jarke, Mayr: Mediengestütztes Anforderungsmanagement, 2002, S. 454.
Ähnlich dem hier zugrunde gelegten Verständnis definiert Easterbrook eine Perspektive als „... a description of an area of knowledge which has internal consistency and an identifiable focus of attention“ (Easterbrook: Elicitation, 1991, S. 54). Zu einem anderen Verständnis von „Perspektive“ vgl. Leite: Viewpoint Analysis, 1989, S. 112; Leite, Freeman: Viewpoint Resolution, 1991, S. 1255; dort stellen Perspektiven Modellierungsaspekte dar, bspw. Daten, Akteure und Prozesse.
Vgl. Leite: Viewpoint Analysis, 1989, S. 111; Leite: Viewpoints on Viewpoints, 1996, S. 285; Darke, Shanks: Requirements Definition, 1996, S. 88 f. (dort auch zu wissenschaftstheoretischen Grundlagen viewpointorientierter Methoden); Nuseibeh et al.: Method Engineering, 1996; Nuseibeh: Crosscutting Requirements, 2004, S. 3.
Nuseibeh et al.: Method Engineering, 1996; Finkelstein et al.: Inconsistency Handling, 1994, S. 569; Nuseibeh et al.: Multiple Views, 1994, S. 1.
Vgl. Greer, Ruhe: Release Planning, 2004, S. 244; Pohl: Requirements Engineering, 1993; Pohl: Requirements Engineering, 1997; Nissen: Separierung, 1997, S. 1; Easterbrook: Elidtation, 1991, S. 10.
Vgl. Nissen: Separierung, 1997, S. 1 f.; für eine Ausnahme bei der Entwicklung von Datenbanken vgl. Batini et al.: Database, 1992, S. 85–137; dort wird ein Verfahren vorgestellt, um ein ERM aus den „Views“ verschiedener Stakeholder herzuleiten.
Vgl hierzu die Fallstudie von Breitmann et al., in der das Scheitern eines neuen Notfall-und Rettungssystems für die Stadt London nach der Viewpoint-Methode analysiert wird (Breitmann et al.: Real-Life Case Study, 1999).
Nuseibeh et al.: ViewPoints, 2003, S. 676.
Für Übersichten und Vergleiche siehe bspw. Darke, Shanks: Requirements Definition, 1996; Stanger: Framework, 2000; Kotonya, Sommerville: Requirements Engineering, 1998; Kotonya, Sommerville: Viewpoints, 1995.
Darke Shanks: Requirements Definition, 1996.
Vgl. Finkelstein, Sommerville: Viewpoints FAQ, 1996, S. 2; Kotonya, Sommerville: Requirements Engineering, 1998, S. 172; Sommerville, Sawyer: Requirements Engineering, 1997, S. 364.
Vgl. Nuseibeh et al.: ViewPoints, 2003, S. 677; Stanger: Framework, 2000.
Leite: Viewpoints on Viewpoints, 1996; Breitmann et al.: Real-Life Case Study, 1999 S. 18 ff.; ähnlich: Sommerville, Sawyer: Viewpoints, 1997, S. 102.
Vgl. Darke, Shanks: Viewpoint Modelling, 1997, S. 214.
Vgl. Kotonya beschreibt dies in Analogie zu Client-Server-Systemen: Kotonya: Requirements Specification, 1999, S. 117.
Vgl. Nuseibeh et al.: ViewPoints, 2003, S. 676 f.
Nuseibeh et al.: Multiple Views, 1994, S. 1.
Vgl. Sommerville, Sawyer: Viewpoints 1997, S. 102; Darke, Shanks: Viewpoint Modelling, 1997, S. 216.
Balzer: Tolerating Inconsistency, 1991; Easterbrook: Elicitation, 1991, S. 18 ff.; Darke, Shanks: Requirements Definition, 1996, S. 92.
Vgl. Nuseibeh et al.: Multiple Views, 1994, S. 7: „Tolerating inconsistency [..] is fundamental to the ViewPoints approach, with consistency checking and conflict resolution not (necessarily) performed as a matter of course. Consistency checking may only be appropriate at specific stages of the development life-cycle and detection of inconsistency may not require immediate resolution, but left for later action, or even not resolved at all.“
Vgl. Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 810.
Vgl. Sommerville, Sawyer: Requirements Engineering, 1997, S. 386; Kotonya: Requirements Specification, 1999, S. 130; Pohl: Requirements Engineering, 1997; Melchisedech: Spezifikationen, 2000, S. 24 ff.; anders: Finkelstein et al.: Inconsistency Handling, 1994, S. 570.
Leite, Freeman: Viewpoint Resolution, 1991; Leite: Viewpoint Analysis, 1989, S. 112.
Rights and permissions
Copyright information
© 2006 Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden
About this chapter
Cite this chapter
(2006). Merkmale von VODWE. In: Entwicklung von Data-Warehouse-Systemen. DUV. https://doi.org/10.1007/978-3-8350-9178-8_8
Download citation
DOI: https://doi.org/10.1007/978-3-8350-9178-8_8
Publisher Name: DUV
Print ISBN: 978-3-8350-0325-5
Online ISBN: 978-3-8350-9178-8
eBook Packages: Business and Economics (German Language)