Se os schemas todos estão num único database, ESQUEÇA tudo que te falaram de dblink, dblink serve para abrir conexões de um database em outro... Vê porque eu sempre insisto na nomenclatura correta ? Acaba sempre dando confusão, as pessoas que falaram em dblink estavam/estão/estariam 100% CORRETAS ** SE ** fossem databases diferentes, sendo um database único não faz sentido NENHUM o dblink....
Muito bem : no rdbms Oracle o conceito é que NÃo existe nenhum agrupamento lógico acima do SCHEMA, então esse "schema maior", esse "schema que contém outros schemas", não existe, fisicamente vc não terá como fazer.. O que vc pode fazer é trabalhar no nível LÓGICO, ie : digamos que vc tem um schema X que tem as tabelas da aplicação X (digamos, as tabelas TX1, TX2, etc), um outro schema Y aonde residem os objetos da app Y (digamos, a tabela TY1, a tabela TY2, etc), um outro schema Z aonde residem objs da app Z ,assim por diante, E agora vc quer selecionar todos de uma vez, ok ? Sendo isso mesmo, entenda que *** NÂO É *** absolutamente exigido vc fazer NADA especificamente pra isso, okdoc ? Tranquilamente vc TEM a opção de ter um schema N que recebeu os GRANTs de select nas tabelas do X, do Y e do Z , e aí vc conecta pelo schema N e escreve a sua query tipo : ou ainda, faz o JOIN entre as tabelas se houver chave, coisas do tipo... E claro, se vc quiser "esconder" os schemas (pois isso será usado por um usuário não-especialista, digamos) a opção seria vc ter uma views, ie : CREATE VIEW CONSULTA_CONSOLIDADA as SELECT camposqueeuquro FROM X.TX1, X.TX2 UNION SELECT camposqueeuquero FROM Y.TY1, Y.TY2 .... e aí vc fala pro cara : ó, pra vc ter a visão consolidade de todos os schemas, vc por favor escreva : SELECT * FROM CONSULTA_CONSOLIDADA; belezinha ??? É isso aí.... Uma outra opção seria vc ter no schema N novo que vc vai criar uma cópia Já processada e Consolidada dos dados - isso tem a desvantagem de ocupar mais espaço em disco, MAS tem a vantagem de já trazer os dados "processados", no seguinte sentido : normalmente, vc Não Precisa ver a tabela X.TX1 , X.TX2, etc, inteirinhas, MAS sim só os dados dos últimos poucos meses, coisa assim (isso é Típico de ocorrer se quem vai usar a consulta consolidade é um gerente, um Administrador do negócio, etc : esses caras NÃo Querem ter os dados detalhados todos de todos os mesmes, normalmente) : vc faria então no schema N uma VIEW MATERIALIZADA, esse bichinho é como se fosse um agregador de dados. Vc criaria tipo : CREATE MATERIALIZED VIEW CONSULTA_CONSOLIDADA as SELECT camposqueeuquro FROM X.TX1, X.TX2 WHERE condiçoes... UNION SELECT camposqueeuquero FROM Y.TY1, Y.TY2 .... e aí (Automagicamente se possível, veja as Restrições nos manuais Oracle) sozinho a cada vez que entram ou saem dados das tabelas originais a view materializada é atualizada.... E vc continuaria indicando pra pessoa que quer consultar : ó, pra vc ter a visão consolidade de todos os schemas, vc por favor escreva : SELECT * FROM CONSULTA_CONSOLIDADA; blz ? As outras opções, tal como Sinônimos, eu entendo que não seriam de interesse pra vc... []s Chiappa --- Em [email protected], "ciadart" <rafael.henrique@...> escreveu > > Chiappa bom dia!! > > Peço desculpas quanto a falta de nomenclatura. Irei utiliza-la da proxima vez. > > Tenho vários SCHEMAS dentro de um único DATABASE. > > Desejo agrupar estes SCHEMAS em um único SCHEMA MAIOR. > > Ficou claro? > > Obrigado a todos pelo apoio. > > SDs, > > RAfael > > > > > --- Em [email protected], José Laurindo <jlchiappa@> escreveu > > > > Rafael, boa noite : primeira coisa, por favor vamos usar a nomenclatura > > Oracle correta ? Se não , corremos um SÉRIO risco de mal-entendidos e > > respostas corretas de acordo com um pré-requisito que não é o seu... > > Seguinte, no RDBMS Oracle nós temos o DATABASE (o conjunto de arquivos, > > não só os de dados mas também os de init, de controle, etc), e esses > > arquivos são abertos e lidos pela INSTÂNCIA (os binários Oracle), formando > > um database aberto, pronto pra uso. nesse database aberto, cada usuário que > > cria tabelas/índices o faz numa área lógica particular , o SCHEMA. > > > > Com isso eu pergunto : o que é a tal BASE que vc fala : são objetos em > > SCHEMAS diferentes mas dentro do mesmo database ** OU ** são SCHEMAS > > diferentes em diferentes databases ???? > > > > Isso é CRUCIAL para avaliarmos o seu problema - a resposta do dblink é > > TOTALMENTE correta se forem diferentes schemas em diferentes instãncias de > > diferentes databases (sejam databases no mesmo servidor OU em servidores > > diferentes), MAS dblink seria uma opção ERRADA (ou ao menos > > contra-recomendada) SE forem schemas diferentes (tabelas de diferentes > > usuários) mas NO MESMO DATABASE... responda isso que a gente pode continuar > > a partir daí... > > > > []s > > > > Chiappa > > > > --- Em [email protected], Rafael HM Pereira <rafael.henrique@> > > escreveu > > > > > > Pessoal boa noite!! > > > > > > Seguindo a orientação de vocês, tentei criar os sinonimos no banco sem > > > sucesso. > > > > > > Pelo fato das bases de dados serem identicas (mesma estrutura e apenas > > > dados > > > diferentes), o oracle rejeita a criação dos sinonimos dizendo que já > > > existe > > > um objeto com o mesmo nome. > > > > > > Alguem teria uma dica pra driblar este problema? > > > > > > > > > -- > > > Att, > > > > > > Rafael HM Pereira > > > > > > Linux User Id: 360166 > > > Skype: rafaelhmpereira > > > MSN: rafael.henrique@ > > > Blog: http://rafaelhmpereira.blogspot.com > > > LinkedIn: http://br.linkedin.com/in/rafaelhmpereira > > > (27) 9233-0734 / (27) 3328-4320 > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > >
