Auffrischung DB I - techfak.uni-bielefeld.de file1/48 Auffrischung DB I 2 | Inhalt 2.1 Motivation...

1/48

Auffrischung DB I

2 | Inhalt

2.1 Motivation

Begriffe, Vorteile von DBMS, Historie

2.2 Prinzip und Anforderungen

Aufbau eines Datenbanksystems, neun Codd‘sche Regeln

Konzept relationaler Datenbanksysteme

Datenbankgrößen, Einsatzgebiete, Grenzen

2.3 Architektur von Datenbanken

Schemaarchitektur, Systemarchitektur

2.4 Datenbankmodelle

Grundlagen

ER-Modell, OO Modell

2.5 Entwurf von Datenbanken

Anforderungen, Phasenmodell, ER-Abbildung

2.6 Zusammenfassung, Literatur

Quelle: Foliensatz zu Heuer, Saake: Datenbanken

2/48

Ausgangspunkt

2.1 | Motivation

Großteil der biomedizinischen Informationen nicht elektronisch erfaßt

Nur teilweise in verarbeitbarer Form verfügbar Unterschiedliche Systeme, Formate, Semantik Ansonsten in wiss. Veröffentlichungen oder Expertenwissen

Beispielsweise Speicherung von Einfachen experimentellen Ergebnissen, Beobachtungen,

Zusammenhängen Krankheitsbilder, Stoffwechselwege, ...

Probleme Für neue oder komplexere Informationen fehlen häufig Modelle und

geeignete Datenstrukturen Automatische Extraktion von Informationen z.B. durch Text Mining

fehleranfällig

⇒ Speicherung, Wiedergewinnung, Verknüpfung, Aufbereitung, Integration bereits vorhandener Daten oder Datenbankinhalte

3/48

Informationssysteme

2.1 | Motivation

Klassisch:

System zur Speicherung, Wiedergewinnung, Verknüpfung und

Auswertung von Informationen

Datenbanksystem und Anwendungsprogramme

Erweiterte Sicht:

Persistente (dauerhafte) Speicherung von Informationen

Wiedergewinnung der gespeicherten Informationen nach beliebigen

Anfragekriterien

Anwendungsspezifische Auswertung und Aufbereitung der

gespeicherten Informationen

Korrekte (integritätsbewahrende) Aktualisierung der gehaltenen

Informationen

Integration weiterer Informationsquellen

Modellierung von Benutzerschnittstellen und Benutzerführung

Verteilungsaspekte und Aspekte autonomer Systeme

4/48

Informationssysteme /2

2.1 | Motivation

Datenbanksystem

Speicherung und Wiedergewinnung von Informationen

Spezifische Datenbank-Anwendungsprogramme

Anwendungsspezifische Auswertung und Aufbereitung

Korrekte Aktualisierung der gehaltenen Informationen

Weitere Funktionalitäten

Integration weiterer Quellen

Modellierung von Benutzerschnittstellen und Benutzerführung

Zugriff über Netze

Sensoren

Kooperierender Zugriff auf andere informationsverarbeitende

Systeme

Verteilungsaspekte und autonome Aspekte

5/48

Motivation

2.1 | Motivation

Datenbanksysteme als Basis moderner Softwaresysteme

Web-basierte Systeme (eBay, Amazon)

ERP-Systeme (SAP R/3), CRM-Systeme, Finanzsysteme

Administrative Anwendungen

Wissenschaftliche Anwendungen (Sloan Sky Survey, NASA Earth

Observation System, Human Genome Project)

Querbezüge zu anderen Bereichen der Informatik

Modellierung, Datenstrukturen, Theorie, Verteilte Systeme,

Betriebssysteme, Sicherheit, Multimedia

6/48

Motivation /2

2.1 | Motivation

Große Herausforderungen

Verwaltung von Daten im TB-Bereich, viele Nutzer

Weltweit verteilte Datenbestände

Multimedia-Inhalte

Hochverfügbarkeit, Sicherheit

DB-Kenntnisse unverzichtbar für Informatik-Berufe

Administration

Planung, Entwurf

Entwicklung

Nutzung

7/48

Ohne DB: Datenredundanz

2.1 | Motivation

Basis- oder Anwendungssoftware verwaltet ihre eigenen Daten in

eigenen (Datei-)Formaten

Textverarbeitung: Texte, Artikel und Adressen

Buchhaltung: Artikel, Adressen

Lagerverwaltung: Artikel, Aufträge, Nachbestellungen

Auftragsverwaltung: Aufträge, Artikel, Adressen

CAD-System: Komponenten, technische Bauelemente

Daten sind redundant (mehrfach gespeichert) !

⇒ Probleme:

Verschwendung von Speicherplatz

„Vergessen“ von Änderungen, Widersprüche

Keine zentrale, „genormte“ Datenhaltung

8/48

Ohne DB: Datenredundanz /2

2.1 | Motivation

Andere Software-Systeme können große Mengen von Daten nicht

effizient verarbeiten

Mehrere Nutzer oder Anwendungen können nicht parallel auf den

gleichen Daten arbeiten, ohne sich zu stören

Anwendungsprogrammierer/Benutzer können Anwendungen nicht

programmieren/nutzen, ohne

Interne Darstellung der Daten

Speichermedien oder Rechner

zu kennen (fehlende Datenunabhängigkeit)

Datenschutz und Datensicherheit sind nicht gewährleistet

9/48

Mit DB: Datenintegration

2.1 | Motivation

Die gesamte Basis- und Anwendungssoftware arbeitet auf

denselben

Daten, z.B. werden Adressen und Artikel nur einmal gespeichert

Datenbanksysteme können große Datenmengen effizient verwalten

(Anfragesprachen, Optimierung, interne Ebene)

Benutzer können parallel auf Datenbanken arbeiten

(Transaktionskonzept)

Datenunabhängigkeit durch 3-Ebenen-Konzept

Datenschutz (kein unbefugter Zugriff) und Datensicherheit (kein

ungewollter Datenverlust) werden vom System gewährleistet

10/48

Vorteile/Nachteile

2.1 | Motivation

Vorteile des Datenbankeinsatzes

Nutzung von Standards

Kürzere Entwicklungszeiten

Hohe Flexibilität

Hohe Verfügbarkeit

Große Wirtschaftlichkeit

Mögliche Nachteile des Datenbankeinsatzes

Hohe Anfangsinvestitionen für Hardware, Software, Schulung

Universalität eines DBMS für die Definition und Verarbeitung von Daten

Mehrkosten für die Bereitstellung von Sicherheit,

Nebenläufigkeitskontrolle, Wiederherstellung und Integrität

11/48

Historie

2.1 | Motivation

Anfang 60er Jahre

elementare Dateien,

anwendungsspezifische Datenorganisation

(geräteabhängig, redundant, inkonsistent)

Ende 60er Jahre

Datenverwaltungssysteme (SAM, ISAM)

mit Dienstprogrammen (Sortieren)

(geräteunabhängig, aber weiter redundant

und inkonsistent)

70er Jahre

Datenbanksysteme

(geräteunabhängig, datenunabhängig, redundanzfrei, konsistent)

Datei 1

Anwendung 1 Anwendung n

Datei m

...

...

Datei 1

Anwendung 1 Anwendung n

Datei m

...

...

Dateiverwaltung

12/48

Inhalt

2 | Inhalt

2.1 Motivation









Grundlagen





13/48

Prinzip

2.2 | Prinzip und Anforderungen

DB Datenbank

DBMS Datenbankmanagementsystem

DBS Datenbanksystem = (DBMS + DB)

Anwendung n

DBMS

Datenbank

Anwendung 1 ...

14/48

Prinzip /2


Grundmerkmale

Verwaltung persistenter (langfristig zu haltender) Daten

Effiziente Verwaltung großer Datenmengen

Definition eines Datenbankmodell, mit dessen Konzepten alle Daten

einheitlich beschrieben werden (Integration)

Operationen und Sprachen (DDL, DML)

Transaktionskonzept mit Mehrbenutzerkontrolle

Datenschutz, Datenintegrität, Datensicherheit

3-Ebenen-Architektur (physische und logische Datenunabhängigkeit)

Trennung zwischen Schema (z.B. Tabelleninhalt) und Instanz (z.B.

Tabelleninhalt)

15/48

Neun Codd‘sche Regeln


1. Integration: einheitliche, nichtredundante Datenhaltung

2. Operationen: Speichern, Suchen, Ändern

3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary

4. Benutzersichten

5. Integritätssicherung: Korrektheit des Datenbankinhaltes

6. Datenschutz: Ausschluß unauthorisierter Zugriffe

7. Transaktionen: mehrere DB-Operationen als Funktionseinheit

