Vorlesungsagenda Übersicht -...
Transcript of Vorlesungsagenda Übersicht -...
Informationsmanagement Vorlesung 10: Grundlagen der Datenmodellierung
Univ.-Prof. Dr.-Ing. Wolfgang Maass Lehrstuhl für Betriebswirtschaftslehre, insb. Wirtschaftsinformatik im Dienstleistungsbereich (Information and Service Systems ISS) Universität des Saarlandes, Saarbrücken SS 2012 Donnerstags, 10:00 – 12:00 Uhr (s.t.) Audimax, B4 1
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 2
Vorlesungsagenda Übersicht
1. Einleitung Managementsicht des Informationsmanagement
2. Grundlagen des Informationsmanagement 3. Aufgaben des Informationsmanagement – Management der Informationswirtschaft (2-stündig!) 4. Aufgaben des Informationsmanagement – Management der Informationssysteme und
Führungsaufgaben (2-stündig!) 5. Aufgaben des Informationsmanagement – IT-Controlling
Unternehmensarchitekturen 6. Grundlagen der Unternehmensarchitekturen – Gastvortrag Dr. Steffen Roehn (2-stündig!)
Systemarchitekturen 7. Architekturen von Informationssystemen 8. Webarchitekturen (2-stündig!) 9. Mobile & Cloud Computing
Datenmodellierung 10. Grundlagen der Datenmodellierung (2-stündig!) 11. Semantische Datenrepräsentationen (2-stündig!)
Prozessmodellierung 12. Grundlagen der Prozessmodellierung
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 3
Rückblick
Presentation Business Logic Data User
Infrastructure
is provided by some
• Was versteht man unter Daten im Kontext von Informationssystemen?
• Wie werden Daten modelliert, so dass sie von Informationssystemen genutzt werden können?
• Wie können Daten gespeichert und verarbeitet werden?
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 4
Was sind Daten?
1. Wirtschaftstheorie: Bezeichnung für volkswirtschaftliche Gegebenheiten, die den Wirtschaftsablauf beeinflussen, ohne von diesem selbst - zumindest unmittelbar und kurzfristig - beeinflusst zu werden. 2. Wirtschaftsinformatik: Zum Zweck der Verarbeitung zusammengefasste Zeichen, die aufgrund bekannter oder unterstellter Abmachungen Informationen (d.h. Angaben über Sachverhalte und Vorgänge) darstellen.
(Gabler Wirtschaftslexikon)
“A reinterpretable representation of information in a formalized manner,
suitable for communication, interpretation or processing.“
(Technologiestandard ISO/IEC 2382-1)
Informatik und Datenverarbeitung: • Daten = (maschinen-) lesbare und (maschinen-) bearbeitbare, in
der Regel digitale Repräsentation von Information ① Kodierung des Inhalts in Zeichen -> Syntax, z.B. Zahlenfolge
„123456“ = Aneinanderreihung von Ziffern ② Interpretation der Daten in einem Bedeutungskontext, um aus
ihnen Informationen zu gewinnen, z.B. Zahlenfolge „123456“ kann in Abhängigkeit vom Kontext für Telefonnummer, Kontonummer o.ä.
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 5
Was sind Daten?
• Semiotik (Wissenschaft der Zeichensysteme) definiert Daten als potenzielle Information
• Semiotisches Dreieck à Beziehung zwischen einem Zeichen und dem entsprechenden Gegenstand ist indirekt à sie verläuft über eine mentale Repräsentation des Gegenstands
• Erst über geistiges Konzept ('Begriff' genannt) wird die Zuordnung von Zeichen zu Objekten ermöglicht (Peirce, 1907; de Saussure, 1916)
Zeichen
Begriff
Gegenstand
'Baum'
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 6
1,8 Zettabytes an Daten! (Stand: 2011)
• Weltweit 1,8 Zettabytes (1021 Byte = 1.000.000.000.000.000.000.000 Byte = 1,8 Billionen Gigabytes) an digitalen Informationen (Stand 2011)
• Wachstum des Gesamtvolumens in den letzten 5 Jahren um den Faktor 5 Trillion
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 7
Kategorisierung von Daten
o Strukturierte Daten • Daten unterliegen einer allgemeinen Struktur - Datenmodell liegt vor • z.B. relationales Datenbankmodell für Datenbanken
o Semistrukturierte Daten • Daten unterliegen keiner allgemeinen Struktur, sondern tragen einen Teil der
Strukturinformation mit sich • z.B. HTML, Extensible Markup Language (XML), Email
o Unstrukturierte Daten • Digitalisierte Informationen, die in einer nicht formalisierten Struktur vorliegen • Automatische Nutzbarkeit unstrukturierter Daten stark eingeschränkt, da kein
Datenmodell vorliegt -> um Daten zu strukturieren, ist Modellierung erforderlich
• z.B. Grafiken, Audio-Daten, natürliche Sprache
Beispiel: E-Mail • Semistrukturiert – E-Mail liegt in gewisser Struktur vor: Empfänger, Absender, Text der E-Mail und
eventuell Betreff • Text der E-Mail ist aber unstrukturiert
<?xml version="1.0" encoding="UTF-8"?> <rezept xmlns:lm="http://lebensmittel.org"> <zutaten anzahl="3"> <lm:zutat>Ei</lm:zutat> <lm:zutat>Mehl</lm:zutat> <lm:zutat>Salz</lm:zutat> </zutaten> <anleitung> Alles zusammenrühren und backen. </anleitung> <foto><![CDATA[BELIEBIGE DATEN]]> </foto> </rezept>
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 9
Datenmodellierung
• Datenmodellierung = Verfahren der Informatik zur formalen Abbildung der in einem definierten Kontext relevanten Objekte mittels ihrer Attribute und Beziehungen
• Ziel: eindeutige Definition und Spezifikation der in einem Informationssystem zu verwaltenden Objekte, ihrer erforderlichen Attribute und der Zusammenhänge zwischen den Informationsobjekten
• Vorteil: Überblick über die Datensicht des Informationssystems
• Ergebnis: Datenmodelle, die nach dem Durchlauf mehrerer Modellierungsstufen zu einsatzfähigen Datenbanken bzw. Datenbeständen führen
(Maass & Janzen, 2011; Ferstl & Sinz, 2006)
• Datenmodelle -> längere Lebensdauer als Funktionen und Prozesse (Software) - "Data is stable – functions are not."
• "Daten sind Allgemeingut." -> sollten den Anwendungen zur Verfügung stehen, die sie benötigen und nicht (ausschließlich) einer bestimmten IT-Anwendung gehören
Abstract Information System Model (AISM)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 10
Relevante Objekte der “realen Welt” im Kontext
des Informationssystems, z.B. Personen
Vorgehen bei der Datenmodellierung
(1)
Konzeptueller Entwurf
(2)
Logischer Entwurf
(3)
Physischer Entwurf
Konzeptuelles Modell Fachliches Abbild durch
Typisierung und Beschreibung, z.B. Entity-
Relationship-Modell
Logisches Datenbankschema
Datentechnische Festlegung des
Datenbankmodells, z.B. Schlüssel
Physisches Datenbankschema
Script zur Erstellung der Datenbank gemäß
Datenbank Management System (DBMS)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 11
(1) Konzeptioneller Entwurf
• ERM … • … besteht aus Grafik – ER-Diagramm (ERD) – und
textueller Beschreibung der darin verwendeten Elemente
• … behandelt das “Was” (Sachlogik) und nicht das “Wie” (Technik)
• … stellt Datenstrukturen vereinfacht dar -> erleichtert interdisziplinäre Arbeit am Datenbestand des Informationssystems
• ... erfasst Informationsobjekte der realen Welt (z.B. Angestellter, Projekte) und verbindet diese mittels Beziehungen (z.B. Angestellter – leitet -Projekt)
• Betrachtung eines Ausschnitts der realen Welt -> Analyse sowie grafische und textuelle Beschreibung der Objekte mit allen relevanten Eigenschaften
• De-facto Standard für den konzeptuellen Entwurf im Rahmen der Datenmodellierung = Entity Relationship Modell (ERM) (Chen, 1976)
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 12
Entitätstyp (Entity): Typisierung gleichartiger Entitäten, d.h. Dinge / Objekte der Wirklichkeit, die eindeutig identifizierbar sind, z.B. Student, Unternehmen, Projekt
Entity-Relationship-Modell Komponenten des ERD (Chen-Notation)
Student
N
Student Veranstaltung
Vorname
besucht
Student Veranstaltung besucht
M
Beziehungstyp (Relationship): Typisierung gleichartiger Beziehungen zwischen zwei oder mehreren Entitäten, z.B. Student besucht Veranstaltung
1:N – Beziehung: 1 Geschäftsstelle : N Mitarbeiter M:N –Beziehung: M Projekte : N Projektarbeiter 1:1 – Beziehung: 1 Geschäftsführer : 1 Person
Attribut (Value): Typisierung gleichartiger Eigenschaften von Entitäten, z.B. Nachname, Vorname für Entitätstyp Student -> Attribute, die Entität eindeutig beschreiben, werden identifizierende Attribute genannt, z.B. Projektnummer für Entitätstyp Projekt
Kardinalität (Cardinality): Festlegung der Anzahl der beteiligten Entitäten bei Beziehungstypen, z.B. Student besucht M Veranstaltungen
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 13
Entity-Relationship-Modell Komponenten des ERD
Eine Person ist in maximal einem Ort geboren. Ein Ort ist Geburtsort von beliebig vielen Personen. Ein Ort kann ein Geburtsort sein, muss es aber nicht sein.
Beispiel in Chen- und UML-Notation
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 14
① Erkennen und Zusammenfassen von Entitäten zu Entitätstypen durch Abstraktion (z.B. Studenten Fritz Maier und Paul Lehmann -> Entitätstyp Student)
② Erkennen und Zusammenfassen von Beziehungen zwischen je zwei Objekten zu Beziehungstyp (z.B. Student Paul Lehmann besucht Vorlesung “Informationsmanagement” und Student Fritz Maier besucht Vorlesung “Web Technologien” -> Beziehungstyp „Student besucht Vorlesung“
③ Bestimmung der Kardinalitäten -> Darf ein Student mehrere Vorlesungen besuchen? Von wie vielen Studenten kann eine Vorlesung besucht werden?
④ Bestimmung relevanter Attribute für Entitätstypen, z.B. Vorname, Nachname bei Typ Student
Entity-Relationship-Modell Vorgehen
Darstellung von Details zu Entitäten, Attributen und Beziehungen - Ziel: einheitliche und klare Kommunikation der detaillierten Sachverhalte • Beschreibung der Attribute, Entitätstypen und Beziehungen, z.B. Beispiele für Entitäten,
Aussagen von Beziehungen (Mitarbeiter leitet Projekt), Wertebereiche für Attribute (Alter: 1-99)
• Bestimmen geeigneter Attribute eines Entitätstyps als identifizierende(s) Attribut(e), z.B. Matrikelnummer für Typ Student
Dokum
entation des ER
D
Erstellung des ERD
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 15
Relevante Objekte der “realen Welt” im Kontext des
Informationssystems, z.B. Personen
Vorgehen bei der Datenmodellierung
(1)
Konzeptueller Entwurf
(2)
Logischer Entwurf
(3)
Physischer Entwurf
Konzeptuelles Modell Fachliches Abbild durch
Typisierung und Beschreibung, z.B. Entity-
Relationship-Modell
Logisches Datenbankschema
Datentechnische Festlegung des
Datenbankmodells, z.B. Schlüssel
Physisches Datenbankschema
Script zur Erstellung der Datenbank gemäß
Datenbank Management System (DBMS)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 16
(2) Logischer Entwurf
• Überführung eines konzeptuellen Modells in ein logisches Datenbankschema • Diverse Datenbankmodelle, z.B. relational, objektorientiert, graphenbasiert • Bekanntestes Datenbankmodell -> Relationales Datenbankmodell (Codd, 1983):
Speicherung von Daten auf Basis von teilweise untereinander verknüpften Tabellen Datenbankmodell hat drei Eigenschaften (Codd, 1980) ① Generische Datenstruktur, die die Struktur von Daten in einer Datenbank beschreibt
• Beispiel: relationale Datenbank besteht aus Relationen (Tabellen) mit eindeutigen Namen • Relation = Menge von Tupeln (Datensätzen) gleichen Typs • Relationen und ihre Attribute (Spalten) können beliebig gewählt werden
② Menge von generischen Operatoren, die man auf die Datenstrukturen (siehe 1) anwenden kann, um Daten einzutragen, zu ändern, abzufragen oder abzuleiten
③ Menge von Integritätsbedingungen, mit denen die zulässigen Datenbankinhalte über die Datenstrukturen (siehe 1) weiter einschränken kann
• Beispiel: im relationalen Datenbankmodell kann jedes Attribut einer Relation als eindeutig bestimmt werden -> zwei Tupel dieser Relation dürfen dann nicht den gleichen Wert in diesem Attribut haben, ansonsten Verletzung der Integritätsbedingungen
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 17
(2) Logischer Entwurf Relationales Datenbankmodell
Kernfragen: • Welche Tabellen benötige ich? • Welche Spalten in den Tabellen benötige ich? • Wie sehen die möglichen Beziehungen zwischen den verschiedenen Datensätzen aus?
Kundennummer Name
10000 Max Müller
10001 Franziska Maier
10002 Schmid und Söhne GmbH
Tabelle Kunden
AdressID Kundennummer Straße ...
0 10000 Hauptstraße
1 10000 Bahnhofsstraße
Tabelle Adressen
Kunde
KN
Name
...
Adresse hat 1 n
Straße
Stadt
...
Aufgaben des logischen Entwurfs u.a.: • Überführung des ERM in relationales Datenschema • Festlegung der identifizierenden Schlüssel • Festlegungen zur technischen Umsetzung von
Beziehungen • Methodische Überprüfung der modellierten Ansätze
durch Normalisierung
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 18
(2) Logischer Entwurf Relationales Datenbankmodell - Terminologie
• Datenbank/Database: Ein Behältnis zum Speichern von Daten
Relationales Datenbankmodell: • Tabelle/Table:
Der Teil einer Datenbank, welche die Daten enthält. Eine Tabelle hat Spalten/Columns zur Speicherung der zeilenweise abgelegten Daten.
Kundennummer Name Kundentyp
10000 Max Müller 0
10001 Franziska Maier 0
10002 Schmid und Söhne GmbH 1
Tabelle Kunden
TypID Typbezeichnung
0 Privatkunde
1 Geschäftskunde
Tabelle Kundentypen • Spalten/Columns: Jede Spalte enthält ein Attribut eines Datensatzes in einem festgelegten Datentyp (z.B. string (Text), integer (Zahl), date)
• Zeile/Row: Der Datensatz in einer Tabelle
• Primärschlüssel/Primary Key: Eine oder mehrere Spalten, welche eindeutige Werte zur Referenzierung eines Datensatzes enthalten, z.B. Kundennummer
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 19
(2) Logischer Entwurf Vorgehen - Normalisierung
• Minimierung von Redundanzen und inneren Abhängigkeiten Normalisierung eines relationalen Datenschemas = Zerlegung von Relationen (Tabellen) gemäß Normalisierungsregeln -> 4 Normalformen (Codd, 1970) (Normalform 1-3 sind Gegenstand dieser VL)
• Datenredundanzen können zu inkonsistenten Datenbeständen führen, da der Fall eintreten kann, dass mehrfach enthaltene Daten nur teilweise geändert werden -> zudem unnötig Speicherplatz
• Vorgehen um ein relationales Datenschema in eine Normalform zu bringen -> fortschreitend Tabellen in einfachere Tabellen zerlegen bis keine weitere Zerlegung mehr möglich ist ohne Verlust von Daten
• Essentiell: das Schlüsselkonzept -> ein Schlüssel ist eine Menge von Attributen (eines oder mehrere), die eine Datenzeile einer Tabelle eindeutig identifiziert, z.B. Kunden-ID
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 20
(2) Logischer Entwurf Vorgehen - Normalisierung
1. Normalform (1NF): Jedes Attribut der Relation muss einen atomaren Wertebereich haben. • Zusammengesetzte Wertebereiche sind nicht erlaubt • Ziel: kein Attributwertebereich kann in weitere (sinnvolle) Teilbereiche aufgespalten werden, z.B.
Adresse wird aufgeteilt in PLZ, Ort, Straße, Hausnummer • Nutzen: Abfragen der Datenbank werden erleichtert bzw. überhaupt erst ermöglicht, da die
Attributwertebereiche atomar sind; Felder, die einen ganzen Text aus Titel, Vorname und Nachname enthalten, kann man nicht nach dem Nachnamen sortieren
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 21
(2) Logischer Entwurf Vorgehen - Normalisierung
2. Normalform (2NF): Eine Relation ist in der zweiten Normalform, wenn die erste Normalform vorliegt und kein Nichtschlüsselattribut funktional abhängig von einer echten Teilmenge eines Schlüsselkandidaten ist. • Jedes Nichtschlüsselattribut ist von der Gesamtheit des Schlüssels abhängig
(nicht nur von einem Teil des Schlüssels) • Ziel: jede Tabelle modelliert nur einen thematischen Zusammenhang • Nutzen: Redundanz und damit Gefahr von Inkonsistenzen wird reduziert, da sich nur noch logisch/
sachlich zusammengehörige Information in einer Tabelle befindet
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 22
(2) Logischer Entwurf Vorgehen - Normalisierung
3. Normalform (3NF): Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und kein Nichtschlüsselattribut von einem Schlüsselkandidaten transitiv abhängt. • Ein Nichtschlüsselattribut darf nicht von einer Menge aus Nichtschlüsselattributen abhängig sein,
sondern nur direkt von einem Schlüssel abhängig sein • Ziel: jede Tabelle modelliert nur einen Sachverhalt • Nutzen: verbliebene thematische Durchmischungen werden behoben; nach der 3NF sind Tabellen
zuverlässig monothematisch
• Interpret einer CD lässt sich aus der CD_ID bestimmen, das Gründungsjahr der Band/Interpreten hängt vom Interpreten und damit transitiv von der CD_ID ab
• Datenredundanz: wird neue CD mit existierendem Interpreten eingeführt, so wird das Gründungsjahr redundant gespeichert
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 23
Relevante Objekte der “realen Welt” im Kontext des Informations-systems, z.B.
Personen
Vorgehen bei der Datenmodellierung
(1)
Konzeptueller Entwurf
(2)
Logischer Entwurf
(3)
Physischer Entwurf
Konzeptuelles Modell Fachliches Abbild durch
Typisierung und Beschreibung, z.B. Entity-
Relationship-Modell
Logisches Datenbankschema
Datentechnische Festlegung des
Datenbankmodells, z.B. Schlüssel
Physisches Datenbankschema
Script zur Erstellung der Datenbank gemäß
Datenbank Management System (DBMS)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 24
(3) Physischer Entwurf
• Umsetzung des logischen Datenbankschemas in ein physisches Datenbankschema: Formulierung aller Angaben in der Syntax des Datenbank-Management-System (DBMS) zur Datenbankgenerierung
• DBMS = Menge aus Komponenten zur Definition, Erstellung und Verwaltung von Datenbanken
• Abfrage und Manipulation der Daten überwiegend durch Datenbanksprache SQL (Structured Query Language)
• Beispiel: Anlegen einer Datenbank “Shop” sowie einer Tabelle “Kunden”, die anschließend wieder gelöscht werden mittels SQL (im Rahmen eines relationalen DBMS)
���mysql> create database `Shop`; Query OK, 1 row affected (0.00 sec) mysql> use `Shop`; Database changed ���mysql> create table `Kunden` (`Kundennummer` INT NOT NULL AUTO_INCREMENT, `Name` VARCHAR(45), PRIMARY KEY (`Kundennummer`)); Query OK, 0 rows affected (0.02 sec) ���mysql> drop table `Kunden`; Query OK, 0 rows affected (0.00 sec) mysql> drop database `Shop`; Query OK, 0 rows affected (0.04 sec)
SQL Kommandozeile
Datenbanksystem
Anwendung DBMS Datenbank-‐
Dateien
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 25
(3) Physischer Entwurf
Physischer Entwurf unter Einsatz von Generatoren automatisch oder halbautomatisch möglich, z.B. MySQL DBMS
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 26
Speicherung und Verarbeitung von Daten im Kontext des Cloud Computing
Presentation Business Logic Data User
Speicherung von Daten
• Relationale Datenbanken: Leistungsprobleme bei datenintensiven Applikationen, wie z.B. Indexierung von großen Dokumentmengen
• Effizient bei häufigen, kleinen oder große, seltenen Transaktionen
• Können schlecht mit gleichzeitig hohen Datenanforderungen und häufigen Datenänderungen umgehen (Agrawal et al., 2008)
Infrastructure
is provided by some
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 27
Alternative Ansätze zur Datenspeicherung NoSQL
• NoSQL = not only SQL (SQL = Sprache zur Definition, Abfrage und Manipulation von relationalen Datenbanken) -> Datenbanken, die einen nicht-relationalen Ansatz verfolgen
• Merkmale: - kein festgelegtes Datenbankschema - Nicht relational - Kann mit vielen Schreib-/Leseanfragen umgehen - Schwache Garantien hinsichtlich Konsistenz oder auf einzelne
Datensätze eingeschränkte Transaktionen - Unterstützung von verteilten Datenbanken mit redundanter
Datenhaltung auf vielen Servern -> Systeme können einfach skalieren und Ausfälle einzelner Server überstehen
• Bekannte Implementierungen, z.B. Google BigTable, Amazon Dynamo; Open-Source-Implementierungen, z.B. CouchDB, Apache Cassandra, MongoDB
• Anwendung von NoSQL-Ansatz z.B. bei Facebook, eBay
Vertiefung in Veranstaltung “Web Technologien” im
WS12/13
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 28
Alternative Ansätze zur Datenspeicherung NoSQL-Typen
• Graphendatenbank, z.B. Neo4j: Speichern von komplexen Baum- und Netzwerkstrukturen, z.B. bei Twitter um Follower-Beziehungen zwischen den Mitgliedern abzulegen
• Objektorientierte Datenbanken, z.B. db4objects: Speicherung von Daten als Objekte; Einbettung in Anwendungen, die ojektorientiert programmiert sind
• Spaltenorientierte Datenbanken, z.B. HBase: Inhalte werden spaltenweise statt zeilenweise abspeichert; Vorteile beim Festplattenzugriff
• Dokumentorientierte Datenbanken, z.B. CouchDB: Dokumente bilden Grundeinheit zur Speicherung der Daten, z.B. JSON-formatierte Dokumente (XML-basiert)
• Key/Value-Stores, z.B. memcached: Einfache schlüsselbasierende Zugriffe auf Daten, die als Schlüssel-Wert-Paare abgelegt sind
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 29
Speicherung und Verarbeitung von Daten im Kontext des Cloud Computing
Presentation Business Logic Data User
Verarbeitung von Daten
Speicherung von Daten
• Relationale Datenbanken: Leistungsprobleme bei datenintensiven Applikationen, wie z.B. Indexierung von großen Dokumentmengen
• Effizient bei häufigen, kleinen oder große, seltenen Transaktionen
• Können schlecht mit gleichzeitig hohen Datenanforderungen und häufigen Datenänderungen umgehen (Agrawal et al., 2008)
• Verarbeitung vieler Datensätze (Big Data) • schneller Import großer Datenmengen • sofortige Abfrage importierter Daten (Realtime-
Processing) • kurze Antwortzeiten auch bei komplexen
Abfragen • Möglichkeit zur Verarbeitung vieler gleichzeitiger
Abfragen (Concurrent Queries)
Infrastructure
is provided by some
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 30
Alternative Ansätze zur Verarbeitung von Big Data MapReduce
• MapReduce = von Google eingeführtes Framework für nebenläufige Berechnungen über große (mehrere Petabyte) Datenmengen auf Computerclustern (US-Patent 2010)
• Für große Datenmengen • Für Datenverarbeitung ohne viel
Synchronisation • Keine schnellen Antwortzeiten • Keine komplexen
Rechenoperationen
Performance: Speedup with respect to sequential execution
1 - Workers:
(Ranger et al., 2007)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 31
Alternative Ansätze zur Verarbeitung von Big Data MapReduce
2 - Datasize
(Ranger et al., 2007)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 32
Alternative Ansätze zur Verarbeitung von Big Data MapReduce
is provided by some
Infrastructure
Presentation Business-Logic Data User
?
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 33
Alternative Ansätze zur Verarbeitung von Big Data MapReduce
MapReduce Schritte: (1) Daten in Arbeitspakete aufteilen
(2) Arbeitspakete an die Knoten verteilen
(3) Map: Jeder Knoten wendet die Arbeitslogik auf sein eigenes Arbeitspaket an
Ergebnis: Liste aus Schlüssel/Wert-Paaren mit z.T. Schlüssel-Duplikaten
(4) Reduce: Zueinander gehörende Teilergebnisse (gleicher Schlüssel) werden aggregiert Ergebnis: Liste aus Schlüssel/Wert-Paaren mit einzigartigen Schlüsseln
(5) Weitere Zusammenführung zu Endergebnis
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 34
Alternative Ansätze zur Verarbeitung von Big Data MapReduce - Beispiel
Quelle: http://blog.jteam.nl/2009/08/04/introduction-to-hadoop/
Weiteres Beispiel zu MapReduce in der Übung am 12. Juli !
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 35
Alternative Ansätze zur Verarbeitung von Big Data MapReduce - Beispielimplementation
Apache Hadoop Distributed File System (HDFS) = Key-Value-Store (Hbase) + MapReduce Framework
Quelle: http://en.wikipedia.org/wiki/Hadoop
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 36
Literatur
Bücher: • Ferstl, O. K. & Sinz, E. J. (2006), Grundlagen der Wirtschaftsinformatik, Oldenbourg Wissenschaftsverlag. • Peirce, C. S. (1907), Pragmatism. • de Saussure, F. (1995), Cours de linguistique générale, PAYOT. • Embley, D. W. & Thalheim, B., ed. (2011), Handbook of Conceptual Modeling: Theory, Practice, and Research Challenges, Springer.
Paper: • Agrawal, R.; Ailamaki, A.; Bernstein, P. A.; Brewer, E. A.; Carey, M. J.; Chaudhuri, S.; Doan, A.; Florescu, D.; Franklin, M. J.; Garcia-Molina, H.;
Gehrke, J.; Gruenwald, L.; Haas, L. M.; Halevy, A. Y.; Hellerstein, J. M.; Ioannidis, Y. E.; Korth, H. F.; Kossmann, D.; Madden, S.; Magoulas, R.; Ooi, B. C.; O'Reilly, T.; Ramakrishnan, R.; Sarawagi, S.; Stonebraker, M.; Szalay, A. S. & Weikum, G. (2008), 'The Claremont report on database research', SIGMOD Rec. 37(3), 9—19.
• Chen, P. P.-S. (1976), 'The Entity-Relationship Model–Toward a Unified View of Data', ACM Transactions on Database Systems 1(1). • Codd, E. F. (1983), 'A relational model of data for large shared data banks', Commun. ACM 26(1), 64—69. • Codd, E. F. (1980): Data models in database management, Proceedings of the 1980 Workshop on Data Abstraction, Databases and Conceptual
Modeling, • Maass, W. & Janzen, S. (2011), Pattern-Based Approach for Designing with Diagrammatic and Propositional Conceptual Models, in '6th Int. Conf.
on Design Science Research in Information Systems and Technology (DESRIST 2011), Milwaukee, Wisconsin, USA’. • Ranger, C.; Raghuraman, R.; Penmetsa, A.; Bradski, G. & Kozyrakis, C. (2007), Evaluating MapReduce for Multi-core and Multiprocessor
Systems, in 'Proceedings of the 2007 IEEE 13th International Symposium on High Performance Computer Architecture', IEEE Computer Society, Washington, DC, USA, pp. 13—24.
Web: • http://wirtschaftslexikon.gabler.de/ • http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=7229 • http://blog.jteam.nl/2009/08/04/introduction-to-hadoop/
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12 Slide 37
Vorlesungsagenda Übersicht
1. Einleitung Managementsicht des Informationsmanagement
2. Grundlagen des Informationsmanagement 3. Aufgaben des Informationsmanagement – Management der Informationswirtschaft (2-stündig!) 4. Aufgaben des Informationsmanagement – Management der Informationssysteme und
Führungsaufgaben (2-stündig!) 5. Aufgaben des Informationsmanagement – IT-Controlling
Unternehmensarchitekturen 6. Grundlagen der Unternehmensarchitekturen – Gastvortrag Dr. Steffen Roehn (2-stündig!)
Systemarchitekturen 7. Architekturen von Informationssystemen 8. Webarchitekturen (2-stündig!) 9. Mobile & Cloud Computing
Datenmodellierung 10. Grundlagen der Datenmodellierung (2-stündig!) 11. Semantische Datenrepräsentationen (2-stündig!)
Prozessmodellierung 12. Grundlagen der Prozessmodellierung