• Nenhum resultado encontrado

de consultas em bancos de dados NoSQL orientados a documentos

4.2 Estudo de caso: Modelo ER ProgradWeb

Apresenta-se o segundo Modelo ER, referente a um sistema de controle acadêmico que foi utilizado por muito tempo na UFSCar, denominado ProgradWeb. O Modelo ER original é muito maior do que o apresentado aqui. Mas para testar a abordagem pro- posta, apenas algumas Entidades/Relacionamentos, com seus respetivos atributos, são suĄcientes, até porque a semântica completa das consultas não foi implementada.

Na listagem4.12observa-se as seguintes entidades: Alunograd, Matriculagrad, Dis- ciplinagrad, Enfasegrad e os seguintes relacionamentos: Mora, Registra e Gradegrad.

1 A l u n o g r a d { 2 c o d a l u _ a l u g : int , 3 n o m e a l u _ a l u g : string , 4 d a t a n a s c _ a l u g : string , 5 c p f _ a l u g : string 6 } 7 M a t r i c u l a g r a d { 8 c o d a l u _ m a t r : int , 9 c o d e n f _ m a t r : int , 10 a n o i n i _ m a t r : string , 11 s e m i n i _ m a t r : string 12 } 13 D i s c i p l i n a g r a d { 14 c o d d i s c i p _ d i s c i p : string , 15 n o m e _ d i s c i p : string , 16 s e t o r _ d i s c i p : string 17 } 18 E n f a s e g r a d { 19 c o d e n f _ e n f : int , 20 s i g l a e n f _ e n f : string , 21 n o m e e n f _ e n f : string 22 } 23 Endere co { 24 c o d _ e n d e r e c o : int , 25 n o m e _ c i d a d e : string , 26 n o m e _ b a i r r o : sgring , 27 cep : string , 28 n o m e _ r u a : string , 29 c o m p l e m e n t o : string 30 }

31 Mora ( Alunograd , Endere co ) 1:1{ 32 }

4.2. Estudo de caso: Modelo ER ProgradWeb 113 33 R e g i s t r a ( Alunograd , M a t r i c u l a g r a d ) 1: N { 34 o p c a o _ r e g : string 35 } 36 G r a d e g r a d ( Disciplinagrad , E n f a s e g r a d ) N : N { 37 p e r f i l _ g r d : string , 38 u s e r i d _ g r d : string , 39 d a t a t u _ g r d : string 40 }

Listagem 4.12 Ű Modelo Entidade - Relacionamento, estudo de caso Progradweb

4.2.1 Mapeamento com cardinalidade 1-1

Na Listagem 4.13 é apresentada uma das opções de mapeamento para entidades com cardinalidade 1-1. No tipo de documento DocTypeAlunograd foram embutidos os atributos da entidade Endereco.

1 D o c T y p e A l u n o g r a d [ A l u n o g r a d ( main = true ) , Mora ( main = false ) ,

E n d e r e c o ( main = false ) ] 2 { 3 _id : int [ A l u n o g r a d . c o d a l u _ a l u g ] 4 f N o m e a l u _ a l u g : string [ A l u n o g r a d . n o m e a l u _ a l u g ] 5 f D a t a n a s c _ a l u g : string [ A l u n o g r a d . d a t a n a s c _ a l u g ] 6 f C p f _ a l u g : string [ A l u n o g r a d . c p f _ a l u g ] 7 d a t a _ E n d e r e c o : 8 { 9 f C o d _ e n d e r e c o : int [ E n d e r e c o . c o d _ e n d e r e c o ] 10 f N o m e _ c i d a d e : string [ E n d e r e c o . n o m e _ c i d a d e ] 11 f N o m e _ b a i r r o : sgring [ E n d e r e c o . n o m e _ b a i r r o ] 12 fCep : string [ E n d e r e c o . cep ]

13 f N o m e _ r u a : string [ E n d e r e c o . n o m e _ r u a ] 14 f C o m p l e m e n t o : string [ E n d e r e c o . c o m p l e m e n t o ] 15 } 16 } 17 D o c T y p e E n d e r e c o [ E n d e r e c o ( main = true ) ] 18 { 19 _id : int [ E n d e r e c o . c o d _ e n d e r e c o ] 20 f N o m e _ c i d a d e : string [ E n d e r e c o . n o m e _ c i d a d e ] 21 f N o m e _ b a i r r o : sgring [ E n d e r e c o . n o m e _ b a i r r o ] 22 fCep : string [ E n d e r e c o . cep ]

23 f N o m e _ r u a : string [ E n d e r e c o . n o m e _ r u a ] 24 f C o m p l e m e n t o : string [ E n d e r e c o . c o m p l e m e n t o ]

25 }

