188 052 Grundzüge der Wirtschaftsinformatik II VO

188 053 Praktikum aus Wirtschaftsinformatik II PR

1999-03-08

1999-03-15

1999-04-12

1999-04-19

1999-05-03

1999-06-07

1999-03-08

Electronic Commerce

Online-Shopping: 1997: $ 1.138 Mill; Prognose 2000: $ 6.579 Mill

• Marketing
• Pre-Sales
• Finanzierung, Versicherung
• Bestellwesen, Lieferung, Bezahlung
• Service und Wartung
• Kooperative Produktentwicklung
• Verteiltes kooperatives Arbeiten
• business to administration (Konzessionen, Zoll, Steuer...)
• Transport und Logistik
• automatic trading digitaler "Waren"

Basisfunktionen des EC

• Benutzerschnittstellen
  • adaptierbare Schnittstellen
  • usability
  • Partizipation des Endbenutzers im Designprozeß
• Protokolle für EC-Handel
• Zahlungsverkehr
• Security-mechanismen
• Identifikation und Authentifikation
• Rechnungsprüfung und Buchhaltung

Anforderungen an "EC Enabling Technologies"

• Standards

Phasen des EC

Geschäftsprozeß-unterstützend:

• Workflow Management Systems (WFMS) als Basistechnologie zur Unterstützung der EC-Geschäftsprozesse

Pre-sales-Phase des EC

• Datenbanksysteme (Data Mining)

Übung

Inhalte

• Daten- und Prozeßmodellierung
• Betriebe, Unternehmen

Ablauf des Praktikums

Bis 22. 3. einen Betrieb suchen, und dazu 3 Folien vorbereiten

1. Gruppennummer, Matrikelnr, Namen, ausgewähltes Unternehmen

2. Begründung der Auswahl

3. Vorgangsweise der Wissensaquisition

Präsentation max. 5 Minuten (streng!)

Gruppe 24: Mo, 22.3. 1999, 16:15-17:00, HS 17. Tutor: Robert Kosara

Schriftliche Ausarbeitung: Abgabe in der Woche Mo. 17.5 - Fr. 21. 5. bei den TutorInnen

Präsentation: Jedes Gruppenmitglied präsentiert einen Teil der Arbeit, alle müssen anwesend sein.

1999-03-15

Inhalt des Vorlesungsteils Datenmodellierung

• Teil 1: Einführung in die Datenmodellierung
• Teil 2: Das Entity-Relationship-Modell
• Teil 3: Transformation eines ER-Diagrammes in das Relationenmodell
• Teil 4: Erweiterungen des Entity Relationship-Modells
• Teil 5: Semantische Datenmodelle
• Teil 6: Objektorientierte Datenmodelle

Warum Datenmodellierung?

Die Notwendigkeit der Datenmodellierung ergibt sich aus einer übergeordneteten Prblemstellung:

• Methodischer Entwurf der Software von Anwendungssystemen

=> Datenbank-Design und Funktionsanalyse werden durch die Auswahl eines passendes Modells erheblich beeinflußt.

• Konzeptionelles Design: Konzeptionelles (Datenbank-) Schema
• Funktionsanalyse: Funktions-Schema

Der Software Lifecycle als allgemeiner Rahmen für die Softwareentwicklung:

1. Nutzeranalyse

2. Anforderungsanalyse

3. Entwurf: Datenmodell ist bereits Teil des Entwurfes

4. Implementierung

5. Test

6. Betrieb/Wartung

• Einschränkung auf den Entwurf von Informationssystemen
• Definition:
  • ein Informationssystem ist ein System zur Aufnahme, Speicherung, Verarbeitung und Weitergabe von Informationen

Datenbank-Entwurfsprozeß

Ziele:

• Erstellung des konzeptionellen Schemas
• Erstellung der externen Schemata
• Erstellung des internen Schemas

=> Herstellung geeigneter Abstraktionen von gewissen realen Gegebenheiten