8. Synchronisation: Koordination paralleler Transaktionen

9. Datensicherung: Wiederherstellung von Daten nach Systemfehlern

16/48

Konzeptuell: Relationenmodell


Konzeptuell ist eine Datenbank eine Menge von Tabellen

INVNR

0007

1201

4711

4712

TITEL

Dr. No

Datenbanken

Datenbanken

Pascal

AUTOR

James Bond

Vossen

Ullman

Wirth

BUCH

INVNR

4711

1201

4712

NAME

Meier

Meier

Schulze

AUSLEIHE

17/48

Konzeptuell: Relationenmodell /2


Fett geschriebene Zeilen: Relationenschema

Weitere Einträge in der Tabelle: Relation

Eine Zeile der Tabelle: Tupel

Eine Spaltenüberschrift: Attribut

A1R ... An

Relationenname Attribute

Relationenschema

Tupel Relation

18/48

Anfrageoperationen


Selektion: Zeilen (Tupel) auswählen

SEL [NAME=‚Meier‘] (AUSLEIHE)

Projektion: Spalten (Attribute) auswählen

PROJ [INVNR, TITEL] (BUCH)

INVNR

0007

1201

4711

4712

TITEL

Dr. No

Datenbanken

Datenbanken

Pascal

AUTOR

James Bond

Vossen

Ullman

Wirth

BUCH

INVNR

4711

1201

4712

NAME

Meier

Meier

Schulze

AUSLEIHE

19/48

Anfrageoperationen /2


Verbund (Join): Verknüpfung von Tabellen über gleichbenannte Spalten

und gleiche Werte

PROJ [INVNR, TITEL] (BUCH)

JOIN

SEL [NAME=‚Meier‘] (AUSLEIHE)

Weitere Operationen: Vereinigung, Differenz, Durchschnitt,

Umbenennung

Alle Operationen beliebig kombinierbar (Algebra)

INVNR

1201

4711

TITEL

Datenbanken

Datenbanken

NAME

Meier

Meier

20/48

Einsatzgebiete und Grenzen


Klassische Einsatzgebiete

Viele Objekte (15000 Bücher, 300 Benutzer, ...)

Wenige Objekttypen (BUCH, AUSLEIHE, BENUTZER)

z.B. Buchhaltung, Auftragserfassung, Bibliothek

Aktuelle Anwendungen

E-Commerce, entscheidungsunterstützende Systeme (Data Warehouse,

OLAP), Data Mining

21/48

Einsatzgebiete und Grenzen /2


Normalerweise sind herkömmliche Datenbanksysteme überfordert mit

CAD oder anderen technischen Anwendungen

(viele Objekte, viele Objekttypen, stark strukturierte Objekte)

⇒ Objektorientierte, objektrelationale Datenbanksysteme

Expertensysteme

(wenige Objekte, viele Objekttypen, komplizierte Operationen)

⇒ Deduktive Datenbanksysteme

22/48

Heutige Entwicklungslinien


Unterstützung spezieller Anwendungen

Multimediadatenbanken

Verwaltung multimedialer Objekte (Bilder, Audio, Video)

XML-Datenbanken

Verwaltung semistrukturierter Daten (XML-Dokumente)

Verteilte Datenbanken

Verteilung von Daten auf verschiedene Rechnerknoten

Föderierte Datenbanken, Multidatenbanken, Mediatoren

Integration von Daten aus heterogenen Quellen (Datenbanken, Dateien,

Web-Quellen)

Mobile Datenbanken

Datenverwaltung auf Kleinstgeräten (PDA, Handy, ...)

23/48

Datenbankgrößen


Deutsches Klimarechenzentrum (2005) 110 TB (max. 220 TB)

Klimadaten, Simulationsergebnisse

Yahoo! (2005) 100 TB

Sloan Digital Sky Survey 40 TB

Himmelsdaten (Bilder und Objektinformationen)

WalMart Data Warehouse (2003) 300 TB

Produktinformationen (Verkäufe, ...) der Märkte

US Library of Congress 10-20 TB

nicht digitalisiert

Indexierbares WWW (1999) 6 TB

ca. 800 Mill. Dokumente

Microsofts TerraServer 3,5 TB

unkomprimierte Bilder/Karten (174 Mill. Tupel)

Deutsche Telekom SAP R/3 (1998)

15 SAP-Systeme verarbeiten jeweils 200.000 Rechnungen, 1000 Nutzer

