Eine webbasierte Client-Server-Lösung zur indexbasierten Darstellung und Analyse von Entwicklungen beim Einkaufspreis

Tesis , 2010 , 164 Páginas , Calificación: 1,7

Informática - Informática técnica

Diese Diplomarbeit befasst sich mit der Konzeption und Implementierung einer webbasierten Client-Server-Lösung zur indexbasierten Darstellung und Analyse von Einkaufspreisentwicklungen in einem familiengeführten Automobilzulieferer-Unternehmen.

In der Einleitung wird die Firma vorgestellt, in deren Umfeld diese Arbeit angefertigt wurde. Darauf folgt die Motivation der Arbeit mit der Beschreibung der Ausgangssituation, der bisherigen Methode, der Aufgabenstellung und der späteren Funktionalitäten der Anwendung. Der Grundlagenteil geht näher auf Preisindexentwicklungen und Frameworks ein. Darauf folgen die Ergebnisse der Arbeit mit den Teilen „Konzept und Design“ und der Realisierung der Aufgabenstellung.

Diese Arbeit ist in folgende Kapitel gegliedert: Das Kapitel 2 „Grundlagen“ enthält einige ausgewählte Themen der Informatik und der Betriebswirtschaftslehre, die als Basis weiterer Kapitel der vorliegenden Arbeit dienen. Das Kapitel 3 „Analyse“ beinhaltet die Ergebnisse der Analysephase, welche hinsichtlich der technischen Hintergründe ausgearbeitet wurden. Es zeigt den genauen Umfang der Anforderungen, welche in der Anwendung realisiert werden sollen. Das Kapitel 4 „Konzept und Design“ beschreibt den ausgearbeiteten Weg der Umsetzung und des Designs der Anwendung. Auf der Grundlage der Ergebnisse des vorangegangenen Kapitels werden in Kapitel 5 “Realisierung“ die Realisierungsaspekte der Anwendung bestimmt. Eine Beschreibung der erstellten Anwendung wird in Kapitel 6 „Ergebnisse“ vorgenommen. Das letzte Kapitel 7 „Zusammenfassung und Aus-blick“ beinhaltet die Zusammenfassung der Arbeit, welche abschließend die möglichen Erweiterungen und denkbaren Formen der Fortführung der Anwendung darstellt.

Zusätzlich enthält die Arbeit jeweils ein standardisiertes Lasten- und Pflichtenheft zur erstellten Softwarelösung.

Inhaltsverzeichnis

1 Einleitung
1.1 Ausgangssituation
1.2 Motivation
1.3 Aufgabenstellung
1.4 Gliederung der Arbeit

2 Grundlagen
2.1 Datenbanken
2.1.1 Datenbanksystem
2.1.2 Datenbankmanagementsystem
2.1.3 Datenbank
2.1.4 Das relationale Datenbanksystem
2.1.5 SQL
2.2 Frameworks
2.2.1 Das Framework-Prinzip
2.2.2 Framework-Techniken
2.2.3 Webbasierte Client-Server-Anwendungen
2.3 Datenubertragung und Schnittstellen
2.3.1 Datenubertragung
2.3.2 Schnittstellen
2.4 Betriebliche Anwendungssoftware
2.4.1 Anwendungssoftware
2.4.2 ERP-Systeme
2.5 Preisindexentwicklungen
2.5.1 Preisindex
2.5.2 Laspeyres-Index
2.5.3 Paasche-Index
2.5.4 Indexentwicklung am Beispiel DAX
2.5.5 Betriebswirtschaftliche Kennzahlen

3 Analyse
3.1 Anforderungen aus Anwendersicht
3.1.1 Problemstellung
3.1.2 Bisherige Arbeitsweise
3.1.3 Anwenderfunktionalitaten
3.2 Technische Anforderungen
3.3 Vorhandene Systeme
3.3.1 XPPS-System
3.3.2 SAP
3.3.3 MIS
3.3.4 CO-Pilot
3.4 Zwischenfazit

4 Konzept und Design
4.1 Grobkonzeption
4.2 Framework-Struktur
4.2.1 Das Intrexx Xtreme Framework
4.2.2 Client-Server-Konzept
4.2.3 Datenbanken
4.2.4 Oberflachendesign
4.2.5 Rechtevergabe

5 Realisierung
5.1 Werkzeuge
5.1.1 Microsoft Visual Studio 2005
5.1.2 Microsoft SQL Server 2005
5.1.3 Intrexx Xtreme
5.2 Datenbeschaffung
5.2.1 SSIS-Pakete
5.2.2 Erstellung und zeitliche Planung der Pakete
5.3 SQL-Datenbankabfragen
5.4 Oberflachendesign
5.4.1 Aufbau des Hauptframeworks
5.4.2 Benutzergruppenkonzept
5.4.3 Benutzeroberflache der TPI-Anwendung

6 Ergebnisse
6.1 Zentrale Funktionen der TPI-Anwendung
6.1.1 Allgemeine Funktionen
6.1.2 Setting-Manager
6.1.3 Reporting-User
6.1.4 Purchaser
6.2 Grenzen

7 Zusammenfassung und Ausblick
7.1 Zusammenfassung
7.2 Fazit
7.3 Ausblick

Glossar

Quellen

Anhang A

Anhang B

Anhang C

1 Einleitung

Die vorliegende Diplomarbeit entstand im Rahmen einer Kooperation zwischen der Uni- versitat Siegen und dem Unternehmen XXXXXXX aus XXXXX. Betreut wird die Arbeit auf universitarer Seite durch die Fachgruppe „Technische Informatik“, geleitet von Prof. Dr.-Ing. habil. XXXXXXXXX. Ansprechpartner ist Dr.-Ing. XXXXXX. Betreuer im Un­ternehmen sind CFO XXXXXXX und Dipl. Wirt.-Ing. XXXXXX.

Die Arbeitsweise der Abteilung Einkauf eines Unternehmens hat in den letzten Jahren fur die Produktionsprozesse und Geschaftsergebnisse immer mehr an Bedeutung gewonnen. Diese Aussage wird durch das folgende Beispiel verdeutlicht, welches aus einer Studie der Unternehmensberatung Masai' in Zusammenarbeit mit dem Seminar fur Allgemeine Be- triebswirtschaftslehre, Beschaffung und Produktpolitik von Prof. Dr. Udo Koppelmann an der Universitat Koln hervorgeht: “Geht man von einem Unternehmen aus, dessen Umsatz- erlos bei 50 Mio. Euro liegt [...] und einem Anteil der Einkaufskosten am Umsatz von 60 Prozent, kommt man zu der verbluffenden Feststellung, dass eine nur 5-prozentige Kosten- senkung im Einkauf die gleiche Wirkung auf den Unternehmenserfolg hat wie eine 75- prozentige Absatzsteigerung.“ [MAUKO02]

Der Begriff Einkauf war ursprunglich auf die operativen Tatigkeiten zur Versorgung eines Unternehmens mit Gutern und Dienstleistungen, die zur Durchfuhrung des Produktions- prozesses benotigt und von diesem Unternehmen nicht selbst hergestellt werden, bezogen. Mit der zunehmenden Bedeutung der Unternehmensfunktion „Einkauf‘ werden vermehrt auch strategische Aufgaben unter diesem Begriff zusammengefasst. Andreas Lux, Chefre- dakteur der Zeitung „Beschaffungswelt“, veroffentlichte dazu schon im April 2008 im Ma- gazin „All About Sourcing“ im Artikel „Strategischer Einkauf braucht IT“: „Die Einkaufs- leiter werden [.] im Zuge der Outsourcing-Diskussion zunehmend dazu angehalten, ihren Wertbeitrag fur das Business aufzuzeigen. Dies funktioniert nur, in dem die Einkaufsver- antwortlichen von operativen Prozessen entlastet werden und Aufgaben der strategischen Beschaffung in den Mittelpunkt rucken. Ohne IT-Unterstutzung sowohl fur die operative als auch fur die strategische Beschaffung ist dies kaum zu bewerkstelligen.“ [AASAL08]

Die benotigte Unterstutzung der IT gilt so auch fur die Einkaufsabteilung des weltweit agierenden Automobilzulieferunternehmens XXXXXXXX, im Folgenden kurz XXXX genannt, mit seinem Hauptsitz im XXXXXXXXXX. Das Unternehmen, mit derzeit insge- samt rund 5000 Mitarbeitern, besitzt neben seinen sechs Werken in Deutschland weitere Produktionsstatten in Europa, Sudostasien, sowie Nord-, Mittel- und Sudamerika [MCOM09]. Das Entwicklungszentrum, zahlreiche Produktionshallen und die zentrale Verwaltung befinden sich am Standort des Hauptsitzes in XXXXXXX. Die Abteilung „Einkauf‘ am Hauptstandort, welche durch einen operativen Einkauf in den ubrigen Standorten unterstutzt wird, teilt sich weiter in die Bereiche „Kaufteile“, „MRO“ („Main- tenance, Repair and Operations“) und „Rohmaterial“, die fur die Beschaffung einer breit gefacherten und umfangreichen Palette von Produkten zustandig sind.

Neben der Versorgung des Werks mit Materialien, Sachgegenstanden und Dienstleistungen rund um den Hauptsitz, werden die anderen deutschen Werke ebenfalls durch den Zentral- einkauf versorgt. Diese zentrale Beschaffung bietet vor allem den Vorteil einer groBeren Transparenz in den zu tatigenden und bereits getatigten Einkaufsgeschaften. Im Zuge der bei XXXXX eingefuhrten Strategie des „Global Sourcing“, welches als insgesamt weltweit orientierte strategische Beschaffung beschrieben werden kann, wird auch zum Teil fur die Werke an den auBerdeutschen Standorten zentral vom Einkauf in XXXXXX eingekauft. Dies garantiert einen Uberblick uber mogliche Preisentwicklungstendenzen und verschafft einen hoheren Grad an Ubersichtlichkeit in Bezug auf die Einkaufsaktivitaten des gesam- ten Unternehmens.

Durch die steigende Bedeutung der Einkaufskostenminimierung soll im Rahmen der Dip- lomarbeit eine datenbankbasierte Client-Server-Anwendung realisiert werden, welche zur webbasierten Darstellung und Analyse einer transparenten, indexbasierten Einkaufspreis- entwicklung genutzt werden kann. Diese berechneten Kennzahlen werden die strategischen und operativen Entscheidungen der Abteilung Einkauf unterstutzen.

1.1 Ausgangssituation

Das Tatigkeitsfeld der Abteilung ist wesentlich groBer und vielseitiger als der Name „Ein- kauf ‘ vermuten lasst. Die Hauptaufgabe der Abteilung liegt in der Beschaffung von beno- tigten Materialien, Sachgegenstanden und Dienstleistungen, jedoch erfordert die Umset- zung mehr als eine einfache Bestellung bei einem Lieferanten. Im Vorfeld fast jeder Be- stellung mussen zahlreiche Gesichtspunkte beachtet werden, um die Beschaffungskosten zu optimieren. Zu den kostenreduzierenden MaBnahmen gehort beispielsweise der Preis- vergleich, durch den der Anbieter mit den gunstigsten Konditionen ausfindig gemacht wird. Zu diesen Konditionen gehoren nicht nur die realen Kosten, sondern auch Aspekte wie z.B. die Lieferbedingungen, die Garantie- bzw. Gewahrleistungsdauer oder die Art der Lieferung. Auch Qualitat, Flexibilitat und Zuverlassigkeit der Zulieferer sind von zentraler Bedeutung, da sie nicht kalkulierbare Folgekosten nach sich ziehen konnen. So rufen Qua- litatsmangel hohe Kosten in Form von Ruckrufaktionen oder Garantieinanspruchnahmen hervor und es konnen durch die Unzuverlassigkeit eines Lieferanten extrem hohe Kosten durch einen Produktionsstillstand entstehen.