Listagem 4.13 Ű Esquema MongoDB, Mapeamento 1-1

Neste mapeamento, o valor da entidade 1 é Alunograd, da entidade 2 é Endereco e do relacionamento é Mora. A seguir mostra-se a consulta de entrada para este exem- plo: Şfrom Alunograd a rjoin Mora m (Endereco e) select a.nomealu_alug, a.cpf_alug, e.nome_cidade, e.nome_bairro, e.cepŤ.

A partir deste mapeamento no esquema MongoDB mostrada na Listagem 4.13 e da consulta de entrada, é executado o algoritmo, tendo como resultado a consulta em JavaScript apresentada na Listagem4.14. O algoritmo a ser executado neste mapeamento, corresponde ao citado na Listagem 3.14, onde o relacionamento não possui atributos.

Para gerar a consulta, primeiramente, o acesso é feito ao tipo de documento DocTy- peAlunograd, onde é recuperado os atributos da entidade 1 (linhas 1-8), e atributos da entidade 2 (linhas 9-20).

1 db . D o c T y p e A l u n o g r a d . find () . forEach ( f u n c t i o n ( data ) { 2 db . EC . insert ( {

3 d a t a _ A l u n o g r a d : { 4 _id : data . _id ,

5 f N o m e a l u _ a l u g : data . fNomealu_alug , 6 f D a t a n a s c _ a l u g : data . fDatanasc_alug , 7 f C p f _ a l u g : data . f C p f _ a l u g 8 } , 9 d a t a _ J o i n : [{ 10 d a t a _ E n d e r e c o : { 11 f C o d _ e n d e r e c o : data . d a t a _ E n d e r e c o . fCod_endereco , 12 f N o m e _ c i d a d e : data . d a t a _ E n d e r e c o . fNome_cidade , 13 f N o m e _ b a i r r o : data . d a t a _ E n d e r e c o . fNome_bairro , 14 fCep : data . d a t a _ E n d e r e c o . fCep ,

15 f N o m e _ r u a : data . d a t a _ E n d e r e c o . fNome_rua , 16 f C o m p l e m e n t o : data . d a t a _ E n d e r e c o . f C o m p l e m e n t o 17 } 18 }] 19 }) ; 20 }) ;

Listagem 4.14 Ű Consulta em JavaScript, Mapeamento 1-1

4.2.2 Mapeamento com cardinalidade 1-N

Na Listagem 4.15 é apresentada uma das opções de mapeamento para entidades com cardinalidade 1-N. No tipo de documento DocTypeAlunograd foram embutidos den-

4.2. Estudo de caso: Modelo ER ProgradWeb 115

tro de um array os atributos da entidade Matriculagrad e do relacionamento Registra. Neste mapeamento, o valor da entidade 1 é Alunograd, da entidade é 2 Matriculagrad e o relacionamento é Registra.

1 D o c T y p e A l u n o g r a d [ A l u n o g r a d ( main = true ) , M a t r i c u l a g r a d ( main =

true ) , R e g i s t r a ( main = true ) ]

2 { 3 _id : int [ A l u n o g r a d . c o d a l u _ a l u g ] 4 f N o m e a l u _ a l u g : string [ A l u n o g r a d . n o m e a l u _ a l u g ] 5 f D a t a n a s c _ a l u g : string [ A l u n o g r a d . d a t a n a s c _ a l u g ] 6 f C p f _ a l u g : string [ A l u n o g r a d . c p f _ a l u g ] 7 d a t a _ M a t r i c u l a g r a d : 8 [ 9 { 10 f C o d a l u _ m a t r : int [ M a t r i c u l a g r a d . c o d a l u _ m a t r ] 11 f C o d e n f _ m a t r : int [ M a t r i c u l a g r a d . c o d e n f _ m a t r ] 12 f A n o i n i _ m a t r : string [ M a t r i c u l a g r a d . a n o i n i _ m a t r ] 13 f S e m i n i _ m a t r : string [ M a t r i c u l a g r a d . s e m i n i _ m a t r ] 14 f O p c a o _ r e g : string [ R e g i s t r a . o p c a o _ r e g ] 15 } 16 ] 17 }