Phasen des Datenbank-Entwurfprozesses

• Anforderungsanalyse und -spezifikation: mühsam, da nicht automatisierbar
• DBMS-unabhängiger konzeptioneller Entwurf: z.B. ER-Diagramm
• Wahl des Ziel-DBMS
• Logischer Entwurf
• Implementierungsentwurf
• Physischer Entwurf
• Implementierung mittels DDL (Data Definition Language)
• Prototyping
• Dokumentation

Im konzeptionellen Entwurf erstellt der/die DesignerIn eine konzeptionelle Globalsicht der gewünschten anwendung.

• Beschreibung aller einzelnen Benutzersichten (Benutzergruppen) auf die Daten
• Integration der Einzelsichten zu einer konzeptionellen Globalsicht der Datenbank
  • Analyse der Einzelsichten auf Redundanzen und Inkonsistenzen (Namenskonflikte...)
  • Schema-Merging: Zusammenführung der Sichten
• Verwendung eines konzeptionellen Datenmodelles (z.B. ER)

Mögliche Schritte bei der Wahl eines DBMS (Datenbanksystems)

• vorhandene Hard- und Software, insbesondere Betriebssystem
• benötigte Programmiersprachen-Schnittstellen
• Herstellerbindung des betreffenden Unternehmens
• Benötigte Performance des Systems
• Komplexität des zu implementierenden Datenmodells

Physischer Entwurf

• geeignete Speicherstrukturen
• Zugriffsmechanismen
• Indexstrukturen
• ....

Datenmodelle - Abstraktionskonzepte

Wesentlich für den Entwurf einer Datenbank sind folgende drei Abstraktionsmechanismen:

• Klassifikation
• Aggregation (Zusammensetzung)
• Generalisiserung (Verallgemeinerung)/Spezialisierung

Klassifikation

• Definition bestimmter Konzepte als Klassen von Objekten mit gemeinsamen Eigenschaften (Attributen)
  • Mathematische Sicht: Mengenbildung
    • Beispiel: Auto
    • Klasse: Auto

Aggregation

Definition einer neuer Klasse aus anderen, bereits bestehenden Klassen, welche dann Komponenten repräsentieren.

Bestehende Klassen werden zu einer neuen Klasse zusammengesetzt. Mathematische Sicht: Bildung Kartesischer Produkte.

Beispiel Auto: Die Klasse Auto wird aus den bereits existierenden Klassen Motor, Karosserie usw. zusammengesetzt.

Generalisierung (Verallgemeinerung) und Spezialisierung

• Generalisierung:
  • Definition einer Teilmengenbeziehung zwischen den Elementen verschiedener Klassen.
    • Mathematische Sicht: Potenzmengenkonstruktion bzw. Teilmengenbildung
  • Beispiel: die Klasse Fahrzeug ist eine Generalisierung der Klasse Fahrrad
• Spezialisierung:
  • Umgekehrte Sicht der Generalisierung
  • Disjunkte Zerlegung einer Klasse in Unterklassen
  • Beispiel: die Klasse Fahrrad ist eine Spezialisierung der Klasse Fahrzeug

Datenmodelle werden meist formal und grafisch dargestellt.

Geschichte der Datenmodelle

• 70er: Netzwerkmodell, Hierarchisches Modell
• 80er: Relationales Modell
• 90er: Objektorientiertes Modell

Die Verbreitung und Verwendung dieser Modelle in der Wirtschaft erfolgte jeweils um einige Jahre verzögert.

1999-04-12

Datenmodellierung

Teil II. Das Entity-Relationship-Modell

(Buchempfehlung: "Handbuch der Software-Technik")

ER-Modell 1976 von Prof. Peter P. Chen entwickelt.

