2 Einführung Datenbanken und die relationale Datenmodellierung PDF

Title 2 Einführung Datenbanken und die relationale Datenmodellierung
Course Empirische Forschungsmethoden I-2
Institution Ludwig-Maximilians-Universität München
Pages 8
File Size 614.8 KB
File Type PDF
Total Downloads 28
Total Views 171

Summary

Basics zu Datenbanken, speziell einführung in die relationale Datenmodellierung...


Description

2 Einführung in Datenbanken und in die relationale Datenmodellierung

21.04.21

Dateien vs. Datenbanken Privat: Speicherung von Daten in Dateien, Zusammenfassung in Ordnern Betrieblich: Datenbanken Zentrale Ablage von Daten mit Sicherung gegen Ausfälle (Vermeidung überflüssiger Speicherung, Bei Dokumenten: Übersicht durch Versionsverwaltung) Zugriff aus verschiedenen Anwendungen und für versch. Zwecke (Vermeidung Anwendungsspezifischer Datenformate, Datenbankschnittstelle z.B. ODBC) Konsistente Verwaltung von Informationen aus vers. Quellen & mit vers. Aktualisierungen (z.B. Bei Büchern ISBN-Nummer) Zugriff mit versch. Berechtigungen/ Zielsetzungen (lesend: z.B. für externe Anfragen; schreibend: z.B. bei der Bereitstellung von Informationen; teilweise sichtbar/ änderbar: z.B. persönliche Daten) Datenbanken Trennung der physischen, logische und nutzerorientierten Schichten Physische Schicht Konzeptuelle/ Logische Schicht Externe Ebene

Tatsächliche Speicherung Gesamtschema der Datenstruktur (Wie sind die Daten beschaffen z.B. Querbezug) (Außensichten für Anfragen / Änderungen)

Datenbanksysteme (DBS): Beschreibung, dauerhaften Speicherung (Persistenz) & effizienten Wiedergewinnung großer Datenmengen, die von vers. Anwendungen benutzt werden - Datenbank (DB): Sammlung aller gespeicherten Daten & den zugehörigen Beschreibungen - Datenbank Management System (DBMS): Programmsystem zur Verwaltung der DB (Fortschreibung des Inhalts, Zugriffschutz, Transaktionsschutz) Datenbankschema/ konkretes Datenmodell: Schematische Beschreibung der Objekte und ihrer Beziehungen einer DB Datenmodell (abstrakt): Ansatz, nach dem ein konkretes Datenmodell erstellt wird Datenmodellierung Anforderungen: ökonomische & effiziente Darstellung großer Mengen (vorwiegend) Strukturierter Daten Strukturierte Für jedes Objekt wird zu einer Alle Attribute haben Null Values für Daten festangelegten Menge von definierten fehlende Werte Attributen der jeweils Wertebereich zutreffende Wert angegeben Unstrukturie Menge der Attribute nicht In konventioneller In best. Bereichen v. -rte Daten festgelegt DB, wird je ein big data wachsende Attribut für den Bedeutung Metadaten als Attribute (z.B. Dateityp festgelegt → insg. Als häufiger Datum eines Fotos etc.) (z.B. jpg-Bild, mp3eingeschätzt als strukturierte Daten Musikstück) → nicht zu Unstrukturierte Daten können in +Attribute für die DB nur grob erfasst werden z.B. Metadaten vernachlässigen: ein ganzes Musikstück Metadaten geben Struktur (soziale Netzwerke)

Semistrukturierte Daten

Menge an Attributen und Wertebereiche festgelegt, Attribute können mehrfach oder gar nicht gefüllt sein