Listagem 4.15 Ű Esquema MongoDB, Mapeamento 1-N

A seguir mostra-se a consulta de entrada para este exemplo: Şfrom Alunograd a rjoin Registra r (Matriculagrad m) select a.nomealu_alug, a.cpf_alug, m.codenf_matr, m.anoini_matr, m.semini_matr, r.opcao_regŤ.

A partir deste mapeamento no esquema MongoDB mostrada na Listagem 4.15 e da consulta de entrada, é executado o algoritmo, tendo como resultado a consulta em JavaScript apresentada na Listagem 4.16. O acesso é feito ao tipo de documento DocTypeAlunograd, onde é recuperado os atributos da entidade 1 (linhas 1-10), em seguida com o método forEach é percorrido o campo data_Matriculagrad e atualizado os atributos do relacionamento e da entidade 2 (linhas 11-27).

1 db . D o c T y p e A l u n o g r a d . find () . forEach ( f u n c t i o n ( data ) { 2 db . EC . insert ( {

3 d a t a _ A l u n o g r a d : { 4 _id : data . _id ,

5 f N o m e a l u _ a l u g : data . fNomealu_alug , 6 f D a t a n a s c _ a l u g : data . fDatanasc_alug , 7 f C p f _ a l u g : data . f C p f _ a l u g

9 d a t a _ J o i n : [] 10 }) ;

11 data . d a t a _ M a t r i c u l a g r a d . forEach ( f u n c t i o n ( data1 ) { 12 db . EC . update ({ ‘ d a t a _ A l u n o g r a d . _id ’: data . _id } , 13 { $ a d d T o S e t : { 14 ‘ data_Join ’: { 15 d a t a _ R e g i s t r a : { 16 f O p c a o _ r e g : data1 . f O p c a o _ r e g 17 } , 18 d a t a _ M a t r i c u l a g r a d : { 19 f C o d a l u _ m a t r : data1 . fCodalu_matr , 20 f C o d e n f _ m a t r : data1 . fCodenf_matr , 21 f A n o i n i _ m a t r : data1 . fAnoini_matr , 22 f S e m i n i _ m a t r : data1 . f S e m i n i _ m a t r 23 } 24 }} 25 }) ; 26 }) ; 27 }) ;

Listagem 4.16 Ű Consulta em JavaScript, Mapeamento 1-N

4.2.3 Mapeamento com cardinalidade N-1

Na Listagem 4.17 é apresentada uma das opções de mapeamento para entidades com cardinalidade N-1. Neste mapeamento, o valor da entidade 1 é Matriculagrad, en- tidade 2 Alunograd e do relacionamento é Registra. O DocTypeMatriculagrad contêm os campos embutidos da entidade 2, e o atributo do relacionamento deĄnido como um campo mais do documento.

1 D o c T y p e M a t r i c u l a g r a d [ M a t r i c u l a g r a d ( main = true ) , A l u n o g r a d ( main =

false ) , R e g i s t r a ( main = true ) ]

2 { 3 _id : int [ M a t r i c u l a g r a d . c o d a l u _ m a t r ] 4 f C o d e n f _ m a t r : int [ M a t r i c u l a g r a d . c o d e n f _ m a t r ] 5 f A n o i n i _ m a t r : string [ M a t r i c u l a g r a d . a n o i n i _ m a t r ] 6 f S e m i n i _ m a t r : string [ M a t r i c u l a g r a d . s e m i n i _ m a t r ] 7 f O p c a o _ r e g : string [ R e g i s t r a . o p c a o _ r e g ] 8 d a t a _ A l u n o g r a d : 9 { 10 f c o d a l u _ a l u g : int [ A l u n o g r a d . c o d a l u _ a l u g ] 11 } 12 }

4.2. Estudo de caso: Modelo ER ProgradWeb 117 13 D o c T y p e A l u n o g r a d [ A l u n o g r a d ( main = true ) ] 14 { 15 _id : int [ A l u n o g r a d . c o d a l u _ a l u g ] 16 f N o m e a l u _ a l u g : string [ A l u n o g r a d . n o m e a l u _ a l u g ] 17 f D a t a n a s c _ a l u g : string [ A l u n o g r a d . d a t a n a s c _ a l u g ] 18 f C p f _ a l u g : string [ A l u n o g r a d . c p f _ a l u g ] 19 }

Listagem 4.17 Ű Esquema MongoDB, Mapeamento N-1

A seguir mostra-se a consulta de entrada para este exemplo: Şfrom Matriculagrad m rjoin Registra r (Alunograd a) select m.codenf_matr, m.anoini_matr, m.semini_matr, r.opcao_reg, a.nomealu_alug, a.cpf_alugŤ.

A partir deste mapeamento no esquema MongoDB mostrada na Listagem 4.17 e da consulta de entrada, é executado o algoritmo, tendo como resultado a consulta em JavaScript apresentada na Listagem 4.18. O acesso é feito ao tipo de documento DocTypeMatriculagrad, onde é recuperado e inserido na EC, os atributos da entidade 1 (linhas 1-8), e os atributos do relacionamento e da entidade 2 (linhas 9-18). Em seguida, como ainda faltam atributos da entidade 2, é completada e atualizada realizando a junção entre EC e DocTypeAlunograd (linhas 19-29).

1 db . D o c T y p e M a t r i c u l a g r a d . find () . forEach ( f u n c t i o n ( data ) { 2 db . EC . insert ({

3 d a t a _ M a t r i c u l a g r a d : { 4 _id : data . _id ,

5 f C o d e n f _ m a t r : data . fCodenf_matr , 6 f A n o i n i _ m a t r : data . fAnoini_matr , 7 f S e m i n i _ m a t r : data . fSemini_matr , 8 } , 9 d a t a _ J o i n : [{ 10 d a t a _ R e g i s t r a : { 11 f O p c a o _ r e g : data . f O p c a o _ r e g 12 } , 13 d a t a _ A l u n o g r a d : { 14 f C o d a l u _ a l u g : data . d a t a _ a l u n o g r a d . f C o d a l u _ a l u g 15 } , 16 }] 17 }) ; 18 }) ;

19 db . EC . find () . forEach ( f u n c t i o n ( data ) { 20 var n o v o A r r a y = [];

22 data2 . d a t a _ A l u n o g r a d = db . D o c T y p e A l u n o g r a d . findOne ({ ‘ _id ’:

data2 . d a t a _ A l u n o g r a d . f C o d a l u _ a l u g }) ;

23 n o v o A r r a y . push ( data2 ) ; 24 }) ;

25 db . EC . update ({ ‘ d a t a _ M a t r i c u l a g r a d . _id ’: data . d a t a _ M a t r i c u l a g r a d .

_id } ,

26 { $set : {

27 ‘ data_Join ’: n o v o A r r a y 28 }}) ;

29 }) ;

