Folien zum Textbuch. Kapitel 2: Planung, Entwicklung und Betrieb von IS. Teil 3: Modellierung von betrieblichen Informationssystemen

Transkript

1 Folien zum Textbuch Kapitel 2: Planung, Entwicklung und Betrieb von IS Teil 3: Modellierung von betrieblichen Informationssystemen Textbuch-Seiten WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/1

2 Datensicht von Informationssystemen Wo befinden wir uns? Strategische IS-Planung IS-Architekturplanung IS-Entwicklung ARIS Organisationssicht Datensicht Funktionssicht Steuerungssicht IS-Betrieb WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/2

3 Architektur integrierter Informations- Systeme (ARIS) von A.-W. Scheer Organisationssicht Fachkonzept DV-Konzept Implementierung Datensicht Steuerungssicht Funktionssicht Fachkonzept Fachkonzept Fachkonzept Drei Beschreibungsebenen: - Fachkonzept - DV-Konzept - Implementierung DV-Konzept DV-Konzept DV-Konzept Implementierung Implementierung Implementierung Leistungssicht WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/3

4 ARIS: Die Datensicht Die Datensicht hat die Definition der Daten in einem IS zum Gegenstand beschreibt die digitalen Repräsentationen der Objekte des zu beschreibenden Realitätsausschnittes Die Darstellungs- bzw. Realisierungsform auf Ebene des Fachkonzepts konzeptionelle Datenmodelle auf Ebene des DV-Konzepts relationale Datenbanksysteme WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/4

5 Datensicht: Konzeptionelles Datenmodell Vereinfachte Beschreibung eines betrieblichen Realitätsausschnitts Definition der relevanten Objekttypen mit ihren sachlogischen und strukturellen Zusammenhängen Beschreibung meist durch eine grafisch orientierte, formale Modellierungssprache (bspw. das Entitiy-Relationship- oder ER-Modell) WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/5

6 Datensicht: ER-Modelle 1/8 ER-Diagramm mit Objekt- und Beziehungstypen Beziehungstypen Objekte Objekttypen Kunde Kunde entleiht Autor Autor verfasst Buch Buch Beziehungen WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/6

7 Datensicht: ER-Modelle 2/8 Grundlegende Elemente des ER-Modells Objekte, Ausprägungen (engl.: entity) Beziehungen (engl.: relationship) Objekttypen (engl.: entity types) Abstraktion gleichartiger Objekte mit gemeinsamen Attributen Beziehungstypen (engl.: relationship types) Abstraktion gleichartiger Beziehungen Konstruktionselemente von ER-Diagrammen: Objekttypen Beziehungstypen (Attribute) <Objekttyp> <Beziehungstyp> WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/7

8 Datensicht: ER-Modelle 3/8 Weiterführende Elemente des ER-Modells Attribute (beschreibende Eigenschaften) Beschreiben die relevanten Merkmale von Objekten oder Beziehungen Konstruktionselement in ER-Diagramm: Identifizierende Attribute auch Schlüsselattribute genannt Kennzeichnen eindeutig ein bestimmtes Objekt eines Objekttyps Ein Schlüssel ist ein Objektattribut bzw. eine Kombination von Objektattributen, die geeignet sind, ein Objekt eindeutig zu identifizieren; man unterscheidet Primär- und Sekundärschlüssel. Konstruktionselement in ER-Diagramm: <Attribut> <Attribut> WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/8

9 Datensicht: ER-Modelle 4/8 Beispiel eines um Attribute erweiterten ER-Diagramms Kunden-Nr. Name Name Kunde Kunde Autoren-Nr. Autoren-Nr. Name Name Adresse Adresse entleiht Datum Datum Autor Autor verfasst Buch Buch Inventarnr. Inventarnr. Titel Titel WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/9

10 Datensicht: ER-Modelle 5/8 Spezifizierung von ER-Beziehungstypen Das Kardinalitätsverhältnis drückt aus, wie viele Objekte eines Objekttyps mit wie vielen Objekten eines weiteren Objekttyps in Beziehung treten dürfen Ausprägungen: 1:1, 1:n, n:m Die Partizipation bestimmt, ob alle Objekte eines Objekttyps an einer Beziehung teilnehmen müssen. Ausprägungen: partiell, vollständig WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/10

