A anlise de toda aplicao GeneXus comea com o desenho das transaes.

As transaes permitem definir os objetos da realidade.

Para identificar quais so as transaes que precisam ser criadas, se recomenda prestar
ateno aos substantivos que o usurio menciona quando escreve a realidade.
Alm de ter por objetivo a definio da realidade e criao da base de dados
normalizada, as transaes, assim como a maioria dos demais objetos GeneXus,
provocam a gerao de programas. Os programas oriundos das transaes tm o
objetivo de permitir inserir, eliminar e modificar de forma interativa as tabelas que tenham
relao, controlando estes programas e a integridade referencial dos dados.

26

Alguns elementos das transaes, que sero vistos:

Estrutura: Permite definir os atributos (campos) que compem a transao e a reao entre elas. A partir
deles, o GeneXus conclui o desenho da base de dados: tabelas, chaves, ndices, etc.
Web Form: Cada transao contm um Form (tela) Web mediante o qual se realiza inseres,
eliminaes e alteraes no ambiente Web.
Win Form: idem, mas para ambiente Win.
Regras: As regras permitem definir o comportamento particular das transaes. Por exemplo, permitem
definir valores por default para os atributos, definir validaes sobre os dados, etc.
Eventos: As transaes suportam a programao orientada a eventos. Este tipo de programao permite
definir cdigo ocioso, que se ativa em resposta a certas aes provocadas pelo usurio ou pelo sistema.
Variveis: Permite a definio de variveis que so locais a Transao.
Ajuda: Permite a incluso de texto de ajuda, para ser consultado pelos usurios em tempo de execuo
da transao.
Documentao: Permite a incluso de texto tcnico, para ser utilizado como documentao do sistema.
Patterns: (padres) que podem ser aplicados a Transao com a finalidade de implementar de forma
automtica certa funcionalidade.

Propriedades: (so visualizadas numa janela a parte) Permitem definir certos detalhes referentes ao
comportamento da transao.
Alguns destes elementos tambm esto associados a outros tipos de objetos GeneXus.

27

A estrutura de uma transao permite definir que atributos integram a mesma e como esto
relacionados.
Por exemplo, se numa aplicao necessrio registrar informao de fornecedores, ter que ser
definido uma transao, a qual podemos dar o nome Supplier e sua estrutura pode ser a seguinte:
{SupplierId*
SupplierName
SupplierAddress
SupplierPhone }
Esta lista de nomes (um dos quais est sucedido do smbolo asterisco) corresponde aos atributos dos
fornecedores que interessam ser mantidos.
Ento, criamos uma transao de nome Supplier cuja estrutura composta dos atributos
SupplierId*, SupplierName, SupplierAddress e SupplierPhone.
Isto significa que cada fornecedor identificado por um cdigo SupplierId (o qual fica determinado
pelo asterisco aps o atributo), ter um nome SupplierName, um endereo SupplierAddress e um
telefone SupplierPhone.
Para cada atributo definido na estrutura, deveremos indicar coisas como seu tipo de dados, descrio
e alguns outros detalhes mais que veremos.
__________________________________________________________________________________________
1 O asterisco corresponde a uma notao terica que utilizamos para indicar que o atributo identificador. Como
veremos, esse asterisco em GeneXus aparece representado por um cone de chave e o usurio pode configurlo mediante um menu contextual que oferece esta possibilidade.

28

Atributos Chave
Na pgina anterior foi explicado que o asterisco aps o atributo SupplierId indica que o mesmo o
identificador na transao. Toda transao deve ter pelo menos um identificador, isto , um atributo ou
conjunto de atributos que definam a unicidade da informao.
No exemplo no podero existir dois fornecedores com o mesmo valor de SupplierId. Em definitivo se trata
do conceito de chave primria, e para escolher os atributos que a compem, devemos levar em
considerao os requisitos da realidade do objeto.
Nos casos em que no se pode determinar um identificador, deve-se optar por criar um atributo artificial (no
existente na realidade), e que seu valor seja atribudo internamente, por exemplo, na forma correlativa.
Como pode ser observado no editor de transaes GeneXus, um cone de chave representa o asterisco que
usamos como notao terica.
Atributo descriptor
O cone com uma lupa representa o atributo que melhor descreve a transao. Em outras palavras seria o
atributo que tem maior carga semntica na transao.
Por default o primeiro atributo na estrutura da transao que seja do tipo de dados character, se define como
atributo descriptor. possvel definir outro atributo como descriptor utilizando o menu pop-up
correspondente, assim como no definir nenhum.

29

Nveis de uma transao

A transao Invoice consta de dois nveis: o primeiro nvel fica implcito, no necessitando de um
jogo de chaves; e o segundo nvel corresponde ao conjunto de atributos que ficam definidos entre
chaves .
O fato de definir um segundo nvel significa que existem vrias instncias do mesmo, para cada
instancia do nvel anterior. No exemplo, um cabealho da fatura e seus vrios produtos.
Cada nvel de uma transao define um grupo de atributos que devem operar em conjunto, ou seja,
se insere, elimina ou se altere conjuntamente na base de dados.
Chamamos de transao plana a uma transao de um nvel. Assim, podemos dizer que a transao
Supplier a transao plana.
A diferena da transao Invoice que contm dois nveis. comum falarmos de cabealho para o
primeiro nvel e de linhas para o segundo.
Para cada nvel da transao, deve ser indicado quais atributos atuam como identificador. O
identificador de cada nvel pode ser composto somente de um atributo, como o caso das
transaes que vimos at agora, ou pode ser composto por vrios atributos.
Na transao Invoice o atributo InvoiceId o identificador do primeiro nvel, e o atributo ProductId +
o atributo dos nveis superiores o identificador do segundo nvel. Este ltimo significa que para um
nmero de fatura dado, no repetido o valor do atributo ProductId em distintas linhas.
Uma transao pode conter vrios nveis paralelos, assim como aninhados.
_________________________________________________________________________________________
1

O asterisco uma notao terica representando que o atributo que o antecede identificador na transao, o

30

jogo de chaves tambm utilizado como notao terica, para representar que os atributos contidos formam parte de
um nvel aninhado, e que tem uma representao visual em GeneXus distinta, mas indica o mesmo.

30

Em GeneXus fica visualmente claro o nvel correspondente as linhas da fatura.

A cada nvel de uma transao se deve atribuir um nome, tipo1 e descrio (exceto ao primeiro nvel, que recebe
como nome o da transao).
Nveis paralelos e aninhados
Uma transao pode ter vrios nveis aninhados, assim como nveis paralelos.
Por exemplo, no caso hipottico que uma fatura pode ter vrios pagamentos, poderamos definir dois tipos de
estrutura, dependendo do que se queira representar:
Invoice {
InvoiceId*
InvoiceDate
CustomerId
CustomerName
InvoiceAmount
Detail
{ProductId*
ProductDescription
ProductPrice
InvoiceDetailQuantity
InvoiceDetailAmount}
Payment
{InvoicePaymentDate*
InvoicePaymentAmount}
}

Invoice {
InvoiceId*
InvoiceDate
CustomerId
CustomerName
InvoiceAmount
Detail
{ProductId*
ProductDescription
ProductPrice
InvoiceDetailQuantity
InvoiceDetailAmount
Payment
{InvoicePaymentDate*
InvoicePaymentAmount}}
}

Na estrutura da esquerda definido uma fatura que tem muitos produtos e muitos pagamentos, mas no tem relao
direta entre os produtos e os pagamentos (a no ser pelo fato de pertencerem mesma fatura). Na estrutura da
direita so registrados os pagamentos por produto comprado.
fcil compreender que o segundo e o terceiro nvel da transao da esquerda so paralelos. Ambos esto
aninhados ao primeiro nvel, mas entre eles, so paralelos. Na estrutura da direita, so todos os nveis aninhados.
____________________________________________________________________________________________________________
1 Como veremos depois, o tipo que se define para um nvel de uma transao, ser utilizada para trabalhar com business
components, conceito relacionada as transaes.

31

GeneXus utiliza a estrutura das transaes para capturar o conhecimento necessrio para definir
automaticamente qual o modelo de dados que ser criado.
Para poder realizar a normalizao da base de dados ser realizada numa 3 forma normal,
GeneXus deve extrair as dependncias funcionais existentes entre os atributos definidos na base
de conhecimento.
Na base de conhecimento de nosso exemplo, temos definido na transao Supplier e de sua
estrutura GeneXus extramos as seguintes dependncias funcionais:
SupplierId {SupplierName, SupplierAddress, SupplierPhone}
Dadas estas dependncias funcionais, GeneXus determina que deve criar uma tabela que ter por
default o mesmo da transao (SUPPLIER)1, e que estar conforme nem mais nem menos que
pelos quatro atributos anteriores, sendo SupplierId a chave primria da mesma:
SUPPLIER

SupplierId

SupplierName

SupplierAddress

SupplierPhone

Diremos que a transao Supplier tem a tabela associada SUPPLIER quando inserir, modificar ou
eliminar pela transao, assim estaro armazenando, modificando ou eliminando fisicamente na
tabela associada.

________________________________________________________________________________
1

Na documentao, para distinguir o nome de uma tabela do nome de uma transao escreveremos o nome
da tabela em maisculo.

32

A partir da estrutura da transao Invoice, GeneXus determina que deve criar duas tabelas:
Tabela INVOICE, correspondente ao primeiro nvel da transao:
INVOICE

InvoiceId

CustomerId

CustomerName

InvoiceDate

InvoiceAmount

Chave primria: InvoiceId

Tabela INVOICEDETAIL correspondente ao segundo nvel da transao:

INVOICEDET
AIL

InvoiceId

ProductId

InvoiceDetailQuantity

ProductDescription

ProductPrice

InvoiceDetailAmount

Chave primria: {InvoiceId, ProductId}

Chave estrangeira: InvoiceId
j que as dependncias funcionais so:
InvoiceId {CustomerId, CustomerName, InvoiceDate, InvoiceAmount}
{InvoiceId, ProductId} {ProductDescription, ProductPrice, InvoiceDetailQuantity,
InvoiceDetailAmount}
Observe que a chave primria da tabela INVOICEDETAIL a concatenao do identificador do
primeiro nvel, InvoiceId, com o identificador do segundo nvel, ProductId. A regra geral: a chave
primria da tabela correspondente a um nvel n de uma transao se obtm em concatenar os
identificadores dos n-1 nveis anteriores aninhados, com o identificador desse nvel.
GeneXus atribui um nome prdeterminado s tabelas que cria. A tabela associada ao primeiro nvel
de uma transao atribui o mesmo nome que o da transao; e as tabelas dos nveis subordinados
so atribudas a concatenao dos nomes dos nveis. Por isso que a tabela associada ao
segundo nvel da transao Invoice recebe o nome de INVOICEDETAIL, sendo que o nome do
primeiro nvel o da transao INVOICE, e o segundo nvel DETAIL. Os nomes das tabelas
podem ser modificados pelo analista GeneXus quando o desejar.

33

Depois de ter modelado a transao Invoice, damos conta que existem informaes de clientes e
produtos que interessante manter independente das faturas. Isto , os clientes e os produtos so dois
objetos de realidades independentes das faturas, para isso necessrio criar duas novas transaes
"Customer" e "Product" detalhadas acima.
Dependncias funcionais
Com estas novas transaes definidas, aparecem novas dependncias funcionais:
CustomerId {CustomerName, CustomerAddress, CustomerGender, CustomerStatus}
ProductId

{ProductDescription, ProductPrice, ProductStock}

que conduzem diretamente a criao de duas novas tabelas:

CUSTOMER

CustomerId

CustomerName

CustomerAddress

CustomerGender

Chave primria: CustomerId

e:
PRODUCT

ProductId

ProductDescription

ProductPrice

ProductStock

Chave primria: ProductId

34