Listagem 4.18 Ű Consulta em JavaScript, Mapeamento N-1

4.2.4 Mapeamento com cardinalidade N-N

Na Listagem 4.19 é apresentada uma das opções de mapeamento para entida- des com cardinalidade N-N. Modelamos o relacionamento N:N com incorporação de uma via, ŞOne Way EmbeddingŤ (TRIVEDI,2014). No tipo de documento DocTypeGradegrad, foram adicionados os campos identiĄcadores dos tipos de documentos DocTypeDiscipli- nagrad e DocTypeEnfasegrad. Assim, é possível recuperar os dados das entidades Disci- plinagrad e Enfasegrad através dos atributos identiĄcadores.

1 D o c T y p e D i s c i p l i n a g r a d [ D i s c i p l i n a g r a d ( main = true ) ] 2 { 3 _id : string [ D i s c i p l i n a g r a d . c o d d i s c i p _ d i s c i p ] 4 f N o m e _ d i s c i p : string [ D i s c i p l i n a g r a d . n o m e _ d i s c i p ] 5 f S e t o r _ d i s c i p : string [ D i s c i p l i n a g r a d . s e t o r _ d i s c i p ] 6 } 7 D o c T y p e E n f a s e g r a d [ E n f a s e g r a d ( main = true ) ] 8 { 9 id : int [ E n f a s e g r a d . c o d e n f _ e n f ] 10 f S i g l a e n f _ e n f : string [ E n f a s e g r a d . s i g l a e n f _ e n f ] 11 f N o m e e n f _ e n f : string [ E n f a s e g r a d . n o m e e n f _ e n f ] 12 }

