Informationssysteme 0. Einf ¨uhrung
Werbung
Prof. Dr. rer.nat.habil. Bernhard Thalheim Information Systems Engineering Department of Computer Science Christian-Albrechts-University Kiel Olshausenstr. 40 D - 24098 Kiel Vorlesung Informationssysteme 0. Einführung WS 2016/17 0 Grundlagen und Ziele Für die Erörterung im schriftlichen Teil der Vorlesung: Systematik Hier: Informationssysteme aus der Sicht des Informatikers Informatik: Wissenschaft (oder Kunst) der formalen Sprachen zur Beschreibung von abstrakten Dingen und Handlungsabläufen • erfinden Syntax Form der formalen Sprache, Standardisierung, Rückgriff auf existierende Verständigungsmittel, verschiedene Detailisierung (bis hin zu abstrakten Maschinen) • verwirklichen (d.h. beherrschbar) implementieren erst nach Festlegung der Semantik, verschiedene Semantiken (operationale, ...) • nutzen Beschreibung der Aufgaben mit den Mitteln der Sprache, Methodologie schwierigste Teile: von informal zu formal Semantik Pragmatik Wolkenbild mit Maschine Semiotisches Dreieck: Syntax, Semantik, Pragmatik formale Sprache erfinden verwirklichen benutzen Paradigmen \ Theorie Abstraktion Entwurf Unsere Vorlesungsanwendungen : Universitätsdatenbank (Verwaltung von Studenten (, Mitarbeitern, Ressourcen (Gebäude, HW, SW, Bücher, ...), Fonds, Stundenplanung, ... )) mit unterschiedlichen Sichten Universitätsbibliothek (Bcher, Leser, Ausleihe) 0.1 Information, Kommunikation Zeitalter 1. Zeitalter der manuellen Produktion Jäger, Sammler, Landwirte, Handwerker CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 2 2. Industriezeitalter 3. Informationszeitalter Der Mensch ändert sich nicht so sehr wie die Technik suggeriert. Psychologische Barrieren • Verarbeitungskapazität des Menschen • Formulierungsfähigkeit des Menschen • Gewohnheiten des Menschen US-Diskussion der ‘Y’-Gesellschaft und der Trennung Wir sind bereits in Informationen ertränkt. • Anstelle von mehr Information brauchen wir Information • zur rechten Zeit, • der richtigen Sorte, • in der richtigen Dosis, • in der richtigen Form, • im vollen Umfang, • zu akzeptablen Kosten für alle Benutzer (bzw. Anwendungen) unserer Informationssystemes. • Der Mensch ist das einzige Ziel der Information. • Gespeicherte Information muß verarbeitet werden, ehe sie Nutzen bringt. Information Daten + empfangen + ausgewählt durch Interesse + integriert 0.1.1 Einleitung Verschiedene Arten von Informationssystemen (Sammlung von Daten): Computerized Information System CIS Management-Informationssysteme POI-Systeme, meist Spreadsheet-unterstützt, graphische Oberfläche, einfache Bedienung, Vernetzung mit Partnern mit unterschiedlichen Aufgaben im System, hierarchisch Entscheidungsunterstützungssysteme meist stand-alone-Lösungen, Expertensystem-shell-basiert, verschiedene Unterstützung für Äbwägen, Diskussion, Rücknahme (Hyper)textsysteme Volltextsysteme mit umfangreichen Verweismöglichkeiten und evt. logischen Ableitungen (zwischen den Zeilen) (Supertextsysteme) Information-Retrieval-Systeme meist über Deskriptoren organisiert, einfache Funktionen, einfache Datenstrukturen, effiziente Suche, schwierig zu erweitern, unscharfe Suche, unscharfe Daten CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 3 Dokumentationssysteme hierarchisch, Deskriptoren, komplexe Struktur, eingeschränkte, schnelle Suche Büroinformationssysteme kleine Anwendungssysteme, kooperative Lösung Datenbanksysteme Datenbeschreibungssprache (basierend auf Datenmodell), viele Funktionen, optimierend, verteilte Systeme, Konsistenz, Sicherheit, konkurrierender Zugriff und Fehlerbehandlung (Zurückfahren), Sichten für verschiedene Nutzer Wissensbanken Datenbanken sind übergreifend Entwicklung der DBMS führte zur Integration verschiedener Funktionen anderer Arten von CIS • graphische Oberfläche • deduktive Datenbanken • aktive Datenbanken • parallele Datenbanken • Deskriptoren • Wissensverarbeitung • objektorientierte Entwicklung • Reasoning-Funktionen zum Abwägen und Ableiten • groupware-middleware-Datenbanken • telekommunikative, mobile Datenbanken Trotzdem: Datenbanksysteme haben nicht die gesamte Funktionalität von allen CIS (und werden diese auch nicht anstreben). Volltextsysteme, Entscheidungsunterstützungssysteme, inexakte, inkonsistente Daten, ... Entscheidungsunterstützungssysteme sind spezielle Datenbanken. Vielfältige Anwendungen: Materialwirtschaft, Reservierungssysteme, Bibliotheksverwaltungssysteme, Versicherungswirtschaft, Banken, Meldewesen, Auskunftswesen, Produktionsplanung und -steuerung, Personalverwaltung, Auftragsverwaltung, ... Neuartige Anwendungen: CAx, Büroinformationssystem, Geoinformationssysteme, Prozeßdatenverarbeitung, Versuchsdaten, intelligente Systeme, statische Systeme, Multimediasysteme, ... Musikverarbeitung Riesiger Marktsprung (siehe Übersicht) Kennzeichen einer DB • große Mengen von Daten large amount • dauerhaft persistent • verläßlich dependable • verschiedene Benutzer • Sicherheit der Daten shared security CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 4 • effizient • verwalten • Anfragen storage management queries ad-hoc-Anfragesprachen • Änderungen updates ‘Unternehmen’ kann Informationssystem auf verschiedene Arten benutzen; evt. auch gemischt 1. System ist “Modell” der Welt (Daten als Gegebenheiten) 2. System verwaltet ‘Original’dokumente (Bsp. Programmentwicklungssystem, Referatesystem) 3. System wird als ‘schwarzes Brett’ benutzt (gemeinsame Hinterlegung von Daten; Austausch (Bsp. Patienteninformationssystem)) ⇒ Anforderungen • “Daten” strukturieren (für alle Benutzer verstehbar + verwaltbar) • verschiedenartige Benutzer wirken zusammen, unabhängig - wie ? wie sicher ? • Gestaltung von Oberflächen bei gleichzeitiger einheitlicher Verwaltung • Kommunikation ⇒ Besonderheiten von Informationssystemen • Modellierung formalisierbarer statischer und dynamischer Gesichtpunkte von ‘Unternehmen’ • anschauliche Beschreibungen • formale Beschreibungen • Datenmodelle (logische, relationale, objektorientierte) • Algorithmenmodelle (Transaktionen) • Implementierungen • Structured Query language, QBE, Quel, Datalog, ... • Algorithmen, Datenstrukuren für (relationale) Operationen • unterliegende System (C++, Ontos, ...) • Dauerhaftigkeit und Teilhabe • Transaktionen • Schemaentwurf • Sicherheit • Schichtenarchitektur Außerdem: ‘Unternehmen’ bestehen aus Menschen; DB als technisches Hilfsmittel ⇒ Definition von Information , Kommunikation, Wirklichkeit und Modell erforderlich Hinzu: Informationssystem beeinflußt auch den Geschäftsablauf Historie Generationen verschiedene Einteilungen; evt. analog zu Rechnergenerationen semantische Begriffe Modelle CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 5 1. Filesysteme auf Band bzw. später auf Platte 50-er + 60-er Redundanz, Gefahr der Inkonsistenz, Inflexibilität, eingeschränkte Produktivität (aufwendige Programmierung), Datenschutzprobleme, Einhaltung und Durchsetzung von Standards 2. Prärelationale Systeme 70-er Unterscheidung der physischen und logischen Sicht Katalog, verschiedene Benutzer hierarchisches und Netzwerk-Datenmodell Redundanzvermeidung, zentrale Integritätskontrolle, Strukturierung, DML und DDL relativ implementationsnah, navigierender Zugriff Effizienzprobleme, Konsistenzprobleme, Sicherheitsprobleme, Compatibilität 1961 C. Bachman’s Vorschlag, 1965-70 IMS DB/DS (Netzwerk), Dodd’s APL für PL/1, Sabre (IBM + Am. Airlines), IBM’s hierarch. System 1971 CODASYL DBTG Vorschlag; IDMS, IDS II, DMS verschied. Hersteller 1985 Vorschlag für NDL (Network defintion language) 3. Relationale Systeme Dreiebenenarchitektur, Unabhängigkeit der konzeptionellen Darstellung mächtige Sprachen mengenorientiert, Programm-Daten-Unabhängigkeit, Datenabstraktion, insert, delete, update 1970 E.F. Codd (Childs); 1975 VLDB, 1972 ACM SIGMOD; 1976 P.P. Chen SQUARE, SEQUEL (SQL), QBE, QUEL 1985 Preliminary SQL, 1986 ANSI SQL, SQL 89, SQL 2; 199x SQL 3 (x > 5) Etappen der Entwicklung des relationalen Systeme 80-er • Codd’s Arbeit in den Comm. of the ACM, 1970 • MacAIMS (1970-71) (R. Godstein, J. Strnad) • IS/1, PRTV (71-75) • Große Debatte von Codd/Date und Charlie Bachmann • System R (Mitte 70er) • System Ingres (Mitte 70er) • frühe relationale Produkte (79-83) • Tandem NonStop SQL (87) mit ersten besseren Leistungsparametern Hauptbeträge zur Entwicklung der Technologie • Arbeiten von Hall, Todd, Hitchcock, Immon, Stonebraker, Strnad (parallel zu Codd 1971 im IFIP Congress) zu IS/1- und PRTV-Prototypen • Arbeiten von Chamberlin, Traiger u.a. zum R Prototypen • Arbeiten von Zloof zu QBE • Arbeiten von Stonebraker zum Ingres Prototypen • Arbeiten von Armstrong, Fagin u.a. zur Abhängigkeitstheorie 4. Postrelationale Systeme 90-er aufgrund obiger neuartiger Anwendungen Erweiterung der Funktionalität umfangreichere Typenkonstruktoren, verbesserte Semantik, umfangreichere Operationalität, Verhalten, Mehrnutzerbetrieb, offene Systeme, objektorientierte Systeme, Versionen, räumliche Daten, aktive Anwendungen Vermutung: keine universellen Systeme, eher anwendungsspezifische goodies: benutzerdefinierte Datentypen, Vererbung Falsche Ansichten zu OODB CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 6 • blobs + gespeicherte Prozeduren = Objekte Typ hat Zustands- und Verhaltenscharakteristika (blobs nur Zustand), Typen sind in Hierarchie (?), klare Trennung von Typ-Spezifikation und -Implementation • richtige DBMS unterstützen SQL besser Vielzahl von Sprachkonzepten • Client-Server = Client-Server relationales Client-Server-Modell ist Auswuchs der mainframe-Architektur (Steuerung, auch für Terminals und Benutzeroberflächen durch Server); besser Verteilung nach Rechenleistung etc. auf Server Objektrelationale Modelle XMLbasierte Modelle i } 6 16 Universelle Modelle Objektorientierte Modelle Deduktive Modelle ] 6 Relationale Modelle 6 Navigationsmodelle 6 File Strukturen Datenabstraktionshierarchie XMLAlgebraWirrwarr HERMAlgebraAusdrücke ] 6 Logikbasierte Ausdrücke Erweiterte EntityRelationshipModelle 6 EntityRelationshipModelle 6 Relationale Algebra 6 Normalisierungstheorie 6 Anfrageberechnungsstrategien 6 Rekursionsmodelle Baumstrukturen 6 6 Implementations- Strukturierte programme Programmierung Algorithmische Hierarchie Modellieringshierarchie Abbildung 1: Generationen 1, 2, 3, 4 von Datenbankverwaltungssystemen Relationale Systeme β CAU Kiel, IfI, ISE WS 2016/17 Informationssysteme 0. Einführung 7 1. SQL - Linie SQL ist De-Facto-Standard der relationalen Datenbankwelt • 1970 : Codd’s Arbeit • 1974 : Chamberlain’s SEQUEL verschiedene Versionen 1975 (SEQUEL-XRM), 1977 (SEQUEL/2 - R), Standardisierung, 1981 (ORACLE, SQL/DS), 1983 (DB2), DG/SQL (1984), SYBASE (1986), ... History of SQL 1970 E.F. Codd publishes Definition of Relational Model 1975 Initial version of SQL Implemented (D. Chamberlin) IBM experimental version: System R (1977) w/revised SQL IBM commercial versions: SQL/DS and DB2 (early 1980s) Oracle introduces commercial version before IBM’s SQL/DS INGRES 1981 & 85 ShareBase 1982 & 86 Data General (1984) Sybase (1986) by 1992 over 100 SQL products Genealogy of Relational Database Management Systems v6.0, 1986 OpenIngres 2.0, 1997 vR3, 2004 v9.0, 2006 v10, 2010 Ingres Monet Database System (Data Distilleries) DABA (Robotron, TU Dresden) Ingres v5.x, 1970s VectorWise (Actian) VectorWise MonetDB (CWI) Postgres MonetDB Netezza IBM PostgreSQL v1, 1995 v6, 1997 Greenplum Berkeley Ingres Empress Embedded Informix v1.0, 1980s IBM Informix v10, 2005 v4.0, 1990 v5.0, 1992 IBM Red Brick Warehouse C-Store Informix Sybase SQL Server v4.0, 1990 v10, 1993 v11, 2007 PostgreSQL v11.70, 2010 v12.10, 2013 Red Brick v6.0, 1994 v7.0, 1995 Sybase ASE v11.5, 1996 Microsoft SQL Server H-Store H-Store Informix Vertica Analytic DB Volt DB v11.9, 1998 DATAllegro v3.0, 1988 v1.0, 1987 Expressway 103 v1.0, 1981 Sybase IQ v11, 1995 v12.0, 1999 v12, 1999 Watcom SQL Powersoft CODD RIVER VoltDB HP code brand BAY AREA PARK Greenplum v9, 2010 Illustra v9.0, 2000 alpha, 1979 Pivotal EMC v8, 2005 Red Brick Netezza v7, 2000 v12.5, 2001 v12.5.1, 2003 v10, 2001 v11, 2003 v15.0, 2005 Vertica v16.0, 2012 SAP Sybase ASE v15, 2009 Sybase SQL Anywhere Sybase IQ Microsoft SQL Server v1, 1992 v2, 1993 Microsoft Access v3, 1995 v4, 1997 v5, 1999 SQL Anywhere v12, 2007 v14, 2010 Access v1, 1989 FoxPro v4.21, 1993 VisualFoxPro (Microsoft) v6, 1994 v6.5, 1995 v7, 1998 mSQL v3, 1983 v4, 1984 v5, 1985 v8, 2000 v9, 2005 v10, 2008 v11, 2012 Oracle Oracle v8, 1997 v8i, 1999 v9i, 2001 v10g, 2003 v10gR2, 2005 v11g, 2007 v11gR2, 2009 v12c, 2013 Infobright Infobright v5.1, 1986 v3.1, 1997 MySQL v2, 1979 v3.21, 1998 v3.23, 2001 v4, 2003 v4.1, 2004 v5, 2005 v5.1, 2008 MySQL v7, 1992 Paradox (Ansa) Oracle Sun InnoDB (Innobase) Borland Teradata v1, 1983 MariaDB MariaDB v10, 2013 v5.5, 2010 TimesTen Oracle Paradox Corel Oracle Multics Relational Data Store (Honeywell) 1990s RDB (DEC) 1980s ShareBase (BrittonLee) v6.1, 1997 v4, 1995 RELATIONAL CREEK v1, 1988 v1, 1983 v6.2, 2006 v12, 2007 v14.0, 2012 Teradata v13.0, 2009 Teradata RDB v10.2, 2008 v8.1, 1998 DB2/400 Derby DB2 UDB for iSeries Informix v5, 1997 Apache Derby DB2 for iSeries 2010s v6, 2008 IBM DB2 z/OS v7, 2001 v6, 1999 v4, 1992 Derby v9, 2007 v8, 2004 Transbase v10, 2010 DB2 for z/OS DB2 for VSE & VM DB2 for VSE & VM v5, 1996 DB2 UDB v3, 1993 v2, 1988 System/38 Cloudscape v2, 1992 Solid DB persons v6.0, 2005 v7, 2010 SQL/400 DB2 v5.1, 2004 Empress Embedded v3, 1993 SQL/DS System-R (IBM) v13.10, 2010 Aster Database JBMS NCR DB2 MVS BAY AREA PARK TimesTen v4, 1994 v6, 1999 v7, 2001 v8, 2003 IBM v9, 2006 TinyDB Transbase (Transaction Software) Solid DB EXASolution EXASolution dBase REDABAS (Robotron) dBase (Ashton Tate) Borland IBM IS1 InterBase dBase Inc. InfiniDB Firebird Ashton Tate Groton Database Systems Firebird v1, 2003 GDBM Berkeley DB 1970s v1, 1991 NDBM DBM SQLite Sleepycat v2, 1997 v3, 1999 v4, 2001 HSQLDB Mariposa (Berkeley) Gamma (Univ. Wisconsin) v1.5, 2004 v2, 2006 v2, 2012 2000s IBM Peterlee Relational Test Vehicle BerkeleyDB v1.8, 2005 CODD RIVER SQLite v5, 2010 Oracle v1.6, 2001 DB2 for LUW HSQLDB v2.0, 2010 SAP v1.7, 2002 SAP HANA VDN/RDS DDB4 (Nixdorf) HANA Siemens SAP DB P*TIME MaxDB MaxDB FileMaker (Nashoba) Nonstop SQL (Tandem) v1, 1987 v2, 1989 AdabasD (Software AG) Claris (Apple) II, 1988 v1, 1985 Nonstop SQL v3, 2011 Compaq HP FileMaker Pro v2, 1992 v3, 1995 v4, 1997 FileMaker Inc. v5, 1999 v7, 2004 Neoview v9, 2007 v10, 2009 FileMaker Felix Naumann, Jana Bauckmann, Claudia Exeler, Jan-Peer Rudolph, Fabian Tschirschnitz Key to lines and symbols Contact - Hasso Plattner Institut, Potsdam, [email protected] v9, 2006CC Publishing Date AdabasD v11, 2011 v14, 2015 v8, 2005 v6, 2002 Acquisition Design - Alexander Sandt Grafik-Design, Hamburg Versions Discontinued Branch (intellectual and/or code) Crossing lines have no special semantics Version 5.0 - October 2015 http://www.hpi.uni-potsdam.de/naumann/projekte/rdbms_genealogy.html • SQL-Standardisierung SEQUEL/Original SQL - 1974 SQL/86 - Ratification and acceptance of a formal SQL standard by ANSI (American National Stan- CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 8 dards Institute) and ISO (International Standards Organization). SQL/92 - Major revision (ISO 9075), Entry Level SQL-92 adopted as FIPS 127-2. SQL/99 - Added regular expression matching, recursive queries (e.g. transitive closure), triggers, support for procedural and control-of-flow statements, non-scalar types, and some object-oriented features (e.g. structured types). SQL/2003 - Introduced XML-related features (SQL/XML), Window functions, Auto generation. SQL/2006 - Lots of XML Support for XQuery, an XML-SQL interface standard. SQL/2008 - Adds INSTEAD OF triggers, TRUNCATE statement. • SQL:2011 or ISO/IEC 9075:2011 Parts Part 1: Framework (SQL/Framework) Part 2: Foundation (SQL/Foundation) Part 3: Call-Level Interface (SQL/CLI) Part 4: Persistent Stored Modules (SQL/PSM) Part 9: Management of External Data (SQL/MED) Part 10: Object Language Bindings (SQL/OLB) Part 11: Information and Definition Schemas (SQL/Schemata) Part 13: SQL Routines and Types Using the Java Programming Language (SQL/JRT) Part 14: XML-Related Specifications (SQL/XML) • SQL-Schnittstellen anderer Systeme (IDM (1984), INGRES (1985), SESAM (1989), UDS (1989)) VisualSQL als Zusammenführung von SQL, Quel und visuellen Sprachen 2. QUEL - Linie logisch-orientierte Sprache 3. QBE -Linie Query-by-example nicht durchgesetzt ... intelligente Oberflächen 4. Datenbankprogrammiersprachen DBPL, ADABPL, Galileo, Persistente Programmiersprachen Einbettung in PASCAL, Modula-2, QUEST, ... 5. VisualSQL - unsere Eigenentwicklung - steht auch jedem zur Verfügung Verschiedene Benutzer verschiedene Rollen • Administrator (Datenbankadministrator) Ressourcenverwaltung, Zutrittsrechte, internes Schema, tuning und monitoring, Sicherheit und Zuverlässigkeit • Entwerfer (Unternehmensadminstrator) konzeptionelles Schema, externe Schemata, Software-Entwicklung • Systemanalytiker, Anwendungsprogrammierer Anforderungserhebung, Software-Entwicklung • Endbenutzer • Zufälliger Benutzer unterschiedliche Info, komplexe Auswertungen, schnell mal reinschauen, manager, Anfragen nicht vorhersehbar • Naiver (oder parametrischer) Benutzer Anwendungsprogramme, ‘canned transactions’, Sachbearbeiter, ... CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 9 • Voll ausgebildeter Benutzer komplexe Anforderungen, gute Kenntnis von DBS und Schnittstellen, Techniker, wissenschaftler, Analytiker, ... • DBMS und Tools Designer und Implementierer • Operatoren und Wartungspersonal Nutzen von DBMS 1. Kontrollierte Redundanz 2. Daten-sharing 3. Eingeschränkter Benutzerzugriff concurrency, user view security, authorization 4. Verschiedene Interfaces 5. Darstellung komplizierter Beziehungen der Daten 6. Integritätserzwingung 7. Robustheit, Wiederanlauf Vorteile von DB 1. Standarderzwingung 2. Flexibilität 3. Verringerte Anwendungsentwicklung 4. Up-to-date-Information für alle Benutzer 5. Aufgabenverteilung ⇒ Einsatz von DBMS • heterogene Benutzergruppen, gemeinsame Datenhaltung • keine oder kontrollierte Redundanz gewünscht • Benutzerverwaltung, Authorisierung • Unterschiedliche Schnittstellen für unterschiedlich geschulte Benutzer • komplexe Daten, komplexe Beziehungen zwischen den Daten • Integritätsmechanismen sollen genutzt werden • Backup, Fehlerbehandlung • geringe Entwicklungszeit für sich ändernde Anwendungen Ein DBMS sollte man nicht benutzen, wenn • hoher overhead wegen backup, recovery β CAU Kiel, IfI, ISE WS 2016/17 Informationssysteme 0. Einführung • hoher initialer Aufwand (HW + SW) bei geringem Nutzen • Allgemeinheit der vorhandenen Funktionen • security, safety, concurrency control, recovery, integrity • Anwendung und DB sind eher einfach • real-time-Forderungen, die dem overhead gegenüberstehen • kein Mehrfachparallelzugriff auf Daten 0.1.2 Information ‘Information’ - vielseitig belegt Ereignisse untereinander in Beziehung gesetzt unter Gesichtspunkt inwieweit Unsicherheit verringert wird Absteckung des Möglichen Wahrscheinlichkeitstheoretische Sicht von Informationen Gegeben ist eine Zufallsvariable a = (a1 , ..., an ) p(ai ) Wahrscheinlichkeiten des Eintreffens von ai a - Ausschnitt aus Menge der möglichen Ereignisse Informationsgehalt des Wertes ai der Zufallsvariablen a : Unsicherheit, die durch das tatsächliche Eintreffen von ai beseitigt wird Nichtereignis versus Ereignis Formalisierung durch Maß • I(ai ) = I(ai ) mit folgenden Anford. f (p(ai )) • f ist stetig in [0,1] • f ist antiton (wahrscheinlichere Ereignisse enthalten weniger Information) • Informationsgehalt ist additiv: f (p1 ∗ p2 ) = f (p1 ) + f (p2 ) ⇒ dadurch ist I bis auf Konstante eindeutig festgelegt I(ai ) = −ld(p(ai )) = ld( 1 ) p(ai ) falls p(ai ) ̸= 0 Informationsgehalt von einem einzelnen Wert ai falls p(ai ) = 1 , dann keine Unsicherheit beseitigt wird nun der gesamte Informationsgehalt der Zeichen von a betrachtet, d.h. H(a) = n ∑ p(ai )I(ai ) i=1 ist der mittlere Informationsgehalt von a (Entropie) durch weitere Ausnutzung der WMS-Grundlagen angewandt auf Übertragung von Signalen = − n ∑ i=1 p(ai ) ld(p(ai )) 10 CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung Kanal Sender −→ Empfänger bedingte Wahrscheinlichkeiten, unabhängige Zufallsgrößen, ... z.B. Hvor (x|y) und Hnach (x|y) Unsicherheiten von x unter y vor und nach Ausführung D(x, y) := Hvor (x|y) − Hnach (x|y) übertragene Information Modelltheoretische Sicht von Informationen Klasse K von Strukturen gegeben (M = (D, r1 , ..., rn ), ri τi -stellige Relationen) “Ereignisse” werden durch FOPL-Formeln dargestellt Aussage entweder wahr oder falsch in M (falls wahr, dann M Modell von α) d.h. M odK (α) = {M ∈ K | M |= α} ⊆ K bzw. M odK (Φ) = ∩M odK (α) falls Φ bekannt, dann unsicher, welches Modell vorliegt sicher, fall ||M odK (Φ)|| = 1 ; höchst unsicher, falls M odK (Φ) = K Beispiel: S := if x ≥ 8 then y := 1 else y := 0 nach Ausführung der Anweisung und bei Beobachtung von y verringert sich Unsicherheit über x w(eakest) p(recondition) {S} Φ x - Sender; y - Empfänger damit verändert der Informationsfluß von x nach y unsere Kenntnis über die Modellklasse mitunter ist auch Information redundant 0.1.3 Kommunikation ebenso überladen kommunikatives Handeln: Verständigung über ihre Handlungssituation Sprache zur Mittlung Kommunikation als Synthese dreier Selektionen: • Information, ausgewählt aus einem Vorrat an Möglichen • Mitteilung, von Sender gewählt für sein Verhalten • Verstehen zur Veränderung der Möglichkeiten des Empfängers daran anschließend: Ablehnung oder Annahme des Verstandenen 0.1.4 Wirklichkeit und Modell Abstraktion als Mittel der Modellierung verschiedene Arten 1. Datenabstraktion • Klassifizierung / Instantiierung • Aggregation / Dekomposition (Tupel-, Mengen-, Listen-, Clusteroperatoren) • Hierarchien (Generalisierung / Spezialisierung) 11 CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 12 2. Lokalisierungsabstraktion • Unterscheidung zwischen Definition und Verwendung (Wiederverwendung, Wiederholung) • naming • binding • scoping 3. Implementationsabstraktion • Verkapselung (Modularisierung) • Sichtbarkeit , hiding • mapping 0.2 Architektur Architektur mit einer Vielzahl von Sichten Modellierungsarchitektur z.B. Dreiebenenarchitektur dient dem Verständnis Modularchitektur (auch als technische Architektur) Typische Ausprägungen Schichtenarchitektur je nach Anwendungsaktivität oft auch eigenständige Architekturvariante Anwendungsarchitektur entspricht Diagramm der Aktivitäten (wie z.B. Gehirnaktivität) Architektur der Komponenten mit entsprechenden Schnittstellen Architektur als glass box mit einer Abstraktion von Interna der Komponenten Infrastruktur-Architektur mit den entsprechenden Begleitsystemen, Schnittstellen, Kollaboration Integrationsarchitektur im Sinne der Gestalltung der Landschaft Landschaftsarchitekt DBS = DBn + DBMS Dreiebenenarchitektur einer DB-Anwendung darauf aufbauend: 5-Schichten-Modell eines DBMS 1. Ebene derBenutzersprache Benutzerschnittstelle 2. Ebene der Anfrageverarbeitung 3. Ebene der Zugriffstrukturen und Code-Erzeugung 4. Ebene der Synchronisation paralleler Zugriffe 5. Ebene der Speicherverwaltung Darauf aufbauend hat das System verschiedene Schnittstelle Geräteschnittstelle CAU Kiel, IfI, ISE β WS 2016/17 Abstraktionsebene Informationssysteme 0. Einführung zugeordnete Sprache Externe Ebene Externes Externes Schema ... Schema n 1 6 ? ? Interne Ebene DatenDefinition I Konzeptionelle Ebene 6 - 13 DatenManipulation R - DatenAdministration - Abbildung 2: Dreiebenen-Modellierungsarchitektur bzw. -schichtung • Mengen-Schnittstelle select, insert, delete, modify 1 ↔ 2 views, Relationen • Tupel-Schnittstelle fetch, store, erase, update 2 ↔ 3 Cursor, Tupel • Record-Schnittstelle retrieve, add, change, dispose, change 3 ↔ 4 (Index-)Records • Seiten-Schnittstelle read, write 4 ↔ 5 Seiten, Segmente Service des DBMS am Beispiel der Anfrageverarbeitung 1. Überprüfung der Syntax 2. Authorisierungs- und Existenztest 3. Generieren der notwendigen internen Operationen und Speichermechanismen 4. Generieren eines effizienten Programmes 5. Berechnen der Anfrage in der DB 6. Aufbereiten der Anfrageergebnisse (Operand) 7. Sicherstellen, daß Ergebnis während der Ausführung der Anfrage nicht geändert wird darauf aufbauend verschiedene Sprachen für den Benutzer Data Definition Language (DDL): Definition des konzeptionellen Schemas einer Datenbank falls keine zusätzliche Storage Definition Language (SDL) vorhanden auch implizit (d.h. abgeleitet aus DDL-Definitionen) oder explizit Defintion des internen Schemata View Definition Language: Sichtendefinitionssprache zur Definition der externen Schemata Data Manipulation Language (DML): Datenmanipulationssprache zur Modifikation der vorhandenen Datenbank und zur Wiedergewinnung von Informationen CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 14 DBMS Kommunikations-Subsystem InputOutputProzessor Authorisierungkontrolle Parser Precompiler Compiler UpdateProzessor QueryProzessor Optimierer Zugriffsplanerstellung Code-Erzeugung Integritätsprüfung und -erzwingung Verteilungsmanager Recovery Manager Synchronisation paralleler Zugriffe Transaktionsverwaltung Scheduler Speicherverwaltung Data-Manager 6 6 ? Support Systeme Graphische etc. Buffer-Manager 6 ? Logbuch 6 ? - Data Dictionary Datenbank Datenbank Datenbank Datenbank ... Datenbank ? Betriebssystem Abbildung 3: Einfache Sicht (Schichtenarchitektur der Module) auf moderne DBMS CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 15 DBMS InputOutputProzessor Authorisierungkontrolle UpdateProzessor QueryProzessor Code-Erzeugung Speicherverwaltung Data-Manager 6 6 ? Support Systeme Graphische etc. 6 ? Logbuch 6 ? - Data Dictionary Datenbank ? Betriebssystem Abbildung 4: DBMS einfachster Prägung (meist als Einstiegsdroge benutzt) CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 16 Retrieval für die Abfrage Insert für das Einfügen von Daten Delete für das Löschen von Daten Update für die Modifikation der Daten Konzepte der DML können auf unterschiedlicher programmiersprachlicher Basis existieren nicht prozedural / prozedural mengenorientiert / satzorientiert data sublanguage / host language Host Language des unterlegten Programmiersystemes Moderne DBMS bieten eine deklarative DDL, eine deklarative DML und auch eine embedded host language an. Alles andere kann aus diesen Sprachen generiert werden. Die DDL umfaßt auch direkte Möglichkeiten zur Darstellung von Sichten. Die Sprachen basieren auf entsprechenden Datenbankmodellen und auf Typensystemen, die den Programmiersprachen entlehnt sind. Wir unterscheiden heute je nach Datenbankmodell Relationale DBMS (auf der Grundlage des relationalen DB-Modelles), Hierarchische DBMS (auf der Grundlage des hierarchischen DB-Modelles), Netzwerk-DBMS (auf der Grundlage des Netzwerk-DB-Modelles) und neuerdings Objektorientierte DBMS (auf der Grundlage von DB-Modellen mit umfangreicheren Typensystemen und einer direkten Darstellung von Objekten mit ihren Identifikationsmechanismen und ihren Methoden), XML-DBMS als Erweiterung von Ausspiel- und Austauschformaten hin zur objektentfalteten Speicherung von Dingen der Realität mit Eigenbeschreibung, Objektrelationale DBMS als Erweiterung relationaler und universeller Systeme, sowie eine Reihe weiterer Arten von DBMS. Klassifikation von DBMS Datenmodell relational, Netzwerk, hierarchisch, oo # Benutzer Single oder Mehrfachbenutzer # Knoten Zentralisiert oder verteilt • homogen • heterogen • förderiert • interoperabel Kosten Zugriff Typen von Zugriffspfaden General purpose Allgemeine Anwendungen oder Spezialanwendungen CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 17 Architektur Wie gut kann der Server seine Ressourcen im Mehrnutzerbetrieb ausschöpfen ? Einprozeßarchitektur Module der Anwendung und für Zugriff in einem Prozeß zusammengefaßt. + : keine zusätzliche Kommunikation - : selten im Unix-Umfeld Mehrprozeßarchitektur Volle Parallelität der einzelnen Module. + : für viele Anwender und viele parallele Prozesse Zugriffsprogramm nur einmal geladen; Ressourcenminimierung + : einfache Kontrolle der beteiligten DB-Prozesse Single-Threaded-Single-Server-Arch. Jedem Anwendungsprogramm wird sein Prozeß zugeordnet, der über die volle Funktionalität des Servers verfügt. evt. auch Weiteruntergliederung des Servers in verschiedene spezialisierte Prozesse; + : Verarbeitung läßt sich parallelisieren; effizienter Parallel-Server-Arch. Einzelne Funktionen sind in einem Cluster-System (Rechnerzusammenschluß ohne Hauptspeicher und mit gemeinsamer Peripherie) zusammengefaßt Multi-Threaded-Single-Server-Arch. Ein zentraler DB-Prozeß bedient alle Front-End-Prozesse. + : Ein Prozeß wird nur einmal geladen und verteilt die Arbeit auf parallel arbeitende spezialisierte Prozesse. (weniger Speicherbelastung, jedoch wird dann zentraler Prozeß evt. Engpaß) Multi-Threaded-Multi-Server-Arch. Mehrere Backendprozesse versorgen die Frontendprozesse mit Daten. (evt. mit Priorisierung der einzelnen Klassen zur Effzienzverbesserung) (+ : für viele hundert Benutzer noch gute Antwortzeiten) Warum Optimierung ? Weg vom mainframe zur Unix-Umgebung Massives paralleles Processing als Ausweg Bislang offen: wahre Bedeutung von Multiprozessoren und Multiprozessing Ziel war: Anwendungsunabhängigkeit (nicht mehr Programmieren von Seiten, cache Größe, sharing memory, Code-Längen) wichtige Leistungsparameter • Throughput: heute Tausende von Datenbank Requests / Sekunde (TDRPS) frühere Meinung: nur für high-end Firmen; aber heute Ausweitung der DB Technologie auf BS Routinen (Speichertabellen und hartkodierte Werte mit abgelegt) - damit neue Herausforderung • Relationale Technologie und Implementation: bislang effizienter Zugriff für ein Attribut (einschließlich tuning) • Skalierbarkeit und modulares Wachstum: große Zugriffsrate insbesondere in im Netz (mit logischen zentralen ‘Warenhaus’) erfordert spezielle Zugänge zur Leistungserhöhung, Zugriffszeitreduktion, Erhöhung der Flexibilität und für Erweiterbarkeit Das Throughput-Problem Verarbeitung nach Warteschlangen-Theorie Service-Zeit: Beginn mit dispatch vom Programm, Ende mit Prozessorfreigabe Damit einige Parameter: • Ankunftsrate der Prozesse (wartende und ankommende) • Service-Rate (Zeit pro Service und Prozeß) • Serviceintensität (# simultane (concurrent) Operationen) • Länge der Warteschlange (insbesondere der Prozesse gleicher Priorität) • Scheduling delay • Servicekapazität CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 18 2 Basisstrategien: Multiprogramming (mehrere Prozesse auf einem Prozessor) und Multiprocessing (ein Programm auf mehreren Prozessoren) nunmehr Multiprocessing statt Multiprogramming (eigentlich nur Pseudoparalleleität) multitasking (oder synonym multithreading) =⇒ Granularität muß reduziert werden Pipelining, shared Speicherressourcen, nachrichtenbasierte Interprozeßkommunikation Wissenschaftliche Anforderungen • Referentielle Integrität, Integritätsbedingungen • Komplexe Strukturen • Sicherheit • Komplexe Transaktionen • Intelligentes Suchen (Index aufwärts, abwärts, ...) Wichtigste Auswahlkriterien für Systeme 1. Multiuserfähigkeit 2. Datenbankinterne Datenbeschreibungs- und manipulationsprache 3. Sicherheit 4. Leistungsfähigkeit Einige Leistungen der Datenbanktechnologie: I. Technologie auf sicherer theoretischer Basis Mit der Entwicklung des relationalen Datenbankmodelles Strukturierung von Datenbanken Semantik von Datenbanken Generische Operationen Optimierungstheorie Interoperabilität, Verteilung, middleware Dynamik von Datenbankanwendungen Benutzerunterstützung Ausgereifte Datenbankmodelle Darauf aufsetzend: Theorie semantischer und objekt-orientierter Datenbanken Ausgereifte Technologie Ausgereifte, standardisierte Programmiersprachen SQL92 (SQL2), Einbettungsprinzipien in Wirtssprachen Ausgereifte Architektur von Systemen Einbettung in Betriebssysteme, graphische Systeme, ... Komponentenarchitektur, 3-Ebenen-Architektur Verteilung (two tier, three tier, trader) Benutzbarkeit für jedermann: Benutzungsoberflächen Vielfältige Einsatzgebiete durch Erweiterungen der Technologie Informationssysteme, Wissensbanken, Information-Retrieval-Systeme, Suchmaschinen, Dokumenten-Management-Systeme, Entscheidungsunterstützungsysteme, MIS, EIS, Data Warehouse, Internet-DB, Multimedia-DB, Dienste CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 19 Sichere Technologie Sicher für den Anwender Verhalten der Datenbank gesichert Daten gegen Schäden der HW/SW gesichert Sicher gegen Fremdbenutzer Einhaltung der Sicherheitsforderungen Veränderungssicherheit Nachvollziehbarkeit Sicherheitsnormen auf B-, sogar A-Niveau Sicher gegen den Anwender und seine Fehler (Konsistenzerzwingung), seine Nachlässigkeiten (Transaktionskonzept), seine Neugier (Sichten) Ausgereifte Pragmatik vorhanden: Methodiken und Vorgehensmodelle zum Entwurf und zur Implementation von Datenbankanwendungen insbesondere für relationale Anwendungen Beherrschung des Anwendungs-Engineering über die volle Lebenszeit der Anwendung mit Redesign, ReEngineerung Beherrschung der Abstraktion Somit: Regelmäßiges semiotisches Dreieck (Syntax, Semantik, Pragmatik) 0.3 Der grundlegende Zugang zur Modellierung formale Sprache erfinden verwirklichen benutzen Paradigmen \ Theorie • • Abstraktion • Entwurf • Begriffsgerüste Sinn von Informationssystemen • (handelnde) Personen • (strukturelle) Verpflichtungen innerhalb der Unternehmen • die von einer jeweils ausgeführten (sozialen) Rolle abhängen • ihr dazu notwendiges Wissen über das Unternehmen • ihre (formalen) Handlungen • die zugrundeliegenden Mitteilungen Wissen der Anwendung Drei Abstraktionsarten statische Gesichtspunkte einer Anwendung Struktur in Abhängigkeit des Typensystems meist nur Datenabstraktion • Seiendes (entity) : Ding, das wirklich exisitert • Beziehung (relationship) : Zusammenhang • Eigenschaft, Attribut : extensional (Dinge sind durch ihre Eigenschaften vollständig beschrieben und identifizierbar) Dinge stehen in Beziehung bzw. besitzen Eigenschaften CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 20 • Rolle evt. auch mehrmals • Klassenbildung als Abstraktionsprinzip Gesamtheit der Dinge modellieren • Aussonderung : Separation / Spezialisierung • Verallgemeinerung : Generalisierung von Gemeinsamkeiten • Aggregation : Semantik einschränkende Bedingungen für wirklichkeitsgetreue Nachbildung der Anwendung • eindeutige Bestimmung aller Objekte : Schlüsselbedingung • Hierarchie der Objekte Aussonderungsbedingungen (specialization, IsA): Objekte sind auch Objekte in anderen Klassen Verallgemeinerungsbedingungen (partition constraints, uniqueness constraints): Beziehungen zwischen Objekten in einer Verallgemeinerungsklasse • Bedingungen für Beziehungsklassen • funktionaler Zusammenhang (viele-eins-Bedingung) • jedes Komponentenobjekt einbezogen ? Seinsbedingung (existence constraint) • Verweisbedingung auf Objekte der Komponentenklassen • allgemeine Bedingungen - inhärente Bedingungen des Modells • Gesamtheitsregel (universe of discourse) : Gesamtheit der möglichen Seienden ist durch folgende Angaben ... vollständig beschrieben • Verneinungsregel : Ist eine Beziehung weder direkt noch indirekt dargestellt, dann gilt sie nicht. Sichten und abgeleitete Begriffe : aus den Objekten der DB erschließbar Lokalisierungs- und Implementationsabstraktion, mitunter auch Datenabstraktion • Regeln zur Generierung des nicht direkt dargestellten Wissens abgeleitete Begriffe und Typen (Vorfahren aus Eltern-Kind-Beziehung) • Regeln zur Generierung des Ausschnittes, der für handelnde Personen sichtbar sein soll oft als Implementationsabstraktion verstanden für externe Sichten (Sichtbarkeit, hiding) Modularisierung (Verkapselung) oft nur nebenrangig daneben aber auch als Lokalisierungsabstraktion (Unterscheidung zwischen Definition und Verwendung, naming, binding, scoping) dynamische Gesichtpunkte der Anwendung Operationen - Handlungen zur Darstellung des dynamischen Verhaltens • • • • Änderungsoperationen - zur Veränderung im Wissen Retrievaloperationen - zur Erschließung des Wissens ohne Veränderung der DB Sprache zur Generierung von Programmen (siehe Theorie der Programmiersprachen) Rollenveränderungen von dargestellten Objekten Semantik zur Darstellung von zugelassenen und verbotenen Handlungsfolgen Verpflichtungen innerhalb einer Rolle beschrieben durch • welches Wissen zugänglich (Sichten (konsistent zu deren Definition)) und welche Handlungsfolgen ausgeführt werden müssen, evt. unter Berücksichtung von Ursachen (aktive Elemente) • welches Wissen zugänglich (Sichten (konsistent zu deren Definition)) und welche Handlungsfolgen ausgeführt werden dürfen, evt. unter Berücksichtung von Voraussetzungen Mitteilungen an einen oder den anderen Empfänger, die sie ihrerseits verstehen und verarbeiten sollten CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 21 zeit(un)abhängige Beschreibungen • zeitunabhängig wird meist die Semantik vorausgesetzt, evt. auch Operationen, fast immer die Struktur • zeitabhängig ist z.B. aufzählendes Wissen, insbesondere Inhalt der Datenbank Daraus folgt: 3 1 2 Schichten bei der Darstellung einer Datenbank 1. Datenstrukturen (des zugrundegelegten DBMS oder allgemeine) (Datenschema) 2. Struktur, Operationen, Semantik, Sichten, ... (Datenbank-Schema) 3. Datenbankinstanz, die dem DB-Schema entspricht 4. Beispieldaten Zur Erinnerung: Grundbegriffe der Logik, der Mengenlehre, der Theorie der Programmiersprachen Einige wichtige Begriffe • Syntax • Alphabet • Variable (Individuen-, Funktions-, Prädikaten-) • induktive Definition von Formeln • Interpretation • Gültigkeit • Modell • Allgemeingültigkeit, Erfüllbarkeit • Folgerung • Ableitungsregeln • die durch Ψ ausgesonderte Menge Allgemeines Vorgehen • Typen sind über ihre Typausdrücke definiert. Den (freien) Variablen werden wiederum Typen zugeordnet. • Die Zuordnungsvorschrift für Typausdrücke kann sowohl hierarchisch als auch zyklisch sein. Wählt man eine zyklische Struktur, dann sind meist nur Topoi-Semantiken geeignet. Wählt man hierarchische Strukturen, dann kann meist eine Mengensemantik noch garantiert werden. • Typen haben eine assoziierte Semantik (statische). • Typen haben Operationen zu ihrer Manipulation und Veränderung. Man kann diese Operationen generisch definieren, wenn die Typenstruktur hierarchisch aufgebaut ist. (siehe Vorlesung Theorie der Programmiersprachen: Semantik von goto) CAU Kiel, IfI, ISE β semantische Begriffe Seiendes einfach zusammenges. Beziehung Eigenschaft / Attribut WS 2016/17 Informationssysteme 0. Einführung Grundbegiffe aus Logik/Mengenlehre Syntax Semantik Konst.-zeichen Elem. ∈ Wertemenge Grundterm (mit Fkt.-z.) atomare Grundaussage Tupel einer Relation Rolle (bei Bezieh.) (2-stell.) atomare Grundaussage / Grundterm Stelle eines Präd.-z. Komp. einer Relation Klassenbildung Gesamtheit Aussonderung Menge v. Konst.-zeich. Formel ϕ Universum dM,ϕ , 2M Verallgemein. ∨ Vereinigung Aggregation ∧, = ∩,× (implikative) Aussage mit =-Konklusion Modellklasse Bedingung Schlüsselbeding. Aussonderungsbed. Verallgemein.-bed. 1-n-Beding. Seinsbeding. Verweisbeding. Regel Gesamtheitsregel Verneinungsregel Sichtregel Handlung Information Tupel einer (2-stell.) Rel. Funktionswert 22 Konzepte imperativer Prog.-Spr. Konstante Strukturbaum eines Terms Verbund (reecord), Aufruf Boolesch-wert. Proz. Verbund (record) Aufruf einer attribut.wertigen Fkt.-proz. Komp.-bezeichner (Verbund) formaler Parameter (F.-proz.) Deklaration Typendeklarat. Menge, Deklar. (Bool.-w.) Funkt.-proz. Deklarat. eines varianten Verbundtyps Deklarat. von Feldund Verbundtypen Deklarat. einer Prozedur mit =-Konklusion Deklaration einer Prozedur Ableit.-regel, Formeln Ableit.-regel, Formeln Formeln logische Implikation logische Implikation Relation Verkleinerung der Modellklasse Mitteilung konjunktiv hinzugefügte Aussage Aussage Verstehen Widerspruchsfreiheit Erfüllbarkeit Zustandänderung (Wertzuweisung) akt. Parameter beim Prozeduraufruf Ausführung einer Proz. 0.4 Database Systems at the First Level as Abstract State Machines In this section we describe the semantics of a first level database using abstract state machines. The specification is executable using AsmL 1.5, however, we used syntax from AsmL 2.0 at several places in order to make the specification more readable. Currently we are converting the specification to AsmL 2.0 format. 0.4.1 The Database System as an Input-Output Engine At the first level we describe databases from the outside point of view. The structure of the database is fixed, i.e. we do not consider any create/delete table operations. The semantics of those is simple enough. The common data types between inner and outer representation are view names, relation names and procedure names (for stored procedures) and attribute names (including primary and secondary keys). Therefore the interface specification is as follows: type type type type type ViewName RelationName ProcedureName AttributeName TypeName = = = = = String String String String String CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 23 For the representation of stored procedures it is essential to have complete freedom as to how the body of the procedure is defined. This is achieved by allowing the complete power of ASM for the definition of the body. To this end, only an interface is given, how the computations of a procedure should function, and the rest can be given as an ASM procedure. See also 0.4.4 below for some concrete examples of stored procedures. interface ProcedureStep stepAction(params as Seq of Data) as Set of Request stepResult(params as Seq of Data) as Data structure StoredProcedure transactional as Boolean params as Seq of String // means sequence of types contents as Seq of ProcedureStep 0.4.2 Structuring of the Database First, we define the global types necessary for databases. These types are • Database, • Request, with the kinds • Insert • Delete • Update • Call (of a stored procedure) • simple Select (provide a relation as result) • general Select (just provide any result data) and • Answer, which can be a status message or a relation in case of a simple select request. Moreover, we want to use variables at several places. Therefore we define the global database structure as follows: structure Database content as Map of RelationName to Relation procs as Map of ProcedureName to StoredProcedure constraints as Set of Constraint structure Request case Insert relName as RelationName ins as Tuple case Delete relName as RelationName del as Tuple case Update relName as RelationName upd as Tuple case Call pname as ProcedureName pparams as Seq of Data presult as Variable case SimpleSelect what as Seq of AttributeName From as RelationName Where as Constraint result as Relation CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 24 case OutputSelect result as Set of Tuple structure Answer case StatusAnswer status as String case RelationAnswer rel as Relation class Variable name as String value as Data 0.4.3 The Global States of the Database System Now we define the global state variables: an input, an output, a set of variables and the database. var var var var input as Set of Request = {} output as Seq of Answer = [] variables as Set of Variable = {} database as Database = Database({|->},{|->},{}) The action on the database depends on the input as follows (compare again with ??): DBAction() = choose inp in input do input:= input difference { inp } ProcessAction(inp) ProcessAction(inp as Request) = match inp with Insert(n,t): DBChange(n,inp) Delete(n,t): DBChange(n,inp) Update(n,t): DBChange(n,inp) Call(p,par,v): let proc = database.procs(p) if proc = undef then output:= output + [StatusAnswer("no such procedure: " + p.name) as Answer] else DBCall(proc,par,v) SimpleSelect(what,n,constr,result): //very simple version first let res = database.content(n) if res = undef then output:= output + [StatusAnswer("relation " + n.name + " not defined") as Answer] else output:= output + [RelationAnswer(res) as Answer] This behaviour is refined with the definition of DBChange for a simple change to the database and DBCall for the call of a stored procedure. A single change to the database is described using the function DBStep DBChange(n as RelationName, r as Request) = let rel = database.content(n) if rel=undef then output:= output + [StatusAnswer("no such relation") as Answer] else let newDB = DBStep(database.content, n, r) if check(newDB,database.constraints) then database.content:= newDB output:= output + [StatusAnswer("ok") as Answer] else CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 25 output:= output + [StatusAnswer("constraint violation") as Answer] DBStep(cont as Map of RelationName to Relation, n as RelationName, r as Request) as Map of RelationName to Relation = let rel = cont(n) let newrel = match r with Insert(_,t): Relation(rel.attributes, rel.members union {t}) Delete(_,t): Relation(rel.attributes, rel.members difference {t}) Update(_,t): Relation(rel.attributes, (rel.members difference sameKeys(n, rel.members, t)) union {t}) cont override { n |-> newrel } An update to a relation consists of two steps: first, all tuples which have the same key values are deleted, and second, the new tuple is inserted. The tuples with the same key values are computed using the function sameKeys below. sameKeys(n as RelationName, r as Set of Tuple, t as Tuple) as Set of Tuple = let attr = database.content(n).attributes let keys = { (d as KeyConstraint).key | d in database.constraints where d is KeyConstraint and (d as KeyConstraint).rel = n } bigUnion({ { tup | tup in r where getKey(attr,tup,k)=getKey(attr,t,k) } | k in keys }) getKey(n as Seq of AttributeName, t as Tuple, k as Set of AttributeName) as Seq of Data = let len = if length(t.contents) < length(n) then length(t.contents) else length(n) [t.contents(idx) | idx in [ 0 .. len ] where n(idx) in k] DBCall(p as StoredProcedure, par as Seq of Data, res as Variable) = let chk = ParamCheck(p,par) if chk and p.transactional then machine var localDB as Map of RelationName to Relation = database.content foreach pstep in p.contents do foreach act in pstep.stepAction(par) do match act with Insert(n,t): if localDB(n)=undef then output:= output + [StatusAnswer("no such relation") as Answer] else localDB:= DBStep(localDB, n, act) Delete(n,t): if localDB(n)=undef then output:= output + [StatusAnswer("no such relation") as Answer] else localDB:= DBStep(localDB, n, act) Update(n,t): if localDB(n)=undef then output:= output + [StatusAnswer("no such relation") as Answer] else localDB:= DBStep(localDB, n, act) _: output:= output + [StatusAnswer("invalid action in stored procedure") as Answer] step if check(localDB,database.constraints) then database.content:= localDB output:= output + [StatusAnswer("stored procedure ok") as Answer] else output:= output + [StatusAnswer("constraint violation in stored procedure") as Answer] else if chk then CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 26 foreach pstep in p.contents do foreach act in pstep.stepAction(par) do ProcessAction(act) else output:= output + [StatusAnswer("illegal parameters for stored procedure") as Answer] ParamCheck(p as StoredProcedure, par as Seq of Data) as Boolean = let len = length(p.params) let ldiff = length(par) - len ldiff >= 0 and (forall idx in [0 .. len-2] holds p.params(idx)=par(idx).typ) and (p.params(len-1)="*" or (p.params(len-1)=par(len-1).typ and length(par)=len)) This concludes the top level view of databases. We proceed with defining relations and tuples. Moreover, we define a basic set of data types allowed within the database. structure Relation attributes as Seq of AttributeName members as Set of Tuple structure Tuple contents as Seq of Data // no nested Tuples allowed structure Data typ as String case PUndef case PInteger val as Integer case PString val as String case PShort val as Short case PByte val as Byte case PChar val as Char case PBoolean val as Boolean case PDate val as Date case PTimeStamp val as Float // could add more here converter converter converter converter converter converter converter converter (x (x (x (x (x (x (x (x as as as as as as as as Integer) as Data = PInteger("Integer",x) String) as Data = PString("String",x) Short) as Data = PShort("Short",x) Byte) as Data = PByte("Byte",x) Char) as Data = PChar("Char",x) Boolean) as Data = PBoolean("Boolean",x) Date) as Data = PDate("Date",x) Float) as Data = PTimeStamp("TimeStamp",x) We also have to define what constraints are and how they are checked. We distinguish between only two kinds of constraints, namely key constraints and domain constraints. A key constraint says, that the values on the corresponding attributes are unique within the relation. A domain constraint is used for type-checking the attribute values. structure Constraint case KeyConstraint rel as RelationName key as Set of AttributeName case DomainConstraint rel as RelationName attr as AttributeName domain as TypeName check(cont as Map of RelationName to Relation, constr as Set of Constraint) CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 27 as Boolean = forall c in constr holds forall r in dom(cont) holds checkOne(c,r,cont(r)) checkOne(c as Constraint, n as RelationName, rel as Relation) as Boolean = match c with KeyConstraint(RelationName(r),k): if r <> n.name then true else let relSize=size(rel.members) let keyCount=size({ getKey(rel.attributes,t,k) | t in rel.members }) machine if relSize <> keyCount then write("Key constraint violation: "); prettyPrint(c) step relSize = keyCount DomainConstraint(RelationName(r),attr,TypeName(d)): if r <> n.name then true else forall t in rel.members holds if length(rel.attributes) <> length(t.contents) then machine write("Domain constraint violation: ") write("wrong number of elements in "); prettyPrint(t) step false else machine let elem=getKey(rel.attributes,t,{attr}) if head(elem).typ <> d then write("Domain constraint violation: ") write(" Attribute "); write(r); write("."); write(attr.name) write("="); prettyPrint(head(elem)); write(" must be "); write(d) write(" and not "); writeln(head(elem).typ) step head(elem).typ = d 0.4.4 An Application Example The next part is devoted to an example taken in the context of internet information services. We (partially) define a database of restaurants. We define first some simplifications for defining the database structure: structure DataDesc name as AttributeName typ as TypeName // would be good to have MetaType here mkDataDesc(attr as String, atype as String) as DataDesc = DataDesc(AttributeName(attr), TypeName(atype)) mkRelation(name as String, key as Seq of DataDesc, members as Seq of DataDesc) = let relName = RelationName(name) database.content:= database.content override { relName |-> Relation([k.name | k in key] + [k.name | k in members],{}) } database.constraints:= database.constraints union { KeyConstraint(relName,{k.name | k in key}) as Constraint } union { DomainConstraint(relName, k.name, k.typ) as Constraint | k in key } union CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 28 { DomainConstraint(relName, m.name, m.typ) as Constraint | m in members } Now the macro mkRelation is used to create the database structure. Please note that we left this out of our description of database semantics as it is a static structure. As you can see below, it might still cause some work for a real database. InitSampleDB() = machine variables:= { resVar } step mkRelation("Restaurant", [ mkDataDesc("no","Integer") ], [ mkDataDesc("name","String"), mkDataDesc("street","String"), mkDataDesc("place","String"), mkDataDesc("po_code","String"), mkDataDesc("telephone","String"), mkDataDesc("fax","String"), mkDataDesc("email","String"), mkDataDesc("url","String") ]) step mkRelation("Person", < omitted > ) step mkRelation("Contact", [ mkDataDesc("restaurant_id","Integer") ], [ mkDataDesc("person_id","Integer") ]) step mkRelation("Owner", < omitted > ) step mkRelation("Operation_mode", < omitted > ) step mkRelation("Mode", < omitted > ) step mkRelation("Cuisine_kind", [ mkDataDesc("cuisine_id","Integer") ], [ mkDataDesc("description","String") ]) step mkRelation("Cuisine", [ mkDataDesc("restaurant_id","Integer"), mkDataDesc("cuisine_id","Integer") ], []) step mkRelation("Offers", < omitted > ) step mkRelation("Multimedia", < omitted > ) step mkRelation("Offer_description", < omitted > ) step mkRelation("Special_offers", < omitted > ) step mkRelation("Business_hours", < omitted > ) step mkRelation("Description", < omitted > ) step mkRelation("Location", < omitted > ) step mkRelation("Service_offers", < omitted > ) step mkRelation("Service", < omitted > ) step mkRelation("Cards", [ mkDataDesc("card_id","Integer") ], [ mkDataDesc("description","String") ]) step mkRelation("Credit_cards", [ mkDataDesc("restaurant_id","Integer"), mkDataDesc("card_id","Integer") ], [ ]) step mkRelation("Ambiente_kind", [ mkDataDesc("ambiente_id","Integer") ], [ mkDataDesc("description","String") CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 29 ]) step mkRelation("Ambiente", [ mkDataDesc("restaurant_id","Integer"), mkDataDesc("ambiente_id","Integer") ], [ ]) step mkRelation("Intern", < omitted > ) step mkRelation("Acquisition_url", [ ], [ mkDataDesc("url_menu","String"), mkDataDesc("url_map","String"), mkDataDesc("url_pics","String"), mkDataDesc("url_video","String") ]) The next step is to define two sample stored procedures for the database. These are fairly general procedures for deleting the tuples in a relation and for inserting tuples into a relation thereby creating a unique index for each of the entries. Both kinds of procedures are used later on to modify the database. class SP_DeleteStep implements ProcedureStep stepAction(params as Seq of Data) as Set of Request = let n as RelationName = RelationName((params(0) as PString).val) { Delete(n,t) as Request | t in database.content(n).members where t.contents(1) = params(1) } stepResult(params as Seq of Data) as Data = 0 as Data class SP_FillStep implements ProcedureStep stepAction(params as Seq of Data) as Set of Request = let n as RelationName = RelationName((params(0) as PString).val) { Insert(n,Tuple([idx as Data, params(idx)])) as Request | idx in [1..length(params)-1] } stepResult(params as Seq of Data) as Data = length(params) as Data InitProcedures() = database.procs(ProcedureName("sp_delete")):= StoredProcedure(true, ["String", "String"], // these are the parameter types [ new SP_DeleteStep() as ProcedureStep ]) database.procs(ProcedureName("sp_fill")):= StoredProcedure(true, ["String", "*"], // these are the parameter types, ’*’ means any type [ new SP_FillStep() as ProcedureStep ]) Now we define some sample requests. We obtain the following AsmL specification: InitInsertRequests() = input:= { Call(ProcedureName("sp_fill"), ["Service_offers" as Data, < omitted > ], resVar) as Request, Call(ProcedureName("sp_fill"), ["Operation_mode" as Data, < omitted > ], resVar) as Request, Call(ProcedureName("sp_fill"), ["Cuisine_kind" as Data, "american", "arabian", "argentinean", "australian", "balkan", "bavarian", < many more omitted > ], resVar) as Request, Call(ProcedureName("sp_fill"), ["Ambiente_kind" as Data, "asian", "historic building", "dignified", "bucolic", "luxurious", "modern", "nostalgic", "oriental", "rustic" CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung 30 ], resVar) as Request, Call(ProcedureName("sp_fill"), ["Cards" as Data, "American Express", "DinersCub", "Euro Card", "Euro-cheque", "EC-card", "Visage", "Mastercard", "Tele-Cash", "Restaurant-cheque" ], resVar) as Request, Insert(RelationName("Acquisition_url"), Tuple([ "1" as Data, "2", "3", "4" ])) as Request } InitUpdateRequests() = input:= { Update(RelationName("Cards"), Tuple([ 2 as Data, "Diners Club" ])) as Request, Update(RelationName("Cards"), Tuple([ 6 as Data, "Visa" ])) as Request, // it is not clear whether the following line should produce a key constraint violation Insert(RelationName("Cards"), Tuple([ 7 as Data, "Mastercard" ])) as Request, Insert(RelationName("Acquisition_url"), Tuple([ "a" as Data, "b", "c", "d" ])) as Request, Update(RelationName("Acquisition_url"), Tuple( [ "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/speisekarten/" as Data, "http://delaware.informatik.tu-cottbus.de/Stadtkarte/image.pl?place=", "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/bilder/", "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/video/" ])) as Request } InitCallRequests() = input:= { Call(ProcedureName("sp_delete"), ["Ambiente" as Data,"dummy"], resVar) as Request, Call(ProcedureName("sp_delete"), ["Ambiente_kind" as Data,"modern"], resVar) as Request } InitRetrieveRequests() = input:= { SimpleSelect([],RelationName("Cards"),undef,undef) as Request, SimpleSelect([],RelationName("xxx"),undef,undef) as Request } Now we put everything together to get an executable AsmL specification. The idea is always to initialize a sequence of requests and execute them afterwards using until fixpoint do DBAction(). Please note, that the requests are executed non deterministically and not in the order they are given. run() = machine InitSampleDB() InitProcedures() InitInsertRequests() step until fixpoint do DBAction() step writeln("The result is: ") prettyPrint(output) prettyPrint([StatusAnswer("ready") as Answer]) output:= [] InitUpdateRequests() step until fixpoint do DBAction() step prettyPrint(output) prettyPrint([StatusAnswer("ready") as Answer]) output:= [] InitCallRequests() step until fixpoint do DBAction() step prettyPrint(output) prettyPrint([StatusAnswer("ready") as Answer]) output:= [] InitRetrieveRequests() CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung step until fixpoint do DBAction() step prettyPrint(output) prettyPrint([StatusAnswer("ready") as Answer]) output:= [] writeln(); writeln("The database is: ") prettyPrint(database) 0.4.5 Executing the Abstract Database Machine We can now test the database engine by running the specification. The result is as follows: The result is: Status: ok Status: stored procedure ok Status: stored procedure ok Status: stored procedure ok Status: stored procedure ok Status: stored procedure ok Status: ready Key constraint violation: Key(Acquisition_url)= {} Status: ok Status: ok Status: ok Status: constraint violation Status: ok Status: ready Status: stored procedure ok Status: stored procedure ok Status: ready Relation: card_id description #3 "Euro Card" #4 "Euro-Cheque" #5 "EC-Card" #6 "Visa" #7 "Mastercard" #8 "Tele-Cash" #9 "Restaurant-Cheque" #1 "American Express" #2 "Diners Club" Status: relation xxx not defined Status: ready After executing all the requests, the database has the values given below: The database is: Relation Description: <empty> Relation Mode: <empty> Relation Operation_mode: < omitted > Relation Acquisition_url: url_menu url_map url_pics url_video "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/speisekarten/" "http://delaware.informatik.tu-cottbus.de/Stadtkarte/image.pl?place=" "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/bilder/" "http://www.informatik.tu-cottbus.de/˜cbnet/cb_db/gast/video/" Relation Restaurant: <empty> Relation Owner: <empty> Relation Intern: <empty> Relation Cards: card_id description #3 "Euro Card" 31 CAU Kiel, IfI, ISE β WS 2016/17 Informationssysteme 0. Einführung #4 "Euro-Cheque" #5 "EC-Card" #6 "Visa" #7 "Mastercard" #8 "Tele-Cash" #9 "Restaurant-Cheque" #1 "American Express" #2 "Diners Club" Relation Credit_cards: <empty> Relation Cuisine: <empty> Relation Cuisine_kind: cuisine_id description #1 "american" #2 "arabian" #3 "argentinean" #4 "australian" #5 "balkan" #6 "bavarian" < some more omitted > Relation Location: <empty> Relation Multimedia: <empty> Relation Business_hours: <empty> Relation Person: <empty> Relation Service_offers: < omitted > Relation Service: <empty> Relation Offers: <empty> Relation Offer_description: <empty> Relation Ambiente: <empty> Relation Ambiente_kind: ambiente_id description #8 "oriental" #9 "rustic" #1 "asian" #2 "historic building" #3 "dignified" #4 "bucolic" #5 "luxurious" #7 "nostalgic" Relation Special_offers: <empty> Relation Contact: <empty> < now showing the constraints that are in the database > Domain(Acquisition_url.url_map)= String Domain(Acquisition_url.url_pics)= String Domain(Acquisition_url.url_speisekarte)= String Domain(Acquisition_url.url_video)= String < many more domain constraints omitted > Key(Acquisition_url)= {} Key(Cards)= {card_id} < more key constraints omitted > Press any key to continue 32
