���

���

���

Realidade para representar/desenhar:

Em cada reserva tem duas cidades envolvidas, as quais cumprem regras diferentes.O rol de uma das cidades é o de ser a “cidade de partida” (cidade origem) e o rol da outra é o de“cidade de chegada” (cidade destino).

O domínio de ambas cidades é o mesmo, o da tabela CITY.

A forma de representar tanto a “origem” como o “destino” são cidades da tabela CITY, é desenhandoa transação “Reservation” na forma mencionada inicialmente na transparência. Todavia, não épossível que na estrutura de uma transação figure o mesmo atributo mais de uma vez, pois não teriamaneira de identifica-los.SOLUÇÃO: chamar as duas cidades de reserva com diferentes nomes de atributos. Qualquer dasseguintes opções é válida. Escolhemos a 3era por maior clareza.

Opção 1) ReservationCityFromId � cidade origemCityId � cidade destino (mesmo nome que a PK de CITY)

Opção 2) CityId � cidade origem (mesmo nome que a PK de CITY)ReservationCityToId � cidade destino

Opção 3) ReservationCityFromId � cidade origemReservationCityToId � cidade destino

O problema é que ao colocar por exemplo ReservationCityFromId ao invés de CityId, GeneXus deixade inferir que ReservationCityFromId corresponde ao código de uma cidade da tabela de CITY. Comofazemos para relacioná-los, sendo que tem nomes de atributos diferentes? ver resposta na próximafolha …

���

Para estes casos GeneXus fornece os SUBTIPOS, que permitem definir que dois atributos que sechamam diferentes correspondem ao mesmo conceito.

Em nosso exemplo, se definimos o atributo ReservationCityFromId como subtipo de CityId, estamosespecificando que mesmo ReservationCityFromId e CityId são diferentes atributos (de nomesdiferentes), correspondem, ao mesmo conceito (uma cidade da tabela CITY).

Ao estabelecer que um atributo é subtipo de outro, estamos estabelecendo uma dependênciafuncional entre eles.

Se ReservationCityFromId é subtipo de CityId, então dizemos que CityId é supertipo deReservationCityFromId.

�Os atributos que se encontrem numa relação subtipo-supertipo compartilham a mesma definição(tipo de dados).

�Se realizam os controles de integridade referencial automaticamente.

�A tabela estendida obtida com a definição do subtipo, é a mesma que se obteria utilizandodiretamente o supertipo.

���

IMPORTANTE:Observe que este caso de múltiplas referências pode acontecer:

• na tabela base (*)

• como na tabela estendida

(*) é o caso do exemplo, na mesma tabela (RESERVATION) tem mais de uma referência à outratabela (CITY) e com valores diferentes.

RESUMINDO:sempre que a partir de uma tabela se acesse a outra que está em sua tabela estendida por “mais deum caminho” e com “valores diferentes”, é necessário definir SUBTIPOS, para que os atributospossam ser chamados de forma diferente e realizando todos os controles de integridade referencial.

Uma vez definidos os grupos de subtipos que são necessários, a forma de indicar ao GeneXus qualos caminhos deve tomar para acessar a tabela destino, é mencionando os nomes de atributoscorrespondentes. Ex.: mencionar ReservationCityFromName caso queira nesse momento o nomeda cidade origem, o ReservationCityToName caso queira o nome da cidade destino.

���

Com o grupo estamos indicando que os atributos pertencentes ao mesmo grupo de subtipos, estãorelacionados. Por exemplo, no nosso exemplo, GeneXus saberá que o atributoReservationCityToName será inferido através do atributo ReservationCityToId (e não através doReservationCityFromId). Isto é por ambos pertencerem ao mesmo grupo (ao nomeReservationCityTo).

Quando o usuário digita um valor sobre ReservationCityToId, não somente é feito de formaautomática o controle de integridade referencial (que exista uma cidade com esse código na tabelaCITY), e sim que vai inferir em ReservationCityToName o nome correspondente a esse código decidade.

IMPORTANTE: Todo grupo de subtipos, deve conter um atributo ou um conjunto de atributos, cujossupertipos, juntos, correspondam a chave primária de uma tabela do modelo.Os demais atributos do grupo deveram ser do tipo “Inferred”, ou seja, poderão ser inferidos atravésda chave.

Caso contrário o grupo estará mal definido.

���

Se desejarmos, por exemplo listar as vendas (SALE), e de cada uma delas mostrar os dados docliente (nome, país, etc.) e do vendedor (nome, país, etc.):

