PERFORMACE TABELAS EBS

[DanielNN]

Olá,
desde quando comecei a trabalhar com o EBS comecei a estranhar o fato que a oracle não gosta muito de CHAVES(primarias, estrangeiras, etc..). Ela trabalha com índices.
Sei que quando cria uma Chave, é criado um índice único.
1-Mas no final das contas a performace é a mesma(usar apenas indices ou chaves)??
2-Na questão de integridade da informação, não seria mais seguro(e menos trabalhoso) a oracle trabalhar com chaves? Ou essa falta de chaves é para contemplar(ser mais dinâmica) as diversas implantações mundo afora??

[stcoutinho]

Noctífero,

Tive exatamente as mesmas dúvidas de você quando comecei a trabalhar com o EBS 11.5.9, uns quatro anos atrás. Como uma empresa fabricante de banco de dados tem a coragem de ter um ERP que usa a base de dados Oracle sem constraints de PK, FKs, etc? Seria alguma coisa do tipo "faça o que eu digo, não faça o que eu faço?".

Tem até colegas meus que fazem piadas "maldosas" sobre a falta destas constraints, dizendo que - com isso - os erros da ORACLE no EBS fiquem mascarados, evitando a abertura de um volume enorme de chamados no Metalink.

Então ... creio que o principal motivo para a Oracle não criar PKs e FKs na sua base de dados ERP é a de impedir que as pessoas conheçam o modelo de negócio do EBS. Não seria exatamente para evitar "problemas de performance".

Em outras palavras, eles não colocam PKs, FKs e CKs por que não desejaram que um concorrente (e até mesmo um cliente) descobra a relação entre as tabelas do modelo de dados do EBS. Com as constraints, seria possível para um concorrente descobrir exatamente a relação/dependências entre as tabelas e fazer um modelo de dados ERP semelhante ao oracle. Para um usuário, seria possível para ele fazer updates com mais facilidade no ERP, o que poderia depois gerar erros na aplicação. É lógico que neste caso o usuário não vai revelar no chamado do Metalink que "pôs a mão" nas tabelas, o que pode tornar praticamente impossível para a oracle entender se o erro se deve ao produto ou a uma ação indevida do usuário.

Creio até que outros concorrentes da Oracle adotam uma estratégia semelhante à da Oracle. Não conheço o SAP ERP, mas já me disseram que os nomes das tabelas e colunas parecem "grego" para um leigo. Nelas, você como leigo, "bateria o olho" e não saberia para que serve a tabela ou a coluna. E desconfio que na base do SAP não existam PKs e FKs.

Esta mesma coisa acontece com as bibliotecas/packages do EBS da Oracle. Muitas packages básicas do EBS (FND) apresentam seu texto criptografado, para evitar que as pessoas conheçam a fundo como elas funcionam. Se elas fossem descriptografas, um concorrente poderia fazer um ERP parecido com o EBS. Ou um usuário poderia alterar a funcionalidade delas para suas necessidades, mas compromentendo a integridade do EBS.

Agora, voltando à sua questão inicial, eu acho fundamental uma base de dados apresentar PKs, Fks, CKs, etc. Tem muito desenvolvedor que "torce o nariz" para isso, dizendo que "a aplicação GARANTE a integridade do banco". Eu pessoalmente NUNCA acreditei nesta conversa furada, pois um código pode ser desenvolvido de forma errada, uma manutenção pode implantar um componente defeituoso e, um usuário mal-intencionado pode fazer horrores à base de dados se dispor de uma senha e de um SQL*PLUS.

E o pior é que uma falha pode ser detectada só meses depois de ter sido criada. E depois, imagine para "quem sobra" tentar limpar o estrago" feito. Sim, é para o DBA que sobre esta faxina ! E às vezes o estrago é tão grande que não dá para acertar, e você fica com um banco de integridade "capenga". E nestas horas, sempre vai aparecer alguém com a crítica de que " .... porque a "porra" do DBA não colocou antes esta constraint na base !?!? ...". Já passei por algumas situações assim no passado.

