Einsatz eines XML - Datenbank basierten Informationssystems zur Unterstützung der Öffentlichkeitsarbeit eines Unternehmens im Krisenfall
- Art: Diplomarbeit
- Autor: Ralph Bühr
- Abgabedatum: Juni 2000
- Umfang: 131 Seiten
- Dateigröße: 5,0 MB
- Note: 1,0
- Institution / Hochschule: Fachhochschule Darmstadt Deutschland
- ISBN (eBook): 978-3-8324-2739-9
-
ISBN (Paperback) :
978-3-8324-2739-9 P - ISBN (CD) :978-3-8324-2739-9 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Bühr, Ralph Juni 2000: Einsatz eines XML - Datenbank basierten Informationssystems zur Unterstützung der Öffentlichkeitsarbeit eines Unternehmens im Krisenfall, Hamburg: Diplomica Verlag
- Schlagworte: Öffentlichkeitsarbeit, Datenbank, Krise, Informationssystem, PR
In den Warenkorb
48,00 €
Diplomarbeit von Ralph Bühr
Einleitung:
Ziel der Diplomarbeit ist es, für die Firma Fujitsu Microelectronics Europe GmbH ein informationstechnisches Konzept zur Unterstützung der Krisen-PR-Arbeit zu entwickeln, das langfristig die Effizienz der Krisen-PR erhöhen kann und die Mitarbeiter dabei entlastet. Hierbei wird auf konzeptionelle, gestalterische, personelle und technische Aspekte eingegangen und eine mögliche Vorgehensweise erarbeitet.
Gang der Untersuchung:
Zunächst wird in Kapitel 3 auf theoretische Grundlagen und Begriffe zu Krisen und Informationssystemen sowie XML im allgemeinen eingegangen.
Anschließend - in Kapitel 4 - werden die konzeptionellen, gestalterischen, personellen und technischen Anforderungen an das Informationssystem ermittelt. Darauf folgt der Entwurf der technischen Realisierung in Kapitel 5, des weiteren wird der gewählte Realisierungsansatz motiviert und beschrieben. Das vorletzte Kapitel schließt mit Überlegungen zur Kostenschätzung und Nutzenbewertung des zu entwickelnden Systems ab, woran sich im letzten Kapitel Gedanken zur zukünftigen Entwicklung von Informationssystemen zur Unterstützung von Krisen-PR und von Informationssystemen im allgemeinen anschließen.
Den Schwerpunkt der Diplomarbeit stellen die Anforderungsanalyse in Kapitel 4 und der Entwurf der technischen Realisierung in Kapitel 5 dar.
Inhaltsverzeichnis:
| ERKLÄRUNG | 2 | |
| INHALTSVERZEICHNIS | 3 | |
| 1. | EINLEITUNG | 6 |
| 2. | VORÜBERLEGUNGEN | 8 |
| 2.1 | ABGRENZUNG DES FORSCHUNGSPROBLEMS | 8 |
| 2.2 | ÜBERSICHT | 8 |
| 3. | GRUNDLAGEN | 9 |
| 3.1 | KRISE | 9 |
| 3.1.1 | Krisenphasen | 11 |
| 3.1.2 | Krisenpläne | 11 |
| 3.1.3 | Kosten | 12 |
| 3.1.4 | Chancen | 12 |
| 3.2 | PR | 13 |
| 3.3 | INFORMATION UND KOMMUNIKATION | 16 |
| 3.3.1 | Information | 16 |
| 3.3.2 | Informationssysteme | 16 |
| 3.3.3 | Auf Internet-Technologie basierte Informationssysteme | 19 |
| 3.3.4 | Kommunikationssysteme | 20 |
| 3.3.5 | Informations- und Kommunikationstechnologie (IKT) | 20 |
| 3.3.6 | Informationsmanagement | 21 |
| 3.3.7 | Informationslogistik | 22 |
| 3.4 | DATENBANKEN | 22 |
| 3.4.1 | Relationale Datenbanken | 23 |
| 3.4.2 | XML-Datenbanken | 24 |
| 3.4.3 | Lotus Notes - „Groupware“ | 25 |
| 3.5 | PR-KRISENMANAGEMENT | 26 |
| 3.5.1 | PR-Krisenmanagement-Systeme | 27 |
| 3.5.2 | Datenbankbasierte Krisen-PR Systeme | 27 |
| 3.6 | XML | 28 |
| 3.6.1 | Auszeichnungssprachen | 28 |
| 3.6.2 | Die Document Type Definition (DTD) | 30 |
| 3.6.3 | Anforderungen an XML-Dokumente | 31 |
| 3.6.4 | Document Object Model (DOM) | 32 |
| 3.6.5 | Style Sheets | 33 |
| 3.6.6 | Namespaces | 34 |
| 3.6.7 | XML Schema Definition Language (XSDL) | 35 |
| 3.6.8 | XLink / XPointer | 35 |
| 3.6.9 | XPATH | 36 |
| 3.6.10 | Anwendungen für XML: EDI, B2B - ECommerce | 36 |
| 3.6.11 | XML und CORBA / COM / DCOM | 37 |
| 3.6.12 | Fazit: Vor- und Nachteile von XML | 39 |
| 4. | ANFORDERUNGSANALYSE | 41 |
| 4.1 | KONZEPTIONELLE ANFORDERUNGEN AUS ANWENDERSICHT | 42 |
| 4.1.1 | Informationsbedarf | 42 |
| 4.1.2 | Management- Informationssystem | 43 |
| 4.1.3 | PR-Informationssystem | 45 |
| 4.1.4 | Anforderungen an die Datenbank | 46 |
| 4.1.5 | Anforderungen an ein Krisenmanagement-System bei FME | 53 |
| 4.1.6 | Aufgaben eines Informationssystems für FME bei regulärem Betrieb | 57 |
| 4.1.7 | Aufgaben eines Informationssystems für FME im PR-Krisenfall | 59 |
| 4.1.8 | Konzeptionelle Anforderungen: Fazit | 61 |
| 4.2 | GESTALTERISCHE ANFORDERUNGEN | 62 |
| 4.2.1 | Softwareergonomie | 62 |
| 4.2.2 | Visualisierung / Oberflächendesign | 63 |
| 4.2.3 | Gestalterische Anforderungen: Fazit | 65 |
| 4.3 | ANFORDERUNGEN AUS DER SICHT DES ENTWICKLERS UND INFORMATIONSMANAGERS | 66 |
| 4.3.1 | Einhaltung von Standards und Erhaltung von Plattformunabhängigkeit | 66 |
| 4.3.2 | Standardsoftware vs. Eigenerstellung | 66 |
| 4.3.3 | Verfügbarkeit von Entwicklungswerkzeugen | 68 |
| 4.3.4 | Hardwarebeschaffungen | 68 |
| 4.3.5 | Sicherheit | 68 |
| 4.3.6 | Geschwindigkeit | 70 |
| 4.3.7 | Juristische Aspekte | 71 |
| 4.3.8 | Anforderungen aus der Sicht des Entwicklers: Fazit | 71 |
| 4.4 | PERSONELLE ANFORDERUNGEN | 72 |
| 4.4.1 | Schätzung des Programmieraufwandes | 72 |
| 4.4.2 | Aufbauorganisation der IT-Abteilung bei FME | 73 |
| 4.4.3 | Anforderungen an die Personalaufwandsplanung: Fazit | 73 |
| 5. | ENTWURF DER TECHNISCHEN REALISIERUNG | 75 |
| 5.1 | VORÜBERLEGUNGEN | 75 |
| 5.2 | IST-SITUATION | 75 |
| 5.2.1 | Informationssysteme bei FME | 75 |
| 5.2.2 | Hard- und Softwaresituation bei FME | 76 |
| 5.2.3 | Abschließende Problemdefinition | 77 |
| 5.2.4 | Herkömmliche Informationssysteme (Schema) | 79 |
| 5.3 | SOLL-SITUATION | 81 |
| 5.4 | BEISPIELE FÜR EIN XML-BASIERTES KRISENMANAGEMENTSYSTEM | 84 |
| 5.4.1 | Szenario „Fire in warehouse“ | 84 |
| 5.4.2 | Szenario „Price erosion“ | 87 |
| 5.5 | ÜBERLEGUNGEN ZUR SOFTWARE | 90 |
| 5.5.1 | Server-Software | 90 |
| 5.5.2 | Softwareentwicklung für XML-Anwendungen | 95 |
| 5.6 | BENÖTIGTE HARDWARE | 98 |
| 5.6.1 | Server-Hardware | 98 |
| 5.6.2 | Client-Hardware | 98 |
| 5.6.3 | Hardware für Software-Entwickler | 99 |
| 5.7 | ENTWURF EINER XML-BASIERTEN INFORMATIONSSYSTEM-INFRASTRUKTUR | 100 |
| 5.8 | VORGEHENSWEISE DER EINFÜHRUNG EINES IUK-SYSTEMS BEI FME | 101 |
| 5.9 | TECHNISCHE REALISIERUNG: FAZIT | 102 |
| 6. | KOSTENSCHÄTZUNG UND NUTZENBEWERTUNG | 103 |
| 6.1 | KOSTENSCHÄTZUNG | 103 |
| 6.1.1 | Hardware | 103 |
| 6.1.2 | Software | 103 |
| 6.1.3 | Personalkosten | 104 |
| 6.1.4 | Gesamtkosten | 104 |
| 6.2 | NUTZENBEWERTUNG | 105 |
| 6.2.1 | Strategische Vorteile | 105 |
| 6.2.2 | Produktivitätsverbesserungen | 106 |
| 6.2.3 | Kostenersparnis | 106 |
| 7. | INTERPRETATION UND SCHLUßFOLGERUNGEN | 109 |
| 7.1 | FAZIT | 109 |
| 7.2 | AUSBLICK | 110 |
| 8. | LITERATUR | 111 |
| 8.1 | BIBLIOGRAPHIE | 111 |
| 8.2 | INTERNET-LINKS | 113 |
| 9. | VERZEICHNISSE | 114 |
| 9.1 | ABBILDUNGSVERZEICHNIS | 114 |
| 9.2 | TABELLENVERZEICHNIS | 114 |
| 9.3 | DIAGRAMMVERZEICHNIS | 115 |
| 10. | ANHANG | 116 |
| 10.1 | KRISENPLAN „FIRE IN THE WAREHOUSE“ | 117 |
| 10.2 | KRISENPLAN „DRASTIC PRICE EROSION“ | 119 |
| 10.3 | ANGEBOT DER FIRMA DELL FÜR EINEN DUAL-PIII-SERVER | 122 |
| 10.4 | ANGEBOT DER FIRMA IBM FÜR EIN VIDEOKONFERENZ-NOTEBOOK | 125 |
| 10.5 | PREISLISTE DER SOFTWARE AG FÜR DIE PRODUKTE „TAMINO“ UND „BOLERO“ | 127 |
Die "Common Object Request Broker Architecture" (CORBA) ist ein Konzept eines offenen Software-Bussystems, das es Applikationen erlaubt, miteinander zu kommunizieren unabhängig davon, wer sie erstellt hat, auf welcher Plattform sie ablaufen, in welcher Programmiersprache sie erstellt wurden und wo sie ausgeführt werden. CORBA erlaubt es außerdem, Software in Komponentenform zu entwickeln und ist vollständig objektorientiert aufgebaut. Die Hauptaufgabe von CORBA stellt die Verwaltung von Objekten und Methodenaufrufen dar. CORBA wurde 1991 von einem Konsortium namens OMG (Object Management Group) verabschiedet, das aus über 700 namhaften Unternehmen der Computerindustrie besteht. Da die OMG nur Schnittstellenspezifikationen ausarbeitet und keinen Programmcode veröffentlicht, wurden die Spezifikationen in einer neutralen Beschreibungssprache namens "IDL" (Interface Definition Language) definiert. Diese definiert u.a. die betriebssystemund programmiersprachenunabhängigen Schnittstellen für alle Dienste und Komponenten, die sich auf dem CORBA-Bus befinden. Microsofts COM (Component Object Model) bzw. DCOM (Distributed Component Object Model) stellt das Gegenstück zu CORBA dar und ist zu diesem nicht kompatibel. Microsoft hat damit dem offenen Standard CORBA einen eigenen, proprietären Standard gegenübergestellt, COM und DCOM haben sich aber dennoch wegen der engen Verwandtschaft mit den Microsoft-Standards OLE und ActiveX und aufgrund der großen Verbreitung von Windows-Rechnern ebenfalls etablieren können. XML läßt sich sehr gut mit CORBA verbinden, mehrere Anwendungen sind aufgrund des Prinzips der bei CORBA vorhandenen IDL denkbar: • Die IDL kann XML-konform definiert werden und CORBA-Objekte können dann mit einer in XML definierten Sprache miteinander kommunizieren. XML wäre also gewissermaßen das "Transportprotokoll" zwischen CORBA-Objekten. • XML kann als eine abstrakte Systembeschreibungssprache genutzt werden. CORBA-Systemschnittstellen, Abläufe, API-Funktionen und Datendefinitionen so- [...]
Eine Arbeitsgruppe des W3C arbeitet seit Anfang 1999 daran, mit der XSDL eine Sprache zu definieren, mit der sich Schemata definieren lassen, die die DTD-Syntax und damit auch die DTDs selbst ersetzen können. Die Nutzung von DTDs zur Deklaration der Struktur und der Syntax von Auszeichnungssprachen bringt einige Nachteile mit sich: • das Konzept der DTDs eignet sich zur Beschreibung von textbasierten Informationen, XML wird jedoch zunehmend im Bereich des Datenaustauschs bzw. des "Electronic Business" eingesetzt, wo neben Textinformationen auch Daten mit anderen, komplexen Datentypen auftreten. • • In DTDs lassen sich nicht beliebige Kardinalitäten definieren. DTDs sind strenggenommen keine wohlgeformten XML-Dokumente, und erschweren somit die Analyse durch Parser, die deren Struktur auswerten. Einige XML-Datenbanken nutzen schon jetzt das Prinzip der Schemadefinition, es ist daher wahrscheinlich, daß die XSDL das Konzept der DTDs ablösen und ersetzen wird. [...]
3.6.6. Namespaces Der W3C-Standard "Namespaces" ("Namensräume") vom Januar 1999 soll dafür sorgen, daß Namen von Elementen und Attributen, die in XML-Dokumenten verwendet werden, eindeutig hinsichtlich ihrer Bedeutung in der Auswertung durch den Parser sind. Mehrdeutigkeiten, die durch identische Namen für artverschiedene Inhalte entstehen können, werden dabei durch die Vergabe einer eindeutigen URL für jeden Namespace vermieden. Ein Beispiel: das Element <Adresse> könnte in einem XML-Dokument sowohl den Wohnort als auch eine Internet-Adresse definieren. Die Deklaration xmlns:w="http://www.fh-darmstadt.de/iud/xml" würde beispielsweise den Namespace "w" für den Wohnort deklarieren. Das Element <w:Adresse> wäre dann eindeutig dem Wohnort zugeordnet. Dieser Standard ist vor allem für den Einsatz von XML als Austauschformat für Geschäftsdaten essentiell wichtig, da hier häufig Elemente mit gleichem Namen, aber verschiedener inhaltlicher Bedeutung vorkommen können. [...]
In den Warenkorb
48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832427399
Arbeit zitieren:
Bühr, Ralph Juni 2000: Einsatz eines XML - Datenbank basierten Informationssystems zur Unterstützung der Öffentlichkeitsarbeit eines Unternehmens im Krisenfall, Hamburg: Diplomica Verlag
Schlagworte:
Öffentlichkeitsarbeit, Datenbank, Krise, Informationssystem, PR



