Daten- und Prozessmanagement - Datenmodellierung -

Präsentation zum Thema: "Daten- und Prozessmanagement - Datenmodellierung -"—  Präsentation transkript:

1 Daten- und Prozessmanagement - Datenmodellierung -

2 © Prof. T. Kudraß, HTWK Leipzig Rahmenmodell des IM (Krcmar) Management der Informationswirtschaft Management der Informationssysteme Angebot Nachfrage Verwendung Daten Prozesse Anwendungs- lebenszyklus Verarbeitung Speicherung Kommunikation Führungsaufgaben des Informations- managements IT-Governance Strategie IT-Personal IT-Controlling Management der Informations- und Kommunikations- technik Technikbündel IT-Prozesse

3 © Prof. T. Kudraß, HTWK Leipzig Aufgaben für das IS-Management Datenmanagement – Umgang mit Referenzmodellen – Erstellung eines unternehmensweiten Datenmodells – Auswahl einer geeigneten Datenarchitektur – Sicherstellung der Datenkonsistenz Prozessmanagement – Identifizieren von Geschäftsprozessen – Modellierung und Gestaltung von Prozessen – Wiederverwendung von Prozessmodellen – Standardisierung – Ökonomische Beurteilung von Prozessen

4 © Prof. T. Kudraß, HTWK Leipzig Datenmanagement Ziel: – Optimale Nutzung der Daten im Unternehmen: Verbesserung der Informationsqualität + produktive Anwendungsentwicklung durch Einsatz von Datenbanken Aufgaben: – Datenmodellierung – Datenadministration – Datentechnik – Datensicherheit & Datenschutz – Datenkonsistenz und Datenqualität (siehe Vorlesung) – Sicherung von Daten (z.B. Backup) – datenbezogene Benutzerservices

5 © Prof. T. Kudraß, HTWK Leipzig Datenmodellierung Formale Beschreibung der Unternehmensdaten in einem sogenannten Datenmodell – Entity-Relationship-Modell (ERM) für Fakten – Objektorientierte Datenmodellierung – Dokumentenmodelle (XML, schemalos) – Modellierung unscharfer Daten – verschiedene IR-Modelle für Texte – integrierte Modelle für die Text-Fakten-Kombination – Modelle für multimediale Information – Data Dictionary

6 © Prof. T. Kudraß, HTWK Leipzig Unternehmensmodelle Ebenen A B C Informations- technik Unternehmensmodell = Unternehmensdatenmodell + Unternehmensfunktionsmodell ABC-Klassifizierung nach Krcmar

7 © Prof. T. Kudraß, HTWK Leipzig Entity-Relationship-Modell (ERM) Ziele: – Beschreibung der Daten und ihrer Beziehungen untereinander aus fachlogischer Sicht – Erstellung eines konzeptionellen Modells Elemente – Entitäten – Entitätsmengen – Attribute (beschreibend und identifizierend) – Schlüssel – Beziehungen / Relationen und Beziehungsmengen – Kardinalitäten – Aggregationen

8 © Prof. T. Kudraß, HTWK Leipzig Entitäten sind Individuell und eindeutig identifizierbar – jeweilige Sachlage bestimmt, was als Entität zu sehen ist (z.B. Schulklasse oder einzelner Schüler) darstellbar aufgrund eines Schlüsselwertes über Eigenschaften charakterisierbar zu Entitätsmengen mit gleichen Eigenschaften zusammenfassbar

9 © Prof. T. Kudraß, HTWK Leipzig Beispiele für Entitäten

10 © Prof. T. Kudraß, HTWK Leipzig Attribute (Eigenschaft, property) Beschreiben die fachlichen Eigenschaften, die allen Entitäten einer Entitätsmenge gemeinsam sind Attribut hat Namen und Wertebereich – Name soll seiner fachlichen Bedeutung entsprechen – Wertebereich gibt die Menge aller möglichen bzw. zugelassenen Werte für ein Attribut an

11 © Prof. T. Kudraß, HTWK Leipzig Beschreibende und identifizierende Attribute (Schlüssel) Beschreibende Attribute beinhalten die anwendungsrelevanten Eigenschaften Identifizierende Attribute stellen die Schlüssel zur eindeutigen Identifikation einer Entität dar Schlüssel kann aus einem oder mehreren Attributen zusammengesetzt sein (Minimalitätseigenschaft) falls mehrere Schlüssel möglich sind, wird einer als Primärschlüssel festgelegt