Eu prefiro entender que em qualquer banco de dados (MYSQL, ORACLE, SYBASE, SQLSERVER, DB2, etc) uma constraint (PK/CK/FK/UNIQUE) é a "última trincheira/resistência" na manutenção da integridade das informações armazenadas em um banco de dados. No banco, as regras (PK/FK,CK) se tornam permanentes (a não ser que alguém mude ou drope a regra) e são à prova de códigos defeituosos ou usuários mal intencionados.

Um outro ponto pelo motivo que os desenvolvedores não gostam de PKs/Fks e Cks é que o banco responde na hora quando um código mal elaborado tenta gravar dados incorretos na base. Sem estas constraints, o código defeituoso "roda que é uma maravilha". Ou então os desenvolvedores não gostam das constraints por que isso dificulta a atividade de cargas de massa de testes.

Mas no final das contas, não é um dos objetivos de um sistema (aplicação + banco) manter a integridade das informações do usuário? Não se pode desejar os dois mundos (liberdade total x limitada), né?

Talvez os outros participantes deste Forum possam dar outras respostas para suas perguntas, até mesmo opostas ao meu ponto de vista (talvez um pouco radical).

Mas este é um forum, e um dos objetivos dele é a troca de idéias e experiências.

Abraços !

Sergio Coutinho

[DanielNN]

Opa Sérgio,
gostei de sua elaborada resposta.
Realmente já tinha até citado a um amigo que a oracle gasta 10% do tempo para desenvolver uma coisa e os outros 90% para mascarar e dificultar o acesso às informações.
Agora você lenvantou a famosa bandeira (DBA x DESENVOLVEDOR) heheheheheheh.
Sou desenvolvedor, mas me preocupo sempre com a normalização e a regra de negócio ficar o máximo no banco possível.
Tipo aqui na empresa fizeram um sistema que o usuário tinha que informar a data num campo e hora noutro, mas o campo hora não tinha nenhuma validação além de um javascript malfeito para colocar no formato "00:00".
Porém eu consigo inserir letras ou "99:99" por exemplo.
Isto que falaste de não criar constraints para facilitar os testes, achei engraçado. Afinal se deve procurar fazer testes com informações mais fieis possíveis para validar o negócio.
Enfim, existem desenvolvedores e DBAs bons e os "não tão bons".
Tipo quando passo alguns objetos para ser colocado em produção, supostamente foi posto vou testar e NADA.
Falo com o DBA, ele "não, está tudo OK. Testa lá denovo, deve ser cache...". Quando volto MAGICAMENTE(feito naquela hora) ta como eu gostaria.
Mas esta intriga é pra outro post. .

[dr_gori]

Bem, na minha opinião, um dos motivos de não ter constraints ***em alguns casos*** é a questão dos FLEX FIELDS.
Como praticamente todas tabelas possuem flex fields, é impossível ter constraints no banco, pois a regra é definida em tempo de execução.

Tanto as Descriptive Flex Fields quanto os Key Flex Fields inviabilizam o uso de constraints.

:-/

[stcoutinho]

Hum ..

Estava consultando um forum hoje e constatei que - apesar de não existirem PK/FK nas tabelas do EBS - o produto dispõe de tabelas FND onde estes relacionamento entre as tabelas são descritos:

FND_PRIMARY_KEY (relação de PKs “lógicas”)
FND_PRIMARY_KEY_COLUMNS (colunas que compõe cada PK)

FND_FOREIGN_KEY (relação de FKs “lógicas”)
FND_FOREIGN_KEY_COLUMNS (colunas que compõe cada FK)

Para os campos FLEXFIELD, também existem algumas tabelas descritivas:

FND_DESCRIPTIVE_FLEXS
FND_DESCR_FLEX_COLUMN_USAGES

