3.1 daten und datenbanken

3 Daten, Informationen und Wissen
3.1 DATEN UND DATENBANKEN
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
100
Daten als Grundlage für Wissen und Entscheidungen
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
101
Nicht-integrierte Datenverarbeitung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
102
Integrierte Datenverarbeitung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
103
Ziele und Vorteile der Datenintegration
Ziele der Datenintegration:
• Fachlich gleiche Daten werden nur einmal gespeichert
• Datenzugriff für alle betroffenen Anwender und Anwendungen möglich
Vorteile der Datenintegration:
• Verringerung von Datenredundanzen
• Erhöhung der Datenintegrität
• Reduktion des Erfassungsaufwandes
• Schaffen der Voraussetzungen für Funktions- und Prozessintegration
• Rationalisierung und Beschleunigung von Arbeitsabläufen
• Insgesamt verbesserte Informationsversorgung der Entscheidungsträger
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
104
Klassifizierung von Daten
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
105
Grundbegriffe der Datenorganisation - Dateien
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
106
Grundbegriffe der Datenorganisation - Dateien
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
107
Grundbegriffe der Datenorganisation - Datenbanken
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
108
Dateiorganisation vs. Datenbankorganisation
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
109
Dateiorganisation vs. Datenbankorganisation
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
110
Datenbanksysteme (DBS)
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
111
Drei-Ebenen-Architektur von DBS
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
112
Komponenten von DBS
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
113
Anforderungen an DBS
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
114
Qualität von Daten (1/2)
•
•
Datenqualität = Relevanz und Korrektheit von Daten
Daten schlechter Qualität enthalten:
–
–
–
–
–
•
Maßnahmen zur Gewährleistung von hoher Datenqualität:
–
–
–
–
–
Mai-17
Datenfehler
Dubletten
Fehlende Werte
Falsche Formatierungen
etc.
Standardisierte Dateneingabe (vorformatierte Eingabefelder)
Fehlerprüfung bei der Eingabe (Integritätsbedingungen, Vollständigkeit)
Regeln für Schreib- und Lesezugriffe bei der manuellen und automatisierten Datenverarbeitung
Sicherstellung der Stabilität und Sicherheit von Datenschnittstellen
Datensicherheitsmaßnahmen (Vertraulichkeit, Integrität, Verfügbarkeit)
Dipl.-Wirt.-Inf. Nico Michalak
115
Qualität von Daten (2/2)
Qualitätsmerkmale von Daten:
• Glaubwürdigkeit: Daten werden als wahr und glaubwürdig erachtet
• Fehlerfreiheit: Daten sind korrekt und verlässlich
• Objektivität: Daten sind unvoreingenommen und neutral
• Hohes Ansehen: Quellen der Daten stehen im Ruf einer hohen Vertrauenswürdigkeit
• Wertschöpfung: Daten liefern einen Mehrwert
• Relevanz: Daten lassen sich für eine konkrete Aufgabe nutzen
• Aktualität: Alter der Daten ist der konkreten Aufgabe angemessen
• Vollständigkeit: Umfang und Detaillierungsgrad der Daten sind der konkreten Aufgabe
angemessen
• Angemessene Menge: Menge der vorhandenen Daten ist weder zu gering noch zu hoch
• Interpretierbarkeit: Daten sind klar definiert und in einer angemessen Sprache und Einheit
dargestellt
• Gute Verständlichkeit: Daten sind eindeutig und leicht verständlich
• Einheitliche Darstellung: Daten sind einheitlich formatiert und mit früheren Daten kompatibel
• Übersichtlichkeit: Daten sind in kompakter und dennoch vollständiger Form gespeichert
• Zugänglichkeit: Daten sind verfügbar oder leicht abrufbar
• Zugangssicherheit: Zugang zu den Daten kann eingeschränkt werden
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
116
3 Daten, Informationen und Wissen
3.2 DATENMODELLIERUNG
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
117
Rahmenbedingungen der Datenmodellierung
•
Aufgabe:
– möglichst exakte, standardisierte Beschreibung eines Realitätsausschnitts
•
Ziel:
– Datenintegration
•
Vorgehen:
– Ableitung sachlogischer Objekte des Realitätsausschnitts (z. B. Kunden- Artikeldaten)
– Modellierung von Beziehungen zwischen diesen Objekten (z. B. Kunde kauft Artikel)
– Konkretisierung der Objekte durch Attribute
•
De-Facto-Standard:
– Entity-Relationship (ER)-Methode
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
118
Entity-Relationship-Modell (ERM)
•
•
•
Mai-17
Das Entity-Relationship-Modell (ERM) ist ein Hilfsmittel zur Darstellung eines
konzeptionellen Datenmodells.
Das Datenmodell hält auf logischer Ebene die im Betrachtungsbereich relevanten
Objekte (Entities) und Beziehungen (Relationships) zwischen diesen formal fest.
Objekte und Beziehungen können durch Eigenschaften (Attribute) näher beschrieben
werden.
Dipl.-Wirt.-Inf. Nico Michalak
119
Zweck des ERM
•
•
•
Mai-17
Beschreibung der gespeicherten Daten und ihrer Beziehungen untereinander
Die plastische Darstellung der Datenbeziehungen in einem Unternehmen durch ein
Datenmodell liegt nah an der menschlichen Wahrnehmungsweise
Liefert eine geeignete, leicht nachvollziehbare Arbeits-und Diskussionsgrundlage für
Nutzer, Entwickler, Auftraggeber und Projektteilnehmer
Dipl.-Wirt.-Inf. Nico Michalak
120
Entity und Entity-Typ
Entity(Gegenstand, Objekt, Instanz, Objektausprägung)
• Ein Objekt ist ein konkretes oder abstraktes Phänomen des Erfahrungsbereiches bzw. ein
wohlunterscheidbares Ding der realen Welt.
• Beispiele: ein Kunde, ein Mitarbeiter, ein Student, ein Vertrag, ein Termin, ein Buch
Entity-Typ (Objektmenge, Objekttyp)
• Ähnliche Objekte werden zu Objektmengen (Objekttypen) zusammengefasst.
• Alle Objekte einer Objektmenge werden durch dieselben Attribute beschrieben, können
aber für diese unterschiedliche Werte annehmen.
• Objekttypen werden in der Regel im Singular benannt.
• Beispiele: Kunde, Mitarbeiter, Student, Vertrag, Sitzungstermin, Buch
Buch
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
121
Attribut
Attribut (Merkmal, Eigenschaften)
• Ein Objekt wird durch Attribute beschrieben bzw. charakterisiert.
Schlüsselattribut
• Ein(e) Attribut(-kombination), die eine Entityeindeutig identifiziert.
• Beispiel: Ein Buch kann durch den Titel, Autor, Verlag und das Jahr beschrieben und über
die ISBN-Nummer eindeutig identifiziert werden.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
122
Attributwert und Domäne
Attributwert
• Ein konkretes Objekt hat für jedes seiner Attribute einen Wert.
• Beispiel:
– Ein Buch hat die ISBN-Nr. „3-409-42214-5“, den Titel „Die grenzenlose Unternehmung“, ist 2001
im Gabler Verlag erschienen und von den Autoren Picot/Reichwald/Wigand geschrieben
worden.
Domäne (Domain, Wertebereich)
• Die zulässigen Werte der Attribute eines Objektes werden durch eine Domäne
(Wertebereich) beschrieben.
• Beispiel:
– Steuerklasse (Attribut), 6 (Attributwert), {1,2,3,4,5,6} (Wertebereich)
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
123
Relation und Relationship-Typ
Relation (Beziehung, Beziehungsausprägung)
• Objekte können zueinander in Beziehung stehen.
• Beispiel: Heiko Pfalzgraf (Student) leiht sich das Buch „Die
• grenzenlose Unternehmung“ aus.
Relationship-Typ (Beziehungsmenge, Beziehungstyp)
• Ähnliche Beziehungen werden zu Beziehungstypen
• zusammengefasst. Auch Beziehungstypen können Eigenschaften
• (Attribute) besitzen.
• Beispiel: Beziehungstyp: „leiht aus", partizipierende Objekttypen:
• Student, Buch
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
124
Rolle und Kardinalität
Rolle
• Die Funktion, die ein Entitytyp in einem Relationship erfüllt.
Kardinalität (Komplexität) eines Beziehungstyps
• Über die Kardinalität eines Beziehungstyps wird eine Aussage darüber gemacht, mit wie
vielen anderen Objekten ein Objekt eines bestimmten Typs in einer konkreten Beziehung
stehen kann.
• Diese Sichtweise lässt sich als "objektzählend" charakterisieren.
• Die objektzählende Sichtweise wird meist als intuitiv verständlicher angesehen, bedarf
jedoch bei Beziehungstypen mit einem Grad größer 2 einer zusätzlichen Interpretation.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
125
Objektzählende Kardinalitäten: 1,n-Notation (1)
1:1-Beziehung
• Jedes Entity vom Typ1 steht mit genau einem Entity vom Typ2 in einer spezifizierten
Beziehung und umgekehrt
1:n-Beziehung
• Jedes Entity vom Typ1 kann mit mehreren Entities vom Typ2 in einer spezifizierten
Beziehung stehen, jedes Entity vom Typ2 jedoch nur mit einem Entity vom Typ1
m:n-Beziehung
• Jedes Entity vom Typ1 kann mit mehreren Entities vom Typ2 in einer spezifizierten
Beziehung stehen und umgekehrt
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
126
Objektzählende Kardinalitäten: 1,n-Notation (2)
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
127
Objektzählende Kardinalitäten: 1,n-Notation (3)
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
128
Generalisierung und Spezialisierung
•
•
Mai-17
Übergeordnete Begriffe, Teilmengen
„Is-a-Beziehung“
Dipl.-Wirt.-Inf. Nico Michalak
129
Aggregation
•
•
Mai-17
gemeinsamer Sachverhalt -der selbst ein Entitytyp ist
„is-part-of-Beziehung“
Dipl.-Wirt.-Inf. Nico Michalak
130
Erhebungsmethoden zur Datenmodellierung
•
•
•
•
•
Mai-17
Formularanalyse-Vorhandene Prozesse und Dokumente
Selbstaufschreibung betrieblicher Abläufe-Substantive ergeben Entitäten
Interviews – Feinheiten des Datenmodells
Analyse vorhandener Systeme - Datenstrukturen, Systemdokumentation
Referenzmodelle-Anwendungen implizit zugrundeliegende Datenstrukturen als Modelle
Dipl.-Wirt.-Inf. Nico Michalak
131
Beispiel 1
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
132
Beispiel 2
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
133
Übungsaufgabe
•
•
Mai-17
Zeichnen Sie für folgendes Szenario (Speditionsunternehmen mit mehreren LKW) ein ERDiagramm mit Angabe der Kardinalitäten.
Ein LKW wird von einem Fahrer gefahren. Das Unternehmen unterhält mehrere
Werkstätten zur Reparatur der LKW. In jeder Werkstatt werden mehrere LKW repariert,
aber jeder LKW hat eine ihm fest zugewiesenen Werkstatt. Die Mechaniker, die einer
Werkstatt jeweils fest zugeordnet sind, können verschiedene Reparaturarbeiten
durchführen. Bei vielen Reparaturarbeiten besitzen auch mehrere Mechaniker in der
jeweiligen Werkstatt die Fähigkeit, diese durchzuführen.
Dipl.-Wirt.-Inf. Nico Michalak
134
Übungsaufgabe 2:
•
•
Mai-17
Wie könnte man den Faktor Zeit in ERMs darstellen? Versuchen Sie Ihre Methode an
folgendem Beispiel!
Ein Kunde verlegt seinen Firmensitz. Diese Änderung wird ab einem bestimmten Datum
gültig sein.
Dipl.-Wirt.-Inf. Nico Michalak
135
Aufgabe 3:
•
Mai-17
Was sagt folgendes Entity-Relationship-Diagramm aus? Gehen Sie konkret auf die
Beziehungen zwischen den Objekten und die Eigenschaften der Objekte ein.
Dipl.-Wirt.-Inf. Nico Michalak
136
Aufgabe 4:
Eine Beratungsfirma erhält den Auftrag, für das IOC (International OlympicCommittee) eine
Datenbank für die nächsten Olympischen Spiele zu erstellen, die folgenden
Wirklichkeitsausschnitt enthalten soll.
Die einzelnen Wettkämpfe der Olympischen Spiele sind durch den Namen der Sportart, den
Termin und die Sportstätte gekennzeichnet. An jedem Wettkampf nehmen mehrere Sportler
teil, die durch eine Startnummer identifiziert werden und außerdem natürlich, wie jede
Person, einen Namen besitzen. Jeder Wettkampf wird von einem Schiedsrichter geleitet,
dem für diese Spiele eine eindeutige Personalnummer zugeordnet wurde. Die Schiedsrichter
werden bei einem Wettkampf von verschiedenen Helfern unterstützt, die ebenfalls eine
eindeutige Personalnummer erhalten haben. Die Sportler und Schiedsrichter gehören
jeweils einer Nation an, zu der der Name des Mannschaftsleiters und eine Telefonnummer
für Rückfragen abgespeichert werden. Dies gilt zwar ebenfalls für die Helfer, soll jedoch hier
nicht berücksichtigt werden.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
137
Übungsaufgabe: ERM
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
138
3 Daten, Informationen und Wissen
3.3 DATENBANKMODELLE
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
139
Relationales Datenbankmodell
•
•
•
•
Basiert auf mathematisch definierten Grundstrukturen
Einziges Strukturelement: Relation = Tabelle mit einer festen Anzahl von Spalten und
einer beliebigen Anzahl von Zeilen (=Entities oder sog. Tupel)
Jedes Tupel muss über einen Primarschlüssel identifiziert werden
Grundlage der Datenstrukturierung bei relationalen Datenbanken: Normalformenlehre
– Normalisieren = Überführung der DB-Struktur in eine Form, die den Anforderungen der
Redundanzfreiheit, Datenkonsistenz und Datenintegrität genügt
– In der Praxis unterscheidet man drei Normalformen
•
Mai-17
Vorteile: hohe Nutzungsflexibilität durch vielfältige und einfach durchzuführende
Datenmanipulationen, große Verbreitung relationaler Datenbanken
Dipl.-Wirt.-Inf. Nico Michalak
140
Relationales Datenbankmodell
•
•
•
•
Mai-17
Das relationale Datenmodell besteht aus einer Anzahl zweidimensionaler
Datensammlungen, die „Relation“ oder „Tabellen“ genannt werden.
Tabellen sind die Basis der relationalen Datenbanken
Entitäten und teilweise auch Beziehungen werden in Tabellenform gebracht
Überleitung des ER-Diagramms in Tabellen wird "Relationale Auflösung„ genannt
Dipl.-Wirt.-Inf. Nico Michalak
141
ER Modell in Relation überführen
•
•
•
Mai-17
Entitätstyp wird Tabelle
Attribute werden Spalten (die Anordnung ist beliebig)
Einzelne Objekte entsprechen den Zeilen (Tupel)
Dipl.-Wirt.-Inf. Nico Michalak
142
ERM wird Tabelle
•
Jeder Entitytyp wird auf eine Tabelle (Relation) abgebildet. Der Name der Tabelle ist der
Name der Entity.
•
1:N bzw. N:1 Konnektivitäten werden mittels zwei Relationen dargestellt. Die N-Tabelle
enthält den Primärschlüssel der 1-Beziehung als Fremdschlüssel.
•
Bei einer 1:1 Beziehung ist es ebenso, nur dass es keine Rolle spielt, welche Relation den
Fremdschlüssel enthält.
•
Jede M:N Beziehung wird mit Hilfe einer weiteren Tabelle (eine zusätzliche Dritte)
abgebildet. Der Name der Tabelle ist der Name des Beziehungstyps. Darin sind die
Primärschlüssel der Entitytypen anzuführen.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
143
1:1-Beziehung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
144
1:N-Beziehung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
145
N:M-Beziehung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
146
Beispiel zum relationalen Modell
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
147
Eigenschaften von Relationen
•
•
•
•
•
Mai-17
Es gibt keine zwei identischen Tupel in einer Relation
Die Tupel einer Relation unterliegen keiner Ordnung
Die Attribute einer Relation unterliegen keiner Ordnung
Die Attributwerte von Relationen sind atomar
Die Spalten einer Tabelle sind homogen
Dipl.-Wirt.-Inf. Nico Michalak
148
Darstellung einer N:1-Beziehung im relationalen Modell
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
149
Darstellung einer N:M-Beziehung im relationalen Modell
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
150
Kategorisierung von Schlüsselfeldern
•
Primärschlüssel
– Identifiziert durch seine Wertausprägung einen Datensatz eindeutig
– Einfacher Primärschlüssel = ein Attribut (oft als sog. „künstlicher“ Schlüssel, wie z. B.
Personalnummer)
– Zusammengesetzter Primärschlüssel = mehrere Attribute
•
Sekundärschlüssel
– Alle Attributkombinationen mit datensatzidentifizierenden Eigenschaften, die nicht
Primärschlüssel sind (z. B. Name, Vorname und Geburtsdatum neben einem Primärschlüssel
„Personalnummer“)
•
Fremdschlüssel
– Sind Primärschlüssel in anderen Tabellen bzw. Dateien
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
151
Objektorientiertes Datenbankmodell
•
„Dinge“ werden als Objekte dargestellt. Jedes Objekt
– hat ein Verhalten, das durch Operationen ausgelöst wird („Methoden“)
– hat einen Zustand, der durch Werte von Attributen dargestellt wird
– kann Beziehungen zu anderen Objekten haben
•
Mai-17
Ein Objekttyp (Klasse) umfasst gleiche Objekte
Dipl.-Wirt.-Inf. Nico Michalak
152
Aggregationen im OO-Modell
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
153
Vor- und Nachteile von OO-Modellen
•
Vorteile:
– Manipulationen können durch Referenzen automatisch auf mehreren Objekten ausgeführt
werden
– Objekte können an mehreren Beziehungen beteiligt sein, werden aber nur einmal gespeichert
(Vermeidung von Redundanzen)
– Bessere Wiederverwendbarkeit, höhere Anschaulichkeit
•
Nachteile:
– Kein Bezug zu objektorientierten Programmiersprachen (z. B. C++ oder Java) vorhanden
– Hohe Komplexität
– Bislang wenig praktische Bedeutung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
154
Beziehungen im relationalen & objektorientierten Datenbankmodell
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
155
Erste Normalform (1NF)
•
•
Eine Relation ist in der ersten Normalform (1NF), wenn alle Attribute nur atomare Werte
enthalten.
Praktischer Nutzen:
– Abfragen der Datenbank werden durch die 1NF erleichtert bzw. überhaupt erst ermöglicht, wenn die
Attributwertebereiche atomar sind. So ist es beispielsweise in einem Feld, das einen ganzen
Namensstring aus Titel, Vorname und Nachname enthält, schwierig bis unmöglich, nach Nachnamen
zu sortieren.
•
Nachfolgendes Beispiel befindet sich demnach nicht in der 1NF:
– Das Feld Album enthält die Attributwertebereiche Interpret und Albumtitel.
– Das Feld Titelliste enthält eine Menge von Titeln.
•
Dadurch hat man ohne Aufspaltung folgende Probleme bei Abfragen:
– Zur Sortierung nach Albumtitel muss das Feld Album in Interpret und Albumtitel aufgeteilt werden.
– Die Titel können (mit einfachen Mitteln) nur alle gleichzeitig als Titelliste oder gar nicht dargestellt
werden.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
156
Erste Normalform (1NF) Lösung
•
Die Attributwertebereiche werden in atomare Attributwertebereiche aufgespalten:
– Das Feld Album wird in die Felder Albumtitel und Interpret gespalten.
– Das Feld Titelliste wird in die Felder Track und Titel gespalten sowie auf mehrere Datensätze
aufgeteilt.
•
Mai-17
Da jetzt jeder Attributwertebereich atomar ist sowie die Tabelle einen eindeutigen
Primärschlüssel (Verbundschlüssel aus den Spalten CD_ID und Track) besitzt, befindet
sich die Relation in 1NF.
Dipl.-Wirt.-Inf. Nico Michalak
157
Zweite Normalform (2NF)
•
•
•
Eine Relation ist in der zweiten Normalform (2NF), wenn sie in der 1NF ist und jedes
Nicht-Schlüssel-Attribut voll funktional abhängig ist vom Gesamtschlüssel.
Jedes nicht-primäre Attribut (nicht Teil eines Schlüssels) ist jeweils von
allen ganzen Schlüsseln abhängig, nicht nur von einem Teil eines Schlüssels. Wichtig ist
hierbei, dass die Nichtschlüsselattribute wirklich von allen Schlüsseln vollständig
abhängen.
Praktischer Nutzen:
– Jede Relation modelliert nur einen Sachverhalt.
– Dadurch werden Redundanz und die damit einhergehende Gefahr von Inkonsistenzen
reduziert. Nur noch logisch/sachlich zusammengehörige Informationen finden sich in einer
Relation. Dadurch fällt das Verständnis der Datenstrukturen leichter.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
158
Zweite Normalform (2NF)
•
Negativbeispiel, 2NF ist verletzt:
– Der Primärschlüssel der Relation ist aus den Feldern CD_ID und Track zusammengesetzt.
(Grundsätzlich darf ein Primärschlüssel aus mehreren Attributen bestehen, jedoch entsteht daraus im
genannten Beispiel ein Konflikt.)
– Die Felder Albumtitel, Interpret und Erscheinungsdatum sind vom Feld CD_ID abhängig, aber nicht
vom Feld Track. Dieser (Punkt 2) verletzt die 2. Normalform, da die drei nicht-primären Attribute
nicht nur von einem Teil des Schlüssels (hier CD_ID) abhängen dürfen. Wäre der Schlüssel nicht
zusammengesetzt (siehe Punkt 1), so könnte dies nicht passieren.
•
Probleme, die sich daraus ergeben:
– Die Informationen aus diesen drei Feldern sind, wie am Beispiel der CD Not That Kind zu erkennen,
mehrfach vorhanden, d. h. redundant.
– Dadurch besteht die Gefahr, dass die Integrität der Daten verletzt wird. So könnte man den
Albumtitel für das Lied Not That Kind in I Don’t Mind ändern, ohne jedoch die entsprechenden
Einträge für die Titel I’m Outta Love und Cowboys & Kisses zu ändern (Update-Anomalie).
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
159
Zweite Normalform (2NF)
•
Probleme, die sich daraus ergeben:
– Die Informationen aus diesen drei Feldern sind, wie am Beispiel der CD Not That Kind zu
erkennen, mehrfach vorhanden, d. h. redundant.
– Dadurch besteht die Gefahr, dass die Integrität der Daten verletzt wird. So könnte man den
Albumtitel für das Lied Not That Kind in I Don’t Mind ändern, ohne jedoch die entsprechenden
Einträge für die Titel I’m Outta Love und Cowboys & Kisses zu ändern (Update-Anomalie).
– In dem Fall ist ein Zustand erreicht, den man als Dateninkonsistenz bezeichnet. Über die
komplette Tabelle betrachtet, „passen“ die Daten nicht mehr zusammen.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
160
Zweite Normalform (2NF) Lösung
– Die Daten in der Tabelle werden in zwei Tabellen aufgeteilt: CD und Lied.
– Die Tabelle CD enthält nur noch Felder, die voll funktional von CD_ID abhängen, hat also CD_ID
als Primärschlüssel.
– Da keine weiteren (zusammengesetzten) Schlüsselkandidaten existieren, liegt die Tabelle damit
automatisch in der 2. Normalform vor.
– Die Tabelle "Lied" enthält schließlich nur noch Felder, die voll funktional von CD_ID und Track
abhängen, liegt also auch in der 2. Normalform vor.
•
•
Mai-17
Mit Hilfe dieser verlustfreien Zerlegung sind auch die genannten Redundanzen der Daten
beseitigt.
Das Attribut CD_ID aus der Tabelle Lied bezeichnet man als Fremdschlüssel, der auf den
Primärschlüssel der Tabelle CD verweist. Zugleich stellen die
Attribute CD_ID und Track den zusammengesetzten Primärschlüssel der Tabelle Lied dar.
Dipl.-Wirt.-Inf. Nico Michalak
161
Dritte Normalform (3NF)
•
Eine Relation ist in der dritten Normalform (3NF), wenn sie in der 1NF und der 2NF ist
und keine transitiven Abhängigkeiten enthält.
– Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und kein
Nichtschlüsselattribut (hellgraue Zellen in der Tabelle) von einem anderen
Nichtschlüsselattribut funktional abhängig ist.
•
Negativbeispiel 3NF ist verletzt:
– Offensichtlich lässt sich der Interpret einer CD aus der CD_ID bestimmen, das Jahr der
Gründung der Band/Interpreten hängt wiederum vom Interpreten und damit transitiv von
der CD_ID ab.
– Das Problem ist hierbei wieder Datenredundanz. Wird zum Beispiel eine neue CD mit einem
existierenden Interpreten eingeführt, so wird das Jahr der Gründung redundant gespeichert.
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
162
Dritte Normalform (3NF) Lösung
•
•
Mai-17
Die Relation wird aufgeteilt, wobei die beiden voneinander abhängigen Daten in eine
eigene Tabelle ausgelagert werden. Der Schlüssel der neuen Tabelle muss als
Fremdschlüssel in der alten Tabelle erhalten bleiben.
An der Tabelle "Lied" wurden keine Änderungen bei der Übertragung in die 3.
Normalform vorgenommen. Sie ist hier nur der Vollständigkeit halber gelistet.
Dipl.-Wirt.-Inf. Nico Michalak
163
SQL als Abfragesprache
•
•
Structured Query Language (SQL): meistverbreitete deklarative Abfragemethode für
relationale DBS
Befehle für:
– Erstellung von Datenbanken (DDL)
– Formulierung von Abfragen (QL)
– Durchführung von Veränderungen an Tabellen (DML)
•
Grundform einer Abfrage:
– SELECT a1, ...an [welche Attribute, z. B. Kundennr., Name]
– FROM r1, ...rn [aus welchen Relationen, z. B. Relation Kunde]
– WHERE x=...; [unter welchen Bedingungen, z. B. Kundenort = München]
•
Mai-17
Beispielabfrage:
SELECT Name FROM Kunde WHERE Kundennr=`6321552`
Dipl.-Wirt.-Inf. Nico Michalak
164
SQL als Abfragesprache
•
Erlaubt komplexere Abfragen mittels
– Verknüpfung von Relationen
– Gruppierungen
– Sortierfunktionen
•
•
•
•
Mai-17
Nutzung erfordert Programmierkenntnisse, daher wenig geeignet für direkten Einsatz am
Arbeitsplatz
Oft integriert in Anwendungsprogramme (embedded SQL)
Alternative: Query by Example (QBE) mittels Mustertabellen
Objektorientierte Abfragesprachen sind selten, Beispiel: OQL
Dipl.-Wirt.-Inf. Nico Michalak
165
3 Daten, Informationen und Wissen
3.4 VERNETZTE DATENBANKEN
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
166
Vernetzte Datenbanken
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
167
Verteilte Datenbanksysteme
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
168
Suchmaschinen
•
Recherche nach Informationen im Internet
= Suche nach Informationen in einer Ansammlung chaotisch vernetzter Daten ohne
Schemata
•
Beispiele:
•
Komponenten:
– Spider / Crawler: Softwareagenten zur Analyse von Internetseiten
– Index / Katalog: Datenstruktur mit Informationen über gefundene Webseiten
– Suchsoftware: Bearbeitung von Suchanfragen mit Hilfe des Katalogs und Darstellung der
Ergebnisse
•
Arten der Suche:
– Volltext
– Schlagwort
– Meta-Tags der Webseiten
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
169
Data Warehouse
•
•
•
•
Mai-17
Herkömmliche DBS enthalten meist Momentaufnahmen des operativen betrieblichen
Geschehens
Unternehmensführung benötigt oft Daten über größere Ausschnitte und längere
Zeiträume
Momentane Zustände müssen archiviert werden
Data Warehouse (DWH) erlaubt Zeitvergleich und Analyse von Entwicklungen, daher
zeitabhängige Daten
Dipl.-Wirt.-Inf. Nico Michalak
170
Grundkomponenten des Data Warehouse
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
171
Schematischer Aufbau eines idealtypischen Data Warehouse
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
172
Data Mining und OLAP
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
173
Externe Datenbanken und Internet
Zur Befriedigung der Informationsbedarfe eines Unternehmens müssen externe Quellen
(Internet und externe Datenbanken) eingebunden werden:
• Volltext- vs. Referenzdatenbanken
• Abfrage durch Information Retrieval Systeme
• Recherche anhand von Deskriptoren, Verknüpfung mit booleschen Operatoren (UND,
ODER, NICHT,…)
• Im Internet: Suchmaschinen (bestehen aus Spider/Crawler, Index/Katalog und
Suchprogramm), werten Seiteninhalt, Metatags und Verlinkung aus
• Einsatz von Internet-Technologie innerhalb des Unternehmens: Internet als Infrastruktur
der betrieblichen Informationsversorgung
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
174
3 Daten, Informationen und Wissen
3.5 WISSEN, WISSENSTRANSFER
UND WISSENSMANAGEMENT
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
175
Wissen und Wissenstransfer
•
Wissen:
–
–
–
–
•
ist personenbezogen
entsteht durch die Interpretation und Verarbeitung von Informationen
vor dem Hintergrund individueller Erfahrungen und Kenntnisse
hat ökonomischen Wert, wenn es in betriebliche Tätigkeiten umgesetzt werden kann
Ziel des Wissenstransfers:
– Speicherung und Verfügbarkeit des betrieblichen Wissens
•
Probleme:
– fehlende Motivation
– Verständnisprobleme
– Verbalisierungsschwierigkeiten
•
Mai-17
Wissensarten und zutreffende Übertragungsstrategien müssen ermittelt werden
Dipl.-Wirt.-Inf. Nico Michalak
176
Wissensarten
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
177
Strategien des Wissenstransfers
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
178
Wissensmanagementsysteme
•
Problem im Management von Wissen in Unternehmen: Wissen meist weit verstreut
•
Wissensmanagementsysteme sollen helfen, wissen zu
–
–
–
–
–
entwickeln,
visualisieren,
verwalten,
veredeln und
verteilen.
•
Berücksichtigung von Metainformationen: Wissen über Wissen
•
Erfolgsfaktoren
– Permanente Aktualisierung
– einfacher Zugang
Mai-17
Dipl.-Wirt.-Inf. Nico Michalak
179
Beispiel: Wissensmanagement bei Bayer
•
Mai-17
Einsatzbereich: Zentrale Forschung
Dipl.-Wirt.-Inf. Nico Michalak
180
Managementinformationssysteme
•
IT-gestützte Systeme zur Information von Führungskräften aller Ebenen
•
Datenlieferanten:
– Operative Systeme im Wertschöpfungsprozess
– Anwendungssysteme für Querschnittsfunktionen
– Externe Datenbanken
•
Berichtszwecke:
– Kontrolle / Dokumentation
– Anstoß zur Entscheidung
– Entscheidungsunterstützung (auch Decision Support Systems (DSS))
•
Präsentationsformen:
–
–
–
–
Mai-17
Kurzmeldungen
Tabellen
Grafiken
Verbale Berichte
Dipl.-Wirt.-Inf. Nico Michalak
181