12 © Prof. T. Kudraß, HTWK Leipzig Beziehungen Beziehungen stellen Wechselwirkungen und Abhängigkeiten zwischen Entitäten dar gleichartige Beziehungen zwischen Entitäten werden zu Beziehungsmengen (relationship sets) zusammengefasst, auch als Assoziationen bezeichnet Kardinalität von Beziehungen – Die Kardinalität gibt an, mit wieviel anderen Entitäten eine Entität in einer konkreten Beziehung stehen muss bzw. kann. – Prinzipiell drei Möglichkeiten: 1:1 1:M M:N

13 © Prof. T. Kudraß, HTWK Leipzig Kardinalität - Beispiele 1:1-Assoziation – Zwei Entitätsmengen A und B stehen zueinander in einer 1:1- Assoziation, wenn jede Entität aus A mit genau einer Entität aus B verbunden ist und umgekehrt. – Beispiel: Ehe ist 1:1-Beziehung (westlicher Kulturkreis) 1:M-Assoziation (auch 1:N) – Zwei Entitätsmengen A und B stehen zueinander in einer 1:M- Assoziation, wenn es zu jeder Entität aus A eine oder mehrere Entitäten in B gibt, zu jeder Entität aus B aber genau eine Entität in A existiert. M:N-Assoziation – Es gibt zu einer Entität aus A eine oder mehrere Entitäten in B und umgekehrt

14 © Prof. T. Kudraß, HTWK Leipzig Konditionelle Beziehungen Zwischen zwei Entitäten MUSS keine, aber KANN eine Beziehung bestehen. – 1:C Ein PKW kann einen Tempomat haben – C:MCBei einer Tagung kann ein Teilnehmer Mitglied einer Firma sein oder als Privatperson teilnehmen. Die Firma kann keinen, einen oder mehrere Teilnehmer zur Tagung schicken – N:MCein Kurs wird von mindestens einem (maximal N) Dozenten durchgeführt. Ein Dozent führt 0 oder M Kurse durch.

15 © Prof. T. Kudraß, HTWK Leipzig Notation für ERM (Beispiel) Dozent Kurs führt durch N MC

16 © Prof. T. Kudraß, HTWK Leipzig Schritte bei der ER-Modellierung Festlegung der Entitäten (Synonym: Objekt) Festlegung von Eigenschaften (Attributen) und Eigenschaftswerten Zuordnung von von Eigenschaften und Eigenschaftswerten zu Entitäten Herstellung von Beziehungen zwischen Entitäten

17 © Prof. T. Kudraß, HTWK Leipzig Stammdatenmanagement (Master Data Management, MDM) Stammdaten = Grunddaten / Referenzdaten (master data) abgrenzbar gegenüber Bewegungsdaten (transaction data) Kriterien zur Definition – existentielle Abhängigkeit von Bewegungsdaten – unverändert (d.h. relativ statisch) über einen längeren Zeitraum – zustandsorientiert zur Identifikation, Klassifikation und Charakterisierung von Sachverhalten MDM gewann neue Relevanz in SOA (data service)

18 © Prof. T. Kudraß, HTWK Leipzig Stamm- vs. Bewegungsdaten StammdatenBewegungsdatenBestandsdaten zeitlich invariant, ohne Zeitbezug zeitlich variant, zumeist mit Zeitbezug dynamisch, zeitlich variant von mehreren Unternehmensbereichen und Anwendungen genutzt von wenigen Anwendungen genutzt mögliche Dimension bei OLAP liefern Fakten bei analytischen Auswertungen, mögliche Fakten bei OLAP liefern Fakten bei analytischen Auswertungen, mögliche Fakten langfristige Speicherungkurz- oder mittelfristige Speicherung langfristige Speicherung Beispiele: Artikeldaten, Kundendaten, Stücklisten, Arbeitspläne Beispiele: Bestellungen, Aufträge, Lieferungen Beispiele: Lagerbestand, Kontostand