O conjunto total de dependncias funcionais existentes requer algumas modificaes nas tabelas
INVOICE e INVOICEDETAIL desenhadas previamente para que o desenho da base de dados
permanea na 3 forma normal1.
Se representarmos sobre as tabelas CUSTOMER e INVOICE as dependncias funcionais encontradas
para os seus atributos:

podemos ver claramente que INVOICE viola a 3era. forma normal (existe uma dependncia funcional
transitiva):
InvoiceId
CustomerId
CustomerId CustomerName
InvoiceId
CustomerName
por tanto GeneXus normaliza, tirando o atributo CustomerName da tabela INVOICE:

Agora CustomerName somente estar na tabela CUSTOMER.

_________________________________________________________________________________
1 Para mais informao sobre as formas normais (3era. forma normal, etc.) recomendamos a leitura do documento
Fundamentos de bases de dados relacionais, que est includo no captulo Anexos do curso GeneXus no
presencial. Do contrrio, pode pedir ao docente.

35

Agora veremos as dependncias funcionais encontradas nas tabelas PRODUCT e INVOICEDETAIL:

podemos perceber claramente que a tabela INVOICEDETAIL est violando a 3era. forma normal (existem
atributos que dependem de forma parcial da chave primria):
ProductId

ProductDescription

{InvoiceId, ProductId} ProductDescription

ProductId

ProductPrice

{InvoiceId, ProductId} ProductPrice

Portanto GeneXus normaliza, tirando os atributos ProductDescription e ProductPrice da tabela INVOICEDETAIL:

ProductDescription e ProductPrice somente ficaro na tabela PRODUCT.

36

Conceitos iguais devem ter o mesmo nome e conceitos diferentes devem ter nomes diferentes.
GeneXus estabelece as relaes atravs dos nomes dos atributos, de modo que, quando encontra
atributos com o mesmo nome em diferentes transaes, entende que trata-se do mesmo conceito,
e mediante este conhecimento que pode normalizar.
No exemplo que estamos utilizando, quando o GeneXus encontra o atributo de nome CustomerId
tanto na transao "Customer" como na transao "Invoice", analisa que: o atributo tem o mesmo
nome em ambas transaes, assim possuem o mesmo conceito. Na transao "Customer"
CustomerId est marcado como identificador, o qual significa que chave primria na tabela
fsica CUSTOMER; ento na tabela fsica INVOICE ser chave estrangeira.
O atributo CustomerName, por sua parte, tambm se encontra tanto na transao "Customer"
como na transao Invoice, mas a diferena de CustomerId, no est marcado como
identificador em nenhuma transao do modelo; com isso, o GeneXus entende que trata-se de um
atributo secundrio. As dependncias funcionais indicam que o CustomerName o determina
CustomerId:
InvoiceId CustomerId
CustomerId CustomerName
assim que o GeneXus incluir a CustomerName na tabela fsica CUSTOMER (e no na tabela
fsica INVOICE).
Atributos primrios e secundrios
Um atributo se qualifica como primrio quando o mesmo identificador em alguma transao do
modelo. No exemplo que estamos vendo, CustomerId um atributo primrio, j que identificador
na transao "Customer".
CustomerName, um atributo secundrio j que no identificador em nenhuma transao do
modelo.

37

Atributos Armazenados e Inferidos

Ao definir as transaes "Customer" e "Product", inclumos nelas certos atributos que no
eliminamos da transao Invoice.
Os atributos CustomerId e ProductId, sero includos nas transaes "Customer" e "Product"
respectivamente, e ao serem marcados como identificadores das mesmas, passaro a serem
atributos primrios.

O atributo CustomerName, por sua vez, se agregou na transao "Customer"; e os atributos

ProductDescription e ProductPrice na transao "Product". Estes so atributos secundrios.
Todos os atributos antes mencionados esto em mais de uma transao: partindo do princpio que
continuam na transao Invoice tal como foi definido no princpio, e foram includos nas
transaes "Customer" e "Product" respectivamente, porque notamos a necessidade de criar
estes objetos.
Invoice
Customer
Posteriormente, apresentamos 3 estruturas das transaes
em questo, para poder visualiz-las
{
{
juntas:
InvoiceId*
CustomerId*
InvoiceDate
CustomerName
CustomerId
CustomerAddress
CustomerName
CustomerGender
Detail
}
{
ProductId*
ProductDescription
Product
ProductPrice
{
InvoiceDetailQuantity
ProductId*
InvoiceDetailAmount
ProductDescription
}
ProductPrice
InvoiceAmount
ProductStock
}
}

Provavelmente voc est se perguntando qual a razo dos atributos secundrios CustomerName,
ProductDescription e ProductPrice continuam na estrutura da transao "Invoice".
A explicao a seguinte: as estruturas das transaes, no so equivalentes s estruturas
de tabelas fsicas. Nas estruturas das transaes podem ser includos atributos que no estaro
nas tabelas fsicas associadas s mesmas, j que na hora de reorganizar a base de dados, o
GeneXus analisa o conjunto total de dependncias funcionais existentes na base de
conhecimento, e cria - ou modifica, segundo o caso - as tabelas fsicas, deixando-as na 3 forma
normal.
Agora, com que finalidade temos deixado os atributos secundrios CustomerName,
ProductDescription e ProductPrice na estrutura da transao Invoice? Foram deixados para
poder inclu-los em algum dos elementos do objeto da transao, por exemplo, nos forms (GUIWindows e/ou Web) associados a transao Invoice, e assim poder visualizar os valores destes
atributos em tempo de execuo.
Ditos atributos, como temos explicado, no ficam armazenados na tabela INVOICE, nem na tabela
INVOICEDETAIL; por exemplo, em tempo de execuo quando o usurio ingressa atravs de
algum dos forms (GUI-Windows e/ou Web) um valor de CustomerId (atributo que armazenar na
tabela INVOICE sendo chave estrangeira), a continuao mostrar CustomerName
correspondente. Dizemos que o atributo CustomerName um atributo inferido na transao
"Invoice", j que seu valor no est armazenado em nenhuma das tabelas associadas a mesma,
mas sim que se infere isto , se obtm - da tabela CUSTOMER, dado o valor do atributo
CustomerId.
38

Analogamente, os atributos ProductDescription e ProductPrice tambm so inferidos na transao

Invoice, j que no se encontram armazenados nas tabelas associadas mesma, mas sim que seus
valores se inferem na tabela PRODUCT, para serem mostrados na tela.

38

39

A ARTech definiu um padro para a nomenclatura de atributos: o GeneXus Incremental Knowledge

Base (GIK) que utilizado pela comunidade de usurios GeneXus.
Nesta nomenclatura, o nome de um atributo se forma com 4 componentes (alguns opcionais,
assinalados entre parnteses retos):
Componente de Entidade + Categoria [+ Qualificador + Complemento] 1
Posteriormente descrevemos em que consiste cada componente:
Componente de Entidade (ou Objeto): uma Entidade um ator (ex: Customer), o objeto evento (ex:
VendorInvoice, Fatura de Venda) que intervm em uma dada aplicao, representado por uma
transao GeneXus. Um Componente de Entidade representa qualquer nvel subordinado ou
paralelo que defina a entidade.
Exemplo: A fatura tem os seguintes componentes, Invoice (cabealho), InvoiceDetail (linhas da
fatura).
Se sugere um tamanho de 10 caracteres para representar o componente da Entidade.
Categoria: a Categoria semntica do atributo que define o rol que o mesmo assume dentro do
objeto e dentro do ambiente da aplicao. Sugere que no ultrapasse os 10 caracteres.
Exemplos: Id (identificador), Code (cdigo), Name (nome), Date (data), Description (descrio), Price
(preo), Stock (estoque).
__________________________________________________________________________________________
1 Para pases que utilizem lnguas nas quais os adjetivos so colocados depois do substantivo. Em ingls ao
contrrio, por isso a categoria (ou substantivo) vai no final.

40

2 Ou

um conjunto de Transaes paralelas e/ou subordinadas, que falaremos mais adiante.

40

Qualificador: qualquer adjetivo ou advrbio, de 10 caracteres,

conceitual ao nome do atributo para que o torne nico.

que agregue diferenciao

Em geral refere ao texto que qualifica a categoria: Data de Vencimento.

Exemplos: Start (inicial), End (final), Due (vencimento)
Complemento: Texto livre at completar a quantidade de caracteres significativos (30) para o nome.
No slide se mostram alguns exemplos de nomes de atributos.
Nota 1: As letras maisculas permitem estabelecer fronteiras entre os componentes que formam os
nomes dos atributos.
Nota 2: Para cada componente se podem utilizar a quantidade de caracteres desejada, ainda se
sugere utilizar 10 e que o nome completo no seja superior a 30.

41

42

Para definir um atributo, simplesmente deve-se digitar no primeiro campo de uma linha (ou ramo) da estrutura, o
nome do atributo que se deseja criar. Mediante a tecla de tabulao pode-se passar aos seguintes campos para
indicar o tipo de dados do atributo, assim como sua descrio, e no caso que o mesmo venha a ser uma frmula
(conceito que veremos em breve), como calcul-la. Com a tecla Enter pode-se passar a seguinte linha, para definir
outro atributo.
Uma vez definidos os atributos na estrutura da transao, somente restar guardar/salvar as mudanas.
Caso necessite modificar o nome de um atributo, seu tipo de dados, descrio, nulabilidade, ou frmula, bastar
dar um duplo clique sobre o campo desejado, e o mesmo habilitado e pode ser editado. Aps as alteraes as
mudanas precisam ser salvas novamente.
Para indicar que um ou mais atributos so identificadores na transao, deve-se selecion-los e pressionar
CTRL+K; aparecero com um smbolo de chaves.
Para definir o incio de outro nvel na transao, deve-se digitar CTRL+L, e automaticamente se produz uma
endentao e o usurio dever dar um nome a esse nvel, assim, como definir o nome de seu tipo de dado e uma
descrio para o nvel.
Para indicar que um atributo de um dos nveis da transao ser o atributo descriptor, deve-se selecion-lo e
clicar CTRL +D.
GeneXus possui menus pop-up, que so menus que se abrem quando o usurio est posicionado em
determinado contexto e fazendo click com boto direito do mouse. Por exemplo, ao clicar com o boto direito do
mouse sobre um atributo da estrutura, abre-se um menu pop-up sobre o atributo selecionado, que oferece
varias utilidades, como por exemplo indicar que o atributo chave (opo Toggle key), tira-lo da estrutura,
pass-lo a um seguinte nvel de aninhao, etc.
Cada atributo contm propriedades. Algumas delas (as fundamentais e obrigatrias) so oferecidas diretamente
na estrutura para seu ingresso inline. Para acessar o dilogo que permite configurar todas as propriedades de
um atributo, deve-se selecionar o item Properties do menu contextual, ou pressionando a tecla F4. Na figura
alteramos a propriedade Autonumber que como veremos oportunamente, permite autonumerar atributos chave
primria.

___________________________________________________________________________________________
1 Veremos sua utilidade enquanto estudarmos os business components.
2 Tambm chamados contextuais visto que variam segundo o contexto.

43

Name: o nome do atributo. Utilizado para identific-lo.

Description: A Descrio ou mais propriamente Nome extenso uma definio ampliada do atributo. O atributo
deve ser bem identificvel com essa descrio, com independncia do contexto, e principalmente deve ser
entendvel pelo usurio final. Deve ser um identificador global do atributo, isto , no se deve atribuir dois atributos
na base de conhecimento com a mesma descrio, j que ser atravs desta descrio que o usurio final poder
selecionar atributos para definir suas prprias consultas na base de dados, com o GXQuery, executando relatrios
dinmicos (tema bastante simples, mas que no ser abordado neste curso).

