09916225584-o.sandeep 1. Star schema: Characterized by one or more fact tables and corresponding dimension tables 2.

Fact table : Central table in a star schema that contains the metrics analyzed by dimensions. 3. Minidimension table : Contains subsets of heavily queried attributes of parent dimensions 4. Hierarchy table Enables users to drill in reports 5. Internal table : Stores important information that is used during the ETL process, are rebuilt during each ETL process, and are not used by end-user query tools 6. Conforming dimension table : Table shared by fact tables allowing consistent analysis across multiple star schemas 7. Dimension table : Stores descriptions of the characteristics of a business and descriptive information that qualifies a fact 8. Helper table : Used by the Oracle Business Analytics Warehouse to solve complex problems that cannot be resolved by simple dimensional schemas 9. Staging table: Intermediate storage table within the OBAW that holds data for transformation before loading the data into the dimension and fact tables 10. Aggregate table : Improves performance by summing fact data with respect to a given dimension 11. Oracle Business Analytics Warehouse: A modular enterprise-wide data warehouse data model with conformed dimensions for data integrated from multiple sources 12. DATASOURCE_NUM_ID: Unique identifier of the source system from which data was extracted 13. ETL_PROC_WID : Unique identifier for the specific ETL process used to create or update data 14. INTEGRATION_ID: Unique identifier of a dimension or fact entity in its source system Different Types of Dimensions and Facts in Data Warehouse

Dimension -A dimension table typically has two types of columns, primary keys to fact tables and textual\ descriptive data. Fact -A fact table typically has two types of columns, foreign keys to dimension tables and measures those that contain numeric facts. A fact table can contain fact’s data on detail or aggregated level. Types of Dimensions Slowly Changing Dimensions: Attributes of a dimension that would undergo changes over time. It depends on the business requirement whether particular attribute history of changes should be preserved in the data warehouse. This is called a Slowly Changing Attribute and a dimension containing such an attribute is called a Slowly Changing Dimension. Type 1 Slowly Changing Dimension: In Type 1 Slowly Changing Dimension, the new information simply overwrites the original information. In other words, no history is kept. Advantages: This is the easiest way to handle the Slowly Changing Dimension problem, since there is no need to keep track of the old information. Disadvantages: - All history is lost. By applying this methodology, it is not possible to trace back in history. For example, in this case, the company would not be able to know that Christina lived in Illinois before. Type 2 Slowly Changing Dimension In Type 2 Slowly Changing Dimension, a new record is added to the table to represent the new information. Therefore, both the original and the new record will be present. The new record gets its own primary key. Advantages: - This allows us to accurately keep all historical information. Disadvantages: - This will cause the size of the table to grow fast. In cases where the number of rows for the table is very high to start with, storage and performance can become a concern. - This necessarily complicates the ETL process. When to use Type 2:

 Type 3: The original record is modified to reflect the change.  Type 1: The new record replaces the original record. This allows us to keep some part of history. The primary key in each dimension table is related to a foreign key in the fact table. each dimension is represented by a single dimensional table. For example. where each point of the star explodes into more points.Type 2 slowly changing dimension should be used when it is necessary for the data warehouse to track historical changes. that dimensional table is normalized into multiple lookup tables. and when such changes will only occur for a finite number of time. Disadvantages: . each representing a level in the dimensional hierarchy. one indicating the original value. whereas in a snowflake schema. . and one indicating the current value. Type 3 Slowly Changing Dimension In Type 3 Slowly Changing Dimension. there will be two columns to indicate the particular attribute of interest. if Christina later moves to Texas on December 15. the customer is treated essentially as two people. the California information will be lost.Thereby. Star Schema In the star schema design.     Holds multiple subject areas Holds very detailed information Works to integrate all data sources Does not necessarily use a dimensional model but feeds dimensional models. Each dimension is represented as a single table. In a star schema. 2003. since new information is updated. When to use Type 3: Type III slowly changing dimension should only be used when it is necessary for the data warehouse to track historical changes. No trace of the old record exists  Type 2: A new record is added into the customer dimension table.This does not increase the size of the table.Type 3 will not be able to keep all history where an attribute is changed more than once. a single object (the fact table) sits in the middle and is radically connected to other surrounding objects (dimension lookup tables) like a star. Data Warehouse: is a collection of data marts representing historical data from different operations in the company. Snowflake Schema The snowflake schema is an extension of the star schema. There will also be a column that indicates when the current value becomes active. Advantages: .

