Contentmanagement. - uni-leipzig.deasv.informatik.uni-leipzig.de/uploads/document/file_link/219/SQ10CMV... · Institut für Informatik Automatische Sprachverarbeitung topicmapslab.de

Institut für Informatik Automatische Sprachverarbeitung topicmapslab.de

Schlüsselqualifika6on 10

Contentmanagement

Dipl.-‐Inf. Benjamin Bock Topic Maps Lab, Universität Leipzig

[email protected]‐leipzig.de

Einführung in Topic Maps

Institut für Informatik Automatische Sprachverarbeitung topicmapslab.de 2

SQ 10 – Contentmanagement, SS 2009 Benjamin Bock ([email protected]‐leipzig.de)

Einführung in Datenbanken

... und warum wir Dank Ruby on Rails

nicht viel darüber wissen müssen



Ziel des Moduls

•  Grundlagen von Datenbanksystemen vermiWeln •  Verwenden von ER-‐Diagrammen zur Defini6on von DB-‐

Schemas •  Grundkenntnisse zu rela6onalen Datenbanken •  Grundkenntnisse der Anfragesprache SQL •  Möglichkeiten des Zugriffs auf Datenbanken aus

(Web-‐) Anwendungen •  Grundkenntnisse Objekt-‐rela6onales Mapping

3




Mo6va6on

4


Datenbanken

http request

Server

Controller

http response View

Mo-del

Client Ruby on Rails




Grundlagen von Datenbanksystemen




Eigenschaden von Datenbanksystemen

•  Generell: effiziente und flexible Verwaltung großer Mengen persistenter Daten

–  Zentrale Kontrolle über die opera0onalen Daten –  Hoher Grad an Datenunabhängigkeit –  Hohe Leistung und Skalierbarkeit –  Mäch0ge Datenmodelle und Anfragesprachen /

leichte Handhabbarkeit

–  Transak0onskonzept (ACID), Datenkontrolle –  Ständige BetriebsbereitschaJ (hohe Verfügbarkeit und

Fehlertoleranz) •  24-‐Stundenbetrieb •  keine Offline-‐Zeiten für DB-‐Reorganisa6on u. ä.





•  Zentrale Kontrolle über die opera6onalen Daten –  Alle (opera6onalen) Daten können/müssen gemeinsam benutzt

werden •  keine verstreuten privaten Dateien

–  Eliminierung der Redundanz •  Vermeidung von Inkonsistenzen (keine unterschiedlichen Änderungsstände)

–  Datenbankadministrator (DBA) hat zentrale Verantwortung für Daten

–  einfache Entwicklung neuer Anwendungen auf der exis6erenden DB; Erweiterung/Anpassung der DB (Änderung des Informa6onsbedarfs)





•  Hoher Grad an Datenunabhängigkeit (DU)

–  DU = Maß für die Isola6on zwischen Anwendungsprogrammen und Daten

–  Konven6onelle Anwendungsprogramme (AP) mit Dateizugriff •  Nutzung von Kenntnissen der Datenorganisa6on und Zugriffstechnik •  kann gutes Leistungsverhalten ermöglichen, aber ...

–  Datenabhängige Anwendungen sind äußerst unerwünscht •  verschiedene Anwendungen brauchen verschiedene Sichten auf dieselben Daten •  Datenänderung erfordert Änderungen in Anwendungsprogrammen





•  Hohe Leistung und Skalierbarkeit

–  hoher Durchsatz / kurze Antwortzeiten für DB-‐Opera6onen auf großen Datenmengen

–  Leistungsverhalten •  DBS-‐Problem, nicht Anwendungsproblem

•  Zugriffsop6mierung für DB-‐Anfragen durch das DBS (Query-‐Op6mierung)

•  Festlegung von Zugriffspfaden (Indexstrukturen), Datenalloka6on etc. durch den DBA (idealerweise durch das DBS)

–  Hohe Skalierbarkeit •  Anpassung an gewachsene Leistungsanforderungen (wachsende Datenmengen und

Anzahl der Benutzer)

•  Nutzung zusätzlicher/schnellerer Hardware-‐Ressourcen





• Mäch6ge Datenmodelle –  Datenmodell/DBS-‐SchniWstelle