z.B. Ablage strukturierte Literaturnachweise Beschreibungen mit einige Werke haben flexiblen Metadaten mehrere Autoren, kombiniert mit enthalten Onlineunstrukturierten Daten Zugangsdaten oder (z.B. sind anonyme Mediendatenbanken) Manuskripte Ansätze: Datenmodellierung= Anordnung der Attribute für einen Anwendungsbereich in ein Schema In den 1980er Jahren=> Relationaler Ansatz • Basierend auf mathematischen Relationen Kalkül • Geeignet für die Modellierung strukturierter Daten in Unternehmen, Behörden und Forschung Mit Zunahme unstrukturierter Daten & Kontext d. big Data → alternative Ansätze • z.B. Netzwerk-Modell (Graph-basierte Datenbanken): Vorteile => GraphStrukturen sind dynamisch anpassbar & Merkmale können flexibel ergänzt/weggelassen werden Die relationale Datenmodellierung Spalten = Attribute (Eigenschaften) Wertebereich für j. Attribut wird unter d. Gesichtspunkt d. Speicherung durch einen Datentyp festgelegt (z.B. natürliche Zahl, Gleitkommazahl, Datum, Uhrzeit, Zeichenkette) Zeile = Objekt, für das die Ausprägung der Beispiel: Datentabelle Sozialwissenschaft Eigenschaft je Spalte angegeben werden (auch • Jede Zeile = Datensatz Datensatz, Tupel o. Record genannt) (z.B einer Versuchsperson) • Jede Spalte = ein beobachtetes Merkmal (z.B. Antwort auf eine offene Frage, Reaktionszeit, Ausprägung eines diskreten Merkmals) Beschreibung einer relationalen Tabelle: • Tabelle wird durch einen Bezeichner benannt → eindeutige Bezeichner für jeweiligen Tabellen eines Datenbankschemas (vgl. Spaltentitel) • Jedes Attribut je Tabelle wir durch einen Bezeichner benannt → eindeutige Bezeichner für jeweiliges Attribut einer Tabelle Details zu Wertebereichen in der Praxis: • Zusätzliche Festlegungen, um Wertebereich für ein best. DBS zu definieren z.B: ▪ Zeichensatz für einzelne Zeichen/ Zeichenketten (meist Unicode; unterstützt v. Sonderzeichen z.B. asiatische Schriftzeichen, Emoji) ▪ Format einer Datumsangabe oder Zeilenangabe (Deutsches-, Amerikanisches zeitsystem etc.)  Moderne DBMS stellen sog. Lokalisierungen zur Verfügung (ein in der DB gespeichertes Datum je nach Nutzungsanwendung/ -kontext verschieden ausgegeben werden) ▪ Maximal zulässige Länge einer Zeichenkette (in Datendefinition festgelegt)

Aufteilung von Informationen auf verknüpfte Relationen: • Vorteil: Aufteilung zusammenhängender Informationen mit verschiedenen Aspekten auf mehrere Relationen, die miteinander verknüpft werden (z.B. Buchversand) Relation mit den ISBN-Nummer, Verlag, Autor, Erscheinungsjahr, quasi die Grunddaten Bibliographie Relation für das Angebot Umschlagbild, Abstract, Probeseiten, Kommentare einer Web-Side Relation Bestellung & Lieferant & Preisentwicklung Lagerhaltung Relation Marketing & Profile v. Käufern, Wahl alternativer Bücher etc. Kundenbeziehungen Der Primärschlüssel (primary key, PK): = Attribut, dessen Wert über alle Tupel nur 1x vorkommt → Eindeutige Identifizierung jedes Tupel • Einfachster Fall: PK enthält eindeutige Nummerierung der Tabellenzeilen (Datensätze)