Relacionadas a esta propriedade, esto s propriedades Title, Column Title e Contextual Title. As 2 primeiras por
default tem o mesmo valor especificado no Description, podendo ser modificado.
Title: A descrio aqui inserida colocada por default ao lado do atributo, cada vez que se utilize em sadas
planas como, por exemplo: no primeiro nvel dos forms das transaes (veremos em breve os forms).
Column Title: A descrio aqui inserida por default como o ttulo do atributo, cada vez que for includo na coluna
de um grid.
(no caso de uma transao somente se trata de um atributo inferido, como por exemplo o atributo
ProductDescription na transao Invoice)1.
Contextual Title: Quando o atributo pertence ao segundo nvel de uma transao, e no inferido (exemplo
InvoiceDetailQuantity em Invoice), o nome da coluna do grid da transao pega desta propriedade. Observe que
por default se pega da propriedade Description, mas tirando o nome da transao, pois assume o contexto.
Type Definition

Based on: Permite associar um domnio ao atributo. Ao atribuir um domnio a um atributo, certas
propriedades do atributo so desabilitadas (como por exemplo, Data Type e Length) tomando os valores do
domnio. Em caso do atributo no pertencer a um domnio, o programador deixar o valor (none) nesta
propriedade, e as propriedades correspondentes ao tipo de dados do atributo estaro habilitadas para serem
ingressadas.
Data Type: Permite indicar o tipo de dados do atributo, onde escolhido um dos tipos de dados
suportados pelo GeneXus. Dependendo do tipo de dados selecionados, haver certas propriedades, ou outras,
para configurar.
Length: Permite indicar o tamanho do atributo. Se na propriedade Data Type indica que o
atributo numrico, ento, dever ser considerado que o tamanho inclui as posies decimais, o
ponto decimal o sinal. Esta propriedade estar desabilitada quando o tipo de dados escolhido requer estabelecer
um tamanho (por exemplo, quando trata do tipo de dados Date).
Decimals: Se na propriedade Data Type indica que o atributo numrico, esta propriedade
oferecida, para especificar a quantidade de decimais. O valor 0 neste campo, indica que trata de um inteiro.
Signed: Se na propriedade Data Type se indica que o atributo numrico, esta propriedade
oferecida, para indicar se tem sinal ou no. O valor por default False, o que indica que no
sero
representados valores negativos.
Validation
Value Range: Permite indicar uma faixa de valores vlidos para o atributo. Por exemplo:
1:20 30:
- significa que os valores vlidos so entre 1 e 20; e 30 ou maior.
1234
- significa que os valores vlidos so 1, 2, 3 o 4.
'S' 'N'
- significa que os valores vlidos so 'S' ou 'N'.
Picture: Permite indicar o formato de edio para a entrada e sada do atributo. Dependendo do
tipo de dados do atributo, determinadas propriedades abaixo desta classe so disponibilizadas.
GeneXus fornece mais propriedades para os atributos que as mencionadas; dependendo do valor que se escolhe
para determinada propriedade, so disponibilizadas certas propriedades relacionadas ou outras. recomendvel a
leitura de todas as outras propriedades e no somente estas, acessando o Help do GeneXus.
______________________________________________________________________________________________________
1 O atributo tambm pode estar num objeto objeto Web Panel. Nesse caso, de aparecer como coluna, sempre ser oferecido por
default para o nome da mesma o de sua propriedade Column Title.
2 Os domnios sero abordados mais adiante no curso, mas em resumo, o objetivo dos domnios realizar definies de dados
genricos. Por exemplo: pode-se definir um domnio de nome Price e tipo de dados Numeric(10,2) e depois associar este
domnio para todos os atributos que armazenam preos. Tem a vantagem que se depois desejar modific-lo por exemplo para
Numeric(12,2), tem que modificar somente a definio do domnio e automaticamente todos os atributos baseados nesse
domnio herdam essa mudana.

44

Control Info
Um atributo pode associar um tipo de controle. Os possveis tipos de controles so:
- Edit
- Radio Button
- Check Box

- Combo Box
- List Box
- Dynamic Combo Box
- Dynamic List Box
A associao de certo tipo de controle de um atributo, serve para especificar o tipo de controle por default que ser
usado pelo atributo, cada vez que for includo em um form.
Quando um atributo definido com um tipo de dados bsico, o tipo de controle associado a ele o Edit, podendo
ser alterado pelo programador para qualquer um dos outros tipos. Em geral GeneXus escolhe o tipo de controle
para um atributo dependendo de seu tipo de dados. Se um domnio enumerado, como veremos, escolher Radio
Button ou Combo Box, dependendo da quantidade de valores de domnio.
No grupo Control Info do dilogo de edio das propriedades de um atributo, onde o programador pode mudar o
tipo de controle associado ao atributo e e dependendo do tipo de controle escolhido, uma informao distinta pode
ser solicitada.
Cada vez que um atributo agregado em um form, apresentar automaticamente com o tipo de controle que tenha
associado.
Nota
No caso de associar ao atributo o tipo Edit, poder especificar que disfarce seus valores, mostrando os de outro
atributo (propriedade InputType), e incluso que sugira os valores possveis ao usurio, a medida que este vai
digitando (propriedade Suggest), entre outras, como veremos depois, quando estudarmos Descries ao invs de
cdigos.
Tambm se pode escolher a cor da fonte da letra que se deseja associar por default ao atributo, assim como a cor
de fundo, de modo que cada vez que se agregue o atributo em um form, se apresente automaticamente com as
cores que ele tenha associado (ver grupo Appearance).

45

 Numeric: Permite armazenar dados numricos. Quando se seleciona este tipo de dados se deve

indicar a quantidade total de dgitos do nmero, a quantidade de posies decimais, e se permite

sinal ou no.
Exemplo:
Se definimos que o tipo de dados do atributo InvoiceAmount numrico de tamanho 10, com
decimais 2, e sem sinal, estamos especificando que representar nmeros com at 7 dgitos na parte
inteira e 2 decimais (7 dgitos na parte inteira + ponto + 2 dgitos para os decimais = 10 dgitos).
Character: Permite armazenar qualquer tipo de texto (caracteres e dgitos). Para este tipo de
dados, deve ser indicado o tamanho.

Exemplo: O atributo CustomerName que utilizamos para armazenar o nome de um cliente, de tipo
Character e sabemos que nunca um nome ter mais de 20 caracteres, podemos fixar o tamanho: 20.
Date: Permite armazenar uma data.

Exemplo: O atributo InvoiceDate que utilizamos para armazenar a data de uma fatura, ser deste tipo
de dados.
O formato a utilizar para as data (dia-ms-ano, ms-dia-ano), se configura em forma genrica para
todo o modelo dentro de um tipo especial de objeto, o objeto Language correspondente a linguagem
que vai ser gerado o modelo. O objeto language existe para poder ter uma mesma aplicao
traduzida em qualquer linguagem.
A escolha de apresentar o ano com 2 dgitos ou 4, se configura com a propriedade Picture de cada
atributo.
Boolean: permite que um atributo ou varivel assuma os valores lgicos: True, False.

46

 VarChar: Permite armazenar texto de tamanho varivel. Sua funo, em contraposio ao Character,
otimizar o armazenamento na base de dados.
Quando o tipo de dados Varchar selecionado no dilogo de definio do atributo se acrescentam as 2
propriedades seguintes: Maximum Length e Avarage Length.
A primeira para indicar o tamanho mximo de caracteres que podero armazenar, enquanto que a segunda
para indicar o tamanho mdio de caracteres que se vai armazenar pelo geral.
Exemplo: Quando se define um atributo do tipo Character e tamanho 60, se inserimos um dado que ocupa 25
caracteres, a capacidade restante de armazenamento do atributo (35 caracteres), se completa com brancos.
O tipo de dados Varchar, aperfeioa o armazenamento da seguinte forma: se definir Avarage Length (por
exemplo: 25), e Maximum Length (por exemplo: 60); ento, se o dado tem tamanho menor ou igual que 25,
fica armazenado no campo (se completa brancos), exceto nos casos em que o dado seja de tamanho maior
que 25, quando ficam armazenados os primeiros 25 caracteres no campo, e o resto em um rea de overflow.
Em contrapartida a vantagem de otimizao do armazenamento, para os casos que se utilize a rea de
overflow, ser necessrio realizar um acesso adicional tanto para a leitura como para a gravao do dado.
O tipo de dados Varchar equivalente ao tipo Character em todos os sentidos, exceto na forma em que
armazena os caracteres na base de dados. Podem ser aplicadas todas as funes e operadores existentes
para o tipo de dados Character. Se o DBMS no suporta este tipo de dados, se criar o atributo do tipo
Character.
Long Varchar: Permite definir um atributo memo; isto , normalmente utilizado para armazenar textos
grandes, comentrios, etc. Ao selecionar este tipo de dados deve-se indicar um tamanho mximo de
caracteres.
Existem duas funes para manipular este tipo de dados: GXMLines e GXGetMLi.
GXMLines retorna a quantidade de linhas que tem um atributo Long Varchar, tendo como parmetro o nome
do atributo, e a quantidade de caracteres que se deseja considerar por linha.
Exemplo: &cantlin = GXMLines( AtribMemo, 40 ).
O GXGetMLi por sua vez, extrai uma linha do atributo Long Varchar (para depois imprimi-la, por exemplo),
tendo como parmetro o nome do atributo, o nmero da linha desejado, e a quantidade de caracteres que
deseja considerar por linha.
Exemplo: &txt = GXGetMLi( AtribMemo, 1, 40 ).
Geralmente estas 2 funes so usadas combinadas, j que primeiro consulta a quantidade de linhas que tem
certo atributo Long Varchar, indicando a quantidade desejada de caracteres por linha, e depois prossegue
extraindo o contedo das linhas, utilizando um loop at chegar ltima linha, e desta forma eles so
impressos, por exemplo.
DateTime: Permite armazenar uma combinao de data e hora.
A propriedade Picture deste tipo de dados, permite escolher o que desejamos mostrar sobre a data, e o que
desejamos mostrar sobre a hora.
Referente a data podemos escolher entre: no mud-la, mud-la e apresentar o ano com 2 dgitos, mud-la e
apresentar o ano com 4 dgitos. Referente a hora podemos escolher entre: mudar somente 2 dgitos para a
hora (no administrando minutos nem segundos), mudar 2 dgitos para a hora e 2 dgitos para os minutos (no
administrando segundos), mudar 2 dgitos para a hora, 2 dgitos para os minutos e 2 dgitos para os segundos.
Os valores antes mencionados no afetam a forma de armazenar o tipo de dados, caso no seja especificado
a forma de aceitar ou mostrar seu contedo.
Nota: Em caso de no alterar a data, s a hora, o valor da data que ficar no campo ser o mnimo suportado
pelo DBMS, e ser reconhecido pelo GeneXus como data vazia ou nula. No que se diz respeito hora, os
valores no aceitados (minutos e/ou segundos) sero armazenados com valor zero.
Blob: As aplicaes requerem cada vez mais manter e trabalhar com este tipo de informao.
O tipo de dados Blob permite armazenar esta diversidade de informao na prpria base de dados,
aproveitando assim os diferentes mecanismos de integridade e controle fornecido pelos DBMSs.
Este tipo de dados somente pode ser utilizado quando se tem um DBMS.
Para aprofundar o conhecimento nesse tipo de dados entrar no Help GeneXus.

47

Para definir variveis em determinado objeto, deve selecionar o seletor Variveis, como se mostra na
figura.
Este seletor mostra variveis definidas por default (Standard variveis, como por exemplo a varivel
Today que contem a data do sistema) para o objeto, e permite definir variveis novas atravs de um editor
similar ao das transaes.

Tambm se pode ir a opo Insert do menubar e escolher Variables. No quadro de dilogo que se mostra
para selecionar New Varivel.

Este dilogo solicita o nome da varivel, sua descrio, tipo de dados e tamanho, o domnio, de forma
anloga quando se define um atributo.
48

A propriedade Dimensions permite indicar se a varivel ser escalar ou se tratar de um vetor (1

dimenso) o matriz (2 dimenses). O valor que oferece por default esta propriedade escalar.

48