Alle anfallenden Dokumente des Bestellungsprozesses werden von der Einkaufsabteilung geordnet und anschlieBend archiviert. Dies geschieht zum Teil in Form von gedruckten Dokumenten, aber zu einem viel groBeren Teil in digitaler Form. Zu diesem Zweck arbei- tet die Firma XXXXX mit dem ERP-System („Enterprise Resource Planning“)„XPPS“ der Firma INFOR. Des Weiteren gibt es spezielle Auswertungs-Tools, mit denen die Mitarbei- ter relevante Daten aufbereiten und darstellen konnen.

Zur Darstellung einer reinen Preisentwicklung fur die Abteilung Einkauf kann bislang nur die Berechnung eines Einkaufspreisindexes fur bestimmte Materialgruppen exemplarisch durchgefuhrt werden. Unter dem Begriff Materialgruppe ist hierbei eine Klassifizierung von Artikeln zu verstehen, welche im Teilestamm des unternehmensweiten ERP-Systems „XPPS“ gepflegt wird. Beim bisherigen Vorgehen werden dazu bei Bedarf alle relevanten Daten, die fur diese Berechnung benotigt werden, mit einem speziellen Auswertungstool (MIS = XXXXX Information System) aus verschiedenen Datenpools in ein Excel- Dokument exportiert und dort fur jede einzelne Materialgruppe bzw. jeden einzelnen Be- reich separat weiterverarbeitet.

1.2 Motivation

Die aktuelle Methode zur Berechnung eines Einkaufspreisindexes ist eine sehr zeitaufwan- dige Arbeitsweise, die zusatzlich wenige Moglichkeiten zur transparenten und individuel- len Analyse bietet, und dadurch nur stichprobenartig durchgefuhrt wird. Aufgrund der zahlreichen verteilten Systeme, der verschiedenen Datengrundlagen und der unterschiedli- chen Auswertungswerkzeuge, ist es haufig schwierig, eine vollkommene Transparenz bei den benotigten Auswertungen in angemessener Zeit zu schaffen. Ein weiterer Nachteil ist, dass die Analyseprozesse sehr unflexibel sind und man diese in der Form nicht weiter au- tomatisieren kann.

Durch die Erstellung einer Anwendung zur Berechnung von Preisindizes und Ergebnisef- fekten wird es bestimmten Mitarbeitergruppen von XXXXX moglich sein, die Entwick- lungen der Einkaufspreise des Unternehmens in verschiedenen Bereichen komfortabel transparent darzustellen und zu analysieren. Dies erleichtert die Entscheidungsfindung in strategischen Fragen und fordert eine systematische Leistungsmessung, -steuerung und -kontrolle des Einkaufs mit dem Ziel der kontinuierlichen Verbesserung der Unterneh- mensleistung. Bei der Messung und Darstellung des Erfolgs muss die IST-Situation auf Basis von Systemdaten berucksichtigt werden. Eine Folge dessen ist, dass der Erfolg ganz- heitlich und die Einsparungen und ggf. gegenlaufige Effekte gesondert betrachtet werden konnen. Dadurch werden Mix-Effekte vermieden und man erhalt ein transparentes Report­ing durch die Errechnung eines Einkaufspreis-Indexes. AuBerdem sollen zusatzlich zu den reinen Preiseffekten die Ergebniseffekte der Preisentwicklung dargestellt werden. Dies zeigt den Mitarbeitern des Einkaufs schnell und direkt, in welchen Bereichen bzw. Materi- algruppen ein Handlungsbedarf vorliegt. Durch die detaillierten Darstellungen werden die MaBnahmen zur Kostenoptimierung fur die einzelnen Geschaftseinheiten, Abteilungen und Mitarbeiter transparent dargestellt.

1.3 Aufgabenstellung

Die Aufgabenstellung dieser Diplomarbeit ist die Konzeption und Erstellung einer webba- sierten Client-Server-Losung zur indexbasierten Darstellung und Analyse der Einkaufs- preisentwicklung und deren Ergebniseffekten, im folgenden TPI-Anwendung (Total Purchase Index = gesamtheitlicher Einkaufs-Index) genannt. Die Forderung nach einer webbasierten Losung ist in der weltweiten Verteilung des Unternehmens begrundet. Eine weitere wichtige Voraussetzung ist die Integration dieser neu erstellten Anwendung in ein schon bestehendes System der Firma. Es soll keine eigenstandige Softwarelosung einge- fuhrt werden, um somit die Akzeptanz der Mitarbeiter durch die bekannten, standardisier- ten Design-Aspekte der vorhandenen Anwendungen wahren zu konnen. AuBerdem mussen spezielle Schnittstellen zum ERP-System der Firma aufgebaut und genutzt werden, da sich die Grunddaten zur Berechnung der Entwicklungen und Effekte in den Datenpools dieses Systems befinden.

Die Bedienung der Anwendung soll fur die zukunftigen Benutzer einheitlich und komfor­tabel uber einen Webbrowser moglich sein. Es gibt die Optionen der Darstellung verschie- den detaillierter Sichten auf die Entwicklung der Einkaufspreise und die Auswahl unter- schiedlicher Betrachtungsebenen der Preiseffekte, um dem Benutzer einen direkten Ein- stieg zu den gewunschten Informationen zu eroffnen. Alle Daten werden in tabellarischer oder auch in grafischer Form dargestellt und konnen per Filter- und Sortierfunktion analy- siert werden. Die Ergebnisse der Darstellungen konnen zusatzlich aus dem Webbrowser gespeichert werden.

Jeder Benutzeraccount wird zuerst durch einen Administrator angelegt, um sicherzustellen, dass nur bestimmte Personen Zugang zu den Funktionen der Anwendung erhalten. AuBer- dem weist der Administrator den Nutzern bestimmte Berechtigungen und Eigenschaften zu. Mit dieser Kennung kann sich der Benutzer dann jederzeit anmelden. Um verschiedene Sichten und Bearbeitungslevel realisieren zu konnen, muss ein Benutzergruppenkonzept in der Umsetzung der Anwendung berucksichtigt werden. Ein weiterer wichtiger Aspekt ist eine mehrsprachige Benutzeroberflache, welche vor allem bei dem internationalen Auftre- ten des Unternehmens von Bedeutung ist. Vor diesem Hintergrund sollte der Benutzer der Anwendung auch die Moglichkeit haben, zwischen unterschiedlichen Anzeigewahrungen wechseln zu konnen. Dies impliziert eine Verwaltung und Berucksichtigung von Wah- rungsumrechnungsfaktoren.

1.4 Gliederung der Arbeit

Diese Arbeit ist in folgende Kapitel gegliedert: Das Kapitel 2 „Grundlagen“ enthalt einige ausgewahlte Themen der Informatik und der Betriebswirtschaftslehre, die als Basis weite- rer Kapitel der vorliegenden Arbeit dienen. Das Kapitel 3 „Analyse“ beinhaltet die Ergeb- nisse der Analysephase, welche hinsichtlich der technischen Hintergrunde ausgearbeitet wurden. Es zeigt den genauen Umfang der Anforderungen, welche in der Anwendung rea- lisiert werden sollen. Das Kapitel 4 „Konzept und Design“ beschreibt den ausgearbeiteten Weg der Umsetzung und des Designs der Anwendung. Auf der Grundlage der Ergebnisse des vorangegangenen Kapitels werden in Kapitel 5 “Realisierung“ die Realisierungsaspek- te der Anwendung bestimmt. Eine Beschreibung der erstellten Anwendung wird in Kapitel 6 „Ergebnisse“ vorgenommen. Das letzte Kapitel 7 „Zusammenfassung und Ausblick“ beinhaltet die Zusammenfassung der Arbeit, welche abschlieBend die moglichen Erweite- rungen und denkbaren Formen der Fortfuhrung der Anwendung darstellt.

2 Grundlagen

Dieses Kapitel bietet eine Einfuhrung in einige Grundlagenthemen. Hierfur werden Wis- sensgebiete aus den Bereichen der Informatik und der Betriebswirtschaftslehre behandelt. Das Thema „Datenbanken“ in Abschnitt 2.1 gibt einen Einblick in den Aufbau, den Ein- satz und die Funktionalitat von Datenbanken. Die grundlegenden Konzepte der Frame- work-Technik werden in Abschnitt 2.2 erlautert. Im darauf folgenden Teil des Kapitels wird naher auf die Besonderheiten und Moglichkeiten der Datenubertragung und Nutzung von Schnittstellen eingegangen. Im abschlieBenden Teil der Grundlagen werden Aspekte betriebswirtschaftlicher Anwendungssoftware und die Darstellung von Preisindexentwick- lungen erlautert.

2.1 Datenbanken

In diesem Kapitel werden die Funktionalitat, der Aufbau und der Einsatz von Datenbank- systemen beschreiben. Auf die Bestandteile des Datenbanksystems wird genauer einge­gangen und das Modell der relationalen Datenbank erlautert. Darauf folgt ein Einblick in die Abfragesprache SQL.

2.1.1 Datenbanksystem

Datenbanksysteme, oder auch kurz DBS genant, sind nach [VGDDD08] ein weit verbreite- tes Hilfsmittel zur effizienten, rechnergestutzten Organisation, Speicherung, Manipulation, Integration und Verwaltung groBer Datensammlungen. Datenbanksysteme entstanden in den 1960er Jahren aus der Erkenntnis heraus, Daten uber die reale Welt, welche von An- wendungsprogrammen verwaltet werden, als von diesen Pogrammen unabhangiges inte- griertes Betriebsmittel zu behandeln. [VGDDD08] teilt ein DBS in das Datenbankmana- gementsystems (DBMS) und eine Anzahl von Datenbanken (DB) auf und hat die Begriffs- erklarungen in Tabelle 2.1 zusammengefasst.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Begriffsbildung Datenbanksysteme

[GFDB09] beschreibt in Bild 2.1 das Datenbanksystem als Zusammenhang der vier Schichten Hardware, Daten, Software und Personen. Dabei bildet die Hardwareschicht die Basis des Datenbanksystems. Hierzu zahlen der Datenbankserver, die Clientrechner und die physikalische Verbindung der beiden Komponenten. Die Daten sind der zentrale Punkt des DBS. Es sind die Fakten, welche im Datenbanksystem gespeichert und verwaltet wer­den. Zum Schutz der Daten hat nur das Datenbankmanagementsystem eine Zugriffsmog- lichkeit auf die Daten. Das DBMS ist die wichtigste Komponente der Softwareschicht und ubernimmt die Verwaltung der Daten. Die Datenbankanwendungsprogramme stellen die Schnittstelle zwischen den Benutzern und dem DBS dar. Diese Programme konnen als Windows-Anwendungen, Web-Anwendungen oder Dienstprogramme implementiert sein [GFDB09]. Eine letzte wichtige Schicht sind die Personen, die mit dem Datenbanksystem arbeiten. Sie konnen in Gruppen von Anwendern und Datenbankadministratoren aufgeteilt werden.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.1: Details Datenbanksystem

Zur Einordnung der DBS in eine Softwarekategorie teilt [SSHDB08] die Software eines Computersystems gemaB Bild 2.2 in Betriebssystem, Systemsoftware, Basissoftware, An- wendungs- und Individualsoftware.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.2: Aufteilung Softwareschichten

Jede Schicht baut hierbei auf den weiter innen liegenden Schichten auf. Das Datenbanksys­tem gehort zu der Systemsoftware und bildet damit eine sehr elementare Software [SSHDB08]. Ein DBS gewahrleistet die persistente Speicherung, sowie die Konsistenz der Nutzdaten einer Institution und bietet mit dem DBMS eine Schnittstelle zur Abfrage, Ma­nipulation und Verwaltung dieser Daten. Die wesentliche Aufgabe neben der Speicherung der Daten ist die Bereitstellung der benotigten Teilmengen in unterschiedlichen, bedarfsge- rechten Darstellungsformen fur Benutzer und Anwendungsprogramme. Ohne den Einsatz von DBS tritt das Problem der Datenredundanz auf, wobei Daten mehrmals an verschiede- nen Stellen gespeichert werden. Diese dezentrale Datenhaltung hat zur Folge, dass Spei- cherplatz verschwendet wird, Daten mehrfach geandert werden mussen und keine einheit- liche Datenbasis als Grundlage vorliegt [SSHDB08]. Weitere Problemfelder bei fehlender DBS-Nutzung sind EffizienzeinbuBen bei der Verarbeitung groBer Datenmengen, fehlende Sicherstellung der Zugriffskontrolle und fehlende Datenunabhangigkeit [KEDBS01].