•  Defini6on von Datenstrukturen (Data Defini6on Language, DDL), DB-‐Schemas •  Defini6on von Integritätsbedingungen und Zugriffskontrollbedingungen (Datenschutz) •  Opera6onen zum Aufsuchen und Verändern von Daten (Data Manipula6on Language DML)

–  Datenstrukturierung •  Beschreibung der logischen Aspekte der Daten, neutral gegenüber Anwendungen •  Anwendung erhält logische auf ihren Bedarf ausgerichtete Sicht auf die Daten •  Beschreibung der Objekte durch Satztyp, AWribute und AWributwerte (Si/Aj/AWk)

Bsp.: Satztyp: Ar6kel AWribut 1: Autor AWributwert: T. Böhme AWribut 2: Titel AWributwert: WCMS AWribut 3: Inhalt AWributwert: "WCMS haben sich ..."





• Mäch6ge Anfragesprachen –  formale Sprache –  navigierend oder deskrip6v, abhängig von Datenmodell –  satz-‐ oder mengenorien6ert –  Strukturierung ermöglicht Einschränkung des Suchraumes für Anfragen





•  Transak6onskonzept –  Kontrollstruktur: Transak6onen mit den vier ACID-‐Eigenschaden –  Eine Transak6on besteht aus einer Folge von DB-‐Opera6onen, für die

das DBS folgende Eigenschaden garan6ert •  Atomicity: Alles-‐oder-‐Nichts •  Consistency: Gewährleistung der Integritätsbedingungen •  Isolated Execu6on: „logischer Einbenutzerbetrieb“ •  Durabiliy: Persistenz aller Änderungen

–  Bsp.: Änderung von Inhalt und Änderungsdatum eines Ar6kels

Artikel 1: ÄD1, Txt1

BOT Update Txt

Fehler/ Abbruch Rollback

Update ÄD Commit






Auyau eines Datenbanksystems

Datensystem

Speichersystem

Zugriffssystem

Transaktionsverwaltung:

Logging, Recovery

Synchronisation, Integritätssicherung

Zugriffskontrolle

Metadatenverwaltung

Satzzugriffe

Seitenzugriffe

Log, Archiv- kopien... DB DB Metadaten

DBMS

deskriptive Anfragen (Zugriff auf Satzmengen)




3-‐Ebenen-‐Architektur nach ANSI-‐SPARC

Konzeptionelles Schema logische Gesamtsicht auf die

Struktur der Datenbank Beschreibungssprache: DDL abtrahiert von internem Schema

(physische DU)

Internes Schema: legt physische Struktur der

DB fest (physisches Satzformat, Zugriffspfade,...)

Beschreibungssprache: SSL (Storage Strukture Language)

Externes Schema: definiert spezielle Sicht auf DB-

Struktur (für Anwendungs-programm bzw. Endbenutzer)

abtrahiert von konzeptionellem Schema (ermöglicht partiell logische Datenunabhängigkeit

Artikellist

ArtikelID Titel

ArtikelAutor ArtID Autor

ArtikelHeadlines ArtNum Headline

Artikel ArtikelID : INTEGER Titel : VARCHAR(255) AutorName : CHAR(50) Inhalt : TEXT(1M)

STORED_ARTICLES LENGTH= INTERNAL_ID TYPE=BYTE(4), OFFSET=0 ANUM TYPE=BYTE(4), OFFSET=4, INDEX=ARTID AUTOR TYPE=BYTE(50) ,OFFSET=8,

Externe Schemata

Konzeptionelles Schema

Internes Schema

Artikellist ArtikelID Titel

ArtikelAutor ArtID Autor

ArtikelHeadlines ArtNum Headline

Artikel ArtikelID : INTEGER Titel : VARCHAR(255) AutorName : CHAR(50) Inhalt : TEXT(1M)

STORED_ARTICLES LENGTH= INTERNAL_ID TYPE=BYTE(4), OFFSET=0 ANUM TYPE=BYTE(4), OFFSET=4, INDEX=ARTID AUTOR TYPE=BYTE(50) ,OFFSET=8,




Informa6onsmodellierung (ER-‐Modell)

Viel Theorie...




Informa6ons-‐ und Datenmodellierung (DB-‐Entwurf)

•  Ziele –  modellha)e Abbildung eines anwendungsorien6erten AusschniWs der