Based On
Oferece uma forma rpida de definir uma varivel. Quando se seleciona, se mostra um dilogo que mostra todos
os atributos (e domnios) definidos na base de conhecimento; em dito dilogo, simplesmente se deve selecionar um
atributo, e em seguida se defini automaticamente uma varivel com o mesmo nome e a mesma definio que o
atributo. Vale declarar que se podem selecionar vrios atributos, criando nesse caso uma varivel para cada
atributo selecionado, com suas mesmas caractersticas.

Por outra lado, possvel definir variveis dentro do editor de cdigo de cada objeto (source, eventos, etc.),
fazendo uso do menu contextual (boto direito) depois de escrever o nome da varivel. Isto , ao escrever
&nomeDeVariavel (ex: &x) e pressionar boto direito do mouse. No menu contextual depois escolher Add Varivel.
Variveis coleo
possvel definir variveis coleo sobre qualquer tipo de dados oferecido por GeneXus.
Para isso basta clicar na correspondente casinha no editor de variveis, ou indicar o valor True na propriedade
Collection associada as variveis.
Para percorrer depois os itens colecionados em dita varivel, se deve utilizar a estrutura de controle For in.
Por exemplo, temos definido a varivel &myNumbers de tipo Numeric(4.0)
Para percorrer os valores armazenados se dever criar uma nova varivel de tipo Numeric (4.0). Criamos ento a
varivel &OneNumber, e declaramos:
For &OneNumber in &myNumbers
---------Endfor

49

 comum ter numa base de conhecimento atributos que compartilhem definies similares, mas que no
tenham nenhuma relao entre si. Por exemplo, comum definir todos os nomes, como atributos do tipo
character e tamanho 20; ou todos os valores, como atributos do tipo numrico e tamanho 10.2.
O objetivo dos domnios permitir realizar definies genricas. Como exemplo, o atributo
InvoiceDetailAmount do tipo numrico e tamanho 10.2, assim como o atributo ProductPrice que do
mesmo tipo e tamanho, na mesma base de conhecimento. Desse modo, podemos definir um domnio de
nome Price, que seja do tipo numrico com tamanho 10.2, e a cada um dos atributos mencionados atribuir o
domnio valores Price. A vantagem de faz-lo assim, que se no futuro surgir a necessidade de mudar a
definio dos atributos que representam valores, a mudana realizada uma nica vez (no domnio Price),
propagando-se este automaticamente aos atributos InvoiceDetailAmount e ProductPrice.

50

Existe a possibilidade de trabalhar com domnios enumerados (aqueles que representam valores finitos e
particulares). Nas linguagens de programao so bem conhecidos. O caso tpico de uso para os dias da
semana, quando se precisa que uma varivel tenha um dos seguintes valores: Segunda-feira, Tera-feira,
Quarta-feira, Quinta-feira, Sexta-feira, Sbado, Domingo.
Em nosso caso, vamos adicionar estrutura da transao Customer um atributo que representa o estado
do cliente no sistema num determinado momento. Pode estar active, on hold ou closed.
Uma forma de represent-lo definindo um domnio Status, que corresponde ao tipo de dados
Character(1) mas para o qual explicitamente dizemos que no queremos que possa ter todos os valores
desse tipo de dados, mas apenas 3: A, H e C, e dizemos tambm que queremos trabalhar dando nomes a
estes 3 valores e trabalhar com seus nomes. Assim, ao A associamos o nome Active, ao H OnHold e ao
C Closed.
Associando ao atributo CustomerStatus o domnio Status (observar que, devido terminao do nome do
atributo, ao inserir o atributo na estrutura depois de ter definido o domnio isto automaticamente
sugerido pelo GeneXus) no atributo da tabela internamente guardar um dos 3 valores: A, H ou C, porm,
ns no teremos de lembrar esses valores, mas sim seus cdigos: Active, OnHold e Closed.
J tnhamos outro atributo com domnio enumerado: CustomerGender. Nesse caso, possua apenas 2
valores: Female e Male.
Observar como o Control Info oferece para o ControlType um Combo Box ao invs de um Edit. Isto far
sentido quando vermos o Form de uma transao um pouco mais adiante.

51

Assim como o domnio pode ser associado a um atributo (e a outro domnio), da mesma forma pode ser
associado a uma varivel. Um mesmo domnio pode ser referido tanto a atributos como a variveis, j que o
objetivo exatamente o o mesmo.
Como definir um domnio?
Existem vrios caminhos:
1) Opo Domains do Folder View: Mediante um editor similar ao das variveis, pode ser definido um novo
domnio.
2) Visto que na tela de configurao das propriedades de um atributo onde se atribui a um atributo um
domnio existente, em dita tela se oferece um boto para criar um domnio novo. Idem com o dilogo de
definio de variveis.
3) Na estrutura da transao possvel definir um novo domnio no campo de definio do tipo de dados de
um atributo, simplesmente escrevendo sobre essa mesma linha, o nome do domnio, e atribuindo o tipo de
dados. Por exemplo, digitando Price = Numeric(10.2) sobre a coluna Type do atributo que se est definindo,
fica tambm definido o domnio de nome Price, com o tipo de dados Numeric(10.2).

52

Para cada transao, GeneXus cria um form web, que ser a interface com o usurio.
criado por default por GeneXus ao momento de gravar a estrutura da transao, e contem todos os
atributos includos na mesma, com suas respectivas descries, alm de alguns botes.
Se bem criado por default, possvel modific-lo para deix-lo mais vistoso, mudar por exemplo
controles de tipo edit a outros tipos de controles, agregar e/ou tirar botes, etc.

53

No exemplo que se mostra o form Web correspondente a transao Invoice. Atravs deste form o usurio
final poder ingressar, modificar e eliminar faturas na aplicao Web.

O controle Error Viewer se utiliza para poder colocar e programar no lugar onde queremos que as
mensagens gerais sejam mostradas ao usurio final de uma transao Web.
Poderemos especificar entre outras coisas o lugar onde queremos que este controle esteja dentro do form,
seu tipo de letra, cor, etc..
Observe que o segundo nvel da transao aparece no form como um control grid.

54

55

Podemos definir um controle como uma rea da interface com o usurio, que tem uma forma e um
comportamento determinado.
Existem diferentes controles:
- Texto: Permite colocar texto fixo
- Atributo/Varivel: Permite colocar atributos ou variveis.
- Linha horizontal
- Error Viewer
- Tabela: Inserir tabelas no form
- Grid: Permite definir grids de dados.

- Boto: Permite incluir botes nos forms.

- Bitmap: Permite definir bitmaps estticos, etc.
Paleta de ferramentas para inserir controles: Quando se est editando um form, se encontra disponvel
uma paleta de ferramentas (Toolbox) que oferece os controles possveis de inserir no mesmo.
Simplesmente se deve selecionar o controle e arrast-lo sobre o form.

56

Para separar os aspectos de desenho grfico de um site web, dos aspectos de programao
propriamente dito, existe um tipo de objeto chamado Theme (Tema em portugus).
O objetivo desta separao paralelizar o desenvolvimento de um site Web, permitindo ao
programador aproximar-se das tarefas de programao, e apoiar-se em um design grfico para que
defina as questes de desenho. Desta maneira o design grfico configurar o tema escolhido pelo
programador, e o programador somente dever aplic-lo aos objetos de sua base de conhecimento.
Um objeto tema conter um conjunto de classes, para cada tipo de controle dos que podem aparecer
no form Web de um objeto GeneXus. Por exemplo, ter vrias classes para o controle boto, algumas
para o controle atributo, uma classe para o controle Error Viewer, etc.
Quando se cria uma base de conhecimento, automaticamente aparecer dentro do Folder View da
pasta Customazation com objetos Theme prdefinidos que podero ser importados na KB. Por
default se importa o de nome Genexus X. Este tema contem um conjunto de classes associadas aos
diferentes controles existentes.
Os objetos com form Web que vo sendo criados tero por default associado este Theme, e cada
controle que aparea em seus forms ter associado uma classe desse tema, para este controle.

57

Deste modo, quando o analista cria a transao "Customer e informa sua estrutura, ao grav-la
pode ver que o Form Web ter automaticamente o aspecto mostrado na tela acima esquerda.
Quem deu o formato a todos os controles se no foi o analista exatamente?
Pois bem, todas as transaes tero associado por default o tema GeneXus X e todos os controle
colocados no form, tero classes deste tema associadas.
Se sobre o Text Bloxk (controle de texto) mostrado acima (Name), se editam suas propriedades (F4),
pode-se observar a propriedade Class, que tem configurada a classe TextBlock. Esta propriedade
pode ser mudada pelo analista. Ao clicar o combo box poderemos ver uma lista de classes possveis
para esse controle (so as as que figuram no tema associado). A direita mudamos a classe para
uma de nome Title e no form podemos ver a repercusso no desenho do TextBlock.
No entraremos em detalhe neste tema no presente curso.

58

Lembremos que no momento de criao da KB, se indicou o gerador por default a ser utilizado.
Agora deve completar a informao necessria para terminar de definir o ambiente de
implementao.
Database name: Nome da base de dados que estar associada a aplicao.
Server name: Nome do servidor da base de dados que a administra.
Use trusted connection: Yes
No (dever indicar o usurio e senha vlida no DBMS)
Consideraes:
Se a base de dados no existir, GeneXus a criar, sempre e quando o usurio e senha
configurados na janela de dilogo tenham permisso de DBCreator no DBMS.

59

Cada vez que se executa a aplicao (F5), GeneXus realiza uma comparao entre as definies atuais
de todos os objetos e as definies da ltima execuo. Esta comparao que o GeneXus faz, se chama
anlise de impacto. Este nome auto-descritivo: GeneXus analisa o impacto causado pelas novas
definies, e o resultado da anlise de impacto um relatrio de anlise de impacto (IAR: Impact
Analisis Report) que informa ao programador quais alteraes fsicas ou estruturais precisam ser
realizadas na base de dados associada.

Se por exemplo se criou uma nova transao, isto provocar (tal como o objetivo das transaes) que
se criam as tabelas correspondentes na base de dados (ver pgina seguinte).

60