19 © Prof. T. Kudraß, HTWK Leipzig Objektorientierung Objektorientierung stellt neue Konzepte für die Modellierung und Entwicklung von Software-Systemen zur Verfügung – OO-Grundkonzepte Objekt Botschaft Klasse Vererbung Attribut Polymorphismus Operation/Methode Vorteile: – neue Modellierungskonzepte – vereinigt Daten- und Funktionssicht – enge Verbindung zu OO Sprachen – Integrationsansatz für heterogene Systeme (distributed objects)

20 © Prof. T. Kudraß, HTWK Leipzig Objektorientierung Objekt: Haus 2673 Haustyp: Besitzer: Adresse: Wohnfläche: Anz. der Bäder Schwimmbad: Baujahr: Verkaufspreis: qm-Preis Wegbeschreibung Landhaus Otto Kaiser Königsfeld 400 qm 3 ja 1995 2,4 Mio Kapselung Attribute Methoden

21 © Prof. T. Kudraß, HTWK Leipzig 67 Vererbung Immobilie Besitzer Adresse BJ Preis Einfamilienhaus Besitzer Wohnfl. Adresse Bäder BJ Gartenfl. Preis Geschäftshaus Besitzer Büros Adresse Parkpl. BJ Aufzug Preis TG

22 © Prof. T. Kudraß, HTWK Leipzig Polymorphismus dieselbe Botschaft an Objekte verschiedener Klassen wird unterschiedlich interpretiert Drucken Objekt EFH Objekt GH Außenansicht Grundriß

23 © Prof. T. Kudraß, HTWK Leipzig Ansätze zu Objektorientierung in Datenbanken Objektorientierte DBMS – Entstanden durch Verbreitung von OO Programmiersprachen – Verschiedene Persistenzkonzepte – Geringe Bedeutung in der Praxis Objektrelationale DBMS – Kombination der relationalen und OO Eigenschaften im Datenmodell Verwaltung komplexer Datenstrukturen (Geodaten, Biodaten) – Basis für viele multimediale Informationssysteme Objektrelationales Mapping – OO Sprachen (z.B. Java) mit Abstraktionsebene auf Basis relationaler Datenbanken – Persistenz-Frameworks (Hibernate, JDO, Java Persistence API)

24 © Prof. T. Kudraß, HTWK Leipzig Objektrelationales Mapping Objektorientierter Zugriff auf persistente Daten Transparentes Laden und Speichern persistenter Daten Performanceverbesserung durch Objektpuffer im Hauptspeicher Architektur Ziele

25 © Prof. T. Kudraß, HTWK Leipzig Dokumentendatenmodelle: XML physische Ebene Dokument- verarbeitung Dokumenten Entwurf von XML- Konzeptueller logische Ebene konzeptuelle XML Datenbanken Klettke / Meyer XML-Datenbanken

