1 Einleitung. Informationssysteme für Ingenieure. Herbstsemester R. Marti

Transkript

1 1 Einleitung Informationssysteme für Ingenieure Herbstsemester 2015 R. Marti

2 Information und Daten Information gesprochene und geschriebene Sprache (bestehend aus Symbolen: Worte, Buchstaben, Zahlen) Zeichnungen, Diagramme (ebenfalls Symbole) Abbild (Modell) der realen Welt (oder einer imaginären Welt) Daten ("Rohdaten") Fakten, die gespeichert und übermittelt werden 8092 Information = Daten + Bedeutung (Semantik) [ Wissen = Information + "sinnvolle" Anwendung ] Postleitzahl in CH Monatslohn in CHF Informationssystem: Ein Programm (evt. mehrere zusammengehörige Programme), mit welchem Informationen verwaltet werden. 2

3 Strukturierte und unstrukturierte Daten (1) strukturierte Daten Daten, die eine reguläre, fest vorgegebene Struktur besitzen (das sog. Schema). Strukturierte Daten können gut analysiert und organisiert werden. NAME SYMBOL QUOTE_CLS DIFF_ABS DIFF_REL QUOTE_HI QUOTE_LO VAL_DATE ABB#Ltd#N ABBN % Adecco#N ADEN % Baloise#N BALN % Ciba#Sc#N CIBN % Clariant#N CLN C0.20 C0.99% CS#Group#N CSGN % Givaudan#N GIVN 1' % 1' ' Holcim#N HOLN % relationale Datenbanken ( eine Sammlung "grosser" Tabellen ) Excel Spreadsheets andere Datenbanken (z.b. objektorientierte DB) 3

4 Strukturierte und unstrukturierte Daten (2) unstrukturierte Daten Daten bzw. Information, die nicht vorgängig analysiert wurde. Diese haben keine explizite Struktur (aber evt. eine implizite, z.b. Grammatikregeln für natürlichsprachlichen Text, Anordnung von Pixeln / Vektordarstellung für Bilder). ASCII Text Bitmaps, die Texte oder Bilder enthalten (z.b. PNG, TIFF, JPEG, GIF) Die heutige Gesellschaft wird als Informationsgesellschaft bezeichnet. Die rechtzeitige Verfügbarkeit von qualitativ hoch stehender, relevanter Information ist bei der Erledigung vieler alltäglicher Aufgaben absolut zentral, was auch durch Aussagen wie "Wissen ist Macht" dokumentiert wird. Die Wichtigkeit der Ressource Information wird uns insbesondere dann schmerzlich bewusst, wenn die Informationsinfrastruktur einmal nicht funktioniert. Audio-Dateien (z.b. FLAC, MP3) Filme als Sequenzen von Bitmaps (z.b. MP4, FLV) 4

5 Momentaner "Hype": Big Data (1) 5

6 Momentaner "Hype": Big Data (2) "Definition" (Charakterisierung) von Big Data: The 3 Vs Volume: 100 Terabyte ( Byte) oder gar 1 Petabyte (10 15 Byte). Volumen ist relativ, ändert über die Zeit. Berücksichtigung "aller" Daten, nicht nur Stichproben (samples). Speicherung + Verarbeitung benötigen viele Disks + CPUs Variety: nicht nur strukturierte, auch unstrukturierte Daten (insbes. Text). > 80% der Daten sind unstrukturiert. Entdecken von Strukturen Velocity: nicht nur statische (und "abgestandene") Daten, sondern auch dynamische Datenströme (data streams). Ticker von Aktienkursen. Sensor Daten 6

7 Information als Modell der Realität Modelle (Kinder-) Spielsachen Landkarten und ähnliches Baupläne Modelle in der Physik (Wurfparabel) Modelle in der Ökonomie (Black-Scholes Formel) Diagramme von Computerprogrammen Datenbank-Schema Modell der realen Welt (siehe DB-Entwurf) Contract Client Payment Org Unit Event 7

