Skip to main content
  • 6101 Accesses

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.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 59.99
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. Vgl. Lehner et al.: Wirtschaftsinformatik, 1995, S. 292 ff.

    Google Scholar 

  2. Vgl. auch Goeken, Burmester: Data-Warehouse-Entwicklung, 2004, S. 55 ff.; Goeken, Burmester: Business Intelligence, 2004, S. 142.

    Google Scholar 

  3. Vgl. Goeken, Burmester: Data-Warehouse-Entwicklung, 2004, S. 55.

    Google Scholar 

  4. Vgl. Hackney: Architectures, 1998.

    Google Scholar 

  5. Vgl. Kimball, Ross: Toolkit, 2002, S. 26 u. 104 ff.

    Google Scholar 

  6. 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.

    Google Scholar 

  7. Vgl. Burmester, Goeken: Data-Warehouse-Systeme, 2005, S. 1424.

    Google Scholar 

  8. Vgl. Strauch: Informationsbedarfsanalyse, 2002, S. 53 u. S. 83 f.; Holten: Führungsinformationssysteme, 1999, S. 63.

    Google Scholar 

  9. 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).

    Google Scholar 

  10. Vgl. Holten: Führungsinformationssysteme, 1999; Strauch: Informationsbedarfsanalyse, 2002.

    Google Scholar 

  11. Mertens: Integration, 1999, S. 414.

    Google Scholar 

  12. Gabriel, Gluchowski: Notationen, 1998, S. 494.

    Google Scholar 

  13. Becker, Holten: Führungsinformationssysteme, 1999, S. 484.

    Google Scholar 

  14. 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.

    Google Scholar 

  15. Vgl. Goeken: Anforderungsmanagement, 2005, S. 169; Goeken: Führungsinformationssysteme, 2004, S. 357.

    Google Scholar 

  16. 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).

    Google Scholar 

  17. Vgl. hierzu bspw. die Gegenüberstellung bei Helfert (Helfert: Datenqualität, 2002).

    Google Scholar 

  18. Kahn et al.: Information Quality Benchmarks, 2002.

    Google Scholar 

  19. Vgl. Goeken: Anforderungsmanagement, 2005, S. 175.

    Google Scholar 

  20. 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.

    Google Scholar 

  21. McDavid: Business Language Analysis, 1996, S. 146.

    Google Scholar 

  22. Kritisch hierzu ebenfalls: Ortner, Schienmann: Normsprachlicher Entwurf, 1996, S. 116; Leite, Franco: Conceptual Model, 1993, S. 243; Cysneiros et al.: Conceptual Models, 2001.

    Google Scholar 

  23. Vgl. Sankar: Data Elements, 1985, S. 889; McDavid: Business Language Analysis, 1996, S. 134; Hellmuth: Terminologiemanagement, 1997, S. 86.

    Google Scholar 

  24. 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.

    Google Scholar 

  25. Zu Ausnahmen: Lehmann, Ortner: Data Warehouse-Repository, 2000; Lehmann: Meta-Datenmanagement, 2001.

    Google Scholar 

  26. Hellmuth: Terminologiemanagement, 1997, S. 43.

    Google Scholar 

  27. 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.

    Google Scholar 

  28. 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.“

    Google Scholar 

  29. 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.

    Google Scholar 

  30. Vgl. Schienmann: Anforderungsmanagement, 2002, S. 105 ff.

    Google Scholar 

  31. Vgl. Wiegers: Software Requirements, 1999, S. 305 f.

    Google Scholar 

  32. Vgl. Habra: Separation of Concerns, 2001; Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809; Sousa, Castro: Separation of Concerns, 2004.

    Google Scholar 

  33. Vgl. Sousa, Castro: Separation of Concerns, 2004.

    Google Scholar 

  34. Ossher, Tarr: Separation of Concerns, 2001, S. 43.

    Google Scholar 

  35. Vgl. Ossher, Tarr: Separation of Concerns, 2001, S. 44.

    Google Scholar 

  36. Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809; ebenso: Sousa, Castro: Separation of Concerns, 2004.

    Google Scholar 

  37. Ossher, Tarr: Separation of Concerns, 2001, S. 44.; Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 809.

    Google Scholar 

  38. Ossher, Tarr: Separation of Concerns, 2001, S. 44.

    Google Scholar 

  39. Vgl. Czarnecki: Generative Programming, 1998.

    Google Scholar 

  40. 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.

    Google Scholar 

  41. Czarnecki: Generative Programming, 1998, S. 113.

    Google Scholar 

  42. Jackson: System Development, 1990.

    Google Scholar 

  43. Vgl. Nagl: Softwaretechnik, 1990, S. 24, 28 u. 232; Lehner et al: Wirtschaftsinformatik, 1995, S. 292.

    Google Scholar 

  44. Lehner et al.: Wirtschaftsinformatik, 1995, S. 292.

    Google Scholar 

  45. Jarke, Mayr: Mediengestütztes Anforderungsmanagement, 2002, S. 454.

    Google Scholar 

  46. Ä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.

    Google Scholar 

  47. 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.

    Google Scholar 

  48. Nuseibeh et al.: Method Engineering, 1996; Finkelstein et al.: Inconsistency Handling, 1994, S. 569; Nuseibeh et al.: Multiple Views, 1994, S. 1.

    Google Scholar 

  49. 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.

    Google Scholar 

  50. 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.

    Google Scholar 

  51. 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).

    Google Scholar 

  52. Nuseibeh et al.: ViewPoints, 2003, S. 676.

    Google Scholar 

  53. Für Übersichten und Vergleiche siehe bspw. Darke, Shanks: Requirements Definition, 1996; Stanger: Framework, 2000; Kotonya, Sommerville: Requirements Engineering, 1998; Kotonya, Sommerville: Viewpoints, 1995.

    Google Scholar 

  54. Darke Shanks: Requirements Definition, 1996.

    Google Scholar 

  55. Vgl. Finkelstein, Sommerville: Viewpoints FAQ, 1996, S. 2; Kotonya, Sommerville: Requirements Engineering, 1998, S. 172; Sommerville, Sawyer: Requirements Engineering, 1997, S. 364.

    Google Scholar 

  56. Vgl. Nuseibeh et al.: ViewPoints, 2003, S. 677; Stanger: Framework, 2000.

    Google Scholar 

  57. Leite: Viewpoints on Viewpoints, 1996; Breitmann et al.: Real-Life Case Study, 1999 S. 18 ff.; ähnlich: Sommerville, Sawyer: Viewpoints, 1997, S. 102.

    Google Scholar 

  58. Vgl. Darke, Shanks: Viewpoint Modelling, 1997, S. 214.

    Google Scholar 

  59. Vgl. Kotonya beschreibt dies in Analogie zu Client-Server-Systemen: Kotonya: Requirements Specification, 1999, S. 117.

    Google Scholar 

  60. Vgl. Nuseibeh et al.: ViewPoints, 2003, S. 676 f.

    Google Scholar 

  61. Nuseibeh et al.: Multiple Views, 1994, S. 1.

    Google Scholar 

  62. Vgl. Sommerville, Sawyer: Viewpoints 1997, S. 102; Darke, Shanks: Viewpoint Modelling, 1997, S. 216.

    Google Scholar 

  63. Balzer: Tolerating Inconsistency, 1991; Easterbrook: Elicitation, 1991, S. 18 ff.; Darke, Shanks: Requirements Definition, 1996, S. 92.

    Google Scholar 

  64. 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.“

    Google Scholar 

  65. Vgl. Tarr et al.: Multidimensional Separation of Concerns, 2000, S. 810.

    Google Scholar 

  66. 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.

    Google Scholar 

  67. Leite, Freeman: Viewpoint Resolution, 1991; Leite: Viewpoint Analysis, 1989, S. 112.

    Google Scholar 

Download references

Rights and permissions

Reprints 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

Publish with us

Policies and ethics