Commit eb801b55 authored by Blanke, Daniela's avatar Blanke, Daniela
Browse files

Update distributed-orm.html

parent b1546a33
Pipeline #8027 passed with stage
in 1 minute and 9 seconds
......@@ -160,7 +160,7 @@ public class Person {
<h4>JPA-Persistenzkontext</h4>
<p>Der JPA-Persistenzkontext je Session wird durch einen sogenanntes <a href="https://javaee.github.io/javaee-spec/javadocs/javax/persistence/EntityManager.html"><code>EntityManager</code></a>-Objekt verwaltet. Wie in der folgenden Abbildung dargestellt wird, erfolgt in JPA jeder Lese- oder Schreibzugriff auf die Datenbank über Methoden des <i>EntityManager</i>. Das Pendant zum eher abstrakten Begriff <i>EntityManager</i> wird in Hibernate etwas sprechender als <i>Session</i> bezeichnet. Das Interface <code>org.hibernate.Session</code> erweitert dementsprechend das Interface <code>javax.persistence.EntityManager</code>. Der EntityManager verwaltet also sämtliche Entitäten, die während einer Session mit der Datenbank ausgetauscht werden.</p>
<p>Der JPA-Persistenzkontext je Session wird durch ein sogenanntes <a href="https://javaee.github.io/javaee-spec/javadocs/javax/persistence/EntityManager.html"><code>EntityManager</code></a>-Objekt verwaltet. Wie in der folgenden Abbildung dargestellt wird, erfolgt in JPA jeder Lese- oder Schreibzugriff auf die Datenbank über Methoden des <i>EntityManager</i>. Das Pendant zum eher abstrakten Begriff <i>EntityManager</i> wird in Hibernate etwas sprechender als <i>Session</i> bezeichnet. Das Interface <code>org.hibernate.Session</code> erweitert dementsprechend das Interface <code>javax.persistence.EntityManager</code>. Der EntityManager verwaltet also sämtliche Entitäten, die während einer Session mit der Datenbank ausgetauscht werden.</p>
<img src="media/distributed_orm_entitymanager.png" style="width:700px">
<label>EntityManager in JPA</label>
......@@ -294,7 +294,7 @@ public class Department {
// ...
}</code></pre>
<p>Beim <i>Lazy Loading</i> wird das entsprechende Attribut erst bei einem späteren Zugriff befüllt. In folgendem Code-Beispiel löst die Zeile 1 eine oder zwei SQL-Anfragen aus: zum einen wird stets der gesuchte Datensatz aus der Tabelle <code>department</code> gelesen, zum anderen der zugehörige Abteilungsleiter ermittelt, falls das Attribut <code>lead</code> in der Klasse <code>Department</code> gesetzt ist. Das Laden der zugeordneten Personen im Attribut <code>staff</code> durch eine SQL-Anfrage auf die Tabelle <code>person</code> erfolgt erst beim ersten Zugriff auf eine Methode dieses Attributs in Zeile 8. Bis dahin ist das Attribut nicht instantiiert (vgl. Zeilen 5-6). Im Debug-Modus kann das Lazy Loading nicht ohne Weiteres beobachtet werden, da der Debugger selbst das Laden der Attribute verursacht, um deren aktuellen Status anzeigen zu können.</p>
<p>Beim <i>Lazy Loading</i> wird das entsprechende Attribut erst bei einem späteren Zugriff befüllt. Im folgenden Code-Beispiel löst die Zeile 1 eine oder zwei SQL-Anfragen aus: zum einen wird stets der gesuchte Datensatz aus der Tabelle <code>department</code> gelesen, zum anderen der zugehörige Abteilungsleiter ermittelt, falls das Attribut <code>lead</code> in der Klasse <code>Department</code> gesetzt ist. Das Laden der zugeordneten Personen im Attribut <code>staff</code> durch eine SQL-Anfrage auf die Tabelle <code>person</code> erfolgt erst beim ersten Zugriff auf eine Methode dieses Attributs in Zeile 8. Bis dahin ist das Attribut nicht instantiiert (vgl. Zeilen 5-6). Im Debug-Modus kann das Lazy Loading nicht ohne Weiteres beobachtet werden, da der Debugger selbst das Laden der Attribute verursacht, um deren aktuellen Status anzeigen zu können.</p>
<pre><code class="language-java line-numbers">Department dept = em.find(Department.class, 1); // finds person with id = 1
// causes department query: SELECT id, label, lead_id FROM department WHERE id = ?
......@@ -325,7 +325,7 @@ später zu einem ungewollten Zeitpunkt während der Anwenderinteraktion geschehe
</table>
<p>Dazu zählen eine Methode für native SQL-Anfragen und eine Methode zum Aufruf von <i>Stored Procedures</i>. Bevorzugt werden aber Anfragen über die <i>Java Persistence Query Language (JPQL)</i>, die ihrerseits stark an SQL angelehnt ist. JPQL orientiert sich in seiner deklarativen Syntax mit <code>SELECT</code> ... <code>FROM</code> ... <code>WHERE</code> ... <code>GROUP BY</code> ... <code>ORDER BY</code> ... an dem gleichen Gerüst an Schlüsselworten für eine Anfrage wie SQL.
Viele Operatoren (z.B. <code>LIKE</code>, <code>IN</code>) und Aggregatfunktionen (z.B. <code>COUNT</code>, <code>SUM</code>, <code>AVG</code>) verhalten sich ebenfalls wie in SQL. Ein wichtiger Unterschied ist, dass in der <code>FROM</code>-Klausel nicht die zugrundeliegende Tabelle sondern die objektorientierte Klasse adressiert wird. Demzufolge ist auch die Navigation entlang von Assoziationen über den Operator <code>.</code> möglich, welcher bei der Übersetzung in eine SQL-Anfrage implizit einen Join verursachen kann. Zur Veranschaulichung dienen die folgenden Beispiele.</p>
Viele Operatoren (z.B. <code>LIKE</code>, <code>IN</code>) und Aggregatfunktionen (z.B. <code>COUNT</code>, <code>SUM</code>, <code>AVG</code>) verhalten sich ebenfalls wie in SQL. Ein wichtiger Unterschied ist, dass in der <code>FROM</code>-Klausel nicht die zugrundeliegende Tabelle, sondern die objektorientierte Klasse adressiert wird. Demzufolge ist auch die Navigation entlang von Assoziationen über den Operator <code>.</code> möglich, welcher bei der Übersetzung in eine SQL-Anfrage implizit einen Join verursachen kann. Zur Veranschaulichung dienen die folgenden Beispiele.</p>
<pre><code class="language-sql line-numbers">-- Select all persons and their associated department label (causes a join of the person table and the department table)
SELECT p.id, p.name, p.department.label FROM Person p;
......@@ -511,7 +511,7 @@ Nachteile:
</ul><br>
</li>
<li><b>Table per Class</b>: Bei dieser Vererbungsstrategie entsteht eine Tabelle für jede konkrete Klasse einer Vererbungshierarchie. Jede Tabelle enthält nicht nur die Attribute der konkreten Unterklasse sondern auch sämtliche Attribute ihrer Oberklassen. Dadurch gibt es im relationalen Modell keine Fremdschlüssel. Es sind keine Joins erforderlich.
<li><b>Table per Class</b>: Bei dieser Vererbungsstrategie entsteht eine Tabelle für jede konkrete Klasse einer Vererbungshierarchie. Jede Tabelle enthält nicht nur die Attribute der konkreten Unterklasse, sondern auch sämtliche Attribute ihrer Oberklassen. Dadurch gibt es im relationalen Modell keine Fremdschlüssel. Es sind keine Joins erforderlich.
<pre><code class="language-java line-numbers">@Entity @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public class Person {
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment