Folien zum Textbuch - behaim.he.lo-net2.debehaim.he.lo-net2.de/fs/wi_kapitel_02_teil_03.pdf · •...

WI à Planung, Entwicklung und Betrieb von IS à IS-Modellierung Kap. 02, Teil 03/1

Folien zum Textbuch

• Kapitel 2: Planung, Entwicklung und Betrieb von IS

• Teil 3:Modellierung von betrieblichen Informationssystemen

• Textbuch-Seiten 185 - 208


Datensicht von Informationssystemen

StrategischeIS-Planung

IS-Architektur-planung

IS-Entwicklung

IS-Betrieb

ARISOrganisationssicht

…

DatensichtFunktionssichtSteuerungssicht

Wo befinden wir uns?


Fachkonzept

DV-Konzept

Implementierung

Organisations-sicht

Drei Beschrei-bungsebenen:- Fachkonzept- DV-Konzept- Implementierung

Architektur integrierter Informations-Systeme (ARIS) von A.-W. Scheer

Fachkonzept

DV-Konzept

Implemen-tierung

Fachkonzept

DV-Konzept

Implemen-tierung

Fachkonzept

DV-Konzept

Implemen-tierung

Leistungssicht

Datensicht Steuerungssicht Funktionssicht


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


Datensicht: Konzeptionelles Datenmodell

• Vereinfachte Beschreibung eines betrieblichen Realitätsausschnitts

• Definition der relevanten Objekttypen mit ihren sachlogischen und strukturellenZusammenhängen

• Beschreibung meist durch eine grafisch orientierte, formale Modellierungssprache (bspw. das Entitiy-Relationship- oder ER-Modell)


Datensicht: ER-Modelle 1/8ER-Diagramm mit Objekt- und Beziehungstypen

AutorAutor verfasstverfasst

KundeKunde

BuchBuch

entleihtentleiht

Objekttypen

Beziehungstypen Objekte

Beziehungen


Datensicht: ER-Modelle 2/8Grundlegende 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)

<Beziehungstyp>

<Objekttyp>


Datensicht: ER-Modelle 3/8Weiterfü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>


Datensicht: ER-Modelle 4/8Beispiel eines um Attribute erweiterten ER-Diagramms

Kunden-Nr.Kunden-Nr.

NameName

AdresseAdresse

Inventar-nr.

Inventar-nr.

TitelTitel

DatumDatum

Autoren-Nr.Autoren-Nr. NameName


KundeKunde

BuchBuch

entleihtentleiht


Datensicht: ER-Modelle 5/8Spezifizierung 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


Datensicht: ER-Modelle 6/8Beispiele für Kardinalitätsverhältnisse

• 1:1-Beziehung

– Ein Mitarbeiter verwendet maximal einen PC, ein PC wird von maximal einem Mitarbeiter verwendet

• 1:n-Beziehung

– Eine Abteilung kann mehrere (n) Mitarbeiter beschäftigen, ein Mitarbeiter ist in maximal einer Abteilung beschäftigt

verwendetMitarbeiter PC1 1

beschäftigtAbteilung Mitarbeiter1 n


Datensicht: ER-Modelle 7/8Beispiele für Kardinalitätsverhältnisse

• m:n-Beziehung

– Ein Mitarbeiter kann in mehreren Projekten beteiligt sein, an einem Projekt können mehrere Mitarbeiter arbeiten

ist beteiligtMitarbeiter Projektm n


Datensicht: ER-Modelle 8/8Ein Beispiel einer Partizipation

• 1:n-Beziehung mit vollständiger Partizipation

– 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)



Datensicht: Datenbanksysteme 1/6

• Die Realisierung der Datensicht auf Ebene des DV-Konzeptserfolgt 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


Datenbank

Finanz- undRechnungs-

wesen

Finanz- undRechnungs-

wesen

Personal-wirtschaft

Personal-wirtschaft ProduktionProduktion

Vertrieb,Marketing

Vertrieb,Marketing

Forschungund

Entwicklung

Forschungund

Entwicklung

Material-wirtschaft

Material-wirtschaft

Datensicht: Datenbanksysteme 2/6Beispielhafte Verwendung einer zentralen Datenbank


Datensicht: Datenbanksysteme 3/6Architektur von Datenbanksystemen