8 Informationssysteme in der Anwendung Universität: Vorlesungskatalog, Studenten, Räume, Warenhauskette: Lagerbestand, Lieferanten, Kunden, Verkäufe, Bank: Kundenkonti, Eigenhandel, Risiken, on-line Banking Flugreservationssysteme: Flugpläne, Flüge, Passagiere, Geographische Informationssysteme (GIS) Informationssuche on-line Verkauf on-line Zeitungen soziale Netzwerke etc. R. Marti Informationssysteme für Ingenieure (2015) -- 1 Einleitung 8

9 Beispiel: Schnittstelle zu einem Informationssystem R. Marti Informationssysteme für Ingenieure (2015) -- 1 Einleitung 9

10 Grobarchitektur eines Informationssystems User Interface Layer Business Logic Layer Persistency Layer Ein Anwendungsprogramm (kurz: Anwendung, Application) verwaltet die benötigten Daten in einer oder mehreren Dateien kennt die Struktur dieser Dateien Bem: Das Beispiel soll illustrieren, wie die Systeme eines online Buchhändlers aufgebaut sein könnten. Es geht hier nicht um die effektive Realisierung von amazon.com. R. Marti Anwendungsprogramm (logische) 3 Tier Architektur [ Tier = Ebene, Schicht ] Datei(-en) Informationssysteme für Ingenieure (2015) -- 1 Einleitung Informationssystem 10

11 Beispiel: Informationssysteme eines Online Buchhändlers In einem Unternehmen gibt es typischerweise mehrere Informationssysteme bzw. Anwendungen (siehe unten). Verschiedene Anwendungen benötigen teilweise die gleichen Daten. In einer Anwendungslandschaft mit isolierten Datei-basierten Lösungen führt dies zu Redundanzen und Inkonsistenzen. Anwendung "Customer Order" Anwendung "Pack & Ship" Anwendung "Manage Stock" Anwendung "Employee Payroll" Datei(-en) Datei(-en) Datei(-en) Datei(-en) Beispiel: Buch Informationen (und wenn es nur etwas wie eine ISBN ist) werden in "Customer Order", "Pack & Ship" sowie in "Manage Stock" benötigt. R. Marti Informationssysteme für Ingenieure (2015) -- 1 Einleitung 11

12 Einige grundlegende Definitionen Datenbank (Database, DB) Eine Menge von Daten, die miteinander in Beziehung stehen. Datenbankverwaltungssystem (Database Management System, DBMS) Ein Software Paket das die Erstellung, Pflege und Abfrage von Datenbanken unterstützt Datenbanksystem (Database System, DBS) = DB + DBMS Metadaten ( Daten über Daten) Information über die Struktur einer Datenbank, deren Benutzer, etc. Mini Welt (auch Diskursbereich, Universe of Discourse) Ein (typischerweie kleiner) Ausschnitt der realen Welt, der uns interessiert. Dieser Begriff wird vor allem beim Datenbankentwurf verwendet: Ein DB-Schema bildet eine Mini-Welt ab. 12

13 Motivation für Entwicklung & Einsatz von DBMS (1) Vermeidung (unkontrollierter) Redundanzen Isolierte, von verschiedenen Anwendungen verwaltete Dateien führen oft zu Mehrfachspeicherung gleicher / überlappender Daten (Redundanz) und damit oft zu Inkonsistenzen, insbesondere bei Datenänderungen. Erleichterung bei Verknüpfung von Daten in verschiedenen Dateien Es ist oft aufwendig und manchmal unmöglich, isolierte Dateien miteinander zu verknüpfen, weil die Struktur der Daten in den Anwendungen versteckt ist (sog. Silos oder Stovepipes). Anwendung A Anwendung B Anwendung C Datei A Datei B Datei C 13

14 Motivation für Entwicklung & Einsatz von DBMS (2) Vorkehrungen gegen Verletzung von Integritätsbedingungen Ein DBMS kann gewisse inhaltliche Bedingungen an Daten (sog. Integritätsbedingungen) "automatisch" überprüfen inklusive Bedingungen über Dateigrenzen hinweg. Unterstützung von Mehrbenutzerbetrieb Dateisysteme bieten im Gegensatz zu einem DBMS nur rudimentäre Kontollmechanismen für Mehrbenutzerbetrieb, was zu inkorrekten Abfrageresultaten / Datenbeständen führen kann. Vorkehrungen gegen Datenverlust In Dateisystemen können Änderungen, die mehrere Operationen auf verschiedenen Dateien umfassen, bei technischen Problemen zu Inkonsistenzen und /oder Datenverlust führen. Ein DBMS vermeidet solche Inkonsistenzen sowie (gewisse Arten von) Datenverlust. 14