Fique surpreso ao constatar que estas tabelas já existem desde o EBS 11.5.9. Vou tentar pesquisar para ver se consigo extrair scripts "DDL" destas constraints, ou pelo menos extrair as informações de relacionamento em uma forma mais amigável.

Abraços,

Sergio Coutinho

[stcoutinho]

Só pra deixar registrado,

Fiz algumas queries para obter informações de PK/FK das tabelas do EBS:

Selecionar tudo

-- Obtendo as PKs das tabelas
SELECT TBO.TABLE_NAME,
       TBO.DESCRIPTION,
       PK.PRIMARY_KEY_NAME
FROM       
(SELECT APPLICATION_ID,
        TABLE_ID,
        TABLE_NAME,
        DESCRIPTION
   FROM FND_TABLES) TBO,
(SELECT APPLICATION_ID,
        TABLE_ID,
        PRIMARY_KEY_NAME
   FROM FND_PRIMARY_KEYS) PK
WHERE PK.TABLE_ID = TBO.TABLE_ID
  AND PK.APPLICATION_ID = TBO.APPLICATION_ID
ORDER BY TBO.TABLE_NAME

-- Obtendo as FKs das tabelas
SELECT TBO.TABLE_NAME,
       TBO.DESCRIPTION,
       FK.FOREIGN_KEY_NAME
FROM       
(SELECT APPLICATION_ID,
        TABLE_ID,
        TABLE_NAME,
        DESCRIPTION
   FROM FND_TABLES) TBO,
(SELECT APPLICATION_ID,
        TABLE_ID,
        FOREIGN_KEY_NAME
   FROM FND_FOREIGN_KEYS) FK
WHERE FK.TABLE_ID = TBO.TABLE_ID
  AND FK.APPLICATION_ID = TBO.APPLICATION_ID
ORDER BY TBO.TABLE_NAME,
         FK.FOREIGN_KEY_NAME

-- Obtendo as FKs/Pks das Tabelas
SELECT TB_FK.TABLE_NAME_FK,
       FK.FOREIGN_KEY_NAME,
       PK.PRIMARY_KEY_NAME,
       TB_PK.TABLE_NAME_PK       
FROM       
(SELECT APPLICATION_ID,
        TABLE_ID AS TABLE_ID_PK,
        PRIMARY_KEY_ID,
        PRIMARY_KEY_NAME
   FROM FND_PRIMARY_KEYS) PK,
(SELECT PRIMARY_KEY_APPLICATION_ID,
        TABLE_ID AS TABLE_ID_FK,
        PRIMARY_KEY_ID,
        FOREIGN_KEY_NAME
   FROM FND_FOREIGN_KEYS) FK,
(SELECT APPLICATION_ID,
        TABLE_ID,
        TABLE_NAME AS TABLE_NAME_PK,
        DESCRIPTION
   FROM FND_TABLES) TB_PK,
(SELECT APPLICATION_ID,
        TABLE_ID, 
        TABLE_NAME AS TABLE_NAME_FK,
        DESCRIPTION
   FROM FND_TABLES) TB_FK
WHERE FK.PRIMARY_KEY_ID = PK.PRIMARY_KEY_ID
  AND FK.PRIMARY_KEY_APPLICATION_ID = PK.APPLICATION_ID
  AND PK.TABLE_ID_PK = TB_PK.TABLE_ID
  AND FK.TABLE_ID_FK = TB_FK.TABLE_ID  
ORDER BY 3,2

Dá para fazer muito mais com as tabelas FND do EBS. Mas fica aqui como exemplo desta possibilidade de se extrair as PK/FK do EBS. Não sei se o produto usa estas tabelas para alguma consistência lógica das informações do ERP.

Abraços,

Sergio Coutinho

[DanielNN]

Sensacional Sérgio,

De alguma forma o produto utiliza essas informações.
Fucei um pouco aqui e adicionei as colunas envolvidas nas PK's.