A junk dimension is a collection of random transactional codes. Junk dimensions are often created to manage the foreign keys created by Rapidly Changing Dimensions. flags and text attributes that are unrelated to any particular dimension. or across multiple data marts or data warehouses. This new dimension is called a Rapidly Changing Dimension. there are situations where having this kind of relationship makes sense in data warehousing. think about a record of student attendance in classes.Data Mart: is a segment of data warehouse that can provide data for reporting and analysis on a section. a fact less fact table does not make sense. flags and text attributes that are unrelated to any particular dimension. For example. since a fact table is.data that is dimensional in nature but stored in a fact table. The junk dimension is simply a structure that provides the convenient place to store the junk dimension. One solution is to move the attribute to its own dimension. department or operation in the company. . degenerate dimensions . Finance. with a separate foreign key in the fact table. but if you do need to track the changes. junk dimensions .a collection of miscellaneous attributes codes. this avoid having a large number of foreign keys in the fact table. Conformed Dimensions: A Dimension that is used in multiple locations is called a conformed dimension. after all. Junk Dimensions: A junk dimension is a single table with a combination of different and unrelated attributes to avoid having a large number of foreign keys in the fact table. A conformed dimension may be used with multiple fact tables in a single database. In this case. It is essentially an intersection of dimensions.a dimension that can play different roles in a fact table depending on the context. the Rapidly Changing Attribute is no problem. One solution is to generate an surrogate key with Null for all the other attributes. about facts. but is often called an inferred dimension. On the surface. If you don’t need to track the changes. Rapidly Changing Dimensions: A dimension attribute that changes frequently is a Rapidly Changing Attribute. the time dimension. Inferred Dimensions: While loading fact records. the fact table would consist of 3 dimensions: the student dimension. a dimension record may not yet be ready. and the class dimension. Fact less Fact Table A fact less fact table is a fact table that does not have any measures. role playing dimensions . unit.     Often holds only one subject area. This should technically be called an inferred member.for example. However. using a standard Slowly Changing Dimension technique can result in a huge inflation of the size of the dimension. or Sales May hold more summarised data (although many hold full detail) Concentrates on integrating information from a given subject area or set of source systems Is built focused on a dimensional model using a star schema.

A static dimension can be loaded manually — for example with Status codes — or it can be generated by a procedure. which can serve as the Shrunken Dimension. but are created within the context of the data warehouse. A sales fact is a good example for additive fact. but not the others. Role Playing Dimensions: A role-playing dimension is one where the same dimension key — along with its associated attributes — can be joined to more than one foreign key in the fact table. a fact table may include foreign keys for both Ship Date and Delivery Date. and not in a separate dimension table. The first example presented here is a cumulative fact table. Based on the above classifications. But the same date dimension attributes apply to each foreign key. with ProductCategory as its primary key. In a data warehouse. For example.Degenerate Dimensions: A degenerate dimension is when the dimension attribute is stored as part of fact table.Eg: A fact table which has only product key and date key is a factless fact. For example. Creating a smaller dimension table. Shrunken Dimensions: A shrunken dimension is a subset of another dimension. Non-Additive: Non-additive facts are facts that cannot be summed up for any of the dimensions present in the fact table. Fact less Fact Table: In the real world. which is in the Product table. Eg: Facts which have percentages. ratios calculated. Static Dimensions: Static dimensions are not extracted from the original data source. Here the date dimension is taking multiple roles to map ship date as well as delivery date. There are no measures in this table. and hence the name of Role Playing dimension. But still you can get the number products sold over a period of time. Eg: Daily balances fact can be summed up through the customers dimension but not through the time dimension. it is possible to have a fact table that contains no measures or facts. is one way of dealing with this situation of heterogeneous grain. The facts for this type of fact tables are mostly additive facts. These tables are called “Factless Fact tables”. such as a Date or Time dimension. . but the Target fact table may include a foreign key only for ProductCategory. the Orders fact table may include a foreign key for Product. For example. Types of Facts Additive: Additive facts are facts that can be summed up through all of the dimensions in the fact table. this fact table may describe the total sales by product by store by day. there is probably already a separate table for ProductCategory. Semi-Additive: Semi-additive facts are facts that can be summed up for some of the dimensions in the fact table. fact tables are categorized into two: Cumulative: This type of fact table describes what has happened over a period of time. You can use these values to trace back to transactions in the OLTP system. so you can join the same dimension table to both foreign keys. If the Product dimension is snowflaked. but much less granular. these are often used as the result of a drill through query to analyze the source of an aggregated number in a report. These are essentially dimension keys for which there are no other attributes.

