Slide - Lehrstuhl für Betriebswirtschaftslehre

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
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 2
Rückblick
User
Presentation
•  Was versteht man unter Daten im Kontext
von Informationssystemen?
Business Logic
Data
is provided
by some
•  Wie werden Daten modelliert, so dass sie
von Informationssystemen genutzt werden
können?
•  Wie können Daten gespeichert und
verarbeitet werden?
Infrastructure
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 3
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.
“A reinterpretable representation of
information in a formalized manner,
suitable for communication,
interpretation or processing.“
2. Wirtschaftsinformatik: Zum Zweck der Verarbeitung
zusammengefasste Zeichen, die aufgrund bekannter oder
unterstellter Abmachungen Informationen (d.h. Angaben
über Sachverhalte und Vorgänge) darstellen.
(Technologiestandard ISO/IEC 2382-1)
(Gabler Wirtschaftslexikon)
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 4
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)
Begriff
Zeichen
Gegenstand
'Baum'
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 5
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
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Trillion
Slide 6
Kategorisierung von Daten
o  Strukturierte Daten
•  Daten unterliegen einer allgemeinen Struktur - Datenmodell liegt vor
•  z.B. relationales Datenbankmodell für Datenbanken
<?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>
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
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 7
Semi-strukturierte Daten
Beispiel Email
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 8
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
• 
• 
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
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Abstract Information System Model (AISM)
(Maass & Janzen, 2011; Ferstl & Sinz, 2006)
Slide 9
Vorgehen bei der Datenmodellierung
Relevante Objekte der
“realen Welt” im Kontext
des Informationssystems,
z.B. Personen
(1)
Konzeptueller
Entwurf
(2)
Logischer
Entwurf
(3)
Physischer
Entwurf
Konzeptuelles Modell
Fachliches Abbild durch
Typisierung und
Beschreibung, z.B. EntityRelationship-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 10
(1) Konzeptioneller Entwurf
• 
• 
• 
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)
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)
(Bildquelle: wikipedia.de)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 11
Entity-Relationship-Modell
Komponenten des ERD (Chen-Notation)
Entitätstyp (Entity): Typisierung gleichartiger Entitäten, d.h.
Dinge / Objekte der Wirklichkeit, die eindeutig identifizierbar
sind, z.B. Student, Unternehmen, Projekt
Student
Student
Veranstaltung
besucht
Student
05.07.12
M
besucht
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
Vorname
N
Beziehungstyp (Relationship): Typisierung gleichartiger
Beziehungen zwischen zwei oder mehreren Entitäten, z.B.
Student besucht Veranstaltung
Veranstaltung
Kardinalität (Cardinality): Festlegung der Anzahl der
beteiligten Entitäten bei Beziehungstypen, z.B. Student
besucht M Veranstaltungen
Univ.-Prof. Dr.-Ing. Wolfgang Maass
Slide 12
Entity-Relationship-Modell
Komponenten des ERD
Beispiel in Chen- und UML-Notation
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.
(Bildquelle: wikipedia.de)
05.07.12
Univ.-Prof. Dr.-Ing. Wolfgang Maass
Slide 13
Entity-Relationship-Modell
Vorgehen
② 
③ 
④ 
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
Erstellung des ERD
① 
•  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
05.07.12
Univ.-Prof. Dr.-Ing. Wolfgang Maass
Slide 14
Dokumentation
des ERD
Darstellung von Details zu Entitäten, Attributen und Beziehungen - Ziel: einheitliche und
klare Kommunikation der detaillierten Sachverhalte
Vorgehen bei der Datenmodellierung
Relevante Objekte der
“realen Welt” im Kontext des
Informationssystems, z.B.
Personen
(1)
Konzeptueller
Entwurf
(2)
Logischer
Entwurf
(3)
Physischer
Entwurf
Konzeptuelles Modell
Fachliches Abbild durch
Typisierung und
Beschreibung, z.B. EntityRelationship-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 15
(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 16
(2) Logischer Entwurf
Relationales Datenbankmodell
Tabelle Kunden
KN Straße 1
Name Kunde
n
Adresse
hat
... Stadt Kundennummer
Name
10000
Max Müller
10001
Franziska Maier
10002
Schmid und Söhne GmbH
... 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
Tabelle Adressen
AdressID
Kundennummer
Straße
0
10000
Hauptstraße
1
10000
Bahnhofsstraße
...
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?
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 17
(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.
• 
• 
• 
Tabelle Kunden
Kundennummer
Name
Kundentyp
10000
Max Müller
0
10001
Franziska Maier
0
10002
Schmid und Söhne GmbH
1
Spalten/Columns:
Jede Spalte enthält ein Attribut eines Datensatzes in
einem festgelegten Datentyp (z.B. string (Text), integer
(Zahl), date)
Tabelle Kundentypen
TypID
Typbezeichnung
0
Privatkunde
1
Geschäftskunde
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 18
(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 19
(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 20
(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 21
(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 22
Vorgehen bei der Datenmodellierung
Relevante Objekte der
“realen Welt” im Kontext des
Informations-systems, z.B.
Personen
(1)
Konzeptueller
Entwurf
(2)
Logischer
Entwurf
(3)
Physischer
Entwurf
Konzeptuelles Modell
Fachliches Abbild durch
Typisierung und
Beschreibung, z.B. EntityRelationship-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 23
(3) Physischer Entwurf
• 
• 
• 
• 
Umsetzung des logischen Datenbankschemas in ein
physisches Datenbankschema: Formulierung aller
Angaben in der Syntax des DatenbankManagement-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)
SQL Kommandozeile
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)
DBMS Datenbank-­‐
Dateien Anwendung Datenbanksystem Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
mysql> drop database `Shop`;
Query OK, 0 rows
affected (0.04 sec)
Slide 24
(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 25
Speicherung und Verarbeitung von Daten im
Kontext des Cloud Computing
User
Presentation
Speicherung von
Daten
Business Logic
Data
is provided
by some
• 
• 
• 
Infrastructure
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
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)
Slide 26
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:
Vertiefung in
Veranstaltung “Web
Technologien” im
WS12/13
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
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 27
Alternative Ansätze zur Datenspeicherung
NoSQL-Typen
• 
Graphendatenbank, z.B. Neo4j: Speichern von komplexen
Baum- und Netzwerkstrukturen, z.B. bei Twitter um FollowerBeziehungen 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-WertPaare abgelegt sind
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 28
Speicherung und Verarbeitung von Daten im
Kontext des Cloud Computing
User
Verarbeitung von
Speicherung von
Daten
Daten
Presentation
Business Logic
Data
is provided
by some
•  Verarbeitung vieler Datensätze (Big Data)
•  schneller Import großer Datenmengen
•  sofortige Abfrage importierter Daten (RealtimeProcessing)
•  kurze Antwortzeiten auch bei komplexen
Abfragen
•  Möglichkeit zur Verarbeitung vieler gleichzeitiger
Abfragen (Concurrent Queries)
• 
• 
Infrastructure
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
• 
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)
Slide 29
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)
Performance: Speedup with respect to
sequential execution
1 - Workers:
Für große Datenmengen
Für Datenverarbeitung ohne viel
Synchronisation
Keine schnellen Antwortzeiten
Keine komplexen
Rechenoperationen
(Ranger et al., 2007)
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 30
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 31
Alternative Ansätze zur Verarbeitung von Big Data
MapReduce
User
Presentation
Business-Logic
Data
is provided
by some
?
Infrastructure
Univ.-Prof. Dr.-Ing. Wolfgang Maass
05.07.12
Slide 32
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 33
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 34
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 35
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 36
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 37
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
Univ.-Prof. Dr.-Ing. Wolfgang Maass