• necessitamos um For Each com tabela base SALE e acessar através de sua extensão astabelas CUSTOMER, SELLER e COUNTRY para listar os atributos secundários do cliente,vendedor e país respectivamente.

Problema:Os atributos de nome CountryId, CountryName e todos da tabela estendidaCOUNTRY pertencem à tabela estendida SALE por dois caminhos diferentes:

1) através do país do cliente e 2) através do país do vendedor.

Solução:Devemos diferenciá-los, chamá-los com diferente nome de atributo, masquerendo que continuem representando todas as relações e fazendoautomaticamente todos os controles de integridade referencial.

�

Uma vez definidos os dois grupos de subtipos que se mostram na figura, e fazendo a mudançacorrespondente na estrutura da transação Sale, resolve a ambigüidade no modelo de dados!

�

Uma vez definidos os subtipos, temos que lembrar de usar o nome do atributo que corresponda aoque queremos acessar. Por exemplo, em todos aqueles objetos GeneXus nos quais gostaríamos deacessar ao código do nome do país do cliente da venda devemos usar atributosSaleCustomerCountryId e SaleCustomerCountryName respectivamente.

��

Caso de subtipos “Especialização de atributos”:Quando se está modelando uma categorização. Geralmente é utilizada, quando um objeto do negóciocompartilha todas as características de outro objeto, mas agrega mais algumas. A diferença podeestar tanto nas propriedades, como no seu comportamento.

Exemplo “Sistema para uma Universidade”:

Neste exemplo, o professor e o aluno possuem regras e comportamentos claramentediferenciados. Por exemplo, o professor terá cursos atribuídos, remuneração, etc. O aluno estaráinscrito num curso, terá pagamentos, assistência, escolaridade, etc.

Estamos em um caso que as regras e o tratamento das entidades da categorização estão claramentediferenciados.

Tanto os estudantes como os docentes compartilham informação em comum (ambos tem um nome,endereço, etc) mas também possuem informação diferente, que é própria de cada um.

Para representar esta realidade, são criadas três transações: “Person”, “Teacher” e “Studant”.

Na transação “Person” figura a informação em comum. Para representar que tanto os estudantescomo os docentes são pessoas, são utilizados subtipos.

Definindo que o identificador de “Teacher” é subtipo do identificador de “Person” estamosestabelecendo esta relação.

Cada vez que inserir um registro na tabela TEACHER através de sua transação, a checagem daintegridade referencial é realizada contra “Person”. Da mesma forma, ao tentar eliminar um registrode “Person”, primeiro é verificado que não exista nenhum registro na tabela TEACHER (nem emSTUDANT) com o mesmo valor na chave primária.

��

A transação “Teacher” tem associada uma tabela que conterá fisicamente somente dois atributos:TeacherId e TeacherSalary.

TeacherId é o identificador da transação, será a chave primária da tabela associada. Alem disso, aoser um subtipo de PersonId, será uma chave estrangeira da tabela PERSON. Portanto, serãorealizadas as checagens de integridade referencial correspondentes.

Os atributos TeacherName e TeacherAddress são subtipos de PersonName e de PersonAddressrespectivamente e estão agrupados com TeacherId, que serão inferidos da tabela PERSON, atravésda chave estrangeira TeacherId (não estão armazenados na tabela TEACHER).

��

É possível ter uma tabela subordinada a si mesma utilizando subtipos.

Este tipo de subtipos se utiliza para modelar as relações recursivas. Por exemplo, a relação entreEmpregado e Gerente:

- cada empregado tem um gerente. Um gerente, a sua vez, é um empregado (aqui esta arecursividade).- um gerente pode ter vários empregados.

Além disso, a realidade a ser representada é que “somente os empregados que não são gerentespossuem um gerente”, então, ao inserir os dados tem que realizar os seguintes controles:

-quando informar os gerentes, tem que permitir deixar nulo o atributo EmployeeManagerId. Para isto,trocamos para ‘Yes’ a coluna Nulls do atributo EmployeeManagerId, que é uma FK na tabelaEMPLOYEE.-que todo empregado que não é gerente, tenha um gerente. Este controle é realizado com a regraerror mostrada na figura.

O atributo EmployeeManagerName não fica armazenado na tabela EMPLOYEE, é inferido apósingressar um valor em EmployeeManagerId.

Por ser EmployeeManagerId subtipo de EmployeeId, são realizadas automaticamente os controles deintegridade referencial da tabela com ela própria. Isto pode ser visto na navegação da transação napágina seguinte.

��

��