15 Motivation für Entwicklung & Einsatz von DBMS (3) Unterstützung von Zugriffskontrollen Dateisysteme bieten Kontrollmechanismen auf Stufe Datei. Ein DBMS unterstützt wesentlich "feinere" Zugriffskontrollen: auf der Stufe einer "Zelle" eines Spreadsheets in Abhängigkeit von Datenwerten. Verkleinerung von Entwicklungsaufwand und -kosten Die erwähnten Mechanismen müssen nicht für jede neue Anwendung neu programmiert werden, da ein DBMS diese als "generische" Dienstleistungen zur Verfügung stellt. 15

16 Integration der Daten 1 Datenbank (DB) User Interface Layer Business Logic Layer Persistency Layer Anwendung "Pack & Ship" Anwendung "Customer Order" Anwendung "Manage Stock" (logische) 3 Tier Architektur [ Tier = Ebene, Schicht ] Datei(-en) Datenbank Datei(-en) (integriertes) Informationssystem 16

17 Anwendungen auf integrierter Datenbank (1) Anwendung "Pack & Ship" Anwendung "Customer Order" Anwendung "Manage Stock" Datenbank 17

18 Anwendungen auf integrierter Datenbank (2) User Interface Layer User Interface Layer User Interface Layer Business Logic Layer Business Logic Layer Business Logic Layer Persistency Layer Persistency Layer Persistency Layer Datenbank 18

19 "Integration" der Software für Datenverwaltung DBMS Interpreter for ad hoc Queries & Updates User Interface Layer Business Logic Layer User Interface Layer Business Logic Layer Persistency Layer Persistency Layer Persistency Layer Datenbankverwaltungssystem = "Generic" Persistency Layer Datenbanksystem Datenbank 19