Diese Probleme konnen mit Hilfe des Einsatzes von Datenbanktechnologien gelost wer- den. Hierbei spricht man nach [SSHDB08] im Gegensatz zur Datenredundanz von der Da- tenintegritat, d.h. die Daten werden in einer zentralen Datenhaltungskomponente verwaltet. Die Probleme im Umgang mit groBen Datenbestanden, etwa Fragestellungen der Effizienz, Parallelitat, Zugriffskontrolle und Datensicherheit konnen mit heutigen kommerziellen Datenbanksystemen zufriedenstellend gelost werden [SSHDB08]. Grundlegende Struktu- ren fur das DBS sind hierarchische, netzwerkartige, relationale, objektorientierte oder ob- jektrelationale Datenbankmodelle. Das relationale Datenbanksystem wird spater in Ab- schnitt 2.1.4 genauer erlautert.

2.1.2 Datenbankmanagementsystem

Nach [SSHDB08] versteht man unter Datenbankmanagementsystem, kurz DBMS, die Ge- samtheit der Softwaremodule, die die Verwaltung einer Datenbank ubernehmen. Die Ver- waltungssoftware organisiert intern die strukturierte Speicherung der Daten und kontrol- liert alle lesenden und schreibenden Zugriffe auf die Datenbank. Zur Abfrage und Verwal­tung der Daten bietet ein Datenbanksystem eine Datenbanksprache an. Nach [VGDDD08] ist ein DBMS grob gesehen ein spezielles Programm zur Verwaltung einer Datenbank, welches ganz oder teilweise im Hauptspeicher des entsprechenden Rechners abgelegt ist und unter der Kontrolle des Betriebssystems ausgefuhrt wird.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.3: Funktionen eines DBMS

Laut [GFDB09] wird ein Datenbankmanagementsystem zur Organisation der Daten und fur den Zugriff auf die Daten verwendet. Das DBMS kann aus einem einzelnen Programm bestehen, wie es oft bei Desktop-Anwendungen der Fall ist. Bei servergestutzten Anwen- dungen besteht das DBMS meist aus einem Verbund von mehreren Programmen, die die Funktionalitaten eines DBMS bereitstellen. Dazu hat [GFDB09] diese Funktionalitaten in Bild 2.3 zusammengestellt.

[SSHDB08] fasst die Funktionalitat eines DBMS unter den folgenden neun Punkten zu- sammen:

- Integration: einheitliche zentrale Verwaltung aller Daten
- Operation: Speicherung, Suche und Anderung der Daten
- Katalog: ermoglicht Zugriffe auf die Datenbeschreibung der Datenbank
- Benutzersichten: unterschiedliche Sichten bei unterschiedlichen Anwendungen und die Kontrolle der strukturierten Abbildungen des Datenbestandes
- Konsistenzuberwachung: Gewahrleistung korrekter Datenbankinhalte und kor- rekter Ausfuhrung von Anderungen
- Zugriffskontrolle: Ausschluss unautorisierter Zugriffe auf die gespeicherten Da- ten
- Transaktion: Zusammenfassung von Datenbankbestanden zu Funktionseinhei- ten, die als Ganzes ausgefuhrt werden und bei Erfolg in Datenbanken gespei- chert werden
- Synchronisation: konkurrierende Transaktionen verschiedener Benutzer zur Vermeidung von Schreibkonflikten
- Datensicherung: ermoglicht die Wiederherstellung von Daten nach Systemfeh- lern

Hieran sieht man die Vielfaltigkeit und Komplexitat der Aufgaben eines Datenbank- managementsystems.

2.1.3 Datenbank

[GFDB09] gibt zwei Definitionen einer Datenbank. Zuerst beschreibt er diese als ein ver- teiltes integriertes Computersystem, das Nutzdaten und Metadaten enthalt. Nutzdaten sind dabei Daten, die Benutzer in der Datenbank anlegen und aus denen die Informationen ge- wonnen werden. Metadaten werden oft auch als Daten uber Daten bezeichnet und helfen, die Nutzdaten der Datenbank zu strukturieren. Als zweite Definition aus [GFDB09] wer­den Datenbanken als eine geordnete, selbstbeschreibende Sammlung von Daten beschrie- ben, die miteinander in Beziehung stehen.

Nach [VGDDD08] ist eine Datenbank eine Sammlung von Daten, welche Fakten uber ei- nen speziellen Ausschnitt der realen Welt reprasentieren. Als solche sind die Daten in einer Datenbank von einem logischen Standpunkt aus eng verwandt. Dieser Datenbestand wird von einem laufenden DBMS verwaltet. Aufgrund der GroBe wird die Datenbank auf nicht- fluchtigen Speichermedien abgelegt und lediglich zu Verarbeitungszwecken teilweise in den Hauptspeicher geladen [KEDBS01]. Um einen effizienten Zugriff auf die Datenbank zu gewahrleisten, verwaltet das DBMS in der Regel eine Speicherhierarchie, die insbeson- dere einen schnellen Zwischenspeicher umfasst. Zur Wahrung der Konsistenz des Daten- bestandes mussen sich alle Anwendungssysteme an das DBMS wenden, um die Datenbank nutzen zu konnen.

Nach [SSHDB08] sind die klassischen Einsatzgebiete von Datenbanken die folgenden be- triebswirtschaftlichen Funktionalitaten:

- Anwendungen im kommerziellen Bereich, die sich aus Buchhaltungs- und Ka- talogisierungsproblemen entwickelt haben
- Enterprise-Ressource-Planing-Systeme, die die gesamte Ressourcenplanung im Unternehmen unterstutzen
- Customer-Relationchip-Management-Systeme, die zur Verwaltung der Kun- denbeziehungen eines Unternehmen dienen
- Data Warehouses, die eine integrierte Datenbasis fur Unternehmensdaten aus verschiedenen Quellsystemen darstellen, welche zum Analysezweck langerfris- tig und unabhangig vom Quellsystem gespeichert werden muss

AuBerdem dienen Datenbanken als Grundlage eines Informationssystems, als Basis kom- plexer Anwendungsprogramme, als Register zur Abfrage von themenrelevanten Daten oder zur Sicherung von Informationen im privaten Bereich.

2.1.4 Das relationale Datenbanksystem

Es gibt viele verschiedene Formen von Datenbanksystemen. Die Art und Weise, wie ein solches System Daten speichert und verwaltet, wird durch das Datenbankmodell festgelegt. Je nach Datenbankmodell muss das Datenbankschema an bestimmte Strukturierungsmog- lichkeiten angepasst werden. Nach [SRGRD09] lassen sich die Datenmodelle in drei Hauptkategorien einteilen:

- hierarchische Datenbank: die Datenobjekte konnen ausschlieBlich in einer El- tern-Kind-Beziehung zueinander stehen
- relational und objektrelational: die Daten werden zeilenweise in Tabellen ver­waltet, es kann beliebige Beziehungen zwischen den Daten geben und sie wer- den durch Werte bestimmter Tabellenspalten festgelegt
- objektorientiert: die Beziehungen zwischen Datenobjekten werden vom Daten­banksystem selbst verwaltet, wobei die Objekte Eigenschaften und Daten von anderen Objekten erben konnen

Die bekannteste Form eines Datenbanksystems ist das relationale Datenbanksystem. Rela­tionale Systeme haben seit langem eine zentrale Position auf dem Software-Markt und sind auf praktisch allen Hardware-Plattformen verfugbar [VGDDD08]. Die Operationen eines relationalen Datenbankmodells basieren auf der relationalen Algebra. Das algebraische Modell beschreibt die Speicherung, Abfrage und Manipulation von Daten. Die wesentli- chen Operationen des Modells, aus denen alle weiteren abgeleitet werden konnen, zeigt das Bild 2.2 aus [MADBE04]. In einem relationalen Datenmodell sieht der Benutzer die Daten in Form von Tabellen, welche manipuliert werden konnen bzw. auf die zugegriffen werden kann [VGDDD08]. Bei relationalen Datenbanken werden die Daten nicht hierarchisch in einer Datei, sondern geordnet nach Themenkreisen (Entitaten) in Form von Tabellen abge- legt [SRGRD09]. Die relationalen Datenbanken sind zurzeit von den moderneren Ansatzen kommerziell am weitesten verbreitet. Sie unterstutzen ein verhaltnismaBig einfaches Da- tenstrukturierungsmodell, und der Zugang zu ihnen uber Datenbanksprachen ist in Form einer SQL-Norm weitestgehend standardisiert [SSHDB08]. Hierzu schreibt [SSHDB08], dass ein Datenbanksystem an der Benutzerschnittstelle mehrere Sprachkonzepte zur Ver- fugung stellt, etwa um die Anfragen, Datenbankanderungen oder externe Sichten zu dekla- rieren.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.2: Funktionen eines DBMS

Als Anfragesprache bzw. Abfragesprache wird oft eine Sprache angeboten, die es erlaubt, aus vorhandenen Tabellen neue zu berechnen, die Antwort auf eine Fragestellung geben. Relationale DBMS bieten eine interaktive Moglichkeit, Datenbankanfragen zu formulieren und zu starten. Heutzutage ist die Sprache in der Regel ein SQL-Dialekt [SSHDB08].

2.1.5 SQL

SQL ist die Abkurzung fur „Structured Query Language“, was ubersetzt soviel heiBt wie „strukturierte Abfragesprache“. Nach [FPLDI02] ist SQL eine im Jahr 1976 bei IBM ent- standene Datendefinitions- und Datenmanipulationssprache fur relationale Datenbanken. SQL ist eine syntaktische Abbildung der im letzten Abschnitt beschriebenen relationalen Algebra. SQL wurde 1986 durch das American National Standard Institute (ANSI) stan- dardisiert und ist heute als herstellerunabhangiger Standard akzeptiert [ECSID93]. Als Datenbanksprache umfasst SQL nach [SSHDB08] folgende Teile:

- einen Daten- und Sichtdefinitionsteil (DDL = Data Definition Language)
- einen Anfrageteil (DQL = Data Query Language)
- einen Teil zur Formulierung von Datenanderungen (DML = Data Manipulation Language)
- einen Definitionsteil fur Dateiorganisationsformen und Zugriffspfade (DCL = Data Control Language)
- einen Teil mit imperativen Konstrukten zur Definition von Prozeduren und Funktionen

Durch die Funktionen der Datenbanksprache konnen Tabellen angelegt, Datenformate de- finiert und alle gewunschten Daten aus der Datenbank abgefragt werden. Im Gegensatz zu prozeduralen Programmiersprachen, die genau definieren wie eine Aufgabe gelost wird, teilen die SQL-Anweisungen dem Datenbankmanagementsystem nur mit, welches Ergeb- nis geliefert werden soll [GFDB09]. Diese Nutzung der SQL-Datenbanksprache erleichtert die Implementierung von Datenbank-Anwendungen. Das SQL-Datenmodell erweitert nach [SSHDB08] das theoretische Relationenmodell um einige weitere Aspekte. Eine Reihe von unterschiedlichen Wertebereichen (unter anderem lange Felder, Strings, Datumswerte) und Nullwerte werden eingefuhrt. AuBerdem werden die Gruppierung und Sortierung in der Abfragesprache unterstutzt. Die syntaktische Prufung durch einen sogenannten Scanner- Parser stellt fest, ob eine Abfrage der SQL-Syntax entspricht [SHRDB02] und es erscheint bei der Ausfuhrung fehlerhafter SQL-Abfragen eine Fehlermeldung.

2.2 Frameworks

Ein Framework ist nach [FSJBAF99] definiert als ein wiederverwendbares Design von Teilen bzw. einem gesamten System, welches durch eine Reihe abstrakter Klassen und der Art wie ihre Instanzen miteinander kommunizieren, reprasentiert wird. Diese allgemeine Beschreibung eines Frameworks wird im folgenden Kapitel genauer betrachtet. Es werden die Framework-Prinzipien und -Techniken vorgestellt. Im Weiteren wird auf die webba- sierten Client-Server-Anwendungen eingegangen.

2.2.1 Das Framework-Prinzip

Framework bedeutet ubersetzt soviel wie „Rahmenwerk“ und ist nach [FSOAF97] eine wiederverwendbare, halbfertige Anwendung, die spezialisiert werden kann, um gebrauch- liche Anwendungen zu erstellen. Eine weitere Definition aus [FSJBAF99] beschreibt ein Framework als Skelett einer Applikation, welches durch einen Software-Entwickler kun- dengerecht angepasst werden kann. Weitreichende Anderungen bei der Entwicklung von Software ergeben sich durch die Nutzung von Frameworks. Durch dieses Rahmenwerk wird bereits eine grobe Anwendungsstruktur vorgegeben, die meist nur eine Vervollstandi- gung an definierten Schnittstellen erforderlich macht, um eine voll funktionsfahige An­wendung zu erhalten [FSJBAF99]. Ein Framework ist also noch kein fertiges Programm, sondern nur der Rahmen innerhalb dessen der Programmierer eine Anwendung erstellt. Die speziellen wiederverwendbaren Infrastrukturen ermoglichen dem Entwickler, Produkte einer bestimmten Fachdomane schnell und effizient herzustellen. Frameworks erfullen nach [PWKSF97] eine bestimmte Aufgabe und bieten den hochsten Grad an Wiederver- wendbarkeit. Das hat auBerdem den Vorteil, dass Entwicklungs- und Wartungskosten ge- ringer ausfallen, sowie die Softwarequalitat durch die bereits getesteten Komponenten ver- bessert wird.

Das ausgearbeitete Framework steht mit dem Softwarepaket und der Softwarekomponente wie im Bild 2.4 aus [KMOPP07] in Beziehung. Naher betrachtet besteht ein Framework aus einer Menge von Objekten, die eine allgemeingultige Losung fur eine Menge verwand- ter Problemstellungen implementieren. Es legt die Funktionen der einzelnen Objekte und deren Interaktion fest. Das Framework bietet eine generische Schnittstelle, welche allge- meingultig ist und uber die die Aufgaben der Objekte erweitert und angepasst werden kon­nen. Ein Framework beschreibt eine Reihe von Klassen, welche zur Wiederverwendung genutzt werden konnen, bestimmte Aufgaben erfullen und wichtige Entscheidungen im Entwurf festlegen. Von diesen abstrakten Klassen werden dann die konkreten Klassen fur die jeweilige Anwendungsschicht abgeleitet. Wie in [OBADU06] zu lesen ist, ist eine Be- sonderheit solcher Rahmenwerke die Verlagerung der vertikalen Beziehungen zwischen den Schichten einer Anwendung, d.h. die Bedienung der grundlegenden Schnittstellen durch das Rahmenwerk.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.4: Framework-Beziehungen

Die Kommunikation zwischen den Schichten verlauft soweit wie moglich uber die Klassen des Frameworks. Die auf das Rahmenwerk aufgesetzten Klassen kommunizieren moglichst nur innerhalb ihrer jeweiligen Schicht. [OBADU06] schreibt weiter, dass fur die Benut- zung des Frameworks der Ausspruch “Don’t call the framework, the framework calls y- ou!“ gilt. Das bedeutet, dass der Entwickler konkrete Implementierungen registriert, die dann durch das Rahmenwerk gesteuert und benutzt werden.

Frameworks werden also entwickelt, um architektonische Muster erneut zu verwenden. Da der Entwurf nicht ohne die Berucksichtigung einer konkreten Anwendungsdomane durch- gefuhrt werden kann, sind Frameworks meist domanenspezifisch oder auf einen speziellen Anwendungstyp eingegrenzt. Beispiele sind Frameworks fur grafische Editoren, Buchhal- tungssysteme oder elektronische Warenhauser im World Wide Web [KMOPP07].

Dabei sind die White-Box-Wiederverwendung und Black-Box-Wiederverwendung als Arten der Benutzung von Frameworks [FSOAF97] bzw. der Sichtbarkeiten der Implemen- tierung hinter der Schnittstelle [KMOPP07] bekannt.

White-Box

Die White-Box ist nach [FPLDI02] die Betrachtung eines Systems innerhalb der System- grenzen. Ein Programmsystem wird von der Ablauflogik und der Dynamik der Daten beur- teilt und als strukturbezogen angesehen. Eine White-Box erlaubt die Modifikation sowohl des Innen- als auch des AuBenlebens einer Komponente [AAKSE04]. White-Box- Frameworks bestehen aus unvollstandigen spezifizierten Klassen. Die Klassen enthalten abstrakte Methoden, die vom Entwickler neu definiert bzw. erweitert werden mussen. Da- zu werden uber Vererbung die Methoden durch die Unterklassen uberschrieben. Das Framework legt dabei wichtige Teile und Beziehungen fest, die in Bild 2.5 als dunkle

Puzzle-Teile dargestellt sind. Diese mussen durch anwendungsspezifische Teile erganzt werden, welche in Bild 2.5 weiB dargestellt sind.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.5: White-Box-Framework

Die White-Box-Wiederverwendung ist die umfangreichste Art der Wiederverwendung, da man in Unterklassen sehr flexibel Anpassungen und Erweiterungen vornehmen kann [ZHOOH05]. Dies beinhaltet aber auch, dass der Entwickler des Frameworks aufwendige Programmierung leisten muss und ein gutes Verstandnis fur die im Framework implemen- tierten Mechanismen vorhanden ist [PWKSF97].

Blackbox

Die Black-Box ist nach [FPLDI02] die Betrachtung eines Systems auBerhalb der System- grenzen. Ein Programmsystem wird von den Ein- und Ausgaben beurteilt und als wir- kungsbezogen angesehen. Beim Black-Box-Framework ist nur das AuBere der Komponen- te zu sehen, d.h. man sieht nur deren Schnittstelle [AAKSE04]. Das Black-Box-Prinzip basiert im Gegensatz zum White-Box-Prinzip nicht auf unfertigen Klassen, welche ange- passt werden mussen. Das bedeutet, dass die Funktionsweise von Black-Box-Frameworks uber definierte Schnittstellen konfigurierbar ist und der Entwickler keine Kenntnisse uber die innere Struktur benotigt [PWKSF97]. Eine Black-Box stellt verschiedene Klassen zur Instanzierung und Parametrisierung zur Verfugung, welche direkt genutzt und ausgetauscht werden konnen, ohne dass der Entwickler versteht, wie die Objekte intern zusammenspie- len. Um mogliche notwendige Veranderung der Komponenten durchfuhren zu konnen, nutzt man das Adapter-Entwurfsmuster. Dieses Muster legt einen sogenannten Wrapper um die nicht veranderbare Komponente, der wie ein Schutzwall alle benutzten Komponen­ten von dieser Komponente trennt. Bild 2.6 aus zeigt ein Black-Box Framework, bei dem einzelne Teile austauschbar sind.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.6: Black-Box-Framework

Der Ubergang von der White-Box- zur Black-Box-Wiederverwendung ist flieBend. Einige Frameworks ermoglichen wesentliche Erweiterungen durch Parameterobjekte. Andere er- lauben nur aus einer vorgegebenen Menge von Klassen auszuwahlen. [ZHOOH05].

2.2.2 Framework-Techniken

Neben der Unterteilung der Frameworks bezuglich der Sichtbarkeit ihrer Implementierung lassen sich diese weiter differenziert bezuglich der verwendeten Technik betrachten.

Application-Frameworks

Die Application-Frameworks, auch Enterprise Application Framework genannt, bilden den Programmrahmen fur eine bestimmte Klasse von Anwendungen, d.h. von Funktionen und Programmstrukturen, die bei allen Anwendungen dieser Klasse von Bedeutung sind [KMOPP07]. Nach [PWKSF97] besteht das Application-Framework aus statischen Berei- chen (engl. frozen spots) und veranderbaren Bereichen (engl. hot spots). Dieses Code- Gerust aus fertigen und unfertigen Klassen wird durch die Anpassung an die kundenspezi- fischen Einsatzgebiete zu einer speziellen Applikation. Die allgemeine Schnittstelle besteht aus einer Menge abstrakter und konkreter Klassen deren Funktionen durch den domanen- spezifischen Teil aufgerufen bzw. uberladen werden. Die durch diesen Typ gebildeten Programmrahmen werden auch als „horizontal slice“ bezeichnet [KMOPP07]. Horizontale Frameworks unterstutzen die Entwicklung von Anwendungen, die eine bestimmte Techno- logie verwenden (z.B. Web Services), ohne auf die Fachrichtung festgelegt zu sein. Sie werden auch als Application Frameworks bezeichnet. Typische Anwendungsgebiete von Application-Frameworks sind grafische Benutzeroberflachen, Dokumente und Datenban- ken.

Domain Frameworks

Die Domain-Framworks bilden den Programmrahmen fur einen bestimmten Problembe- reich, d.h. von Funktionen und Strukturen, die zur Losung dieses Problembereichs im All- gemeinen benotigt werden. Die durch diesen Typ gebildeten Programmrahmen werden auch als „vertical slice“ bezeichnet [KMOPP07]. Vertikale Frameworks erzeugen Anwen­dungen aus einer bestimmten Domane. Ein Beispiel fur einen speziellen Anwendungsbe- reich sind Banksysteme oder Alarmsysteme [BTSD05].

CAx-Framework

Die CAx-Frameworks, oder auch „Middleware-Integration-Framework“ genannt, werden allgemein verwendet, um verteilte Anwendungen und Komponenten zu integrieren. Midd­leware-Integration-Frameworks werden entworfen, um die Moglichkeiten von Software- entwicklern bei der Modularisierung und Wiederverwendung zu erhohen [FSJBAF99]. Sie konnen auBerdem die Softwareinfrastruktur einfach erweitern, damit diese nahtlos in einer verteilten Umgebung arbeiten kann. Ein CAx-Framework ist ein Bezugssystem, das be- stimmte Infrastrukturen und Dienste garantiert. Es stellt eine Sammlung von Werkzeugen zur Auswahl in einer meist einheitlichen Oberflache dar. Die Zusammenstellung der Werkzeuge gibt bereits Formate und Moglichkeiten fur den Entwurf vor. Der groBe Vorteil von CAx-Frameworks ist die Reduktion der Komplexitat durch die zentrale Steuerung uber das Framework und die zentrale Datenhaltung. Die einzelnen Werkzeuge und Komponen­ten durfen nicht mehr direkt miteinander kommunizieren, sondern operieren alle uber nor- mierte Schnittstellen mit der zentralen Datenhaltung [SSWBSI03]. Die allgemein gultige Schnittstelle zur Fachdomane verbirgt sich hinter textuellen und grafischen Editoren (GUI).

Applikationsgeneratoren

Ein Applikationsgenerator ist nach [LMDDB03] ein Programm, das aufgrund einer Spezi- fikation des Benutzers einen Prototyp erstellt, der programmiersprachlich verfeinert wer­den kann. [LMDDB03] schreibt weiter, dass Applikationsgeneratoren schlieBlich ganze Standardanwendungen automatisch erzeugen. Es wird in der Regel eine Standardspezifika- tion in ein Quellprogramm ubersetzt, das der Entwickler programmiersprachlich verfeinern und erweitern kann. Beim Applikationsgenerator ist die generische Schnittstelle in Form eines Interpreters oder Compilers gegeben. Die Fachdomane wird durch eine geeignete Spezifikationssprache, wie z.B. UML, HTML oder andere Programmiersprachen, definiert und in eine Framework-konforme Beschreibung ubersetzt. Sie bildet zusammen mit dem Framework die lauffahige Applikation.

