Aby zagnieździć zapytania, należy przypisać je do elementów
potomnych.
Procedura
- W programie Document Studio otwórz widok Schemat źródła
danych.
- Przeciągnij element z widoku Schemat źródła danych
do elementu szablonu. Gdy zapytanie jest przeciągane
na element, który ma element nadrzędny, sprawdzane jest, czy to zapytanie
można uruchomić w kontekście zapytania elementu nadrzędnego. Wszystkie
zapytania, które mogą działać jako kontekst, są wyświetlane w oknie
Wybór kontekstu.
Na liście wyświetlany jest identyfikator i jego reprezentacja tekstowa.
- Wybierz kontekst zapytania z listy. Brak wyboru
kontekstu spowoduje, że będą istnieć dwa niepowiązane zapytania zagnieżdżone.
- Kliknij przycisk
OK.
Przykład
W poniższym przykładzie przedstawiono zagnieżdżone zapytanie
przypisane do elementu szablonu produktu
Rational DOORS.
Paragraph DOORS 1 $1 Module/Object
Text
Module/Object/Object/Heading
Paragraph DOORS 1 $2 Module/Object/Attribute
Text
Module/Object/Attribute/Name
W tym przykładzie zapytanie
Module/Object
stanowi kontekst dla zapytania
Module/Object/Attribute.
W tym
przykładzie ustawienie kontekstu dla drugiego zapytania na $1 spowoduje wygenerowanie
następujących danych wyjściowych:
- Zestaw akapitów zawierających nagłówek każdego obiektu
w module.
- Lista akapitów z nazwami atrybutów dla bieżącego
obiektu w zapytaniu $1.
Ustawienie kontekstu dla drugiego zapytania na wartość brak spowoduje
wygenerowanie następujących danych wyjściowych:
- Zestaw akapitów zawierających nagłówek każdego obiektu
w module.
- Lista akapitów z nazwami atrybutów dla wszystkich obiektów.
W poniższym przykładzie przedstawiono zagnieżdżone zapytanie przypisane do elementu szablonu produktu
IBM® Rational Tau.
Pierwsze zapytanie - model/root(Package) -
jest wykonywane w kontekście modelu produktu Rational Tau.
Drugie zapytanie - model/root(Package)/ownedMember - jest
wykonywane w każdym pakiecie zwracanym przez pierwsze zapytanie.
Jeśli
lista wszystkich klas z pakietów najwyższego poziomu w modelu jest wymagana, zapytanie
to
model/root(Package)/ownedMember(Class).
W tym formularzu dokument wyjściowy nie zawiera już nazwy
każdego pakietu. Lista klasy jest budowana w taki sam sposób, jak w pierwszym
przypadku. Zapytanie jest podzielone na własne zapytania komponentów, a każde zapytanie
działa w kontekście zdefiniowanym przez poprzednie zapytania:
Tabela 1. PodzapytaniaPodzapytanie |
Kontekst |
Wynik |
model |
Nie dotyczy |
model |
model/root(Package) |
model |
lista pakietów |
ownedMember(Class) |
lista pakietów |
lista klas |
Każde podzapytanie jest wykonywane jeden raz dla każdego elementu, a wyniki
każdego wykonania są konkatenowane. Te wyniki
stają się kontekstem dla następnego podzapytania lub listy wyników, jeśli podzapytanie
jest ostatnim zapytaniem.