• 1998 von ANSI zum Standardmodell für Information Ressource Dictionary Systems gewählt
• Grafisches Modell
• Erste Abstraktionsstufe von der realen Welt weg zu deren Abbild im relationalen Datenmodell und der Datenbank (Datenbankdesign)
• Suchen der Objekte und deren Beziehungen zueinander im betrachteten Ausschnitt der realen Welt
• Darstellung des Ausschnittes der realen Welt mit einem ER-Diagramm
• Ausschließlich statisches Modell, keine Interaktion zwischen den Daten definiert.

Das ER-Modell ist dem Gebiet des konzeptionellen Datenbankentwurfes zuzuordnen. Es ist von Speicher- und Effizienzüberlegungen unabhängig (Indizes usw. werden erst später hinzugefügt).

Das ER-Modell unterstützt die Modellierung der externen Schemata des Dreischichtmodells nicht.

Unter einem (starken) Entity versteht mensch ein bestimmtes Objekt der ralen Welt bzw. des betrachteten Anwendungsgebietes.

• Ein Entity kann ein Individuum (MitarbeiterIn), ein Gegenstand, ein abstraktes Konzept, ein Ereignis usw. sein.
• Ein Entity hat hat eine eigenständige Existenz und kann eindeutig identifiziert werden.
• Ein Entity-Typ ist eine Repräsentation innerhalb des Datenmodelles, die Entities kategorisiert.
  • Ein Entity-Typ wird durch Attribute beschrieben. Im Sinne der Abstraktion kann dein Entity-Typ als Aggregation von Attributen gesehen werden.

Entities besitzen Eigenschaften, mit denen sie beschrieben werden können. Diese Beschreibungsmerkmale werden als Attribute bezeichnet.

Die konkrete Ausprägung eines Attributes wird als (Attributs-)Wert bezeichnet. Die Zusammenfassung (Menge) aller zugelassenen (sinnvollen und möglichen Werte für ein Attribut) wird Domain (Wertebereich) genannt.

Alle Entities, die mit den Attributen eines Entity-Typs beschreiben werden können, wereden einem Entity-Typ zugeordnet. Im ER-Modell wird ein Entity-Typ auch als Entity-Set bezeichnet.

Beispiel:

• Entity: Der Mitarbeiter Wagner, Altenberger Str. ...
• Entity-Set: Die Menge aller MitarbeiterInnenn
• Entity-Typ: MitarbeiterIn
• Attribute: Name, Straße, Ort

Entity-Typ, Attribute und Domain eines Attributes sind zeitinvariant (statisch)

Zur Identifizierung eines Eintities ist häufig nicht die Angabe aller Attributswerte erforderlich.

• Es kann ausreichen, sog. Schlüsselattribute und ihre Zusammenfassung als (zeitinvarianten) Schlüssel anzugeben.
  • Beispiel:
    • Entity-Set: Stadt (PLZ, Ort, Bundesland, Vorwahl)
    • Schlüsselkandidaten: PLZ oder Vorwahl

Relationships

Im Gegensatz zu Entities können Relationships nicht für sich alleine existieren: Sie modellieren Beziehungen zwischen Entities.

Beziehungen können auch Attribute haben, die erst durch das Herstellen der Beziehung relevant werden. Diese sind für die einzelnen Entity-Sets bedeutungslos.

Relationships werden auch mit Hilfe von Relationship-Typen (Rel.-Sets) deklariert.

Der Inhalt eines Relationship-Sets ist zeitveränderlich (dynamisch).

Ein Relationship-Typ wird im ER-Diagramm als Raute dargestellt.

• Dieser wird durch Kanten mit den beteiligten Entity-Typen verbunden.
• Die Kanten sind ungerichtet. Ausnahme: Rekursive Relationships.
• Eigene Attribute der Relationship werden mit Kreisen markiert.

Schwache Entity-Sets:

• Modellierung einer Existenzabhängigkeit zwischen Entity-Setz
• Die Existenz eines Entity-Sets hängt von der Existenz eines anderen (übergeordneten) Entity-Sets ab.
  • Beispiel: Ein Kind existiert nur, wenn auch Eltern existieren