Integrierte objektorientierte Applikationsgeneratoren stellen objektorientierte Generatoren zur Verfugung und beinhalten implizierte Funktionen zum Datenzugriff. Alle Teilkompo- nenten des Werkzeugs (Objekte, Masken, Menus, Reportgenerator, Editor und Interpreter) greifen auf die gleichen Informationen zu, die in einem eigenen erweiterten Data- Dictionary abgelegt sind. Dieses Konzept erlaubt dynamische Programmanderungen zur Laufzeit und ist damit flexibel von Entwicklern und Endanwendern einsetzbar [CWOAD91].

2.2.3 Webbasierte Client-Server-Anwendungen

Die Entwicklung einer webbasierten Client-Server-Anwendung besteht aus der Implemen- tierung des Fachkonzepts und der Erstellung der Benutzeroberflache.

Client-Server Anwendung

[FPLDI02] beschreibt die Client-Server-Anwendung als zentrales Konzept der dezentralen Datenverarbeitung. Dabei laufen die Client-Programme auf der Anwendungsseite und die Server-Programme an einem zentralen Ort. Die Hardware- oder Softwarekomponenten, die Dienste von einem Server in Anspruch nehmen konnen, werden Client oder auch Kunde genannt [WPPCL05]. Der Client bietet die Benutzeroberflache oder -schnittstelle einer Anwendung an [TEHITM03]. Der Server stellt dem Client bestimmte Dienste zur Verfu­gung. Die Verarbeitung geschieht teils beim Client und teils beim Server, wobei die Daten oft im ganzen Netz verteilt verarbeitet werden [FPLDI02]. Die Datenverarbeitung ist zu- dem oft dynamisch und den aktuellen Gegebenheiten zur Laufzeit angepasst.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.7: Traditionelle versus Client-Server-Anwendung

Das Betriebssystem vergibt Auftrage an den Ort groBter verfugbarer Rechnerkapazitat. Die Daten des Systems werden zentral gespeichert und lassen sich so besser verwalten. AuBer- dem lasst sich mit diesem Verfahren ein System sehr flexibel skalieren [WPPCL05].

Wahrend in traditionellen Umgebungen ein Computer die Ressourcen fur die Verarbei- tung, Datenhaltung und Presentation der Daten bereit stellt, kommunizieren in einer Client- Server-Umgebung Clients mit Server-Modulen uber ein gemeinsames Protokoll in einem Netzwerk. Die Kommunikation zwischen den beiden Komponenten erfolgt uber eine ge- normte Schnittstelle. Ein Beispiel dafur ist die Abfragesprache SQL [TEHITM03]. Eine mogliche Aufgabenverteilung zwischen Client und Server zeigt das Bild 2.7 aus [TEHITM03] im Vergleich zum Aufbau einer traditionellen Anwendung.

Der Webserver ist ein Beispiel fur einen Serverdienst. Hierbei versorgt der Server viele Clients mit Informationen. Diese konnen sich entweder statisch auf dem Web-Server be- finden oder aber dynamisch von weiteren Dienstprogrammen erzeugt werden. Das World Wide Web ist eine klassische Client-Server-Anwendung, bestehend aus Web-Browser als Client und dem Web-Server [KEDBS01]. Webbasierte Anwendungen sind nur uber das Internet oder ein Intranet erreichbar und nur fur klassische Client-Server-Architekturen programmiert [TGWBD05]. Bild 2.8 aus [KEDBS01] zeigt die Client-Server-Architektur des World Wide Web.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.8: Client-Server-Architektur des World Wide Web

In den letzten Jahren sind so genannte Client-Server-Datenbankanwendungen stark in den Mittelpunkt des Interesses geruckt [DPVDB96]. Charakteristisch fur diese Systeme ist, dass eine Funktionsaufteilung zwischen der Anwendung und dem Datenbankserver statt- findet. Bei konventionellen kaufmannischen Anwendungen wird in der Regel angestrebt, datenintensive Zugriffe moglichst unmittelbar auf dem Datenbankserver auszufuhren, um die Kommunikation ubers Netz zu reduzieren. Hier werden Teile des Anwendungspro- gramms auf den Datenbankserver verlagert, z.B. in Form von dort abgelegten Prozeduren, die vom Anwendungsprogramm im Sinne eines entfernten Prozeduraufrufs dort aufgerufen werden.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.9: Client-Server-Architektur des World Wide Web

GroBe komplexe Datenobjekte, welche in technischen bzw. wissenschaftlichen Anwen­dungen vorkommen, werden hingegen auf der Client-Seite bearbeitet [DPVDB96]. Bild 2.9 aus [MURDS03] zeigt speziell das Schema einer Datenbank-Anwendung im World Wide Web.

Grafische Benutzeroberflache

Eine grafische Benutzeroberflache ist nach [FPLDI02] eine mit einer Maus steuerbare und auf grafischen Symbolen beruhende Benutzeroberflache. [ECSID93] definiert die Benut­zeroberflache als das Erscheinungsbild der Anwendungsprogramme und des Rechner- Dialogs auf dem Bildschirm. Laut [WPPCL05] erlaubt die Benutzeroberflache - oder auch Graphical User Interface („GUI“) genannt - dem Anwender, Programme uber grafische Reprasentationen seiner Befehle zu steuern, anstatt handisch Befehle eintragen zu mussen. [ECSID93] schreibt dazu, dass jedes Anwendungsprogramm die Eingabe, die Ausgabe und den jeweiligen Bearbeitungszustand in irgendeiner Form prasentieren und die Eingriffe fur Interaktionen, Auskunfte, Hilfestellungen oder Erklarungen zulassen muss. Die Benutzer­oberflache besitzt Schnittstellen zu den darunter liegenden Schichten im Rechnersystem, also zu den Anwendungsprogrammen, zu Compilern, zu Graphiksystemen und zu den Funktionen des Betriebssystems. Grafische Bedienoberflachen bestehen aus Fenstern, Me­nus, Statuszeilen Schaltflachen, Auswahllisten, Eingabezeilen und Symbolen. Bild 2.10 zeigt die Benutzeroberflache des „SQL Query Analyzer" zur Erstellung, Ausfuhrung und Analyse von SQL-Abfragen.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.10: Benutzeroberflache „SQL Query Analyzer"

Nach [ECSID93] setzt sich die Benutzeroberflache im Wesentlichen aus folgenden drei Teilen zusammen:

- Presentation zur Darstellung der Daten, z.B. in grafischer Form, mit Fenstern oder durch bewegte Bilder
- Interaktion zur Bereitstellung von Dialogfunktionen und Festlegung der Anwei- sungen fur Anwendungsprogramme
- Kontrolle zur Analyse der ein- und ausgehenden Daten, Ausfuhrung der reinen Dialogbefehle oder Aktivierung von Anwendungsprogrammen

Anwendungsgeneratoren

Heutzutage wird nach [WPPCL05] sogar die Programmierung durch grafische Oberflachen erleichtert, die automatisch Routinefunktionen in den Code einfugen. Der Entwurf einer Anwendung mit einer grafischen Benutzeroberflache ist z.B. durch die Programmierspra- chen C, C++, Java, Perl, PHP oder Phyton moglich. Zu diesen Programmiersprachen exis- tieren eine Reihe von Toolkits und Bibliotheken, welche den Entwickler beim Entwurf und bei der Umsetzung der Benutzeroberflache unterstutzen. Ein Toolkit oder auch Toolbox bezeichnet nach [WPPCL05] eine Sammlung von Werkzeugen, wie Bibliotheken, Klassen und Schnittstellen, die eine Vereinfachung und Beschleunigung bei der Programmerstel- lung beinhalten. Ziel eines Toolkits ist es, dem Programmierer das Entwickeln von An- wendungen zu erleichtern, indem Standardfunktionen zur Verfugung gestellt werden.

Eine Anwendung kann im Gesamten mit Hilfe eines Anwendungsgenerators erstellt wer­den. Anwendungsgeneratoren stellen nach [MBREE97] einen auBerst erfolgreichen Ansatz zur Wiederverwendung von Programmteilen bei der Anwendungsentwicklung dar. Sie sind auf einer sehr hohen und abstrakten Ebene bzw. in einer sehr hohen und abstrakten Gene- ratorsprache programmiert. Die spezifische Eingabe wird dann vom Generator in ein aus- fuhrbares Programm einer herkommlichen Programmiersprache transformiert. Ein typi- sches Einsatzgebiet von Anwendungsgeneratoren ist laut [MBREE97] die visuelle Gene- rierung und Spezifikation von Benutzeroberflachen. Zu Werkzeugen der vierten Generati­on, bezogen auf die Entwicklung der Programmiersprachen, werden vor allem Programm- generatoren gezahlt. Um die Software-Erstellung zu vereinfachen und abzukurzen, werden nach [EHGI08] die methodischen Konzepte des Software-Engineerings durch leistungsfa- hige Entwicklungssysteme, sowie eine Reihe von Werkzeugen des Computer Aided Soft­ware Engineering (CASE) unterstutzt. Dazu gehoren zum Beispiel auch Masken- und Pro- gramm-Generatoren. Nach [WPPCL05] wird die Softwareerstellung durch den Einsatz von Programmgeneratoren in groBem MaBe vereinfacht, da sich der Entwickler beim Entwurf einer Applikation nur auf die Funktionsbeschreibung beschrankt, welche durch den Gene­rator dann selbststandig in einen Quellcode ubersetzt wird. Die Anwendungsgeneratoren sind in Bezug auf die Framework-Technik in den Bereich der Applikationsgenerator, wie in Abschnitt 2.2.2 beschrieben, einzuordnen.

2.3 Datenubertragung und Schnittstellen

Im Allgemeinen sind mit Datenubertragung alle Methoden gemeint, die Informationen von einem Sender (Informationsquelle) zu einem Empfanger (Informationssenke) ubermitteln. In Abschnitt 2.3.1 wird dieser Datentransfer genauer beschrieben und das Beispiel des Extract-Transform-Load-Prozesses (ELT) erklart. Schnittstellen besitzen als Abgrenzun- gen zwischen den verschiedenen Bausteinen von Systemen besondere Bedeutung. Uber Schnittstellen arbeiten diese Komponenten zusammen und erzeugen letztlich den Mehr- wert des Gesamtsystems. Sie beinhalten in der Regel den Transfer von Daten oder Steue- rungsinformationen [SGESA08]. Aufgrund der Datenubertragung per Schnittstelle wird in Abschnitt 2.3.2 naher auf die Software- und Datenbankschnittstellen eingegangen und da- nach wird das Beispiel des ODBC-Standards erlautert.

2.3.1 Datenubertragung

Als Datenubertragung oder Datentransfer bezeichnet man nach [ECSID93] die Ubertra- gung digitaler Daten von einem Rechner auf einen anderen, also zum Beispiel von einem Server zu einem Client. AuBerdem ist damit die Datenubermittlung von einem Speicher- medium auf ein anderes beschrieben. Etwas genauer beschreibt [VPPSI06] den Datentrans­fer als die Weitergabe von Daten zwischen zwei Schnittstellen von Anwendungen, die auf Basis vorab definierter Regeln zur Erfullung der Datenanforderungen erfolgt. Der Daten- transfer kann, je nach Integrationsart, zwischen Datensammlungsschnittstellen, Applikati- onsschnittstellen oder Applikations- und Datensammlungsschnittstellen stattfinden. [AMWI04] definiert ein Datenubertragungssystem im einfachsten Fall als zwei Datenstati- onen, die zum Zweck der Datenubertragung miteinander durch ein Ubertragungsmedium bzw. Kommunikationsnetz verbunden sind. Jede Datenstation besteht aus der Datenendein- richtung (DEE) und der Datenubertragungseinrichtung (DUE). Beide Einrichtungen sind uber eine standardisierte Schnittstelle verbunden, bei der die physikalischen und funktio- nellen Eigenschaften durch international Normen festgelegt sind. [PWRN02] teilt die DEE in eine Fernbetriebseinheit und ein Datenendgerat auf und stellt das beschriebene Datenubertragungssystem wie in Bild 2.11 dar.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.11: Datenubertragungssystem

