↳
Explained my project details that worked on
↳
As best of my knowledge and technical coding which helps me to replied in this process of 3 rounds. Minder
↳
answered in detail
↳
OUTER JOIN returns all records that match in either left or right tables.
↳
as best as i can
↳
Explained better the process of ETL and written query as they expected in that particular scenario Minder
↳
solution were involving window function, nested queries and joins
↳
I can understand the pain of lack of proper documentation. Start from the most visible point of the application, probably, the login point to the app. I am a DW / SQL / ETL resource experienced in Prod support for last 4 years over multiple ETL tools. Step-1 : Scheduler Start from scheduler jobs. thats where you cn see the processes being triggered. Scheduler is basically a caller which triggers the process based on the order of execution and time of execution. so, Scheduler is best part. Step - 2 : Landing Area/ETL Layer next, a typical Warehouse application will have second step as either a File handling process or a ETL Sequence/Workflow. Analyse the same in their respective UI's. Step-3 : Warehouse Last one is the Warehouse tables where the data finally settles. Though this is just less than 10 lines, believe me, I was able to document a technically undocumented Control-M >> Unix Shell >> Datastage >> Oracle Warehouse (Partitioned tables) to provide a potential effort required in changing the Landing Area and ETL Tool. so, it took less thn a month to properly document and get it reviewed, where Data tables were close to 120 and ETL components were 250+, not to mention the shell scripts which count up for 80, n scheduler jobs in Control-M which are 50+, all being, luckily Monthly. Support is tough ask, but documenting the technical specs of an undocumented warehouse application is very interesting part... :D i loved it. Minder