No exemplo, criar as 2 transaes Customer e Invoice e dar F5, aparece o relatrio de anlise de
impacto que pode se ver, onde so listados entre outras coisas, a estrutura que ter cada tabela que ser
criada, com seus atributos, tipo de dados, os ndices que sero criados sobre as tabelas, as chaves
estrangeiras (observar que o relatrio da tabela INVOICE diz que se referenciar a tabela CUSTOMER
(isto acontece pelo atributo CustomerId da transao Invoice que se chama igual que o atributo
CustomerId de CUSTOMER, constituindo portanto uma chave estrangeira a dita tabela).
Se o programador est de acordo com os alteraes estruturais informadas no relatrio de anlise de
impacto, poder prosseguir, passando a reorganizar a base de dados. O trmino reorganizar refere a
efetuar alteraes fsicas na base de dados.
Se na alterao o programador encontra algo informado no relatrio de anlise de impacto no era o que
pretendia obter, poder no efetuar a reorganizao, e as redefinies convenientes so criadas.
Quando se decide efetuar uma reorganizao GeneXus gera programas (na linguagem escolhida
quando se criou a KB) que implementam as modificaes a serem realizadas na base de dados. A
execuo destes programas tem como resultado a obteno de uma nova verso da base de dados com
as alteraes efetuadas.

O seguinte passo ser obter os programas da aplicao associados aos objetos GeneXus. Para isso
GeneXus dever especificar, gerar e compilar os programas da aplicao.
Especificar um objeto significa que GeneXus analisar tudo o que foi definido em cada um dos
elementos que o compem: estrutura, forms, ou outros elementos segundo corresponda. GeneXus
verificar a sintaxe das definies, a validade do qu foi definido, e como resultado da especificao
mostrar ao usurio uma listagem de navegao, na qual informar a lgica interpretada, e se tem
alguma advertncia ou erro.
Gerar um objeto, significa que GeneXus escrever linhas de cdigo que implementem a programao do

61

mesmo, na linguagem escolhida.

Compilar os programas significa que o cdigo escrito (gerado) seja convertido a linguagem de mquina
(binrio) para que possam ser executados.

61

62

Opes do item Build:

Build All e Rebuild All: Estas opes so utilizadas quando no se est seguro do impacto das
alteraes e se quer ter atualizadas as ltimas definies. A opo Build All realiza todas as aes que
estejam pendentes, enquanto que Rebuild All fora todas elas.
As aes so:
- Salvar todos os objetos que no estejam salvos.
- Reorganizar a base de dados, se for necessrio.
- Especificar somente os objetos que foram modificados (se selecionou Build All), ou
forar a especificao de todos (selecionou Rebuild All).
- Gerar os objetos
- Compilar os objetos definidos Main
- Compilar o Developer Menu

Build / Rebuild Developer Menu: Similar as opes anteriores mas aplicadas somente ao Developer
Menu. No o executa.
Run Developer Menu: Executa todas as aes que estejam pendentes e executa o Developer Menu.
- Salva todos os objetos que no estejam salvos.
- Reorganiz-la a base de dados, se for necessrio.
- Especifica somente os objetos que foram modificados.
- Gera os objetos.
- Compila e executa o Developer Menu.

63

 Build / Rebuild / Run options: Opes aplicadas a objetos definidos como Main. Disparam as seguintes
aes:
- Salvam os objetos que no estejam salvos.
- Reorganizao a base de dados, se for necessrio.
- So especificados somente os objetos que sofrerem alteraes (se selecionou Build), ou
se
fora a especificao de todos os objetos pertencentes a rvore de chamadas do objeto
Main (quando selecionado Rebuild).
- Gerao
- Compilao do objeto Main
- Execuo do objeto Main (quando selecionado a opo Run)

Build / Run with this only options: Build e execuo do objeto definido como Startup. Por default o
objeto Startup o Developer Menu.
- Salvam todos objetos que no estejam salvos.
- Reorganizao a base de dados, se for necessrio.
- Especificam somente o objeto selecionado.
- Geram somente o objeto selecionado.
- Compilam o objeto Startup
- Se executa o objeto Startup (se selecionou Run).

Set As Startup Object: O objeto indicado passar a ser o objeto Startup da aplicao, ou seja o objeto
que finalmente se executa quando se pressione a tecla F5. Por default o objeto Startup o Developer
Menu.
Create Database Tables: Cria novamente as tabelas. Se perdem os dados que podero estar
armazenados previamente.
Impact Database Tables: Se realiza um impacto sobre as tabelas da base de dados.

64

Dependendo do ambiente de gerao, existem algumas diferenas referentes

operacionalidade das transaes em tempo de execuo. Diante da plataforma, cada vez que se
realize uma operao de insero, atualizao, eliminao, ou consulta da base de dados
atravs de uma transao, existem um modo associado.

65

Sempre vai mostrar um nmero de linhas vazias fixas para ser ingressadas pelo usurio (valor
configurvel pelo analista a nvel do grid, em sua propriedade Rows). Por default so
mostradas 5 linhas vazias.
Se o usurio ingressou as 5 linhas e necessita ingressar mais, bastar pressionar New Row, ou
simplesmente pressionar Enter e uma nova linha agregada.
Para poder eliminar linhas em execuo, GeneXus incorpora uma coluna do lado esquerdo do
grid, que aparece com uma cruz para cada linha inserida. Pressionando sobre a cruz, a linha
removida.

66

Ter um look&feel consistente hoje em dia um dever de toda aplicao Web.

Criar e manter cada pgina de uma aplicao Web assegurando a consistncia com o resto do site toma
grande tempo de programao.
Ao criar uma base de conhecimento GeneXus X cria tambm dois objetos de tipo Master Page:
AppMasterPage: Para a aplicao.

PromptMasterPage: Para os prompts.

As Master Pages fornecem uma forma de centralizar o layout e o comportamento comum em um objeto
somente e reutiliz-lo em qualquer outro objeto sem ter que programar. Isto significa que a modificao de
alguma parte do layout ou do comportamento comum to fcil como modificar em um nico objeto e
pronto!
Em uma mesma base de conhecimento podem ser definidas quantas Master Pages como se deseje.
Quando estudarmos o objeto Web Panel compreenderemos que uma Master Page ser em particular
uma Web Panel categorizado como Master Page com todo o Layout e comportamento comum a todas
as pginas do site, dentro deste objeto se deixa um espao para carregar em cada oportunidade a pgina
que corresponda (o contedo varivel do site). Isso se faz no controle presente no form de nome Content
Placeholder.

67

As pginas web que implementam o contedo varivel, se associam a Master Page, de maneira que cada vez que
sejam executadas, carreguem com esse contexto (o da Master Page).

68

Observe como depois de criar a transao Product GeneXus normaliza e indica graficamente na
estrutura da transao Invoice que os atributos, antes prprios da tabela INVOICEDETAIL, agora sero
inferidos, atravs da nova chave estrangeira ProductId.
A chave primria da tabela INVOICEDETAIL continua sendo composta: {InvoiceId, ProductId}, mas alm
disso, o atributo ProductId sozinho, ser uma FK na tabela PRODUCT, a partir da qual se inferem os
atributos ProductDescription e ProductPrice.
Depois do F5, naturalmente ser informado a necessidade de reorganizar a base de dados, criando a
tabela PRODUCT e modificando a tabela INVOICEDETAIL da maneira que indicamos nos pargrafos
anteriores.
O que acontece com os registros j existentes na tabela INVOICEDETAIL, para os que possuam valores
de ProductDescription e ProductPrice?
Como ser visto quando executar, o programa de reorganizao agrega uma rotina para criar os registros
de produtos na tabela PRODUCT com essa informao pr-existente. O que acontecer se existia o
mesmo produto em vrias linhas de diferentes faturas?

69

70

O conceito de integridade referencial um conceito que se refere s bases de dados relacionais.

Se refere que deve fazer a consistncia entre os dados das diferentes tabelas de uma base de
dados relacional.
As tabelas de uma base de dados relacional esto relacionadas por atributos que tem em comum.
Estas relaes implicam que os dados das tabelas no sejam independentes, mas que ao inserir,
modificar ou eliminar registros de uma tabela tem que ser levado em considerao os dados das
outras tabelas para que sempre se conserve a consistncia da informao na base de dados.
Se temos um modelo de dados relacional com as tabelas:
COUNTRY (CountryId, CountryName)
Chave Primria: CountryId
CUSTOMER (CustomerId, CustomerName, CustomerAddress, CustomerGender, CountryId)
Chave Primria: CustomerId
Chave Estrangeira: CountryId (COUNTRY)
O fato do atributo CountryId na tabela CUSTOMER ser uma chave estrangeira em relao a
tabela COUNTRY, estabelece uma relao entre ambas as tabelas. A relao entre elas pode ser
representada com o diagrama mostrado.
No Diagrama de Bachman, a seta simplesmente representa a existncia de uma instancia da
tabela mostrada, para cada instancia da outra (para cada cliente existe um e somente um pas). A
seta dupla representa a ocorrncia de vrias instncias da tabela apontada, para cada instancia
de outra tabela (para cada pas, existem muitos clientes).
Dizemos que a relao entre a tabela COUNTRY e a tabela CUSTOMER 1 de N (1 a muitos).

Reciprocamente, a relao entre CUSTOMER e COUNTRY N de 1 (muitos a 1).

71

Na terminologia GeneXus, dizemos que existe uma relao de subordinao entre ambas as
tabelas. Dizemos que:
COUNTRY est superordinada a CUSTOMER
CUSTOMER est subordinada a COUNTRY
Significando que:

Quando se cria ou modifica um registro na tabela subordinada (CUSTOMER), deve existir o

registro relacionado na tabela superordinada (COUNTRY).
Quando se elimina um registro na tabela superordinada (COUNTRY), no devem existir
registros relacionados na tabela subordinada (CUSTOMER).
Devido a esta relao entre as tabelas, a informao contida nelas no independente, e
necessrio realizar controles para que os dados sejam consistentes. A estes controles se chama
de Integridade Referencial e basicamente so os seguintes:
Quando se insere ou modifica um registro na tabela CUSTOMER, o valor ingressado no
atributo que chave estrangeira (CountryId), deve existir como valor de chave primria de um
registro na tabela COUNTRY.
Quando se elimina um registro na tabela COUNTRY, no devem existir registros na tabela
CUSTOMER cujos valores da chave estrangeira (CountryId), sejam iguais ao valor da chave
primria do registro que se deseja eliminar.
GeneXus gera os programas associados as transaes, incluindo no cdigo gerado estes
controles de Integridade Referencial. Por esta razo, se o usurio final insere (ou modifica) um
cliente atravs da transao "Customer", validado automaticamente que o valor ingressado no
cdigo de pas CountryId, exista como chave primria de um registro na tabela COUNTRY. Em
caso de falhar este controle de integridade referencial, uma mensagem mostrada ao usurio
indicando que no se encontrou esse pas.

72

Os ndices so vias de acesso eficientes as tabelas.

GeneXus cria automaticamente alguns deles, e outros devero ser criados pelo programador quando
este assim o determine, baseando-se em critrios de otimizao.
Existem quatro tipos de ndices em GeneXus:
Primrios
Estrangeiros
De usurio
Temporrios
De todos eles, os nicos que no so criados automaticamente por GeneXus so os de usurio.
Enquanto aos tipos de ndices que so criados por GeneXus, a diferena que existe entre eles o
momento em que so criados e o tempo durante o qual se mantm.
- Os ndices primrios e estrangeiros so criados no momento de criar ou reorganizar as tabelas
que compem a base de dados, e depois so mantidos automaticamente por GeneXus.
- Os ndices temporrios, por sua vez, so criados ao executar as aplicaes, para acessar a
tabelas ordenadas por algum atributo ou conjunto de atributos para ele/eles que no existe um
ndice de usurio criado; estes se criam em tempo de execuo das aplicaes, so utilizados e
depois so eliminados.
NDICES PRIMRIOS E ESTRANGEIROS
GeneXus cria para cada tabela um ndice por sua chave primria (ndice primrio), e um ndice por cada
chave estrangeira que a tabela tenha (ndices estrangeiros). Por que criar ndices primrios e
estrangeiros para as tabelas no incio de forma automtica, sendo que depois devem ser mantidos?
Sejam as tabelas COUNTRY e CUSTOMER, que vimos um par de pginas atrs, criadas em nosso
modelo de dados a partir das estruturas das transaes "Country" e "Customer. Existe entre estas
tabelas uma relao 1-N, que ocorre pelo fato de que o atributo CountryId na tabela CUSTOMER uma
chave estrangeira com respeito a tabela COUNTRY.
73

Por existir esta relao, o GeneXus inclui nos programas associados s transaes "Country" e
"Customer", os controles de integridade referencial pertinentes. Estes controles so:
Se o usurio final insere ou modifica um cliente atravs da transao "Customer", ser validado
automaticamente assim que o valor ingressado na chave estrangeira CountryId exista como chave
primria de um registro na tabela COUNTRY. Caso o controle de integridade referencial falhe
indicado ao usurio que no foi encontrado este pas. Para controlar isto, deve-se buscar na tabela
COUNTRY a existncia de um registro que tenha esse valor de CountryId como chave primria;
devemos consultar a tabela COUNTRY, buscando pela chave primria, sendo que, a busca pode ser
otimizada se existir um ndice pela chave primria em dita tabela.
Se o usurio final tentar eliminar um pas atravs da transao "Country" validado
automaticamente que no existam clientes no pas atribudo com chave estrangeira; em caso de
encontrar um registro na tabela CUSTOMER, cujo valor de chave estrangeira CountryId seja o que
se deseja eliminar, ser indicado ao usurio que no possvel eliminar o pas (j que do contrrio
ficariam dados inconsistentes na base de dados).
Para controlar isto, devemos consultar a tabela CUSTOMER, buscando pela chave estrangeira
CountryId. Esta busca ser otimizada se existir um ndice por CountryId na mesma.

Controle de unicidade de chave primria

Outro controle que o GeneXus tambm inclui nos programas associados s transaes a unicidade
da Chave Primria; isto , em nenhuma tabela podero existir dois registros com o mesmo valor na
Chave Primria.
Para controlar isto, quando o usurio final tentar inserir um registro, validado automaticamente que
o valor ingressado para a Chave Primria, no exista como Chave Primria de outro registro na
tabela.
Para fazer esta busca com eficincia, devemos utilizar o ndice primrio da tabela.
Concluindo, o GeneXus ao criar cada tabela da base de dados, cria tambm seu ndice primrio, e
um ndice estrangeiro por cada Chave Estrangeira que a tabela contenha.
A criao destes ndices permite realizar os controles de integridade referencial e de

74

unicidade de chave primria acessando as tabelas de forma eficiente.

74

ndices de usurio
Estes ndices devem ser definidos explicitamente pelo analista. No so definidos
automaticamente. Dividem-se em duplicate e unique:
Um ndice de usurio duplicate definido para atributos de uma tabela que possam ter vrios
registros com o mesmo valor nos mesmo (isto , se define para atributos que no so uma
chave candidata).
Este tipo de ndices se define fundamentalmente para acessar os dados ordenados por
determinados atributos de forma eficiente.
Por exemplo, supondo que o nome do cliente no chave na tabela de CUSTOMER (seus
valores podem se repetir) poderemos definir um ndice de usurio duplicate para o atributo
CustomerName, sendo muito til para realizar consultas e relatrios que necessitem que sejam
ordenados por nome.
Um ndice de usurio unique utilizado para especificar que um conjunto de atributos chave
candidata em uma tabela (diferente da chave primria).

Esta a forma de representar chaves candidatas no modelo de dados. Com isso conseguimos
que o GeneXus incorpore automaticamente o controle de unicidade correspondente nas
transaes associadas.
Por exemplo, se o nome do cliente no pode ser repetido, a forma de represent-lo e fazer com
que o GeneXus o controle automaticamente definindo na tabela CUSTOMER um ndice de
usurio unique pelo atributo CustomerName.

75

ndices unique (chaves candidatas)

Em uma tabela da base de dados podem existir vrios conjuntos de atributos cujos valores
sejam nicos na realidade. Dizemos que cada um desses conjuntos uma chave da tabela.
Depois, o analista escolhe uma das chaves como a chave primria. GeneXus identifica a chave
primria da tabela de acordo com os atributos que foram qualificados pelo analista com o
smbolo da chave.
Vamos supor que na realidade alm de poder identificar um cliente por seu cdigo ou possa ser
identificado por sua carteira de identidade. Neste caso tanto o atributo CustomerId como o
atributo CustomerSSN (armazena o Nro da Carteira de Identidade) seriam chaves da tabela
CUSTOMER. Ao indicar que CustomerId o identificador da transao, o GeneXus cria
automaticamente um ndice primrio para dito atributo e controla a unicidade dos valores
ingressados para o mesmo.
O que acontecer com a carteira de identidade do cliente? Ao ser este atributo chave, queremos
que o GeneXus garanta da mesma forma, no permitindo que seja inserido um registro, j
existindo outro com o mesmo valor da carteira de identidade (CustomerSSN). Para poder fazer
este controle de forma eficiente, o GeneXus deveria ter um ndice para cada atributo chave.

A forma de definir em GeneXus que um atributo ou um conjunto de atributos Chave alternativa

ou candidata e que para tanto deve-se checar sua unicidade, definindo um ndice de usurio
composto por esse atributo ou conjunto de atributos, e o qualificando como unique ao invs
de duplicate, que o valor por default de um ndice de usurio.
A partir da, GeneXus inclui na lgica da transao esse controle de unicidade utilizando esse
ndice definido pelo usurio.
Em resumo, as transaes GeneXus realizam automaticamente os seguintes controles:
. Integridade referencial
. Unicidade de chave (tanto primria como candidatas)
76

ndices temporrios
Quando se deseja acessar os dados ordenados por determinados atributos, mas no se deseja
criar um ndice permanente para ele (por exemplo, porque se trata de uma consulta que se
realiza com pouca frequncia), ento, dependendo da plataforma, um ndice temporrio
criado.

77

A permisso ou no do valor <NULL> na base de dados muito importante no modelo relacional.

Permitir o valor null para um atributo dado, significa que pode em certas circunstncias, ser
ignorado visto que valor no especificado. Por outro lado, o atributo no permitindo valor null,
um valor vlido deve sempre ser atribudo a ele.
A propriedade Nulls (apresentada como coluna no editor de estrutura de transaes), permite
configurar para cada atributo se admite ou no valor null na tabela associada. Os atributos que
podem ser configurados desta forma, so aqueles armazenados nas tabelas associadas na
transao (isto , no inferidos) sempre e quando no forem atributos primrios nestas tabelas (j
que por definio as chaves primrias no suportam valor null).
Resumindo: o objetivo desta propriedade definir qual valor vai ser armazenado na base de dados
quando no for digitado nada no campo (o valor <NULL> ou o valor empty).

78

Os valores possveis de serem configurados para essa propriedade Nulls so:

No: significa que o atributo no permite o valor null na tabela associada (valor por default)
Yes: significa que o atributo permite o valor null na tabela associada.
A definio de nulls utilizada por GeneXus no momento de criar/reorganizar as tabelas da base
de dados, j que o suporte ou no suporte de nulabilidade dos atributos em sua tabela, se
define a nvel da base de dados.
Ou seja que modificar o valor da propriedade Nulls para um atributo vai implicar em executar
uma reorganizao (para redefinir a nvel da base de dados o suporte de nulabilidade do atributo
em sua tabela).

79

Repercusso em controles de integridade referencial

A definio de nulls para atributos que formam uma chave estrangeira diz ao GeneXus quo
forte a referncia a outra tabela.
Se nenhuns dos atributos que compem uma chave estrangeira permitem valores nulos
(caso 1), trata-se de uma referncia forte (tambm conhecida como not null reference), j
que estabelecido que a FK dever sempre apontar a um registro existente da tabela
referenciada.
Outro caso, se uma chave estrangeira que tenha pelo menos um atributo que suporte
nulos (caso 2), se estabelece uma referncia fraca (tambm conhecida como null
reference), j que se algum dos atributos que formam parte da chave estrangeira so nulls,
ento a referncia no ser checada.
Quando uma chave estrangeira composta e os nulos so permitidos para alguns de seus
atributos, podem aparecer novas referencias (no checadas caso possua referncias fortes)
se os atributos restantes compem tambm uma chave estrangeira. Um exemplo o
apresentado acima, onde se o usurio deixar nulo o valor de CityId para um cliente, se
realizar a checagem de IR contra COUNTRY, para assegurar que o pas ingressado esteja
correto.

80

Mtodos para trabalhar com nulos e vazios

IsEmpty, IsNull: devolvem true quando o atributo contem valor empty ou null respectivamente.

SetEmpty, SetNull: configuram no atributo o valor empty ou null, respectivamente.

Exemplos:
* error(You must specify a name) if CustomerName.IsEmpty();
* msg(Warning: You didnt specify a Country) if ContryId.IsNull();

81

82

Os critrios de normalizao do desenho da base de dados servem para minimizar a

possibilidade de inconsistncia dos dados. Uma base de dados desenhada desta maneira tem
uma srie de vantagens importantes (tanto assim que atualmente a normalizao de dados
um padro de desenho), mas que deve ser considerado tambm alguns inconvenientes.
O inconveniente mais notrio que os dados se encontram dispersos em muitas tabelas, e
muitas vezes quando se quer realizar consultas mais ou menos complexas base de dados,
devemos consultar uma quantidade importante de tabelas.
Assim, por exemplo, se o seguinte Diagrama representa nosso modelo de dados:

para listar as faturas seria necessrio consultar as tabelas: INVOICE e INVOICEDETAIL (linhas
de faturas), CUSTOMER, COUNTRY e PRODUCT.
Para simplificar esta tarefa GeneXus utiliza o conceito de tabela estendida.
Chamamos tabela base a qualquer tabela da base de dados na qual estamos posicionados em
determinado momento; e dada certa tabela base, sua tabela estendida alcanar todos os
atributos da prpria tabela base, mas todos os atributos das tabelas que tenham informao
relacionada unicamente com a tabela base (relao N-1 desde a tabela base, direta e
indiretamente).

83

Utilizando o diagrama fcil determinar qual a tabela estendida correspondente a uma tabela
base qualquer:
Partindo da tabela base, devem-se seguir as relaes N-1 (devem-se seguir as setas que tem
ponta dupla partindo da tabela base e ponta simples no outro extremo).
Todas as tabelas as quais se pode chegar seguindo as setas que representam relaes N-1 da
tabela base, formaram parte de sua tabela estendida.

O seguinte quadro mostra a tabela estendida correspondente a cada uma das tabelas de nosso
modelo de dados:

84

No objeto transao as regras cumprem um rol muito importante, j que permitem programar seu
comportamento (por exemplo: atribuir valores por default, definir controles sobre os dados, etc.).
So escritas de forma declarativa, ou seja, a ordem em que se escreve no significa a ordem de
execuo.
Podem envolver os atributos definidos na estrutura da transao, assim como as variveis
definidas dentro do objeto, constantes e funes.
Somente so vlidas dentro da transao na qual esto definidas, ou seja, so locais.

_______________________________________________________________________________________
1 Todas as regras das transaes podem utilizar atributos das tabelas base associadas a transao; e a
maior parte delas pode tambm utilizar atributos das tabelas estendidas de ditas tabelas base.

85

Algumas regras vlidas para transao so:

Default
OBJETIVO: Permite atribuir um valor por default para um atributo ou varivel; o valor por default inicialiaza o
atributo ou a varivel quando est sendo realizada uma insero atravs da transao (modo Insert), mas o
usurio final pode alterar esse valor se no for o desejado.
SINTAXE: Default( att | &var, exp );
ONDE:
att: um atributo que pertence a alguma das tabelas base associadas na transao.
var: o nome de uma varivel.
exp: uma expresso que pode envolver constantes, funes, variveis ou outros atributos.
FUNCIONALIDADE: Esta regra atribui o valor da expresso exp como valor por default do atributo att ou varivel
var, quando a transao executada em modo Insert.
Esta regra no vlida para atributos que formam parte da chave primria de algum dos nveis da transao,
porque disparada logo que a chave informada (j que somente nesse momento o modo conhecido e esta
regra disparada somente em modo Insert
EXEMPLOS:
Default( InvoiceDate, &today );

/* Regra definida na transao Invoice */

Quando uma Invoice nova inserida, se sugere o valor de InvoiceDate o valor contido na varivel do sistema
&today.
Default( InvoiceDate, Today());

/* Regra definida na transao Invoice */

Anloga a anterior, a diferena que ao invs de utilizar a varivel do sistema today, se utiliza a funo Today
que devolve a data correspondente ao dia.
Default( InvoiceDetailAmount, ProductPrice*InvoiceDetailQuantity); /* Regra definida na transao Invoice */
Quando uma linha da fatura inserida, se sugere que o atributo InvoiceDetailAmount (valor da linha) receba o
valor resultante da expresso ProductPrice*InvoiceDetailQuantity (preo do produto vezes a quantidade levada do
mesmo).
Nota: O tipo de dados da expresso deve coincidir com o tipo de dados do atributo ou varivel.

Regra de atribuio
OBJETIVO: Permite atribuir a um atributo ou a uma varivel, o valor de uma expresso.
SINTAXE: att | &var = exp [if cond] [on evento / momento de disparo];
ONDE:
att:
um atributo que pertence alguma das tabelas base associadas a transao, ou a suas estendidas (deve
estar declarado na estrutura).
var: o nome de uma varivel.
exp: uma expresso que pode envolver constantes, funes, variveis ou outros atributos, e deve ser do
mesmo tipo que att ou var.
cond: uma expresso booleana (pode conter os operadores lgicos and, or, not)
evento/momento de disparo: um dos eventos predefinidos do GeneXus disponveis para regras de transaes,
que permitem definir o momento especfico de execuo de uma regra.
FUNCIONALIDADE: Uma regra deste tipo permite atribuir ao atributo ou varivel que fica a esquerda, o valor
resultante da expresso. Como se pode ver, a condio opcional; se ela no for definida, a atribuio realizada
sempre.
A atribuio a um atributo, implica sua atualizao no registro que corresponda. A atribuio a um atributo, implica
em sua atualizao no registro que corresponda. As regras de atribuio podem ser definidas aos atributos de
alguma das tabelas bases associadas a transao, incluso de suas estendidas. Isto significa que os atributos
inferidos podem ser atualizados em uma transao.

86

EXEMPLO:
InvoiceDetailAmount = ProductPrice * InvoiceDetailQuantity; /* Regra definida na transao Invoice */
Se o valor de cada linha de uma fatura calculado sempre multiplicando o preo do produto vezes a quantidade
levada do mesmo, podemos utilizar esta regra de atribuio para que o usurio no precise realizar o clculo.
Error
OBJETIVO: Permite mostrar uma mensagem de erro se a condio seja satisfeita. Serve para definir os controles que
os dados devem cumprir.
SINTAXE: Error( msg | &var | character expresion, msgId ) if cond [on evento/momento de disparo];
ONDE:
msg: uma string com uma mensagem de error a mostrar
var: o nome de uma varivel de tipo caractere, que contm uma string com uma mensagem de erro a mostrar
character expression: uma expresso cujo tipo resultante, caractere e que ser mostrada
msgId: uma string (sem espaos em branco nem aspas) que ser utilizado somente se a transao definida
tambm como business component1.
cond: tipo booleana (que pode conter os operadores lgicos and, or, not)
evento/momento de disparo: um dos eventos pr-definidos do GeneXus disponveis para regras de transaes, que
permitem definir o momento especfico da execuo de uma regra.
FUNCIONALIDADE: Esta regra mostra a mensagem do parmetro msg, var ou expresso caractere, se a condio
cond avaliada resulta como verdadeira. A mensagem de erro aparece em uma tela pop-up quando o ambiente de
trabalho Windows e no controle Error Viewer e/ou um quadro texto quando o ambiente de trabalho Web, detendo
qualquer atualizao na base de dados. Quando a transao executado como business component (estudaremos
este tema mais adiante), ao disparar o error, gera um entrada no SDT messages, com identificador msgId.
EXEMPLOS:
Error(Informe o Nome do Cliente) if CustomerName.isEmpty();
/*Regra definida na transao Customer*/
Se avalia a condio CustomerName.isEmpty(), e se for satisfeita, mostra a mensagem Informe o Nome do Cliente
na tela. No permite continuar at que o usurio ingresse um nome no campo CustomerName ou abandone a
transao (nesse caso no realizada nenhuma atualizao na base de dados).
Error(Fatura no pode ser eliminada) if Delete;
/* Regra definida em a transao Invoice */
Necessita proibir a eliminao de faturas. Com esta regra, se o usurio tentar realizar uma eliminao, a condio dar
True e se dispara a regra, evitando a eliminao.

Msg
OBJETIVO: Permite mostrar uma mensagem de advertncia se a condio for satisfeita
SINTAXE: Msg( msg | &var | character expresion, msgId) if cond [on evento/momento de disparo];
ONDE:
msg, var, character expresion, msgId, cond, evento/momento de disparo: so os mesmos que para a regra error.
Observar que a sintaxe exatamente a mesma.
FUNCIONALIDADE: Esta regra se utiliza para apresentar mensagens de advertncia ao usurio. Mostra a mensagem
do primeiro parmetro, se a condio satisfeita, analogamente a regra Error; mas a diferena desta ltima, permite
continuar com a execuo se a condio segue sendo satisfeita. Do mesmo modo, se a transao business
component1, se disparar a regra gera entrada no SDT messages.
As mensagens de advertncia so mostradas no Error Viewer.
_________________________________________________________________________________________________________
1 Este tema ser visto mais adiante no curso.

87

EXEMPLO:
Msg( Nome do Cliente no foi informado ) if CustomerName.isEmpty();
/*Regra definida na transao "Customer*/
Se avalia a condio CustomerName.isEmpty(), e se esta se satisfaz mostra-se a mensagem Nome do Cliente no foi
informado. A diferena que ocorre com a regra Error, que aqui permitido continuar a execuo, pois no se trata de
um erro e sim de uma advertncia.
Noaccept

OBJETIVO: Permite indicar que o atributo no aceite valores por parte do usurio (ser somente de sada).
SINTAXE: Noaccept(att) [if cond] [on evento/momento de disparo];
ONDE:
att: um atributo pertencente a alguma(s) da(s) tabela(s) base(s) associada(s) transao
cond: uma expresso booleana (pode conter os operadores lgicos and, or, not)
Evento/momento de disparo: um dos eventos predefinidos pelo GeneXus disponveis para regras de transaes, que
permitem definir o momento especfico de execuo de uma regra.
FUNCIONALIDADE: em uma transao, todos os atributos que pertencem as tabelas base associadas a transao, por
default so aceitos. Se quisermos que um atributo destas caractersticas no seja aceito, ento contamos com a regra
Noaccept.
EXEMPLO:
Noaccept( InvoiceDate) if Update; /* Regra definida na transao Invoice */
Se est modificando uma fatura (modo Update), no permitido que seja modificada sua data.
Subtract
OBJETIVO: Subtrai o valor de um atributo ao valor de outro atributo, se satisfaz a condio especificada.
SINTAXE: subtract(att1, att2) [if cond];
ONDE:
att1, att2: so atributos pertencentes a alguma das tabelas base associadas transao, ou a suas tabelas estendidas
(e devem estar declarados na estrutura).
cond:
uma expresso booleana (que pode conter os operadores lgicos and, or, not).
FUNCIONALIDADE: A subtrao realizada levando em considerao o modo que se esteja trabalhando na transao
(Insert, Update ou Delete).
Em modo:
- Insert: subtrai o valor do atributo att2, o valor do atributo att1
- Delete: soma a valor de att2, o valor do atributo att1
- Update: subtrai o valor do atributo att2, a diferena entre o valor novo e o velho do att1

EXEMPLO:
Na transao Invoice, cada vez que se ingressa uma linha com um produto que se est comprando, se deve diminuir o
stock do mesmo, segundo a quantidade levada.
Isto poderia ser feito de forma simples com a seguinte regra de atribuio:
ProductStock = ProductStock InvoiceDetailQuantity;
Se prestarmos ateno, todavia, vemos que esta regra no nos serve, pois no est condicionada a um modo particular,
razo pelo qual ser disparada tanto quando estiver inserindo uma nova linha na fatura, como quando se est
eliminando ou modificando uma j existente. Nestes ltimos dois casos incorreto disparar a regra.

88

De fato, quando eliminada uma linha existente, a operao contrria deve ser realizada, ou seja, devolver ao
estoque o que havia sido quitado quando se inseriu a linha.
O correto ento, tendo em conta todos os casos possveis seria ter 3 regras:
ProductStock =ProductStock - InvoiceDetailQuantity if Insert;
ProductStock =ProductStock + InvoiceDetailQuantity if Delete;
ProductStock=ProductStock + old(InvoiceDetailQuantity) InvoiceDetailQuantity if Update;
Aqui estamos utilizando a funo old, que devolve o valor armazenado do atributo ( o valor antes de modific-lo).
Para evitar fazer tudo GeneXus fornece a regra subtract que se encarrega de fazer a atribuio correta de acordo ao
modo. Ento podemos substituir as 3 atribuies anteriores, por:
subtract( InvoiceDetailQuantity, ProductStock);
Esta regra tem a inteligncia para, dependendo do modo, subtrair ou somar.
Add
OBJETIVO: Soma o valor de um atributo ao valor de outro atributo, se a condio especificada for satisfeita.
SINTAXE: add( att1, att2) [if cond];
ONDE:
att1, att2 : so os atributos pertencentes a alguma das tabelas base associadas a transao, ou a suas estendidas (e
devem estar declarados na estrutura).
cond:
uma expresso booleana.
FUNCIONALIDADE: a adio realizada considerando o modo da transao (Insert, Update ou Delete).
Modo:
- Insert:
soma ao valor do atributo att2, o valor do atributo att1
- Delete:
subtrai ao valor de att2, o valor do atributo att1
- Update: soma ao valor do atributo att2, a diferena entre o valor novo e o velho de att1
EXEMPLO:
Definimos na transao "Customer", um atributo de nome CustomerTotalPurchases, para registrar o valor total de
compras efetuadas pelo mesmo. O comportamento desejado que cada vez que for criado uma fatura para um
cliente, seja somado o total da fatura (InvoiceAmount) ao total de compras efetuadas pelo cliente
(CustomerTotalPurchases).
Como vimos na regra subtract, no devemos esquecer que na transao Invoice podemos tambm eliminar e
modificar Invoice, e no somente cri-las; para tanto importante ter em conta o modo de trabalho na transao
(Insert, Update, Delete). O GeneXus nos libera de termos que considerar os modos, tendo que escrever as seguintes
3 regras de atribuio na transao Invoice :
CustomerTotalPurchases = CustomerTotalPurchases + InvoiceAmount if Insert;
CustomerTotalPurchases = CustomerTotalPurchases InvoiceAmount if Delete;
CustomerTotalPurchases = CustomerTotalPurchases old(InvoiceAmount) + InvoiceAmount if
Update;
Ao invs disso o GeneXus nos brinda com a regra add, que encarrega de somar ou diminuir, dependendo do modo.

89

Se agregarmos na transao "Customer o atributo CustomerTotalPurchases (total de compras do cliente):

CustomerId*
CustomerName
CustomerAddress
CustomerGender
...
CustomerTotalPurchases

e na transao Invoice inferimos o atributo CustomerTotalPurchases que pertence a tabela estendida e

podemos definir a regra:
add(InvoiceAmount, CustomerTotalPurchases);
e conseguimos o comportamento desejado, que :
se insere uma fatura (Insert): soma ao valor do atributo CustomerTotalPurchases, o valor do
atributo InvoiceAmount
se elimina uma fatura (Delete): subtrai ao valor do atributo CustomerTotalPurchases, o valor do
atributo InvoiceAmount
se modifica uma fatura (Update): soma ao valor do atributo CustomerTotalPurchases, a diferena
entre o valor novo e o velho de InvoiceAmount
Serial
OBJETIVO: Permite serializar (auto-numerar) atributos numricos.
SINTAXE: Serial( att1, att2, step);
ONDE:
att1 : um atributo pertencente a alguma das tabelas base associadas transao (isto ,no inferido), que
deseja serializar (depende de estar declarado na estrutura).
att2 : deve pertencer a uma tabela diretamente superordinada do atributo att1.
step: o passo ou incremento da serializao
FUNCIONALIDADE: o propsito desta regra atribuir um nmero correlativo att1 cada vez que inserido
um registro na tabela que pertence att1. Toma-se o valor de att2 att2 contm o ltimo nmero utilizado na
auto-numerao), incrementa-se o valor do parmetro step, e o valor resultante atribudo tanto ao atributo
att1 do novo registro, como ao atributo att2 para conservar o ltimo nmero atribudo.
Quando um registro inserido por meio de uma transao na qual foi definida a regra: Serial (att1, att2, step),
se acesse ao att2 (haver um s valor deste atributo relacionado, pois pertence a uma tabela diretamente
superordinada), soma-se o valor step, e se atribui o valor obtido tanto a att1 do registro que vai inserir, como
a att2 pertencente a uma tabela diretamente superordinada com respeito tabela que contem a att1.
Caso se desenha a transao "Invoice" contendo um Nmero de linha da Faturae (atributo InvoiceDetailId)
como identificador nico do segundo nvel. A estrutura da transao seria:
INVOICE
{
InvoiceId*
CustomerId
CustomerName
InvoiceDate
InvoiceLastDetailId
INVOICEDETAIL
{
InvoiceDetailId*
ProductId
ProductDescription

90

Neste desenho o atributo ProductId no o identificador nico do nvel, e sim a chave estrangeira unicamente.
Cada linha tem um nmero de linha que identificada de forma nica, possvel ingressar o mesmo produto em
distintas linhas.
Pode ser til atribuir por meio do sistema, nmeros correlativos ao campo InvoiceDetailId, definindo a regra:
Serial (InvoiceDetailId, InvoiceLastDetailId, 1);
O primeiro parmetro da regra serial define qual o atributo a ser numerado automaticamente, no segundo
parmetro deve ser indicado um atributo cuja funo guardar o ltimo valor atribudo at o momento, e por ltimo
o terceiro parmetro para indicar o incremento (neste caso se incrementa de um em um).
O segundo parmetro (no exemplo InvoiceLastDetailId) deve pertencer a uma tabela diretamente superordinada
tabela que contm o atributo que se deseja numerar automaticamente (InvoiceDetailId). A regra serial o requer
assim. No exemplo, pode ser observado que InvoiceLastDetailId encontra-se na tabela de chave InvoiceId*, a qual
diretamente superordinada tabela que contm o atributo numerar (InvoiceDetailId).
Isto , cada fatura ter no cabealho, um atributo que armazena o ltimo nmero de linha atribudo at o momento
(InvoiceLastDetailId). A regra serial est implementada de forma que necessita deste atributo (para fixar o ltimo
nmero utilizado, som-lo ou incremento, e atribuir o prximo nmero da nova linha).
Considerao:
A regra serial til na hora de autonumerar (serializar) linhas, no em cabealhos (por exemplo, nmeros de
faturas, nmeros de clientes, etc.). Para utiliz-la precisa definir um atributo em uma tabela diretamente
superordinada; isto resulta que se desejarmos autonumerar linhas devemos incluir este atributo no nvel da
estrutura imediatamente superior ao do atributo a serializar.

91

Contamos com uma soluo muito mais simples para autonumerar cabealhos: quando uma tabela tem uma chave
simples ( formada por somente um atributo) e o tipo de dados numrico, pode numerar-se automaticamente
utilizando a funcionalidade que fornecem os administradores de base de dados para isto. A forma de indic-lo em
GeneXus configurando a propriedade Autonumber do atributo chave:

Se na propriedade Autonumber de um atributo numrico chave, selecionar o valor True, significa que ser realizada a
numerao automtica do mesmo. Sero agregadas as seguintes propriedades no dilogo:
Start: Mediante esta propriedade se configura a partir de qual nmero comea a numerao automtica.
Step: Mediante esta propriedade possvel configurar o incremento do campo (entre dois registros).
For replication: Esta propriedade somente vlida para o motor de base de dados SQL Server; o valor Yes indica a
este que no deve aplicar a propriedade em caso de que a tabela seja receptora de replicao (mas que deve manter
os nmeros vindos da replicao).
Para maiores detalhes desta propriedade, recomendamos acessar ao Help de GeneXus.

92

Update
OBJETIVO: Possibilita atualizar no form de uma transao (Win/Web) atributos da tabela estendida (inferidos).
SINTAXE: Update( att1[, atti ]);
ONDE:
atti: um atributo pertencente a tabela estendida de alguma das tabelas bases associadas a transao.
FUNCIONALIDADE: Em uma transao, todos os atributos que pertencem as tabelas associadas a transao, por
default so aceitos e os que pertencem a tabela estendida, no pertencem a base, so inferidos, e portanto no
aceitos.
Mas se queremos que estes atributos inferidos sejam aceitos, para que o usurio possa modificar a partir do form seu
valor, ento temos a regra Update.
EXEMPLO:
InvoiceId*
InvoiceDate
CustomerId
CustomerName

CustomerId*
CustomerName

update(CustomerName);

93

Em qual nvel de uma transao so executadas as regras definidas na mesma?

Na maioria das vezes no necessrio agregar explicitamente na definio das regras o nvel da
transao no qual se deseja que sejam disparadas, j que os atributos envolvidos nas regras guiam
GeneXus ao nvel correspondente para execut-las.
Por exemplo, se uma regra referencia unicamente a atributos do primeiro nvel da transao na qual
se encontra definida (seja na prpria regra ou na condio de disparo), GeneXus entende que a
mesma estar associada ao primeiro nvel da transao.
Analogamente, se uma regra referencia somente atributos do segundo nvel da transao na qual
est definida (seja na prpria regra ou na condio de disparo), GeneXus entende que a mesma
estar associada ao segundo nvel da transao.
No caso que uma regra referencie atributos de vrios nveis, GeneXus entende que a regra est
associada ao ltimo dos nveis dos atributos envolvidos, j que ser no ltimo nvel que ter os
valores de todos os atributos implicados.
Em seguida apresentaremos exemplos concretos:
1) Se define a seguinte regra na transao Invoice:
Default(InvoiceDate, &today);
como o nico atributo que se menciona na regra InvoiceDate, e um atributo do primeiro nvel da
transao, GeneXus determina que se trata de uma regra associada ao primeiro nvel.
2) Se definir a seguinte regra na transao Invoice:
subtract( InvoiceDetailQuantity, ProductStock );
como os dois atributos mencionados na mesma se encontram no segundo nvel da transao,
GeneXus determina que se trata de uma regra associada ao segundo nvel.

94

3) Se definir a seguinte regra na transao Invoice:

InvoiceDetailDiscount= InvoiceDetailAmount * CustomerDiscountPercentage/100;

sendo InvoiceDetailDiscount (desconto correspondente a uma linha) um atributo pertencente ao segundo nvel
da transao Invoice e CustomerDiscountPercentage (porcentagem de desconto ortogado a um cliente) um
atributo declarado no primeiro nvel da transao Invoice, GeneXus determina que se trata de uma regra
associada ao segundo nvel da transao.
Quando nos referimos que uma regra est associada a determinado nvel, significa que a mesma se executa
para cada instancia com a qual se trabalhe atravs desse nvel (se cumprir com a condio de disparo da
regra).
No caso do primeiro exemplo visto, a regra Default(InvoiceDate, &today) uma regra associada ao primeiro
nvel da transao Invoice. Isto significa que ao executar todo cabealho de fatura inserido atravs do
primeiro nvel da transao Invoice (a regra Default tem a particularidade de se disparar unicamente quando
o modo de execuo Insert).
No caso do segundo exemplo visto, a regra subtract(InvoiceDetailQuantity, ProductStock) uma regra
associada ao segundo nvel da transao Invoice. Isto significa que executando toda linha da fatura que se
insira, atualize ou elimine atravs do segundo nvel da transao Invoice.
No caso do terceiro exemplo, a regra:
InvoiceDetailDiscount = InvoiceDetailAmount * CustomerDiscountPercentage/100 uma regra associada ao
segundo nvel da transao Invoice. De modo que esta regra se executa para toda linha da fatura que se
insira, atualize ou elimine atravs do segundo nvel da transao Invoice.
Concluindo, para cada fatura com a qual se trabalhe atravs da transao Invoice:
- para o cabealho: so executadas as regras associadas ao primeiro nvel
- para cada uma das linhas: so executadas as regras associadas ao segundo nvel
importante saber que como norma geral GeneXus sempre determina que uma regra seja disparada no
primeiro momento possvel, isto , naquele momento que tenha todos os dados necessrios. E somente em
alguns casos que assim o requeiram, a mesma regra voltar a ser disparada mais adiante.
Qual nvel de disparo por default associado uma regra que no referencia atributos?
Quando no tem atributos envolvidos numa regra, o nvel associado por default a regra ser o primeiro.
Por exemplo, a seguinte regra definida na transao Invoice:
Error(Faturas no podem ser eliminadas) if Delete;
no tem atributos envolvidos, portanto, o nvel associado por default a regra ser o primeiro.
Quando tem que especificar explicitamente o nvel de disparo de uma regra?