realen Welt (Miniwelt) –  Entwurf der logischen und physischen DB-‐Struktur (DB-‐Entwurf) –  Nachbildung von Vorgängen durch Transak6onen

•  Nebenbedingungen –  Vollständigkeit –  Korrektheit –  Minimalität –  Lesbarkeit –  Modifizierbarkeit




En6ty-‐Rela6onship-‐Modell

•  entwickelt von P. P. Chen (1976) •  Konzepte:

–  En6ty-‐Mengen –  Beziehungsmengen (Rela6onship-‐Mengen) –  AWribute –  Wertebereiche –  Primärschlüssel

•  unterstützt folgende Abstrak6onskonzepte –  Klassifika/on (Zusammenfassung gleichar6ger Objekte) –  Aggrega/on (Zusammenfassung poten6ell unterschiedlicher

Teilobjekte / Komponenten zu neuem Objekt) •  graphische Darstellung durch Diagramme •  zahlreiche Erweiterungsvorschläge •  weite Verbreitung über konzep6onellen DB-‐Entwurf

hinaus: Systemanalyse, Unternehmensmodellierung




ER-‐Modellierung – En6ty-‐Mengen

•  En/ty (En6tät, Gegenstand): repräsen6ert abtraktes oder physisches Objekt der realen Welt

•  Gleichar6ge En66es (d. h. En66es mit gemeinsamen Eigenschaden) werden zu En6ty-‐Mengen (Gegenstandstypen, ObjekWypen) zusammengefasst (Klassifika6on) En66es sind Elemente einer (homogenen) Menge: e ∈ E

z. B. Personen, Mitarbeiter, Projekte ... Publika6onen, Ar6kel, Autoren ...

•  DB enthält endlich viele En6ty-‐Mengen: E1, E2, ..., En ; nicht notwendigerweise disjunkt z. B. E1 ... Personen, E2 ... Mitarbeiter: E2 ⊆ E1

•  Symbol für En6ty-‐Menge E: E




ER-‐Modellierung – AWribute

•  AWribute –  Eigenschaden von En6ty-‐Mengen werden durch AWribute bes6mmt –  Eigenschaden einzelner En66es sind durch AWributwerte festgelegt –  Nullwert: spezieller AWributwert, dessen Wert unbekannt oder nicht möglich ist (z. B.

private Tel.Nr.) •  Jedem AWribut ist ein Wertebereich (Domain) zugeordnet, der festlegt,

welche AWributwerte zulässig sind (Integritätsbedingung) •  AWributsymbol in ER-‐Diagrammen:

Attr.Name

Tel.-Nummern Adresse

Ort

PLZ

Straße

zusammengesetztes Attribut mehrwertiges Attribut




ER-‐Modellierung – Primärschlüssel

•  Schlüsselkandidat oder kurz Schlüssel (key) –  einwer6ges AWribut oder AWributkombina6on, die jedes En6ty einer

En6ty-‐Menge eindeu6g iden6fiziert (ggf. künstlich erzwungen) •  Eigenschaden eines Schlüssels

–  keine Nullwerte –  minimal (Teilmenge der AWribute eines Schlüssels nicht selbst Schlüssel)

•  En6ty-‐Menge kann mehr als einen Schlüsselkandidaten haben –  Beispiel: Autor (AutorID, Vorname, Name, E-Mail)

•  Primärschlüssel ist ein beliebig ausgewählter Schlüsselkandidat

•  Darstellung PrimärschlüsselaWribute im ER-‐Diagramm:

AutorID




ER-‐Modellierung – Rela6onships (Beziehungen)

•  Rela6onship-‐Menge: Zusammenfassung von gleichar6gen Beziehungen (Rela6onships) zwischen En66es, die jeweils gleichen En6ty-‐Mengen angehören

•  Beispiel: Beziehungen „Verwendung“ zwischen „Asset“ und „Publika6on“

•  Symbol:

v2

A3

A2

A1

Assets

Verwendung

P3

P1

Publikationen

E1 E2 R




ER-‐Modellierung – Rela6onships

•  Rela6onship-‐Mengen können auch AWribute besitzen

•  keine Disjunktheit der beteiligten En6ty-‐Mengen gefordert (rekursive Beziehungen)

Redakteure Assets bearbeitet

von bis

Personen Vorgesetzter

Mitarbeiter

Chef




ER-‐Modellierung – Rela6onships