parallel

über 13.000 Tabellen

24/48

Inhalt

2 | Inhalt

2.1 Motivation









Grundlagen





25/48

Architekturen von DB

2.3 | Architektur von DB

Betrachtung von DB-Architekturen aus verschiedenen Blickwinkeln:

Schema-Architektur

Zusammenhang zwischen konzeptuellen, internen und externen

Schema

Einordnung der DB-Anwendungsprogramme

System-Architektur

Aufbau des DBS aus Komponenten, Bausteinen oder Werkzeugen

Normierung von Schnittstellen

Anwendungsarchitektur

Ablauf der Anwendungsentwicklung

Beschreibung von Vorgängen und Arbeitsschritten

26/48

Schema-Architektur


Zusammenhang zwischen

Konzeptuellem Schema (Ergebnis der Datendefinition,

implementierungsunabhängige Modellierung der gesamten DB)

Internem Schema (Festlegung von Dateiorganisation und Zugriffpfaden)

Externem Schema (Ergebnis der Sichtdefinition)

Anwendungsprogrammen (Ergebnis der Anwendungsprogrammierung)

Trennung Schema – Instanz

Schema: Metadaten, Datenbeschreibungen

Instanz: Anwenderdaten, Datenbankzustand oder –ausprägung

Unterstützung der Datenunabhängigkeit

27/48

Schema-Architektur /2


Externes Schema n

Konzeptuelles Schema

Externes Schema 1 ...

Internes Schema

Anfra

gebearb

eitu

ng

Date

ndarste

llung

28/48

Datenunabhängigkeit


= Stabilität der Benutzerschnittstelle gegen Änderungen

Physische Datenunabhängigkeit (Implementierungs-)

Änderungen der Dateiorganisation und Zugriffpfade haben keinen

Einfluß auf das konzeptuelle Schema

Logische Datenunabhängigkeit (Anwendungs-)

Änderungen am konzeptuellen und gewissen externen Schemata haben

keine Auswirkungen auf andere externe Schemata und

Anwendungsprogramme

Mögliche Auswirkungen von Änderungen am konzeptuellen Schema

Eventuell externe Schemata betroffen (Ändern von Attributen)

Eventuell Anwendungsprogramme betroffen (Rekompilieren der

Anwendungsprogramme, eventuell Änderungen nötig)

29/48

System-Architekturen


Beschreibung der Komponenten eines DBS

Standardisierung der Schnittstellen zwischen Komponenten

Architekturvorschläge

ANSI-SPARC-Architektur aus dem Jahre 1978

(detaillierte Version der Drei-Ebenen-Schema-Architektur)

Fünf-Schichten-Architektur

(detaillierte Version der Transformationskomponente der Drei-Ebenen-

Schema-Architektur)

30/48

Definitionskomponenten

Transformationskomponenten

Programmierkomponenten

Benutzerkomponenten

Data Dictionary

ANSI-SPARC-Architektur


ANSI: American National Standards Institute

SPARC : Standards Planning and Requirement Committee

Externe Ebene Konzeptuelle Ebene Interne Ebene

UpdatesOptimierer Auswertung Plattenzugriff

DB-Operationen

Einbettung

MaskenSichtdefinition Datendefinition Dateiorganisation

P1

Pn

Anfragen

...

31/48

Fünf-Schichten-Architektur


Datensystem

MengenorientierteSchnittstelle

Übersetzung, Zugriffpfadauswahl,Zugriffskontrolle, Integritätskontrolle

Relationen, Sichten

Zugriffssystem

SatzorientierteSchnittstelle

Data Dictionary, Currency Pointer, Sortierung, Transaktionsverwaltung

Externe Sätze, Index-Strukturen

Speichersystem

InterneSatzschnittstelle

Record Manager, ZugriffpfadverwaltungSperrverwaltung, Log/Recovery

Interne Sätze, Bäume, Hashtab.

Pufferverwaltung

Systempuffer-Schnittstelle

Systempufferverwaltung mitSeitenwechselstrategie

Segmente, Seiten

Betriebssystem

Datei-Schnittstelle

Externspeicherverwaltung

Dateien, Blöcke

Geräte-Schnittstelle

Zylinder,Spuren

32/48

Inhalt

2 | Inhalt

2.1 Motivation









Grundlagen





33/48

Datenbankmodell

2.4 | Datenbankmodelle

= System von Konzepten zur Beschreibung von Datenbanken. Es legt

Syntax und

Semantik von Datenbankbeschreibungen (Schemata) für ein

Datenbanksystem fest.

4. Statische Eigenschaften wie

Objekte

Beziehungen

inklusive der Standard-Datentypen

5. Dynamische Eigenschaften wie

Operationen

Beziehungen zwischen Operationen

6. Integritätsbedingungen an

Objekte

Operationen

34/48

Überblick


Klassische Modelle

Hierarchisches Modell

Netzwerkmodell

Relationenmodell

Entity-Relationship-Modell

⇒ Darstellung großer Informationsmengen mit relativ starrer Struktur

⇒ Darstellung statischer Eigenschaften und Integritätsbedingungen

Neuere Modelle

Deduktives Modell

Semantisches Modell

Objektorientiertes Modell

35/48

Entity-Relationship-Modelle


P. P. Chen im Jahre 1976

Entity: Objekt der realen oder der Vorstellungswelt, über das

Informationen zu speichern sind z.B. Vorlesungsveranstaltung, Buch,

Lehrperson, . . .

Auch Informationen über Ereignisse: Prüfungen, . . .

Relationship: Beziehung zwischen Entities, z.B. eine Lehrperson hält eine

Vorlesung

Attribut: Eigenschaft von Entities oder Beziehungen, z.B. die ISBN eines

Buchs, der Titel einer Vorlesung, oder das Semester, in dem eine

Vorlesung gehalten wird

36/48

Beispiel


Patient Diagnose

Therapie

Name

Geburtsdatum

Krankenkasse

Name

Krankheitsbild

Name

Beschreibung

Dauer

hat

hilft

gesichert

37/48

Einige Modellierungskonzepte


Attribute eines Entity-TypenEA : D

RA : D Beziehungsattribute

E1 E2R

Funktionale BeziehungenJedem Entity vom Typ E1 wird max. ein Entity vom

TypE2 zugeordnet (z.B. Patient „liegt in“ Zimmer)

A : D Schlüssel zur eindeutigen Identifizierung eines

Entities

E1 E2IST

