Skip to main content

Flexible Datenbankarchitekturen als Integrationsplattform wettbewerbsorientierter Systeme

  • Chapter
Ökonomische Datenhaltung in der Unternehmung

Part of the book series: DUV Wirtschaftsinformatik ((DUVWI))

  • 18 Accesses

Zusammenfassung

Die Bereitsteilbarkeit guter wie auch einfacher und überzeugender Lösungen für komplexe kundenindividuelle Problemstellungen intensiviert die Kundenbeziehungen. Die Erarbeitung von Wettbewerbsvorteilen erfordert hierbei eine intelligente Integration aller Kompetenzpotentiale einer Unternehmung. Da es weder im personellen, noch im informationstechnischen Bereich, den “universellen Problemlöser” gibt, liegt Kompetenz logisch und i.d.R. auch geographisch nach Fachgebieten segmentiert in der Unternehmung vor. Fachgebiete werden im folgenden auch als Fachdomänen bezeichnet.

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 44.99
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 59.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. Vgl. Abschnitt 1.1.

    Google Scholar 

  2. Vgl. die Abschnitte 2.5, 2.7 und 2.8.

    Google Scholar 

  3. Vgl. Abschnitt 1.1.

    Google Scholar 

  4. Vgl. Abschnitt 1.1.

    Google Scholar 

  5. Vgl. in anderer Form auch [BuWi93, S. 42ff].

    Google Scholar 

  6. Vgl. Abschnitt 1.2.

    Google Scholar 

  7. Vgl. [Savo85],[Savo89],[Wate861,[Pupp88].

    Google Scholar 

  8. Diese führt logische Deduktionen über dem repräsentierten Wissen aus.

    Google Scholar 

  9. Diese erläutert einem menschlichen Benutzer das Zustandekommen einer Expertise.

    Google Scholar 

  10. Vgl. [Reim91],[RiDu88].

    Google Scholar 

  11. Die sukzessive Abarbeitung von Regeln besitzt natürlich auch einen prozeduralen Charakter. Einzelne Regeln sind jedoch als deklarativ anzusehen.

    Google Scholar 

  12. Vgl. die Abschnitte 1.3 und 1.4.

    Google Scholar 

  13. Vgl. Abschnitt 1.5.2.

    Google Scholar 

  14. Auf eine detaillierte Darstellung logischer Probleme im Zusammenhang mit repräsentiertem Wissen wird an dieser Stelle verzichtet.

    Google Scholar 

  15. [BuSa93] wird explizites Wissen über vorteilhafte Kombinationen von Bankleistungen der finanzwirtschaftlichen Fachdomänen Couponanleihe, Lebensversicherung und Zerobond erarbeitet.

    Google Scholar 

  16. Vgl. die Abschnitte 1.1 und 2.4.

    Google Scholar 

  17. For most of this survey, we will rely on a simple and intuitive notion of an agent as a computational process with a single locus of control and/or “intention”. This view, however, is actually very problematic: agents may be implemented using concurrent subprocesses..., they may have multiple and conflicting goals, and the nature and reality of the concepts “goal” and “intention” are unclear... . The process of defining the boundaries of what comprises an agent interacting with a world is also fraught with difficulties, from the standpoint of epistemology, of social psychology, and, we think, of computer science [BoGa88, S. 3].

    Google Scholar 

  18. Vgl. [SmDa81].

    Google Scholar 

  19. Vgl. [LeCo81].

    Google Scholar 

  20. Vgl. [BoGa88].

    Google Scholar 

  21. Vgl. [Nii86],[JaDo89],[EnMo88].

    Google Scholar 

  22. Vgl. [Newe62].

    Google Scholar 

  23. Vgl. [DuLe89].

    Google Scholar 

  24. Diese sind • Unterstützung bei der Lösung komplexer und schlecht strukturierter Probleme. • Unterstützung bei einer verteilten Problemlösung. • Unterstützung einer guten Erweiterbarkeit und Wartbarkeit. • Unterstützung verschiedener Wissensrepräsentationsformen. • Unterstützung der expliziten Kollaboration (unter Ausnutzung von explizitem fachdomänenübergreifendem Wissen). • Unterstützung der impliziten Kollaboration (unter Ausnutzung von implizitem fachdomänenübergreifendem Wissen). • Unterstützung von Konkurrenz (durch gleichzeitige Verfolgung alternativer Lösungspfade). • Unterstützung einer flexiblen und opportunistischen Steuerung des Problemlösungsprozesses. Die Kooperationsformen explizite und implizite Kollaboration werden in Abschnitt 4.4 detaillierter vorgestellt.

    Google Scholar 

  25. Im Sinne einer “nicht flüchtigen”, dauerhaften Speicherung.

    Google Scholar 

  26. Vgl. Abschnitt 2.5.

    Google Scholar 

  27. Vgl. Abschnitt 1.3.

    Google Scholar 

  28. So besteht keine Notwendigkeit, koordinationsrelevante Daten z.B. mit Kundendaten zu vermengen.

    Google Scholar 

  29. Vgl. Abschnitt 2.2.2.

    Google Scholar 

  30. Vgl. Abschnitt 1.5.3.

    Google Scholar 

  31. Vgl. Abschnitt 1.3.

    Google Scholar 

  32. Vgl. Kapitel 3.

    Google Scholar 

  33. Vgl. Abschnitt 2.6.2.

    Google Scholar 

  34. Vgl. Abschnitt 2.6.2.

    Google Scholar 

  35. Z.B. unter Verwendung der in Kapitel 3 vorgestellten Partialmodelle.

    Google Scholar 

  36. Vgl. u.a. [KöRo93, S. 228].

    Google Scholar 

  37. Der Kundenanalyseagent ist z.B. ein Problemlösungsagent, der kein Fachagent ist.

    Google Scholar 

  38. Vgl. auch (KöRo93, S. 228],[Roem94].

    Google Scholar 

  39. Dem verteilten Problemlösungsprozeß von ALLFIWIB liegt aus Kundensicht eine Unterscheidung in drei Problemklassen von Kundenproblemen zugrunde. Dieses sind Anlageprobleme, Finanzierungsprobleme und gemischte Probleme. Die Klasse der Anlageprobleme ist dadurch gekennzeichnet, daß eine Kunde eine anfängliche Auszahlung und spätere Einzahlungen wünscht. Bei Finanzierungsproblemen ist die Zahlungsrichtung der von Anlageproblemen entgegengesetzt. Gemischte Probleme stellen Kombinationen von Anlage- und Finanzierungsproblemen dar. Die zugehörige Zahlungsreihe besitzt mehrere Vorzeichenwechsel. Anlageprobleme, Finanzierungsprobleme wie auch gemischte Probleme werden in ALLFIWIB einheidich durch einen Problemvektor repräsentiert, welcher eine Zahlungsreihe bestehend aus determinierten Zahlungen (z.B. Auszahlung von 100 GE in t = 0) und nicht determinierten Zahlungen (z.B. möglichst hohe konstante Einzahlungen in t = 1,...,T) darstellt. Vgl. [SaWe93]. Siehe auch [KöRo93, S. 224ff.].

    Google Scholar 

  40. In [BuSa93] wird explizites Wissen über vorteilhafte Kombinationen von Bankleistungen der finanzwirtschaftlichen Fachdomänen Couponanleihe, Lebensversicherung und Zerobond erarbeitet.

    Google Scholar 

  41. Eine detaillierte Beschreibung des verteilten Problemlösungsprozesses in ALLFIWIB findet man bei [Roem93] und [KöRo93].

    Google Scholar 

  42. Nach [SaWe92, S. 4ff.]. Siehe auch [KöRo93, S. 224ff.].

    Google Scholar 

  43. Der Leasingagent generiert auf PI eine Lösung S2, die keine vollständige Lösung des Kundenproblems darstellt. Es verbleibt das Restproblem P21 usw.

    Google Scholar 

  44. Z.B. eine Immobilie.

    Google Scholar 

  45. Ein Erarbeiten der Leasingvariante mit anfänglicher Einmalzahlung erfolgt lokal durch den Leasingagenten unter Verwendung leasingspezifischen Wissens. Derartiges fachdomänenspezifisches Wissen wurde z.B. in [BuEr91],[WiBu93] erarbeitet.

    Google Scholar 

  46. Auch die Konfiguration des Kreditvertrags als endfälliger Kredit obliegt der lokalen Probiemiösungskompetenz des Kreditagenten.

    Google Scholar 

  47. Vgl. auch [KöRo93, S. 225].

    Google Scholar 

  48. Vgl. [Mass93, S. 28ff.] sowie die dort angegebene Literatur.

    Google Scholar 

  49. In ALLFIWIB wurde als wissensbasierte Entwicklungsumgebung das Produkt AionDS gewählt. Es unterstützt neben der Funktionalität eines wissensbasierten Systems zusätzlich in integrierter Form auch Objektorientierung und konventionelle prozedurale Programmierung.

    Google Scholar 

  50. Vgl. [Mass93, S. 177ff.].

    Google Scholar 

  51. Zur Repräsentation von prozeduralem Methodenwissen (z.B. Lineare Optimierung) eignen sich jedoch DBMS nicht, da Methodenbanken primär Programmcode dezentral bereitstellen. Derartiges Methodenwissen könnte u.U. als Methoden in objektorientierten Datenbanken zu integrieren sein. Eine objektorientierte Datenbank, die Daten und prozedurales Methodenwissen kapselt, kann als Modellbank dienen.

    Google Scholar 

  52. Diese zukunftsweisende und ressourcenartenübergreifende Integrationsleistung einer FMDBSA ist derzeit im Prototyp von ALLFIWIB jedoch noch nicht realisiert.

    Google Scholar 

Download references

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 1994 Springer Fachmedien Wiesbaden

About this chapter

Cite this chapter

König, HJ. (1994). Flexible Datenbankarchitekturen als Integrationsplattform wettbewerbsorientierter Systeme. In: Ökonomische Datenhaltung in der Unternehmung. DUV Wirtschaftsinformatik. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-14578-3_5

Download citation

  • DOI: https://doi.org/10.1007/978-3-663-14578-3_5

  • Publisher Name: Deutscher Universitätsverlag, Wiesbaden

  • Print ISBN: 978-3-8244-2058-2

  • Online ISBN: 978-3-663-14578-3

  • eBook Packages: Springer Book Archive

Publish with us

Policies and ethics