11 Datensicht: ER-Modelle 6/8 Beispiele für Kardinalitätsverhältnisse 1:1-Beziehung Mitarbeiter 1 1 verwendet PC Ein Mitarbeiter verwendet maximal einen PC, ein PC wird von maximal einem Mitarbeiter verwendet 1:n-Beziehung Abteilung 1 n beschäftigt Mitarbeiter Eine Abteilung kann mehrere (n) Mitarbeiter beschäftigen, ein Mitarbeiter ist in maximal einer Abteilung beschäftigt WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/11

12 Datensicht: ER-Modelle 7/8 Beispiele für Kardinalitätsverhältnisse m:n-beziehung Mitarbeiter m ist beteiligt n Projekt Ein Mitarbeiter kann in mehreren Projekten beteiligt sein, an einem Projekt können mehrere Mitarbeiter arbeiten WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/12

13 Datensicht: ER-Modelle 8/8 Ein Beispiel einer Partizipation 1:n-Beziehung mit vollständiger Partizipation Abteilung 1 n beschäftigt Mitarbeiter Kardinalitätsverhältnis: Eine Abteilung kann mehrere (n) Mitarbeiter beschäftigen, ein Mitarbeiter ist in maximal einer Abteilung beschäftigt (Optionalität) (vollständige) Partizipation: Jeder Mitarbeiter ist bei einer Abteilung beschäftigt. Es gibt keinen Mitarbeiter, für den das nicht gilt (Ausschluss der Optionalität) WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/13

14 Datensicht: Datenbanksysteme 1/6 Die Realisierung der Datensicht auf Ebene des DV-Konzepts erfolgt durch Datenbanksysteme als Verbund aus Datenbank und Datenbankverwaltungssystem (DBMS) Auf Fachkonzept-Ebene als Vorbedingung: Konzeptionelles Modell Charakteristika eines Datenbanksystems Zentrale Kontrolle von Daten, die von mehreren Benutzern bzw. Programmen verwendet werden Probleme der Datenspeicherung und Dateiorganisation werden zentral und anwendungsunabhängig gelöst Trennung der Daten von anwendungsspezifischen Auswertungen und Datensichten WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/14

15 Datensicht: Datenbanksysteme 2/6 Beispielhafte Verwendung einer zentralen Datenbank Personalwirtschaft Materialwirtschaft Finanz- und und Rechnungswesewesen Datenbank Produktion Forschung und und Entwicklung Vertrieb, Marketing WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/15

16 Datensicht: Datenbanksysteme 3/6 Architektur von Datenbanksystemen Die Architektur von Datenbanksystemen aus der Sicht des ANSI-SPARC- Dreischichtenmodells WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/16

17 Datensicht: Datenbanksysteme 4/6 Ziele des ANSI-SPARC-Dreischichtenmodells Logische Datenunabhängigkeit Entkopplung eines Datenbanksystems von Änderungen der Anwendung Physische Datenunabhängigkeit Entkopplung der Anwendung von der physischen Art der Speicherung der Daten in der Datenbank WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/17

18 Datensicht: Datenbanksysteme 5/6 Externe Schemata Benutzerspezifische Sichten (Ausschnitte) des konzeptionellen Schemas einer Datenbank Warum? Der Benutzer sieht nur die Teile des konzeptionellen Schemas (Gesamtsystems), die für ihn interessant sind Benutzerfreundliche Präsentation (Oberfläche) Beschränkung des Zugriffs auf die wirklich benötigten Daten Zum Beispiel das externe Schema für Bibliothekskunden: Bequemer, rascher Zugriff auf Bücherdaten, aber kein Zugriff auf die Daten der Entleiher und der Lieferanten (Preise usw.) WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/18