13 D o c T y p e G r a d e g r a d [ G r a d e g r a d ( main = true ) , D i s c i p l i n a g r a d ( main =

false ) , E n f a s e g r a d ( main = false ) ]

14 { 15 p e r f i l _ g r d : date [ G r a d e g r a d . p e r f i l _ g r d ] 16 u s e r i d _ g r d : string [ G r a d e g r a d . u s e r i d _ g r d ] 17 d a t a t u _ g r d : string [ G r a d e g r a d . d a t a t u _ g r d ] 18 f C o d d i s c i p _ d i s c i p : int [ D i s c i p l i n a g r a d . c o d d i s c i p _ d i s c i p ] 19 f C o d e n f _ e n f : int [ E n f a s e g r a d . c o d e n f _ e n f ]

4.2. Estudo de caso: Modelo ER ProgradWeb 119

20 }

Listagem 4.19 Ű Esquema MongoDB, Mapeamento N-N

A seguir mostra-se a consulta de entrada para este exemplo: Şfrom Disciplinagrad d rjoin Gradegrad g (Enfasegrad e) select d.coddiscip_discip, d.nome_discip, e.siglaenf_enf, e.nomeenf_enf, g.perĄl_grd, g.userid_grd, g.datatu_grdŤ.

A partir deste mapeamento no esquema MongoDB mostrada na Listagem 4.19 e da consulta de entrada, é executado o algoritmo, tendo como resultados as consultas em JavaScript apresentadas na Listagem 4.20 e 4.21. Na Listagem 4.20 o acesso é feito ao tipo de documento DocTypeDisciplinagrad, onde é recuperado e inserido na EC, os atributos da entidade 1 ŞDisciplinagradŤ (linhas 1-10). Depois, é realizada a junção entre EC e DocTypeGradegrad, onde são recuperados e atualizados na EC os atributos do relacionamento ŞGradegradŤ e da entidade 2 ŞEnfasegradŠ (linhas 11-34). Como faltam atributos da Entidade 2, é realizada outra junção entre EC e DocTypeEnfasegrad, onde Ąnalmente são recuperados e atualizados os todos os atributos da entidade 2.

1 db . D o c T y p e D i s c i p l i n a g r a d . find () . forEach ( f u n c t i o n ( data ) { 2 db . EC . insert ({

3 d a t a _ D i s c i p l i n a g r a d : { 4 _id : data . _id ,

5 f N o m e _ d i s c i p : data . fNome_discip , 6 f S e t o r _ d i s c i p : data . f S e t o r _ d i s c i p 7 } , 8 d a t a _ J o i n : [] 9 }) ; 10 }) ;

11 db . EC . find () . forEach ( f u n c t i o n ( data ) { 12 var varData = [];

13 data . d a t a _ J o i n . forEach ( 14 f u n c t i o n ( d a t a C o p y ) {

15 varData . push ( d a t a C o p y ) ; 16 }) ;

17 db . D o c T y p e G r a d e g r a d . find ({ ‘ fCoddiscip_grd ’: data .

d a t a _ D i s c i p l i n a g r a d . _id }) . forEach ( 18 f u n c t i o n ( data2 ) { 19 varData . push ({ 20 d a t a _ E n f a s e g r a d : { 21 f C o d e n f _ g r d : data2 . f C o d e n f _ g r d 22 } , 23 d a t a _ G r a d e g r a d : { 24 p e r f i l _ g r d : data2 . perfil_grd ,

25 u s e r i d _ g r d : data2 . userid_grd , 26 d a t a t u _ g r d : data2 . d a t a t u _ g r d

27 }

28 }) 29 }) ;

30 db . EC . update ({ ‘ d a t a _ D i s c i p l i n a g r a d . _id ’: data .

d a t a _ D i s c i p l i n a g r a d . _id } ,

31 { $set : {

32 ‘ data_Join ’: varData 33 }}) ;

34 }) ;