Es gibt beim Datentransfer unterschiedliche Moglichkeiten, die Informationen vom Sender zum Empfanger zu ubermitteln. Zeichen werden entweder bitweise nacheinander uber ei- nen Kanal ubertragen (bitserielle Ubertragung) oder mehrere Bits werden gleichzeitig auf verschiedenen Kanalen transportiert (bitparallele Ubertragung) [AMWI04]. Bei der seriel- len Datenubertragung setzt der Empfanger die Informationen wieder zu groBeren Einheiten zusammen. Bei parallelen Datentransfers werden die Daten nicht zerlegt, sondern auf meh- reren nebeneinander verlaufenden Datenleitungen gleichzeitig gesendet bzw. empfangen. Dies kann somit auf mehreren physischen Leitungen nebeneinander oder uber mehrere logische Kanale zur gleichen Zeit geschehen. Daraus resultiert eine wesentlich hohere Da- tenubertragungsgeschwindigkeit [N SHHM91].

AuBerdem unterscheidet man zwischen der analogen und der digitalen Ubertragung von Daten. Ein analoges Signal kann beliebig viele Zwischenwerte haben, wahrend ein digita- les Signal auf seiner untersten Ebene nur zwei mogliche Zustande (0 oder 1) haben kann und keine Ubergange kennt [ECSID93]. Ein groBer Nachteil bei der analogen Informa- tionsubertragung liegt darin, dass analoge Signale sehr sensibel gegenuber Storungen sind [SBGRK04]. In Computern laufen zahlreiche digitale Datenubertragungen ab. Ein Beispiel ist die Kommunikation zwischen Festplatte und Arbeitsspeicher. Die ersten Tests, Compu­ter bezuglich einer Informationsubertragung zu verbinden, waren direkte Verbindungen mit speziellen Verbindungsprogrammen, welche der heutigen seriellen Schnittstelle oder der parallelen Schnittstelle ahnlich sind. Spater erfolgten die Datentransfers uber Telefon- leitungen mit Modems und einfachen Protokollen. Diese wurden durch bidirektional arbei- tende Protokolle zur gleichzeitigen Ubertragung von Dateien in beide Richtungen ersetzt. Heute wird Datenubertragung meist netzwerkbasiert durchgefuhrt [NHDSU08]. Bei der netzwerkbasierten Datenubertragung existiert eine n:n-Beziehung zwischen den Kommu- nikationspartnern. Es konnen also mehrere Sender bzw. Empfanger zur gleichen Zeit mit- einander Informationen austauschen.

ETL-Prozess

Die Abkurzung ETL steht fur „Extract, Transform, Load“ und bezeichnet in der Informatik einen speziellen Prozess der Datenubertragung. Hierbei werden Daten aus mehreren Da- tenquellen mit ggf. unterschiedlichen Strukturen in einer Zieldatenbank vereinigt. Dieser Vorgang wird laut [OLIT09] in den folgenden drei Schritten vollzogen:

- Extraktion (Extract): Die Daten werden aus einem oder mehreren Quelldaten- banken bzw. Quellsystemen in das ETL-System geladen.
- Transformation (Transform): Die Daten werden im ETL-System umgewandelt. Dabei kann es sich sowohl um technische Umwandlungen, wie beispielsweise der Anderung der Datentypen, aber auch um fachliche Umwandlungen, z.B. von Berechnungen und Aggregationen, handeln.
- Laden (Load): Die Daten werden aus dem ETL-System in die Zieldatenbank bzw. in das Data Warehouse geladen.

In modernen ETL-Prozessen unterscheidet [OLIT09] noch weitere Aufgaben, die in einem ETL-Prozess wahrgenommen werden:

- Data Cleaning (Datenbereinigung) und Qualitatssicherung
- Historisierung
- Vor-Aggregation und Stammdaten-Management
- Benachrichtigung per Email
- Logging und Anderungsverfolgung

Bekannt ist der Prozess vor allem durch seine Bedeutung beim Betrieb eines Data- Warehouses. Hier werden groBe Datenmengen aus mehreren operationalen Datenbanken zusammengefasst, um dann in das Data-Warehouse gespeichert zu werden. Die operationa- len Datenbanken sind diejenigen, die im standigen Routinebetrieb genutzt und gepflegt werden. Der Begriff Data-Warehouse ist nach [IBDW05] als themenorientierte, vereinheit- lichte, bestandige, zeitraumbezogene Sammlung von Daten zur Unterstutzung von Ma- nagemententscheidungen definiert.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.12: ETL-Prozess im Uberblick

Den ETL-Prozess in Verbindung mit dem Data Warehouse zeigt das Bild 2.12 aus [O- RETL09].

Die nachstehende detaillierte Definition der Begriffe Extraktion, Transformation und La­den findet sich in [SRHDW01].

Bei der Extraktion erfolgt die Selektion der Basisdaten in eine sog. Staging Area. Die tem- porare Zwischenspeicherung ist notwendig, um Rohdaten durch die Transformation anzu- passen, ehe sie durch den Ladevorgang ins Data Warehouse gelangen. Die Quellen der Extraktion konnen aus verschiedenen Informationssystemen mit verschiedenen Datenfor- maten und -strukturen bestehen. Um das Data-Warehouse mit aktuellen Daten zu versor- gen, findet die Extraktion regelmaBig in den Ruhezeiten des Quellsystems statt. Dies kann nach [SSISPM08] synchron mit der Aktualisierung der Quellen oder asynchron geschehen. Die asynchrone Extraktion erfolgt periodisch, ereignisgesteuert oder anfragegesteuert:

- periodisch: Die Quelle erzeugt in regelmaBigen Abstanden Auszuge ihrer Da- ten, die regelmaBig abgefragt werden
- ereignisgesteuert: Die Quelle erzeugt bei bestimmten Ereignissen - beispiels- weise nach einer bestimmten Anzahl von Anderungen - einen Auszug
- anfragegesteuert: Die Quelle stellt Auszuge erst auf Anfrage bereit

Die Transformation beschreibt laut [SSISPM08] die Anpassung der extrahierten heteroge- nen Daten an das vorgegebene Daten-Schema des Data-Warehouse-Systems. Die Daten werden dabei von syntaktischen und semantischen Mangeln bereinigt oder bezuglich der verschiedenen Datentypen vereinheitlicht. AuBerdem ist es moglich sie im Transformati- onsschritt hinsichtlich ihres Informationsgehaltes zu verdichten oder anzureichern.

Beim Laden werden, wie in [SRHDW01] beschrieben, die Daten von den ETL- Werkzeugen an das Data-Warehouse ubermittelt. Hierzu zahlen sowohl der erstmalige Einladungsvorgang bei der Inbetriebnahme, als auch die fortlaufende Aktualisierung.

Das ETL-Verfahren lasst sich als allgemeiner Prozess der Informationsintegration auch auf andere Datenbanken ubertragen. Grundsatzlich kann der ETL-Prozess durch selbsterstellte Programme in einer beliebigen Programmiersprache umgesetzt werden. Unternehmen nut- zen aber immer mehr bestehende ETL-Programmsysteme von Drittherstellern. Nach [SRHDW01] existieren inzwischen eine Vielzahl von ETL-Werkzeugen auf dem Markt. Grund dafur war die Erkenntnis, dass auch sehr unternehmensindividuelle ETL-Prozesse und -Probleme nicht zwangslaufig durch Eigenentwicklungen realisiert bzw. gelost werden mussen. Die Standardwerkzeuge unterstutzen den Zugriff auf die gangigen Datenbanksys- teme, sowie ERP- und Dateisysteme. Sie werden unterstutzt durch geeignete Transformati- onen, Methoden und Verfahren wie Visualisierung des Datenflusses, Fehlerbehandlung und Scheduling.

SSIS

SQL Server Integration Services, kurz SSIS, ist ein ETL-Serverprodukt und in Microsoft SQL Server 2005 und 2008 in den Versionen „Standard“, „Professional“ und „Enterprise“ integriert. Es besteht aus einem Windows-Systemdienst, einer Verwaltungskonsole und einem Entwicklerprodukt, dem SQL Server Business Intelligence Development Studio. SSIS ist der Nachfolger der Data Transformation Services [MSQLS09].

Data Transformation Services - kurz DTS - ist eine Sammlung von Paketen, Komponenten und Hilfsprogrammen, die es erlaubt, ETL-Prozesse beim Import in oder Export aus einer Datenbank zu automatisieren. DTS sind in den Microsoft SQL-Server integriert, konnen aber ebenso mit anderen Datenbanken unabhangig genutzt werden. Nach [LFMSS01] las­sen sich Daten mit DTS aus heterogenen Quellen wie OLE DB, ODBC oder Textdateien laden und in eine beliebige, unterstutzte Datenbank transformieren. Zusatzlich konnen die- se Schritte regelmaBig uber einen Zeitplan ausgefuhrt werden.

2.3.2 Schnittstellen

Unter einer Schnittstelle versteht man allgemein den Punkt, an dem eine Verbindung zwi- schen zwei Elementen hergestellt wird, so dass eine Zusammenarbeit der beiden Elemente moglich wird.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.13: Schnittstellenubersicht

Eine Schnittstelle ist ein definierter Ubergang zwischen Datenubertragungseinrichtungen, Hardwarekomponenten, logischen Softwareeinheiten oder zwischen Menschen und Com- putern [OLIT09]. Bild 2.13 aus [ECSID93] zeigt verschiedene Schnittstellen.

Softwareschnittstellen

Eine Softwareschnittstelle definiert laut [PWRN02] die Zusammenarbeit zwischen Pro- grammen und in sich abgeschlossenen Programmteilen, sogenannte Modulen. Hierzu wird nach [ECSID93] folgendes formuliert:

- die vom Modul auszufuhrenden Aufgaben
- die erforderlichen Attribute
- die bereitgestellten Funktionen einschlieBlich ihrer Parameter
- die Zugriffmoglichkeiten auf Daten
- die Beziehung zwischen den Daten

Die Schnittstelle eines Moduls enthalt alle von auBen sichtbaren Informationen uber das Modul. Die Spezifikation solcher Schnittstellen ermoglicht beim Software-Entwurf die unabhangige Implementierung von Programmeinheiten, sie erleichtert die Benutzung und die Fehlersuche, und sie ist Voraussetzung fur die Wartung und Aktualisierung von Pro- grammsystemen [ECSID93]. Zugleich umfasst eine Software-Schnittstelle Vereinbarun- gen, sogenannte Protokolle, uber die Art und Weise wie Informationen ausgetauscht wer­den [LREIDI03]. Es werden bei Software-Schnittstellen die Schnittstellen zur Verstandi- gung mit anderen Prozessen und die zur Verbindung einzelner Softwarekomponenten (Module) eines Programms bzw. programmubergreifende Schnittstellen unterschieden.

Mit Interprozesskommunikation (IPC) wird die Kommunikation zwischen verschiedenen Programmen auf dem gleichen oder einem anderen Computer verstanden [OANPS03]. Der Client-Server ist ein Mechanismus zur Interprozesskommunikation, also ein abgestimmtes Verfahren, mit dem Informationen und Daten zwischen zwei Kommunikationspartnern - Client und Server - ausgetauscht werden konnen. Die Neuheit besteht darin, Aufgaben und Funktionen, die bisher immer nur gesamtheitlich innerhalb eines Systems abgearbeitet wurden, in getrennt ausfuhrbare Komponenten zu zerlegen [OANPS03]. Beispiele fur sol- che Kommunikationsschnittstellen uber ein Netzwerk sind ODBC und JDBC. Auch die bekannten Netzwerkprotokolle wie TCP oder HTTP werden als IPC-Schnittstellen ver­standen. Die Schnittstelle fur Programmkomponenten ist eine formale Definition welche Funktionalitat verfugbar ist und wie diese genutzt wird. Das hat den Nutzen, dass Pogrammteile mit der gleichen Schnittstelle austauschbar sind. Solche Schnittstellen die- nen der Modularisierung einer Softwarearchitektur. Beispiele fur Software-Schnittstellen sind etwa "Open Database Connectivity" (ODBC), "Common Gateway Interface" (CGI) oder "Common Application Programm Interface" (CAPI).

Datenbankschnittstellen