19 Datensicht: Datenbanksysteme 2/6 Internes Schema Physische Organisation der Daten auf den peripheren Speichermedien Ziele Minimale Zugriffszeit und Speicherkapazität Wird erreicht durch Wahl geeigneter Größen und Anordnungen der physischen Datenblöcke Erzeugung von Indexdateien für bestimmte Attribute Verwendung geeigneter Zugriffsmethoden Eine Änderung des internen Schemas beeinflusst das konzeptionelle Schema und die externen Schemata nicht! WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/19

20 Datensicht: Relationales Datenmodell 1/12 Das in der Praxis dominierende Datenmodell: Repräsentation der Anwendungsdaten in der Form von Relationen (Tabellen) Relationen (Tabellen) haben einen Namen Relationen (Tabellen) sind Attribute zugeordnet, die durch Spalten repräsentiert sind Zeilen tragen die zusammengehörigen Attributwerte für eine Ausprägung der Relation. Sie werden auch Tupel genannt. Eindeutig identifizierende Attribute/ Attributmengen werden als Primärschlüssel bezeichnet WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/20

21 Datensicht: Relationales Datenmodell 2/12 Relationsschema als ER-Modell [Relation] Kunde(KundenNr,Name,PLZ) Name Name Kunden-Nr Kunde Kunde PLZ PLZ WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/21

22 Datensicht: Relationales Datenmodell 3/12 Relationsschema in Tabellenform [Relation] Kunde(KundenNr,Name,PLZ) Primärschlüssel Attribute KUNDE Kunden- Nr. Name PLZ Tabellenname 1 2 Hansen Torberg Neumann 1010 Tupel 4 Schnitzler WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/22

23 Datensicht: Relationales Datenmodell 4/12 Regelwerk zu Definition von Relationen Werteinschränkungen bezogen auf Attribute (Wertbereiche, Datentypen usw.) Abhängigkeiten zwischen Attributen Funktionale Abhängigkeit Inklusionsabhängigkeit Normalisierung von Relationsschemata Ziel ist es, Dateninkonsistenz und Datenredundanz zu vermeiden WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/23

24 Datensicht: Relationales Datenmodell 5/12 Funktionale Abhängigkeit Ausprägung einer Attributmenge bestimmt Ausprägung einer zweiten Attributmenge Abhängigkeiten zwischen Attributen/ Attributmengen innerhalb einer Relation Beispiel: Kunden-Nr bestimmt Adresse Kunden-Nr Adresse Interpretation: Für eine Kundennummer darf nur eine Adresse in einer Tabelle eingetragen werden. Diese Abhängigkeit wird bspw. verletzt, wenn mehrfach die gleiche Kundennummer vergeben wurde. WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/24

25 Datensicht: Relationales Datenmodell 6/12 Inklusionsabhängigkeit Alle Ausprägungen einer Attributmenge müssen in den Ausprägungen einer zweiten Attributmenge enthalten sein Abhängigkeiten zwischen Attributen/ Attributmengen unterschiedlicher Relationen Beispiel: Interpretation: AUTOR(Autoren-Nr, Name) VERFASST(Autoren-Nr, Buch-Nr) Autoren-Nr VERFASST inkludiert in Autoren-Nr AUTOR Autoren-Nr VERFASST ist Fremdschlüssel (engl.: foreign key). Die Abhängigkeit wird bspw. verletzt, wenn ein Tupel in Relation/Tabelle AUTOR gelöscht wird ohne das korrespondierende Tupel in Relation/Tabelle VERFASST ebenfalls zu entfernen. WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/25

26 Datensicht: Relationales Datenmodell 7/12 Normalisierung von Relationsschemata Attribute werden derart auf Relationen verteilt, dass beim Einfügen, Löschen oder Ändern von Tupeln keine Inkonsistenzen auftreten Erste Normalform: Jedes Attribut ist atomar (nicht weiter zerlegbar) Zweite Normalform: Erste Normalform + jedes Nicht-Schlüsselattribut muss funktional vom Schlüssel der Relation abhängen BUCH(Inv.Nr, Titel, Verlag, Preis,...) Erzwingt semantisch zusammengehörige Attribute pro Relation WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/26