Die Architektur von Datenbanksystemen aus der Sicht des ANSI-SPARC-Dreischichtenmodells


Datensicht: Datenbanksysteme 4/6Ziele 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


• 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.)

Datensicht: Datenbanksysteme 5/6Externe Schemata


• 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!

Datensicht: Datenbanksysteme 2/6Internes Schema


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 Tupelgenannt.

• Eindeutig identifizierende Attribute/ Attributmengen werden als Primärschlüssel bezeichnet


Datensicht: Relationales Datenmodell 2/12Relationsschema als ER-Modell

[Relation] Kunde(KundenNr,Name,PLZ)

Kunden-NrKunden-Nr

NameName

PLZPLZ

KundeKunde


[Relation] Kunde(KundenNr,Name,PLZ)

Primärschlüssel

Tabellenname

Tupel

Kunden-Nr. Name PLZ

1

2

3

4

.

.

Hansen

Torberg

Neumann

Schnitzler

.

.

1010

8670

1010

8020

.

.

KUNDE

Attribute

Datensicht: Relationales Datenmodell 3/12Relationsschema in Tabellenform


Datensicht: Relationales Datenmodell 4/12Regelwerk 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


Datensicht: Relationales Datenmodell 5/12Funktionale 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.


Datensicht: Relationales Datenmodell 6/12Inklusionsabhä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:AUTOR(Autoren-Nr, Name)

VERFASST(Autoren-Nr, Buch-Nr)

• Interpretation:– Autoren-NrVERFASST inkludiert in Autoren-NrAUTOR

– Autoren-NrVERFASST 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.


Datensicht: Relationales Datenmodell 7/12Normalisierung 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


Datensicht: Relationales Datenmodell 8/12Normalisierung 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)


Datensicht: Relationales Datenmodell 9/12Vom Fachkonzept zum DV-Konzept

1. Jeder Objekttyp wird zur Relation

2. Die Attribute eines Objekttypen werden zu den Attributen der Relation

3. Mehrwertige Attribute werden eigene Relationen

KundenNrKundenNr

NameName

AdresseAdresse

InventarNrInventarNr

TitelTitel

DatumDatum

AutorenNr.AutorenNr.

NameName


KundeKunde

BuchBuch

entleihtentleiht

Überführung von ER-Diagrammen in Relationsschemata

Autor

Kunde

Buch

Verfasst


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(Abteilungsnummer,…)

– MITARBEITER(Mitarbeiternummer, …, Abteilungsnummer)

• m:n-Beziehungen: Der Beziehungstyp wird zwingend in eine eigene Relation überführt



Datensicht: Relationales Datenmodell 11/12Beispiel: ER-Diagramm als Ausgangspunkt

KundenNrKundenNr

NameName

AdresseAdresse

InventarNrInventarNr

TitelTitel

DatumDatum

AutorenNr.AutorenNr. NameName


KundeKunde

BuchBuch

entleihtentleiht


KUNDE Kunden-Nr. Name Adresse

BUCH Inventarnr. Titel

AUTOR Autoren-Nr. Name

ENTLEIHT Kunden-Nr. Inventarnr. Datum

VERFASST Autoren-Nr. Inventarnr.

Kunden-Nr Entleih-Datum

Alternativ: eigene Tabelle für ENTLEIHT, BUCH mit 2 Attributen weniger

Datensicht: Relationales Datenmodell 12/12Beispiel: Abgeleitetes relationales Schema


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


Datenbanksprachen 2/2 Beispiel einer SQL-Abfrage: Selektion

SELECT * FROM Kunde WHERE PLZ = 1010

Kunden-Nr. Name PLZ

1

2

3

4

.

.

Hansen

Torberg

Neumann

Schnitzler

.

.

1010

8670

1010

8020

.

.

KUNDE Kunden-Nr. Name PLZ

1

2

3

4

.

.

Hansen

Torberg

Neumann

Schnitzler

.

.

1010

8670

1010

8020

.

.

KUNDE

1010Neumann3

1010Hansen1

PLZNameKundenNr

Folien zum Textbuch - behaim.he.lo-net2.debehaim.he.lo-net2.de/fs/wi_kapitel_02_teil_03.pdf · •...

Documents

Transcript of Folien zum Textbuch - behaim.he.lo-net2.debehaim.he.lo-net2.de/fs/wi_kapitel_02_teil_03.pdf · •...