26 © Prof. T. Kudraß, HTWK Leipzig XML und Datenbanken Speicherung von Dokumenten mit und ohne Schema (XML Schema) Arten von Dokumenten: – Datenorientiert (z.B. Bestellung) – Dokumentenorientiert (z.B. – Semistrukturiert (z.B. Patientenakten) Speicherung von XML – relationale Speicherung inhaltsorientiert (Dokumentenstruktur DB-Struktur) Strukturorientiert (generisch mit festem DB-Schema) – opak (CLOB) – nativ (XML-Datenbanksystem) XML-orientierte Abfragen (XQuery)

27 © Prof. T. Kudraß, HTWK Leipzig Dokumentendatenbanken Alternative DB-Architekturen (NoSQL) SQLCouchDB Festes SchemaDynamisches Schema Tabellen von Daten, Menge, ZeilenSammlung von Dokumenten variabler Struktur (JSON), Multisets normalisiertdenormalisiert Objekte über mehrere Tabellen verteiltDokumente beschreiben sich selbst Zum Verarbeiten der Objekte muss Schema bekannt sein Zum Verarbeiten muss nur Dokumentenname bekannt sein Dynamische Abfragen mit statischem Schema Statische Abfragen mit dynamischem Schema CouchDB als Beispiel einer schemafreien Datenbank

28 © Prof. T. Kudraß, HTWK Leipzig Datenbanken in der Cloud Cloud Storage als Ressource des Cloud Computing, verschiedene Kategorien BLOB Storage: Virtuelles Dateisystem – Speicherung von Text- und Binärdaten in der Cloud – Zugriff über APIs, SOAP, REST Table Storage: BigTable-Ansatz, NoSQL-Datenbank – BigTable-Konzept (eine riesige Tabelle ohne feste Struktur) – Zugriff über SOAP & REST, APIs (echter) DB-Server – virtueller Datenbankserver zur eigenen Verwendung – übliche APIs

29 © Prof. T. Kudraß, HTWK Leipzig Ursachen für unscharfes Wissen Unwissenheit – Fakten zwar nicht bekannt, aber Normalfall bekannt (Default Reasoning) – Häufigkeitsverteilung der möglichen Werte bekannt (Stochastik) – Häufigkeitsverteilung der möglichen Werte ist nicht bekannt (Evidenztheorie) Ungenauigkeit, z.B. Messungenauigkeit – Intervallarithmetik zur Behandlung von Rundungsungenauigkeit Vagheit der Begriffe – Fuzzy-Logik: Quantifizierung mit vagen oder unscharfen Begriffen der natürlichen Sprache und Schlussfolgern über Aussagen mit diesen Begriffen

30 © Prof. T. Kudraß, HTWK Leipzig Unscharfes Wissen Impräzision: Wissen besteht aus mehreren präzisen Alternativen Beispiel: Herr Müller ist zwischen 30 und 40 Jahre alt. Unsicherheit (objektive Unschärfe): Die Wahrheit einer Aussage ist nicht klar. Sowohl präzise als auch unpräzise Aussagen können unsicher sein. Beispiel: Leipzig liegt (exakt) 113 m u. NN Vagheit (subjektive Unschärfe): Die Aussage ist eher qualitativ. Beispiel: Das Büro Z130 ist groß.

31 © Prof. T. Kudraß, HTWK Leipzig Beispiel für unscharfes Wissen 0 10 20 30 40 50 60 70 80 90 100 Preise günstig mittel teuer 1

32 © Prof. T. Kudraß, HTWK Leipzig Grundmodell: Information Retrieval Autoren Texte Match Anfrage Analyse Ergebnis 1.Dok.6 2.Dok.8 3.Dok. 78 4.Dok.99 Repräsentationen term1, term2, term3, term4... Repräsentation text text text Anwender Anwendung und Bewertung, ggf. Modifikation

33 © Prof. T. Kudraß, HTWK Leipzig Textmodellierung Bei der strukturbezogenen Systembetrachtung sind die den Input in den Output überführenden Mechanismen zu be- stimmen und in geeigneter Form zu visualisieren. bestimmen Form geeignet Input Mechanismus Output strukturbezogen Systembetrachtung überführen visualisieren Transforma- tionen Stoppwörter

34 © Prof. T. Kudraß, HTWK Leipzig Das Matching-Paradigma des klassischen Information Retrieval (IR) klassisches Boolesches Retrieval (mengentheoretisches Modell) Benutzer drücken ihr Suchproblem in einer exakten Retrievalsprache aus Verbindung von Termen und Boolescher Logik: AND, OR, NOT Term1 Term2 Term3

35 © Prof. T. Kudraß, HTWK Leipzig Nachteile der Booleschen Systeme disjunkte Unterteilung in relevant und nicht- relevant erwünschter Umfang schwer kontrollierbar (keine Sortierung nach Relevanz) Benutzer haben Probleme mit der Booleschen Logik Visualisierbarkeit

36 © Prof. T. Kudraß, HTWK Leipzig Ranking-Systeme Prinzip: Anordnung des Ergebnisses in einer nach Relevanz (!) sortierten Reihenfolge notwendige Voraussetzung: gewichtete Indexierung Grundlage: Vektorraummodell auf Basis von Textstatistik Vorteile – Rangordnung reiht die relevantesten Dokumente an den Anfang der Folge – Benutzer bestimmt den Abbruch (cut-off) selbst, d.h. keine Mengenprobleme – Experimente zeigen bessere Retrievalqualität (bereits für sehr einfache Verfahren)

37 © Prof. T. Kudraß, HTWK Leipzig Grundprinzip Ranking

38 © Prof. T. Kudraß, HTWK Leipzig Systemunterschiede beim IR Retrievalmodelle (Boolesches M., Textstatistik, Linktopologisches M., Netzwerk-M., Nutzer-M.) Indexierungsmodelle – Indexierungsvokabular: Wortindex / Phrasenindex – Informationen über Position und Dokumentstruktur Struktur von Textdokumenten – strukturiert (z.B. CSV, XML-Output) – schwach strukturiert (Überschriften, Paragraphen) – nicht strukturiert (eher selten) Ähnlichkeitsmaße / Abstandsfunktionen Outputform: Ranking, Relevance Feedback

39 © Prof. T. Kudraß, HTWK Leipzig Multimedia-Retrieval-Systeme Zeitungsarchive (Texte, Bilder, Fotos, Graphiken) Rundfunkarchive (Audioarchive) Videodatenbanken chemische Strukturen Fakten diverse Mischformen (oft Ergebnis von Integration unterschiedlicher Quellen) spezielle Ansätze, z.B. Content-Based Image Retrieval (vgl. Bildverarbeitung)

40 © Prof. T. Kudraß, HTWK Leipzig Datenadministration Verwaltung der Daten und Funktionen unter Berücksichtigung von Standards und internationalen Normen Einsatz von Data-Dictionary-Systemen (Datenkatalogsystemen), um eine konsistente Verwendung von Datenobjekten zu gewährleisten Weiterentwicklung zu Repository-Systemen

41 © Prof. T. Kudraß, HTWK Leipzig Data-Dictionary-Systeme DDS bestehen aus einem Data Dictionary und einem Software-System – Primär: wenn explizit auf Datenkatalog-Verwaltung ausgerichtet – Sekundär: Datenkatalog-Funktionen nur Teil eines anderen Softwaresystems DDS ist: – Abhängig: Verwaltungsfunktionen werden von einem bestimmten DBMS übernommen – Unabhängig: Eigene Management-Software und über Schnittstellen zu anderen DBMS Sie enthalten Metainformation über die in den DBS enthaltenen Daten und Anwendungsprogramme

42 © Prof. T. Kudraß, HTWK Leipzig Aufgaben und Bedeutung von DDS DDS dienen zur Konsistenzüberwachung eines Datenbestandes Analysen ermöglichen: – verschiedenartige Übersichten über die Datenstrukturen – Überprüfung auf Redundanz- und Widerspruchsfreiheit Data Dictionaries entstehen in der Definitions- phase einer Anwendung und werden während des Entwurfs und der Implementierung ständig ergänzt und verfeinert. Auswahl einer bestimmten Notation: Beschreibung der Datenstrukturen und - elemente

43 © Prof. T. Kudraß, HTWK Leipzig Beispiel: Kunde in BNF Kundendatei= {Kundeneintrag} Kundeneintrag= Personal-Nr. + Name + Adresse + (Geburtsdatum) + (Funktion) + Umsatz Name= Anrede + (Titel) + Vorname + Nachname Adresse= [Straße + Haus-Nr. | Postfach-Nr.] + (Länder-Kennzeichen) + PLZ + Ort + (Telefon) + (Fax)

44 © Prof. T. Kudraß, HTWK Leipzig Beispiel Kunde (Forts) Die Kundendatei besteht aus keinem, einem oder beliebig vielen Kundeneinträgen Ein Kundeneintrag besteht aus der Personal-Nr., dem Namen, der Adresse und dem Umsatz (Muss-Angaben). Optional sind Geburtsdatum und die Funktion (Kann-Angaben). Bei der Adresse wird entweder die Straße und die Haus-Nr. oder die Postfach-Nr. angegeben, gefolgt von PLZ und Ort. Optional sind Länderkennzeichen, Telefon- und Fax-Nummer.

45 © Prof. T. Kudraß, HTWK Leipzig Repository-Systeme Anwendungen – Systementwicklung und Software-Reengineering – Content-Management – Service-Repository / Registry / Directory – IT-Infrastrukturmanagement (Konfigurationsdatenbank, ITIL) Systeme – Artifactory Maven Enterprise Repository (für firmenweite Repositories) – CentraSite (SOA Repository der Software AG)