R12 기준으로 확인 했을때 보통 툴이나  Dba_Constraints 를 찾아 보게 될건데 오라클 ERP 는 

어떻게 된놈인지 테이블이 2만개가 넘는데 제약 조건이 없다!!  

어떻게 된 일일까? 

그러면 표준테이블 어디서 어떻게 Key 를 찾아서 Extension 개발을 하지?

SQL 조인을 해서 데이터를 뽑던, VIEW 를 만들던 조인이 되야 할꺼 아닌가.

Database 를 공부하다가 보면 제약 조건에 대한 내용은 배우는 거라서 테이블에 웬만하면 다하는줄 알았는데.;;

어느 DB 커뮤니티에 PK FK 가 설정안된 곳이 많이 있냐고 올라온 글을 보고서 뻘 답글을 남긴적이 있다

그러면 어디서 어떻게 찾아야 할까....

현 MOS(My Oracle Support) 구 metalink (구 양배추 현 조세호 도 아니고;;) 에 방대한 문서들도 있고.

Technical Reference Manual 이 잘 되어 있다.  

E-TRM 에서 해당 버전별 OBJECT 를 조회 하면 각 칼럼들의 설명과 더불어 대빵큰(?) 모듈별 ERD 에서

논리적 연결고리를 확인할 수 있다.

http://etrm.oracle.com/pls/etrm/etrm_search.search

▶ ERD는 어느정도 익숙한 모듈이다 싶으면 800%확대해도 간신히 글자가 보이고, 1600% 확대 해야 알아 먹을수 있는 PDF;;

이외에 Database 직접 접근이 가능할 경우  해당 테이블의 Index 중에 Unique Index 를 찾아 테이블의 Key 를 찾아서 

조인해서 사용을 할것이다. 대부분이 그렇지 않을까; (처음 배울때 누가 알려주는 사람이 없어서 이렇게 맨땅에 헤딩경험한 1인)

한가지 더 소개 하자면, application developer 권한의 Database 라는 메뉴를 사용해서 확인이 가능하다.

TABLE Function 을 참고로 해서 보면 툴에서 많이 보던 내용이 나타난다.

각 아이템별 설명은 대부분 아실거라 생각 하고 패쓰 하고.생소한 아이템들에 대해서는 별도로 개인정리하기로 혼자 정함;;

Oracle ERP Primary Key 조회

SELECT ft.table_id,        ft.table_name,        ft.table_type,        fpk.primary_key_id,        fpk.primary_key_name,        fpk.description,        fpk.enabled_flag,        fpkc.column_id,        fc.column_sequence,        fc.column_name,        fc.column_type   FROM fnd_tables              ft,        fnd_columns             fc,        fnd_primary_keys        fpk,        fnd_primary_key_columns fpkc  WHERE 1 = 1    AND ft.application_id = fc.application_id    AND ft.table_id = fc.table_id             AND ft.application_id = fpk.application_id    AND ft.table_id = fpk.table_id          AND fpk.application_id = fpkc.application_id    AND fpk.table_id = fpkc.table_id          AND fpkc.column_id = fc.column_id          AND ft.table_name LIKE '<TABLE_NAME>';

▶ 테이블/칼럼

fnd_tables

fnd_columns

▶ Primary Key/Column

 fnd_primary_keys

 fnd_primary_key_columns

▶ Foreign Key/Column

 fnd_foreign_keys

 fnd_foreign_key_columns

▶ Index/Column

 fnd_indexes;

 fnd_index_columns

DB OBJECT 아이디와 별개로 각각의 고유한 Table ID 를 가지고 있다.

결국은 제약 조건을 테이블에 직접 걸지 않고, 별도의 테이블로 관리를 하고 있었다는거다. 

Surrogate Key 사용은 쿼리가 복잡해진다는 단점이 있지만, 데이터 변경에 대한 영향을 적게 받을수 있기 때문에 운영상의 이점이 있다는 점이 

작용을 한것으로 보인다.

아래의 Wiki 문서 내용을 참조 

• Applications cannot lose their reference to a row in the database (since the identifier never changes).

• The primary or natural key data can always be modified, even with databases that do not support cascading updates across related foreign keys.

https://en.wikipedia.org/wiki/Surrogate_key#Advantages

추가. Table Column 제약조건 찾기 (2014.11.03)

SELECT dcc.owner,        dcc.table_name,        dcc.constraint_name,        dcc.column_name,        decode(dc.constraint_type, 'P', 'PRIMARY KEY', 'U', 'UNIQUE KEY', 'C', 'CHECK OR NOT NULL', 'R', 'FOREIGN KEY') constraint_type   FROM dba_cons_columns dcc,        dba_constraints  dc  WHERE 1 = 1    AND dcc.table_name = dc.table_name    AND dcc.constraint_name = dc.constraint_name    AND dcc.owner = nvl(upper('&USERNAME'), dcc.owner)    AND dcc.table_name = nvl(upper('&TABLENAME'), dcc.table_name)  ORDER BY 1,           2,           3,           4;