SQL>SELECT SAL FROM ( SELECT * FROM EMP ORDER BY SAL DESC ) WHERE ROWNUM <4 5) DISPLAY 9th FROM THE EMP TABLE? SQL>SELECT ENAME FROM EMP WHERE ROWID=(SELECT ROWID FROM EMP WHERE ROWNUM<=10 MINUS SELECT ROWID FROM EMP WHERE ROWNUM <10) select second max salary from emp.emp ) SELECT * FROM emp Emp1 WHERE (5) = ( SELECT COUNT(DISTINCT(Emp2. . <Col_Name> from table_name group by <col_name> having count(*) > 1. and usually includes more semi-additive and non-additive facts. 4) DISPLAY TOP 3 SALARIES FROM EMP.rowid).emp >= a. SELECT * FROM t1 a WHERE n = (SELECT COUNT(rowid) FROM t1 b WHERE a.sal > Emp1. SQL>Delete from emp where rowid not in(select min(rowid) from emp group by ename) 2) TO DISPLAY 5 TO 7 ROWS FROM A TABLE SQL>select ename from emp where rowid in(select rowid from emp where rownum<=7 minus select rowid from emp where rownum<5) 3) DISPLAY TOP N ROWS FROM TABLE? SQL>SELECT * FROM (SELECT * FROM EMP ORDER BY ENAME DESC) WHERE ROWNUM <10.rowid >= b. select count(*). SELECT * FROM emp a WHERE ( n+1 ) = ( SELECT COUNT( DISTINCT ( b. select max(sal) fromemp where sal<(select max(sal) from emp). Delete duplicate records from a table 1 ) Write a Query To Delete The Repeted Rows from emp table.sal)) FROM emp Emp2 WHERE Emp2.Snapshot:This type of fact table describes the state of things in a particular instance of time. The second example presented here is a snapshot fact table.sal ) To Retrieve nth row.emp ) ) FROM emp b WHERE b.

fst_nm.ser_no).ename||' works for '||e2.ser_no ).ename "Employees and their Managers" FROM emp e1. deptid. emp e2 WHERE e1.key_values).empname. Delete Duplicate records. What is the difference between DELETE and TRUNCATE ? a) DELETE is a DML command and TRUNCATE is a DDL command. 1.select * from <table> where rownum < N+1 minus select * from <table> where rownum < N Self Join SELECT e1. GROUP BY 2. Using rowid DELETE FROM tbl_test WHERE ROWID NOT IN (SELECT MIN (ROWID) FROM tbl_test ser_no. DELETE FROM table_name A WHERE ROWID > ( SELECT min(rowid) FROM table_name B WHERE A.mgr = e2. Difference between UNION and UNION ALL clause – Oracle UNION and UNION ALL used to combine ( set operation ) two or more query results. 3. 3.ser_no = e2.salary ). UNION will eliminate duplicate rows and UNION ALL will display all rows. How to find duplicate records? select id. Using self-join delete from tbl_test a where rowid<(select max(rowid) from tbl_test b where a.key_values = B.salary from emp group by empname. cmnt).empname. count(*) from t1 group by id having count(*) > 1.ser_no = b. delete from tbl_test e1 where rowid not in (select max(rowid) from tbl_test e2 where e1.empno.salary) in (select max(empno). Using group by delete from emp where (empno. .

or may be a summary based on aggregations of a table's data. 1. A snapshot can be redefined as a materialized view. 2. What is the difference between PRIMARY KEY and UNIQUE KEY constraints ? 1. it may be a local copy of data located remotely. are also known as snapshots. But synonym can be on view. http://www. When do you use WHERE clause and when do you use HAVING clause? The WHERE condition lets you restrict the rows selected to those that satisfy one or more conditions.field1). Materialized views are basically used to increase query performance since it contains results of a query.php http://www.a2zinterviews. UNIQUE KEY columns can have null values but PRIMARY KEY column cannot accept null values. A table can have only one PRIMARY KEY column but many UNIQUE KEY columns allowed. whereas a column that compose a UNIQUE is not automatically defined to be mandatory must also specify the column is NOT NULL.html Why use materialized view instead of a table? A materialized view is a database object that contains the results of a query. . The columns that compose PK are automatically define NOT NULL. What is the difference between a view and a synonym? Synonym is just a second name of table used for multiple link of database. For example.gcreddy.com/RDBMS/oracle/oracle-interview-questions_2. They should be used for reporting instead of a table for a faster execution. View can be created with many tables. What is a CO-RELATED SUBQUERY A CO-RELATED SUBQUERY is one that has a correlation name as table or view designator in the FROM clause of the outer query and the same correlation name as a qualifier of a search condition in the WHERE clause of the subquery. and with virtual columns and with conditions. eg SELECT field1 from table1 X WHERE field2>(select avg(field2) from table1 Y where field1=X. or may be a subset of the rows and/or columns of a table or join result. Materialized views. Use the HAVING clause to restrict the groups of returned rows to those groups for which the specified condition is TRUE. which store data based on remote tables. What is difference between UNIQUE and PRIMARY KEY constraints A table can have only one PRIMARY KEY whereas there can be any number of UNIQUE keys.com/2012/12/oracle-interview-questions-and-answers.b) TRUNCATE re-set the memory blocks after execution and much faster than DELETE in most of the circumstances.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.