Der Fremdschlüssel (Foreign Key, FK) = enthält in einem Attribut einer Tabelle A den Verweis auf den PK einer anderen Tabelle B • Erlaubt Aufteilung separat zu behandelnden Informationen auf mehren Relationen • Nutzung gemeinsamer Attribute deutlich • FK bei der Aufteilung getrennt veränderlicher, aber fachlich verknüpfter Daten auf mehrere Tabellen sinnvoll ▪ Stammdaten [engl. Master Data] (z.B. Studienfach, Matrikel-nummer, Semester) ▪ Bewegungsdaten (z.B. Vorlesungsbesuche, Bestellungen, Lieferungen) • Erweiterung: PK / FK können mehrspaltig sein (z.B. Angabe [Gebäude, Raum] als Vorlesungsort) Informations-Aufteilung auf mehrere Tabellen: Ziel: Informationen unters. Art getrennt verwalten (z.B. naiven lehre Tabelle sind Veranstaltungs- und Personalinformationen vermischt (BWL: Stamm- & Bewegungsdaten) Lösung: getrennte Tabellen für Seminare und Dozenten • Zusammenhang der Informationen wird durch FK gewahrt • FK von Seminaren (Attribut Prof) zu PK Id der Relation Professoren

Nutzen: Vermeidung bestimmter Anomalien (am BSP. Buchtabelle) Insert-Anomalie Autor kann nur eingefügt werden, wenn ein Buch von ihm erhältlich ist (wenn ISBN =PK) Delete-Anomalie Mit Löschung eines Verlages werden alle Bücher gelöscht Update-Anomalie Zur Änderung eines Verlagsnamens müssen alle Publikationen aktualisiert werden

Referentielle Integrität: = Daten einer erfüllen die logischen Beschränkungen in der Datendefinition • Ein relationales DBMS kann bei jeder Änderung in den „verlinkten Tabellen die Fremdschlüsselbeziehung prüfen (z.B. verhindern, dass einer LV ein Dozent mit ungültiger Personal-Nr. zugeordnet wird • Sicherstellung der referentiellen Integrität durch in FK enthaltene logische Bedingungen (constraints) Ansatz der entity relationship Modellierung (ERM) Ziel

Methodik zur Entwicklung eines Technische Expertise => Detaillierung & Datenbankschemas aus der Verbesserung des Entwurfes aus fachlichen Sicht heraus fachlicher Sicht Ansatz Semantische Modellierung Schematisch… (Beziehung zwischen zwei komplexer Daten durch Ganzheiten Entitätstypen) (Entitäten) & ihre Beziehungen (relationships) Grundlagen Oft Herleitung der Elemente einer ERM aus einfachen Formulierungen z.B. Studierende (=Entität) besuchen (=Beziehung) Lehrveranstaltung (=Entität) Jede Entität ≅ In Rel. DB zunächst einer Tabelle Jede Beziehung ≅ Fremdschlüssel oder besonderer Beziehungstabelle (Assoziationstabellen) Entitäten Allgemein: Entitäten beschreiben Bsp. Assoziationstabelle als komplexe Objekte/Geschäftsobjekte GeschäftsEntität Auftrag enthält je nach i.a. durch relationale Tabelle objekte Anwendung modelliert  Tabelle mit Auftragsposition  Aber auch Tabelle mehrere Tabellen können durch Lieferangaben Beziehungen verknüpft sein (z.B.  Evtl. sogar Tabelle Assoziationstabelle Verfügbarkeitsangaben

Beziehungen im ERM • Bestehen zwischen 2 oder mehreren Entitäten • Sind semantische Konzepte (evtl. umfangreiche Datentabellen verborgen) o „Kunde ERTEILT Auftrag“ ▪ Beziehung ERTEILT => z.B. durch Bestellung realisiert ➢ Bestellung verweist auf je eine Entität vom Typ Kunde & evtl. mehrere Entitäten vom Typ Auftrag • Multiplizitäten in Beziehungen Wie viele Objekte können eine bestimmte Beziehung eingehen?

z.B. Auftrag mit mehreren Positionen, aber eine Position kommt nur in einem Aufrag vor Aufträge verhalten sich zur Postition: 1:n Modellierung durch Fremdschlüssel von Position zu Auftrag bei Multiplizität 1:n sinnvoll

Positionstabelle: Warennummer, Mengen, Stückpreis etc.

dieser verallgemeinerter Quotient = Multiplizität Auftragstabelle: Kunde (FK!), Liefertermin o.ä.





Verschiedene Multiplizitäten 1: 1 Beziehung Abteilung : Kostenstelle (in best. Nummernbereich (= Bezugsrahmen)) → jede Abteilung hat genau eine Kostenstelle → jede Kostenstelle im gegeben Nummernbereich gehört genau einer Abteilung Auftrag : Position 1: n Beziehung Gegenrichtung: n:1 Beziehung n: m Beziehung Ware : Supermarkt (many to many) → Supermarkt hat viele versch. Waren → eine Ware gibt es in versch. Superm. Konzeptuelle Modellierung eines Datenbankschemas Rechtecke: Entitäten Pfeile: Beziehungen

n : m Beziehung Kann über verschiedene Beziehungen zu versch. Seminaren gelangen

Darstellung Beziehung Studierende und Seminare Nachteil: Beziehung nur über Studienleistung (Problematisch, wenn jmd. keine Studienleistung erbringt)

Bedeutung einer m : n Beziehung In vielen Bereichen Sinnvoll => Hinweis auf bedeutungsvollen Zusammenhang Dieser wird als selbstständige Entität modelliert Assoziationsklassen • Darstellung von n:m Beziehungen erfordert „Übersichtstabelle“ (= Assoziationstabelle/-klasse) • Vorteil: Attribute können auf Beziehungsebene angelegt werden z.B. Prüfungsergebnis als Attribut des Besuchs von Studierenden im Seminar



Umsetzung durch Assoziationstabelle BELEG-INFO (=Assoziationstabelle): m:n Beziehung „Studierende(r) belegt Vorlesung“ → Darstellung über FK

→ Wer hat was, in welchem Zeitraum belegt

→ Vorteil: Ergänzung d. Assoziationstabelle um spezifische Informationen (z.B. Klausurnote) •

Einarbeitung der Assoziationsklasse in das Konzeptuelle Schema Studienleistung bezieht sich auf eine Person, in einem Seminar

Beziehungen als Entitäten • Attribute auf Beziehungsebene → (m:n) Beziehungen können als Entitäten interpretiert werden (z.B. Beziehung Besuch zwischen Studierenden und Lehrveranstaltung; weitere Attribute wie z.B. Prüfungsbewertung möglich) • Ermöglicht Modellierung komplexer Sachverhalte und Zusammenhänge (Objekt/ Geschäftsobjekt) Typisierung – Das erweiterte ERM • Entitäten sind (aus logischer Sicht) definierte/ komplexe (Daten-)Typen (z.B. Zeichenketten, positive Zahlen sind elementare /atomare Daten-Typen) o Atomare Daten-Typen= nicht weiter zerlegbar → gerade die Wertebereiche für Attribute in relationalen Tabellen (z.B. aus den Attributen 2, 23, & 2021 wird die Entität DATUM erstellt • Einige DBS erlauben Spezialisierungen/Generalisierungen von Typen o z.B. Spezialisierung der Entität DATUM, durch Hinzufügen der Zeitzone o z.B. Geschenkbestellung als Spezialisierung von Bestellung • Spezialisierung von Beziehungen ebenfalls möglich o z.B. Vertrag (Beziehung zw. Kunde und Dienstleistung) – Kaufvertrag, Mietvertrag etc. Planung und Umsetzung von Datenbanken - Structured Query Language (SQL) • Für relationale DB nötige Operationen o Administrativ: Anlegen von DB, Benutzerprofilen etc.

Definieren von Datenmodellen → data definition Language (DDL) (z.B. Erzeugen einer Tabelle mit best. Attributen; SQL: CREATE TABLE statement; Welche Attribute, welche Wertebereiche, welche Regeln/ Zusammenhänge?) o Anfragen und Ändern von Daten → data manipulation language (DML) (z.B. Auswahl bestimmter Datensätze; SQL: SELECT statement SQL als Industriestandart für alle diese Operationen o Anlehnung an natürliche Sprache o Übersichtliche Manipulation beliebig komplexer Tabellen o Oft im Hintergrund von Anwendungen generiert ▪ Admin-Anwendungen: generieren u.a. DDL ▪ Web-Anwendungen: generieren DML (z.B. Buchbestellung etc.) Grundoperatoren der SQL Datenmanipulation Basisoperatoren Selektion Auswahl von Tupel Projektion Auswahl von Attributen Vereinigung Von Tabellen mit gleichen Spalten Differenz Von Tabellen mit gleichen Spalten Kartesisches Produkt Ergibt künstliche Tabellen mit allen Kombinationen der Tupel existierender Tabellen Abgeleitete bes. (Equi-)Join Selektion gleicher Werte gemeinsamer Operatoren: Attribute, dann Projektion auf nicht gemeinsame Attribute Aggregation COUNT; MIN; MAX; Entspricht Formeln in SUM; AVG; … Tabellenkalkulationsprogrammen o



Syntaktische Umsetzung in SQL https://d.docs.live.net/1d0e1cd5b1403d1d/Studium/2019BA%20Pädagogik/SS%2021/EFM%20II2/20210421%202_RelDBuERM.pdf (#44)

JOIN-Operation = Verknüpfung Relationen unter Beachtung einer/ mehrerer Bedingungen

 Zusammenführung der Aufgeteilten Informationen, Generierung neuer Tabellen für best. Fragestellungen z.B.

Änderung von Daten mit SQL Eintragung von INSERT INTO … Daten Variante 1: () VALUES () Variante 2: SET = [, = ]* Modifizierung UPDATE SET = bereits WHERE vorhandener Einträge Löschen

Erzeugt neues Tupel

Ermöglicht „bulk updates“ z.B. ändere alle Verträge aus 2002

DELETE FROM WHERE

• Benutzerrechte und Sicherheit in DBMS o User management Komponente enthalten → Verwalter: DB-Administrator (DBA) → Benutzer: Personen oder Systeme (z.B. Anwendungssysteme von Geschäftspartnern) → Aufgaben von Benutzer können in Rollen zusammengefasst werden o Berechtigungen werden je Nutzer/Rolle differenziert nach Tabellen & Operationen vergeben z.B. → Nur SELECT für Auswertungsanfragen → Nur INSERT für automatische Einträge (Geldautomat => Kontoserver) → Nur UPDATE/ DELETE für Revision einer Personalabteilung...


Similar Free PDFs