35 db . EC . find () . forEach ( f u n c t i o n ( data ) { 36 var n o v o A r r a y = [];

37 data . d a t a _ J o i n . forEach ( f u n c t i o n ( data2 ) {

38 data2 . d a t a _ E n f a s e g r a d = db . D o c T y p e E n f a s e g r a d . findOne ({ ‘ _id ’:

data2 . d a t a _ E n f a s e g r a d . f C o d e n f _ g r d }) ;

39 n o v o A r r a y . push ( data2 ) ; 40 }) ;

41 db . EC . update ( { ’ d a t a _ D i s c i p l i n a g r a d . _id ’: data .

d a t a _ D i s c i p l i n a g r a d . _id } ,

42 { $set : {

43 ‘ data_Join ’: n o v o A r r a y 44 }}) ;

45 }) ;

Listagem 4.20 Ű Consulta em JavaScript, Mapeamento N-N, Query 1

Para a mesma consulta de entrada descrita anteriormente, o algoritmo retorna a consulta apresentada na Listagem4.21. O acesso é feito ao tipo de documento DocType- Gradegrad, onde é recuperado e inserido na EC, os atributos da entidade 1 ŞDisciplina- gradŤ (linhas 1-7) e atualizado os atributos do relacionamento ŞGradegradŤ e da entidade 2 ŞEnfasegradŤ (linhas 9-22). Na linha 8 é criado um índice, de maneira e evitar a in- serção de dois Disciplinas com mesmo fCoddiscip_grd. Com a operação de junção entre EC e DocTypeDisciplinagrad são atualizados os dados da entidade 1 dentro da EC (li- nhas 23-38). Depois, é realizada outra junção entre entre EC e DocTypeEnfasegrad, onde Ąnalmente são recuperados e atualizados os todos os atributos da entidade 2 dentro da EC (linha 39-49).

1 db . D o c T y p e G r a d e g r a d . find () . forEach ( f u n c t i o n ( data ) { 2 db . EC . insert ({

3 d a t a _ D i s c i p l i n a g r a d : {

4 f C o d d i s c i p _ g r d : data . f C o d d i s c i p _ g r d 5 } ,

4.2. Estudo de caso: Modelo ER ProgradWeb 121

6 d a t a _ J o i n : [] 7 }) ;

8 db . EC . c r e a t e I n d e x ( ‘ d a t a _ D i s c i p l i n a g r a d . fCoddiscip_grd ’: 1 } , {

unique : true }) ;

9 db . EC . update ({ ‘ d a t a _ D i s c i p l i n a g r a d . fCoddiscip_grd ’: data .

f C o d d i s c i p _ g r d } , 10 { $ a d d T o S e t : { 11 ’ data_Join ’: { 12 d a t a _ G r a d e g r a d : { 13 p e r f i l _ g r d : data . perfil_grd , 14 u s e r i d _ g r d : data . userid_grd , 15 d a t a t u _ g r d : data . d a t a t u _ g r d 16 } , 17 d a t a _ E n f a s e g r a d : { 18 f C o d e n f _ g r d : data . f C o d e n f _ g r d 19 } 20 } 21 }}) ; 22 }) ;

23 db . EC . find () . forEach ( f u n c t i o n ( data ) { 24 var varData = [];

25 db . D o c T y p e D i s c i p l i n a g r a d . find ({ ‘ _id ’: data . d a t a _ D i s c i p l i n a g r a d .

f C o d d i s c i p _ g r d }) . forEach ( 26 f u n c t i o n ( data2 ) { 27 varData . push ({ 28 d a t a _ D i s c i p l i n a g r a d : { 29 f C o d d i s c i p _ g r d I D : data2 . _id , 30 f N o m e _ d i s c i p : data2 . fNome_discip , 31 f S e t o r _ d i s c i p : data2 . f S e t o r _ d i s c i p 32 }}) 33 }) ; 34 db . EC . u p d a t e M a n y ({ ‘ d a t a _ D i s c i p l i n a g r a d . fCoddiscip_grd ’: data . d a t a _ D i s c i p l i n a g r a d . f C o d d i s c i p _ g r d } , 35 { $set : { 36 ‘ d a t a _ D i s c i p l i n a g r a d ’: varData [0]. d a t a _ D i s c i p l i n a g r a d 37 }}) 38 }) ;