Eine Datenbankschnittstelle ist eine spezielle Software-Schnittstelle, die den Zugriff auf und den Datenaustausch mit einer Datenbank regelt, d. h. die Kommunikation zwischen einer Softwareapplikation und der Datenbank ermoglicht. Durch diese standardisierten Schnittstellen ist der Anwendungsprogrammierer von den spezifischen Erfordernissen ein- zelner Datenbanksysteme losgelost. Die Anforderungen zur Abfrage und zur Anderung von Daten werden von der Anwendung an die aus Anwendungssicht immer gleiche Schnittstelle ubergeben. Die Schnittstelle ubersetzt diese, z. B. durch Treiber, auf die spe­zielle Syntax des jeweils angesprochenen Datenbanksystems [UPLEX09]. Um Anwen- dungssysteme, die auf Datenbanken zugreifen, unabhangig von dem jeweiligen Daten- bankverwaltungssystem entwickeln und damit portabel gestalten zu konnen, wurde bereits Mitte der 1970er Jahre die kompatible Datenbankschnittstelle definiert. Im Prinzip handelt es sich dabei um eine Zwischenanwendung, die als Ubersetzungsprogramm (Treiber) zwi­schen der jeweiligen Datenbank und dem Anwendungsprogramm liegt [SHEWI05]. Bild 2.14 aus [SEDBS00] zeigt schematisch die Zugriffe auf eine Datenbank per Datenbank- schnittstelle.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.14: Schematischer Zugriff auf eine Datenbank

Hier sind haufig eingesetzte Datenbankschnittstellen JDBC, ADO.Net, IDAPI oder die im folgenden Abschnitt naher beschriebene ODBC-Schnittstelle.

ODBC

ODBC ist die Abkurzung fur "Open Database Connectivity", was als „offene Datenbank- verbindung“ in die deutsche Sprache ubersetzt werden kann. [OLIT09] beschreibt ODBC als eine von Microsoft im Jahre 1992 entwickelte Schnittstelle fur den Zugriff von Windows-Anwendungen auf Datenbanken beliebiger Hersteller uber ein Computernetz. [OLIT09] definiert ODBC als eine standardisierte Anwendungs-programmierschnittstelle, uber die ein Anwendungsprogramm auf Datenquellen zugreifen kann, fur die es ODBC- kompatible Treiber gibt. Zum Zugriff auf eine bestimmte Datenquelle ruft eine Anwen- dung den ODBC-Treiber auf. Dieser Treiber verwendet die "Structured Query Language" (SQL) als Abfragesprache fur den Datenbankzugriff und ist im zentralen Treibermanage- ment eingebunden. Die ODBC-Architektur ist in Bild 2.15 nach [HJPSPP01] grafisch dar- gestellt:

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.15: ODBC-Architektur

Der ODBC-Standard umfasst nach [HJPSPP01] eine Bibliothek mit ODBC- Funktionsaufrufen, um eine Verbindung zur Datenquelle herzustellen und SQL- Anweisungen auszufuhren und deren Ergebnisse abzurufen. AuBerdem enthalt die Biblio­thek eine standardisierte Darstellungsweise fur Datentypen und Fehler-Codes.

ODBC bietet eine Programmierschnittstelle (API), die es dem Programmierer erlaubt, sei­ne Anwendung unabhangig vom verwendeten Datenbankmanagementsystem zu entwi- ckeln. Dies setzt voraus, dass fur das DBMS ein ODBC-Treiber existiert. Bei der Nutzung von ODBC-Anwendungen muss der Anwender nicht darauf achten, auf welchen Rechnern und in welchen Verzeichnissen die Daten gespeichert sind, auf die er zugreifen mochte. Auch das Format, in denen die betreffenden Daten gespeichert sind, spielt fur den Client keine Rolle. Die Daten behalten ihr ursprungliches Format, auch wenn sie vom Client aus bearbeitet werden. Ein weiterer Vorteil laut [KJPHP05] ist, dass man die zugrunde liegen- de Datenbank austauschen kann, ohne dass Anderungen am Programm notwendig sind, falls die Applikation auf ODBC basiert.

Fur [KMMS05] ist die Open Database Connectivity ein vor allem unter Windows popula- rer Mechanismus zum einheitlichen Zugriff auf die verschiedensten Datenbanksysteme. Seit Windows 2000 ist ODBC als Bestandteil der Microsoft Data Access Components in- tegraler Bestandteil des Betriebssystems. Fur fruhere Windowsversionen kann es nachin- stalliert werden. Doch nach [HJPSPP01] hat sich ODBC auch uber die Windows-Welt hinaus zu einem weltweiten, systemubergreifenden Standard entwickelt, und zu jeder na- menhaften Datenbank existiert in der Regel mindestens ein entsprechender Treiber.

2.4 Betriebliche Anwendungssoftware

Nach Definition in [LWWI06] unterstutzt die betriebliche Anwendungssoftware den Be- nutzer bei der Losung seiner betrieblichen Aufgabenstellungen. Hierzu zahlen zum Bei- spiel Warenwirtschaftssysteme, Software fur den Produktions- und Logistikbereich und Enterprise-Ressource-Planing-Systeme. Dieses Kapitel gibt zunachst eine allgemeine Be- schreibung der betrieblichen Anwendungssoftware und beschreibt diese danach genauer am Beispiel der ERP-Syteme.

2.4.1 Anwendungssoftware

Laut [AMWI04] ist die Anwendungssoftware, auch Anwendungsprogramm genannt, der Kern eines Anwendungssoftware-Systems. Dieses System enthalt neben dem Programm- code spezielle Zusatzleistungen wie Dokumentation und Schulung. AuBerdem bietet dieses Paket eine Installationshilfe, die Wartung und den Support an.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.16: Begriffsabgrenzungen Anwendungssoftware

Das Anwendungssoftware-System ist wiederum Teil eines Standard-Anwendungssoftware- Pakets [BAHESM98], welches als Produkt vom Software-Hersteller an ein Unternehmen verkauft wird. Dieses Standard-Anwendungssoftware-System beinhaltet den vereinbarten Preis, definiert die generelle Einsatzfahigkeit und berucksichtigt Vorkehrungen zur Reduk­tion des Anpassungsaufwandes. Die grafische Darstellung (siehe Bild 2.16) dieser Be­griffsabgrenzungen befindet sich in [AMWI04].

Anwendungsprogramme konnen lokal auf einem Arbeitsplatzrechner installiert sein und werden dann Desktop-Anwendungen genannt. AuBerdem gibt es die Moglichkeit, uber ein Anwendungsprogramm von einem Arbeitsplatzrechner - dem Client - auf einen Server zuzugreifen. Dies bezeichnet man dann als Client-Server- bzw. Webanwendung. Wie in [FSVWI06] zu lesen ist, sind dabei die wesentlichen Komponenten der Anwendungskern mit der fachlichen Logik, die Benutzerschnittstelle, sowie die Datenverwaltung.

Expertensystem

Das Expertensystem, auch XPS abgekurzt, ist nach [ECSID93] ein Programmsystem, das Wissen uber ein spezielles Gebiet speichert und sammelt, aus dem Wissen Schlussfolge- rungen zieht und zu konkreten Problemen des Gebiets Losungen anbietet. Expertensysteme sind nach [BKMWS08] spezielle wissensbasierte Systeme, bei denen das Wissen letztend- lich vom Experten stammt. [BFDWM06] teilt die XPS in deterministische und stochasti- sche Expertensysteme auf. Deterministische Probleme konnen mit Hilfe einer Menge von Regeln beschrieben werden, die definierte Objekte zueinander in Beziehung setzen. Bei den stochastischen Systemen wird die Wahrscheinlichkeitsverteilung der vorhandenen Va- riablen mit in die Berechnung des Ergebnisses einbezogen. Nach [ECSID93] sind Exper- tensysteme in der Lage:

- groBe Mengen diffusen, vagen und unformalisierten Wissens in problembezo- gener Weise zu reprasentieren
- aus vorhandenem Wissen auf logischem und/oder heuristischem Wege Schluss- folgerungen zu ziehen und neues Wissen zu gewinnen
- zu konkreten vorgegebenen Problemen im Dialog mit dem Benutzer Losungen zu finden und den Losungsweg zu erlautern

Es gibt viele unterschiedliche Anwendungsgebiete von Expertensystemen, welche in Bild 2.17 aus [HMHR07] allgemein dargestellt sind.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.17: Anwendungsgebiete Expertensysteme

Es liegen nach [SAEBW90] auch fur ein breites betriebswirtschaftliches Spektrum An- wendungen fur Expertensysteme vor. Diese werden in den bereichen Marketing, Beschaf- fung, Qualitatswesen, Produktionsplanung und Finanzierung eingesetzt.

Betriebliche Anwendungssoftware

Die betriebliche Anwendungssoftware unterstutzt entweder einen oder mehrere betriebs- wirtschaftliche Anwendungsbereiche. Falls die Software mehrere betriebswirtschaftliche Funktionen abdeckt, spricht man von integrierten Anwendungssystemen oder Enterprise- Resource-Planing-Systemen, auch ERP genannt [RPIH06].

[AMWI04] teilt die betrieblichen Anwendungsprogramme bezuglich ihrer zwei unter- schiedlichen Aufgabenstellungen auf. Bei den operativen Aufgaben soll die Software hel- fen, Massen- und Routinearbeiten zu automatisieren oder zumindest zu vereinfachen. Bei der Anwendungssoftware zur Unterstutzung analytischer Aufgaben stehen Auswahl- und Aggregationsmoglichkeiten im Vordergrund. Es werden auf Basis der vorhandenen Da- tenmenge gezielte Auswertungen und Grafiken erstellt. Der Benutzer fuhrt mit Hilfe der Software Analysen durch, um seine eigenen Entscheidungen abzusichern. Eine Untertei- lung der betrieblichen Anwendungssoftware bzgl. der Aufgabenkategorien und ihrer Ein- satzbereiche zeigt das Bild 2.18 aus [AMWI04].

Anwendungssoftware ist nur teilweise Standardsoftware. Zu einem groBen Teil werden auf den jeweiligen Anwendungsfall zugeschnittene Branchenlosungen oder Individuallosungen eingesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.18: Unterteilung der betrieblichen Anwendungssoftware

Im Bereich der strategischen und wirtschaftlichen Anwendungssoftware eines Unterneh- mens werden integrierte Systeme, wie die im folgenden Abschnitt beschriebenen ERP- Systeme, eingesetzt [CBSAD08].

2.4.2 ERP-Systeme

Die Abkurzung ERP steht fur „Enterprise Resource Planning“, was ubersetzt „Unterneh- mensressourcenplanung“ bedeutet. Per Definition aus [CBSAD08] umfasst das ERP- Konzept eine Menge von Prozessen, Methoden und Techniken zur effektiven Planung und Steuerung aller Ressourcen, die zur Beschaffung, zur Herstellung, zum Vertrieb und zur Abrechnung von Kundenauftragen in einem Produktions-, Handels- und Dienstleistungs- unternehmen notig sind. Der Begriff Ressource wird in [GNES04] als naturliche oder ge- sellschaftliche Quelle der Grundlagen der Reproduktion verstanden. Dort wird weiter be- schrieben, dass man es auch als Kraft, Quelle, Hilfsmittel, Geldmittel oder Reserve verste- hen kann. Das ERP-System ist nach [AMWI04] eine Erweiterung des traditionell in In- dustriebetrieben eingesetzten Produktionsplanungs- und Steuerungssystems. Diese, zu- meist als PPS-Systeme bezeichneten Softwarepakete, unterstutzen den gesamten Prozess der Planung und Ausfuhrung von Fertigungsauftragen. Hierzu gehoren die Angebotsbear- beitung, Beschaffung, Lagerhaltung, Material- und Ressourcenplanung, Fertigungsuberwa- chung und Auslieferung. Durch betriebswirtschaftliche Erweiterungen, besonders in den Bereichen Vertrieb, Rechnungswesen und Personalwirtschaft, entwickelten sich die PPS- Systeme zu den ERP-Systemen weiter.