Assoziationstypen

Jede Beziehung wird einem Assoziationstypen (Komplexitätstypen zugeordnet bzw. gewichtet.

• 1:1
• 1:n
• n:m
• Speziell: c (0 - 1) ("konditionell")

Generalisierungshierarchien

• Generalisierung
  • Verschiedene Entity-Mengen werden als eine verallgemeinerte Entity-Menge dargestellt ("IS_A"): MitarbeiterIn "IS_A" Person
    • Beispiel: Fluggesellschaft
      • AngestellteR: AngNr, Name usw.
      • PilotIn: AngNr, Stunden, Lizenz
      • TechnikerIn: AngNr, TeamNr
        • Ein konkreter Pilot kommt also auch als Entity vom Typ AngestellteR vor
• Spezialisierung
  • "CAN_BE"-Beziehung

Innerhalb einer Generaliserungshierarchie können zusätzliche Eigenschaften definiert werden:

• total/partiell
• disjunkt/nicht disjunkt

Im Beispiel gibt es drei Arten von Entity-Sets: Angestellte, PilotInnen, TechnikerInnen. Es gibt Angestellte, die weder PilotInnen noch TechnikerInnen sind => partiell

1999-04-19

Das Wichtigste bei Datenbanken: Konsistenz!

Abbildung von Relationship-Typen

• 1:1-Relationen: z.B. Jede Abteilung hat eineN AbteilungsleiterIn; jedeR AbteilungsleiterIn leitet eine Abteilung

Abbildung rekursiver Relationship-Typen

Abbildung einer Generalisierung

• Für jeden Entity-Typ der Generalisierungshierarchie wir ein eigenes Relationenschema eingeführt.

1999-05-03

http://byron.ifs.tuwien.ac.at/datenmodellierung/

Prinzipien in der Softwareentwicklung

• Annahme von strukturierter Analyse / Entwurf
  • Prozesse sind komplexer als Daten
  • prozeßorientiert: WAS wird ausgeführt
• Annahme von objektorientierter Analyse / Entwurf
  • Objekte sind komplexer als Prozesse
  • Objekte ändern sich weniger häufig als Prozesse
  • objektorientiert: WER ist involviert

Bei OO-Design ist die "Anlaufzeit" viel länger, dadurch wird allerdings Wiederverwendbarkeit erreicht.

Vorteile der objektorientierten Entwicklung:

• Integration von Daten und Prozeduren zu Objekten
• Verwendung derselben Konzepte in Analyse, Entwurf und Implementierung

Anwendungsentwicklungsarten

• Funktionsorientiert
  • Entwickeln von Software wird mit der Erstellung von Programmen gleichgesetzt
  • Das Programm realisiert eine oder mehrere Funktionen
  • Gefahr des Datenchaos: Jede Funktion verarbeitet unkoordiniert Daten
• klassisch
  • Funktionen - Aufrufe - Zugriffe - Daten - Beziehungen
• objektorientiert
  • Objekte:
    • tauschen Nachrichten aus und führen Aktionen durch

Evolutionäres Prototyping

• Objektorientierte Entwicklung unterstützt evolutionäres Prototyping
• (auch Versioning genannt): der Prototyp stellt kein Wegwerfprodukt, sondern den Kern eines neuen Produkts dar.

Objekte

• zentrales Strukturierungskonzept der OO-Programmierung
• Entsprechen möglichst direkt realen Entitäten
• Können Konkreta oder Abstrakta darstellen ("Alles ist ein Objekt")
• Sind eindeutig identifizierbar.
• Zeigen ein definiertes Verhalten (Menge von Methoden), das von außen durch Senden von botschaften aktiviert wird (message passing)
• Sind durch ihren Zustand charakterisiert, der nur über Mehtoden manipuliert werden kann (Kapselung)
  • Zustände durch Instanzvariablen beschrieben

Kapselung

• Schutz vor unerlaubtem Zugriff auf den internen Zustand des Objekts durch eine eindeutig definierte Schnittstelle (Protokoll). Nur mit den Operationen ist es möglich, den internen Zustand des Objekts zu manipulieren

• Objekte repräsentieren individuelle und identifizierbare Exemplare von Dingen, Personen oder Begriffen. Objekt = Einzelfall
• Klassen
  • Gleichartige Objekte werden zu Klassen zusammengefaßt
    • Gleichartig: Der Objekt-Status kann mit identischen Variablen (Attributen) festgehalten werden und es liegt identisches Verhalten vor.
  • Klassen beschreiben die Eigenschaften ihrer Mitglieder (Ausprägungen, Exemplare oder Instanzen)
  • Die Menge aller in einer Klasse definierten Methoden heißt Protokoll oder Signatur der Klasse
  • Klassen implementieren abstrakte Datentypen (ADT)
  • Klassen können über Klassenmethoden (objektunabhängig) und Klassenvariablen verfügen.
  • Klassen kennen eine vordefinierte Methode (Konstruktor) zum Erzeugen von neuen Instanzen
    • Jedes Objekt ist Instanz genau einer Objektklasse
  • Jede Instanz beistzt eine eigene Kopie jeder Instanzvariablen
  • Operationen und Klassenvariablen sind nur einmal pro Klasse implementiert
  • Abstrakte (nicht instanzierbare) Klassen:
    • Zweck: Variable und Methoden werden an andere Klassen vererbt

1999-06-07

Data Warehouse (DWH)

• DWH supports informational processing by providing a solid platform of integrated, historical data from which to do analysis.

Im Data Warehouse braucht mensch Metadaten:

• Metadaten = Informationen über die im DWH gespeicherten Daten

Metadaten bilden die Verbindung zwischen den operationalen Daten und den entscheidungsunterstützenden Systemen (DSS), sodaß ein DSS die notwendigen Daten identifizieren, finden und zur Verarbeitung aufbereiten kann.

• Metadaten beschreiben die Semantik der Daten im DWH
• Metadaten beinhalten:
  • Lokation der Daten
  • usw.
• MCI Telecommunications Corporation:
  • 23*10⁹ Telefonate/Jahr + Kundendaten
  • gespeichert in 15 Datenbanken
• DWH:
  • IBM SP2 (104 Knoten)
  • Informix 8.0 RDBMS unter MVS
  • 3500 Attribute für ein Potential von 100*10⁶ Kunden
• DWH:
  • 4,5 Terabyte + 12 data marts (85-100 Gbytes)
  • massiv-parallele Hardware

Motive für Data Warehouses im Unternehmen:

• Information für EntscheidungsträgerInnen durch Erstellung von Reports aus operationalen Daten
  • Wunsch: Interaktion mit diesen Daten
• Der Erfolg der DB-technologie bringt es mit sich, daß eine sehr große Menge (auch verteilter evtl. historischer Daten) den Unternehmen zur Verfügung stehen.
  • Wunsch: Flexible Analyse dieser Daten für Managemententscheidungen
• Der Erfolg der Analysetechniken (Statistik, AI) erlaubt es, aus operationalen Daten Hypothesen zu generieren und zu prüfen.

Probleme

• Datenbanksysteme sind transaktionsorientiert, nicht subjektorientiert.
  • Schwerpunkt auf individuelle Transaktionen und nicht auf Gruppen von Transaktionen
  • OLTP (on-line transaction processing) versus OLAP (on-line analytical processing)
• Gefahr der Scheinkorrelation bei Data Mining: 5 % von Verteilungen von Zufallsdaten sind auf dem 5 %-Niveau signifikant!

© Balázs Bárány, Nicht autorisiert. Für Nutzungsbedingungen siehe http://www.tud.at/uni/kleingedrucktes.htm.
Zuletzt geändert (JMT):1999-10-01