•  mehrstellige Rela6onship-‐Mengen möglich

Redakteure Assets bearbeitet

Software




ER-‐Modellierung – Kardinalität von Rela6onships

•  Festlegung wich6ger struktureller Integritätsbedingungen

•  Unterschiedliche Abbildungstypen für binäre Beziehung zwischen En6ty-‐Mengen Ei und Ej –  1:1 eineindeu6ge Funk6on (injek6ve Abbildung) –  n:1 mathema6sche Funk6on (funk6onale Abbildung) –  n:m mathema6sche Rela6on (komplexe Abbildung)

•  Abbildungstypen implizieren nicht, dass für jedes e ∈ Ei auch tatsächlich ein e’ ∈ Ej exis6ert!

•  Beispiel für 1:1 Abbildungstyp Personen Team leitet

1 1

leitet wird geleitet




ER-‐Modellierung – Kardinalität von Rela6onships

•  Beispiel für n:1 Abbildungstyp

–  in einem Team arbeiten n Personen –  eine Person arbeitet in genau einem Team

Personen Team arbeitet n 1

Redakteure Publikation arbeitet n m

Beispiel für n:m Abbildungstyp

an einer Publikation arbeiten n Redakteure ein Redakteur arbeitet an m Publikationen



ER-‐Modellierung – Überblick über Diagrammsymbole

26


A

E

A A

R E

E1 E2 R n 1

A1 A2 A3

A

Entity-Menge Relationship-Menge schwache Entity-Menge

Attribut Schlüsselattribut mehrwertiges Attribut zusammengesetztes Attribut

Kardinalitätsangaben




ER-‐Modellierung – Generalisierung / Spezialisierung

•  Is-‐A-‐Beziehung zwischen En6ty-‐Mengen

–  E1 is-‐a E2 bedeutet, dass jedes En6ty e aus E1 auch ein En6ty aus E2 ist, jedoch mit zusätzlichen strukturellen Eigenschaden

–  Subs/tu/onsprinzip: alle Instanzen einer Subklasse sind auch Instanzen der Superklasse •  Generalisierung: BoWom-‐Up-‐Vorgehensweise •  Spezialisierung: Top-‐Down-‐Vorgehensweise •  Vererbung von Eigenschaden (AWribute, Methoden, ...) der Superklasse

an alle Subklassen –  Wiederverwendbarkeit, Erweiterbarkeit –  keine Wiederholung von Beschreibungsinforma6on, Fehlervermeidung

Superklasse

Subklasse2 Subklasse1 Artikel Foto

Asset




ER-‐Modellierung – Aggrega6on

•  Objekte werden als Zusammensetzung von anderen Objekten (En6ty-‐Mengen) angesehen

•  Zwischen Komponentenobjekten besteht Part-‐of-‐Beziehung (Teil-‐von-‐Beziehung) –  Elemente einer Subkomponente sind auch Elemente aller

Superkomponenten dieser Subkomponente –  Referenzseman0k ermöglicht, dass ein Objekt gleichzei6g

Subkomponente von mehreren Superkomponenten sein –  Werteseman6k (Komposi0on): Objekt gehört genau zu einem

Aggregat-‐Objekt; Existenzabhängigkeit!




ER-‐Modellierung – Aggrega6on

•  Objekte werden als Zusammensetzung von anderen Objekten (En6ty-‐Mengen) angesehen

•  Zwischen Komponentenobjekten besteht Part-‐of-‐Beziehung (Teil-‐von-‐Beziehung) –  Elemente einer Subkomponente sind auch Elemente aller

Superkomponenten dieser Subkomponente –  Referenzseman0k ermöglicht, dass ein Objekt gleichzei6g

Subkomponente von mehreren Superkomponenten sein –  Werteseman6k (Komposi0on): Objekt gehört genau zu einem

Aggregat-‐Objekt; Existenzabhängigkeit! Aggregatklasse

Komp.klasse2 Komp.klasse1

Komposition

Aggregatklasse

Komp.klasse2 Komp.klasse1

Referenzsemantik

Publikation

Assets




Rela6onales Modell

(noch mehr Theorie aber danach wird’s spannend)




Rela6onales Modell -‐ Datenbankmodelle