39 db . EC . find () . forEach ( f u n c t i o n ( data ) { 40 var n o v o A r r a y = [];

41 data . d a t a _ J o i n . forEach ( f u n c t i o n ( data2 ) {

42 data2 . d a t a _ E n f a s e g r a d = db . D o c T y p e E n f a s e g r a d . findOne ({ ‘ _id ’:

43 n o v o A r r a y . push ( data2 ) ; 44 }) ;

45 db . EC . update ({ ‘ d a t a _ D i s c i p l i n a g r a d . fCoddiscip_grd ’: data .

d a t a _ D i s c i p l i n a g r a d . f C o d d i s c i p _ g r d } ,

46 { $set : {

47 ‘ data_Join ’: n o v o A r r a y 48 }}) ;

49 }) ;

Listagem 4.21 Ű Consulta em JavaScript, Mapeamento N-N, Query 2

4.3 Considerações Ąnais

Os modelos e mapeamentos mostrados neste capítulo são apenas algumas das mui- tas possibilidades experimentadas. Após a deĄnição dos mapeamentos nos metamodelos, a implementação do algoritmo e a execução das consultas, alguns aspectos podem ser considerados:

É possível mapear um campo identiĄcador por DocumentType.

• O algoritmo gera consultas envolvendo projeção de dados e junção de duas entidades. • O algoritmo recupera todos os atributos expressados na lista queryAttributes, no entanto, ele não desconsidera os demais atributos pertencentes a entidade/relacio- namento. Por esse motivo, aĄrma-se que o suporte à projeção é apenas parcial.

Em caso de que o DocumentType ao qual foi mapeado a Entidade 1 tiver main=false, e realizar uma projeção dos dados sobre ele, o algoritmo emite uma advertência de que a consulta pode não retornar todas as instancias da entidade.

Em caso de buscar um DocumentType para realizar junção com a Entidade Compu- tada, se o DocumentType encontrado não possui identiĄcadores comuns, o algoritmo emite uma mensagem de que é impossivel realizar junção, pois não há atributos id comuns entre os DocumentTypes. Se o DocumentType tiver mapeado main=false, o algoritmo emite a mensagem de que o mapeamento não é principal. Ou seja, a junção é realizada se tiver id comuns entre os DocumentTypes, e se o DocumentType tiver mapeado com main=true.

• Todas as consultas geradas em JavaScript dentro de um mesmo tipo de cardinalidade (1-1, 1-N, N-1, N-N), independente do tipo de mapeamento, retornam a mesma estrutura do resultado da consulta. Excepcionalmente, o resultado da consulta, em alguns casos pode variar só a ordem dos campos da Entidade 2 e do Relaciomento dentro do campo Śdata_JoinŠ da Entidade Computada.

4.3. Considerações Ąnais 123

Ainda é possível identiĄcar algumas limitações nos resultados:

• É possível mapear as entidades/relacionamentos como referências e documentos embutidos somente no primeiro nível;

• Devido às limitações na implementação, não foi possível testar consultas reais dos sistemas estudados, em especial o sistema ProgradWeb, para o qual existem muitas consultas.

Dadas as observações e limitações acima, considera-se que os resultados foram positivos, pois eles demonstram, por meio de um conjunto de casos de testes em que se buscou cobrir exaustivamente todas as possibilidades de mapeamento, que a abordagem cumpre o seu objetivo.

125

5 Conclusão

Como apresentado no Capítulo 2, Seção 2.3, a maior diĄculdade apontada pe- los trabalhos relacionados envolvendo modelos de dados é a heterogeneidade dos bancos NoSQL. Existem diversos bancos de dados não relacionais, onde cada um tem linguagem de consulta própria, tipos de armazenamentos, estratégias, ferramentas, modelo de dados e outras características que tornam o processo de manipulação de dados uma atividade complexa (DHARMASIRI; GOONETILLAKE, 2013). É necessário levar em considera- ção que mesmo quando um único tipo de banco NoSQL é utilizado, existe mais de uma estratégia diferente para se organizar os dados.

Devido à falta de um padrão para as linguagens de manipulação de dados (DML) que uniĄca e simpliĄca as consultas em armazenamentos de dados NoSQL, o intuito geral dessa pesquisa foi possibilitar ao desenvolvedor especiĄcar consultas de forma conceitual, independente do modelo de dados, utilizando para isso uma linguagem genérica. Poste- rior, automatizar o processo de tradução dessas consultas para consultas especíĄcas na linguagem JavaScript, por meio de técnicas do desenvolvimento de software dirigido por modelos.