Selecionar tudo

SELECT TBO.TABLE_NAME,
       TBO.DESCRIPTION,
       PK.PRIMARY_KEY_NAME,
       COL.COLUMN_NAME,
       COL.DESCRIPTION COL_DESCRIPTION
  FROM FND_TABLES              TBO,
       FND_PRIMARY_KEYS        PK,
       FND_PRIMARY_KEY_COLUMNS PK_COL,
       FND_COLUMNS             COL
 WHERE PK.TABLE_ID = TBO.TABLE_ID
   AND PK.APPLICATION_ID = TBO.APPLICATION_ID
   AND PK_COL.PRIMARY_KEY_ID = PK.PRIMARY_KEY_ID
   AND PK_COL.COLUMN_ID      = COL.COLUMN_ID
   AND TBO.TABLE_NAME         = 'PO_LINES_ALL'
 ORDER BY 1,3,4;

Aqui também vai a estrutura da tabela com o diferencial da descrição dos campos(o que é raro encontrar na própria tabela) e a utilização dos mesmo em flexfields:

Selecionar tudo

SELECT TBO.TABLE_NAME,
       TBO.DESCRIPTION,
       COL.COLUMN_NAME,
       COL.DESCRIPTION COL_DESCRIPTION,
       COL.COLUMN_TYPE,
       COL.NULL_ALLOWED_FLAG,
       COL.WIDTH,
       COL.FLEXFIELD_USAGE_CODE,
       COL.FLEXFIELD_NAME
  FROM FND_TABLES              TBO,
       FND_COLUMNS             COL
 WHERE TBO.TABLE_ID             = COL.TABLE_ID
   AND TBO.APPLICATION_ID       = COL.APPLICATION_ID
   AND TBO.TABLE_NAME           = 'PO_LINES_ALL'
 ORDER BY 1,3;

[stcoutinho]

Opa Nocifero !

Muito boas as suas queries. Elas vão me ajudar em um levantamento que estou fazendo.

O que me surpreende é que os comentários das tabelas e colunas são armazenados na FND_TABLES ou FND_COLUMNS, ao invés do dicionário de dados do banco.

Não estou certo, mas desconfio que no EBS deve ter um modulo no ADMINISTRADOR SISTEMA, onde se pode consultar estas informações sobre as tabelas. Talvez ele busque estas informações nestas tabelas FND.

Abraços e tudo de bom !

Sergio Coutinho

[dr_gori]

Essas queries vão lá pro topico "queries uteis para Oracle Applications". heheheh
feitoooo
muito bom!

[dr_gori]

Juntei as 2 query do Noctifero em 1 só...
Abaixo:

Selecionar tudo

SELECT TBO.TABLE_NAME,
       TBO.DESCRIPTION,
       COL.COLUMN_NAME,
       PK.PRIMARY_KEY_NAME,       
       COL.DESCRIPTION COL_DESCRIPTION,
       COL.COLUMN_TYPE,
       COL.NULL_ALLOWED_FLAG,
       COL.WIDTH,
       COL.FLEXFIELD_USAGE_CODE,
       COL.FLEXFIELD_NAME
  FROM FND_TABLES              TBO,
       FND_COLUMNS             COL,
       FND_PRIMARY_KEYS        PK,
       FND_PRIMARY_KEY_COLUMNS PK_COL
WHERE TBO.TABLE_ID             = COL.TABLE_ID
   AND TBO.APPLICATION_ID       = COL.APPLICATION_ID
   AND TBO.TABLE_NAME           = 'PO_LINES_ALL'
   AND PK_COL.PRIMARY_KEY_ID = PK.PRIMARY_KEY_ID(+)
   AND PK_COL.COLUMN_ID(+)       = COL.COLUMN_ID
ORDER BY 1,column_sequence;

[DanielNN]

Legal.
Salvei aqui para mim essa tb. .