Skip to main content
SpringerLink
Log in

Gestaltung und Betrieb von BI-Lösungen

  • Chapter
Book cover Management Support Systeme und Business Intelligence

  • 18k Accesses

Auszug

Die voran gegangenen Ausführungen haben gezeigt, dass Business Intelligence-Systeme höchst unterschiedliche Erscheinungsformen annehmen und zahlreiche betriebswirtschaftliche Aufgabenstellungen unterstützen können. Dennoch lassen sich Kriterien erarbeiten, welche für die Gestaltung und den Betrieb entsprechender Lösungen kennzeichnend sind. Ausgehend von den verschiedenen Reifegradstufen von Business Intelligence-Systemen (vgl. Abschnitt 9.1), die zur Einordnung und Bewertung konkreter Umsetzungen heran gezogen werden können, beleuchten die folgenden Abschnitte geeignete Vorgehensmodelle für den Aufbau und die Nutzung der Systeme (vgl. Abschnitt 9.2). Anschließend erfolgt die detaillierte Erörterung der einzelnen Phasen und Aktivitätsblöcke, die im Rahmen der Gestaltung und des Betriebs Relevanz aufweisen (vgl. Abschnitt 9.3).

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

Access this chapter

Log in via an institution
Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 84.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

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. Zur IV-Strategie vgl. Gabriel/Beier (2003) sowie Krcmar (2005).

    Google Scholar 

  2. Vgl. Steria-Mummert (2006); Schulze/Dittmar (2006).

    Google Scholar 

  3. Vgl. Mellis/Stelzer (1999).

    Google Scholar 

  4. Vgl. Paulk/Weber/Curtis (1995).

    Google Scholar 

  5. Vgl. Bollinger/McGowan (1991).

    Google Scholar 

  6. Vgl. Suhr/Suhr (1993), S. 96.

    Google Scholar 

  7. Im Rahmen der vorliegenden Ausführungen wird dem Begriffsverständnis von Pomberger und Blaschek gefolgt, die Software Engineering definieren als “die praktische Anwendung wissenschaftlicher Erkenntnisse für die wirtschaftliche Herstellung und den wirtschaftlichen Einsatz qualitativ hochwertiger Software”. Pomberger/Blaschek (1993), S. 3. Alternative Abgrenzungen finden sich z. B. bei Boehm (1986), S. 13; Balzert (1989), S. 3.

    Google Scholar 

  8. Vgl. Hesse/Merbeth/Frölich (1992), S. 30; Balzert (1989), S. 17.

    Google Scholar 

  9. Vgl. Pomberger/Blaschek (1993), S. 24. Teilweise werden die Begriffe Life-Cycle-Modell und Wasserfallmodell auch synonym verwendet. Vgl. Goldammer (1994), S. 253.

    Google Scholar 

  10. Ein Überblick über unterschiedliche Phasenkonzepte findet sich bei Balzert (1989), S. 469.

    Google Scholar 

  11. Vgl. Suhr/Suhr (1993), S. 97.

    Google Scholar 

  12. Vgl. Pomberger/Blaschek (1993), S. 22.

    Google Scholar 

  13. Vgl. Balzert (2000).

    Google Scholar 

  14. Eine Übersicht über diese Vorgehensmodelle zur Gestaltung klassischer MSS-Systeme findet sich bei Walterscheid (1996), S. 105–113.

    Google Scholar 

  15. Entsprechende Vorgehensmodelle präsentieren u. a. Holthuis (1998), S. 206–228; Kemper u. a. (2004), S. 147–173; Poe/Reeves (1997), S. 79–98.

    Google Scholar 

  16. Vgl. Hansen (1997), S. 319.

    Google Scholar 

  17. Vgl. Heck-Weinhart/Mutterer/Herrmann/Rupprecht (2003), S. 201.

    Google Scholar 

  18. Vgl. z. B. Krcmar (2005), S. 238ff.; Gabriel/Beier (2003).

    Google Scholar 

  19. Vgl. Gehrke/Wendlandt/Sommer (2006).

    Google Scholar 

  20. Vgl. Totok (2006), S. 62. Allerdings finden sich ebenfalls Organisationsformen, in denen neben den aufgeführten Aktivitäten auch die Entwicklung, der Betrieb und der Support zu einer BI-Organisationseinheit gerechnet werden. Vgl. Kemper/Finger (2006).

    Google Scholar 

  21. Vgl. Totok (2006), S. 56.

    Google Scholar 

  22. Ein allgemeiner Kriterienkatalog zur Beurteilung von Data Warehouse-Lösungen findet sich beispielsweise bei Böttiger/Chamoni/Gluchowski/Müller (2001), S. 39–56.

    Google Scholar 

  23. Vgl. Küpper (2005), S. 156, Strauch/Winter (2002) S. 363. In diesem Sinne wird Informationsbedarf hier als Menge von objektiv relevanten Informationen verstanden. Hiervon abzugrenzen ist das (subjektive) Informationsbedürfnis sowie die tatsächlich nachgefragte Informationsmenge. Vgl. zur Abgrenzung Koreimann (1999); Groffmann (1992), S. 15f.

    Google Scholar 

  24. Vgl. Küpper (2005), S. 160f. Gemünden führt als weiteren Bestimmungsfaktor die angestrebte Lösungsqualität an. Vgl. Gemünden (1993), Sp. 1728.

    Google Scholar 

  25. Dazu trägt der Umstand bei, dass die späteren Nutzer ihren konkreten Bedarf oftmals nicht oder nur unzureichend artikulieren können. Vgl. Strauch/Winter (2002b), S. 362f.

    Google Scholar 

  26. Vgl. Reichmann (2006), S. 666.

    Google Scholar 

  27. Vgl. Küpper (2005), S. 163; Horvath (2006), S. 335–339.

    Google Scholar 

  28. Vgl. Berthel (1975), S. 13.

    Google Scholar 

  29. Vgl. Horvath (2006), S. 336.

    Google Scholar 

  30. Vgl. Küpper (2005), S. 167.

    Google Scholar 

  31. Vgl. Schirp (2001), S. 84.

    Google Scholar 

  32. Vgl. Chen (1976), S. 9–36; Schelp (2000), S.161; Totok (2000b), S. 124.

    Google Scholar 

  33. Ein (semantisch fragwürdiger) Vorschlag besteht darin, die Objekte einer elementbestimmten Dimension (wie beispielsweise „Plan“, „Ist“ und „Abweichung“) als Attribute einer Entitätsmenge („Szenario“) zu interpretieren. Vgl. Totok (2000b), S. 124f.

    Google Scholar 

  34. Vgl. Sapia/Blaschka/Höfling/Dinter (1998).

    Google Scholar 

  35. In Anlehnung an Sapia/Blaschka/Höfling/Dinter (1998), S. 9; Totok (2000b), S. 126f.

    Google Scholar 

  36. Vgl. Sapia (1999), S. 2.2–2.4.

    Google Scholar 

  37. Vgl. Sapia (1999), S. 2.7–2.8.

    Google Scholar 

  38. Vgl. Golfarelli/Maio/Rizzi (1998), S. 1–10.

    Google Scholar 

  39. Vgl. Golfarelli/Maio/Rizzi (1998), S. 2.

    Google Scholar 

  40. Vgl. Golfarelli/Maio/Rizzi (1998), S. 3f.

    Google Scholar 

  41. Vgl. Sapia (1999), S. 2.2–2.4.

    Google Scholar 

  42. Vgl. Bulos (1996), S. 33–37.

    Google Scholar 

  43. Vgl. Bulos (1996), S. 34–35.

    Google Scholar 

  44. Vgl. Totok (1998), S. 15; Totok (2000a), S. 199–203.

    Google Scholar 

  45. Vgl. Behme/Holthuis/Mucksch (2000), S. 216; Holthuis (1998), S. 186; Müller (2000), S. 100; Oehler (2006), S. 107.

    Google Scholar 

  46. Vgl. Bauer/Günzel (2004), S. 202ff.

    Google Scholar 

  47. Der Begriff resultiert aus der sternenförmigen Anordnung der beteiligten Tabellen. Vgl. Bauer/Günzel (2004), S. 2005; Holthuis (1998), S. 193.

    Google Scholar 

  48. Vgl. Gluchowski (1998a), S. 32–39.

    Google Scholar 

  49. Vgl. Hahne (2006), S. 191f.; McClanahan (1997), S. 67; Nußdorfer (1998), S. 23f. Bereits die Tabelle „Absatz“ in Abbildung 9/16 kann nach diesem Verständnis als Fakten-Tabelle bezeichnet werden, allerdings erfolgt in realen Modellen eher die Nutzung künstlicher, möglichst speicherschonender Primärschlüssel.

    Google Scholar 

  50. Kimball bezeichnet eine derartige Anordnung von Tabellen auch als „dimensional model“. Vgl. Kimball (1996), S. 10.

    Google Scholar 

  51. Eine derartige Vorgehensweise akzeptiert die Abkehr von der Normalformenlehre (vgl. Gabriel/Röhrs (1995), S. 123–131), wie sie bei der Gestaltung operativer Datenbanksysteme genutzt wird, zumal sich durch denormalisierte Dimensionstabellen Geschwindigkeitsvorteile beim Zugriff eröffnen.

    Google Scholar 

  52. Vgl. Bauer/Günzel (2004), S. 210. Hahne bezeichnet derartige selbstreferenzierende Tabellen als Parent-Child-Tabellen. Vgl. Hahne (2002), S. 114.

    Google Scholar 

  53. Vgl. Bauer/Günzel (2004), S. 203–205.

    Google Scholar 

  54. Vgl. McClanahan (1997), S. 67. Kurz verweist darauf, dass dann jedoch bei Abfragen u. U. viele verbundene Tabellen über Join-Operationen zu verknüpfen sind, was erhebliche Geschwindigkeitseinbußen mit sich bringt. Vgl. Kurz (1999), S. 164.

    Google Scholar 

  55. Nußdorfer unterscheidet sogar sieben unterschiedliche Typen von Faktentabellen, die für unterschiedliche Auswertungsziele angelegt werden können. Vgl. Nußdorfer (1998), S. 26.

    Google Scholar 

  56. Vgl. Bauer/Günzel (2004), S. 209; Hahne (2002), S. 140–143; Raden (1996); Schelp (2000), S. 170f.

    Google Scholar 

  57. Bislang wurde implizit unterstellt, dass sich in einer zentralen Faktentabelle alle quantitativen Größen finden lassen. Falls dies nicht nur die Detaildaten auf höchster Disaggregationsstufe, sondern auch verdichtete Größen sind, dann lässt sich ein derartiges Schema als konsolidiert bezeichnen. Vgl. Kurz (1999), S. 171f.

    Google Scholar 

  58. Vgl. Bauer/Günzel (2004), S. 209f.; Nußdorfer (1998), S. 23f.; Schelp (2000), S. 173. Alternativ werden derartige Strukturen auch Multi-Faktentabellen-Schema genannt. Vgl. Holthuis (1998), S. 194.

    Google Scholar 

  59. Oehler bezeichnet diese Ablageform als RAM-basiert. Vgl. Oehler (2006), S. 123.

    Google Scholar 

  60. Vgl. Kurz (1999), S. 330.

    Google Scholar 

  61. Im günstigen Fall läßt sich dadurch das Datenvolumen um den Faktor 100 gegenüber einer ASCII-Datei mit gleichem Informationsgehalt reduzieren. Vgl. Clausen (1999), S. 311; Thomsen (1997), S. 208.

    Google Scholar 

  62. Bauer und Günzel unterscheiden zwischen den Extrempositionen „real time processing“ und „batch processing“. Vgl. Bauer/Günzel (2004), S. 231.

    Google Scholar 

  63. Vgl. Chamoni/Gluchowski (2000), S. 359.

    Google Scholar 

  64. Vgl. Gluchowski/Chamoni (2006), S. 160.

    Google Scholar 

  65. Dieser Effekt verstärkt sich, wenn anstatt zwei mehr Dimensionen betrachtet werden und/oder die Dimensionen eine größere Anzahl an Hierarchieebenen aufweisen. Vgl. Behme/Holthuis/Mucksch (2000), S. 220.

    Google Scholar 

  66. Vgl. Chamoni/Gluchowski (2000), S. 358.

    Google Scholar 

  67. Eine Veranschaulichung des Problems der dünnen Besetzung findet sich bei Behme, Holthuis und Mucksch. Vgl. Behme/Holthuis/Mucksch (2000), S. 217–220; siehe auch Clausen (1998), S. 70–72.

    Google Scholar 

  68. Auf die Notwendigkeit zur effizienten Behandlung dünnbesetzter Matrizen weisen vor allem Codd, Codd und Salley hin. Vgl. Codd/Codd/Salley (1993).

    Google Scholar 

  69. Vgl. Buytendijk (1995), S. 9.

    Google Scholar 

  70. Einen Überblick über die gebräuchlichen Ablageverfahren geben Bauer und Günzel. Vgl. Bauer/Günzel (2004), S. 235–239. Clausen stellt weitere Techniken zur Ablage multidimensionaler Daten mitsamt den zugehörigen Vor-und Nachteilen vor. Vgl. Clausen (1999), S. 309f.

    Google Scholar 

  71. Vgl. Bauer/Günzel (2004), S. 236.

    Google Scholar 

  72. Vgl. Clausen (1999), S. 308f.

    Google Scholar 

  73. Vgl. Kimball/Reeves/Ross/Thornthwaite (1998), S. 587; Roti (1996), S. 3.

    Google Scholar 

  74. Vgl. Biethahn/Mucksch/Ruf (2004).

    Google Scholar 

  75. Vgl. Yazdani/Wong (1997), S. 122. Gegenüber dem einfachen B-Baum-Index zeichnet sich der B*-Baum-Index dadurch aus, dass sich Angaben über die jeweilige Position des Datensatzes nur auf der Blatt-Ebene des aufgespannten Baumes finden. Vgl. Bauer/ Günzel (2004), S. 261.

    Google Scholar 

  76. Vgl. Grandy (2002), S. 10.

    Google Scholar 

  77. Vgl. Behme/Holthuis/Mucksch (2000), S. 232; Roti (1996), S. 2. Die Kardinalität ist eine Maßgröße, welche die Anzahl unterschiedlicher Wertausprägungen einer Tabellenspalte mit der Anzahl aller Tabellenzeilen in Beziehung setzt. Somit sind B*-Baum-Indizes bei wenigen Wertwiederholungen in einer Tabellenspalte, wie etwa im Falle der Kundennamen in der Kundentabelle, oder bei Tabellenspalten, in denen die Ausprägungen nur einmalig auftreten, wie bei eindeutigen Primärschlüsseln (z. B. Kunden#), ausgezeichnet als Zugriffstechnik geeignet.

    Google Scholar 

  78. Vgl. Kimball/Reeves/Ross/Thornthwaite (1998), S. 588.

    Google Scholar 

  79. Vgl. Berson/Smith (1997), S. 180; Gluchowski (1998b), S. 17; Kimball/Reeves/Ross/ Thornthwaite (1998), S. 588; Kurz (1999), S. 257; Oracle (1997), S. 142.

    Google Scholar 

  80. Vgl. Grandy (2002), S. 18; Holthuis (1998), S. 202; Oracle (1997), S. 140.

    Google Scholar 

  81. Vgl. Behme/Holthuis/Mucksch (2000), S. 216; Bontempo/Saracco (1996).

    Google Scholar 

  82. Bei 1.000.000 Kundensätzen benötigt der Index für die Einkommens-Spalte lediglich 1.000.000*3*1 Bit zuzüglich des fast zu vernachlässigenden Overhead-Platzes (einmalige Ablage der Wertausprägungen „hoch“, „mittel“ und „niedrig“), also ca. 375 KB. Ein entsprechender B*-Baum-Index würde dagegen allein für die Speicherung der RIDs gemäß dem RID-Listen-Verfahren (bei einer RID-Größe von 4 Byte) ca. 4 MB benötigen. Mit jeder neuen Ausprägung der Einkommenspalte (z. B. „ohne eigenes Einkommen“) vergrößert sich allerdings der Bitmap-Index um 125 KB. Somit lässt sich ein Bitmap-Index vor allem bei wenigen Wertausprägungen (geringe Kardinalität) besonders klein halten. Vgl. Reuter (1996), S. 28–33.

    Google Scholar 

  83. Vgl. Bauer/Günzel (2004), S. 272; O’Neil/Quass (1997), S. 42.

    Google Scholar 

  84. Vgl. Oracle (1997), S. 141; Yazdani/Wong (1997), S. 122.

    Google Scholar 

  85. Vgl. Grandy (2002), S. 26; Kurz (1999), S. 259f.

    Google Scholar 

  86. Vgl. Behme/Holthuis/Mucksch (2000), S. 232; O’Neil/Quass (1997), S. 38–49.

    Google Scholar 

  87. Vgl. Harms (1996). Einige aussagekräftige Performanceergebnisse stellt Nußdorfer vor. Vgl. Nußdorfer (1996); Nußdorfer (1999), S. 222. Durch den Einsatz paralleler Technologie gelingt es, auch Datenbestände in Terabyte-Größe in vertretbaren Zeiten zu analysieren.

    Google Scholar 

  88. Vgl. Behme/Holthuis/Mucksch (2000), S. 236–238; Berson/Smith (1997), S. 47–66; Gilliland (1996), S. 63–65; Holthuis (1998), S. 203; Nußdorfer (1999), S. 217; Wenig/Sannik (1997), S. 77.

    Google Scholar 

  89. Vgl. Bauer/Günzel (2004); S. 423.

    Google Scholar 

  90. Vgl. Nußdorfer (1999), S. 218.

    Google Scholar 

  91. Vgl. Ballard u. a. (2005), S. 132.

    Google Scholar 

  92. Vgl. Küspert/Nowitzky (1999), S. 146–147; Saylor/Bedell/Rodenberger (1997), S. 42; Scalzo (1996), S. 67.

    Google Scholar 

  93. Vgl. Ballard u. a. (2005), S. 128ff.

    Google Scholar 

  94. Neben dieser als Range-Partitionierung bezeichneten Variante finden sich auch Techniken, die mit Hash-Verfahren arbeiten. Vgl. Bauer/Günzel (2004), S. 279; Kurz (1999), S. 255.

    Google Scholar 

  95. Vgl. Bauer/Günzel (2004), S. 277.

    Google Scholar 

  96. Vgl. Bauer/Günzel (2004), S. 458.

    Google Scholar 

  97. Als Rahmenordnung für die Definition und den Betrieb von IT-Prozessen diente ITIL zwar ursprünglich primär der Beschreibung von Prozessen für die Serviceerbringung bei transaktionalen, operativen Systemen, lässt sich allerdings nutzbringend auf den Business Intelligence-Sektor übertragen. Philippi präsentiert hierzu eine BI-spezifische ITILSpezifikation und bezeichnet diese als biTIL. Vgl. Philippi (2005).

    Google Scholar 

  98. Vgl. Kemper/Finger (2006).

    Google Scholar 

  99. Vgl. Philippi (2005).

    Google Scholar 

  100. Vgl. Bauer/Günzel (2004), S. 444.

    Google Scholar 

  101. Mucksch und Behme erweitern die erforderliche Verfügbarkeit gar auf 24 (Stunden) * 7 (Tage) * 52 (Wochen). Vgl. Mucksch/Behme (2000), S. 48.

    Google Scholar 

  102. Vgl. Bauer/Günzel (2004), S. 387.

    Google Scholar 

  103. Vgl. Bauer/Günzel (2004), S. 389.

    Google Scholar 

  104. In Anlehnung an Conrad (2000), S. 293.

    Google Scholar 

  105. Vgl. Bauer/Günzel (2004), S. 395.

    Google Scholar 

  106. Eine Übersicht über unterschiedliche Datenqualitätsmerkmale findet sich bei Winter u. a., die Interpretierbarkeit, Nützlichkeit, Glaubwürdigkeit, zeitlicher Bezug und Verfügbarkeit anführen. Vgl. Winter/Herrmann/Helfert (2003), S. 226f.

    Google Scholar 

  107. Behme beziffert den Schaden einer unzureichenden Datenqualität („Total Cost of poor Data Quality“) in Unternehmungen auf 8-12 % des Umsatzes. Vgl. Behme (2002), S. 49.

    Google Scholar 

  108. Vgl. Winter/Herrmann/Helfert(2003), S. 222.

    Google Scholar 

  109. Vgl. Behme/Nietzschmann (2006), S. 45.

    Google Scholar 

  110. Vgl. Winter/Herrmann/Helfert(2003), S. 229, Goltsche (2006), S. 13f.

    Google Scholar 

  111. Vgl. Schieder (2006).

    Google Scholar 

  112. Serwas und Wandt definieren hierzu sogar einen Data Quality Life Cycle mit den Phasen „Inspect, Transform, Name, Address, Identify, Merge, Enrich und Report“. Vgl. Serwas/Wandt (2007), S. 12.

    Google Scholar 

  113. Vgl. Schorb (2006), S. 19.

    Google Scholar 

  114. Behme und Nietzschmann diskutieren unterschiedliche strategische Ansätze für eine Verbesserung und Sicherung der Datenqualität und beleuchteten dabei Aspekte der Integration in die strategische Unternehmungsführung. Vgl. Behme/Nietzschmann (2006), S. 45–50.

    Google Scholar 

Download references

Rights and permissions

Reprints and permissions

Copyright information

© 2008 Springer-Verlag Berlin Heidelberg

About this chapter

Cite this chapter

(2008). Gestaltung und Betrieb von BI-Lösungen. In: Management Support Systeme und Business Intelligence. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-68269-1_9

Download citation

  • DOI: https://doi.org/10.1007/978-3-540-68269-1_9

  • Publisher Name: Springer, Berlin, Heidelberg

  • Print ISBN: 978-3-540-23543-9

  • Online ISBN: 978-3-540-68269-1

  • eBook Packages: Business and Economics (German Language)

Publish with us

Policies and ethics

Search

Navigation