27 Datensicht: Relationales Datenmodell 8/12 Normalisierung von Relationsschemata Dritte Normalform 1. Bedingung: Relationsschema in Erster Normalform 2. Bedingung: Kein Nicht-Schlüsselattribut hängt transitiv, d.h. nicht auch indirekt, vom Schlüssel der Relation ab Beispiel Relation BUCH(Inventarnummer,Kundennummer,Adresse-Ausleiher) Inventarnummer bestimmt Kundennummer Kundennummer bestimmt Adresse-Ausleiher Folglich: Inventarnummer bestimmt Adresse-Ausleiher transitiv Relation(en) in Dritter Normalform BUCH(Inventarnummer, Titel, ) LEIHE(Inventarnummer,Kundennummer) KUNDE(Kundennummer, Adresse-Ausleiher) WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/27

28 Datensicht: Relationales Datenmodell 9/12 Vom Fachkonzept zum DV-Konzept Überführung von ER-Diagrammen in Relationsschemata 1. Jeder Objekttyp wird zur Relation 2. Die Attribute eines Objekttypen werden zu den Attributen der Relation AutorenNr. AutorenNr. Name Name Autor Autor Name Name Kunde KundenNr KundenNr Adresse Adresse verfasst verfasst Kunde Kunde entleiht entleiht Buch Buch Datum Datum InventarNr InventarNr Titel Titel 3. Mehrwertige Attribute werden eigene Relationen Autor Verfasst Buch WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/28

29 Datensicht: Relationales Datenmodell 10/12 Überführung von ER-Diagrammen in Relationsschemata 1:1-Beziehungen: Primärschlüssel der Objekttypen werden als Fremdschlüssel in den beteiligten Objekttypen aufgenommen PC(Seriennummer,, Mitarbeiternummer) MITARBEITER(Mitarbeiternummer,, PC-Seriennummer) 1:n-Beziehungen: Primärschlüssel der Objekttypen werden als Fremdschlüssel in den beteiligten Objekttypen aufgenommen Abteilung 1 n beschäftigt Mitarbeiter ABTEILUNG(Abteilungsnummer, ) MITARBEITER(Mitarbeiternummer,, Abteilungsnummer) m:n-beziehungen: Der Beziehungstyp wird zwingend in eine eigene Relation überführt WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/29

30 Datensicht: Relationales Datenmodell 11/12 Beispiel: ER-Diagramm als Ausgangspunkt KundenNr KundenNr Name Name Kunde Kunde AutorenNr. AutorenNr. Name Name Adresse Adresse entleiht Datum Datum InventarNr InventarNr Autor Autor verfasst Buch Buch Titel Titel WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/30

31 Datensicht: Relationales Datenmodell 12/12 Beispiel: Abgeleitetes relationales Schema KUNDE Kunden-Nr. Name Adresse BUCH Inventarnr. Titel Kunden-Nr Entleih-Datum AUTOR Autoren-Nr. Name VERFASST Autoren-Nr. Inventarnr. Alternativ: eigene Tabelle für ENTLEIHT, BUCH mit 2 Attributen weniger ENTLEIHT Kunden-Nr. Inventarnr. Datum WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/31

32 Datenbanksprachen 1/2 Erstellung, Veränderung und Abfrage von Datenbanken Dominierend bei relationalen DB: Structured Query Language (SQL) Deskriptiv Es genügt anzugeben, was das Problem ist (und nicht - wie bei prozeduralen Sprachen - wie es im einzelnen gelöst werden soll) Abfrageoperationen Selektion Projektion Verbund WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/32

33 Datenbanksprachen 2/2 Beispiel einer SQL-Abfrage: Selektion SELECT * FROM Kunde WHERE PLZ = 1010 KUNDE Kunden- Nr. Name PLZ 1 Hansen Torberg Neumann Schnitzler KundenNr 1 3 Name Hansen Neumann PLZ WI Planung, Entwicklung und Betrieb von IS IS-Modellierung Kap. 02, Teil 03/33