Existe uma clusula opcional de nome Level que permite modificar o nvel por default de disparo de uma
regra, alterando-o por um nvel posterior.
Isto , se por exemplo uma regra se executa por default para o primeiro nvel de uma transao e se deseja
que se execute para o segundo, se dever agregar a regra ou componente Level seguido de um atributo ou
conjunto de atributos do segundo nvel. Isto far que a regra se execute para cada uma das instancias
correspondentes as linhas, e no para a instancia correspondente ao cabealho como era o comportamento
por default.
Por exemplo, se definimos a seguinte regra na transao Invoice:
msg(A data da fatura maior que a data atual) if InvoiceDate > &Today;
por default esta regra est associada ao primeiro nvel da transao, j que o nico atributo referenciado na
regra se encontra no primeiro nvel da transao. Se por algum motivo desejamos que a regra se execute para
cada uma das instancias correspondentes as linhas em vez de executar-se para a instancia correspondente ao
cabealho, teremos que agregar na definio da regra, a clusula Level seguida de um ou vrios atributos do
segundo nvel:
msg(A data da fatura maior que a data atual) if InvoiceDate>&Today Level InvoiceDetailAmount;

95

Agregar a clusula Level a uma regra somente faz sentido se a continuao da mesma so mencionados
atributos que so de algum nvel posterior aos nveis dos atributos implicados na definio da regra em si.
No seguinte exemplo, o fato de ter agregado a clusula Level a regra no agrega mais informao visto que o
atributo que j tem essa informao na definio da prpria regra:
msg(A data da fatura maior que a data atual) if InvoiceDate > &Today Level CustomerId;
fcil compreender que o atributo InvoiceDate j guia GeneXus que se trata de uma regra associada ao
primeiro nvel, assim que o especificado pela clusula Level no exemplo no contribui mais informao e
portanto desnecessrio.

