Modelleer tip 4 : READ en Performance 1

READ van attributen van twee Entity Types

Je leert:
     - hoe wordt DM en DSL gebruikt bij READ-statements?
     - welke SQL-code wordt gegenereerd uit een READ-statement?
     - hoeveel tabellen worden benaderd bij een READ van twee entity types? 

Gebruik je READ statements om data uit de DB te lezen? Wees dan op je hoede, want onhandig modelleren van READ-statements heeft geregeld een slechte performance tot gevolg. 
Vele factoren hebben invloed op de performance van een applicatie die gegevens uit een DB haalt. Enkele zijn:
- de structuur van het Data Model,
- de bouw van tabellen en indexen van de database,
- de views in het Action Diagram,
- de structuur van READ-statement(s).

In deze modelleertip kijken we naar de manier waarop de code wordt gegenereerd vanuit de specificaties in het Gen-model.
Realiseer je dat het READ gebruik maakt van het Data Model. De gegenereerde code maakt gebruik van de in de DSL genoemde tabel- en kolomnamen van de database.
In het vervolg wordt achtereenvolgens gekeken naar:
1. het Data Model (DM) en de hieruit getransformeerde Data Structure List (DSL)
2. READ-statements en de views in het action diagram bij het opvragen van
    a. Customer gegevens,
    b. Order gegevens en
    c. Customer-Order gegevens

1. Data Model en Data Structure List
Het Data Model (DM in de Analysis tool) is een model van de business data, niet de structuur van de tabellen in de database.  Door de Transformation wordt het Data Model omgezet in de Data Structure List (DSL). De DSL toont de structuur van de databasetabellen waarin de data worden opgeslagen. 

Elk element in het DM heeft een overeenkomstig element in de DSL. Hieronder staan enkele van de belangrijkste.

Dit principe is voor elk DBMS gelijk. Hieronder zie je in figuur 1 hoe het DM van twee entity types is omgezet in de DSL.


figuur 1.

Elke entity type wordt als tabel geïmplementeerd en elk attribuut wordt een column in een tabel.
De 1:n relatie wordt geïmplementeerd door de (primary) identifier van het entity type van de 1-kant als foreign-key column op te nemen in de tabel van de n-kant. Zie de figuur 2 hieronder.


  figuur 2.

2. Ophalen van Customer gegevens
Om de gegevens van een customer uit de DB op te halen wordt een READ-statement gebruikt:  READ customer.
Een READ-statement resulteert bij codegeneratie in een SQL-statement. Zo zal READ customer resulteren in een SELECT .... FROM CUSTOMER. 
Niet altijd worden alle atributen van de gelezen entity type aan de applicatie afgeleverd. Slechts de identifier(s) en de attributen die in de entity action view zijn opgenomen, worden gelezen. Zie figuur 3 hieronder.


figuur 3.

N.B. Wil je de gegenereerde SQL bekijken? Selecteer in het  Generation window de regel van het action diagram en kies daarna Diagram, Show, Source. Of u daar de statische of dynamische vorm van SQL ziet, is afhankelijk van de generatie-omgeving die u gebruikt.

3. Ophalen van ordergegevens
READ order genereert een soortgelijke select voor de order tabel. Als alle attributen in de entity action view staan, zullen ze alle de waarde uit de tabel krijgen.

SELECT
            NUMBER
            ORDER_DATE
            ......
            ......
FROM
            ORDER


4. Ophalen van customer- én ordergegevens
Lezen van customer- én ordergegevens kan op twee manieren:
1. Twee READ's: READ customer gevolgd door READ order
    Na generatie zijn er twee Select statements, één voor customer en één voor order.
    Beide tabellen worden gelezen op de wijze die hierboven is besproken.
2. Eén gecombineerde READ: READ customer,order
    Na generatie is er één Select statement. Of er ook twee of slechts één tabel worden
    benaderd, hangt af van verschillende factoren. 
    De order tabel in figuur 1 bevat ook een foreign key column van customer number. Als men
    alleen customer number wil weten (=alleen number in de customer entity action view), kan
    het customer number uit de customer tabel of uit de order tabel gelezen worden. CA Gen
    optimaliseert in deze situatie de SQL zodanig dat alleen de order tabel gelezen wordt.
    De READ van twee entity types levert nu een select van slechts één tabel op.
    Zie figuur 4 hieronder.



figuur 4.

Let op: Het is meestal niet juist om op grond van de gegenereerde selects nu al te concluderen welke READ situatie de voorkeur heeft vanuit het performanceperspectief. Grootte van de tabel, vullingsgraad, indexen en andere factoren moeten in de beschouwing worden betrokken om een juiste keuze te kunnen maken, veelal in overleg met de DBA. Echter, kennis van de manier waarop de select wordt gegenereerd is een belangrijke basis op grond waarvan de developer actie kan ondernemen.

Bedenk ook dat de Database Administrator allerlei mogelijkheden heeft om het DB-ontwerp in Gen maken en aan te passen. Deze kennis is helaas niet voldoende algemeen bekend bij DBA's. Niet alle DBA's weten bijvoorbeeld hoe je in Gen kunt denormaliseren t.b.v. performance.