•  Datenbankmodell: beschreibt Art und Weise, wie Daten prinzipiell gespeichert und manipuliert werden können –  beinhaltet Datenstrukturen, Operatoren, Integritätsregeln

•  Beispiele: –  Hierarchisches Datenbankmodell

–  Netzwerkmodell

–  Rela6onales Modell

–  Objektorien6ertes Datenbankmodell •  Kapselung der Daten in Objekten •  Zugriff über ID




Rela6onales Modell – Grundlagen

•  Vorschlag von E.F. Codd (1970) •  Grundlage rela6onaler DBS (DB2, SQLServer, MySQL, ...) •  Datenstruktur: Rela6on (Tabelle)

–  einzige Datenstruktur (neben atomaren Werten) –  alle Informa6onen ausschließlich durch Werte

dargestellt

•  Operatoren auf (mehreren) Rela6onen –  Vereinigung, Differenz –  Kartesisches Produkt –  Projek6on –  Selek6on –  zusätzlich: Änderungsopera6onen (Einfügen, Löschen, Ändern)




Rela6onales Modell – Grundlagen

•  Grundregeln

–  Jede Zeile (Tupel) ist eindeu6g und beschreibt ein Objekt (En6ty) der Miniwelt •  Eindeu6gkeit durch Primärschlüssel •  Rela6on ist eine Menge

–  Die Ordnung der Zeilen ist ohne Bedeutung; durch ihre Reihenfolge wird keine für den Benutzer relevante Informa6on ausgedrückt

–  Die Ordnung der Spalten ist ohne Bedeutung, da sie einen eindeu6gen Namen (AWributnamen) tragen

–  Jeder Datenwert innerhalb einer Rela6on ist ein atomares Datenelement (nur einfache AWribute)

–  Alle für den Benutzer bedeutungsvollen Informa6onen sind ausschließlich durch Datenwerte ausgedrückt

Titel

Kurzinformation

Das MML

Studienprogramm

Impressum

ArtID

1

2

3

4

Inhalt

Das ...

In der...

Eine ...

Die ...




Rela6onales Modell – Grundlagen (Fremdschlüssel)

•  Darstellung „rela6onenübergreifender“ Informa6on durch Fremdschlüssel (foreign key) –  AWribut, das in Bezug auf den Primärschlüssel einer anderen (oder

derselben) Rela6on definiert ist (gleicher Defini6onsbereich) –  Beziehungen werden durch Fremdschlüssel und zugehörigen

Primärschlüssel dargestellt

TNR TNAME ...

RE Redaktion ...

TE Technische Dienste ...

MANR NAME TNR W-ORT

123 766 Coy RE Halle

654 711 Abel TE Leipzig

196 481 Maier TE Delitzsch

226 302 Schulz RE Leipzig

Team Mitarbeiter




Rela6onales Modell – Invarianten

•  inhärente Integritätsbedingungen des Rela6onenmodells (Modellbedingungen)

–  Primärschlüsselbedingung (En0ty-‐Integrität) •  Eindeu6gkeit des Primärschlüssels •  keine Nullwerte!

–  Fremdschlüsselbedingung (referen0elle Integrität) •  zugehöriger Primärschlüssel muss exis6eren •  d.h. zu jedem Wert (ungleich Null) eines FremdschlüsselaWributs einer Rela6on R2

muss ein gleicher Wert des Primärschlüssels in irgendeinem Tupel von Rela6on R1 vorhanden sein



Rela6onales Modell – Beispiel

36


Statistik

URL

referenziertIn

WebPage

verweistAuf

WPStatistik

1

m n

n

1 1

ER-Diagramm

Relationales Schema

WID Titel erstelltAm geändertAm WebPage

URL überprüftAm Fehler URL verweistAuf

WebPage Zugriffe Größe STATISTIK URL REFSeite Anzahl URLREF

überprüftAm

Fehler

Anzahl

erstelltAm

geändertAm

Zugriffe

Größe




SQL

(zum Glück brauchen wir das für Rails nicht...) ;-)




SQL

•  Anfragesprache für rela6onale Datenbanken

•  Standardisierung von SQL durch ANSI und ISO –  erster ISO-‐Standard 1987

–  1992: Verabschiedung von „SQL2“ bzw. SQL-‐92

–  1999/2003: SQL:1999 („SQL3“) und SQL:2003 („SQL4“) mit objektorien6erten Erweiterungen etc. (-‐> objekt-‐rela6onale DBS)

•  strukturierte Sprache, die auf englischen Schlüsselwörtern basiert •  Basisanfrage

SELECT artid, inhalt

FROM Artikel

WHERE titel = 'Kurzinformation'

artid

1

2

3

4

inhalt

Das ...

In der...

Eine ...

Die ...




SQL – Anfragemöglichkeiten

•  SELECT-‐Klausel –  Auswahl auszugebender AWribute ( * steht für alle AWribute)

•  FROM-‐Klausel –  spezifiziert die Objekte (Rela6onen, Sichten), die verarbeitet werden sollen

•  WHERE-‐Klausel –  selek6ert auszugebende Datensätze aus den in FROM ausgewählten Rela6onen miWels Bedingungen (können NOT,

AND und OR enthalten) –  Bedingungen können folgende Operatoren enthalten: = , <>, <, <=, >, >=, LIKE, IS NULL

•  GROUP BY-‐Klausel –  Gruppenbildung der selek6erten Datensätze nach angegebenen AWributen –  pro Gruppe s6mmen alle Datensätze in den angegebenen AWributen überein –  pro Gruppe ein Ergebnisdatensatz

•  HAVING-‐Klausel: selek6ert Gruppen bzgl. der Bedingung •  ORDER BY-‐Klausel: Sor6erung nach angegebenen AWributen (DESC abwärts, ASC aufwärts)

select-expression ::= SELECT [ALL | DISTINCT] select-item-list FROM table-ref-commalist [WHERE cond-exp] [GROUP BY column-ref-commalist] [HAVING cond-exp] [ORDER BY order-item-commalist ]




SQL – Beispieldatenbank

•  SQL-‐Trainer: hWp://lots.uni-‐leipzig.de

autor

buch

schlagwort

hat

n

n

m

m

verlag 1 n

autorid nachname initialen vornamen zusatz

verlagsid name ort

buchid titel isbn auflage

jahr preis

waehrung

signatur verlagsid

swid schlagwort

buchid autorid rolle rang

buchid swid

autor

verlag

buch

schlagwort

buch_aut

buch_sw




SQL – Beispielanfragen

Q1: Welche Autoren mit dem Vornamen Lutz gibt es?

Q2: Welche Bücher (Titel) erschienen vor 1980 in einer Neuauflage?

SELECT nachname

FROM autor

WHERE vorname = 'Lutz'

SELECT titel

FROM buch

WHERE jahr<1980 AND auflage='1. Auflage'




SQL – Beispielanfragen

Q3: Welche Bücher (Titel) wurden vom Verlag "Springer" verlegt?

Q4: Geben Sie zu jedem Buch den Titel und die Anzahl der Autoren aus.

SELECT b.titel

FROM buch AS b, verlag AS v

WHERE b.verlagsid=v.verlagsid AND v.name='Springer'

SELECT b.titel, count(*)

FROM buch AS b, autor AS a, buch_aut AS ba

WHERE b.buchid=ba.buchid AND ba.autorid=a.autorid

GROUP BY b.buchid, b.titel



SQL – Befehlsübersicht (Auswahl)

43


Datenmanipulation (DML):

SELECT INSERT UPDATE DELETE Aggregatfunktionen: COUNT, SUM, AVG, MAX, MIN

Datendefinition (DDL):

CREATE SCHEMA CREATE DOMAIN CREATE TABLE CREATE VIEW ALTER TABLE DROP SCHEMA DROP DOMAIN DROP TABLE DROP VIEW

Datenkontrolle:

Constraints-Definitionen bei CREATE TABLE CREATE ASSERTION DROP ASSERTION GRANT REVOKE COMMIT ROLLBACK




Objekt-‐rela6onale Modellierung



Mo6va6on •  Rela6onales Datenmodell (Tabellen) eignet sich gut für

Speicherung, Transak6onen (ACID)

•  Objekt-‐orien6erte Konzepte eignen sich besser für Modellierung als ER-‐Diagramme

