13 subtipos-curso gxxbr

389 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
389
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
9
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

13 subtipos-curso gxxbr

  1. 1. 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, é desenhando a 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 teria maneira de identifica-los. SOLUÇÃO: chamar as duas cidades de reserva com diferentes nomes de atributos. Qualquer das seguintes opções é válida. Escolhemos a 3era por maior clareza. Opção 1) ReservationCityFromId cidade origem CityId 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 origem ReservationCityToId cidade destino O problema é que ao colocar por exemplo ReservationCityFromId ao invés de CityId, GeneXus deixa de inferir que ReservationCityFromId corresponde ao código de uma cidade da tabela de CITY. Como fazemos para relacioná-los, sendo que tem nomes de atributos diferentes? ver resposta na próxima folha …
  2. 2. Para estes casos GeneXus fornece os SUBTIPOS, que permitem definir que dois atributos que se chamam diferentes correspondem ao mesmo conceito. Em nosso exemplo, se definimos o atributo ReservationCityFromId como subtipo de CityId, estamos especificando que mesmo ReservationCityFromId e CityId são diferentes atributos (de nomes diferentes), correspondem, ao mesmo conceito (uma cidade da tabela CITY). Ao estabelecer que um atributo é subtipo de outro, estamos estabelecendo uma dependência funcional entre eles. Se ReservationCityFromId é subtipo de CityId, então dizemos que CityId é supertipo de ReservationCityFromId. 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 utilizando diretamente o supertipo.
  3. 3. 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 à outra tabela (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 de um caminho” e com “valores diferentes”, é necessário definir SUBTIPOS, para que os atributos possam 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 qual os caminhos deve tomar para acessar a tabela destino, é mencionando os nomes de atributos correspondentes. Ex.: mencionar ReservationCityFromName caso queira nesse momento o nome da cidade origem, o ReservationCityToName caso queira o nome da cidade destino.
  4. 4. Com o grupo estamos indicando que os atributos pertencentes ao mesmo grupo de subtipos, estão relacionados. Por exemplo, no nosso exemplo, GeneXus saberá que o atributo ReservationCityToName será inferido através do atributo ReservationCityToId (e não através do ReservationCityFromId). Isto é por ambos pertencerem ao mesmo grupo (ao nome ReservationCityTo). Quando o usuário digita um valor sobre ReservationCityToId, não somente é feito de forma automática o controle de integridade referencial (que exista uma cidade com esse código na tabela CITY), e sim que vai inferir em ReservationCityToName o nome correspondente a esse código de cidade. IMPORTANTE: Todo grupo de subtipos, deve conter um atributo ou um conjunto de atributos, cujos supertipos, 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és da chave. Caso contrário o grupo estará mal definido.
  5. 5. Se desejarmos, por exemplo listar as vendas (SALE), e de cada uma delas mostrar os dados do cliente (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 as tabelas 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 estendida COUNTRY 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, mas querendo que continuem representando todas as relações e fazendo automaticamente todos os controles de integridade referencial.
  6. 6. Uma vez definidos os dois grupos de subtipos que se mostram na figura, e fazendo a mudança correspondente na estrutura da transação Sale, resolve a ambigüidade no modelo de dados!
  7. 7. Uma vez definidos os subtipos, temos que lembrar de usar o nome do atributo que corresponda ao que queremos acessar. Por exemplo, em todos aqueles objetos GeneXus nos quais gostaríamos de acessar ao código do nome do país do cliente da venda devemos usar atributos SaleCustomerCountryId e SaleCustomerCountryName respectivamente.
  8. 8. Caso de subtipos “Especialização de atributos”: Quando se está modelando uma categorização. Geralmente é utilizada, quando um objeto do negócio compartilha todas as características de outro objeto, mas agrega mais algumas. A diferença pode estar tanto nas propriedades, como no seu comportamento. Exemplo “Sistema para uma Universidade”: Neste exemplo, o professor e o aluno possuem regras e comportamentos claramente diferenciados. 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 claramente diferenciados. 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 estudantes como os docentes são pessoas, são utilizados subtipos. Definindo que o identificador de “Teacher” é subtipo do identificador de “Person” estamos estabelecendo esta relação. Cada vez que inserir um registro na tabela TEACHER através de sua transação, a checagem da integridade referencial é realizada contra “Person”. Da mesma forma, ao tentar eliminar um registro de “Person”, primeiro é verificado que não exista nenhum registro na tabela TEACHER (nem em STUDANT) com o mesmo valor na chave primária.
  9. 9. 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, ao ser um subtipo de PersonId, será uma chave estrangeira da tabela PERSON. Portanto, serão realizadas as checagens de integridade referencial correspondentes. Os atributos TeacherName e TeacherAddress são subtipos de PersonName e de PersonAddress respectivamente e estão agrupados com TeacherId, que serão inferidos da tabela PERSON, através da chave estrangeira TeacherId (não estão armazenados na tabela TEACHER).
  10. 10. É 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 entre Empregado e Gerente: - cada empregado tem um gerente. Um gerente, a sua vez, é um empregado (aqui esta a recursividade). - um gerente pode ter vários empregados. Além disso, a realidade a ser representada é que “somente os empregados que não são gerentes possuem 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 tabela EMPLOYEE. -que todo empregado que não é gerente, tenha um gerente. Este controle é realizado com a regra error mostrada na figura. O atributo EmployeeManagerName não fica armazenado na tabela EMPLOYEE, é inferido após ingressar um valor em EmployeeManagerId. Por ser EmployeeManagerId subtipo de EmployeeId, são realizadas automaticamente os controles de integridade referencial da tabela com ela própria. Isto pode ser visto na navegação da transação na página seguinte.

×