20 Typische Benutzer eines DBMS (1) Power User Parametrischer Benutzer Interpreter for ad hoc Queries & Updates Persistency Layer Anwendung User Interface Layer Business Logic Layer Persistency Layer Anwendungsprogrammierer Datenbankverwaltungssystem (a Generic" Persistency Layer) Datenbanksystem Datenbank Datenbank-Administrator R. Marti Informationssysteme für Ingenieure (2015) -- 1 Einleitung 20

21 Typische Benutzer eines DBMS (2) DB-Administrator verantwortlich für Koordination & Überwachung des DB Betriebs (z.b. bezüglich Platzbedarf, Durchsatz, Antwortzeiten); Vergeben von Zugriffsberechtigungen DB-Designer verantwortlich für die inhaltliche Struktur der DB Anwendungsprogrammierer (oft gleichzeitig ein "Power User") verantwortlich für die Programmierung der Anwendung Daten-Analysten ("Power User") typischerweise Business Analysten, Wissenschaftler und Ingenieure, die mit der Technik und den Daten gut vertraut sind Parametrische Benutzer Der Grossteil der Benutzer, die über Anwendungsprogramme zugreifen, und durch Eingabe in Masken und Auswahl in Menus (= Parameter) ihre Datenbedürfnisse kommunizieren 21

22 Typische Grobarchitektur eines Datenbanksystems Datenbankverwaltungssystem DDL / DML Übersetzer & Evaluator Metadaten Manager Daten Manager Transaktions Manager Datenbanksystem Daten & Matadaten (in Dateien auf Disk) R. Marti Informationssysteme für Ingenieure (2015) -- 1 Einleitung 22

23 Datenmodell Ein DBMS basiert auf einem Datenmodell. Ein Datenmodell stellt die Infrastruktur für die Modellierung der realen Welt zur Verfügung, d.h., das Datenmodell legt die Konstrukte fest, mit denen die reale Welt dargestellt werden kann: Data Definition Language (DDL) Strukturen von Daten + Integritätsbedingungen (sog. DB Schema) Data Manipulation Language (DML) Operationen zur Manipulation (Einfügen/Verändern/Löschen) sowie zur Abfrage von Daten Oft können DDL und DML nicht nur "eingebettet" in Anwendungen sondern auch interaktiv ( Kapitel 3) verwendet werden. Ein Datenmodell ist in etwa vergleichbar mit einer Programmiersprache. 23

24 Beispiele von Datenmodellen Relationenmodell (Standard: SQL) heutige marktbeherrschend, basierend auf Relationen bzw. Tabellen objekt-orientiertes / objekt-relationales Datenmodell moderneres aber komplexeres Datenmodell, oft eher im Technikbereich XML "Datenmodell" primär für Datenaustausch, "semi-strukturierte" Daten, Dokumente historische Datenmodelle, die in "Legacy" Anwendungen weiterleben hierarchisches Datenmodell CODASYL Netzwek Modell "NoSQL Movement" (NoSQL: kann auch "not only SQL" heissen) z.b. Datenmodelle basierend auf Graphen, geeignet für soziale Netzwerke Entity-Relationship (ER) Modell [ Objekt-Beziehungs-Modell] für logischen DB-Entwurf; danach Abbildung auf Datenmodell eines DBMS 24

25 Abfragesprachen Die Abfragesprache ist die Sprache mit welcher Benutzer und Anwendungen die gewünschten Daten aus der Datenbank auswählen. Sie ist ein Teil der Data Manipulation Language (DML) (siehe oben). Eine Abfragesprache kann prozedural oder deklarativ sein. prozedural: es wird spezifiziert wie ein Zielzustand erreicht werden kann (englisch: how to reach the goal state) z.b. wie Menge der Resultate einer Anfrage berechnet wird deklarativ: es wird spezifiziert welche Eigenschaften der Zielzustand hat (englisch: what are the properties of the goal state) z.b. welche Bedingungen die Objekte in der Resultatmenge erfüllen müssen Heute werden primär deklarative Abfragesprachen verwendet (insbes. SQL). Das DBMS entscheidet, wie die Resultatmenge konstruiert wird. Bei mehreren Alternativen wird eine möglichst effiziente ausgewählt. 25

26 Integrierte Übung 1.1 Geben Sie Beispiele aus der realen Welt für prozedurale respektive deklarative Beschreibungen. 26

27 Ebenen der Beschreibung von Daten Daten werden (nach wie vor) meist auf Magnetplatten (Hard Disk) gespeichert Alternative: Solid State Drives (SSDs) logische Ebene der DB-Beschreibung: - Welche Daten werden überhaupt gespeichert? - Welche Daten gehören logisch zusammen (z.b. in eine Tabelle)? - Welche Verknüpfungen gibt es unter Daten (z.b. über Tabellengrenzen)? physische Ebene der DB-Beschreibung: - Welche Daten sind auf welcher ("internen") Datei? - In welcher Reihenfolge sind die Daten gespeichert (wenn überhaupt)? - Wie "dicht" werden neue Daten anfänglich gespeichert? - Welche Hilfsstrukturen (z.b. sog. Indexe) gibt es, wie sehen sie aus? Bem.: Die "normale" Benutzerin interessiert sich im Allgemeinen nicht dafür. (Sie beklagt allenfalls eine schlechte Performance des Systems!) 27

28 3 Schema Architektur Auf logischer Ebene wird unterschieden zwischen: externer Ebene / externen Sichten Die logische Struktur des für eine Anwendung / Benutzergruppe relevanten Ausschnitts der DB. konzeptioneller Ebene (auch: "konzeptuell") Die logische Struktur der gesamten DB. Die physische Ebene wird auch interne Ebene genannt. 28

29 Datenunabhängigkeit Die 3 Schema Architektur bildet die Grundlage für das Konzept der Datenunabhängigkeit Die Abbildung zwischen konzeptioneller und externer Ebene gewährleistet logische Datenunabhängigkeit: Die Isolation der Anwendungen von Änderungen am konzeptionellen Schema. Die Abbildung zwischen konzeptioneller und interner Ebene gewährleistet physische Datenunabhängigkeit: Die Isolation des konzeptionellen Schemas (und der externen Sichten) von Änderungen am internen Schema. 29

30 Datenbankschema Datenbankschema Die (logische und physische) Beschreibung einer Datenbank. Dazu gehören (auf der logischen Ebene): - Die Struktur der zu speichernden Datenobjekte und deren Datenelemente. - Normalerweise der Datentyp jedes einzelnen Datenelements. - Integritätsbedingungen: Bedingungen an den Inhalt der Datenbank, d.h. Bedingungen, die von den gespeicherten Daten ( Datenbankinstanz) "jederzeit" erfüllt werden müssen z.b. die Immatrikulationsnummer der Studierenden muss eindeutig sein das Alter einer Studierenden muss zwischen 16 und 120 liegen Das Datenbank-Schema ändert sich normalerweise selten. (Typischerweise wenn die Benutzer neue Daten-Bedürfnisse anmelden.) 30

31 Beispiel eines relationalen Datenbankschemas Beispiele eines Datenbankschemas Studenten Name StudNr Hauptfach logische Ebene - ohne Datentypen - ohne Integritätsbedingungen Vorlesungen VorlesungsName VorlesungsNr ECTS Institut Voraussetzungen VorlesungsNr VoraussetzungsNr Module ModulNr VorlesungsNr Semester Jahr Dozent Notenblätter StudNr ModulNr Note 31 InfO12, Einführung 34/50 M. Böhlen, ifi@uzh

32 Datenbankinstanz Datenbankinstanz (auch DB-Ausprägung, DB-Zustand, Extension einer DB) Eine Instanz einer Datenbank besteht aus den Daten, die zu einem gegebenen Zeitpunkt in der Datenbank gespeichert sind. Der Begriff der Instanz wird auch für Komponenten der Datenbank verwendet (z.b. Instanz einer Tabelle). Gültige Datenbankinstanz Eine DB-Instanz, die sämtliche Integritätsbedingungen erfüllt. Die Datenbankinstanz ändert sich bei jedem Einfügen / Verändern / Löschen von Daten, im allgemeinen also relativ häufig (im Vergleich zum Schema). Nebenbemerkung: Bei vielen (aber längst nicht allen) Anwendungen werden die Daten etwa 3 so oft abgefragt wie verändert. 32

33 Beispiel einer Datenban Beispiel einer Datenbankinstanz Beispiel einer (relationalen) Datenbankinstanz Vorlesungen VorlesungsName VorlesungsNr ECTS Beispiel Vorlesungen einer Datenbankinstanz Intro to Computer Science CS VorlesungsName VorlesungsNr ECTS Institut Data Structures CS Intro Vorlesungen Beispiel einer to Computer Datenbankinstanz Science CS CS Discrete Mathematics MATH Data VorlesungsName Structures VorlesungsNr CS3320 ECTS 4 Institut CS Databases CS Vorlesungen Intro Discrete to Computer Mathematics Science MATH2410 CS MATH CS VorlesungsName Data Databases Structures VorlesungsNr CS3360 CS3320 ECTS Institut 34 Module CS Discrete Mathematics MATH ModulNr MATH VorlesungsNr Semester Jahr Intro to Computer Science CS CS Data Structures Module Databases CS3320 CS CS 3 CS 85 MATH2410 Fall 04 Discrete Mathematics ModulNr VorlesungsNr MATH2410 Semester 3 Jahr MATH Dozent 92 CS1310 Fall 04 A Databases Module 85 MATH2410 CS3360 Fall3 04CS King 102 CS3320 Spring 05 ModulNr 92 VorlesungsNr CS1310 Semester Fall Jahr 04 Anderson Dozent112 MATH2410 Fall 05 Module MATH2410 CS3320 Spring Fall Knuth King 119 CS1310 Fall 05 A ModulNr VorlesungsNr MATH2410 CS1310 Semester Jahr Fall Dozent Anderson Chang 135 CS3380 Fall MATH CS1310 CS3320 Fall 04 Spring Fall King 05 Anderson Knuth 92 CS MATH2410 CS3380 Fall 04 Fall Anderson 05 Chang Stone Voraussetzungen 102 CS CS1310 Spring 05Fall Knuth 05 Anderson VorlesungsNr VoraussetzungsNr 112 Voraussetzungen MATH CS3380 Fall 05Fall Chang 05 Stone CS3380 CS VorlesungsNr CS1310 VoraussetzungsNr Fall 05 Anderson CS3380 MATH Voraussetzungen CS3380 Fall CS Stone CS3320 CS1310 VorlesungsNr CS3380 VoraussetzungsNr MATH2410 VoraussetzungenCS3320 CS3380 CS1310 CS3320 Notenblätter VorlesungsNr CS3380 VoraussetzungsNr MATH2410 StudNr ModulNr Note CS3380 Notenblätter CS3320 CS3320 CS B CS3380 StudNrMATH2410 ModulNr Note C CS3320 Notenblätter 17 CS B 8 85 A StudNr 17 ModulNr 119 Note C 8 92 A Notenblätter AB B StudNr ModulNr 17 8 Note AC A B BA R. Marti 8 C 92 Informationssysteme A für Ingenieure (2015) -- 1 Einleitung InfO12, Einführung A102 B 8 92 InfO12, 8 A Einführung 135 A 36/50 M. Böhlen B

34 Datenbanken im Unternehmen Theorie (bzw. Idealzustand) Eine unternehmensweite Datenbank, mit einem unternehmensweiten konzeptionellen DB-Schema, auf die alle Anwendungen zugreifen. Application A Application B Application C Partner Counterparty Intermediary Client Bank Location Risk Contract Financial Transaction Shared Database Organizational Unit Loss Event Market Claim Management Unit Product Asset Legal Entity Employee 34

35 Unternehmensweites DB-Schema (stark vereinfacht) Beispiel: Versicherung / Rückversicherung dargestellt in Variation des ER-Modells Partner Counterparty Intermediary Client Bank Location Insurable Contract Financial Transaction Loss Event Claim Product Asset Organizational Unit Market Management Unit Legal Entity Employee 35

36 Einsatz von Datenbanktechnologie in der Praxis Viele Anwendungen haben ihre "eigene" Datenbank, verwaltet durch ein DBMS. Auch dies führt zu Daten-Silos und (mehr oder minder sichtbaren) Abhängigkeiten zwischen Anwendungen 1 Aufruf einer Prozedur einer klar definierten und publizierten Schnittstelle (App C ruft App B auf) Anwendung A Anwendung B 1 2 Anwendung C 2 Direkter Zugriff auf eine "fremde" Datenbank (App C greift auf DB A zu) 3 Speichern der gleichen Daten in verschiedenen Datenbanken (DBs A und B) 3 36

37 Anwendungen im Unternehmen Unterstützung der operativen Geschäftsprozesse (OLTP = OnLine Transaction Processing) Erfassen von (Transaktions-) Daten ("getting the data in") z.b. im Verkauf, Versand, Lagerbewirtschaftung oft in separaten Datenbanken Überwachung / Reporting solcher Geschäftsprozesse Unterstützung der Steuerung von Firmen / "Business Intelligence" (OLAP = OnLine Analytical Processing) Analyse aller in verschiedenen OLTP Datenbanken erfassten Daten ("getting the data out") Überwachung von vordefinierten "Key Performance Indicators" (KPIs) 37

38 Zusammenfassung Daten sind eine wichtige Ressource heutiger Unternehmungen Datenbankverwaltungssysteme (DBMSs) ermöglichen die integrierte Pflege der Ressource Daten die kostengünstige Entwicklung von Daten-zentrischen Anwendungen DBMSs bieten generische Dienstleistungen an, insbesondere persistente Verwaltung sehr grosser Datenmengen, inkl. Fehlertoleranz deklarativen, mengenorientierten Datenzugriff Mehrbenutzerbetrieb (concurrency control) Datenintegritätskontrolle (semantic integrity) Zugriffskontrolle, Datenschutz (authorization) Optimierung der Datenzugriffe (access path selection, query optimization) Datenunabhängigkeit für Anwendungen (data independence) 38