IST-BeziehungSpezialisierungs-/Generalisierungsbeziehung (z.B.

Prüfer „ist“ Mitarbeiter

E1 E2R

KardinalitätenEinschränkung der möglichen Teilnahme von

Entitäten an Beziehungen durch minimalen und maximalen Wert

[0,1] [0,*]

38/48

Erweitertes ER-Modell


Strukturierte Attribute: zusammengesetzte Attributwerte

Abgeleitete Attribute: durch eine Berechnungsvorschrift berechnete

Attributwerte

Spezialisierung: Verfeinerung eines Entity-Typen zu einem

spezielleren Entity-Typ

Generalisierung: Zusammenfassung von Entity-Typen zu einem

allgemeineren Entity-Typ

Partitionierung: mehrere disjunkte Spezialisierungen eines Entity-

Typen

Aggregierung: Zusammensetzung von Entities aus anderen Entities

Objektwertige Attribute: Attribute, die Entity-Typen als Wertebereich

haben

39/48

Objektorientiertes Modell: UML


Seit Beginn der 90er Jahre: Ansätze zur objektorientierten Analyse und zum

objektorientierten Entwurf

Ab Mitte der 90er Jahre: Vereinheitlichung zur Unified Modeling Language

(UML) (Booch, Jacobson, Rumbaugh)

Objektmodell: Anreicherung von EER-Modellen um objektorientierte

Konzepte (Klassen, Beziehungen, Operationen, ...)

Dynamikmodell: Beschreibung des dynamischen Verhaltens eines

Objektes in Form von Übergangsautomaten (Übergänge entsprechen

Systemereignissen)

Funktionenmodell: Datenflußdiagramme zur Darstellung globaler

Berechnungsabläufe

Anwendungsfälle

Implementierungsdiagramme

...

40/48

Objektmodell von UML


Erweiterung des EER-Modells

Unterscheidung in

Klassendiagramm: entspricht Datenbankschema-Notation,

beschreibt Typen von Kollektionen von Instanzen

Objektdiagramm: beschreibt Einzelobjekte

Beschreibung von strukturellen Aspekten (Attribute, Beziehungen) und

Operationen

Formulierung von Integritätsbedingungen und Ableitungsregeln

(textuell, Object Constraint Language)

41/48

Inhalt

2 | Inhalt

2.1 Motivation









Grundlagen





42/48

Entwurfsaufgabe

2.5 | Entwurf von Datenbanken

Anforderungen an den Entwurfsprozeß

Informationserhalt

Konsistenzerhaltung

Redundanzfreiheit

Vollständigkeit bezüglich Anforderungsanalyse

Konsistenz des Beschreibungsdokuments

Ausdrucksstärke, Verständlichkeit des benutzten Formalismus

Formale Semantik der Beschreibungskonstrukte

Lesbarkeit der Dokumente

Weitere Qualitätseigenschaften: Erweiterbarkeit, Modularisierung,

Wiederverwendbarkeit, Werkzeugunterstützung etc.

43/48

Phasenmodell


Anforderungsanalyse

Konzeptioneller Entwurf

Verteilungsentwurf

Logischer Entwurf

Datendefinition

Physischer Entwurf

Implementierung & Wartung

Informale Beschreibung des Informationsbedarfes der Fachabteilungen

Formale Beschreibung des Fachproblems, z.B. ER-Modell

Art und Weise der verteilten Speicherung

Transformation in Datenmodell des DBMS

Festlegung eines konkretes Schemas (z.B. mit SQL-

DDL)

Ergänzung um Zugriffsunterstützung zur Effizienzverbesserung (z.B.

Indexe)

Installation, Optimierung, Anpassung, Portierung, Wartung

44/48

Phasenbegleitende Methoden


Validationsmethoden

Verifikation: formaler Beweis etwa von Schemaeigenschaften

Prototyping: beispielhaftes Arbeiten mit der Datenbank vor der

endgültigen Implementierung

Validation mit Testdaten: Überprüfung der Richtigkeit des Entwurfs

anhand von realen oder künstlichen Testdaten

45/48

ER-Abbildung


Erster Teilschritt des logischen Datenbankentwurfs

Abbildung von ER-Modell auf Relationenmodell

Vorgehensweisen:

Transformation nach Faustregeln manuell

automatische Transformation

Ziel: kapazitätserhaltende Abbildung

Entity-Typen und Beziehungstypen ⇒ Relationenschemata

Attribute ⇒ Attribute des Relationenschemas

Schlüssel werden übernommen

Kardinalitäten der Beziehungen ⇒ Wahl der Schlüssel

Relationenschemata von Entity- und Beziehungstypen können eventuell

miteinander verschmolzen werden

Einführung diverser Fremdschlüsselbedingungen

46/48

ER-Abbildung /2


E1, E2: an Beziehung beteiligte Entity-Typen,

P1, P2: deren Primärschlüssel,

1:n-Beziehung: E2 ist n-Seite

Ist-Beziehung: E1 ist speziellerer Entity-Typ

R1 erhält zusätzlichen Schlüssel P2Ist-Beziehung

RelationenschemaAttribute: P1, P2

weitere AttributeP2 wird Primärschlüssel der Beziehung

P1 und P2 werden Schlüssel der Beziehung

P1∪P2 wird Primärschlüssel der Beziehung

Beziehungstyp

dessen Attribute1:n1:1m:n

Relationenschema Ri

Attribute von Ri

Primärschlüssel Pi

Entity-Typ Ei

Attribute von Ei

Primärschlüssel Pi

Wird abgebildet auf relationales KonzeptER-Konzept

47/48

Inhalt

2 | Inhalt

2.1 Motivation









Grundlagen




2.6 Zusammenfassung

48/48

Zusammenfassung

2.6 | Zusammenfassung

Ausgangspunkt: verfügbare Daten, Begriffsklärung IS/DBS

Motivation für Datenbanksysteme, Datenredundanz vs. Datenintegration

Historie, Vor- und Nachteile,

Prinzip von DBS, Codd‘sche Regeln, Relationenmodell,

Anfrageoperationen

Einsatzgebiete, Grenzen, Größen

Schema-Architektur, Datenunabhängigkeit

System-Architektur

Grundlagen von DB-Modellen

ER-Modell, Modellierungskonzepte, UML

Entwurfsaufgaben

Phasenmodell, ER-Abbildung

Auffrischung DB I - techfak.uni-bielefeld.de file1/48 Auffrischung DB I 2 | Inhalt 2.1 Motivation...

Documents

Transcript of Auffrischung DB I - techfak.uni-bielefeld.de file1/48 Auffrischung DB I 2 | Inhalt 2.1 Motivation...