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