Por ltimo, no exemplo que segue:

InvoiceDetailDiscount= InvoiceDetailAmount * CustomerDiscountPercentage/100 Level InvoiceDate;
se incluiu a clusula Level na definio da regra, como o atributo que segue a clusula de um nvel superior
ao nvel dos atributos referenciados na regra, a clusula Level definida no contribuiu com informao til
neste caso. Isto , no possvel que possuindo atributos envolvidos de um segundo nvel em uma regra, a
mesma se execute no primeiro nvel, j que no primeiro nvel no tem informao do ou dos nveis inferiores
(alm de que tem N instancias para os nveis inferiores). De modo que a regra seguir estando associada ao
segundo nvel da transao Invoice, no contribuindo com informao til da clusula Level neste exemplo.
Concluindo, a clusula Level somente faz sentido que seja agregada para modificar o nvel por default de
disparo de uma regra, a um nvel posterior.

Como condicionar regras para que se executem em determinados modos?

GeneXus fornece as seguintes funes booleanas para poder inclu-las na condio de disparo das regras
com o objetivo de limit-las que se executem pontualmente em alguns dos modos possveis:

Insert
Update
Delete

Exemplos de uso (todas as regras correspondem a transao Invoice)

1) Noaccept( InvoiceDate ) if Update;
Se est modificando uma fatura (modo Update), no se permite que sua data seja modificada. Se a regra foi
definida sem condio de disparo que temos explicitado, o atributo InvoiceDate fica desabilitado em todos os
modos de execuo.
2) Error( Faturas no podem ser eliminadas ) if Delete;
Se tentar eliminar uma fatura, se dispara o error impedindo a eliminao. Como no tem atributos envolvidos
na regra, por default o nvel associado a regra ser o primeiro.

3) Error( Linhas da Faturas no podem ser eliminadas ) if Delete Level InvoiceDetailQuantity;

Se tenta eliminar uma linha de uma fatura, se dispara o error impedindo a eliminao. Observar que se tem
explcito na regra a clusula Level seguida de um atributo do segundo nvel da transao Invoice, para
indicar que se deseja que a mesma esteja associada ao segundo nvel da transao.

96