Wie schon im vorangegangenen Abschnitt erklart, handelt es sich dabei um ein integriertes System, das Funktionen aus mehreren Unternehmensbereichen abdeckt. Ein integriertes System lasst sich nach [HGBES07] durch folgende Merkmale charakterisieren:

- Aufgaben aus mehreren Anwendungsbereichen werden vom System abgedeckt
- die Systemfunktionalitaten fur die unterschiedlichen Anwendungsbereiche sind zu einem Gesamtsystem verknupft
- es erfolgt nur eine moglichst fruhe Erfassung von Daten, die dann im System gespeichert und intern weitergeleitet werden

[HGBES07] teilt die ERP-Systeme, wie in Bild 2.19 zu sehen, in die folgenden vier klassi- schen Anwendungsbereiche und die bereichsubergreifenden Funktionen auf.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.19: Anwendungsbereiche ERP-System

Die ERP-Systeme sind meist bezuglich dieser Funktionalitaten modular aufgebaut, damit der Kunde die Moglichkeit hat, nur fur ihn relevante Softwareteile zu erwerben. Die GroBe des Unternehmens bestimmt die Anforderungen an die dargestellten Bereiche. Ein GroBun- ternehmen muss zum Beispiel uber eine ERP-Losung auch seine Konzernstrukturen abbil- den konnen, gegebenenfalls Tochterunternehmen direkt anbinden, und benotigt eine Viel- zahl von komplexen, betriebswirtschaftlichen Funktionen. ERP-Systeme sollen demnach weitgehend alle Geschaftsprozesse abbilden. Eine durchgehende Integration und Abkehr von Insellosungen fuhren zu einem zentralisierten System, in dem Ressourcen unterneh- mensweit verwaltet werden konnen [HGBES07].

Im Allgemeinen unterscheiden sich die verschiedenen ERP-Systeme hauptsachlich in ihrer fachlichen Ausrichtung (Zielbranche), der Skalierbarkeit auf unterschiedliche Unterneh- mensgroBen (Anzahl benotigter Benutzer oder Unternehmensstandorte), dem angebotenen Funktionsumfang und den zum Einsatz kommenden Technologien (Datenbanken, Pro- grammiersprachen, Schichtenarchitekturen, unterstutzten Betriebssystemen). Es werden hierfur unterschiedliche Datenbanksysteme genutzt. Das Spektrum reicht dabei von Micro­soft Access uber PostgreSQL, MySQL bis hin zu DB2, Oracle oder Microsoft SQL Server. [GNES04] sieht dabei die wesentlichen Vorteile der ERP-Systeme in einer Automatisie- rung von Ablaufen und in einer Standardisierung von Prozessen. Fur den Einsatz der Stan- dardisierung lassen sich bei [GNES04] folgende Argumente finden:

- sie erhoht die Produktivitat, indem eine Rationalisierung der Aktivitaten besteht und vorhandene Sachmittel okonomisch eingesetzt werden
- Standardisierung erleichtert die Koordination, da Doppelverarbeitungen ver- mieden werden und das organisatorische Konfliktpotential durch das Festlegen klarer Kompetenzen reduziert wird
- sie entlastet die Fuhrungskrafte, da die Steuerung der Prozesse automatisiert wird und das Setzen von Schwerpunkten moglich ist
- Standardisierung erhoht die Stabilitat des organisatorischen Systems, da die einzelnen Aktivitatsfolgen von den beteiligten Personen weitgehend unabhan- gig werden

Ein weiterer Vorteil, der durch die Nutzung einer ERP-Software entsteht, ist die Reduzie- rung von Schnittstellenproblemen und Sicherheitsrisiken. Dies liegt darin begrundet, dass ERP-Systeme mit einer in sich schlussigen Software viele Aufgaben losen, und das Auf- kommen von doppelten Daten minimiert wird. Alle Daten sind aufgrund einer gemeinsa- men Datenbasis immer auf dem neusten Stand, und Mehrfacheingaben sind unnotig. Die Funktionalitaten und ihre einheitliche Datenbasis sieht man im Schaubild 2.20 aus [AM- WI04].

Abbildung in dieser Leseprobe nicht enthalten

Bild 2.20: ERP-Konzept

Aber laut [MMEA05] ist der Einsatz von ERP-Software nicht nur mit Vorteilen fur ein Unternehmen verbunden, sondern auch mit finanziellen, technischen und organisatorischen Aufwendungen und Risiken. Die verschiedenen Einsatzzwecke, Implementierungszeit- punkte und Automatisierungsgrade von Ablaufen fuhren durch den Einsatz von Informati- onssystemen haufig zu einem komplizierten Gesamtbild. Trotz der Anwendung von Stan- dardsoftware verursachen Beratung und Parametrisierung groBere Kosten. Neben komple- xen, stark integrierten und fur viele Branchen anpassbaren, universellen ERP-Systemen, stehen den kleinen und mittelstandischen Unternehmen auch branchenspezifische ERP- Systeme mit reduzierter Komplexitat zur Verfugung.

Nach [TAEESA03] ist das popularste ERP-Softwarepaket „SAP Version R/3“, welches 1992 vom deutschen Unternehmen SAP entwickelt wurde. Es stellt eine Weiterentwick- lung des von IBM produzierten PPS-Systems „COPICS“ dar, bei welchem die betriebs- wirtschaftlichen Gesichtspunkte berucksichtigt wurden.

2.5 Preisindexentwicklungen

Laut [HHKTEV92] sind Preisindizes bestimmte Funktionen, die die Preise und deren Ver- anderungen aggregieren und zu einer Messzahl zusammenfassen, welche eine Aussage uber die Preisentwicklung als Ganzes zulasst. Das folgende Kapitel geht naher auf diese Preisindexbildung und ihre Entwicklung ein. Es werden die popularsten Indexberech- nungstheorien dargestellt und die Indexentwicklung am Beispiel der Borse erlautert.

2.5.1 Preisindex

Ein Preisindex unterstutzt im Allgemeinen die Darstellung und Betrachtung der Preisent­wicklung ganzer Gutergruppen, welche man auch als "Warenkorb" bezeichnet. Von amtli- chen Stellen, z.B. vom Statistischen Bundesamt, wird diese Messzahl errechnet, um eine Auskunft uber die durchschnittlichen Preisveranderungen in verschiedenen Bereichen der Wirtschaft zu geben. Wie in [BLFAZ09] beispielsweise zu lesen ist, gibt der Preisindex fur die Lebenshaltung (Index der Verbraucherpreise) die Entwicklung der Preise fur Guter und Leistungen des taglichen Bedarfs wieder. Errechnet wird er anhand eines Warenkorbs, der neben Waren auch Dienstleistungen und Nutzungen umfasst, fur eine Gruppe von Haushal- ten, die nach Personenzahl und sozialer Stellung reprasentativ fur die Gesamtbevolkerung stehen. Der Anteil eines Gutes an einem Warenkorb bestimmt dabei sein "Gewicht" in der Durchschnittsberechnung.

Bei einem zeitlichen Preisindex werden zunachst zwei Zeitpunkte bestimmt, zu denen der Preis des Warenkorbes ermittelt werden soll. Der erste Zeitpunkt ist das Basisjahr oder auch Basisperiode genannt, welcher den Startpunkt der Betrachtung angibt, auf den sich die Untersuchung bezieht. Der zweite Termin ist das Berichtsjahr, also das aktuelle Jahr bzw. der Endpunkt der Betrachtung. Bei der Bestimmung von Veranderungen eines Preis­index wird das Basisjahr gleich 100% gesetzt. Es wird immer so gewahlt, dass es mog- lichst gut im aktuellen Trend der Entwicklung liegt. Nach der Bestimmung des Zeitraums werden die Preisindizes durch eine Formel zur Berechnung der durchschnittlichen Preis­veranderungen ermittelt, die auf der Basis von verschiedenen theoretischen Ansatzen und grundlegenden Voraussetzungen aufgestellt ist. Die zwei am weitesten verbreiteten Kon- zepte zur Bildung von Preisindizes sind nach Aussage von [BBKSTA08] die von Laspey- res und Paasche aufgestellten Indextheorien. Der Preis eines Warenkorbes ist dabei die Summe der einzelnen Guterpreise, die er beinhaltet. Diese werden mit den jeweiligen Ver- brauchsmengen der Guter multipliziert, d.h. mit ihrem Anteil an den Gesamtausgaben des Haushaltes gewichtet. Aus welchem Jahr diese Gewichtungen stammen, unterscheidet den Laspeyres-Index von dem Paasche-Index, worauf in den folgenden Abschnitten naher ein- gegangen wird.

Die Aussagekraft eines Preisindex wird durch mehrere Unwagbarkeiten relativiert, welche hier am Beispiel des Verbraucherpreisindex dargestellt werden:

- es wird nicht nach den einzelnen sozialen Zuordnungen der Bevolkerung diffe- renziert, die unterschiedlich stark von Preisniveauveranderungen betroffen sein konnen
- die Bildung unterschiedlicher Indizes fur bestimmte Haushalte erhoht die Ge- nauigkeit der Aussage. Aber auch diese Indizes stellen nur optimierte Durch- schnittswerte dar, die nicht den tatsachlichen personlichen Konsumgewohnhei- ten einzelner Haushalte entsprechen mussen
- die Definition des verwendeten Warenkorbes andert sich bis zur Festsetzung ei- nes neuen Basisjahres aus Grunden der Vergleichbarkeit nicht. Wohingegen sich die tatsachliche Verbrauchsstruktur im Zeitverlauf entwickeln kann
- keine Berucksichtigung der relativen Anderung, die sich bei der Angebots- bzw. Nachfragemenge ergibt, wenn eine relative Preisanderung eintritt
- die Berechnung der Preisindizes kann nur fur Erzeugnisse durchgefuhrt werden, deren preisbestimmende Merkmale sich nicht verandern

2.5.2 Laspeyres-Index

Nach [KRAWSV99] geht die weltweit popularste Indexformel zuruck auf Dr. Ernst Louis Etienne Laspeyres, Professor fur Volkswirtschaftslehre an der Universitat zu Dorpat, spater GieBen, der sie vor rund 120 Jahren zum ersten Mal auf Guterpreise im Hamburger Hafen angewendet hat.

Bei der Berechnung des Preisindex nach Laspeyres stammen die berucksichtigten Ver- brauchsmengen bzw. Gewichte aus dem Basisjahr. Der Index ermittelt den Preis eines Wa­renkorbes in der Zusammensetzung des Basisjahres und den Preis der Warenkorbartikel des Berichtsjahres.

Dieser Vorgang wird durch den nachstehenden Quotienten ausgedruckt:

Abbildung in dieser Leseprobe nicht enthalten

Diese Formel bildet ab, was der Warenkorb (Mengen des Basisjahres) heute kostet (Preise des Berichtsjahres) und was fur den gleichen Warenkorb (Mengen des Basisjahres) im Ba­sisjahr bezahlt werden musste (Preise des Basisjahres). Dieses Vorgehen soll am folgenden Beispiel deutlich gemacht werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Beispiel Warenkorb

Dieser exemplarische Warenkorb besteht aus vier Artikeln, d.h. es werden typischerweise nur diese vier Guter in den angegebenen Mengen zu den angegebenen Preisen von den Konsumenten gekauft. Da sich die Gewohnheiten der Konsumenten im Laufe der Jahre geandert haben, mussten die Verbrauchsmengen des Warenkorbes von 2002 zu 2009 ange- passt werden.

[...]

• Universidad: University of Siegen (Fachbereich 12 - Fachgruppe „Technische Informatik“)
• Calificación: 1,7
• Autor: Thomas Schürholz (Autor)
• Año de publicación: 2010
• Páginas: 164
• No. de catálogo: V461160
• ISBN (Ebook): 9783668916982
• ISBN (Libro): 9783668916999
• Idioma: Alemán
• Etiqueta: Einkaufspreisindex, Framework, Client-Server, Intrexx, SQL, Webbasiert, Lastenheft, Pflichtenheft, Einkaufspreis, Index, Laspeyres, Paasche, Datenbank, DBMS