•  Objekt-‐orien6erte Konzepte können direkt mit Objekt-‐orien6erten Programmiersprachen (Ruby, Python, Java, C#, C++, ...) umgesetzt werden

beides Verbinden bringt die Vorteile von beidem

45




Ziel •  Datenhaltung in einer rela6onaler Datenbank •  Datenverwendung mit objekt-‐orien6erten Klassen

•  Möglichst einfache Modellierung •  Möglichst automa6sche Generierung des Mapping

Codes

46




Rela6onale Modellierung •  Bereits behandelt (ER-‐Diagramme, SQL)

•  Für ORM wich6g: –  alle „Dinge“ vom gleichen Typ stehen in einer Tabelle –  Jede Zeile ein „Ding“ –  Jedes Ding (d.h. jede Zeile) hat eine eindeu6ge ID (meist Integer) –  Jede Spalte ist eine Eigenschad des Dings –  Beziehungen zu anderen „Dingen“ miWels Fremdschlüssel: die ID der

zugehörigen Zeile in anderer Tabelle wird in eine Spalte geschrieben

47




Objekt-‐orien6erte Modellierung •  zu verarbeitende Daten werden anhand ihrer

Eigenschaden und möglichen Opera6onen klassifiziert •  gemeinsame Betrachtung von Eigenschaden und

Funk6onen soll entsprechende menschliche Organisa6onsmethoden aus der realen Welt besser nachzubilden

•  für ORM werden nur Eigenschaden, nicht Funk6onen, betrachtet, da letztere sich nicht (direkt) im Rela6onenmodell abbilden lassen

48




Objekt-‐rela6onales Mapping •  SchniWpunkte zwischen RM und OOM werden

„verbunden“

•  Tabellen <-‐> Klassen •  Spalten <-‐> Eigenschaden •  Zeilen <-‐> Objekte

49




Objekt-‐rela6onales Mapping mit Ac6veRecord

•  Einfache Eigenschaden werden nur in der Tabelle angegeben, nicht im Modell

•  Komplexere Eigenschaden brauchen Fremdschlüssel

•  Komplexere Eigenschaden brachen Deklara6on im Modell

•  Wurde bereits in der Übung gemeinsam erarbeitet

50




Objekt-‐rela6onales Mapping in Rails •  Sowohl Datenbank-‐Tabellen, als auch Modell-‐Klassen

werden automa6sch angelegt •  Verbindung Tabelle-‐Klasse usw. wird auf Basis einiger

Konven6onen automa6sch gemacht •  Beziehungen zwischen Klassen untereinander müssen

manuell angelegt werden

•  Konven6on 1: –  Klassenname im Singular, dazugehörige Tabelle im Plural

•  Konven6on 2: –  Eigenschadsnamen gleich Spaltenname

51




Rails Scaffolding •  Rails Scaffolding erstellt Datenbank und Modellklassen

•  Hilfe –  ruby script/generate scaffold

•  Verwendung –  ruby script/generate scaffold SingularName spalte1:typ spalte2:typ

•  Klasse class SingularName < ActiveRecord::Base end

•  Tabelle PluralName (bzw. prak6sch: „SingularName“.pluralize => SingularNames)

52




Modellklassen in Rails Erstellen: script/generate model Person firstname:string

lastname:string dob:date Code: class Person < Ac6veRecord::Base # keine Methoden hier

end

Verwendung p = Person.new p.firstname = "Benjamin" p.save

53




Vergleich: Datenbankeinbindung mit PHP („früher“)

•  PHP – Die Webseite ist das Programm

54


<html> <body> <h1>Employee #1</h1> <?php

$con = dbx_connect(DBX_PGSQL, “host“, “myDB”, “login”, “password”) or die(“Connection error!</body></html>“); $result = dbx_query($con, “SELECT * FROM Employees WHERE EmployeeID = 1“); if ( is_object($result) and ($result->rows > 0) ) {

?> <b>Name:</b> <?php echo $result->data[0][“Name”] ?><br> <b>Address:</b> <?php echo $result->data[0][“Address”] ?><br> <b>City/State/ZIP:</b> <?php echo $result->data[0][“City”] . “,“ . $result->data[0][“State”] . ““ . $result->data[0][“ZipCode”]

?><br> <?php } else { echo “Unknown employee!“; } ?>

</body> </html>

•  Vermischung von Inhalt und Programmlogik

Documents

Contentmanagement. - uni-leipzig.deasv.informatik.uni-leipzig.de/uploads/document/file_link/219/SQ10CMV... · Institut für Informatik Automatische Sprachverarbeitung topicmapslab.de